Le bug informatique qui a coûté le plus cher de l’histoire est celui qui a impacté le vol 501 d’Ariane 5 en 1996. À cause de ce bug, la célèbre fusée a volé 36,5 secondes avant d’exploser en plein vol. La raison de cet échec à 370 millions de dollars ? Un copier-coller afin de dupliquer les données volumétriques d’Ariane 4… qui était bien plus légère qu’Ariane 5 !
Si des tests avaient été faits, la défaillance aurait sûrement été détectée. Nous pouvons sûrement dire qu’à cause ou grâce à cela, les tests ont pris une part plus importante dans le cycle d’un produit !
Une fois que vous avez défini les objectifs de votre projet, vous allez identifier ce qui doit être automatisé pour que cette histoire ne vous arrive pas, à votre échelle. Comment ? Grâce à des critères de détermination afin d’évaluer ce qui est à risque dans votre projet. Cela permettra alors d’identifier vos besoins en données.
Comprenez les critères de détermination
Il faut déjà comprendre ce qui peut être automatisé, car tout n’est pas automatisable.
Les critères de détermination peuvent être :
La fréquence d’utilisation | Exécutez-vous souvent ce test ? Si vous n’exécutez ce test qu’une fois ou deux, ce n’est pas la peine de l’automatiser car il vous coûtera plus de temps et d’argent. Prenons un exemple, la page de login. Est-ce que vous allez vous connecter souvent ? Oui, sans le moindre doute ! Il faut donc automatiser ce cas de test. |
L’évolution de la fonctionnalité | Est-ce que cette fonctionnalité change souvent ? Si la fonctionnalité évolue régulièrement au point de devoir changer entièrement les tests, c’est qu’il ne faut pas encore automatiser les tests sur cette partie. Reprenons l’exemple de la page de login, cette fonctionnalité n’a pas lieu de changer souvent. Une fois implémentée, il n’y a rien à ajouter à part la maintenir selon les vulnérabilités, mais l’interface ne changera pas. Vous pouvez donc automatiser ce test. |
La complexité à automatiser | Est-ce que le test manuel est compliqué à automatiser ? Il peut être complexe s’il y a des dépendances externes : par exemple s’il y a une API ou une infrastructure externe et qu’il n’y a pas les compétences au sein de l’équipe pour les gérer. Mais inversement, le test manuel peut être difficile à effectuer de manière précise et cohérente. Dans ce cas, l’automatisation permet d'exécuter ces tests de manière fiable en réduisant les risques d’erreur humaine. Pour continuer avec l’exemple de la page de login, celle-ci ne doit pas être complexe à tester. Il suffit dans la plupart des cas d’avoir des utilisateurs en base de données. Dans certains cas, il va falloir tester la double authentification, mais ce n’est pas complexe en Cypress. Vous pouvez donc automatiser ce test. |
La compatibilité avec des outils | Est-ce que vous avez les outils nécessaires au sein de l’équipe ou de l’entreprise ? Cela inclut des frameworks d'automatisation, des logiciels de gestion de tests, des outils de rapport, etc. Si ces outils sont déjà en place, cela peut faciliter la décision d'automatiser, car vous n'avez pas besoin d'investir davantage dans de nouveaux outils. Langage de programmation : Si vous travaillez principalement avec un langage de programmation particulier, assurez-vous que le framework d'automatisation que vous envisagez d'utiliser prend en charge ce langage. Environnements cibles : Vérifiez si les outils d'automatisation peuvent fonctionner sur les environnements cibles, tels que les navigateurs web, les appareils mobiles, les systèmes d'exploitation, etc., que vous ciblez pour vos tests. Intégration avec les outils existants : Assurez-vous que les outils d'automatisation peuvent être intégrés de manière transparente avec d'autres outils que vous utilisez, tels que des systèmes de gestion de versions, des systèmes de gestion de projets, etc. |
La maturité du processus de test | Définition des processus : il faut avoir des processus de test bien définis et documentés avant de commencer l’automatisation de tests. Gestion des cas de test : il faut avoir des cas de test manuels déjà bien organisés et maintenus à jour pour pouvoir les automatiser de manière efficace. Infrastructure de test : il faut avoir une infrastructure de tests robuste. Si elle ne l’est pas, il faut prévoir les ajustements. Compétences de l’équipe de test : il faut des compétences techniques spécifiques comme la maîtrise de JavaScript ou de TypeScript afin de coder les scénarios de tests. Suivi des résultats de tests : il faut des capacités pour analyser et interpréter les résultats des tests automatisés afin d’en tirer les bonnes conclusions. Il est important d’avoir en place des mécanismes de suivi et de rapport pour permettre une évaluation précise de la qualité du site internet testé. |
Les ressources disponibles | Avez-vous les ressources disponibles dans l’équipe afin de réaliser l’automatisation ? |
Les risques et la criticité | Avez-vous des fonctionnalités critiques ou qui présentent des risques critiques ? Si vous en avez, ce sont toujours de bons candidats pour l’automatisation. Par exemple, si c’est un site de e-commerce, vos fonctionnalités critiques sont, entre autres, le panier, l’achat et la connexion des utilisateurs. Si l’une de ces fonctionnalités ne fonctionne pas, vous allez passer à côté d’opportunités de vente et votre image sera impactée. |
Le coût | Prenez en compte le coût d'acquisition et de maintenance des outils d'automatisation, y compris les licences, la formation, le support technique, etc. |
Évaluez ce qui est risqué ou critique
Qu’est-ce qu’un risque?
Un risque dans le contexte du test signifie une menace potentielle pour la qualité du site internet testé. Cela peut être une erreur, un dysfonctionnement ou un problème qui pourrait avoir un impact négatif sur le bon fonctionnement de l'application testée. Les risques peuvent être liés à des facteurs tels que des fonctionnalités complexes, des dépendances externes, des changements fréquents, des ressources limitées, etc.
Le risque est le résultat de la combinaison de la probabilité et de l'impact d'un événement indésirable.
Et alors, qu’est-ce qu’une probabilité et un impact ?
La probabilité, c’est la chance ou la fréquence à laquelle un événement indésirable peut se produire.
L’impact, c’est l’ampleur des conséquences en cas de réalisation du risque. Il peut être lié à l’aspect financier, aux retards dans la livraison, au dépassement du budget, à une diminution de la qualité qui se répercute sur l’image de la société. Par exemple, un panier non disponible dans un site de e-commerce est considéré comme critique car l’impact direct est la perte d’argent.
Lorsque vous évaluez un risque, vous prenez en compte à la fois la probabilité et l'impact pour déterminer la gravité du risque. Plus la probabilité est élevée et plus l'impact est important, plus le risque sera considéré comme critique.
La formule générale pour évaluer le risque est souvent exprimée comme suit :
Risque = Probabilité x Impact
Il s'agit d'une évaluation quantitative qui permet de classer les risques en fonction de leur importance et de prendre des décisions éclairées concernant la gestion des risques et l'allocation des ressources, pour minimiser les risques élevés et prévenir les problèmes potentiels. En utilisant cette approche, on peut hiérarchiser les risques et concentrer les efforts sur les risques les plus critiques lors de la planification et de l'exécution des tests.
Oui, mais comment fait-on pour évaluer la probabilité ?
Pour évaluer la probabilité, il y a plusieurs facteurs ; par exemple :
L’historique. Est-ce qu’il y a des projets ou des fonctionnalités similaires qui peuvent nous aider ou nous fournir des informations sur la réalisation du risque ?
L’expertise. Est-ce qu’il y a des experts dans l’équipe qui peuvent estimer la probabilité en se basant sur toutes leurs connaissances (système, technologies…) ?
La documentation. Lisez la documentation qui concerne le projet : spécifications, exigences, cas d’utilisation, etc., afin d’estimer la probabilité des risques.
La complexité : Plus le système, les fonctionnalités ou les interactions sont complexes, plus il peut y avoir de risques associés.
La rapidité : Les changements fréquents ou itérations rapides dans les développements du site peuvent augmenter la probabilité de certains risques liés à l’instabilité du site, par exemple.
L’identification des risques de test se fait en évaluant les caractéristiques du site, les exigences, les fonctionnalités, les dépendances, les contraintes de temps et les compétences de l’équipe.
Il faudra décider du nombre minimal de tests suffisant pour prendre en compte le niveau de risque, incluant les risques techniques, les risques liés à la sûreté et au projet, ainsi que les contraintes du projet telles que le temps et le budget.
Quid de notre exemple fil rouge, le site Tech&Buy ?
Dans notre exemple, les risques fonctionnels sont peu nombreux :
L’utilisateur que nous cherchons à ajouter ne s’ajoute pas.
La liste des utilisateurs déjà présents ne s’affiche pas.
Par contre, nous devons faire attention au Règlement général sur la protection des données (RGPD), qui peut générer un risque financier pour l’entreprise s’il n’est pas respecté.
De plus, il y a un risque de faille XSS.
Une faille XSS ? Je connais le CSS mais pas le XSS, c’est une faute de frappe dans le cours, sûrement ?
Eh non, ce n’est pas une faute de frappe. Une faille XSS c’est quand une personne, généralement mal intentionnée, essaie d’injecter du code dans un champ texte.
Reprenons notre exemple de formulaire : il contient des champs texte où l’utilisateur peut écrire ce qu’il veut. Or, les champs texte sont liés indirectement à la base de données n’est-ce pas ? Si, si… une fois le formulaire soumis, l’utilisateur va être enregistré où ? Exact, dans la base de données. Si l’utilisateur entre par exemple drop table Utilisateurs; , et que vous ne vous protégez pas, c’est la catastrophe, vous perdez toutes vos données car cette commande permet de supprimer la table existante “Utilisateurs” de manière irréversible ! Vous avez peut-être entendu parler d’injection SQL ? Eh bien, c'est exactement l’exemple que je viens de vous donner.
D’accord ! Maintenant que je sais ce que c’est, comment tester si mon application a une faille de ce type ? Parce que je n’en veux pas !
Nous allons voir cela plus tard dans le cours quand vous aurez installé et exécuté vos premiers tests !
Identifiez vos besoins en données
L’identification des besoins en données est une étape essentielle pour assurer des tests efficaces et complets :
Comprenez les scénarios de tests. Analysez-les, ainsi que les exigences fonctionnelles du site que vous testez. Comprenez quelles fonctionnalités doivent être testées et les différentes conditions auxquelles l'infrastructure sera confrontée.
Déterminez les données d’entrée. Dans notre contexte, il nous faut quelques utilisateurs avec des noms différents et adresses e-mails différentes et avec des caractères spéciaux, par exemple pour tester le formulaire de contact.
Identifiez les données de test pour vérifier que le système fonctionne correctement. Vous pouvez tester avec des données valides ou des données invalides. Dans notre exemple de formulaire de contact, vous pouvez tester les champs avec des e-mails invalides.
Vérifiez la qualité des données. Assurez-vous que les données utilisées sont de bonne qualité : valides, réalistes et représentatives de scénarios réels. N’utilisez pas de données fictives ou aléatoires dans la mesure du possible, sauf si cela est vraiment justifié par des besoins de test bien spécifiques.
Identifiez les données :
De performance/charge : Par exemple, lors des tests de performance d'un site de e-commerce, vous pouvez identifier les données liées à la gestion des utilisateurs simultanés, tels que le nombre de clients connectés en même temps, les paniers d'achat remplis, les commandes effectuées, etc. Ces données aideront à simuler une charge réaliste sur le système pour évaluer comment il réagit sous différentes conditions de charge.
De sécurité : Par exemple, lors des tests de sécurité d'une application web, vous pouvez identifier des données qui simulent des scénarios d'intrusion ou d'attaque, comme des tentatives de piratage de mots de passe, des injections SQL, des failles XSS ou des tentatives d'accès non autorisé à certaines fonctionnalités sensibles. Ces données permettront de vérifier la robustesse de la sécurité de l'application face à de telles tentatives.
Spécifiques à un environnement particulier : Par exemple, si l'application doit fonctionner dans différents environnements, tels que des serveurs de développement, de test ou de production, vous pouvez identifier des données spécifiques à chacun de ces environnements. Cela pourra inclure des adresses IP, des configurations système, des informations de connexion ou d'autres paramètres spécifiques à chaque environnement.
Une fois que vous avez identifié tous les besoins, préparez votre jeu de données. Vous devez être capable de couvrir tous les cas de test pertinents. Ça tombe bien, la préparation du jeu de données, c'est le sujet du prochain chapitre.
En résumé
Les critères de détermination de l’automatisation de vos tests peuvent être : la fréquence d’utilisation, l’évolution de la fonctionnalité, la complexité à automatiser, la compatibilité avec des outils, la maturité du processus de test, les ressources disponibles, les risques et la criticité, et le coût.
Un risque représente une menace potentielle pour la qualité du site internet testé.
La probabilité, c’est la fréquence à laquelle le risque peut se produire.
L’impact, c’est l’ampleur des conséquences en cas de réalisation du risque.
Pour évaluer la probabilité, il y a plusieurs facteurs : l’historique, l’expertise, la documentation, la complexité et la rapidité.
Pour identifier vos besoins en données, vous devez comprendre vos scénarios de tests, déterminer vos données en entrée, identifier vos données de tests, vérifier la qualité de vos données et identifier les données de performance.
Une fois que vous avez identifié vos données, vous allez pouvoir commencer à rédiger et à automatiser vos tests via des scripts dans la deuxième partie de ce cours. Mais avant cela, je vous ai préparé un petit quiz pour tester vos connaissances sur cette première partie.
