Les tests de bout en bout et bouchonnés sont en soi deux concepts antagonistes, vue que les tests réalisés le sont sur des environnements organisés différemment. L’un possède toutes les briques du SI, l’autre en remplace certaines par des injecteurs ou des bouchons. Néanmoins dans le cadre d’une stratégie de test, ils sont souvent complémentaires.

On voit de plus en plus des entreprises qui sous couvert de shift left, font disparaitre les tests bout en bout au profit de test de plus bas niveau. Certaines organisations agiles font des tests bouchonnés au niveau des users stories, mais considèrent que le test bout en bout n’a pas sa place dans l’agilité. D’un autre côté, certains, plus rares, ne font que des tests bout en bout.

Pourquoi certains ne font que des tests bouchonnés et d’autres que des tests bout en bout. Qui a raison ?

Les tests bouchonnés

Les tests bouchonnés sont plus faciles à organiser et à réaliser. Hormis la création des injecteurs et bouchons, on a besoin que d’une seule brique applicative, une seule « équipe ». L’organisation et les processus sont donc plus simple.

Il est aussi plus simple de diagnostiquer une anomalie, vu qu’il y a moins de composants incriminés.

Les tests bout en bout

Les tests bout en bout sont plus proche du réel. On peut même aller jusqu’à dire que c’est les seuls tests qui ont une vraie valeur, puisque jouer sur un environnement avec l’ensemble des composants comme pour la production (mais pas forcément la volumétrie). Et c’est sûrement la raison pour laquelle certaines entreprises ne font que ce niveau de test.

Certaines anomalies qui sont à « la liaison » entre deux applications ne pourront être constatées qu’à ce moment-là. Et de manière générale la bonne intégration fonctionnelle de deux applications nécessite un environnement bout en bout, ou au minimum deux à deux, dans tous les cas non bouchonné.

Comparatifs

Plus simple d’un côté, plus réel de l’autre, sont-ils vraiment comparables ?

On a notamment parlé d’anomalies, et même si ce n’est qu’une vision du sujet, elle est néanmoins caractéristique de l’ensemble. Certaines anomalies ne peuvent être découvertes que lors des tests bout en bout, qui semblent donc indispensables. Par contre cet environnement coûte cher à monter et à maintenir, et les tests qui y sont joués nécessitent une organisation qui est plus complexe. Il semble donc aussi indispensable de faire des tests bouchonnés pour gagner en efficience.

La stratégie de test est là pour répondre à cette question. Sachant que les tests bout en bout sont indispensables mais cher et complexe, quels sont les autres niveaux qui doivent venir les compléter pour gagner en efficience ?

Et effectivement si le coût des tests bout en bout ne vient pas contrebalancer le risque d’anomalies transverses, est-ce intéressant d’en faire ?

Le shift left ne veut donc pas dire qu’on fait disparaitre le côté droit, mais qu’on vient le « diffuser » à l’image de ce que l’on vient de dire précédemment. L’agilité est « centrée » sur elle-même mais cela ne veut pas dire qu’elle doit oublier tout l’écosystème. L’agilité à l’échelle répond de plus en plus à cette question, en commençant à aborder les tests bout en bout.

Toujours pas de gagnant dans ce combat, enfin si on pourrait dire que les deux ont gagnés pour une fois.