Quem deve escrever o plano de teste?


10

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


11
A única entrada para isso que os desenvolvedores devem ter é sugerir áreas e possivelmente alguns casos extremos que devem ser testados (e não esquecidos). Mas eles não devem dar detalhes passo a passo sobre como exatamente testar.
CaffGeek

Respostas:


10

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.


Era isso que eu dizia há anos em um emprego.
David Thornley

11
Até a última frase, mas o teste nunca deve ficar apenas para verificar se o aplicativo segue as expectativas (mas também deve cobrir o inesperado!), E saber pelo menos um pouco sobre como o aplicativo foi tecnicamente projetado SEMPRE me ajuda como testador a identificar as rachaduras nas quais eu posso colocar o pé-de-cabra do testador para alavancar a coisa totalmente aberta. ;) É um pouco antiquado imaginar que os testadores são melhores sem saber nada sobre a implementação.
Testerab

11
Exatamente, @testerab. Não conhecer os internos ajuda a projetar alguns tipos de casos de teste, enquanto conhecer os internos ajuda nos testes de caixa cinza, por exemplo, conheço a área de risco no código, só preciso provar que o aplicativo alcança esse código.
dzieciou

7

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.


3
Possivelmente com a ajuda dos desenvolvedores, mas principalmente da equipe de controle de qualidade.
Zachary K

E se não tivermos uma equipe de controle de qualidade? Essa tarefa deve recair sobre os solicitantes? A partir das respostas aqui, isso seria mais lógico.
Ckng 17/02/11

Se você estiver migrando para o Agile, tente contratar algumas pessoas especializadas em testes para sua equipe de desenvolvimento atual. (Nota: ler sobre as diferentes escolas de testar primeiro, alguns não são compatíveis com uma abordagem Agile - redcanary.mypublicsquare.com/view/hiring-software )
testerab

2
Se você não possui uma equipe de controle de qualidade, precisará se reunir com os solicitantes para tomar essa decisão. Por um lado, os desenvolvedores não precisam fazer planos de teste. Por outro lado, muitos / a maioria dos clientes empresariais não sabem nada sobre testes, e você gastará MUITO TEMPO DE TREINAMENTO E MANUTENÇÃO DE MÃO no início. Tentamos isso uma vez e os clientes empresariais enfrentaram grandes dificuldades. Os casos regulares não eram um grande problema, mas quando se tratava de casos detalhados e, especialmente, casos de testes negativos, eles lutavam. Melhor seria obter / designar um responsável pelo controle de qualidade ou um analista de negócios do que atribuir aos clientes.
sdek

4

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.


2

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.


2

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).


Ótima resposta, ótima maneira de tirar os desenvolvedores da monotonia sem graça e obter feedback dos clientes. E ótimos links.
Ethel Evans

1

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.


1

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.


en.wikipedia.org/wiki/… para mais informações.
Ethel Evans

+1 para indicar que os testes de aceitação do usuário precisam ser projetados pelo usuário. Embora eu tenha sugerido uma abordagem alternativa na minha resposta (como não parece que eles realmente tenham algum recurso de controle de qualidade), o teste de aceitação do usuário não pode ser realizado de maneira eficaz por não usuários. Nessa situação, parece que tanto o desenvolvedor quanto o usuário estão um pouco impassíveis, então acho que o desenvolvedor precisa tentar quebrar isso de alguma forma.
Testerab
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.