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

«Qualité extraordinaire ne remédie pas à court terme un sens économique."
- Peopleware, Tom Demarco
Imaginez un instant que vous venez de terminer une application web pour un client. Nageant autour dans cette application est de 100 bugs. Quelle est la proportion de ces bugs 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 sa va être soit vous ou le client. Vous pouvez penser que c'est une échelle mobile, les bugs 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: "attendez le meilleur, mais se préparer au pire". Les sceaux de l'US Navy ont une version un peu plus gun-ho qui va, "Le plus vous transpirez dans la formation, moins vous saignez dans la bataille." Remarquez comment il affirme que le «moins» que tu saignes dans la bataille, ce qui signifie 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 devriez aller à 100%, un objectif louable, mais noble. Votre meilleur pari pour attraper autant de bogues que possible est de créer un plan de test du système. Création d'un plan de système décent de test est 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. Ce que vous faites est de vérifier pour voir si les choses que vous dites que vous allez faire ont été réellement fait.

Un plan de test n'a rien de nouveau, en fait, la structure que j'utilise a été développé par Microsoft années. Il s'agit d'un format simple, un cas de test a un titre, quelques marches, et un résultat attendu.

J'écris mes plans de test avec l'intention d'avoir une course de certification indépendant, QA à travers elle, donc pas de connaissances préalable du système doit être assumée. Vous voulez quelqu'un qui n'a jamais utilisé le système avant car ils vont adopter une nouvelle approche. Vous comptez sur eux pour 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, car la base de données a de place que pour une chaîne de 32 caractères).

Vous devriez garder vos cas de test court, au point, et autonome (c'est à dire qu'ils n'ont généralement pas de liens 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 autonomes ainsi, c'est, il ne devrait pas exiger le testeur QA de se lever et de poser des questions aux programmeurs comme "quel est le mot de passe de connexion?". Demandez à votre testeur QA pour vous connecter tous les bugs 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 test a échoué." Vous pouvez lire mon article sur Journalisation des bogues comme un pro pour des suggestions sur les bonnes pratiques d'exploitation de bugs....