La rédaction d'un plan de test du système

«La qualité extraordinaire ne fait pas bon à court terme un sens économique."
- Peopleware, Tom Demarco
Imaginez un instant que vous venez de terminer une application web pour un client. Natation autour sein de cette application est de 100 bogues. Quelle est la proportion de ces bogues diriez-vous est acceptable pour le client à trouver (par exemple 50, 30, 10)? Le point est, ces bugs vont être trouvée par quelqu'un, et de son soit va être vous-même ou le client. Vous pouvez penser que c'est une échelle mobile, les bogues plus le client trouve, plus votre crédibilité en souffre et le plus de dégâts que vous faites pour la relation d'affaires.

Dans les arts martiaux, il ya un proverbe qui dit; "s'attendre au meilleur, mais se préparer au pire". Les sceaux de l'US Navy ont une version un peu plus des armes à feu-ho qui va; «Le plus vous transpirez dans la formation, le moins vous saignez dans la bataille." Remarquez comment il affirme que le «moins» que tu saignes dans la bataille, ce qui implique que si vous entrez en combat, vous allez obtenir sanglante. Le développement logiciel est comme ça aussi, si vous allez créer un logiciel, vous allez obtenir des bugs.

A titre indicatif, vous voulez essayer attraper au moins 80% de tous les bugs. Idéalement, vous iriez à 100%, un objectif louable, mais noble. Votre meilleur pari pour la capture que de nombreux bugs que possible est de créer un plan de test du système. Création d'un plan de système de test est décent plus facile à dire qu'à faire. Un bon endroit pour commencer est votre cahier des charges fonctionnel (en supposant que vous en avez un). En effet, votre cahier des charges est converti dans le plan de test du système. Qu'est-ce que vous faites est de vérifier si les choses que vous dit que vous alliez faire ont été effectivement fait.

Un plan de test n'a rien de nouveau, en fait, la structure-je utiliser a été développé par Microsoft ans. C'est un format simple, un cas de test a un titre, certaines mesures, et un résultat attendu.

J'écris mes plans de test avec l'intention d'avoir une course de certification indépendant AQ à travers elle, la connaissance donc pas avant du système devrait être pris en charge. Vous voulez quelqu'un qui n'a jamais utilisé le système avant parce qu'ils auront une nouvelle approche. Vous comptons sur eux de l'utiliser d'une manière qui n'a jamais été prévu (par exemple sur la page «Mon profil», ils tapent dans un nom très long pour la «Société» sur le terrain et planter le système parce que la base de données a de place que pour une chaîne de caractères 32).

Vous devriez garder vos cas de test à court, au point, et autonome (c'est à dire qu'ils n'ont généralement pas de lien vers d'autres cas de test). Si vous avez un cas de test qui va sur une page, pensez à le casser en plus petites unités. Le document lui-même devrait être autonome aussi bien, qui est, il ne devrait pas exiger le testeur QA de se lever et de poser des questions comme les programmeurs "quel est le login mot de passe?». Demandez à votre testeur QA de se connecter tous les bogues qu'ils trouvent dans votre système de suivi des bogues et aussi d'écrire une description adéquate plutôt que de simplement dire "16 cas de test a échoué." Vous pouvez lire mon article sur Consignation des bogues comme un pro pour quelques suggestions sur les bonnes pratiques d'exploitation de bugs....