Les 7 principes du test: tester tôt (3/7)

Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test.

Tester tôt

Description

Ce principe est assez simple à appréhender. Il rappelle qu’il est important/ nécessaire de tester aussi tôt que possible afin d’éviter que des problèmes mineurs et faciles à corriger au moment où ils ont été introduits deviennent des problèmes majeurs et particulièrement complexe (voire impossible) à corriger à mesure.

Cette croissance de la complexité s’explique par plusieurs points, les plus évidents me semblent être ceux-ci:

  • Il est plus facile de corriger quelque chose lorsque l’on est dans le sujet que lorsque l’on ne travaille plus dessus
  • Le logiciel et l’environnement dans le logiciel évoluent et deviennent plus complexe au fur et à mesure que le temps passe
  • La cause de l’anomalie devient plus complexe à trouver car plus le temps passe plus il y a eu des modifications
  • Dans le cas du développement d’un logiciel il est plus facile de corriger une anomalie introduite dans l’expression de besoin ou les spécifications à ce moment là (correction d’une phrase) qu’ultérieurement.

Conséquences

La conséquence principale est simple et s’appelle « shift left« . Les tests doivent intervenir aussi tôt que possible! Il y a d’ailleurs de nombreuses techniques implémentant ce concept, je pense par exemple aux revues, à l’ATDD ou au BDD!

Ce qu’il faut retenir

il est bon de tester toute production faite pour un logiciel. Par tester on peut entendre ici « vérifier » et par production tout ce qui est lié au logiciel développé ce qui inclut: les US, les expressions de besoins, les spécifications, le code, les tests, les plan de test et j’en passe.

Repérer une anomalie dès qu’elle est introduite permet de gagner du temps, de l’argent… mais aussi de travailler dans de bonnes conditions où l’on ne passe pas son temps à corriger des anomalies.

De même, « tester tôt » a une autre vertu: cela entraîne une collaboration et une forte communication!

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Agilité

Le manifeste « Fragile »

Le manifeste Agile est un outil simple, visuel et particulièrement puissant. Son objectif est pour moi assez similaire à celui des 7 principes du test: faire comprendre l’état d’esprit à adopter. Pour rappel le manifeste Agile c’est: D’ailleurs, je considère personnellement que le manifeste Agile est un peu comme les

Lire la suite »
Automatisation

Tests autos vs tests manuels

L’automatisation, le nouvel Eldorado ! Il faut automatiser tous les tests et une fois que ça sera fait, exécuter les cas de tests sera gratuit et parfaitement fiable, tout sera merveilleux ! Vraiment ? Dire cela montre juste un manque de connaissance du métier du test. Les tests ce n’est pas que l’exécution.

Lire la suite »
Agilité

13 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (1 / 3) 

Prenons le cas d’une fonctionnalité “F” du produit et essayons de concevoir des scénarios de test qui pourraient représenter leurs critères d’acceptation. En termes clairs “F” représente un macro-UC ou un UC (Use Case) du produit à un instant T de sa conception. Autrement dit, “F” intègre et synthétise tous

Lire la suite »