Essai

Eh bien, vous ne voulez pas de bugs évidents. Passer rapidement ne signifie pas que nous devons libérer des choses qui cassent l'application ou qui ont un aspect déplorable.

Tester quelque chose avant sa sortie est une bonne idée. Le test, comme tout le reste, est un grand sujet et il existe différentes écoles pour le faire. Nous ne parlons évidemment pas d'une « phase de test » à la manière des anciens gestionnaires de projets.

Attendre de tester tout au bout d'un projet peut sembler comique aujourd'hui, mais c'était une pratique courante et elle l'est encore dans de nombreux projets en mode Waterfall. Heureusement, la plupart ont évolué. Attendre avec le test et les développeurs sont passés et ont oublié, et c'est presque un nouveau projet pour corriger toutes les petites choses.

Aujourd'hui, les entreprises utilisent des tests continus qui doivent se dérouler dans un environnement de test avant que le ticket/histoire/fixe aille en production (se libère).

De cette façon, nous pouvons coder des fonctionnalités, les tester, donner des retours, coder à nouveau et continuer de tester jusqu'à ce que nous soyons satisfaits du résultat. Nous pouvons libérer quand cela est prêt sur une base fonctionnalité par fonctionnalité.

Dans de nombreux processus de développement, le développeur code quelque chose, puis teste un peu sur son ordinateur local, puis commite le code et fait une Pull Request pour revue par les pairs (dans le meilleur des cas). Ensuite, c'est sur l'environnement de test.

Ici, certains développeurs aiment passer la main à une équipe QA (« Assurance qualité ») qui prend en charge la responsabilité des tests et « s'assure » que cela a « la bonne qualité ». Cela semble bien sur le papier. Ne le faites pas ! Au moins, pas comme cela.

Lisez plus dans «Le Playbook du PDG» disponible sur Amazon/Kindle.