test article mkd #2
Description
0. QA
Plusieurs roles entrent en jeu dans l'élaboration d'un projet de developement. QA pour "quality assurance". Donner une "Assurance qualité" signifie controler à chaque étape du developement le respect et l'exactitude des spécifications prévues dans le cahier des charges et leur fonctionnement optimal final.
I. Ecriture user story en amont
Intégrer et décrire l'expérience utilisateur lors du démarrage du projet permet de donner un périmètre aux tests de QA qui vont être réalisés en paralelle du developement. Une décompostion simple d'action du type qui/quoi/quand/resultat qui servent de cadre à la cohérence des fonctionnalités attendues pour accomplir ces actions.
II. Fonctionnalités et spécifications décomposées en détail dans spreadsheet
Le détail des fonctionnalités est reporté dans des feuilles de calcul. Le format tableur permet de garder une trace logique des évolutions des spécifications en fonction des versions et des changements apportés en cours de developement. Ce format permet également de créer des scenarios de walkthrough (voir chapitre III alinéa b.)
III. Contrôle code fini:
Grace à la décomposition des éléments fonctionnels effectuée dans les feuilles de calcul chaque livraison de code stabilisé peut etre contrôlé en suivant les étapes suivantes:
a. Parcours d'une fonctionnalité élément par élément
Chaque fonctionnalité est testé individuellement indépendament du fonctionnement du reste du programme.
b. Scenarios de walkthrough d'usage type
Les fonctionnalités sont ensuite intégrées à une démarche type pensée pour être suivie par l'utilisateur final dans un usage logique de l'application. Ces scenarios s'approche des user story designées en amont mais détaillent quant à eux toutes les étapes et actions suivies juqu'au résultat attendu.
c. Stress test
La fonctionnalité est poussé à réagir dans des conditions d'usage intensif et répété pour établir sa stabilité. Ce test peut être réalisé manuellement par un testeur ou automatiquement dans le cadre d'un script de maintenance (voir aussi alinéa e. "automatisation")
d. Tests exploratoires
Un ensemble défini de plusieurs fonctionnalités sont sollicités sans qu'une cohérence précise dans leur utilisation les unes vis à vis des autres ne soit considérée. Souvent réalisés à la main par un testeur. Ce sont les tests considérés comme les plus qualitatifs car ils permettent de découvrir des dysfonctionnements innatendus et de parer à des bugs parfois critique. Demande au testeur une connaissance poussée du logiciel pour réaliser une utilisation contre-intuitive des fonctionnalités.
e. Test de régression et automatisation
Les contenus qui ne sont plus sujet à subir de modification dans un avenir proche peuvent être controlés par un "script", une routine de tests qui appliqueront une série d'instructions à accomplir et de données à traiter sans intervention humaine. ces scripts participent à la maintenance du projet pour s'assurer que des fonctionalités qui n'ont pas subi de modifications directes ne soient pas impactées par les changements effectués dans d'autres parties du projet. La vitesse d'execution et la répétition programmée de ces scripts peuvent servir également à "stess tester" un scénario de type walkthrough ou exploratoire.
IV. Retours vers équipe de développement.
a. Ecrire un rapport de bug
Rédiger description concise du bug recontré, lister les étapes de reproduction des bugs. Ce rapport peut être intégrer à des cartes à assigner dans un tableau de bord pour que l'équipe de développement puisse s'en saisir.
b. Tenir à jour un journal d'activité
Documenter les tests réalisés et les mises à jours effectuées dans un journal en plus des cartes de rapport peut s'avérer précieux pour avoir une vue rapide de l'état de l'app
