Voir la source de Utilisation des Quadrants de Tests Agile

[[Category: Portail Equipe de développement]]
[[Category: Portail Product Owner]]
[[Category: Tests]]
[[Category: Lisa Crispin]]
[[Category: Brian Marick]]
Auteure : Lisa Crispin<br />
Source : [https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants Using the Agile Testing Quadrants]<br/>
Date : 08/11/2011<br/>
----
Traducteur : Fabrice Aimetti<br />
Date : 07/07/2019<br />
----
Traduction :<br />
<br />
Quelqu'un sur la liste de diffusion agile-testing du Yahoo Group a posté un lien vers un billet de blog dans lequel il utilisait de la mauvaise manière, estropiait les Quadrants de Tests Agile. Il n'y a aucun moyen de faire des commentaires sur ce billet de blog pour essayer de réfuter son affirmation selon laquelle les quadrants sont en quelque sorte un processus waterfall. Étant donné que d'autres personnes pourraient mal comprendre le but des quadrants, j'aimerais vous donner une brève explication ici.<br/>
<br/>
[[Fichier:Agile-Testing-Quadrants fr.png|left]]Vous voudrez peut-être commencer par les [http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2 posts originaux de Brian Marick] sur sa matrice de test agile, que nous avons appelée les Quadrants et dont nous avons fait (avec sa permission) le coeur de notre livre [https://agiletester.ca/ Agile Testing].<br/>
<br/>
La plupart des projets commenceraient par des tests Q2, parce que c'est là que l'on trouve des exemples qui se transforment en spécifications et en tests qui pilotent le codage, ainsi que des prototypes et autres. Cependant, j'ai travaillé sur des projets où nous avons commencé par des tests de performance (qui sont au Q4) sur un spike de l'architecture, parce que c'était le critère le plus important pour cette fonctionnalité. Si vos clients ne sont pas certains de leurs besoins, vous pouvez même faire un spike et commencer par des tests exploratoires (Q3).<br/>
<br/>
Les tests Q3 et Q4 exigent qu'une partie du code soit écrite et déployable, mais la plupart des équipes itèrent rapidement dans les quadrants, travaillant par petits incréments. Ecrire un test pour un petit morceau d'une fonctionnalité, écrire le code, une fois le test réussi, peut-être automatiser d'autres tests, mener des tests exploratoires, mener des tests de sécurité ou de charge, peu importe, puis ajouter le petit morceau suivant de fonctionnalité et recommencer l'ensemble du processus.<br/>
<br/>
Les quadrants ne sont qu'une taxonomie pour aider les équipes à planifier leurs tests et à s'assurer qu'elles disposent de toutes les ressources nécessaires pour y parvenir. Il n'y a pas de règles strictes et rapides sur ce qui se passe dans chaque quadrant. Pensez-y au fur et à mesure que vous planifiez votre version, votre thème et votre itération, de sorte que toute votre équipe commence par penser aux tests en premier.<br/>
<br/>
Michael Huetterman ajoute "De l'extérieur vers l'intérieur, facile d'accès, collaboratif" au milieu des quadrants, voir son article [http://huettermann.net/perform/AgileALM-AgileRecord-Huettermann.pdf Agile Record] ou son excellent livre [http://huettermann.net/alm/ Agile ALM].<br/>
<br/>
Visitez ma page [https://lisacrispin.com/presentations/ Présentations] pour quelques diapositives qui contiennent plus d'informations sur les quadrants, ou consultez notre livre. Je suis toujours heureuse de parler des quadrants, envoyez-moi un email !