Qualidade é responsabilidade da equipe. Nossa experiência em controle de qualidade

Trabalho como engenheiro de controle de qualidade na Miro . Vou contar a você sobre nosso experimento em transferir para os desenvolvedores parte das tarefas de teste e transformar o papel do testador no papel de controle de qualidade (garantia de qualidade).

Primeiro, brevemente sobre o nosso processo de desenvolvimento. Temos lançamentos diários de clientes e 3 a 5 lançamentos de servidores por semana. A equipe de desenvolvimento tem mais de 60 pessoas, divididas em 10 equipes funcionais de scrum.

Trabalho na equipe de integração, cuja tarefa é integrar nosso serviço a produtos externos e integrar produtos externos a nosso serviço. Por exemplo, integramos o rastreador de tarefas Jira . Cartas Jira - uma exibição visual de tarefas que você pode trabalhar convenientemente no quadro sem entrar no Jira.

Como o experimento começou?

Tudo começou com um problema comum. Quando um dos testadores foi para a lista de doentes, o desempenho da equipe foi bastante reduzido. A equipe continuou a trabalhar nas tarefas, mas o código chegou ao estágio de teste e a tarefa parou. Como resultado, a nova funcionalidade não atingiu a produção no prazo.

A partida do testador de férias é outra história. Ele precisa encontrar com antecedência um dos testadores que está pronto para executar suas tarefas, além das suas, para concordar, para mergulhar nas tarefas. Ao mesmo tempo, dois testadores saem de férias é um luxo inadmissível.

Começamos a pensar em como resolver o problema e percebemos que o problema real é que o estreito pescoço dos processos de desenvolvimento está testando. Vou mostrar um exemplo de várias histórias.

A primeira história: reversão infinita de tarefas

Há também um desenvolvedor. Cada um tem suas próprias tarefas. O desenvolvedor concluiu uma das tarefas e me entregou para teste. Como essa tarefa tem uma prioridade mais alta que a atual, eu mudo para ela. Encontro bugs, pego tudo no Jira e devolvo ao desenvolvedor para revisão.

Volto às tarefas que tiveram que ser adiadas. O desenvolvedor muda de novas tarefas para a tarefa que retornei. Ele corrige bugs e me devolve para o teste. Encontro bugs novamente e retorno a tarefa novamente. Esse processo pode continuar por muito tempo.



Como resultado, o tempo total de trabalho na tarefa aumenta várias vezes, seguido pelo aumento do tempo de colocação no mercado, e isso é fundamental para nós, como empresa de alimentos. Há vários motivos para aumentar o tempo gasto na tarefa:

1. A tarefa está mudando constantemente entre desenvolvimento e teste.
2. A tarefa está ociosa aguardando um testador ou desenvolvedor.
3. O desenvolvedor e o testador precisam alternar regularmente entre tarefas, o que requer tempo e energia adicionais.

A segunda história: uma linha crescente de tarefas

Nossa equipe de scrum tem vários desenvolvedores. Eles me enviam suas tarefas regularmente para testes. Uma fila de formulários de tarefas pelas quais me comprometo, com base em prioridades.

Por isso, trabalhamos por cerca de um ano, mas durante esse tempo a empresa cresceu significativamente: o número de projetos e desenvolvedores aumentou e, portanto, o número de tarefas nos testes. Ao mesmo tempo, eu ainda era o único testador em nossa equipe e não conseguia multiplicar minha velocidade. Como resultado, mais e mais tarefas estavam se acumulando na fila de testes, e o processo de transferência de tarefas entre o desenvolvedor e o testador aumentou o tempo de espera.

De repente, fiquei doente. A entrega de novos recursos de nossa equipe de produção foi completamente interrompida. O que uma equipe deve fazer em tal situação? Você pode pedir ao testador ajuda de outra equipe. Mas, com um alto grau de probabilidade, ele não ficará imerso em nossas especificidades, o que afetará negativamente a qualidade e o timing das duas equipes.

A conclusão das duas histórias é a mesma - as equipes dependem muito do testador:

• O desempenho de toda a equipe é limitado pelo desempenho do testador.
• O número de desenvolvedores não pode ser aumentado sem aumentar a equipe de testadores.
• Um aumento na velocidade de desenvolvimento não faz sentido se todas as tarefas caírem na fila para teste.
• Enquanto o trabalho do desenvolvedor é verificado pelo testador, o senso de responsabilidade do desenvolvedor pela qualidade é reduzido.
• Se não houver testador, o processo de saída de novas funcionalidades será prejudicado.

Vamos aumentar a equipe de testadores?

O pensamento mais óbvio é aumentar a equipe de testadores. Isso funcionará, mas apenas até um certo ponto: o número de tarefas aumentará constantemente e é impossível aumentar infinitamente o número de testadores - em algum momento, ficará caro e ineficiente. Fedor Ovchinnikov , CEO da Dodo Pizza, escreveu bem sobre o problema dos problemas de "pensamento de recursos" (você não consegue resolver o problema? Contrate outro funcionário).

É muito mais eficiente manter a velocidade e a qualidade do desenvolvimento dentro dos recursos atuais. Portanto, decidimos lançar um experimento que ajudará as equipes a criar funcionalidade imediatamente, levando em consideração todos os riscos e situações de fronteira. Eles o chamaram de Testador de transformação em controle de qualidade, porque trata-se da transformação de uma das funções da equipe: de um testador de macaco, identificando erros pelo desenvolvedor, a um engenheiro de controle de qualidade que conscientemente garante a qualidade em todas as etapas do processo de desenvolvimento.

Vamos melhorar os processos de desenvolvimento

Objetivos do experimento:

• Para remover a dependência da equipe dos testadores, mas sem perda de qualidade e tempo.
• Melhore a garantia de qualidade dos engenheiros de controle de qualidade nas equipes.

O primeiro passo foi mudar o pensamento da equipe. Todos estão acostumados ao fato de que o testador é responsável pela qualidade da equipe.

Nossa hipótese era que aumentar o tempo para preparar e testar tarefas ajudaria a reduzir o número de iterações ao trabalhar em uma tarefa. Isso, por sua vez, permitirá trazer novas funcionalidades à produção sem perda de velocidade e nível de qualidade, e talvez mais rápido e com melhor qualidade.

Juntamente com a equipe e com testadores de outras equipes, desenvolvemos um novo esquema de trabalho. Durante meio ano, enquanto a equipe trabalha nisso, levamos em conta as dificuldades e os problemas que surgiram ao longo do caminho, e hoje fica assim:

1. Apresentação da produção.
2. Solução técnica e cenário de teste.
3. Desenvolvimento e verificação.
4. Lançamento

Declaração do problema

O Dono do produto apresenta a declaração do problema à equipe. A equipe analisa a formulação para identificar situações limítrofes do lado técnico e do produto. Se houver perguntas que precisem ser investigadas mais detalhadamente - uma tarefa separada será definida, para a qual o tempo será alocado no sprint.

Solução técnica

O resultado da análise da formulação do problema é uma solução técnica, que é um ou mais desenvolvedores. Todos os funcionários relevantes da empresa, incluindo o controle de qualidade, devem estar familiarizados e concordar com a solução técnica. A solução técnica descreve o problema que estamos resolvendo, os blocos funcionais do produto que serão afetados e o plano proposto para fazer alterações no código.

Essa solução permite identificar uma solução melhor e mais simples, com base na experiência dos participantes relevantes no processo de desenvolvimento. Tendo em mãos uma descrição técnica detalhada - é mais fácil ver e evitar problemas de bloqueio, é mais fácil realizar uma revisão de código.

Aqui está um exemplo de alguns blocos de uma solução técnica:

Descrição da tarefa

Novas entidades ou abordagens foram adicionadas ao sistema?
Nesse caso, eles são descritos e explicados por que é impossível resolver o problema dentro da estrutura das abordagens existentes.
A interação do servidor está mudando dentro do cluster? Novas funções de cluster estão sendo adicionadas?

O modelo de dados está mudando?

Para o servidor, estamos falando de objetos e modelos.
Se o modelo de dados for complexo, você poderá apresentá-lo na forma de um diagrama UML ou como uma descrição de texto.

A interação entre o cliente e o servidor está mudando?

Descrição das alterações. Se for uma API, ela pode ser fornecida a usuários externos? Não se esqueça do tratamento de erros - ou seja, indicar o motivo correto.

Cenário de teste

Paralelamente, o desenvolvedor ou o controle de qualidade elabora um cenário de teste que leva em consideração todos os locais possíveis onde ocorreram problemas. Se o desenvolvedor fizer isso, ele necessariamente fornecerá o script ao controle de qualidade, que verifica a integridade e a suficiência. Se o script for controle de qualidade, o desenvolvedor deve confirmar que entende como cada um de seus itens pode ser concluído. A equipe também avalia o script para correção.

Para compilação e armazenamento de scripts, usamos o HipTest.

Desenvolvimento e Validação

O desenvolvedor começa a escrever o código com base em uma solução técnica e levando em consideração todas as situações possíveis descritas na documentação do teste. Passa em uma revisão de código e verifica o código em relação aos cenários de teste. Produz mesclagem no mestre.

Nesse estágio, o controle de qualidade fornece o suporte necessário ao desenvolvedor. Por exemplo, ajuda a reproduzir casos complexos, a configuração de um ambiente de teste, a realização de testes de carga e informa sobre as possíveis nuances da saída de grandes recursos para a produção.

Lançamento da funcionalidade pronta

Esta é a etapa final. Aqui, a equipe pode ser solicitada a realizar ações de pré / pós-lançamento, por exemplo, a inclusão de novas funcionalidades para usuários beta.

Documentação e Ferramentas

O novo esquema de trabalho exigiu aos desenvolvedores mais imersão no processo de teste. Portanto, como um controle de qualidade, era importante fornecer todas as ferramentas necessárias e ensinar o básico dos testes funcionais. Juntamente com o controle de qualidade de outras equipes, fizemos uma lista da documentação necessária, criamos as instruções de teste ausentes e finalizamos as existentes levando em conta coisas que não eram óbvias para os desenvolvedores.

Em seguida, demos aos desenvolvedores acesso a todas as ferramentas e ambientes de teste e começamos a realizar testes conjuntos. No início, os desenvolvedores não queriam se responsabilizar pelos resultados dos testes, porque ninguém mais verificou nada para eles, era incomum para eles. Cada desenvolvedor tinha apenas um script de teste, a funcionalidade que ele desenvolveu e o botão Mesclar. Mas gradualmente eles se acostumaram.

Resultados da Experiência

Seis meses se passaram desde o início do experimento. O gráfico exibe as estatísticas do número de bugs por semana em nossa equipe. A cor vermelha mostra o número de todos os erros encontrados pela equipe, verde - o número de erros corrigidos.



Pode-se observar que o nível da linha vermelha permaneceu no mesmo nível, exceto pela explosão no início do experimento. Não há mais erros, o que significa que mantivemos o nível atual de qualidade.

Ao mesmo tempo, o tempo médio para trabalhar em tarefas diminuiu apenas 2%: antes do início do experimento, eram 12 horas e 40 minutos, depois - 12 horas e 25 minutos. Portanto, conseguimos manter a velocidade atual do trabalho nas tarefas.

Como resultado, nossa equipe não tem mais uma forte dependência do controle de qualidade. Se eu ficar doente ou sair de férias, a equipe continuará trabalhando sem perda de velocidade e qualidade.

Consideramos o experimento bem-sucedido, apesar de os indicadores de tempo e qualidade permanecerem os mesmos? Sim, acreditamos, porque mantivemos a velocidade e a qualidade do trabalho e liberamos tempo de controle de qualidade para um trabalho mais consciente sobre a qualidade do produto e os processos de desenvolvimento. Por exemplo, para realizar testes de pesquisa, aumente a cobertura de testes funcionais e descreva os princípios e regras para o desenvolvimento da documentação de testes em todas as equipes.

Em outras equipes, plantamos a semente do experimento. Por exemplo, em um dos comandos, o controle de qualidade agora não testa o que é descrito pelo desenvolvedor na solicitação pull, porque o desenvolvedor pode vê-lo por conta própria. Em outra equipe, o controle de qualidade analisa as alterações na solicitação e verifica apenas casos complexos e não óbvios.

Lembretes antes de iniciar um experimento

Este é um experimento complexo e demorado. Não é implementado com o clique de um dedo, você precisa se preparar com cuidado e não esperar por resultados rápidos.

Esteja preparado para a negatividade da equipe. Você não pode simplesmente aceitar e dizer que agora os desenvolvedores estão testando a funcionalidade. É necessário prepará-los para isso, desenvolver abordagens, explicar o valor do experimento para a equipe e o produto.

A perda de velocidade no início é inevitável. O tempo para treinar desenvolvedores, escrever a documentação que está faltando e reconstruir os processos leva tempo, que precisará ser doado ao experimento.

Não há solução pronta. Processos semelhantes são implementados, por exemplo, no Atlassian , mas isso não significa que você também será capaz de implementá-los por conta própria. É importante a adaptação à cultura da empresa e às especificidades das equipes.