| Version 9 (modified by cesar.vianna, 14 years ago) (diff) |
|---|
Conteúdo
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 processo adotado para o Centro de Testes é baseado no Demoiselle Process, com algumas alterações pertinentes às características do Projeto Expresso. A partir dessa experiência pretende-se estabelecer um processo de testes adequado ao desenvolvimento de sistemas livres em comunidade.
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]"
A elaboração da User Story é produzida na elicitação de requisitos. Após, os requisitos serão analisados iterativamente, produzindo Casos de Testes. Essa é uma mudança de paradigma em relação aos processos formais de desenvolvimento. Escolhe-se o Caso de Teste como documento mínimo de requisito, demonstrando um direcionado a testes desde a fase de concepção do projeto. Mais informações sobre essa prática podem ser verificadas na Tarefa Elicitar e Analisar Requisitos Principais do Demoisele Process.
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. Deve expressar de forma sucinta o objetivo da funcionalidade, sem a necessidade de detalhamento. Durante o desenvolvimento, serve como base e um ponto de partida para discussões mais detalhadas com o cliente sobre suas necessidades.
Já um caso de uso, é bem mais complexo 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. As Users Stories podem ser complementadas usando casos de uso para documentar os caminhos alternativos e de exceção, quando necessário. Contudo, o artefato de requisito será o Caso de Teste, como será descrito abaixo.
Para começar esse trabalho, vamos estar documentando o módulo de contatos Contact Center, pois esse é um módulo relativamente pequeno em relação ao número de funcionalidades. A ideia é usar esse módulo como um piloto para que possamos avaliar se a estratégia adotada é correta.
Tarefas e Artefatos
A disciplina de testes atuará diretamente em três tarefas: Planejar Testes, Projetar Testes e Executar Testes
O Planejamento dos Testes tem como objetivo a identificação dos itens e funcionalidades que deverão ser testados, quem são os responsáveis e quais os riscos envolvidos. Ou seja, permite definir o escopo, o custo e o prazo para as atividades de teste do projeto. Para isso, recebe como entrada os Casos de Testes das funcionalidades e gera o Plano de Testes.
O Projeto de Teste visa definir as condições necessárias para a realização dos testes em um contexto específico, identificando pontos de observação e de controle. Essas informações devem ser registradas nos casos de testes. Sendo assim, nesta atividade são projetados e elaborados os casos de testes e os roteiros de testes automáticos a serem utilizados para o desenvolvimento da funcionalidade.
Por fim, devem ser executados os testes, bem como deve ser avaliada a cobertura do código por estes testes.
Referências
Última atualização: 06-Mai-2010
