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

9

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.

MetaFight
fonte
Embora haja sobreposição sobre se os Desenvolvedores podem ou devem ser testadores, acho que o cerne desta questão é sobre as funções fora de fase 2 no modelo de 2 projetos.
MetaFight 24/02
2
Minha opinião pessoal é que você está arriscando bastante com essa abordagem. Sou um ex-testador (e não o pior) e, uma vez que entrei em um projeto em que pude "entrelaçar" 2 papéis, pensei pela primeira vez em wow, uma chance de descobrir como fazer isso direito. Após cerca de meio ano, mudei de idéia e nunca mais quero tentar. Ambas as funções (desenvolvedor e controle de qualidade) exigem 100% de foco para fazer o certo, mas quando você se entrelaça, distrai e perde a qualidade ou a produtividade ou ambas. BTW ficando testador dedicado nesse projeto produzido ROI mais impressionante que eu já testemunhei
mosquito
2
@gnat, mas você não explicou por que um desenvolvedor não pode desempenhar a função de testador. Concedido que a pessoa em questão precisaria levá-la a sério como uma função de período integral, motivo pelo qual sugeri que elas alternassem projetos e trabalhassem apenas em um projeto por vez. Não espero que nenhum desenvolvedor seja capaz de fazer isso ... apenas aqueles que seriam bons testadores se tivessem escolhido esse caminho.
MetaFight 24/02
2
Parafraseando o que você quer fazer: "Quero abrir uma cirurgia médica, em vez de contratar alguns anestesistas, empregarei cirurgiões suficientes e os rotacionarei por esse papel". Sua proposta mostra uma (típica) falta de entendimento do que um testador profissional oferece a uma equipe. Você poderia fazer isso, muitos fazem, alguns fazem funcionar. O que você nunca saberá é o que está perdendo e o que poderia estar fazendo melhor. A propósito - Testar não é controle de qualidade - apenas uma lição que um testador profissional ensinará.
mattnz

Respostas:

8

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.

Roubar
fonte
6

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.

Sklivvz
fonte
Comentando a Provocação 2: a automação de teste pode ser feita pelos desenvolvedores, mas não necessariamente. Os testadores que sabem codificar (mas não no nível de um desenvolvedor profissional) podem escrever scripts bons o suficiente.
Mate Mrše 17/04/19
4

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.

Rory Hunter
fonte
é difícil ler este post (parede de texto). Você se importaria de editá -lo em uma forma melhor?
Gnat
2
Desculpe, despejo matinal. Eu quebrei agora.
Rory Hunter
2

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.

Telastyn
fonte
Talvez meu modelo precise de uma função de controle de qualidade Sr para revisar as abordagens propostas pelos meus testadores de desenvolvimento e recomendar abordagens de melhores práticas. Ah, e a maioria das pessoas não me acha incrível, mas minha mãe sim :) e isso é bom o suficiente para mim!
MetaFight 24/02
Estou fazendo a transição de algumas de nossas funções de controle de qualidade para proprietários de produtos. Parece que você não tem a aceitação do proprietário do produto de histórias de usuários ou revisões de sprint. Ambos pegam muitos problemas que a equipe de desenvolvimento pode ter perdido. Antes disso, porém, se você não pode confiar nos desenvolvedores para produzir qualidade, você precisa encontrar desenvolvedores diferentes. Essa é a minha conclusão - na minha experiência - você não pode treinar uma qualidade ruim com um desenvolvedor ruim. Eu trabalhei com muitos desenvolvedores "faça o trabalho" e essa é a saída que você obtém deles. Uma boa equipe de scrum requer bons desenvolvedores.
David Anderson
0

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.

JeffO
fonte
A função Testador nesse caso provavelmente envolveria testes manuais e automatizados. Eu esperava que os desenvolvedores escrevessem testes de unidade e integração, mas os Testers também fariam o mesmo. Espera-se que a divisão exata da escrita do teste codificado seja um equilíbrio natural alcançado após algumas iterações.
MetaFight 24/02
Realmente nem deveria ser um caso se os candidatos estão dispostos a desempenhar papéis duplos ou não. Se você deseja administrar uma empresa de sucesso, coloque as pessoas onde elas se destacam. Por que colocar o cara em teste, que pode projetar e codificar 2 sistemas confiáveis ​​por conta própria, onde uma equipe de 4 ou 5 leva para executar um único sistema ao mesmo tempo? Da mesma forma, o teste tem suas próprias habilidades para poder fazê-lo bem. Os maiores avanços na civilização humana ocorreram quando os humanos começaram a se especializar. Por que administrar uma empresa de software seria diferente do que a mãe natureza já provou funcionar melhor?
Dunk