Changes between Version 8 and Version 9 of ExpressoTestCenter/processo

Timestamp:

09/17/10 11:00:15 (14 years ago)

Author:

cesar.vianna

Comment:

--

ExpressoTestCenter/processo

@@ -5 +5 @@
 == 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 ==
@@ -20 +22 @@
 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'''''. É 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.
+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 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.
+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. 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.
+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 ==