Poste
Tests et QA
Que laissez-vous tomber en premier quand une mise en production arrive plus vite que les tests ? En général la régression - et c'est en général là que se loge le bug qui revient en signalement d'utilisateur.
Entretien préalable
Quatre questions par lesquelles nous commencerions
Que laissez-vous tomber en premier quand une date de mise en production est serrée ?
La réponse décrit où naît la dette de qualité dans votre processus.
Comment savez-vous que la zone modifiée dans cette mise en production a été testée ?
Si c'est parce que le testeur le pense, la couverture est une conviction plutôt qu'un fait.
Combien de fois le même bug revient-il après un correctif ?
Si cela arrive régulièrement, ce qui manque est un test qui l'arrêterait - pas l'attention d'un développeur.
Que ne faites-vous pas, bien que vous sachiez qu'il le faudrait ?
En général : vous ne testez pas les cas limites et les scénarios rares. Toujours faute de temps, jamais faute de conscience.
Nous prenons la préparation et la répétition, vous gardez la conception des tests
Préparer les jeux de données de test, lancer la régression, rendre compte des résultats et entretenir la documentation de test peuvent être retirés du bureau. Ce qui doit être testé et pourquoi, c'est le testeur qui le conçoit.
- La régression ne concurrence pas les nouveaux tests. - Si les scénarios répétables se lancent d'eux-mêmes, le temps du testeur va à ce que personne n'a vérifié auparavant.
- Les données de test ne bloquent pas le départ. - Préparer un jeu de données pour un scénario cesse d'être une demi-journée avant chaque campagne de tests.
- La couverture est un fait, pas une impression. - On voit quelles zones modifiées dans une mise en production ont des tests et lesquelles n'en ont pas - et c'est la base d'une décision de livraison.
Périmètre
Ce qui peut être retiré d'un testeur
Dix-neuf tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à votre processus de développement.
Conception des tests
- Un projet de cas de test issu d'une exigence (appréciation : le testeur)
- Signalement des cas limites à considérer
- Liaison d'un cas à une exigence et à une zone du système
- Un signal quand une exigence n'a pas de test affecté
Données de test
- Génération de jeux de données pour un scénario
- Des données couvrant différents états et configurations
- Restauration de l'état de l'environnement avant une campagne de tests
- Anonymisation des données issues de la production
Exécution et compte rendu
- Lancement des scénarios répétables sans le testeur
- Consignation du résultat avec les étapes de reproduction
- Un projet de rapport de bug avec le contexte (contenu : le testeur)
- Un récapitulatif des résultats d'une campagne de tests
Tests de régression
- Signalement des zones couvertes par une modification de la mise en production
- Un jeu de régression ajusté au périmètre de la modification (décision : le testeur)
- Un signal sur une zone modifiée et non couverte par un test
- Comparaison du résultat à la campagne précédente
Qualité après la mise en production
- Liaison des signalements d'utilisateurs aux zones du système
- Signalement des bugs qu'un test existant aurait dû attraper
- Les bugs récapitulés par zone et par cause
Une journée de travail
Aujourd'hui
- Vous préparez les données de test à la main avant chaque campagne
- Vous lancez la régression en cliquant à travers les mêmes scénarios
- Sous une échéance serrée, vous testez ce que vous pouvez
- Vous ne savez pas si la zone modifiée dans la mise en production a des tests
- Vous écrivez un rapport de bug depuis zéro, avec les étapes
- Après la mise en production, vous ne savez pas quel bug aurait pu être attrapé plus tôt
Avec l'assistance de l'IA
- Un jeu de données pour un scénario se produit sans une demi-journée de préparation
- Les scénarios répétables se lancent d'eux-mêmes
- Le temps va aux cas que personne n'a vérifiés auparavant
- Une zone modifiée et non couverte par un test est signalée
- Un rapport de bug a un projet avec les étapes de reproduction
- Les bugs d'après la mise en production sont liés aux trous dans les tests
- Couverture de test
on voit ce qui est vérifié et ce qui en a seulement l'air
les cas sont liés aux exigences et aux zones
- Durée de la régression
la régression tient avant la mise en production plutôt qu'après
les scénarios répétables se lancent d'eux-mêmes
- Bugs trouvés après la mise en production
moins de sujets qui atteignent les utilisateurs
le temps du testeur va à de nouveaux cas
- Des tests reproductibles
le même test donne le même résultat qui que ce soit qui le lance
les données et l'état de l'environnement se reproduisent
Nous commençons par les données de test, parce que c'est ce qui retarde le plus souvent le départ des tests.
- Étape 1
Données et environnement reproductible
Des jeux de données pour les scénarios et un état de départ répétable.
- Étape 2
Scénarios répétables
Le lancement de la régression sans le testeur à chaque passage.
- Étape 3
La couverture au regard des modifications
Signalement des zones modifiées et non couvertes par un test.
- Étape 4
La qualité après la mise en production
Liaison des signalements aux zones et aux trous dans les tests. En dernier, parce que cela exige des données de production.
Questions fréquentes
Les questions qui reviennent à la première réunion
Cela n'abaissera-t-il pas la place du testeur dans l'équipe ?
En général l'inverse, parce que le testeur cesse d'être la personne qui clique à travers la régression et devient celle qui conçoit ce qu'il vaut seulement la peine de vérifier. C'est la part la plus difficile de ce travail et la plus visible pour l'équipe.
Des testeurs seront-ils encore nécessaires ?
Des tests générés ne trouvent pas ce qui compte - et nous le disons ouvertement quelques paragraphes plus bas. Un testeur est nécessaire pour concevoir ce qu'il vaut seulement la peine de vérifier, et c'est la part la plus difficile de ce travail, plus que de cliquer à travers la régression. Quand la régression se lance d'elle-même, il reste du temps pour cela. Les équipes qui passent par là finissent en général avec un QA plus fort, pas plus petit.
Cela relève-t-il du règlement sur l'IA ?
Tester un logiciel n'est pas un usage à haut risque. Le seul point demandant de la prudence est l'usage de données de production comme données de test - les règles de protection des données s'y appliquent et l'anonymisation fait partie du périmètre plutôt que d'être une option.
Une question qui ne figure pas ici ? Réservez un appel
Étape suivante
Combien de temps la dernière mise en production a-t-elle coûté en préparation de données de test ?
Nous vous montrerons à quoi ressemblent les tests quand la régression ne concurrence pas les nouveaux cas et que la couverture se voit avant la décision de livraison.