this scenario explains how important it is document frequently encountered errors
Pensez-vous que les erreurs logicielles ne se produisent qu'une seule fois et que lorsqu'elles sont corrigées, elles ne refont jamais surface? Je pense qu'environ 30% des erreurs se reproduisent.
Dans cet article, je souhaite expliquer à quel point il est important de documenter certaines des erreurs fréquemment rencontrées.
Ci-dessous, vous trouverez quelques zones communes où les problèmes sont observés et un modèle pour les documenter.
J'espère que vous le trouverez utile!
image la source
Scénario 1
Le code est déployé et prêt pour le contrôle qualité. John, le testeur est prêt avec ses cas de test. À mi-chemin des tests, il rencontre un problème. Il sent que cela a été remarqué plusieurs fois plus tôt, mais John ne savait pas comment le résoudre.
John et Sheryl allèrent tous deux à la recherche de Smith qui avait vu la même erreur plus tôt et l'avait résolue auparavant. Malheureusement, Smith était en congé ce jour-là.
Que devrait faire John maintenant? John devrait-il essayer de contacter Smith pour trouver une solution même lorsque Smith n'est pas disponible?
Par conséquent, si un problème environnemental est observé à plusieurs reprises dans plusieurs rejets, c'est une bonne idée de documenter les détails et placez-le dans un emplacement partagé. Cela éliminera la dépendance vis-à-vis d'une seule personne et aidera tous les membres de l'équipe à trouver une solution par eux-mêmes lorsque cela se produit.
Scénario n ° 2
John teste une nouvelle version et rencontre à nouveau une erreur connue. Cette fois, il sait qu'un défaut a été créé pour cela dans l'une des versions précédentes. Mais la question est: 'Comment puis-je trouver le numéro du défaut et les autres détails associés?'
Dans ce cas aussi, que pensez-vous aiderait John?
- Rechercher le défaut dans Outil de suivi des défauts avec la description?
- Rechercher tout le passé rapports de défauts ?
- Approcher son chef d'équipe pour obtenir de l'aide?
Ce sont des possibilités.
Mais à mon avis, si ces problèmes sont bien documentés dans un domaine séparé et partagés avec l'équipe, cela ajoute de la valeur et fait gagner du temps.
Ce que vous apprendrez:
- Certains des domaines avec des erreurs fréquentes:
- Téléchargez des modèles pour suivre les erreurs fréquemment rencontrées
- Avantages de la documentation des erreurs fréquemment rencontrées
- Conclusion
- lecture recommandée
Certains des domaines avec des erreurs fréquentes:
1) Fichier de paramètres - Sur la base de mon expérience avec l'outil Informatica, dans de nombreux cas, j'ai remarqué le fichier param pointant vers une connexion de base de données incorrecte. Cela a entraîné les mêmes problèmes à plusieurs reprises. La raison principale était que la connexion était partagée entre le développement et le contrôle qualité. Ainsi, le fichier param devait toujours être mis à jour selon les besoins pour éviter l'erreur.
2) URL pointant vers une base de données incorrecte
3) Problèmes d'accès - Les utilisateurs rencontrent des problèmes lorsqu'ils ont des autorisations d'accès insuffisantes ou incorrectes à la base de données ou Dans ce cas, un document décrivant les étapes à suivre ou la / les personne (s) à contacter serait très utile.
4) Problème de données de test - L'utilisation d'un format ou de valeurs de données incorrects entraînera le plus souvent des problèmes.
5) Problèmes de base de données - La connexion à la base de données a expiré est l'un de ces problèmes courants. Certains des temps d'arrêt sont temporaires, planifiés et parfois, nous pouvons avoir besoin de l'aide de DBA. Les utilisateurs sont informés à l'avance de la maintenance planifiée, mais pour les erreurs temporaires et la résolution, les testeurs ont définitivement besoin
Les erreurs les plus répétées sont généralement problèmes environnementaux .
Pourtant, problèmes de code ne peut être ignoré. La discussion ci-dessus est générique et n'inclut pas les problèmes de code car les problèmes de code sont plus spécifiques à votre application, framework, langage de programmation, etc.
java vs c ++ qui est mieux
Une petite zone de défauts pourrait également être saisie de données ou erreur d'utilisation humaine s .
TéléchargerModèles pour suivre les erreurs fréquemment rencontrées
Format Word
=> Télécharger le modèle de suivi des erreurs (Monde)
Format Excel
=> Télécharger le modèle de suivi des erreurs (Excel)
Avantages de la documentation des erreurs fréquemment rencontrées
1) Élimine la dépendance - Dans le scénario 1, John dépendait de Smith pour la résolution. S'il y avait eu un document pour la référence de John, ce ne serait pas le cas.
2) Délai d'exécution plus rapide - Prenez le scénario 2. Un testeur n'aurait pas à parcourir la liste complète des défauts déjà enregistrés s'il existait un document dédié aux problèmes haute fréquence.
3) Aide les nouveaux membres de l'équipe à être autonomes
4) Aide à résoudre les erreurs humaines
Conclusion
Je dirais qu'il est certainement utile de documenter les problèmes les plus fréquents car cela ferait une merveilleuse référence et une valeur ajoutée.
Il peut devenir fastidieux de documenter pendant l'exécution du test, mais comme meilleure pratique, des notes approximatives peuvent être prises pendant l'exécution, qui peuvent ensuite être résumées et mises à jour dans des documents partagés.
lecture recommandée
- 10 meilleurs systèmes de gestion de documents pour un meilleur flux de travail
- Mise à jour et suppression de documents MongoDB avec des exemples
- Document de requête MongoDB utilisant la méthode Find () (exemples)
- Tutoriel sur le système de gestion de documents SharePoint
- 7 types d'erreurs logicielles que chaque testeur devrait connaître
- Comment tester plus intelligemment: explorez plus, documentez moins
- Scénario de test vs scénario de test: quelle est la différence entre ceux-ci?
- Comment rédiger un document de stratégie de test (avec un exemple de modèle de stratégie de test)