Quem deve escrever o plano de teste?

Faço parte da equipe interna de desenvolvimento da minha empresa e desenvolvemos os sites da empresa de acordo com os requisitos da equipe de marketing. Antes de liberar o site para eles para teste de aceitação, fomos solicitados a fornecer um plano de teste a seguir.

No entanto, a equipe de desenvolvimento considera que, uma vez que os requisitos vieram dos solicitantes, eles teriam o melhor conhecimento sobre o que testar, o que procurar, como as coisas devem se comportar etc., e, portanto, um plano de teste não é necessário. Estamos sempre discutindo sobre isso, e os desenvolvedores acham uma perda de tempo escrever coisas como:

1. Clique no botão A .
2. Chave na XYZ no campo de formulário e clique o botão B .
3. Você deverá ver o comportamento C .

que precisamos repetir para cada requisito / recurso solicitado. Isso basicamente reformula o que já está no documento de requisitos.

Estamos avançando no uso de uma abordagem ágil para gerenciar nossos projetos, e isso também é solicitado no final de cada iteração.

Testes de unidade e integração à parte, quem deve apresentar o plano de teste de aceitação do usuário final? Devem ser os solicitantes ou os desenvolvedores?

Muito obrigado antecipadamente.

Atenciosamente
CK

O plano de teste NÃO deve ser elaborado pelos desenvolvedores. Parte do que o plano de teste deve fazer é verificar se o desenvolvedor interpretou corretamente o requisito. Um desenvolvedor não pode efetivamente escrever um plano de teste no código que ele irá escrever. Os planos de teste devem ser escritos pelas pessoas que farão o controle de qualidade ou pelos analistas de negócios. Se os desenvolvedores precisarem escrever os planos, nunca designe alguém para escrever o plano para a parte do programa que ele irá escrever.

Observe que isso é diferente de projetar testes de unidade que devem ser escritos pelo desenvolvedor, pois ele deve testar o código que ele escreveu para ver se ele faz o que ele está esperando. Mas os planos de teste são testar para ver se o aplicativo funciona da maneira que se esperava que funcione e isso deve ser feito por alguém que não sabe como o aplicativo foi tecnicamente projetado para funcionar para ser eficaz.

A equipe de controle de qualidade deve escrever e executar o plano de teste.

Idealmente, o plano de teste deve ser escrito em paralelo com a especificação funcional - é incrível como pensar em como testar a funcionalidade concentra a mente e melhora a especificação.

Uma resposta do Scrum: Se você deseja definir a 'Definição de Concluído', notará que ter um plano de teste rapidamente se torna um dos itens. De que outra forma você pode descrever a história a ser feita, se ainda não foi testada.

Quem é então responsável pela criação do plano de teste? O time

Quem é a equipe? Qualquer pessoa comprometida com a realização do produto deve ser um membro da Equipe.

Portanto, no seu caso, você pode incluir (ou contratar) a pessoa que pode escrever os planos de teste em sua 'equipe de desenvolvimento'. Se você estiver mudando para o Agile, notará que a criação de um plano de teste ocorre paralelamente ao desenvolvimento. Ambos começam na mesma história e, através da comunicação, acabam sincronizados e entregues ao mesmo tempo. Você não deve declarar sua história como "concluída" antes de passar nos casos de teste que as Partes Interessadas consideram críticas.

Acho que os planos de teste funcional devem ser escritos por analistas funcionais / de negócios. Eles escrevem a análise funcional (mesmo que você esteja trabalhando com agilidade, suponho que você tenha alguma análise) e, portanto, devem escrever quais caminhos no aplicativo devem ser seguidos para fins de teste.

Depende totalmente de como você está trabalhando, mas, na minha opinião, os desenvolvedores não devem escrever documentos funcionais sobre como testar o aplicativo, quais dados usar para testá-lo etc.

Aqui está uma idéia que pode alegrar os dois grupos e se encaixar bem na mudança para uma abordagem ágil:

Automatize suas verificações de aceitação do usuário e as faça screencast.

http://pragprog.com/magazines/2009-12/automating-screencasts

Parece que parte do problema que você está tendo é que os planos de teste que você está escrevendo são muito repetitivos e puramente confirmatórios. Para ser sincero, eu não chamaria o que você está escrevendo de teste - se está apenas confirmando os requisitos, está verificando . Automatizar e fazer screencasting permitirá que você empacote regularmente uma demonstração interessante para seus clientes (você pode até enviá-la diariamente) - é mais provável que eles cliquem em uma demonstração e assistam a ela do que abrir um plano de teste e comece a trabalhar com isso. Espero ter um feedback mais rápido (muito importante se você estiver adotando uma abordagem mais ágil). Você poderá reutilizar componentes para reduzir a carga de trabalho para você,

Ele também fornece uma maneira de realmente executar os requisitos - você encontrou as especificações executáveis ​​do Gojko Adzic? Dê uma olhada aqui: http://gojko.net/2010/08/04/lets-change-the-tune/ Se você está pensando nisso como uma maneira de obter os requisitos em um formulário executável para demonstrar aos seus clientes , de repente parece muito menos inútil.

Agora, colocando meu chapéu de testador, tenho a honra de ressaltar que, se a coisa do screencast decolar, isso liberará você / suas partes interessadas para fazer alguns testes adequados - por exemplo, tentar casos extremos e testes que realmente desafiam o aplicativo , em vez de apenas confirmar requisitos. Sugiro que você forneça os screencasts, além de perguntas ou sugestões curtas para as áreas nas quais deseja obter mais feedback, por exemplo:

1) Aqui está o nosso novo formulário de inscrição - assista a este screencast para ver como funciona!

Sobre o que gostaríamos de receber feedback: adicionamos muitas verificações extras neste formulário para garantir que os clientes não consigam inserir os dados incorretos. Gostaríamos muito que você observasse as mensagens de erro que os clientes recebem quando coloque a coisa errada e diga-nos se nossos clientes as acharão fáceis de entender.
Também gostaríamos de saber se temos sido muito rigorosos em alguns casos - se você possui dados de clientes particularmente incomuns (talvez um nome muito longo ou muito curto ou alguém com caracteres incomuns em seu nome, ou qualquer outra coisa em que não pensamos, ou talvez o endereço deles não tenha um nome de rua ou algo estranho como esse?), então talvez você possa passar alguns minutos experimentando-os?

Ou seja, você apresenta um bom screencast e, em seguida, pede feedback, enquadrando-o sem ser muito específico, faça-os pensar em possíveis problemas em vez de apenas confirmar. Faça-os pensar , em vez de apenas clicar cegamente em um plano de teste. Você está basicamente escrevendo uma carta de teste exploratória para eles. (Se você olhar para os quadrantes de testes ágeis , seriam testes no quadrante 3).

Tome a reforma de sua casa como um exemplo. Você aceitaria uma lista de verificação elaborada pelo contratado, solicitando que você marque o que ele fez por você? Ou você faria sua própria lista de verificação e verificaria se o contratante fez o que VOCÊ especificou?

A resposta é clara: o solicitante deve verificar se o que ele / ela solicitou é feito de acordo com as especificações. Ele / ela deve elaborar sua própria lista de verificação e testar o aplicativo. contra esta lista.

O desenvolvedor, no entanto, deve ter sua própria lista de verificação e garantir a realização de testes internos adequados e a eliminação de erros antes de manipular o aplicativo. para o UAT. Idealmente, o desenvolvedor deve automatizar a maioria desses testes na forma de scripts de teste. Lembra do TDD? Idealmente, scripts de teste (nesse caso, casos de teste de unidade) devem ser escritos para testar componentes de aplicativos. O conjunto de testes deve ser escrito para combinar esses casos de teste de unidade para executar testes de regressão integrados e subsequentemente.

O plano de teste de aceitação do usuário final geralmente é elaborado pelos clientes ou por um parceiro de negócios da empresa que representa o cliente. Ele deve representar os recursos que o cliente deseja e complementa o teste de integração do controle de qualidade. Nem o controle de qualidade nem o desenvolvimento podem planejar efetivamente os testes de aceitação do usuário, pois um dos principais objetivos dos testes de aceitação do usuário é garantir que o que o controle de qualidade e o desenvolvimento acham que o cliente deseja seja realmente preciso.