Testeur logiciel / ingénieur qualité — tâches, une par une

Les tests de régression manuels

La régression scriptée était déjà automatisable ; ce qui a changé, c'est que des agents peuvent désormais piloter une vraie interface depuis une description en langue courante et réparer leurs propres scripts quand l'interface change, ce qui a retiré la charge de maintenance qui gardait les équipes sur le test manuel. C'est le plus gros bloc d'heures de la plupart des postes qualité et il part vite.

C'est explicitement le plus gros bloc d'heures de la plupart des postes qualité. Rien dans les tâches restantes n'est assez grand pour absorber les gens dont il remplissait la semaine.

Écrire les cas de test et l'automatisation

Générer des tests depuis une spécification ou depuis le code lui-même est l'un des usages les plus efficaces des outils de génération de code, et une couverture qui aurait pris une itération apparaît désormais en une après-midi. Les tests générés sont superficiels de la même façon que le code généré — ils confirment ce que le code fait plutôt que ce qu'il devrait faire — raison pour laquelle la tâche suivante compte davantage.

Les tests générés confirment ce que le code fait plutôt que ce qu'il devrait faire. Les équipes qui mesurent la couverture plutôt que les défauts concluront que cette tâche est résolue, ce qui est un problème de mesure qui nuit aux testeurs.

Les tests exploratoires et adversariaux

Les tests générés dérivent de la spécification ou du code : ils partagent donc ses angles morts. Trouver la défaillance que personne n'a imaginée exige un modèle de la façon dont de vrais utilisateurs et de vrais systèmes se conduisent mal, bâti par l'expérience de ce produit et de ce domaine. Les outils élargissent la recherche ; l'hypothèse sur l'endroit où chercher reste humaine, et c'est là que sont les bogues coûteux.

L'hypothèse sur l'endroit où chercher se bâtit en ayant fait le travail de régression qui disparaît. Cette tâche est protégée par une expérience que la filière ne produit plus.

Décider si cela part

C'est une décision de responsabilité aux conséquences organisationnelles, et les équipes n'ont montré aucune envie de la déléguer. Les tableaux de bord résument l'état ; la décision sur le niveau de risque que cette livraison, cette base de clients et cette semaine peuvent supporter se prend par une personne dont l'équipe fait confiance au jugement.

Dans beaucoup d'équipes, cette décision appartient à un responsable d'ingénierie, non à un testeur. Là où c'est le cas, la protéger protège le métier de quelqu'un d'autre.

Tester des systèmes avec un modèle dedans

La plupart des nouveaux produits ont un modèle dans la boucle et ne peuvent pas être testés en affirmant une sortie fixe. La conception d'évaluations, le prompt adversarial et la régression comportementale forment une discipline nouvelle avec peu de praticiens, et l'état d'esprit qualité — supposer que c'est cassé, découvrir comment — se transfère directement.

Peu de praticiens est un énoncé sur le présent. La discipline est assez jeune pour que sa taille finale soit inconnue, et elle pourrait finir à l'intérieur des équipes modèle plutôt qu'en qualité.