Escrevendo um Plano de Teste do Sistema

"Qualidade extraordinária não faz sentido a curto prazo bem econômico."
- Peopleware, Tom Demarco
Imagine por um momento que você acabou de terminar uma aplicação web para um cliente. Nadando ao redor dentro dessa aplicação é de 100 bugs. Qual a proporção desses bugs você diria que é aceitável para o cliente encontrar (por exemplo, 50, 30, 10)? O ponto é, aqueles erros vão ser encontrado por alguém, e seu ou vai ser você ou o cliente. Você pode pensar nisso como uma escala móvel, os bugs mais o cliente encontra, mais a sua credibilidade sofre e mais o dano que você faz para o relacionamento comercial.

Nas artes marciais há um ditado, "esperar o melhor, mas se preparar para o pior". Os Seals da Marinha dos EUA tem uma versão um pouco mais arma-ho, que vai, "Quanto mais você suar nos treinamentos, menos você sangrará no campo de batalha." Observe como ele diz que o 'menos' você sangrar na batalha, o que significa que se você entrar em combate, você está indo para obter sangrenta. Desenvolvimento de software é assim também, se você estiver indo para criar um software, você está indo para obter bugs.

Como um guia, você quiser tentar pegar pelo menos 80% de todos os erros. Idealmente, você iria para 100%, uma meta que vale a pena, mas sublime. Sua melhor aposta para a captura de tantos bugs quanto possível é criar um plano de teste do sistema. Criar um plano de teste decente sistema é mais fácil de dizer do que fazer. Um bom lugar para começar é a sua especificação funcional (supondo que você tem um). Com efeito, sua especificação é convertido para o plano de teste do sistema. O que você está fazendo é verificar para ver se as coisas que você disse que ia fazer de fato foi feito.

Um plano de teste não é nada novo, na verdade, a estrutura que eu uso foi desenvolvido pela Microsoft de anos atrás. É um formato simples, um caso de teste tem um título, alguns passos e um resultado esperado.

Eu escrevo os meus planos de teste, com a intenção de ter uma corrida verificador independente QA através dela, de forma que nenhum conhecimento prévio do sistema deve ser assumida. Você quer alguém que nunca usou o sistema antes, porque eles vão ter uma nova abordagem. Você está contando com eles para usá-lo de uma forma que nunca teve a intenção (por exemplo, na página "Meu perfil", ele digita um nome muito longo para a 'Companhia' campo e travar o sistema porque o banco só tem espaço para uma seqüência de 32 caracteres).

Você deve manter seus casos de teste de curto, ao ponto, e independentes (ou seja, eles geralmente não vincular a outros casos de teste). Se você tem um caso de teste que vai mais de uma página, considere dividi-lo em unidades menores. O próprio documento deve ser auto-contido, bem como, que é, não deve exigir o testador QA para levantar e pedir programadores perguntas como "qual é a senha de login?". Instrua o testador QA para registrar todos os erros que encontrarem em seu sistema de rastreamento de bugs e também para escrever uma boa descrição em vez de apenas dizer "Caso de Teste 16 falhou." Você pode querer ler o meu artigo sobre erros de Registro como um profissional para algumas sugestões sobre práticas madeireiras boas bugs....