Qual é a estratégia de teste correta nas equipes do Agile Scrum / Kanban?

O problema é:

A equipe em que estou trabalhando tem uma proporção de 10 desenvolvedores para 2 testadores, o que significa que vamos produzir o código mais rapidamente do que o "Teste".

Então, qual deve ser a abordagem correta para rastrear atividades em tais cenários, de acordo com especialistas em agilidade?

Meu medo é que em breve chegue o dia, quando houver muitas coisas que serão chamadas de "Concluídas" em sprints anteriores (sem que os testes sejam realizados), mas quando se trata de testes, pode haver alguns defeitos em potencial.

Como posso acompanhar os esforços sem problemas? O teste deve fazer parte da "Definição Concluída"? Quais são as armadilhas se não for?

De acordo com mim, é uma espécie de 'Cachoeira', como você está chamando de histórias "Concluídas" antes de ser realmente testada funcionalmente.

Sim, o teste absolutamente deve fazer parte da definição de "Concluído". Sem dúvida.

Do ponto de vista puramente ágil, a abordagem correta é para que todos na equipe contribuam para escrever testes. O testador seria o responsável pela coordenação do esforço, mas é responsabilidade de toda a equipe garantir que o software seja testado corretamente.

Em primeiro lugar, uma proporção de 10: 2 é ruim. Por experiência, uma proporção de desenvolvedores 3: 1 ou 4: 1 para testadores funciona bem. Portanto, você provavelmente precisará de pelo menos mais um testador; caso contrário, o backlog de testes aumentará e nunca será limpo, ou você cortará os cantos em algum lugar.

Se você testar tarefas no próximo sprint, estará implementando uma mini cascata ou "scrumfall" à medida que separa o teste do desenvolvimento. Você está certo em que o teste absolutamente deve fazer parte da definição feita. Se uma tarefa não for testada, como ela pode ser declarada "concluída"?

A abordagem correta seria:

1. Adicione um testador à equipe, se possível, caso contrário, peça aos desenvolvedores que realizem alguns testes (embora eles provavelmente não façam um trabalho tão bom quanto um testador profissional).
2. Modifique sua placa scrum / kanban para incluir as colunas "pronto para teste" e "em teste" e concorde com a equipe que parte do fluxo de trabalho deve estar executando todas as tarefas por essas faixas.
3. As tarefas só chegam à coluna "Concluído" quando são aceitáveis ​​pelo teste.

Isso é bastante comum, se não típico. Para responder a várias perguntas:

• Qual deve ser a abordagem correta para rastrear atividades em tais cenários?
• Os recursos serão executados sem controle de qualidade, mas com defeitos?
• Como posso acompanhar os esforços sem problemas?
• O teste deve fazer parte da "Definição Concluída"?
• Quais são as armadilhas se não for?

Eu adotaria uma abordagem geral que:

• permite que os testadores agreguem valor
• lhes dá autoridade
• maximiza seu valor
• incentiva o pessoal de controle de qualidade a treinar desenvolvedores

e para fazer isso (e responder suas perguntas) eu:

• verifique se eles podem inserir bugs em um sistema de rastreamento de bugs fácil de usar, que também contém recursos como Jira, Trello, Pivotal Tracker, etc.

• verifique se eles são treinados na criação de bons relatórios de erros que descrevem:

  • Passos para reproduzir
  • valores iniciais / de configuração
  • valores inseridos
  • capturas de tela quando apropriado
  • logs do servidor quando apropriado
• verifique se eles vêem os erros serem atribuídos, trabalhados e concluídos.
• treiná-los nas melhores práticas e enviá-los para conferências.
• treiná-los em programação e usando uma estrutura de teste.
• permita que eles ensinem os programadores sobre boas abordagens e mentalidade para testes.

Além disso, sim, alguns recursos podem ser executados sem o controle de qualidade, mas com defeitos. Costumo achar que o controle de qualidade é um segundo par de olhos. Às vezes, essa função pode ser preenchida por outro desenvolvedor. Pessoalmente, acho que isso encontra alguns erros, mas nem todos que uma mentalidade de controle de qualidade diferente pode encontrar.

O teste deve fazer parte do processo, mas isso não significa que a pessoa do controle de qualidade precise fazer o teste. Dada a escassez de recursos e um ambiente ágil que evita as especificações que o controle de qualidade pode analisar, o controle de qualidade precisa estar envolvido com o aprendizado do domínio dos usuários, a criação de reuniões, as reuniões de preparação de pontos de vista, de pé, retrospectivas etc.

Quanto à grande questão da estratégia de teste, use os quadrantes de teste Agile para guiá-lo:

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

Os desenvolvedores já podem estar fazendo testes de unidade. Uma área importante que o controle de qualidade pode agregar valor ao cobrir está em Testes integrados e usando a automação da interface do usuário. Um bom teste exploratório também é muito valioso - não é apenas clicar em todos os links da página, é aprender o domínio do usuário final e o que o uso do aplicativo significa para eles.

Para a proporção de QA's e testadores, considere também o triângulo de teste:

    Exploratory
  Integrated Tests
Individual Unit Tests

em que um teste exploratório ou integrado pode representar dezenas, senão centenas, de testes de unidade, exercitando toda a 'pilha'.

Considere também que, como nas equipes Agile, geralmente deve haver uma abordagem de qualquer um que possa codificar, qualquer um que possa testar. A chave do curso é dar às pessoas a orientação e a estrutura para que eles possam fazer o que for necessário e treiná-las para a outra área.

Em termos da proporção real, discordo da precisão da resposta de David de 3: 1 ou 4: 1. Em algumas organizações em que os desenvolvedores estão escrevendo boas unidades e testes integrados, pode ser 7: 1 em uma organização com muito pouco testes feitos por desenvolvedores, isso pode precisar ser 1: 1 'depende' realmente da organização, estrutura, conhecimento, setor, etc., etc.

Quando começamos a construir nosso produto , também implementamos o Kanban e, juntamente com isso, implementamos uma estratégia completa de automação de teste. Como resultado, hoje não temos testadores em nossa equipe. Em vez disso, os desenvolvedores devem escrever casos de teste e automatizá-los como parte do trabalho em qualquer história, aprimoramento ou defeito do usuário. Nossa definição de Dev Complete inclui teste de unidade e automação funcional.

Ainda temos um estágio de "Validação" após a conclusão do desenvolvedor - onde todo o novo trabalho de desenvolvedor (recursos, correções de bugs) é implantado em um servidor intermediário e alguém - qualquer pessoa que tenha entendimento funcional do recurso - deve validá-lo. Utilizamos pessoas da nossa equipe de documentação, bem como do gerenciamento de produtos - e, às vezes, líderes / arquitetos Sr. Engg - para validar. Cada versão deve permanecer no mínimo 1 semana na preparação antes de ser implementada na produção.

Aqui está um instantâneo do nosso quadro Kanban -

O processo e o Kanban funcionaram para nós. Temos quase 100% de automação de teste, temos uma cadência de liberação de produção de 3-4 semanas e, o melhor de tudo, a maioria dos membros da equipe tem flexibilidade para trabalhar na maioria das partes do nosso produto!

Portanto, embora isso possa não atender aos seus objetivos de curto prazo, você pode definitivamente querer ver como pode reestruturar sua equipe a longo prazo e, se ainda não o tiver feito, analisar as estratégias de automação de teste que definitivamente ajudariam sua equipe a obter melhores resultados. qualidade em intervalos mais curtos.