Tests

Dans tout projet, les tests occupent une place très particulière. Ils assurent le lien entre le monde des utilisateurs et le monde du développement. Nous avons vu dans un précédent article que la démarche de développement pilotée par les tests n'est pas incompatible avec les tests de recettes traditionnels. Un projet bénéfice peut tirer bénéfice de l'utilisation conjointe des deux approches. Il faut alors intégrer deux types d'outils. Nous allons voir aujourd'hui comment inclure les résultats de tests GreenPepper dans Test Director afin de présenter une vision homogène de l'ensemble des tests à notre client.

Dans un précédent post, j'avais déjà évoqué l'insuffisance de l'indicateur "couverture de test" à lui seul pour garantir la détection de régressions. Pour résumer, un autre indicateur permettant de répondre aux questions "mes tests me protègent-ils contre d'éventuelles régressions?" ou formuler autrement "Quel est le niveau de confiance que j'ai dans mes tests?" doit être trouvé.

Deux idées existent. La méthode plus simple consiste à compter le nombre d'assertions réalisées: efficace et simple à mettre en oeuvre puisque cette solution repose sur un simple grep (comme si grep était simple...).
L'autre méthode repose sur le principe suivant:

Le code de test "valide" le code métier. le code métier peut valider le code de test...

Alors concrètement comment faire?! comment l'implémenter? Comme j'avais envie de coder, voilà "l'histoire" d'un POC visant à valider les principes précédemment énoncés.

Dans tout projet, les tests occupent une place très particulière. Leur vocation première est de s'assurer que le logiciel répond au besoin. Ils assurent ainsi le lien entre le monde des utilisateurs et le monde du développement. Les tests se retrouvent de manière très formelle - quasi juridique - dans le process de validation (le "PV de recette"). Ce rôle de point d'orgue du projet (sa conclusion) occulte très souvent la place réelle des tests, on oublie qu'ils ont participé très en amont à l'élaboration du livrable : derrière un PV de recette dûment signé, combien de bugs ont dû être préalablement corrigés, combien de chapitres a-t-il fallu revoir dans les spécifications ? Ces ajustements n'ont pas été produits ex nihilo, ils sont le résultat de la constatation d'une anomalie, d'un test en fait. S'ils ne sont pas formalisés, on les retrouve indirectement dans les écrits du projet : soit sous forme de complément de spécifications, soit aussi sous forme de correction de bug.

Lorsque le test n'est plus formalisé " sous le manteau " mais fait l'objet d'une démarche systématisée, on parle de démarche pilotée par les tests.

Trop souvent cette démarche est opposée à l'approche classique, et ce de façon manichéenne. Nous allons voir au contraire que les deux démarches sont complémentaires et que les outils correspondants peuvent être facilement intégrés.

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J'en entends déjà pester "encore un truc de geek"...Le pilotage par les tests se résume à ces deux points clés:

• remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l'ambiguïté du langage courant par des spécifications exécutables c'est à dire vérifiables concrètement et fournissant une réponse sans appel: "vert" ou "rouge".

• Piloter non pas sur un "reste à faire" - concept obscur car que met on dans le "reste à faire"? - mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d'avoir un outil permettant aux "fonctionnels" d'écrire simplement - c'est à dire dans leur vocabulaire - les spécifications exécutables et permettant aux "managers" de piloter les développements.