Conheça os autores do artigo de julho do “Calendário do testador ” Andrei Marchenko e Marina Tretyakova, testadores e analistas da Kontur. Neste mês, os caras falarão sobre modelos de fluxo de trabalho para testar análises e como eles começaram a testar análises antes do estágio de desenvolvimento. A experiência dos funcionários será útil para gerentes, testadores e analistas de equipes de produtos de médio porte que não moram em uma startup e para quem a qualidade é mais importante que a velocidade .

Modelos de fluxo de trabalho de teste do Analytics

Model 1

O testador trabalha com análises depois de receber a tarefa concluída. Ele valida a tarefa lendo análises como documentação do que o desenvolvedor fez. Tudo está errado, independentemente do nível de profissionalismo. Os defeitos podem estar na análise ou no código do desenvolvedor.

Contras:

• defeitos nas análises não serão detectados antes da fase de teste,
• existe o risco de que a tarefa do teste retorne ao analytics para revisão. Como resultado, a tarefa TimeToMarket aumenta significativamente.

Os erros de análise identificados durante o teste são caros ou muito caros.

Prós:

• o tempo do testador é reduzido para tarefas nas quais um analista não é necessário (infraestrutura, refatoração).

Model 2

O testador está conectado à tarefa mesmo antes de ser transferido para o desenvolvimento. Ele analisa os protótipos de uma tarefa ou apenas lê a documentação. O testador faz ao analista todas as perguntas da tarefa. O analista corrige imediatamente os comentários. O testador faz testes de aceitação.

Contras:

• o testador terá que estudar um campo adjacente (projetando análises e TK),
• alternando para esse modelo, o testador primeiro terá que gastar mais tempo testando, porque o processo "a tarefa concluída chegou - leio análises - estou testando" estende-se para "a descrição da tarefa futura chega - leio análises - estou testando análises - a tarefa final chegou - estou testando".

Prós:

• a probabilidade de encontrar erros de análise depois que a tarefa é transferida para o desenvolvimento se torna menor
• o testador já está no contexto da tarefa, quando chega a ele para testar, portanto, ele verifica mais rapidamente,
• a análise de teste expande perfeitamente os horizontes, oferecendo ao especialista a oportunidade para a futura transição para a análise,
• o desenvolvedor melhora a qualidade de seu código e do produto como um todo, porque antes de passar sua solução para teste, ele passa nos testes de aceitação.

Se a equipe de desenvolvimento não revisar o trabalho dos analistas, a análise de teste melhora a qualidade do produto e reduz o risco de transferir tarefas para o desenvolvimento com erros no ToR.

Quando recomendamos o segundo modelo para testadores que trabalham no primeiro modelo, ouvimos muitas vezes:

• "Temos alinhados e, portanto, temos tarefas atuais suficientes para levar mais".
• "Fale com o gerente."

Redesenhar o processo de desenvolvimento é uma tarefa administrativa séria.

Implementar testes de análise antes do desenvolvimento

Por quase um ano, como no projeto Kontur , o padrão no processo de desenvolvimento é um estágio obrigatório de "teste de análise". A equipe não chegou a isso imediatamente. O ímpeto foi o aumento no número de retornos de tarefas dos testes para o estágio analítico e o refinamento adicional.

Foi especialmente doloroso para grandes tarefas com novas funcionalidades. As tarefas de front-end transferidas para a fase de teste eram brutas, muitas vezes interrompidas nos cenários mais simples, implementadas de maneira diferente em vista da "dupla dobragem" de definições e termos em análises.

O processo de teste de análise não aparece com o clique de um dedo ou qualquer tipo de mágica. Este é um trabalho minucioso, mas pode ser dividido em etapas.

Etapa 0. Venda à equipe a ideia de testar análises

Você pode facilmente imaginar uma situação quando de repente recebe feedback do seu trabalho com comentários, sugestões e correções. O primeiro pensamento de qualquer pessoa normal seria: “Por que você decidiu me testar? Eles não confiam em mim? Eles monitoram a qualidade do meu trabalho? Nesse estágio, é muito importante que o analista não tenha a sensação de que ele está sendo verificado quanto à qualidade e, em caso de falha no teste, ele será demitido.

Uma série de perguntas pode ser removida se as informações forem apresentadas na chave: “isso nos dará a oportunidade de aprender sobre novas funcionalidades mais cedo, acelerar a fase de testes e impedir a introdução de pequenos defeitos no código”.

Quando o estágio 0 estiver concluído, você poderá seguir em frente.

Etapa 1. Implementação de testes analíticos no processo de desenvolvimento

Depois de convencer a equipe, começamos a introduzir testes de análise no fluxo de trabalho diário. Se inicialmente o fluxo de trabalho estivesse assim:

Que após a implementação:

Se sua equipe tiver vários analistas que realizam uma revisão um do outro antes de atribuir a tarefa ao desenvolvimento, prosseguimos testando um texto melhor. Queremos dizer que a análise analítica não a está testando, mas apenas uma parte dela.

Etapa 2. Teste de análise

Existem tarefas em que os protótipos substituem a versão em texto do analytics.

Nesse caso, o protótipo também é verificado como texto. Se os protótipos complementarem a análise, é útil examinar os layouts de design das funcionalidades futuras antes de ler a documentação. Esta é sua única chance de olhar para a tarefa como um usuário que não leu o TOR e não sabe como tudo funciona e deve funcionar.

O que pode ser verificado na análise:

1. A solução proposta atende aos objetivos da tarefa.

Por exemplo, se o objetivo da tarefa é coletar feedback dos usuários, a solução deve envolver o registro e o armazenamento de respostas do usuário.

2. Exclusividade de interpretação.

Por exemplo, a expressão “mostrar informações para o dia atual” pode ser interpretada de maneira diferente. Você pode entender como "mostrar informações para o dia selecionado nas configurações" ou como "mostrar informações para o dia igual a hoje".

3. Viabilidade da decisão.

Viabilidade é a capacidade de implementar os requisitos escritos na analítica sob as limitações conhecidas do ambiente de desenvolvimento, linguagem de programação e complexidade algorítmica. Bons analistas podem ter em mente o algoritmo pelo qual podem resolver o problema que escreveram. Não é fato que os desenvolvedores façam esse algoritmo (eles são mais conhecedores, encontram maneiras de otimizar o algoritmo etc.), mas sua presença indica a viabilidade da tarefa.

4.Testabilidade.

Não é claro como verificar se a condição "melhorar os resultados da pesquisa". Mas se reescrevermos a condição em “os resultados da pesquisa devem ser mostrados ao usuário dentro de 1 segundo depois de pressionar o controle“ Pesquisar ”- está claro.

5. A disponibilidade de cenários alternativos.

No texto “Se o número e a data estiverem indicados, imprimimos o número e a data. Se a data não for especificada, imprimiremos apenas o número "não há scripts suficientes:

• não há número, mas há uma data,
• sem dados.

6. Manuseio de exceção.

No texto “Você pode fazer o download de um documento apenas no formato Excel”, não está claro o que deve acontecer se carregarmos arquivos de outros formatos e que erro veremos ao fazer o download deles.

Artefatos ao testar análises

Quais artefatos podem permanecer após o teste da análise:

• casos de teste compilados
• listas de verificação para desenvolvedores.

Lista de verificação para o desenvolvedor - as verificações necessárias, abrangentes e básicas dos principais cenários que devem funcionar para serem testados. É também uma ferramenta para melhorar a qualidade do código. Antes de enviar a tarefa para teste, o desenvolvedor passa na lista de verificação, identificando rapidamente os erros por conta própria.

O desenvolvedor deve ser persuadido a examinar a lista de verificação do testador, removendo as preocupações internas do desenvolvedor "eles me testam", concentrando-se em "acelerar o processo, acelerar os testes, melhorar a qualidade". Como resultado, nosso desenvolvedor passa por essas listas de verificação e está feliz por não ter sido o testador que encontrou os erros, mas ele próprio ("ninguém descobrirá o que eu errei em um cenário de besteira").

Qual é o resultado

À primeira vista, parece que a introdução de uma nova etapa no processo de desenvolvimento aumentará apenas o TimeToMarket, mas isso é uma ilusão. No início, é claro, o processo de teste de análise será novo e não testado, e o testador passará mais tempo nele. No futuro, ganhando experiência, ele será capaz de conduzi-lo mais rapidamente. E os resultados obtidos no estágio de análise de testes reduzirão o tempo no estágio de testes diretos e reduzirão ao mínimo o número de retornos.

Esse processo de teste de análise foi implementado em várias equipes da Contour. As equipes de desenvolvimento receberam várias vantagens inegáveis:

• economizando tempo no estágio de teste: não há custo para o projeto e a análise de testes, pois tudo já foi feito com antecedência,
• acelerar o feedback para o desenvolvedor através da lista de verificação, antes de encontrarmos erros críticos,
• todas as partes interessadas podem pré-verificar as listas de verificação e adicionar algumas verificações (no estágio de teste, essa ação é "mais cara").

Acreditamos que você será capaz de obter essas vantagens implementando a fase de testes analíticos em seu projeto.

Lista de artigos do calendário:
Tente uma abordagem diferente
Teste de par razoável
Feedback: como acontece
Otimizar testes
Leia um livro
Teste de análise
O testador deve pegar o erro, ler Caner e organizar a mudança.
Carregar serviço
Métricas de serviço de controle de qualidade
Teste de segurança
Conheça seu cliente
Receber lista de pendências