Como fazer um plano de testes baseado em casos de uso

Garantir a qualidade do software desenvolvido é primordial para conseguir o sucesso de qualquer projeto. Testá-lo adequadamente virou uma obrigação. Aqui vou mostrar uma forma sistemática de como montar um plano de testes eficiente e consistente baseado em casos de uso.

Uma das primeiras perguntas que devem ser respondidas para iniciar a montagem de um plano de testes é o que testar? Parece óbvio e a resposta é realmente essa: devemos testar as funcionalidades que compõem o escopo do software que está sendo desenvolvido. Agora você pode perguntar, onde está descrito esse escopo? Pode estar na proposta do projeto, na especificação funcional e, em muitos projetos, nos casos de uso.
Os casos de uso descrevem requisitos, identificam o valor que o cliente espera obter da funcionalidade, e representam a forma como o sistema será utilizado. Permite identificar todos os caminhos que o usuário pode percorrer para conseguir o que deseja e se podem ocorrer problemas. Mostram ao cliente o que esperar do software, ao desenvolvedor o que codificar, e ao testador ou certificador o que validar para garantir a qualidade dos entregáveis.

Desse modo, podemos concluir que os casos de uso ajudam na certificação e validação dos requisitos implementados. Simplificando e sistematizando o processo de teste do software, permitindo um ganho de produtividade e ajudando na garantia de que todo o escopo vai ser abrangido pelo teste.
Agora que sabemos que os casos de uso podem nos ajudar a fazer um plano de testes, já podemos começar a detalhá-lo. Abaixo vou listar alguns procedimentos que você pode seguir:

- Selecione o caso de uso que será testado, identifique o fluxo principal e os fluxos alternativos e desenhe um diagrama de atividades. Desse modo vai conseguir visualizar mais facilmente todos os cenários que o usuário pode utilizar.
- Agora que já identificou os cenários, você vai começar a escrever um caso de teste para cada cenário, detalhando neste caso de teste todos os passos do cenário. Desse modo o testador vai poder executar as ações do ator e validar se a resposta do sistema está de acordo com o que foi especificado;
- Para iniciar os testes, vai ser necessário a criação de uma base de dados de certificação, se a mesma ainda não existir (não é prudente fazer os testes na base de desenvolvimento e muito menos em produção), e identificar os dados de entrada que serão utilizados nos testes;
- É importante tabular o resultado dos testes, como quantidade de acertos, defeitos e correções, e armazenar essa informação em algum meio permanente. Isso vai servir para avaliar a qualidade de cada desenvolvedor da sua equipe;

Modelo de check list do plano de testes:


Conclusão

A utilização dos casos de uso como modelo para os testes vai permitir ao testador ter uma visão mais apurada do negócio e ter uma noção mais clara da necessidade dos clientes. Permite também, se o caso de uso estiver bem detalhado e consistente, a garantia de ter uma cobertura completa dos entregáveis desenvolvidos. A sistematização e padronização do processo de teste gera uma confiança maior por parte do cliente e diminui a curva de treinamento ou adaptação de novos testadores.

[]’s
Eduardo Ernandes da Silva
Arquiteto de Sistemas
Blog Arquitetura de Software .NET
http://arquiteturadotnet.wordpress.com/

Exibições: 253

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Eduardo Ernandes da Silva em 27 abril 2010 às 14:53
Camilo,

obrigado pelo elogio. Li tbm o seu artigo, o que já me ajudou a fazer algumas melhorias no processo de testes aqui da empresa onde eu trabalho.

[]'s
Eduardo Ernandes
Comentário de Camilo Ribeiro em 2 abril 2010 às 19:55
Boa tarde Eduardo,

Existem dois artefatos distintos na sua colocação:
O plano de testes e o caso de teste.

O Plano de Teste é o artefato mais abstrato do testware. Nele as informações ainda são muito estratégicas, como o escopo do teste (tanto em nível funcional quanto em nível não funcional), os tipos de teste que serão aplicados a cada um dos casos de uso, quais artefatos deverão ter inspeções, qual o nível de cobertura dos casos de uso e qual o nível de detalhamento dos casos de teste, entre outras informações sobre a condução, papeis, técnicas, ferramentas e todas as tomadas de decisão a nível de projeto/produto no teste de software.
Normalmente também temos estimativas sobre o número de ciclos de teste, quantidade de casos de teste e sobre a distribuição dos casos de teste em suítes de teste.
O documento mais reconhecido da atualidade ainda é o mesmo citado na norma 829 da IEEE. Pode ver a estrutura no post do wikipedia http://en.wikipedia.org/wiki/Test_Plan#IEEE_829_test_plan_structure
Mas usar o template do IEEE nem sempre é viável. O ideal é valorizar mais o planejamento do que o plano (artefato) e personalizar um plano de testes que seja apropriado para a maturidade da organização.

O seu exemplo de técnica de elaboração de casos e cenários de teste está muito bem descrito :) parabéns!

Normalmente são definidos vários cenários, atribuídos os pontos de verificação das regras e através dos cenários são associados procedimentos de teste, entradas, saídas e resultados esperados.
Elaborei um roteiro para especificação de casos de teste baseados em casos de uso (texto ou diagrama) com imagens.
O passo a passo pode ser acessado no link: http://www.bugbang.com.br/?p=823

Também palestrei no Centro Universitário UNA sobre o assunto recentemente, o slide está disponível em: http://www.slideshare.net/camiloribeiro/tcnicas-de-teste

Mas é importante o analista de teste ou projetista de teste não se limitar a essa técnica. Várias outras técnicas podem ser usadas como partição de equivalência, análise de valores limites, tabela de decisão, testes baseados em riscos, estes baseados em troca de estado, testes exploratórios e uma infinidade de outras técnicas que aprendemos com o passar dos anos no "fascinante mundo da engenharia de software" :)

Abraços.

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço