Viabilidade de uma equipe de desenvolvimento sem função * testadora * dedicada [fechada]

Ultimamente, tenho pensado muito em como criar uma equipe de desenvolvimento enxuta. Por fim, gostaria de abrir minha própria pequena casa de software com um pequeno número de pessoas que pensam da mesma forma. O objetivo não será ficar rico, mas ter um ambiente de trabalho saudável.

Até agora, estou definindo uma equipe enxuta da seguinte forma:

• Pequeno;
• Auto-organização;
• Todos os membros devem ter o controle de qualidade em mente;
• Os membros devem ser capazes de desempenhar várias funções

O último ponto é onde estou um pouco preocupado, porque, como o mantra diz ...

Os desenvolvedores fazem testadores ruins.

Embora compreenda que, muitas vezes, os desenvolvedores estão "muito perto" de seu código ou o código do seu colega para fazer avaliações de alto nível de qualidade, não estou convencido de que eles são de-facto testadores ruins. Pelo contrário, sou da opinião de que as qualidades de um bom desenvolvedor se sobrepõem muito às qualidades de um bom testador.

Supondo que isso esteja correto, estive pensando em diferentes maneiras de solucionar o problema do desenvolvedor / testador e acredito que criei um modelo viável.

Meu modelo requer:

• Uma pequena casa de software com mais de 2 projetos
• Uma abordagem ágil (iterativa) para desenvolvimento e entrega
• 1 equipe por projeto
• Todos os membros da equipe serão desenvolvedores de software
  • A descrição de suas funções indicará claramente Desenvolvimento , Garantia da Qualidade , Testes e Entrega como responsabilidades

Se todas essas pré-condições forem atendidas, os projetos poderão ser organizados da seguinte maneira (este exemplo se referirá a dois projetos, A e B ):

• Cada membro da equipe alterna entre a função de desenvolvedor e a função de testador
• Se um membro da equipe for um desenvolvedor no projeto A , ele será um testador no projeto B
  • Os membros irão trabalhar em apenas 1 projeto de cada vez e, portanto, são esperados para estar agindo como qualquer um Dev ou um Tester.
• Um Ciclo de Função consiste em 3 iterações como Dev e 2 iterações como Testador (novamente, em dois projetos diferentes)
• As equipes do projeto teriam 3 desenvolvedores e 2 testadores o tempo todo.
• Os ciclos de função de membro devem estar fora de fase por 1 iteração.
  • Isso minimiza a brusquidão das mudanças da equipe. Para cada iteração, 2 Devs e 1 Tester permanecerão os mesmos da iteração anterior.

Dado o exposto, vejo os seguintes prós e contras:

Prós

• Distribui o conhecimento do projeto por toda a empresa.
• Garante que os membros da equipe não estejam testando o código que ajudaram a escrever.
• Ciclos de funções fora de fase significam que nenhum projeto possui uma troca de 100% de membros.
• Papéis alternados quebram a monotonia de projetos chatos.

Contras

• As iterações de ambos os projetos estão fortemente acopladas. Se um projeto cancelar uma iteração no meio do caminho e iniciar novamente, os dois projetos ficarão fora de sincronia. Isso dificultaria o gerenciamento do ciclo de funções.
• A contratação de desenvolvedores também funciona como testadores.

Recebi críticas mistas ao discutir essa abordagem com amigos e colegas. Alguns acreditam que poucos desenvolvedores desejam alternar papéis como esse, enquanto outros me dizem que pessoalmente gostariam de experimentar.

Então, minha pergunta é: esse modelo poderia funcionar na prática? Caso contrário, poderia ser ajustado em um modelo de trabalho?

Nota: Por uma questão de brevidade, concentrei-me apenas nos papéis de Dev e Tester. Expandirei outras funções, se necessário.

Eu não concordo

Os desenvolvedores fazem testes ruins

A maioria das equipes em que trabalhei na minha carreira não teve nenhum suporte de controle de qualidade. Isso inclui duas grandes corporações globais que envolvem produtos como o sistema global de login e registro. Em outro caso, eu tinha 30% da receita da empresa passando por uma caixa na minha mesa. (Essas práticas não são recomendadas BTW;)) Essas empresas confiavam nos engenheiros para garantir que seu código funcionasse corretamente. E nós, sendo detalhistas, um pouco compulsivos e orgulhosos de nosso trabalho, nos esforçamos bastante para garantir que nosso software funcione corretamente.

Além disso, como desenvolvedor, faço muito mais testes do que os testadores. Rotineiramente, testei meu código de unidade em 90% ou 100% se não estiver trabalhando com Java.

Eu gosto de trabalhar com os Testadores, porque eles vêm de uma perspectiva diferente e capturam coisas em que eu não pensava. Mas eu realmente não conto com eles para fornecer mais de 30 a 50% de cobertura de teste, enquanto me responsabilizo por 100%. (Aliás, isso não é um golpe para eles - eles geralmente se espalham entre os projetos.)

Em vez de perguntar aos engenheiros em entrevistas se eles querem fazer o controle de qualidade, pergunte: se um bug aparece na produção, quem é o responsável? Se eu introduzir um bug, e um cliente experimentá-lo, me sinto mal e assumo a responsabilidade. Não culpo os caras do controle de qualidade. IMHO Esse é o tipo de engenheiro que você deseja contratar (e trabalhar)

Meu método de garantir a qualidade é: a) teste de unidade super agressivo (embora eu não consiga me esforçar para fazer o desenvolvimento completo orientado a teste), b) um forte processo de revisão de código realmente ajuda ec) integrar intolerância e impaciência a defeitos na cultura da equipe.

Sempre me ocorreu que os caras mais graduados eram os mais diligentes e atentos a questões menores, porque eles poderiam apontar para um problema maior. Mas, principalmente, eles foram os mais dispostos a gastar o tempo para acertar.

Mas a maioria das equipes nas quais trabalhei, especialmente para pequenas empresas, não possuía um componente formal de controle de qualidade.

Concordo com a resposta do @Rob Y e gostaria de acrescentar alguns pontos:

• No ágil, testadores dedicados dentro de uma equipe são um antipadrão, porque forçam as equipes a canalizar o trabalho e são inerentemente ineficientes. Você acaba constantemente com histórias "dev done", mas não testadas. Os testadores dedicados são bons se trabalharem fora da equipe (ou de uma equipe separada).

• Dev fazer testadores ruins ... e testadores fazer testadores ruins. O controle de qualidade é difícil. Na verdade, é muito difícil. Seu problema pode não ser pessoas e funções. Seu problema pode ser que seu software está esgotado. Novamente, no ágil, é responsabilidade da sua equipe testar antes da produção (se eles dedicaram o controle de qualidade ou não).

• O controle de qualidade faz parte do desenvolvimento, como refatoração, arquitetura etc. É responsabilidade de uma equipe de desenvolvimento produzir software para um determinado padrão realista, acordado e acordado. O controle de qualidade não melhorará esse padrão. Os melhores desenvolvedores provavelmente o farão.

• Provocação: quem disse que os QAs são melhores que os desenvolvedores no QA-ing? É algo que as pessoas dizem, mas ... [citação necessário]. A mentalidade necessária "hacker" do controle de qualidade é uma mentalidade de desenvolvedor. De fato, basicamente todos os hackers são ou foram desenvolvedores, não o controle de qualidade ...

• Provocação 2: 99% do trabalho de controle de qualidade pode ser (e, devo dizer, deveria ser ) automatizado por meio de scripts. Uma boa equipe fará isso e, para fazer isso corretamente, você precisa de ... desenvolvedores.

Em um trabalho anterior, tínhamos apenas desenvolvedores e nenhuma equipe de controle de qualidade. Como resultado, não havia mais ninguém para culpar se um problema chegasse à produção. Levamos nossas responsabilidades de controle de qualidade muito a sério e dependemos muito de suítes de teste automatizadas. Como escrever testes automatizados ainda está codificando, não era grande coisa para os desenvolvedores fazerem isso.

O principal é torná-lo parte da cultura da equipe e parte de cada projeto. Escrevemos planos de teste (apenas breves listas de testes que pretendíamos escrever para um projeto), e outros desenvolvedores revisavam e sugeriam casos e cenários que perdemos.

Se você é rigoroso, pode funcionar muito bem. Foi o que fizemos por nós - tivemos excelente tempo de atividade e baixos defeitos em um serviço da web de comércio eletrônico sempre ativo.

Primeiro uma ressalva - trabalhei profissionalmente como engenheiro de controle de qualidade e engenheiro de software.

Esse modelo poderia funcionar na prática?

Tudo é possível.

Embora eu entenda que, muitas vezes, os desenvolvedores estão "muito próximos" de seu código ou do código de seus colegas para fazer avaliações de nível superior da qualidade, não estou convencido de que sejam realmente testadores ruins. Pelo contrário, sou da opinião de que as qualidades de um bom desenvolvedor se sobrepõem muito às qualidades de um bom testador.

Depende do tipo de teste que você precisa. Se você precisar de testes manuais repetitivos, monótonos e entorpecentes, para garantir que todas as telas ou elementos sejam realmente traduzidos para elboniano ... você terá problemas.

E, na minha experiência, todo projeto requer pelo menos um pouco desse tipo de teste (mesmo que nem todo projeto tenha feito esse tipo de teste). O problema é que você não recebe esse tipo de teste de pessoas não familiarizadas com as práticas recomendadas de controle de qualidade. Inferno, você nem entende de pessoas que conhecem as melhores práticas, mas "confia" nos desenvolvedores.

Como testador, você não pode confiar nos desenvolvedores. Perdi a conta dos bugs que descobri que "não poderiam ter sido causados ​​por essa alteração" ou "funcionam perfeitamente bem na minha caixa de desenvolvimento".

Mesmo que você encontre desenvolvedores que toleram não fazer o que gostam de fazer em duas semanas, você também enfrentará essa contradição principal. Pior ainda, você está gastando tempo e energia para treinar as pessoas a serem boas em dois empregos, em vez de um. As empresas têm dificuldade em encontrar e treinar pessoas boas em um único emprego, e muito menos em dois.

Talvez você seja incrível de alguma forma que ainda não encontrei - mas duvido.

Eu acho que poderia funcionar, mas há algumas coisas que eu garantiria que você fizesse.

1. Seja muito franco quanto aos papéis duplos para os candidatos. Não é para todos por muitas razões. Se você tem muitas pessoas que não gostam, terá falhas e rotatividade.
2. Tenha um plano em que você possa avaliar a melhor maneira de incorporar isso à equipe. Embora eu goste de focar em uma tarefa / projeto de cada vez, não tenho certeza se gostaria de não programar por um período muito longo. Talvez o teste seja um período agradável de férias longe da programação. Não que seja mais fácil, basta usar algumas células cerebrais diferentes para variar. Esteja preparado para experimentá-lo de diferentes maneiras antes de decidir o que é melhor.

Sincronizar projetos não parece uma solução prática. Se alguém é testador de um projeto, pode ser o melhor candidato para substituir um programador e vice-versa.

Esse plano não permite que as equipes se auto-organizem o suficiente. Uma estratégia provavelmente não se ajustará a todas as equipes e todos os projetos.