Quem está no comando? Como eliminar o bloqueio e aumentar a qualidade

Jonny Steiner, Gerente de Marketing de Produto

Temos certeza que você já deve ter passado por uma situação como esta antes: Você está andando em algum lugar público e se depara com uma pessoa mais jovem vestindo uma camiseta da sua banda favorita. Talvez sua reação inicial seja algo como: “Uau, uma camiseta do Nirvana? Eu me pergunto se eles conhecem alguma música do Nirvana.” Soa familiar? Então, parabéns, você tem potencial de gatekeeper! Dizemos potencial porque em nenhum caso você deve ir até as pessoas e questioná-las sobre o direito de usar uma camiseta do Nirvana. Essa é uma lição para a vida fornecida gratuitamente com esta postagem no blog.

Chega de generalidades, porém, estamos aqui para discutir o controle de qualidade no que se refere ao controle de qualidade e às equipes de teste. No mundo do desenvolvimento de software, um Gatekeeper é uma pessoa que tem controle sobre quando um software ou atualização está pronto para entrar em produção. O que isso significa é que, nesse cenário, o gatekeeper assume toda a responsabilidade pela qualidade do software. Freqüentemente, esse papel é desempenhado por um membro dedicado da equipe de teste ou controle de qualidade.

Quem Releases da Releases?

As pessoas costumam perguntar aos testadores quando eles aprovam release. Os testadores e desenvolvedores geralmente expressam frustração quando trabalham em projetos em que o controle de qualidade detém as chaves para o release. Colocar esse nível de responsabilidade em uma equipe pode levar a disputas e atrasos.

Em algum nível, as equipes de teste se orgulham dessa designação, pois ela coloca muito poder em suas mãos. No entanto, levanta a questão de por que QA ou equipes de teste precisam aprovar um release de forma alguma. Certamente não estou tentando arriscar no controle de qualidade ou nas equipes de teste. Todos sabemos que, quando colocadas em condições difíceis, essas equipes fazem o melhor que podem com boa natureza e desenvoltura.

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

Vejamos algumas das consequências negativas de ter o controle de qualidade como seu guardião:

• Todos os gargalos - As equipes de desenvolvimento geralmente consistem em cinco pessoas, sendo uma pessoa designada como “testador”. É uma matemática bem simples ver que tornar uma pessoa responsável pelos testes e pela qualidade pode conduzir aos gargalos.
• Carregando o peso da responsabilidade – Tornar uma pessoa responsável por releases significa que os outros membros da equipe funcionarão sob a falsa noção de que todos os defeitos serão detectados no controle de qualidade. Talvez ainda pior, também lhes dá a chance de não assumir a responsabilidade por nenhum bug que chegue à produção, porque eles podem simplesmente culpar o controle de qualidade.
• Ninguém é perfeito, nem mesmo os testadores – Melhor não basear todo o seu release processo em uma pessoa encontrando todos os Os insetos. Eles são humanos e você também, e humanos cometem erros.
• Ciclos de feedback - No modelo gatekeeper, quando um desenvolvedor termina sua parte no processo, eles o entregam ao testador ou ao controle de qualidade e, em seguida, passam para o próximo projeto. No entanto, quando o feedback inevitável vem in, eles precisarão mudar de contexto de volta para o recurso anterior. Isso pode resultar em uma confusão de projetos incompletos e interrompidos.

A alternativa ao gatekeeping é o gatebreaking

Existem maneiras de executar testes que garantem que você release aplicações de qualidade sem a necessidade de qualquer controle. Se você atribuir o trabalho de controle de qualidade a toda a equipe de desenvolvimento, todos serão responsáveis ​​pela qualidade. O controle de qualidade ainda pode ser responsável pelos testes, mas há mais testes a serem feitos e outros membros da equipe podem ajudar.

• Os desenvolvedores podem cobrir o trabalho que fazem escrevendo seus próprios testes de unidade.
• Os gerentes de produto podem verificar os ambientes de preparação para garantir que os novos recursos sejam executados conforme executado.
• DevOps os gerentes podem usar sistemas de IC para monitorar os testes à medida que cada novo código é confirmado.

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

Comece com uma sessão antes do trabalho de desenvolvimento começar em um novo recurso. Dessa forma, os desenvolvedores e testadores podem entrar no sprint entendendo o que precisam fazer para provar que o trabalho foi concluído de acordo com os critérios de aceitação. Com o trabalho sendo discutido com antecedência, a carga de trabalho será distribuída uniformemente entre a equipe e com os testes de API sendo escritos pelos desenvolvedores, o QA pode trabalhar na interface do usuário e nos testes funcionais.

À medida que o projeto avança e a equipe encontra um problema que precisa ser resolvido, eles podem discuti-lo entre si ou entre as equipes. Por exemplo, se o controle de qualidade descobrir um defeito, ele pode apresentá-lo às equipes de desenvolvimento do produto para ver se é algo que precisa de atenção imediata ou se pode esperar.

Melhor ainda, à medida que mais pessoas se envolvem com um projeto e participam dos testes, isso leva a uma mentalidade Shift-Left, na qual o teste é feito o mais cedo possível no processo. Ninguém precisa esperar um horário específico para iniciar o teste, ele simplesmente se torna um aspecto do dia a dia das pessoas. A longo prazo, isso deve ajudar a minimizar o risco no final do ciclo de desenvolvimento

Em última análise, leva a mais testes que se traduzem em melhor cobertura porque faz com que as equipes interdisciplinares se comuniquem entre si, em vez de permanecerem em suas próprias equipes isoladas. Se as equipes isoladas são um problema em sua organização, você pode até falar com os proprietários do produto e as partes interessadas. Promova a comunicação e a colaboração é extremamente importante ao cuidar de uma situação de gatekeeper.

Os resultados ficarão assim:

• Responsabilidade compartilhada - Sem uma pessoa responsável, toda a equipe assume a responsabilidade de entregar software de qualidade.
• Adeus gargalos - Não é mais uma pessoa testando contra o mundo. Com todos testando, novas versões e aplicativos chegarão à produção mais rapidamente.
• Apertando o loop de feedback – Não há mais troca de contexto quando um defeito é descoberto. Os defeitos serão descobertos e mitigados no início do processo, eliminando quaisquer atrasos na produção.

Gatekeeping em QA é uma relíquia

Isso ainda acontece em algumas organizações. QA é responsável por um projeto release e detém as chaves do release. Essa prática prejudicial pressiona os testadores e leva a relacionamentos ruins entre equipes isoladas, pois trabalham separadamente em direção a uma meta com a qual não estão colaborando.

Existem dois cenários negativos principais ao praticar o controle de qualidade:

1. Projetos adiados - Como o controle de qualidade bloqueia certos pequenos problemas antes release.
2. Defeitos de produção - Sempre que um bug passa despercebido, o controle de qualidade é o bode expiatório porque é visto como responsável pela qualidade geral.

Para abandonar esse método antiquado – e francamente anti-colaborativo – de desenvolvimento e teste, as equipes precisam ter todos no projeto trabalhando nos testes à medida que se desenvolvem, em vez de ter o controle de qualidade como responsável por tudo isso. Eles também precisam mudar para a esquerda e testar cedo e frequentemente. Ter esse entendimento básico ajudará as organizações a criar um sistema em que todos possam fazer sua parte e a qualidade geral de seus releases vai melhorar também.

A qualidade como meta e como conceito precisa ser um dos fundamentos do fluxo de trabalho de uma equipe. Também precisa ser algo do qual todos os envolvidos em um projeto participem. Se você perceber que alguns dos silos ou falta de cooperação entre as equipes começam a surgir em sua empresa, você deve falar com aqueles em posição de mudar isso. Quando uma equipe de controle de qualidade está focada em controlar a qualidade geral do aplicativo, isso é uma pena, porque a palavra está literalmente no título.