Get best of the week

Como melhorar o desempenho de equipes ágeis por meio de testes

O desenvolvimento ágil visa fornecer novos recursos de forma rápida e com a freqüência certa, garantindo um fluxo constante de alterações. Uma abordagem flexível permite que a equipe mantenha um ritmo alto, mas, por causa disso, a qualidade do código e a estabilidade do produto costumam sofrer. Como resolver esse problema sem levar a equipe a uma estrutura rígida e sem privá-la das vantagens dos métodos ágeis? A ajuda vem dos testadores. Meu nome é Denis Dubovoi, chefio o departamento de testes na Diretoria de Big Data do X5 Retail Group e, neste artigo, mostrarei como a aparência dos testadores ajudou a melhorar a qualidade do trabalho de nossos desenvolvedores.



Criando regras através de testes


As equipes ágeis geralmente negligenciam a qualidade. Isso se deve em parte ao fato de as metodologias de teste tradicionais não se ajustarem a um contexto "flexível", em parte devido à prioridade da velocidade sobre a qualidade. A principal tarefa da equipe ágil é implementar rapidamente as funções que um cliente comercial precisa. Isso é especialmente verdadeiro no estágio de formação de um produto, quando sua funcionalidade é determinada literalmente por tentativa e erro, e os desenvolvedores precisam reconstruir rapidamente o produto para solicitações atuais. Em tal situação, a equipe geralmente decide assim: chamaremos o testador mais tarde, quando fizermos o MVP / primeira versão de trabalho / aprendermos o Zen - porque ele simplesmente não entenderá como organizar o teste flexível. O resultado geralmente é interrupção nos prazos de entrega, erros na demonstração e, o pior de tudo, no ambiente da PROM.

No nosso caso, a situação era muito semelhante: o departamento de desenvolvimento de produtos de Big Data do X5 Retail Group existe há 2 anos e, inicialmente, a qualidade dos produtos era mantida apenas pelos próprios desenvolvedores - não havia uma função de especialista em controle de qualidade dedicada, e o departamento de testes e o primeiro testador do produto apareciam. apenas um ano atrás, quando os produtos já haviam começado.

Hoje, já existem 15 pessoas no departamento de testes: 11 testadores acompanham os produtos em equipes, duas pessoas desenvolvem a direção do teste de carga e mais duas - a direção da automação de testes. Em muitas equipes de produtos, os testadores se tornaram um catalisador para mudanças importantes: sua chegada simplificou o processo de desenvolvimento e melhorou a estabilidade da versão. Para fazer isso, conectamos testadores a equipes que já trabalham, de acordo com o seguinte esquema:

1. Mergulhe no processo


No primeiro estágio, precisamos entender como a equipe está trabalhando agora, como as funções são distribuídas nela e como as informações são trocadas. O testador começa a ajudar no teste, mais na forma de "controle de qualidade", avaliando simultaneamente a maturidade da equipe e os processos da equipe - para isso, existe um pequeno "mapa de calor" da maturidade, um exemplo disso pode ser visto abaixo. Nela, você pode ver como várias direções são desenvolvidas (desenvolvimento, teste, DG, DevOps, suporte) em cada um de nossos produtos.


Mapa de Calor de Maturidade

Os testadores coletam a avaliação da maturidade do processo junto aos desenvolvedores, avaliando o conjunto de práticas tecnológicas e metodológicas usadas pela equipe. Como resultado, podemos ver no mapa de calor o que e em que área é possível melhorar - por exemplo, desenvolver a prática de testes de unidade em desenvolvimento ou automatizar verificações de API em testes - para cada estágio da vida de um produto (protótipo, piloto, industrial), recomenda-se seu próprio conjunto de práticas.

2. Fazemos recomendações para melhoria




Depois de descobrir como a equipe vive, você pode pensar nas primeiras recomendações para melhorar seu trabalho. Aqui seguimos a seguinte lógica: os testadores não são uma função dedicada responsável por uma área específica, somos parte da equipe e podemos influenciar todo o processo. Para facilitar o lançamento de melhorias, começamos com o básico:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • Fixamos os estágios do sprint e um dos pontos críticos - o ponto "congelamento de código".

Examinamos os estágios antes do teste e um pouco do próprio teste, mas também há uma parte técnica com a manutenção de bancos de teste e o trabalho com dados de teste e uma parte industrial com suporte ao produto. Os testadores estão envolvidos de alguma forma em todas essas etapas - tentamos criar especialistas em T-Shape que veem todo o processo de produção, e não apenas sua função imediata.

3. Apresentamos nossas melhorias aos líderes de equipe e partes interessadas, focando em quais problemas essas melhorias resolverão


O processo será mais fácil se você contar com o apoio da equipe. É importante "vender" sua ideia, para mostrar que lucro suas alterações propostas trarão. Por exemplo, os critérios de aceitação que mencionamos acima podem parecer trabalho adicional para o analista, mas quando a equipe entende que economia de tempo receberá - e isso de horas para dias, o que pode levar para refinar a tarefa - facilita muito a melhoria.

Em alguns casos, você pode agir através do proprietário do produto. Por exemplo, o produto não possui monitoramento (por exemplo, técnico, com logs e belos gráficos) e não há tempo para configurar, porque essa não é uma tarefa do produto. Nesse caso, você pode entrar em contato com o produto e explicar exatamente quais benefícios ele receberá do monitoramento (ele não se tornará mais estável imediatamente, mas a velocidade da localização de problemas aumentará) e peça que ele aloque recursos para isso.
Paralelamente à padronização do trabalho em equipes de produtos, estão sendo desenvolvidas abordagens de teste que garantem a qualidade dos produtos, por exemplo, avaliando e preparando os volumes necessários de dados de teste, desenvolvendo um modelo de teste, formando pontos para automação futura etc.

Sempre há uma chance de a equipe não aceitar as alterações propostas, por mais razoáveis ​​que possam parecer para você. Em cada caso, é necessário formular suas próprias abordagens e procurar uma maneira individual de persuasão. Os produtos são muito diferentes e as abordagens que funcionam em um produto não funcionam em outro.

Muitas equipes estão confiantes de que são capazes de organizar seu trabalho, e às vezes isso é verdade. Houve casos em que nossa participação se resumiu em recomendar os principais pontos de verificação e, em seguida, a equipe implementou perfeitamente tudo no nível do código, e ficamos por perto, sempre prontos para ajudar. Porém, na maioria das vezes isso acontece de maneira diferente: nosso funcionário chega à equipe e os desenvolvedores começam a chorar de brincadeira com os defeitos encontrados pelo testador, regozijando-se com o fato de os defeitos terem sido encontrados antes da demonstração ou do lançamento industrial.

O que mudou


As mudanças nas equipes de produtos foram diferentes e afetaram diferentes aspectos do processo. Em uma das equipes, os testes a princípio se tornaram um gargalo: levou tempo e nem todo mundo entendeu o que estava acontecendo nesta fase. Como um experimento, conectamos os desenvolvedores à execução de testes, como resultado dos quais eles foram capazes de experimentar o trabalho dos testadores e até mesmo ver o produto como um todo - não uma função de relatório separada, por exemplo, mas desde a autorização do usuário no produto e a condução das operações comerciais até o final - descarregando relatório. Por isso, reforçamos o envolvimento de toda a equipe, tornamos o processo de teste transparente e mostramos a importância dessa ação, e a prática descrita acima se tornou regular.

Em outro produto, o ciclo de lançamento mudou com a nossa ajuda. Inicialmente, foi combinado que os resultados do sprint fossem testados na sexta-feira à tarde e na segunda-feira o produto já chegaria ao cliente. No final da sexta-feira, e apenas no início da segunda-feira, restava o teste e a correção de erros críticos e, como resultado, a nova versão era frequentemente “bruta” ou os desenvolvedores tinham que corrigir os bugs com urgência no fim de semana. Depois de algumas mudanças difíceis na entrega, a equipe ainda adiou a entrega do sprint para quarta-feira (não reduziu a duração do sprint, mas simplesmente mudou o cronograma em dois dias). Agora, a equipe tem tempo para verificar e corrigir a entrega em um ambiente descontraído.



A decisão final, de mudar ou não, permanece com a equipe: é ela quem é responsável pelo produto e por sua produção, e é por isso que escolhe a opção mais conveniente para si mesma. O objetivo do nosso trabalho não é impor nossas abordagens aos programadores, mas fornecer o máximo de informações sobre os possíveis riscos e oferecer melhorias e ações adequadas ao produto.

O que nosso departamento de testes conseguiu fazer no ano passado:

  • Testes funcionais regulares apareceram em 7 produtos do Departamento de Big Data do X5 Retail Group, 2 deles alcançaram versões estáveis ​​no PROM sem comentários críticos. Teste de carga regular organizado de 3 produtos.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

As mudanças são sempre complexas, mas são necessárias se torcermos por nossos produtos. E são os testadores que podem dar uma contribuição significativa para garantir a qualidade dos produtos.
Nos artigos a seguir, meus colegas e eu falaremos sobre como testamos produtos específicos, sobre como escolher uma estratégia de teste, sobre ferramentas (por exemplo, Allure Enterprise edition - uma ferramenta conveniente para gerenciar testes, relatórios e até mesmo gerenciar autotestes) e como implementar testes automatizados em pipeline e quais opções de desenvolvimento nós vemos (Test Driven Development, se você pensou sobre isso, essa é apenas uma das opções possíveis).

More articles:


All Articles