= Processo de testes = [[PageOutline(1-3, Conteúdo)]] == 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 [http://demoiselle.sourceforge.net/process/ 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 '''''', quero poder '''''', de forma que ''''''. 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 [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/workproducts/casoDeTeste_24F453B9.html 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 [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/capabilitypatterns/elicitarAnalisarRequisitosPrincipais_B80D420A.html?proc=_LU5c0RJ4Ed-8yYY0KoE9bg&path=_LU5c0RJ4Ed-8yYY0KoE9bg,_VZH60BJ4Ed-8yYY0KoE9bg,_lFEloCB2Ed-FxtM0rIDhSg&nodeId=9391b348 Tarefa Elicitar e Analisar Requisitos Principais] do [http://demoiselle.sourceforge.net/process 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 [wiki:contactcenter 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: [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/tasks/planejarTestes_48FB42D9.html?proc=_LU5c0RJ4Ed-8yYY0KoE9bg&path=_LU5c0RJ4Ed-8yYY0KoE9bg,_joIXMRJ4Ed-8yYY0KoE9bg,_AEdR8BGJEd-sBcwSDLV5Ew Planejar Testes], [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/capabilitypatterns/projetarTestes_BE0F3D68.html?proc=_LU5c0RJ4Ed-8yYY0KoE9bg&path=_LU5c0RJ4Ed-8yYY0KoE9bg,_joIXMRJ4Ed-8yYY0KoE9bg,_BygLsCB9Ed-FxtM0rIDhSg&nodeId=4099442a Projetar Testes] e [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/capabilitypatterns/executarTestes_2B63EEDA.html?proc=_LU5c0RJ4Ed-8yYY0KoE9bg&path=_LU5c0RJ4Ed-8yYY0KoE9bg,_l4yLMRJ4Ed-8yYY0KoE9bg,_KEz4wSCAEd-FxtM0rIDhSg,_TcWP4CCAEd-FxtM0rIDhSg&nodeId=4140ec6e 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 [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/workproducts/casoDeTeste_24F453B9.html Casos de Testes] das funcionalidades e gera o [http://demoiselle.sourceforge.net/process/1.2.1-BETA1/ProcessoDemoisellePlugin/workproducts/planoDeTeste_D3635ED4.html 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 == * [http://agilemanifesto.org/ Agile Manifesto] * [http://www.agilemodeling.com/ Práticas de modelagem ágil] * [http://www.agilealliance.org/ Artigos sobre metodologias ágeis] ---- ''Última atualização: 17-Set-2010''