Comment faire

En quoi la planification des tests diffère-t-elle pour les projets manuels et d’automatisation ?

Nous sommes tous d’accord pour dire que les projets d’automatisation sont de nature différente des projets de tests manuels. Bien que les projets d’automatisation autonomes n’existent pas vraiment (ou ne devraient pas exister idéalement), les projets manuels et d’automatisation sont traités différemment lors de leur planification.

Un projet mixte planifié obtient inévitablement est exécuté; cela affecte non seulement le projet en cours et jette une ombre sur les capacités de l’individu, mais peut également entraîner une perte de confiance dans l’équipe pour le client/la direction, ce qui affecte les affaires futures. Je préfère dire que nous, les testeurs, prévenons plutôt que guérir.

=> Cliquez ici pour une série de didacticiels sur le plan de test complet

Une bonne BD de Dilbert sur la planification :

planification de projet dilbert

Avant d’aller plus loin, je veux établir le sujet de cet article.

#1) Il ne s’agit pas d’une discussion approfondie sur les frameworks d’automatisation. Différents projets utilisent des frameworks différents en fonction de la nature de leur AUT, de leur architecture, de leur complexité, de l’expertise de l’équipe, etc.

Les informations concernant les cadres peuvent être trouvées sur les liens ci-dessous:

Testez les frameworks d’automatisation partie 1 et partie 2.

#2) Il ne s’agit pas non plus de modèle, de format ou de création d’un document de plan de test. Nous allons aborder les considérations de pré-documentation pour un projet d’automatisation, plus dans les lignes d’une analyse de faisabilité.

#3) Ce n’est pas non plus les outils en particulier. Chaque activité dans le SDLC prend du temps, des efforts, une infrastructure, en d’autres termes, de l’ARGENT.

Pour un projet de test manuel, les facteurs de coût sont :

  • Gens
  • Outils – Test/Gestion des défauts
  • Infrastructures – environnement
  • Temps
  • Entraînement
  • Pour un projet d’automatisation, en plus des éléments ci-dessus, il faut des dépenses pour :

  • Outils d’automatisation
  • Complément pour l’intégration de l’outil de gestion des tests
  • Add-in pour prendre en charge AUT (comme SAP, Oracle, etc.)
  • Cadre mis en place
  • Formation spécifique à l’outil
  • Dans ces circonstances, le succès d’un projet d’automatisation dépend-il de la qualité de l’écriture du code, du nombre de composants réutilisables que vous avez écrits ou du nombre de lignes de code que vous avez obtenu pour obtenir le résultat souhaité ?

    Non.

    Il y a une seule et unique question qui détermine le succès – « Êtes-vous capable de générer un meilleur ROI (Retour sur Investissement) par rapport à la route Manuelle » ? – Si ce n’est pas immédiatement, éventuellement.

    Si la réponse à cette question est « NON », c’est que vous avez mal planifié le projet d’automatisation.

    Normalement, un plan de test comprend les sections suivantes. Nous allons discuter de chacun d’eux en nous concentrant sur les aspects spécifiques à l’automatisation à prendre en compte :

    plan de test d'automatisation

    Sections du plan de test des tests d’automatisation

    Section 1 : Portée

  • Choisissez les cas de test/scénarios qui doivent être régressés encore et encore sur plusieurs cycles.
  • Parfois, les cas de test les plus simples nécessitent l’automatisation de nombreuses solutions compliquées. S’il ne s’agit que d’un usage unique, cela n’a évidemment pas de sens. La réutilisation devrait être votre objectif.
  • Les tests d’automatisation n’effectuent pas/ne peuvent pas effectuer de tests exploratoires.
  • Section #2 : Stratégie de test

  • Cette section est appelée Framework dans le monde de l’automatisation. Certains cadres sont extrêmement difficiles à créer et sont également efficaces – mais en termes de temps, d’efforts et de compétences, ils sont exigeants. Cherchez toujours un juste milieu et faites de votre mieux sans compromettre la surutilisation des ressources.
  • Décidez des meilleures pratiques de codage à utiliser, des conventions de nommage, des emplacements pour les actifs de test à stocker, du format des résultats des tests, etc. pour maintenir l’uniformité et augmenter la productivité.
  • Section 3 : ressources/rôles et responsabilités

  • La première étape dans cette direction consiste à comprendre les capacités de l’équipe et à anticiper la portée de l’automatisation à venir. Cela aidera à choisir une équipe qui convient à la fois aux besoins d’automatisation et de tests manuels. De plus, choisissez des personnes qui ont la bonne attitude – celles-ci ne pensent pas que les tests manuels sont en dessous de leur taille.
  • Choisissez une équipe bien au fait de l’AUT, de la gestion des tests, de la gestion des défauts et d’autres activités SDLC
  • Section 1 : Portée
  • Section #4 : Outils

    Choisissez les outils d’automatisation en fonction des règles suivantes :

  • L’entreprise a-t-elle déjà des licences pour un certain outil, essayez de voir si vous pouvez l’utiliser
  • Recherchez des outils open source (mais fiables)
  • Les membres de l’équipe connaissent-ils déjà l’outil ou devons-nous faire appel à quelqu’un de nouveau ? Ou former ceux qui existent déjà ?
  • Section #5 : Horaires

  • Inclure du temps pour les revues de code et l’inspection des scripts d’automatisation
  • Maintenir les scripts en temps opportun. Si vous créez un morceau de code que vous n’allez pas utiliser pendant les 6 prochains mois environ, assurez-vous de le maintenir périodiquement pour réduire ses risques d’échec.
  • Section #6 : Environnement

  • L’environnement cible que votre AUT va exécuter et l’outil d’automatisation que vous souhaitez utiliser doivent être compatibles. C’est l’un des facteurs à prendre en compte pour la pré-licence de l’outil.
  • Analysez également si le reste des outils de gestion en place et l’outil d’automatisation que vous essayez d’intégrer sont interconnectés pour un avantage supplémentaire.
  • Section #7 : Livrables

  • Vos scripts de test sont vos livrables. Cependant, tout le monde n’est pas familiarisé avec l’automatisation/le langage de programmation. Alors, prévoyez de créer un document « Comment faire » qui aidera les utilisateurs actuels et les futurs membres de l’équipe à comprendre ce script même lorsque vous n’êtes pas là.
  • Incluez également des commentaires dans votre script.
  • Section #8 : Risques

    Si vous envisagez de proposer une solution d’automatisation, veillez à choisir des outils et des solutions rentables pour vous assurer que l’effort d’automatisation ne surcharge pas le projet.

    Il est important de définir l’attente selon laquelle le retour sur investissement d’un projet d’automatisation ne peut pas être positif immédiatement mais peut être clairement visible sur de longues périodes.

    Par conséquent, si vous proposez d’automatiser un système, choisissez celui qui est

  • Stable et pas trop d’entretien
  • Possibilité d’énormes suites de régression
  • N’a pas trop d’intervention manuelle ou ne dépend pas de l’intuition humaine
  • Section 9 : Données d’essai

  • Prendre en considération les aspects de sécurité des données
  • Ne codez en dur aucune donnée de test dans les scripts. Cela conduit simplement à trop de maintenance de script et peut induire des erreurs lors de la modification.
  • Soyez très précis. Pour une étape de test manuel – « entrez le prénom », vous pouvez dire entrez n’importe quel nom à 5 caractères. Pendant le test, un testeur peut taper « Swati » ou « Seela » ou autre chose. Mais pour un outil, il ne peut pas faire de telles suppositions. Par conséquent, fournissez des valeurs exactes.
  • Section #10 : Rapports/Résultats

  • Les résultats de l’exécution du script sont également techniques et peuvent ne pas être facilement compris par le reste des équipes. Prévoyez d’écrire les résultats détaillés dans le bloc-notes ou sur des feuilles Excel comme mesure supplémentaire.
  • Des documents cadres détaillés, des résultats de revue, des rapports de défauts, des rapports d’état d’exécution sont également attendus.
  • Nous, en tant qu’amateurs d’automatisation, pourrions penser que les clients/la direction n’achètent pas facilement les propositions d’automatisation.

    Cependant, lorsque notre objectif ultime est de maximiser le retour sur investissement grâce à l’automatisation, nous sommes également en parfaite harmonie avec les objectifs de la direction/du client. Cela garantira que non seulement nous arriverons à automatiser notre projet, mais que nous serons en mesure de le faire, avec beaucoup de consentement, de coopération et d’enthousiasme.

    La planification et l’analyse approfondie de tous les facteurs énumérés ci-dessus peuvent être notre allié tout au long de ce voyage. Encore une fois, le retour sur investissement signifie tout.

    Cet article est écrit par Swati Seela, membre de l’équipe d’auteurs STH.

    Vous avez des questions ou des choses à discuter ? N’hésitez pas à poster dans les commentaires ci-dessous.

    => Visitez ici pour une série de didacticiels sur le plan de test complet

    Back to top button