Menu

3 stratégies pour traiter un défaut de bloqueur

3 strategies dealing with blocker defect

Essayez Notre Instrument Pour Éliminer Les Problèmes

Les défauts de blocage ajoutent des tonnes de drame à des jours de test par ailleurs réguliers.

Dans cet article, je souhaite aborder certaines étapes qu'un testeur peut suivre pour les gérer.

Je vais supposer que nos chers lecteurs comprennent déjà profondément la gravité et la priorité des défauts. Besoin d'un bref récapitulatif? Regarde ça.

Maintenant, cela signifie-t-il toujours que nous devons arrêter complètement les tests si nous rencontrons un problème de blocage?

Dans certains cas, «Oui», mais peut-être pas toujours. Il peut y avoir des cas où une activité de test est possible.

Traiter le défaut du bloqueur

image la source

Voici quelques situations que j'ai vécues dans ma carrière de testeur. Je crois fermement que les étapes décrites ci-dessous (ultérieurement consolidées dans un organigramme) doivent être suivies pour simplifier ce processus.

Allons-y directement.

Mesures à prendre lorsque vous rencontrez un défaut de blocage

Étape 1: Lorsque vous rencontrez un problème, prenez du temps pour en trouver la cause.

Je suis convaincu qu'en tant que testeur, notre travail ne s'arrête pas à signaler les défauts . Si le temps le permet, nous devrions explorer ce qui aurait pu causer le problème. Il se peut que nous ne puissions pas toujours indiquer la zone à problème exacte, mais essayez de résoudre le problème autant que possible. Les mêmes détails peuvent être mis à jour dans le défaut en tant que commentaires supplémentaires.

J'ai beaucoup fait cela dans mes projets, et cela a abouti à une solution rapide. Les avantages de l'analyse des causes profondes sommes:

  • Étant une valeur ajoutée, cela peut certainement fournir une meilleure direction au développeur pour la correction des bogues.
  • En outre, le testeur d'assurance qualité peut reconnaître si ce problème est auto-créé (saisie de données ou problèmes d'utilisation humaine) et si tel est le cas, peut être résolu par le testeur lui-même. Lorsque de telles erreurs sont signalées aux développeurs sans que nous les vérifions du côté du contrôle qualité, elles sont considéré comme un non-problème et pourrait créer une réputation négative pour le testeur.

Donc, je suggère que nous vérifions toujours de notre côté avant de consigner un défaut.

Voici quelques exemples en temps réel de mes projets qui renforceront les points ci-dessus:

J'ai travaillé sur un projet où nos tests nous obligeraient à déposer un fichier à un emplacement spécifié. Renommez-le pour qu'il corresponde au nom dans la configuration. Un travail planifié ramasserait le fichier de données et chargerait les données dans le système. Après quoi, nous validerions les données dans la base de données et le front-end.

quel est le meilleur dissolvant de virus

Nous avions l'habitude de rencontrer des problèmes où la tâche s'exécutait mais les données ne se chargeraient pas, et après enquête, c'était parce que le testeur n'avait pas changé le nom en déposant le fichier à l'emplacement.

C'était un bloqueur pour nous, mais pas quelque chose qui nécessitait l'attention des développeurs. Nous avons dû faire attention aux détails et éviter ces petites erreurs.

Voici quelques catégories courantes, causes profondes et remèdes:

# 1) Fichier d'hôtes Problème - Dites, votre fichier hosts a des paramètres incorrects et qui causent le problème. Dans ce cas, vous pouvez soit mettre à jour le fichier hôte vous-même, soit demander l'aide d'une personne ayant accès pour mettre à jour et poursuivre l'exécution du test.

Un défaut pour le même devrait être signalé afin que les développeurs enquêtent, mais avec la solution de contournement, les tests fonctionnels peuvent toujours être poursuivis.

Noter: Vérifiez auprès de vos équipes de projet si l'équipe d'assurance qualité peut apporter ces modifications avant de le faire.

hosting VPN Europe

# 2) Configuration - Souvent, nous avons noté des problèmes de configuration tels que le fait de ne pas pointer vers l'environnement correct ou d'autres problèmes de configuration, qui sont des problèmes de blocage. Dans de tels cas également, les testeurs peuvent apporter des modifications et procéder aux tests.

Noter: Encore une fois, demandez la permission avant de faire cela.

# 3) Problème de code - Si vous pensez que le problème est dû au code, les testeurs ne peuvent pas faire grand-chose. Enregistrez un défaut de blocage et attendez que le correctif procède au test.

# 4) Problème de déploiement - Un mauvais déploiement est une autre cause fréquente de problèmes de blocage et ceux-ci peuvent être détectés lors du test de cohérence. Ici aussi, les tests doivent être arrêtés immédiatement jusqu'à ce qu'une nouvelle version soit reçue.

# 5) Environnement vers le bas - Si l'environnement est en panne, disons que la base de données ne se connecte pas au serveur ou que l'URL ne fonctionne pas dans le cas de sites Web; les testeurs ne peuvent pas faire grand-chose dans ces cas à part signaler un défaut et attendre que le système soit opérationnel.

Par conséquent, si une solution de contournement existe, utilisez-la pour continuer le test. La seule façon de trouver, si cette solution de contournement existe, consiste à rechercher la cause première. Le plus souvent, il pourrait y avoir une alternative.

Étape 2: Il est très facile de tomber dans une boucle infinie lors de la recherche de la cause première. Alors, assurez-vous qu'il ne consomme pas toute la journée et tous les efforts.

Voici quelques conseils:

  • Trouvez un équilibre et reconnaissez le point d'arrêt lorsque vous y arrivez.
  • L'expérience et l'expertise d'un testeur sont essentielles pour un RCA réussi. Cependant, c'est une bonne idée d'impliquer l'équipe et le chef d'équipe, si nécessaire.
  • Lorsque vous pensez que RCA prend du temps, signalez d'abord le problème immédiatement et fournissez autant d'informations que possible. Une capture d'écran est toujours utile.
  • Si nécessaire, faites un suivi. Envoyez un e-mail au responsable ou au développeur pour attirer l'attention sur le problème critique.
  • Continuez le dépannage après avoir alerté les parties nécessaires.

Raison pour laquelle les défauts de blocage doivent être signalés immédiatement:

  • La direction doit être informée de tous les temps d'arrêt si le problème se trouve être un défaut spectaculaire. Ces informations doivent être relayées au client et peuvent également nécessiter des mises à jour du plan de projet (délais d'AQ), des changements dans les livrables, etc.
  • Tout retard dans les livrables d'assurance qualité doit être étayé par des preuves. Il est donc toujours préférable de communiquer le plus tôt possible au lieu d'attendre la fin de la journée.

Étape 3: Maintenant, passant à la dernière étape puisque nous avons fini d'analyser le problème et de le communiquer, quelle est la prochaine étape?

  • Si le problème bloque l'accès à un domaine fonctionnel, vérifiez si cela a un impact sur d'autres domaines
  • Si l'application frontale est en panne, vérifiez si les tests backend / middleware / base de données peuvent être poursuivis.
  • Si aucune activité d'exécution de test ne peut avoir lieu, essayez de travailler sur de la documentation liés à votre projet.
  • Vous pouvez également essayer de identifier les domaines d'automatisation si vous répétez manuellement beaucoup de travail. L’automatisation n’a pas toujours besoin d’utiliser un outil. Dites, la génération de rapports est une tâche monotone pour vous, c'est un domaine qui peut être automatisé par de simples macros Excel, etc.
  • Passez du temps à connaître les outils open source qui peuvent être implémentés dans votre projet
  • Dernier mais pas des moindres , travaillez vers l’innovation, le mantra qui régit actuellement le monde!

finalement , l'organigramme qui résume toute la discussion!

Organigramme: étapes pour gérer un défaut de blocage

défaut de blocage

Auteur : Cet article génial est écrit par Priya R., membre de l'équipe STH.

Quelles mesures prenez-vous lorsque vous rencontrez un défaut de blocage?

lecture recommandée

^