Autrement dit, vous venez de lancer une application mobile mais vous n’avez aucune idée si l’application va marcher ou non. Il est d’ailleurs possible de réaliser plusieurs versions de cette application avant de trouver votre cible.
Selon vous :
devez-vous intégrer dès maintenant des tests dans votre application,
ou ne devez-vous pas plutôt vous concentrer sur les fonctionnalités de cette dernière ?
Découvrez le cycle de développement logiciel
Cette question peut clairement faire débat. En effet, les développeurs ont souvent envie de bien faire leur travail, moi le premier. Ils aiment les bases de code propres et les tests automatisés. Cela dit, écrire des tests et du “beau code” va souvent dépendre de la phase dans laquelle se trouve votre produit.
Le POC (ou Proof of Concept)
Cette phase correspond au début de la création d’un projet. Votre projet peut être un site web ou une application mobile. À ce moment-là, il n’y a que très peu de développeurs travaillant sur le projet.
L’idée, ici, est de valider un concept. On va souvent faire plusieurs versions de l’application avant d’en avoir une qui fonctionne et qui trouve sa cible. Dans cette phase, on va écrire du code qu’on n’aura aucune honte à supprimer si le concept ne marche pas. Il y a donc très souvent peu, voire aucun test.
Cela pourrait correspondre aux premières phases de notre projet fil rouge. Ce projet aurait été développé en interne par une grande entreprise du bâtiment, et on voudrait tester l’idée et le concept de façades connectées. Ces premiers mois d’utilisation permettent de se faire une meilleure idée de la manière dont le projet va se comporter dans le temps.
La croissance
Dans cette phase, le produit a trouvé son public et commence à faire parler de lui. La croissance est exceptionnelle et le nombre d’utilisateurs, de votre application par exemple, bat des records de jour en jour.
C’est souvent à partir de ce moment que vous allez devoir intégrer vos premiers tests. C’est une période assez complexe dans la vie d’une entreprise : beaucoup d’entreprises, notamment des startups, peuvent se prendre les pieds dans le tapis à ce moment-là. Vous allez devoir alterner entre sortir de nouvelles fonctionnalités et structurer l’architecture de votre projet.
Notre projet fil rouge a recueilli un très bon accueil en interne, et est maintenant utilisé par de nombreux techniciens. Les technologies embarquées sur les capteurs sont stables, et les données remontées sont cohérentes. On va maintenant chercher à rendre l’application stable.
Vers la maturité et au-delà
Enfin, dernière phase du cycle de vie : la maturité. À ce moment-là, votre projet marche maintenant bien et a trouvé son rythme de croisière. Les fonctionnalités qui vont sortir vont être de plus en plus complexes, et le besoin de refactoriser du code va se faire de plus en plus sentir.
C’est l’heure maintenant de faire des tests plus complexes, et peut-être même de recruter une équipe dédiée à ça : les QA, ou Quality Assurance (assurance qualité, en français).
Par exemple, le projet est maintenant utilisé par plusieurs milliers de personnes, et il commence à être vendu à d’autres entreprises du bâtiment. Un haut niveau de qualité est devenu critique, et il faut donc développer de nouveaux tests automatisés et une architecture robuste dans ce sens.
Identifiez le test à adopter
En développement logiciel, il existe de très nombreux tests possibles. Vous pouvez réaliser des tests unitaires, des tests fonctionnels ou d’intégration, des tests End-To-End (ou E2E), des Smoke Tests, des Snapshot Tests, etc.
Certains sont plus complexes à mettre en place que d’autres, et leur implémentation va dépendre de la phase du cycle de vie dans laquelle se trouve votre produit, ainsi que des technologies utilisées.
Qu’est-ce qui peut changer en fonction des technologies utilisées ?
Pas mal de choses. :)
Par exemple, dans l’écosystème React, on utilise beaucoup les tests de snapshots (je vous en parlerai dans la dernière partie du cours), alors qu’on en utilise assez peu sur des projets back-end.
Voici les tests les plus courants :
Les tests unitaires – ce sont souvent les premiers à être implémentés dans une base de code. On les ajoute à partir du moment où le produit a trouvé sa cible. Ils sont généralement “assez faciles” à réaliser.
Les tests fonctionnels ou d’intégration – on les ajoute souvent soit en même temps que les tests unitaires, soit après. Ils vont être un peu plus complexes à réaliser.
Les tests E2E ou End 2 End – ce sont des tests assez complexes, qui seront souvent réservés à la phase de maturité du projet.
Dans ce cours, vous allez découvrir comment réaliser des tests unitaires et fonctionnels. Cela dit, la dernière partie vous permettra de vous focaliser sur les autres types de tests, et vous aidera à savoir comment les mettre en place. :)
Définissez votre stratégie de test
Mais pourquoi on a besoin de définir une stratégie de tests ? On ne peut pas juste les écrire ?
Je comprends votre remarque mais posez-vous une question : quand vous développez une application, est-il plus simple et plus rapide de développer quand :
On vous a déjà fourni des maquettes à intégrer et que vous n’avez donc pas à déterminer quel est le design ?
On vous a aussi déjà fourni les fonctionnalités (sous la forme de user stories) ?
La programmation, c’est quelque chose de complexe où on passe son temps à se poser des questions. Pour moi, la règle d’or est de se poser le maximum de questions en amont, que ce soit avec les autres développeurs ou avec l’équipe Produit. Comme ça, une fois que vous serez devant votre code, vous pourrez vous focaliser sur l’essentiel : le code.
Nous allons donc voir deux documents : le plan de test et la stratégie de test.
Découvrez la stratégie de test
La stratégie de test est une ligne directrice à suivre pour atteindre l’objectif de test et l’implémentation des différents types de tests mentionnés dans le plan de test. Ce document est généralement réalisé par le Product Manager (ou chef de projet, en français). On y traite de l’objectif du test, de l’environnement dans lequel ce dernier est réalisé, de l’approche, et des outils qui vont être utilisés.
C’est un document “statique” ; autrement dit, il ne va pas changer durant le cycle de vie du projet. C’est un document qui va guider l’équipe, notamment dans la rédaction des plans de test.
Il est important d’y parler des éléments suivants :
La portée des tests : l’idée ici est de savoir ce qu’il faut tester, et pourquoi il faut le tester.
L’approche des tests : vous allez parler des types de test (unitaire, intégration, etc.), des responsabilités des différents membres de l’équipe, etc.
Les outils de test : par exemple Jest pour les tests unitaires JavaScript, et NightWatch pour les tests end to end.
OK… Très bien. Mais du coup, il a quelle tête, ce document ?
Hé hé hé, je me doutais que vous alliez vous poser la question.
Bien, maintenant que vous êtes calé concernant la stratégie de test, nous pouvons nous intéresser au plan de test !
Écrivez un plan de test
À la différence d’une stratégie de test, un plan de test est un document dynamique ; autrement dit, c’est un document qui va être régulièrement mis à jour. L’objectif est de décrire ce qu’il faut et ce qu’il ne faut pas tester, comment et quand tester, et enfin qui fera le test. C’est généralement un document qui est écrit par un QA Engineer.
Un exemple ici à nous partager ?
Enfin, pour finir, vous allez pouvoir vous aider d’un modèle de cas de test pour réaliser vos tests. Eh oui, ça fait pas mal de documents différents !
En résumé
Un produit passe par différentes phases au cours de sa vie : l’idée, le développement, le lancement, la croissance, la maturité et le déclin.
Les tests à intégrer dépendent du cycle de vie du projet. Plus celui-ci est avancé, autrement dit plus il approche de la maturité, plus il va y avoir de tests automatisés dessus.
On peut intégrer un grand nombre de tests à un produit : tests unitaires, fonctionnels ou d’intégration, E2E, SmokeTest, etc.
Le plan de test est une vision de ce que vous voulez réaliser comme tests, alors que la stratégie de test correspond à un plan d’action conçu pour réaliser cette vision.
Maintenant que vous avez vu les phases composant un projet, et les différents types de tests, nous allons rentrer directement dans le vif du sujet avec les tests unitaires ! Mais avant tout, testez vos compétences dans le quiz qui suit.
