Por que o guia Scrum diz que não há testadores?

Eu tenho lido o Guia Scrum em scrum.org e ele diz:

As equipes de desenvolvimento não contêm subequipes dedicadas a domínios específicos, como teste ou análise de negócios.

Na sua tradução literal, isso significa que não há testadores que sejam confusos. Como eles podem estar sugerindo isso?

Isso significa que:

1. Os testadores são integrados às ferramentas de desenvolvimento da equipe de desenvolvimento para ajudar os desenvolvedores a testar e testar.

   ou:

2. A equipe pratica o desenvolvimento orientado a testes - ou seja, eles escrevem testes automatizados que exercitam o sistema.

Qualquer um desses meios significa que não há necessidade de uma equipe de teste separada.

Na sua tradução literal, isso significa que não há testadores que sejam confusos ... Como eles podem sugerir isso?

Sim, é exatamente isso que eles sugerem. Em outras palavras - os desenvolvedores são os testadores e os testadores são os desenvolvedores.

A idéia é promover a propriedade e a qualidade do código .

Isso não significa que o código não foi testado, mas que as pessoas envolvidas na redação são as pessoas envolvidas no teste - não há separação de responsabilidades.

O problema que essa abordagem está tentando resolver é a separação muito comum entre desenvolvedores e testadores, na qual os desenvolvedores escrevem código e "jogam por cima do muro" para a outra equipe e depois vão e voltam, atrasando o projeto e produzindo software sub-padrão.

A parte fundamental disso é que a responsabilidade do codificador é criar um código que funcione e atenda ao requisito. Isso requer uma mentalidade específica - "O código que estou escrevendo faz o que é suposto".

Misturar as responsabilidades do codificador significa que agora é necessário que o codificador entre em outras mentalidades para outras atividades; no entanto, como codificador, é difícil para alguém se divorciar completamente dessa mentalidade.

A responsabilidade do testador é encontrar bugs e locais onde a funcionalidade diverge da funcionalidade necessária. Isso exigia a mentalidade de "O código está quebrado e vou descobrir como".

Da mesma forma, um analista de negócios está tentando identificar os requisitos que o cliente realmente está solicitando. Isso requer outra mentalidade de "o aplicativo não funciona dessa maneira, mas deveria".

Para um codificador trabalhar em qualquer uma dessas outras capacidades, existe uma probabilidade razoável de que as mentalidades entrem em conflito e que o codificador execute sub-par:

• Codificador / controle de qualidade - "O código funciona perfeitamente, e eu já codifiquei para lidar com todas as maneiras possíveis que eu possa imaginar que possam quebrá-lo".
• Coder / BA - "O código deve funcionar da maneira que eu quero e isso seria algo interessante a acrescentar, que o cliente não pensou.

Isso não quer dizer que todo codificador seja suscetível a esses problemas (eu encontrei alguns tipos muito talentosos de codificador / controle de qualidade ... embora não seja o código que eles escreveram).

Isso também se estende à equipe de desenvolvimento. A mistura de responsabilidades e mentalidades associadas dessas responsabilidades para uma equipe de desenvolvimento compromete o produto final (o código).

Ele diz que não há sub -team dedicado a testar. Isso não significa que não há testes realizados. Isso significa apenas que os membros da equipe farão seus próprios testes e frequentemente testarão o código / recursos de outras pessoas. Não estou familiarizado com a metodologia scrum, mas irei direto ao assunto e digo que o cliente também pode estar envolvido nos testes.

Acho que isso significa, em parte, que você deve escrever testes para seu próprio código, para que você saiba que funciona (caso contrário, você realmente não o terminou) e em parte para que você possa ser um testador do código de outras pessoas às vezes .

Em vez de permitir que as pessoas descarregem o trabalho de qualidade de software para outra pessoa e o ignorem, isso força todos a pensar no código que estão escrevendo a partir de uma perspectiva de qualidade o tempo todo, por isso é uma boa idéia.

Esta afirmação está basicamente tentando evitar o trabalho em silos. Uma parte da solução para isso são práticas como - Desenvolvimento Orientado a Testes - Programação em Pares - Solicitações Pull - Automação de testes e afins, que tornam o teste uma parte intrínseca do processo de desenvolvimento, em vez de algo que é feito isoladamente, tanto de lado quanto de lado. 'depois de'.

Além disso, há muito poucas conversas sobre papéis no Guia Scrum. Na verdade, eles falam sobre a equipe de desenvolvimento. O que eles querem dizer é que você quer uma equipe multifuncional forte. Isso significa que, dependendo do que seus projetos precisam, você precisa de uma série de habilidades, como UX, BA, QA / Tester, Ops, Coder, etc, etc.

As equipes com as quais trabalho certamente têm o controle de qualidade, pois temos o pessoal do DevOps. Mas todos eles também são Devs, apenas com especialização nessas áreas. O truque é realmente não cair em silos e trabalhar isoladamente.

Isso não significa necessariamente que não há testadores. Pode ser que uma equipe do Scrum tenha testadores dedicados ou não.

Para mim, o que essa afirmação sobre Scrum significa é que você deve pensar em todo o pipeline de entrega como uma única equipe. Fazer parte da mesma equipe sugere algumas coisas:

1. Há uma única estimativa em uma história / bug / tarefa. Não há uma estimativa de desenvolvimento e uma estimativa de teste.
2. A equipe não estima uma história e se compromete com ela sem o testador presente.
3. Se algo der errado, não é mais culpa do testador do que culpa do desenvolvedor. A culpa é da equipe .
4. A equipe nunca precisa pedir emprestado, solicitar ou solicitar testadores.
5. O teste faz parte da definição de concluído. Trabalho não testado é trabalho incompleto.
6. Os desenvolvedores devem considerar a testabilidade ao criar seu código.

Se eles estão trabalhando juntos em uma única equipe, a equipe consegue e falha juntos. Eu estive em uma equipe Scrum de muito sucesso, que teve vários testadores. Os testadores estavam presentes em todas as etapas, sessões de preparação, planejamento etc. Se não estivesse claro como testar uma história, a equipe não se comprometeria. Sempre conversamos com nossos testadores ao fazer estimativas.

Sinais em potencial de que você não pode realmente tratar os testadores como parte da equipe de entrega, mesmo que pense que sim:

1. Os testadores têm um "controle de qualidade" (sim, eu já vi).
2. Os testadores têm uma estrutura de gerenciamento separada.
3. Você tem um lead de controle de qualidade.
4. Você depende muito de testes de ponta a ponta.
5. Os testes são escritos no seguinte sprint.
6. A maioria dos testes ocorre no último dia do sprint.

Estes são subjetivos e não necessariamente errados. Eles são bandeiras vermelhas, porém, na minha opinião.

Tudo isso dito, é perfeitamente possível ter uma equipe Scrum sem alguém que tenha um papel designado de testador. Isso pode funcionar bem também. Especialmente se você automatizar os testes. TDD também ajuda.