wiki:ExpressoTestCenter/processo

Version 3 (modified by luiz-fernando, 14 years ago) (diff)

--

Processo de testes

Introdução

Essa seção tem por objetivo definir um processo para criação e manutenção dos casos de teste do ExpressoTestCenter. Antes de definir casos de teste, temos que ter os requisitos funcionais documentos. Portanto, abordaremos aqui também uma forma para definir esses requisitos. Para quem não está habituado aos termos: metodologias ágeis, casos de uso, User Story e processos de teste, sugiro uma leitura prévia nos assuntos de forma a facilitar a compreensão desse tópico. Foi colocado no final dessa seção links para quem quiser se aventurar nesses tópicos.

O Problema

O grande problema atual do Expresso é a falta de documentação de suas funcionalidades. Sem requisitos funcionais, a tarefa de criar casos de testes se torna bastante complicada. Como o usuário vai testar alguma coisa sem saber como essa coisa funciona!?

Meotodologias Ágeis

Com o intuito de agilizar a criação da documentação do Expresso, a técnica de desenvolvimento ágil User Stories pode ser empregada. User Stories é um modo simples de capturar os requisitos de uma aplicação, sendo uma alternativa a escrita de imensas especificações de requisitos utilizada nas tradicionais metodologias de desenvolvimento.

Uma User Story é uma frase simples especificando o que o usuário quer fazer com uma funcionalidade da aplicação, escrita a partir da perspectiva do próprio usuário, não devendo portanto utilizar jargões técnicos nem especificar detalhes de projeto. Ela deve ser escrita na linguagem do usuário de forma que todos possam compreender.

A User Story deve focar no quem, no o que e no porquê de uma funcionalidade, e não no como. Um modo simples de escrever uma User Story é seguir o padrão abaixo:

Eu, como <papel do usuário>, quero poder <objetivo>, de forma que <razão>.

Um exemplo para o requisito funcional de compartilhamento de contatos seria: "Eu, como [Usuário], quero poder [compartilhar meus contatos], de forma que outros Usuários [possam ler, editar e excluir meus contatos]"

User Story vs Caso de Uso

Alguém pode estar se perguntando: Mas e os casos de uso não é a técnica mais utilizada para especificação de requisitos? Nesse primeiro momento da criação da documentação do Expresso, a utilização dos casos de uso tornaria o processo bastante complexo. Vejamos o porquê.

Uma User Story é bastante simples e escrita pelo cliente. É incompleta, possivelmente não precisa, e não trata casos de exceção. Durante o desenvolvimento, serve como um lembrete e um ponto de partida para discussões adicionais com o cliente sobre suas necessidades com maiores detalhes.

Já um caso de uso, é bem mais completo e é escrito pelo analista de requisitos junto com o cliente. É uma tentativa de ser completo, preciso, e trata todos os possíveis casos. Muito esforço é desprendido para garantir que está correto, ao ponto de um desenvolvedor não necessitar contactar o cliente para sanar qualquer dúvida sobre os requisitos.

Então, para termos um ponto de partida para essa difícil tarefa de documentar todos os requisitos do Expresso, vamos estar usando Users Stories. Lembrando que vamos estar levantando as funcionalidades previamente existentes, portanto, não faz sentido usá-las para estimativa e planejamento do projeto. Mas quem vai escrevê-las? Quem é o cliente do Expresso? O cliente, nesse caso, seria a própria comunidade Expressolivre.org, pois todas as requisições de novas funcionalidades chegam através dela. A equipe do ExpressoTestCenter estará escrevendo as Users Stories com o intuito de levantar todas as funcionalidades atualmente disponíveis na versão 2.0 do Expresso. Logo após esse trabalho, poderemos passar a detalhar mais as Users Stories usando casos de uso para documentar os caminhos alternativos e de exceção. Finalmente poderemos, a partir dos casos de uso, derivar os cenários de teste, bem como os casos de teste para as funcionalidades do Expresso.

Para começar esse trabalho, vamos estar documentando o módulo de contatos (ContactCenter?), pois esse é o módulo relativamente pequeno em número de funcionalidades. A ideia é usar o ContactCenter? como um piloto para que possamos avaliar se a estratégia adotada é correta.

Referências

<a ser adicionado>


Última atualização: 06-Mai-2010