Tous les articles

Écrire de bons cas de test est une compétence qui s'apprend. En écrire de mauvais est l'une des façons les plus courantes de ralentir son équipe sans s'en rendre compte.

La plupart des juniors traitent severity et priority comme la même chose. Voici pourquoi c'est faux et comment maîtriser la différence change la façon dont toute votre équipe perçoit votre travail.

Essayer de tout tester de manière égale n'est pas de la rigueur, c'est la garantie de manquer ce qui compte. Un cadre pratique pour prioriser l'effort de test par risque.

Écrire des cas de test à l'instinct rate les bugs les plus importants. Ces quatre techniques vous donnent un processus reproductible pour choisir les bonnes entrées et réduire le nombre de tests sans réduire la couverture.

Si le QA rejoint votre sprint le neuvième jour, vous faites du Waterfall avec une horloge de deux semaines. Voici comment le QA s'intègre vraiment dans chaque cérémonie et phase Agile.

Soumettre un rapport de bug n'est que le point de départ. Voici ce que chaque état de New à Closed signifie vraiment, qui est responsable de chaque transition et comment éviter que les bugs disparaissent silencieusement.

La plupart des équipes écrivent trop de tests E2E et pas assez de tests unitaires. La pyramide des tests vous donne un modèle mental pour la bonne distribution et explique pourquoi la forme compte.

Vous n'avez pas besoin d'une certification en sécurité pour trouver des bugs de sécurité. Voici les vérifications que tout ingénieur QA peut effectuer: failles d'auth, lacunes de contrôle d'accès, validation des entrées et flags de cookies.

La plupart des équipes QA suivent les mauvaises métriques. Voici ce que le taux d'échappement des défauts, la densité des défauts et le temps moyen de détection vous disent vraiment, et pourquoi le pourcentage de couverture est presque inutile.

Le TDD est écrit du point de vue du développeur. Voici ce que cela signifie pour le QA, où vous vous intégrez dans une équipe TDD, ce qu'est l'ATDD et comment le BDD étend le pattern à toute l'équipe.

Les tests de fumée et les tests de régression sont souvent confondus. Ils répondent à des questions différentes, s'exécutent à des moments différents et ont des portées différentes. Voici une explication claire.

Vous ne pouvez pas tout tester, mais vous pouvez tester les bonnes choses. La partition d'équivalence et l'analyse des valeurs limites vous aident à choisir le minimum de tests qui détectent le maximum de bugs.

Les équipes utilisent ces termes différemment et la confusion est réelle. Un scénario est la question; un cas de test est la procédure complète pour y répondre.

"Construisons-nous correctement le produit?" vs "Construisons-nous le bon produit?" Cette distinction classique décrit deux approches de test fondamentalement différentes.

Si vous avez testé une app sans lire le code source, vous avez fait du test boîte noire. Si vous avez regardé le code pour décider quoi tester, vous avez fait boîte blanche. Quand chacun s'applique-t-il?

Un plan de test répond à une question: comment allons-nous tester ceci? Pas seulement "on lancera des tests Selenium", mais quoi précisément, par qui, quand et ce que signifie "terminé".

Les tests d'acceptation sont la vérification finale avant la mise en production du logiciel. Ils répondent à la question: ce logiciel fait-il ce que le business a besoin qu'il fasse?

En TDD, les tests s'écrivent avant le code. Pour les ingénieurs QA, comprendre le TDD est utile pour collaborer avec des développeurs qui le pratiquent et appliquer une approche similaire aux tests d'acceptation.

"Comment savez-vous que vos tests sont efficaces?" Si vous ne pouvez pas répondre à cette question, vous testez à l'aveugle. Les métriques vous donnent des données pour améliorer votre processus, justifier vos ressources et communiquer la valeur du QA.

Votre app fonctionne parfaitement avec 1 utilisateur. Fonctionne-t-elle avec 1 000? Les tests de performance répondent aux questions que les tests fonctionnels ne peuvent pas: quelle est sa rapidité et combien d'utilisateurs peut-elle gérer?

Les tests de sécurité ne sont pas réservés aux pentesters. Les ingénieurs QA peuvent et doivent tester les vulnérabilités courantes qui apparaissent constamment et que les outils automatisés détectent facilement.

Les tests mobiles diffèrent des tests web — interactions tactiles, tailles d'écran variables, réseaux lents. Ce guide couvre ce que les ingénieurs QA doivent savoir et comment l'aborder concrètement.