Quem está no comando? Como eliminar o controle de acesso e aumentar a qualidade.

Jonny Steiner, Gerente de Marketing de Produto

 

Com certeza você já passou por uma situação parecida: você está andando por aí e se depara com alguém mais jovem usando uma camiseta da sua banda favorita. Talvez sua reação inicial seja algo como: “Nossa, uma camiseta do Nirvana? Será que essa pessoa conhece alguma música do Nirvana?”. Parece familiar? Então, parabéns, você tem potencial para ser um elitista! Dizemos potencial porque, em hipótese alguma, você deve abordar alguém e questioná-lo sobre o direito dessa pessoa de usar uma camiseta do Nirvana. Essa é uma lição para a vida, oferecida gratuitamente neste post.

Mas chega de generalidades, estamos aqui para discutir o conceito de gatekeeping no contexto das equipes de QA e testes. No mundo do desenvolvimento de software, um gatekeeper é a pessoa responsável por decidir quando um software ou atualização está pronto para entrar em produção. Isso significa que, nesse cenário, o gatekeeper assume toda a responsabilidade pela qualidade do software. Frequentemente, esse papel é desempenhado por um membro dedicado da equipe de testes ou QA.

Quem Releases da Releases?

É comum as pessoas perguntarem aos testadores quando eles aprovam o lançamento de uma versão. Testadores e desenvolvedores frequentemente expressam frustração quando trabalham em projetos onde a equipe de controle de qualidade detém o poder de decisão final sobre o lançamento. Atribuir esse nível de responsabilidade a uma única equipe pode levar a conflitos e atrasos.

Em certo nível, as equipes de teste se orgulham dessa designação, pois ela lhes confere um grande poder. No entanto, surge a questão de por que as equipes de controle de qualidade (QA) ou de teste precisam aprovar uma versão. Certamente não estou tentando criticar as equipes de QA ou de teste. Todos sabemos que, quando colocadas em condições difíceis, essas equipes fazem o melhor que podem com bom humor e desenvoltura.

Por outro lado, colocar os testadores nessa posição, como responsáveis ​​pela palavra final sobre os lançamentos, exerce muita pressão sobre eles.

Vamos analisar algumas das consequências negativas de ter o controle de qualidade como seu principal responsável pela triagem inicial:

• Todos os gargalos – As equipes de desenvolvimento geralmente são compostas por cinco pessoas, sendo uma delas designada como "testador". É bastante simples perceber que atribuir a responsabilidade pelos testes e pela qualidade a uma única pessoa pode... e liderar aos gargalos.
• Arcar com o peso da responsabilidade – Atribuir a responsabilidade pelos lançamentos a uma única pessoa significa que os outros membros da equipe trabalharão sob a falsa premissa de que todos os defeitos serão detectados pelo controle de qualidade. Pior ainda, isso também lhes dá a desculpa para não assumirem a responsabilidade por quaisquer bugs que cheguem à produção, pois podem simplesmente culpar o controle de qualidade.
• Ninguém é perfeito, nem mesmo os testadores – É melhor não basear todo o processo de lançamento na decisão de uma única pessoa. todos os Os insetos. Eles são humanos, assim como você, e humanos cometem erros.
• Ciclos de feedback – No modelo de gatekeeper, quando um desenvolvedor termina sua parte no processo, Eles entregam o projeto ao testador ou ao responsável pela garantia da qualidade e passam para o próximo. No entanto, quando o feedback inevitável chega, in, Eles precisarão alternar o contexto de volta para a funcionalidade anterior. Isso pode resultar em uma bagunça de projetos inacabados e interrompidos.

A alternativa ao controle de acesso é a quebra de barreiras.

Existem maneiras de executar testes que garantem a entrega de aplicativos de qualidade sem a necessidade de qualquer controle de qualidade. Se você delegar o trabalho de controle de qualidade para toda a equipe de desenvolvimento, todos serão responsáveis ​​pela qualidade. A equipe de controle de qualidade ainda pode ser responsável pelos testes, mas haverá mais testes a serem feitos e outros membros da equipe poderão contribuir.

• Os desenvolvedores podem proteger o trabalho que realizam escrevendo seus próprios testes unitários.
• Os gerentes de produto podem verificar os ambientes de teste para garantir que os novos recursos funcionem conforme o planejado.
• DevOps Os gerentes podem usar sistemas de CI para monitorar os testes à medida que cada novo código é enviado.

Você pode começar a implementar essa prática de forma simples.

Comece com uma sessão antes do início do desenvolvimento de uma nova funcionalidade. Dessa forma, os desenvolvedores e testadores podem iniciar o sprint entendendo o que precisam fazer para comprovar que o trabalho foi concluído de acordo com os critérios de aceitação. Com o trabalho discutido antecipadamente, a carga de trabalho será distribuída uniformemente entre a equipe e, com os testes de API sendo escritos pelos desenvolvedores, a equipe de QA poderá se concentrar nos testes de interface e funcionais.

À medida que o projeto avança e a equipe encontra um problema que precisa ser resolvido, ela pode discuti-lo entre si ou com outras equipes. Por exemplo, se a equipe de controle de qualidade (QA) descobrir um defeito, pode comunicá-lo às equipes de desenvolvimento de produto para verificar se é algo que exige atenção imediata ou se pode esperar.

Melhor ainda, à medida que mais pessoas se envolvem em um projeto e participam dos testes, isso leva a uma mentalidade de "shift-left" (deslocamento para a esquerda), na qual os testes são realizados o mais cedo possível no processo. Ninguém precisa esperar por um momento específico para começar a testar; isso simplesmente se torna um aspecto da rotina diária das pessoas. A longo prazo, isso deve ajudar a minimizar os riscos no final do ciclo de desenvolvimento.

Em última análise, isso leva a mais testes, o que se traduz em uma melhor cobertura, pois faz com que as equipes interdisciplinares se comuniquem entre si, em vez de permanecerem isoladas em seus próprios silos. Se equipes isoladas forem um problema em sua organização, você pode até mesmo discutir o assunto com os donos do produto e as partes interessadas. Promova a comunicação e a colaboração é extremamente importante ao lidar com situações de controle de acesso.

Os resultados serão então semelhantes a este:

• Responsabilidade compartilhada – Sem uma única pessoa responsável, toda a equipe assume a responsabilidade de entregar software de qualidade.
• Adeus gargalos – Não se trata mais de uma única pessoa testando contra o mundo inteiro. Com todos testando, novas versões e aplicativos chegarão à produção mais rapidamente.
• Aperfeiçoando o ciclo de feedback – Não será mais necessário alternar entre contextos quando um defeito for descoberto. Os defeitos serão detectados e mitigados no início do processo, eliminando quaisquer atrasos na produção.

O controle de acesso em controle de qualidade é uma relíquia.

Isso ainda acontece em algumas organizações. A equipe de controle de qualidade (QA) é responsabilizada pelo lançamento de um projeto e detém as chaves de acesso a ele. Essa prática prejudicial pressiona os testadores e leva a relações ruins entre equipes isoladas, já que trabalham separadamente em busca de um objetivo com o qual não colaboram.

Existem dois principais cenários negativos na prática de controle de qualidade:

1. Projetos atrasados ​​– Como o controle de qualidade bloqueia certos pequenos problemas antes do lançamento.
2. Defeitos de produção – Sempre que um bug passa despercebido, o controle de qualidade (QA) vira bode expiatório, pois é visto como responsável pela qualidade geral.

Para abandonar esse método antiquado — e francamente pouco colaborativo — de desenvolvimento e teste, as equipes precisam que todos os membros do projeto trabalhem nos testes durante o desenvolvimento, em vez de deixar tudo a cargo da equipe de controle de qualidade. Também precisam adotar a estratégia de "shift left" (deslocamento para a esquerda) e testar com frequência e desde o início. Essa compreensão básica ajudará as organizações a criar um sistema onde todos possam contribuir e a qualidade geral dos lançamentos também melhorará.

A qualidade, como objetivo e conceito, precisa ser um dos fundamentos do fluxo de trabalho de uma equipe. Também precisa ser algo em que todos os envolvidos em um projeto participem. Se você perceber que o isolamento ou a falta de cooperação entre as equipes estão começando a surgir na sua empresa, deve conversar sobre isso com quem tem poder para mudar essa situação. Quando uma equipe de controle de qualidade se concentra em controlar o processo, a qualidade geral do aplicativo fica prejudicada, e isso é uma pena, porque a palavra está literalmente no nome da equipe.