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