Isenção de responsabilidade: Esta é uma tradução de um artigo . Todos os direitos pertencem ao autor do artigo original e à empresa Miro.
Sou engenheiro de controle de qualidade em Miro . Deixe-me contar sobre nosso experimento de transferir tarefas de teste parcialmente para desenvolvedores e de transformar a função de Engenheiro de Teste em QA (garantia de qualidade).
Primeiro, brevemente sobre o nosso processo de desenvolvimento. Temos lançamentos diários para o lado do cliente e 3 a 5 lançamentos semanais do lado do servidor. A equipe tem mais de 60 pessoas cuspidas em 10 equipes funcionais de Scrum.
Estou trabalhando na equipe de integração. Nossas tarefas são:
- Integração do nosso serviço em produtos externos
- Integração de produtos externos em nosso serviço
Por exemplo, integramos o Jira . Cartões Jira - representação visual de tarefas, por isso é útil trabalhar com tarefas que não abrem o Jira.
Como o experimento começa
Tudo começa com um problema trivial. Quando alguém dos Engenheiros de Teste teve licença médica, o desempenho da equipe foi significativamente reduzido. A equipe continuou trabalhando nas tarefas. No entanto, quando o código foi alcançado, a tarefa da fase de teste foi mantida. Como resultado, novas funcionalidades não chegaram à produção a tempo.
Sair de férias pelo Engenheiro de Teste é uma história mais complexa. Ele / ela precisa encontrar outro Engenheiro de Teste que esteja pronto para executar tarefas extras e conduzir o compartilhamento de conhecimento. Sair de férias por dois engenheiros de teste no momento são não é um luxo aplicável.
Começamos a pensar em como resolver esse problema. Descobrimos que a causa raiz é que a fase de teste é um gargalo. Deixe-me compartilhar alguns exemplos disso.
Caso 1: pingue-pongue de tarefas
Eu e o desenvolvedor. Cada um tem suas próprias tarefas. O desenvolvedor concluiu uma tarefa e a enviou para teste. Na medida em que essa nova tarefa tem maior prioridade, eu estou ativando-a. Encontrei defeitos, criei-os no Jira e retornei a tarefa ao desenvolvedor para correção.
Volto para as tarefas anteriores. O desenvolvedor volta das tarefas atuais para a tarefa retornada. Após as correções, o desenvolvedor retorna a tarefa para Mim novamente para teste. Encontrei defeito novamente e retornei a tarefa novamente. Isso pode durar muito tempo.
Como resultado, o tempo acumulado gasto em tarefas está aumentando em pouco tempo e, portanto, o tempo de colocação no mercado, o que é essencial para nós como empresa de produtos. Existem poucas razões para aumentar o esforço:
- Tarefa em constante movimento entre o engenheiro de teste e o desenvolvedor
- Tarefa que passa um tempo aguardando o engenheiro ou desenvolvedor de teste
- O desenvolvedor e o engenheiro de teste precisam alternar frequentemente o contexto entre as tarefas, o que causa perdas adicionais de tempo e energia mental.
Caso 2: fila de tarefas está aumentando
Existem alguns desenvolvedores em nossa equipe Scrum. Eles me enviam tarefas para testes regularmente. Isso forma uma fila de tarefas que eu procedo com base em prioridades.
É assim que trabalhamos há cerca de um ano. No entanto, durante esse período, a empresa cresce. O número de projetos e desenvolvedores foi aumentado e, portanto, o número de tarefas para teste. Ao mesmo tempo, eu ainda era o único engenheiro de teste em nossa equipe Scrum e não era capaz de aumentar meu desempenho em alguns momentos. Como resultado, mais e mais tarefas presas na fila para teste e processo de ping-pong também aumentavam o tempo de espera.
De repente, fiquei doente. A entrega de novos recursos da nossa equipe Scrum para a produção foi totalmente interrompida.
Que equipe deve fazer nessa situação? É possível solicitar uma ajuda do Engenheiro de Teste para outra equipe. No entanto, outro Engenheiro de Teste não está no contexto e não recebeu transferência de conhecimento antecipadamente, o que afetará negativamente a qualidade e o cronograma das duas equipes.
O resultado de ambos os casos no mesmo - as equipes também dependem dos engenheiros de teste:
- A velocidade da equipe é limitada pela velocidade do engenheiro de teste.
- Não é possível aumentar a quantidade de desenvolvedores sem adicionar engenheiros de teste, porque não faz sentido acelerar o desenvolvimento se todas as tarefas desenvolvidas estiverem presas na fila para teste.
- Enquanto o Engenheiro de Teste verifica a tarefa após o Desenvolvedor, o sentimento de responsabilidade do Desenvolvedor por uma qualidade está diminuindo.
- Se o Engenheiro de teste não estiver disponível, o processo de entrega está sofrendo.
Vamos adicionar engenheiros de teste?
A idéia óbvia - vamos aumentar a quantidade de engenheiros de teste. Isso poderia funcionar até certo momento: a quantidade de tarefas aumentará, mas é impossível aumentar a quantidade de engenheiros de teste continuamente. Vai ser muito caro e ineficiente.
Mais eficiente é manter velocidade e qualidade com os recursos atuais. Por isso, decidimos lançar um experimento que ajudará as equipes a criar funcionalidades com qualidade incorporada, assumindo riscos e casos extremos. Chamamos esse experimento de "Transformar testador em controle de qualidade", porque trata-se da transformação de uma função de testadores de macacos que procuram bugs no controle de qualidade que influenciam conscientemente e fornecem qualidade em todas as fases do SDLC.
Vamos melhorar os processos de desenvolvimento
Objetivos da experiência:
- Remova a dependência da equipe de engenheiros de teste que não perde em qualidade e tempo.
- Melhore o nível de garantia de qualidade fornecido pelos QAs e equipes.
O primeiro passo importante foi mudar a mentalidade da equipe. Esperava-se que todos os engenheiros de teste se importassem e fossem responsáveis pela qualidade.
Nossa idéia era que adicionar esforços na preparação e verificação de tarefas ajudará a reduzir o número de iterações de pingue-pongue. Portanto, permitirá fornecer novas funcionalidades na produção, mantendo níveis aceitáveis de velocidade e qualidade ou até melhorá-los.
Minha equipe Scrum, juntamente com engenheiros de teste de outras equipes, criaram um novo processo. Trabalhámos nesse processo por um ano e meio e corrigimos alguns problemas durante esse período, e agora o processo se parece com:
- Apresentação na declaração da tarefa.
- Solução técnica e cenário de teste.
- Desenvolvimento e verificação.
- Lançamento
Declaração de tarefa
Declaração de tarefa atual do proprietário do produto para uma equipe. A equipe analisa a declaração da tarefa para descobrir casos de canto do ponto de vista técnico e do produto. Se aparecerem perguntas para esclarecimento ou investigação, ela será rastreada como uma tarefa separada, com tempo dedicado em um sprint.
Solução técnica
Como resultado da análise, há uma solução técnica criada por um ou poucos desenvolvedores. Todos os colegas de equipe relevantes, juntamente com o controle de qualidade, devem revisar e concordar com isso. Solução técnica contém o objetivo da solução, os blocos funcionais do produto que serão afetados e a descrição das alterações planejadas do código.
Essa solução técnica permite descobrir uma solução mais leve e adequada, com base na experiência dos participantes relevantes do processo de desenvolvimento. Com a Solução Técnica detalhada, é mais fácil descobrir e evitar problemas de bloqueio, mais fácil realizar a revisão de código.
Aqui está um exemplo de alguns blocos na Solução Técnica:
Descrição da tarefa
Novas entidades ou abordagens estão sendo introduzidas no sistema?
Se sim, eles são descritos juntamente com a explicação de por que é impossível resolver tarefas com as abordagens atuais.
As interações dos servidores em um cluster estão mudando? As novas funções de cluster estão sendo introduzidas?
O Modelo de Dados está mudando?
Para servidor, trata-se de objetos e modelos.
Se o modelo de dados for complexo, ele poderá ser representado pelo diagrama UML ou pela descrição do texto.
A interação cliente-servidor está mudando?
Muda a descrição. Se for uma API, poderíamos publicá-la? Não se esqueça do tratamento de exceções, ou seja, registre os motivos corretos.
Cenário de teste
Em paralelo, os desenvolvedores ou o controle de qualidade estão criando cenários de teste assumindo casos de canto e possíveis pontos de problemas. Se ele foi criado pelo desenvolvedor, o controle de qualidade deve revisar a integridade. Se o Cenário de teste for criado pelo controle de qualidade, o desenvolvedor precisará revisar e confirmar se está claro como implementar cada ponto. A equipe também avalia os cenários de teste quanto à correção.
Para criar e manter cenários de teste, estamos usando o HipTest.
Desenvolvimento e verificação
O desenvolvedor cria um código de aplicativo baseado na solução técnica e assumindo casos de canto e cenários de teste. passando revisão de código e verificação de recurso em cenários de teste. Mescla ramificação para mestre.
Nesse estágio, o controle de qualidade oferece suporte ao desenvolvedor. Por exemplo, ajuda na reprodução de casos de teste complexos, configuração do ambiente de teste, realização de testes de carregamento, consultoria sobre o fornecimento de grandes recursos na produção.
Liberação da funcionalidade concluída
Esta é uma etapa final. Aqui, a equipe pode precisar fornecer ações de pré e pós-lançamento. Por exemplo, ative a nova funcionalidade para usuários beta.
Um novo processo de desenvolvimento exigia dos desenvolvedores um aprofundamento sobre o processo de teste.
Portanto, era importante que eu, como controle de qualidade, fornecesse todas as ferramentas necessárias e as estudasse sobre os Fundamentos dos testes funcionais. Juntamente com os QAs de outras equipes, compilamos uma lista da documentação necessária, criamos instruções de teste ausentes e atualizamos as existentes, incluindo o óbvio para os desenvolvedores.
Em seguida, concedemos aos desenvolvedores acesso a todas as ferramentas e ambientes de teste e começamos a executar o teste juntos. No começo, os desenvolvedores não queriam se responsabilizar pelos resultados dos testes, porque ninguém os verificou. Isso era incomum. Cada desenvolvedor tinha apenas o cenário de teste, funcionalidade criada pelo botão desenvolvedor e mesclagem. Mas eles se adaptaram rapidamente.
Resultados da Experiência
É meio ano desde o início do experimento. Há um gráfico da quantidade de bugs por semana. A quantidade de todos os erros descobertos é representada pela cor vermelha. A quantidade de bugs corrigidos é representada por verde. A linha amarela é o começo da experiência.
É visível que a linha vermelha permanece no mesmo nível, exceto o lance no início do experimento.
A quantidade de bugs não aumentou e, portanto, mantivemos o nível atual de qualidade.
Juntamente com o tempo médio gasto na tarefa, diminuiu 2%: 12 horas e 40 minutos antes da Experiência vs. 12 horas e 25 minutos depois. Isso significa que conseguimos manter a velocidade.
Como resultado, não há mais dependência do controle de qualidade em uma equipe. Se eu ficar doente ou sair de férias, a equipe continuará desenvolvendo sem perdas de velocidade e qualidade.
Estamos considerando a experiência bem-sucedida, apesar da velocidade e qualidade permanecerem as mesmas? Sim, porque, ao mesmo tempo, liberamos a capacidade de controle de qualidade para um trabalho consciente no produto e na estratégia de controle de qualidade. Por exemplo, para testes exploratórios, aumentando a cobertura funcional dos testes e descrevendo princípios e regras de criação de documentação de testes em todas as equipes.
Temos também a mentalidade do experimento inicial em outras equipes. Por exemplo, em um controle de qualidade da equipe, agora não testa o que descrito na solicitação de recebimento do desenvolvedor, pois o próprio desenvolvedor pode verificar isso. em outro controle de qualidade da equipe, analisando a solicitação pull e testa apenas casos de canto complexos e não óbvios.
O que você deve ter em mente antes de iniciar um experimento
É um caminho longo e complexo. Não pôde ser implementado imediatamente. Requer preparação e paciência. Não promete vitórias rápidas.
Esteja pronto para o time resistente. Não é apenas uma maneira de afirmar que, a partir de agora, os desenvolvedores verificarão a funcionalidade. É importante prepará-los para isso, criar abordagens, descrever os profissionais do experimento para equipe e produto.
A perda de velocidade no início é inevitável. Tempo para transferência de conhecimento para desenvolvedores, para a criação de documentação ausente e para alterações nos processos de investimento.
Não existe uma bala de prata Processos similares estão sendo implementados, por exemplo, no Atlassian, no entanto, isso não significa que seja possível implementá-lo em sua empresa como está. É importante adaptar o experimento à cultura e às especificidades da empresa.