Se estiver executando um projeto usando BDD com 100% de cobertura de histórias de usuários com testes de aceitação automatizados, qual seria o papel de um testador / responsável pela garantia da qualidade?
Acho que estou imaginando que os desenvolvedores escreveriam os testes de aceitação em conjunto com o proprietário do produto, deixe-me saber se isso parece uma suposição tola.
Respostas:
Talvez eu seja antiquado demais, mas mesmo as técnicas mais modernas de desenvolvimento ou processo não podem substituir outro conjunto de olhos, olhos novos, antes de liberar um produto para o seu cliente.
Mesmo que seu produto seja simplesmente uma API para outro desenvolvedor, você pode usar o controle de qualidade para pensar como usuário da API, fornecendo cenários de teste / uso que você ou seu cliente não pensaram com antecedência.
Se o seu produto é pesado com base na interface do usuário, definitivamente você quer outra pessoa (que não seja você ou alguém da sua equipe) olhando para o resultado final antes de enviá-lo ao cliente.
Como qualquer outra palavra da moda em nosso setor, o BDD - mesmo com 100% de cobertura - não é uma bala de prata .
100% de cobertura não é o mesmo que 100% testado.
Eu veria uma pessoa de controle de qualidade em um projeto ATDD como alguém que ajudaria a escrever os testes e executar os outros tipos de testes que ainda existem. Ou seja, testes de interface do usuário, testes de destruição e testes de carga / estresse.
Mas nunca trabalhei em um projeto ATDD.
O trabalho do controle de qualidade é interromper o aplicativo, o trabalho dos desenvolvedores é não quebrá-lo. Portanto, eles escrevem seus testes de uma perspectiva diferente. Por exemplo, os desenvolvedores escrevem testes para ver se o comportamento esperado acontece, o controle de qualidade escreve testes para ver o que acontece quando os usuários fazem algo que o desenvolvedor nunca consideraria que o usuário faria. Além disso, os desenvolvedores geralmente interpretam mal os requisitos e os testes de controle de qualidade são detectados quando a interpretação deles é diferente do que o desenvolvedor pensou que isso significava e depois se reúnem com as partes interessadas no projeto para determinar qual é a interpretação correta. Testes escritos por desenvolvedores que escreveram o código geralmente têm grandes pontos cegos porque o desenvolvedor tinha um grande ponto cego. Por exemplo, ele pode testar o que acontece 97% do tempo, mas não os casos extremos.
Em um empregador anterior, o papel do controle de qualidade era não testar o produto, mas garantir que os desenvolvedores essencialmente fizessem o que disseram que iriam fazer com relação aos testes de aceitação definidos anteriormente, definidos pelo controle de qualidade.
O proprietário do produto, por outro lado, não tinha absolutamente nada a ver com o teste. Lidar com testes em qualquer nível IMHO não é o papel do proprietário do produto.
Em algum momento você precisa ter confiança em seus funcionários; as verificações e os saldos são bons, mas você não deve forçar uma solução dentro do ciclo de desenvolvimento que, na realidade, é tratar apenas de um pequeno subconjunto da ética do trabalho dos funcionários.
Em um mundo perfeito, vejo a colaboração com o desenvolvedor e o controle de qualidade formalizada com a escrita dos testes de aceitação de maneira conjunta. O controle de qualidade deve trazer um aspecto diferente para a tabela, assim como a equipe de desenvolvimento. O controle de qualidade deve ter a mão na torta no início do produto e permanecer engajado durante todo o ciclo. O proprietário do produto, por outro lado, deve contratar controle de qualidade para entender qual é o estado atual do produto, riscos, etc ... e se concentrar no produto de maneira holística; não as nuances específicas que compõem o produto.
Da minha experiência: estávamos usando o teste de unidade para cobrir mais de 90% do código. Também houve testes de integração e compilações a cada hora. jBehave testes para BDD.
Função de controle de qualidade: - adoção de histórias de usuário para teste - gravação de código por trás das etapas - teste de exploração usando o plug-in RestClient para IDEA (portanto, encontramos alguns bugs principais)
Parte do BDD está aplicando a abordagem dos 3 Amigos, na qual as partes interessadas colaboram para produzir os critérios de aceitação. O controle de qualidade / desenvolvedor pode escrever o código da etapa para fazer com que os cenários sejam executados como testes de aceitação. Onde está o valor do controle de qualidade para executar manualmente os mesmos testes de aceitação que uma ferramenta BDD executará automaticamente? O valor agregado do controle de qualidade é validar esses testes de aceitação e executar testes exploratórios manuais fora dos testes de aceitação com script. A duplicação geralmente produzirá o mesmo resultado.
Os desenvolvedores não reescrevem requisitos e especificações, o controle de qualidade não reescreve o código do aplicativo ... é possível que o controle de qualidade não precise executar os mesmos testes com script que os desenvolvedores executam como testes de aceitação. É hora dos desenvolvedores usarem um pouco do chapéu de controle de qualidade!