Revisão por pares para testes, assim como revisões de código

Alguém pratica o processo de "revisão de código" para testes funcionais? Você acha útil? Da maneira como meu atual empregador pratica o SCRUM, incluímos testes funcionais como parte do nosso material "deve ter feito" em qualquer sprint.

Também praticamos SCRUM. E da mesma forma que você, também incluímos testes funcionais como parte de nossa definição.

Pela minha experiência, acho incrivelmente útil. Reduzimos significativamente o número de bugs em nosso código simplesmente forçando o teste funcional.

Uma segunda coisa interessante sobre a revisão de código é que ela oferece outra visão sobre a funcionalidade real e garante 100% de que está alinhada com o que o cliente queria. Houve algumas vezes em que alguém estava revisando o código e a funcionalidade em que a pessoa foi ... "Espere, isso não está certo ..." e descobriu-se que a pessoa que implementava o código apenas entendeu algo errado.

Meu Deus, sim (tento não usar palavrões no SO; p). A revisão por pares de seus testes funcionais é basicamente a revisão por pares de seus requisitos e análises, é incrivelmente importante e, se você usar uma linguagem BDD como pepino, poderá envolver também não programadores!

É incrível quando nossos usuários finais detectam problemas com nossos testes funcionais e isso faz com que eles se sintam imensamente parte do processo de desenvolvimento "Eu também posso ler código!"

Faz todo o sentido para mim. Qualquer código que você escrever deve ser analisado por outra pessoa, mesmo que o código seja usado apenas internamente e nunca seja executado pelo cliente.

Com as metodologias que colocam tanto peso nos testes, a revisão dos testes se torna muito mais importante, possivelmente necessária, às vezes mais importante que a revisão do código em si, pois geralmente se presume que ele pode ser substituído por qualquer código que atenda ao mesmo código automatizado. resultado do teste.

Revisar que os testes estão corretos é um aspecto, que eles são completos o suficiente e precisos / representativos também são muito importantes.

Perder esse ponto é uma das coisas que faz com que essas metodologias pareçam desleixadas para revisores externos.

Você pode fazer inspeções em pares!

As inspeções de pares são:

Uma revisão de documentos de forma ativa e informal, como parte do ciclo de criação e produção de documentos.

As razões pelas quais isso funciona bem com o teste são:

1. Você pode inspecionar requisitos ou documentos com mais de um par de olhos.
2. Você pode envolver mais do que apenas desenvolvedores: experimente o BA com Test Lead, BA com PM, BA com Dev.
3. Você pode definir reuniões de re-cura como parte de um processo ágil - certifique-se de ser sério com compromissos sólidos dos membros da equipe.
4. Você pode usar essas inspeções de pares como parte de um exercício de construção de relacionamento e de comunicação com seus stakeholders. Comece a conversa!

Testamos testes funcionais de revisão por pares pelo menos casualmente, e é altamente recomendável em nossa organização que tudo seja revisado em código.

Eu recomendaria escolher seu revisor com base em suas metas para a revisão. Os testes codificados podem ser melhor revisados ​​por um desenvolvedor (principalmente para a qualidade do código) e outro testador (principalmente para a cobertura do teste). Testes sem código (usando um chicote, por exemplo, testes controlados por dados) podem ser melhor revisados ​​apenas por outro testador. As revisões por pares também são uma ótima maneira de incentivar os testadores a aprender um com o outro.