Oi Meu nome é Alyona Isakova, sou um dos principais testadores no Avito e quero contar sobre minha experiência na introdução de testes ágeis para a equipe. Quando li artigos sobre o teste Agile e o ATDD disponíveis em russo, tive a impressão de que "não estava na moda", "não era sobre o Agile". Parecia que era algum tipo de estrutura complexa que exigia a inclusão de desenvolvedores e, antes de ser aplicada, eu ainda precisava "arar e arar".

Por um tempo, vivi com essa ideia, escrevi uma lista de verificação de tarefas durante a criação de tarefas, colecionei reuniões da "equipe de recursos", para a qual PM, QA, Frontend e Backend foram convidados a discutir as nuances da tarefa antes da implementação.

Quem entende do que está falando já percebeu o problema, não é?

Se você pesquisar no Google o que é "teste ágil", poderá sugerir alguns cursos, alguns artigos com visões sobre a abordagem e a definição na Wikipedia:

"O teste ágil é uma prática de teste de software que segue os princípios do desenvolvimento ágil de software. O teste ágil envolve todos os membros de uma equipe ágil multifuncional, com experiência especial contribuída pelos testadores para garantir a entrega do valor comercial desejado pelo cliente em intervalos frequentes, trabalhando em um ritmo sustentável. A especificação por exemplo é usada para capturar exemplos de comportamento desejado e indesejado e codificar guia. "

Não conheço você, mas não terminei de ler esta definição pela primeira vez; fui atacado por desejo. De fato, nem tudo é tão seco. A conclusão é que o teste ágil é uma abordagem do processo de teste, na qual o testador está muito mais envolvido nos primeiros estágios da tarefa e menos (ou completamente ausente) nos últimos, diferentemente da abordagem em cascata.

Como nosso fluxo de tarefas foi organizado

Vale dizer que, inicialmente, nossa equipe trabalhou no rigoroso SCRUM, desculpe pela expressão, que obviamente combina bem com o teste Agile, você pode dizer que isso implica.

1. Declaração do cliente (assumir PM)

Nesta fase, a formulação do problema para nós foi realizada de acordo com o esquema História do usuário, Critérios de aceitação, Caso de uso. Essa afirmação, obviamente, Agile, não é acidental - é um mérito do meu colega da unidade, que já introduziu o teste Agile em sua equipe. Por que não pude emprestar apenas a experiência de uma equipe vizinha, falarei mais adiante neste artigo.

2. Revisão da declaração do problema pelo testador

Nesta fase, a tarefa foi verificada quanto à singularidade, consistência e utilidade. No meu caso, também adicionei o item "tests" aqui, que descrevia casos de teste adicionais (por exemplo, negativos), que eram inadequados para gravação no formato de Caso de Uso. Naquela época, eu não estava totalmente ciente de como usar os critérios de aceitação, então apenas tentei fornecer ao desenvolvedor o máximo de informações para minhas verificações futuras.

3. Discussão da tarefa por todos os interessados ​​ou pela "equipe de recursos"

O palco foi realizado conforme necessário. Se, após a revisão, o testador decidiu que a tarefa é clara e não são necessárias discussões adicionais, passamos ao quarto parágrafo.

Se o estágio era necessário, na reunião era feita clareza sobre os requisitos, trabalho adicional. Muitas vezes, a tarefa era decomposta, as condições de teste eram discutidas durante a operação independente do front-end e do back-end.

4. A tarefa seguida em uma lista de pendências, foi planejada, executada, implementada e trouxe benefícios e felicidade

Parece que tudo não está tão ruim, mas há algo a melhorar: pelo menos você pode remover algumas etapas extras, pois não entendemos por que elas estão.

O que foi feito para melhorar

Sentindo um desejo insaciável de melhorar, o desenvolvedor e eu passamos por uma master class interna em testes Agile. Verificou-se que, para cumprir totalmente com a abordagem, a equipe só precisa alterar a terminologia e apertar um pouco os parafusos de nossa bicicleta personalizada.
Introduzir a abordagem, observar as equipes em que ela já existe, não é suficiente; você precisa de um bloco de conhecimento e um estágio de conscientização, que no meu caso foi ministrado por uma aula de mestre. Uma grande vantagem foi o fato de termos passado por um treinamento com o desenvolvedor, que eu recomendo fortemente a todos, é difícil superestimar sua ajuda. Vocês dois (testador e desenvolvedor) são um mínimo necessário e suficiente para começar a implementar a abordagem. Além disso, cada equipe e produto é individual. Para refinar esse método, você deve pelo menos tentar.

Por exemplo, em uma equipe vizinha, há experiência no uso útil de testes de unidade com uma descrição preliminar em uma ferramenta para armazenar casos de teste e automação subsequente. Nossa equipe decidiu primeiro determinar a verificação necessária conceitualmente, automatizá-la e, em seguida, selecionar automaticamente os casos do código em uma ferramenta de armazenamento. Você pode ter sua própria maneira de interagir.

Não declaro que, sem um evento especial, seja impossível introduzir uma abordagem, em nenhum caso. Mas você precisa de um tempo para entender, motivar a equipe e começar a mudar e mudar. Esteja preparado para que nem todos aceitem imediatamente o aumento do tempo gasto na tarefa de braços abertos, tive sorte nesse sentido.

O que ler sobre este tópico

“Teste ágil. Curso de treinamento para toda a equipe ”, Janet Gregory e Lisa Crispin. O livro foi publicado recentemente em tradução russa e está disponível no Ozone.

O que exatamente mudou

1. Em nossas reuniões para esclarecer o atraso (PBR), eu me tornei um excelente aluno irritante, perguntando tudo: "O que acontecerá se o serviço de terceiros cair?", "O que acontecerá se retornarmos nulos, não 0?", "A por que chamamos isso, e não por lá? ”,“ E se não obtivermos todos os dados? ”,“ E se o planeta for capturado por dinossauros rebeldes? ” Brincadeirinha, apenas perguntas importantes, sem "nulo" e "0".
   Com o tempo, os caras perceberam que, em tal discussão, nascem vários casos não explicados com antecedência que agora podem prever. Anteriormente, perguntas como "O que acontece se tudo desmoronar?" Eu me perguntava na fase de testes e agora na fase de configuração.
2. Em vez do item "Testes" nas tarefas, escrevemos "Critérios de aceitação" em detalhes e conscientemente, e também determinamos o número e os níveis de futuros autotestes.
   Por honestidade, vale dizer que nem em 100% dos casos conhecemos os níveis de autoteste com antecedência. Há momentos em que tecnicamente não podemos fazer isso ou leva mais tempo do que temos na reunião. Na prática, muitas vezes não é possível agir dramaticamente. E isso é permitido - algo virá com o tempo.
3. Os itens “Revisão da declaração do problema pelo testador” e “equipe de recursos” não estamos conduzindo no momento. Resolvemos todos os problemas nas reuniões da PBR, pois todas as pessoas necessárias já estão aqui e os critérios de aceitação são discutidos no processo.
4. O testador é adicionado ao código de revisão do teste de unidade para confirmar se há verificações suficientes.
5. Em vez dos testes usuais de funcionalidade, no final do processo de desenvolvimento, os autotestes (em todos os níveis) são executados e apenas os testes de pesquisa são realizados.
   Idealmente, é claro, os testes não devem estar presentes, mas, em nossa prática, descobrimos que quando você faz alterações em um produto desenvolvido por muitas equipes, é mais fácil e correto adicionar testes de pesquisa.

Que dificuldades você enfrentou?

1. O que é um teste de unidade

Somos confrontados com o fato de que nós, QA, não entendemos quais testes de unidade estão testando e, portanto, não confiamos neles, e em homenagem à nossa vigilância, escrevemos testes um nível mais alto e com um calcanhar "para automatizar, você não pode ter piedade".

Conforme decidido:
Nós, com nosso desenvolvedor de formação ágil (agradecemos a ele e sua paciência), sentamos no canto e, por uma hora, ele me explicou nos dedos o que são os testes de unidade, o que eles comem e por que ainda não conseguem verificar "essa merda". Como resultado de nosso sofrimento, nasceu um incrível esquema de serviço: eles o desenhavam de tal maneira que eles mesmos entendiam.

Uma seta selecionada - uma viagem - uma verificação no teste de unidade

Como resultado, depois de alguns meses, eu mesmo escrevo alguns testes de unidade e excluo verificações redundantes nos níveis superiores. Isso, é claro, é principalmente copiar e colar, mas consciente!

Talvez você já entenda bem a essência dos testes de unidade e não precise gastar tempo com esse item. Caso contrário, subcautifique seu desenvolvedor em um ambiente calmo e ataque-o com perguntas.

2. Na implementação atual, nem todos os testes podem ser omitidos sem modificações

Conforme decidido:
Removidos conjuntos de dados desnecessários de testes e2e, aumentando o número de testes de unidade.
Já revisamos os testes de unidade que foram implementados, anotamos quais verificações queremos deles. Depois disso, com toda a expectativa, descobrimos que estávamos perdendo algumas das verificações.
Depois de determinar o que e em que nível queremos, definimos tarefas para o futuro.
Tendo treinado o que já está lá, adotamos a aplicação real da abordagem e começamos a escrever verificações sobre métodos que ainda não estão disponíveis. Já era mais difícil.

Conclusões

• A peculiaridade dessa abordagem é que ela é natural e cresce a partir de coisas como: “agregar valor ao usuário”, “reduzir o controle de qualidade manual”, “fornecer cobertura”. Como exatamente você fará isso é outra questão, mas essa abordagem tem algo a oferecer e sugere quais chaves mestras usar para simplificar sua vida e não perder nada.
  Por exemplo, "Práticas de teste ágil" são ferramentas prontas para aplicação, e "Valores" e "Princípios" são o que o testador de uma pessoa saudável entende, mas ainda vale a pena repeti-los para você e sua equipe, porque sei por experiência própria : geralmente são relegados para segundo plano no modo de alta carga.

  
  

• O principal na metodologia ATDD é que, antes de fazer algo, você precisa apresentar um critério para o trabalho realizado e um critério para o trabalho a ser feito corretamente. Grosso modo, a abordagem determina o período em que você concorda com a equipe. O resto vai junto com a peça.

  
  

Por exemplo, você percebe que em suas condições não pode distinguir a camada de integração de testes - tudo bem. Comece com os primeiros passos da abordagem: anote os critérios de aceitação, defina os testes e seus níveis, crie uma tarefa para um futuro melhor. O estágio mais útil aqui é a definição de verificações antecipadas, a partir de suas perguntas meticulosas no estágio de definição da tarefa - o resultado positivo mais rápido que provará à sua equipe que você não está desperdiçando seu tempo.

• Em geral, a abordagem de teste ágil e os valores, princípios e práticas propostos nela decorrem de coisas bastante óbvias, como meu professor favorito em álgebra superior disse: "Mas aqui é necessário aplicar o bom senso". Vale a pena seguir, e não apenas nos testes.

Uma vez, no meio de uma discussão, a equipe e eu percebemos que estávamos fazendo verificações em muitas condições, e isso nos levou à pergunta: "Estamos chamando o método exatamente com esse parâmetro?" Descobriu-se que a formulação do problema pode ser fundamentalmente simplificada chamando a própria essência, e não a lógica acima dela. Ou seja, as condições em que temos uma entidade dependente, mas não existe uma entidade em si, ela não existe. Isso tornou a vida mais fácil para nós.

Como determinar o nível do caso de teste, este é um holivar separado. Quando você começar a sentir dor, tente consultar a literatura. E lembre-se de que a prática deve ser aplicada onde realmente resolve o problema, onde facilita a vida. Tudo de bom, boa sorte e focas!