Talvez eliminar a equipe de QA tenha sido, na verdade, uma decisão ruim
- A parte mais lenta da entrega de software é o teste. Se a entrega contínua existe por causa dos testes, é natural que esse seja considerado o gargalo em um sistema otimizado.
- O hábito e o comportamento de otimização levaram a indústria a enxergar a equipe de QA como um gargalo e tentar eliminá-la. Isso reduziu o respeito pelo papel de QA e gerou problemas na produção de software de qualidade.
- Os desenvolvedores não compreendem adequadamente a gestão da qualidade de software. Muitas organizações não sabem de quem é a responsabilidade pela qualidade do software, e mesmo as que mantiveram a função de QA têm dificuldade para encontrar um lugar adequado para ela.
O que é preciso fazer para gerenciar a qualidade nas práticas de software
- Rastreamento de defeitos: é necessário haver uma forma de os usuários fornecerem informações sobre bugs e de os desenvolvedores registrarem esses bugs.
- Triagem: a triagem de bugs é o processo de gerenciar atribuição, priorização, organização, classificação e remoção de duplicatas.
- Investigação de defeitos: reproduzir bugs é uma parte importante da gestão de bugs, e exige esforço de engenharia para identificar e resolver o problema real.
- Foco: é preciso haver pessoas na empresa focadas em qualidade, além de alguém que defenda a qualidade para equilibrá-la com a velocidade.
- Testes end-to-end: problemas de propriedade do sistema surgem por causa de arquiteturas complexas, o que leva à ausência de testes de uso real antes do lançamento do produto.
Opinião do GN⁺
- Acabar com a equipe de QA pode ser um erro de gestão que, no longo prazo, afeta seriamente a qualidade do software.
- No processo de desenvolvimento de software, a garantia de qualidade é uma atividade importante, e ignorá-la ou tratá-la com descaso pode acabar levando ao fracasso.
- Este artigo é interessante por recolocar em destaque a importância do QA na indústria de software e por enfatizar a necessidade de uma percepção adequada sobre gestão da qualidade e de uma divisão clara de papéis dentro da organização.
1 comentários
Opiniões do Hacker News
No fim da década de 1970, trabalhei na IBM com garantia de produto, escrevendo código de teste e montando hardware para o produto sob minha responsabilidade (um sistema de processamento de texto). Eu não revelava os casos de teste específicos à equipe de desenvolvimento, apenas comunicava problemas gerais para induzir a correção de bugs. Pela discrepância entre os bugs que eu encontrava e os bugs que a equipe corrigia, era possível calcular estatisticamente uma estimativa dos bugs restantes.
Em organizações sem equipe de QA, foi adotado o conceito de "sniff test". Trata-se de uma sessão em que toda a empresa testa intensivamente um novo recurso por um curto período de tempo (normalmente 1 hora), o que resultava na criação de muitos tickets de bug. Muitas vezes, testes simples acabavam causando problemas, mas isso já não surpreende mais.
Duas empresas em que trabalhei há 15–20 anos investiam em equipes de QA de altíssimo nível, e elas eram excelentes em encontrar bugs que os desenvolvedores não imaginavam. A equipe de QA tinha a autoridade final para decidir se o produto seria lançado ou não. Hoje, muitas empresas acham que o melhor caminho é fazer os desenvolvedores escreverem testes automatizados e gastarem muito tempo com code coverage, mas já vi muitos produtos que, na prática, não funcionavam. Não é que testes automatizados sejam ruins; a questão é eliminar testadores humanos de QA.
Os funcionários mais conscienciosos de uma organização muitas vezes também são os mais insatisfeitos. Eles percebem problemas de qualidade e tentam resolvê-los, mas não recebem reconhecimento, e quando falam sobre qualidade são tratados como pessoas que querem desacelerar. Enquanto quem "se move rápido e quebra coisas" continua sendo recompensado, eles ficam irritados tendo de limpar a bagunça e sentem que se importar pode prejudicar a carreira dentro da organização.
QA tende a ser visto como um "centro de custo" pelo negócio e pela alta gestão. Existe a hipótese de que se deve evitar trabalhar em departamentos considerados "centros de custo", pois a compensação e o reconhecimento sempre vão para quem gera receita. QA tem de fazer mais trabalho com menos gente, leva a culpa pelos fracassos e pode ser o primeiro lugar a sofrer demissões quando a empresa precisa ficar mais enxuta.
Engenheiros de QA têm excelentes habilidades de depuração. Eles trabalham com todos os aspectos da aplicação, como pipeline, código-fonte e diretórios de teste, e com frequência veem engenheiros de software passarem dias sem ler mensagens de erro do pipeline, ignorando o problema básico e tentando adivinhar a solução. O desprezo por engenheiros de QA não é exagero no artigo, e como as organizações de QA não passam por processos seletivos tão rigorosos quanto os da engenharia, os engenheiros de QA acabam sendo vistos como inferiores.
Pela minha experiência pessoal, nunca encontrei uma equipe de QA que realmente escrevesse testes para a engenharia. A maioria das equipes de QA executa "planos de teste" manualmente ou, mais raramente, por meio de testes automatizados de navegador/dispositivo. Esses tipos de teste têm valor, mas não tanto quanto "testes unitários" ou "testes de integração". Nesse modelo, a equipe de engenharia é que acaba exercendo o verdadeiro papel de QA, enquanto a equipe de QA muitas vezes reduz seu valor ao apontar como bug coisas que não são bugs.
A Microsoft testemunhou mais bugs no Windows e em produtos de nuvem depois de eliminar a equipe de QA.