how does test planning differ
Nous convenons tous que les projets d'automatisation sont de nature différente des projets de test 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 la planification.
Un projet de mixage planifié est inévitablement exécuté; cela affecte non seulement le projet en cours et jette une ombre sur les capacités de l’individu, mais peut également conduire à une perte de confiance dans l’équipe pour le client / la direction, ce qui affecte les activités futures. Je dirais plutôt que nous, les testeurs, sommes prévenus que désolé.
=> Cliquez ici pour une série complète de didacticiels sur le plan de test
Une bonne bande dessinée de Dilbert sur la planification:
Avant d'aller plus loin, je veux établir de quoi cet article ne va PAS être.
#1) Il ne s'agit pas d'une discussion approfondie sur les cadres d'automatisation. Différents projets utilisent différents frameworks 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 aux liens ci-dessous:
Tester les cadres d'automatisation, partie 1 et partie 2 .
#deux) 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 des outils spécifiquement. Chaque activité du SDLC demande du temps, des efforts, une infrastructure - en d'autres termes - de l'argent.
Pour un projet de test manuel, les facteurs de consommation sont les suivants:
- Gens
- Outils - Test / Gestion des défauts
- Infrastructure - environnement
- Temps
- Formation
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
- Complément 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 dans lequel vous avez obtenu le résultat souhaité?
Ne pas.
Il y a une et la seule question qui détermine le succès - «Êtes-vous en mesure de générer un meilleur ROI (retour sur investissement) par rapport à l'itinéraire manuel»? - Sinon 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 se concentrant sur les aspects spécifiques de l'automatisation à prendre en compte:
Sections du plan de test de test d'automatisation
Section 1:Portée
- Choisissez les cas de test / scénarios qui doivent être régressés à plusieurs reprises sur plusieurs cycles.
- Parfois, les cas de test les plus simples nécessitent de nombreuses solutions compliquées pour être automatisées. Si ce n'est que pour une utilisation unique, cela n'a évidemment aucun 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 le Framework dans le monde de l'automatisation. Certains cadres sont extrêmement difficiles à créer et sont également efficaces - mais ils demandent du temps, des efforts et des compétences. Recherchez toujours un terrain d'entente et faites de votre mieux sans compromettre la surutilisation des ressources.
- Décidez des meilleures pratiques de codage à utiliser, des conventions de dénomination, des emplacements des ressources 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 est de comprendre les capacités de l’équipe et d’anticiper sur la portée de l’automatisation qui entre en jeu. Cela aidera à choisir une équipe qui répond à la fois aux besoins d'automatisation et de test manuel. Choisissez également des personnes qui ont la bonne attitude - celles-ci ne pensent pas que les tests manuels sont en dessous de leur stature.
- Choisissez une équipe bien familiarisée avec l'AUT, la gestion des tests, 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 les existants?
Section # 5: Des horaires
- Inclure le temps pour les procédures pas à pas du code et l'inspection des scripts d'automatisation
- Maintenez 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 avant l'octroi de licence pour l'outil.
- Aussi, analysez si le reste du Outils de gestion en place et l'outil d'automatisation que vous essayez d'intégrer sont interconnectables pour un avantage supplémentaire.
Section # 7:Livrables
- Vos scripts de test sont vos livrables. Cependant, tout le monde n'est pas averti en automatisation / langage de programmation. Alors, prévoyez de créer un document «Comment faire» qui aidera les utilisateurs actuels et 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: Des risques
Si vous envisagez de proposer une solution d'automatisation, assurez-vous de choisir des outils et des solutions rentables pour vous assurer que l'effort d'automatisation n'alourdit 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 vu sur de longues périodes de temps.
Par conséquent, si vous proposez d'automatiser un système, choisissez celui qui est
- Stable et pas trop d'entretien
- Possède de vastes suites de régression
- N'a pas trop d'intervention manuelle ou ne dépend pas de l'intuition humaine
Section # 9:Données de test
- 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 juste à trop de maintenance du script et peut provoquer 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 quoi que ce soit d'autre. 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 des scripts sont également techniques et peuvent ne pas être facilement compris par le reste des équipes. Prévoyez d'écrire des résultats détaillés dans le bloc-notes ou sur des feuilles Excel comme mesure supplémentaire.
- Des documents de cadre détaillés, des résultats d'examen, des rapports sur les défauts, des rapports sur l'état d'exécution sont également attendus.
En tant que passionnés d'automatisation, nous pourrions penser que les clients / la direction n'achètent pas facilement les propositions d'automatisation.
Questions d'entretien du centre d'assistance de niveau 1
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 non seulement que nous parviendrons à 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ée tout au long de ce voyage. Encore une fois, le retour sur investissement signifie tout.
Cet article est rédigé par Swati Seela, membre de l'équipe des auteurs de 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 complète de didacticiels sur le plan de test
lecture recommandée
- Cadres QTP - Cadres d'automatisation des tests - Exemples de cadres linéaires et pilotés par mots-clés - Tutoriel QTP # 17
- Défis des tests manuels et automatisés
- Comment décider quel type de test est requis pour un projet? - Manuel ou automatisation
- Pourquoi avons-nous besoin d'un cadre pour l'automatisation des tests?
- Top 10 des stratégies d'automatisation des tests et des meilleures pratiques
- Comment traduire des cas de test manuels en scripts d'automatisation? - Un guide étape par étape avec un exemple
- Quand opter pour les tests d'automatisation?
- Processus de test d'automatisation en 10 étapes: comment démarrer les tests d'automatisation dans votre organisation