Você certamente pode ficar sem uma estratégia de teste se tiver um número infinito de funcionários qualificados, tempo e dinheiro. Em uma palavra, a capacidade de cortar uma versão ao longo dos anos. Nessas condições ideais hipotéticas, nenhuma estratégia é necessária, porque você pode testar seu produto de todas as formas existentes pelo tempo que desejar, aplicando as técnicas em qualquer ordem, por vários círculos, e mais cedo ou mais tarde, de alguma forma, você chegará à qualidade de produção pronta.

Na realidade, o projeto sempre acaba com o prazo, as habilidades / habilidades de trabalho da equipe não são de borracha e os requisitos do produto estão em constante evolução - e aqui você não pode prescindir de um bom plano. Portanto, uma estratégia de teste vem em socorro.

Neste artigo, ofereceremos perguntas que precisam ser discutidas para elaborar uma estratégia de teste e mostrar com exemplos como as decisões são tomadas sobre as ferramentas de teste em um caso específico.

0. Vamos descobrir na praia

Por que precisamos de uma estratégia de teste?

• Organizar o processo em condições de recursos limitados. Portanto, para começar, seria bom perceber quais recursos temos.
• Para que todos os participantes do projeto compreendam o papel do teste, o que ele pode oferecer, que lucros obteremos com isso. Para que todos tenham igual expectativa e entendimento do que está acontecendo no campo do controle de qualidade. E também para identificar possíveis problemas que inevitavelmente se tornarão aparentes no processo de discussão.

Quem compõe a estratégia?

Antes de tudo, é claro, controle de qualidade e necessariamente um gerente de projeto.

Então, pegue o gerente de projeto ou o testador manualmente, despeje café, leve papel, marcadores, laptops e ... vamos lá!

1. Que tipos de teste usaremos no projeto e por que

Desde o início, oferecemos recordar todos os tipos de testes existentes e decidir sobre cada um: será que vamos usá-lo e por quê. Vejamos alguns exemplos de como você pode decidir sobre a necessidade de um tipo específico de teste.

Instalação da versão de teste

De qualquer forma, mesmo que o aplicativo seja completamente novo e esteja sendo instalado (implantado) pela primeira vez, é necessário verificar como ele decolou: se é iniciado, se é possível começar a trabalhar com ele. Seja um aplicativo móvel, desktop ou web.

Para aplicativos da Web, é útil discutir como verificamos se os dados após a atualização não são perdidos. Que tipo de comportamento esperamos de uma sessão ativa.

Para aplicativos de desktop e móveis, é necessário pensar em uma maneira de entregar a nova distribuição ao usuário e o processo de atualização, que é iniciado pelo usuário.

Para todos os projetos, é útil discutir assuntos como o aquecimento do sistema: instalação de diretórios, configuração de usuários e outros dados necessários para o usuário iniciar o sistema.

Teste de desempenho

Tais fatores influenciarão a decisão: quantos usuários trabalharão no sistema, quantos dados serão processados.

Dado	Solução
Sabemos que 10 pessoas usarão o produto. E sabemos que eles entregarão tabelas de vários milhares de registros.	Faz sentido planejar testes de volume com grandes quantidades de dados.
Sabemos que, no processo de uso do produto, os usuários farão o upload de muitos arquivos de mídia no servidor do cliente.	Você precisa descobrir para que tipo de carregamento esse servidor foi projetado e manter esses dados em mente.
O aplicativo é usado por várias pessoas por semana, a quantidade de dados é mínima.	O teste de desempenho não é necessário.

Teste de regressão

Uma verificação completa de todo o sistema sempre leva muito tempo. Portanto, para tomar uma decisão, é necessário avaliar a adequação: quanto tempo é necessário para uma regressão completa e os riscos que podem ocorrer se não a conduzirmos.

Dado	Solução
Lançamos a primeira versão de um produto ou módulo de programa.	O teste de regressão não é necessário.
O projeto é muito grande e uma regressão completa antes do lançamento de novos recursos leva um tempo comparável ao período de desenvolvimento. A taxa de fornecimento necessária não permite isso.	Decidimos que não realizamos testes de regressão, mas prestamos mais atenção a outros tipos de testes e monitoramento.
A interação entre microsserviços é coberta por testes de contrato.	Uma regressão completa é impraticável. Na estrutura do teste manual, realizamos uma regressão da funcionalidade por recomendação do desenvolvedor.

Teste de integração

Para determinar a necessidade de teste de integração, é útil listar todos os sistemas externos com os quais o produto interage e indicar quais dados recebemos e transmitimos.

Dado	Solução
Os dados de vendas do portal são transferidos para o sistema analítico.	É importante não apenas verificar se as vendas se foram, se foram no formato correto, mas também se elas vieram no formato correto - nada foi perdido ao longo do caminho.

Teste de localização

É importante responder a perguntas sobre o projeto:

• quais idiomas devem ser suportados
• fornecemos a conexão de localizações adicionais durante a operação da solução,
• Em quais países nossos usuários trabalharão,
• haverá vendas e em que moedas
• Você precisa trabalhar com fusos horários?

Dado	Solução
O sistema possui 2 idiomas: russo e inglês.	Faz sentido discutir como entenderemos a interface em qual idioma mostrar ao usuário.
O cliente pede para tornar o aplicativo multilíngue.	Vale a pena responder a si mesmo às perguntas de como verificaremos os textos, de onde obteremos os textos em árabe, como a tela será adaptada para o texto escrito da direita para a esquerda.

Entre navegadores e plataformas

Não podemos verificar o funcionamento correto do aplicativo móvel em todos os dispositivos em geral. No caso de um aplicativo Web, surge imediatamente a pergunta: apoiaremos o IE9? Antes de inserir esse tipo de teste na estratégia, analisamos (se a solução já está funcionando) ou assumimos (se já não estiver funcionando) para que eles serão usados.

Dado	Solução
Os usuários de aplicativos móveis são funcionários em todo o país.	Examinamos as estatísticas existentes sobre o uso das plataformas de nosso aplicativo e tomamos uma decisão sobre qual delas será testada.
Nossa aplicação possui usuários corporativos em máquinas estacionárias.	Provavelmente, podemos recomendar o uso de apenas um navegador. E, assim, reduza o tempo para testes e suporte à compatibilidade entre navegadores.

Da mesma forma, você precisa analisar todos os outros tipos de teste:

• Funcional (realizado ou não),
• Aceitação (quem a conduz e como),
• UX / UI (quais são os critérios objetivos para uma boa interface)
• Modular e unitário (quem escreve testes de contrato, quem escreve testes de unidade e se nós os escrevemos),
• Teste de segurança (que garante a segurança dos dados e quão resistente é o sistema contra hackers),
• Falha e recuperação (como o sistema se comportará em uma emergência)

e outros

2. Prioridades nos testes

A força maior acontece em todos os projetos, por isso é útil ter uma folha de dicas com um plano bem elaborado, em vez de usar botões aleatórios.



No modo normal, prioridades significativas também são importantes. Por exemplo, o desenvolvimento de autotestes deve ser planejado levando em consideração as prioridades: primeiro, os cenários mais críticos são automatizados (teste de fumaça).

Dado	Solução
Nosso programa é usado nos aeroportos para vender serviços aos passageiros ao embarcar em um avião. E se neste momento ocorrer algum tipo de erro, não teremos tempo para uma correção. Portanto, não deve haver erros!	Verificamos o cenário de uso no aeroporto em primeiro lugar.

3. Ambiente para o trabalho

É necessário pensar e coordenar com a equipe quais ambientes são necessários para o trabalho e quem os usará. Como regra, 2-3 ambientes e vendas são suficientes.

Dado	Solução
No projeto CD / CI, testes de fumaça foram escritos para o teste inicial de funcionalidade.	Precisamos de um ambiente para a montagem primária do código em uma ramificação, a execução de testes de fumaça, em que sistemas externos são fechados por stubs. Você também precisa de um ambiente para testes manuais e de integração com o atendimento ao cliente (QA).
As sessões de teste beta são realizadas regularmente.	Precisamos de um ambiente que seja visível "fora", mais estável que o ambiente de controle de qualidade.

4. Trabalho do testador no projeto

Faz sentido discutir antecipadamente todas as atividades que esperamos do testador no projeto, porque elas não são necessariamente as mesmas em todos os projetos. Pode ser uma surpresa para alguém da equipe que o testador esteja fazendo algo ou não.

Esse item ajudará os gerentes a entender qual o nível de competência exigido do testador e a qual carga de tempo é esperada. Para projetos existentes, também é importante indicar que nós (QA) somos capazes de fazer com que o gerente entenda o que significa.

Por exemplo, poderia ser:

• avaliação dos objetivos do sprint quanto à integridade e consistência,
• avaliação dos custos de mão-de-obra para testes,
• preparação de listas de verificação para teste (ou casos de teste),
• revisão de script de autoteste
• escrever autotestes funcionais,
• teste manual direto,
• implantação de mudanças no ambiente,
• atualização de estratégias de teste etc.

5. Documentação de teste no projeto

É necessário concordar em terra e, possivelmente, revisar mais e regularmente o formato da documentação do teste:

• qual documentação de teste realizaremos no projeto,
• vamos escrever casos de teste
• faça listas de verificação
• e com que frequência atualizar esta documentação.

Dado	Solução
Cerca de 300 casos de teste já foram gravados para cerca de um terço da funcionalidade do sistema. Eles devem ser revisados ​​não apenas periodicamente, mas também atualizados periodicamente.	Em condições de recursos limitados, decidimos não trabalhar com casos de teste, mas nos restringir a listas de verificação para cada tarefa específica. E, como resultado, economizamos tempo na documentação de suporte sem perder a qualidade dos testes.

6. Como os casos de teste são gerados

As condições e cenários operacionais dependem da solução específica, portanto, discuta:

• que técnicas de design de teste faz sentido usar. Como parte deste parágrafo, é útil fazer uma lista de objetos com os quais o aplicativo trabalha e suas classes de equivalência.
• que heurística e experiência de vida banal ajudam a criar scripts de teste para um projeto específico. Para aplicativos móveis, é conveniente usar heurísticas padrão, por exemplo, "Eu me diverti".

Dado	Solução
No projeto de seguro, o usuário (agente) deve inspecionar a máquina, durante a qual é necessário tirar fotografias e enviá-las ao servidor. O senso comum determina que dificilmente haja wifi nas garagens. E, às vezes, não há conexão móvel.	Portanto, você precisa verificar o aplicativo não apenas ao trabalhar com 3G, mas também na ausência de comunicação como tal.
Qualquer ação do usuário no aplicativo móvel da companhia aérea faz parte de um cenário. Por exemplo, você não pode emitir um ticket sem antes criar uma reserva.	Portanto, é lógico usar a técnica "caso de uso".

7. O procedimento para trabalhar com o rastreador

Em rastreadores diferentes, as possibilidades e os tipos de tarefas diferem. Com base nas capacidades do rastreador, aconselhamos que você concorde com quem e por que princípio determina a prioridade das tarefas, em que tipo de tarefas para organizar bugs e tarefas.

Fale os pontos principais com a equipe:

• Como vamos distinguir entre os erros encontrados por nós e os erros encontrados pelos clientes (e se precisamos distinguir entre eles),
• Como fazer melhorias
• É necessário distinguir as melhorias que nós mesmos inventamos daquelas que o cliente solicitou. Como
• Qual status um erro deve ser cometido se não acontecer novamente,
• Qual status é considerado final.

Dado	Solução
O testador cria um erro. O desenvolvedor não pode reproduzi-lo, converte-o em status rejeitado.	O testador verifica novamente a tarefa e define o status como Fechado (final), se o erro realmente desaparecer, ou refina a descrição e retorna para Novo.
O cliente define a tarefa para revisão. O desenvolvedor entende que ele não tem dados suficientes para implementar.	O desenvolvedor coloca a tarefa no status Feedback.

(Escrevemos mais sobre maneiras de descrever bugs e histórico de usuários neste artigo ).

8. Critérios para iniciar e terminar o teste

Se o testador executar qualquer tarefa a qualquer momento, isso não é ordem, mas caos. Porque a tarefa pode não estar pronta. Ou pronto, mas não gratuito. Ou pronto, implantado, mas depende de outras tarefas que ainda não estão prontas. Como resultado, o testador gasta tempo e nervos procurando e corrigindo erros, mas na verdade você só precisa esperar. Portanto, concordamos em que ponto a área de responsabilidade do controle de qualidade sobre a tarefa começa e termina.

Nos estágios iniciais do desenvolvimento do projeto, a prontidão da tarefa / versão é determinada pelos olhos.
Com o crescimento da autoconsciência, entendemos que precisamos de critérios claros de que a tarefa / versão está pronta. Para que essa decisão seja transparente para todos, e não "o testador sente o valor de que tudo está normal". Por exemplo, no contexto de um CD sintonizado, acreditamos que a tarefa está pronta para teste assim que é implantada no ambiente de controle de qualidade e tem o status Resolvido.

Dado	Solução
Um processo foi configurado no projeto em que uma lista de verificação para teste é compilada para cada revisão.	Consideramos a tarefa verificada se passamos todos os pontos da lista de verificação.
O projeto está trabalhando em sprints.	O Sprint é considerado pronto se todas as melhorias estiverem no status Fechado e não houver erros com a prioridade Normal e superior.
O projeto compilou uma lista de funcionalidades por prioridade.	Acreditamos que a versão está pronta para lançamento, se a funcionalidade dos primeiros pontos da lista funcionar com êxito.
O projeto escreveu casos de teste e realizou testes de regressão antes do lançamento.	Uma versão é considerada pronta para liberação se, com base nos resultados do teste de regressão, nenhum erro com prioridade Normal ou superior for encontrado (ou a porcentagem de cenários malsucedidos não for maior que 5).

9. Ferramentas para o trabalho

A seção é útil para colocar as tarefas no comando (para o administrador e o gerente) já no estágio de planejamento dos testes e obter todas as ferramentas necessárias no início do trabalho.

Vale a pena discutir essas questões:

• Quais ferramentas precisamos para conduzir a documentação de teste,
• Quais ferramentas podem preparar dados de teste,
• Quais ferramentas são necessárias para automação.

Dado	Solução
Para descrever a funcionalidade implementada, decidimos usar mapas mentais.	Os funcionários da equipe trabalham em plataformas diferentes, então você precisa escolher um formato de arquivo de mapa mental com o qual possa trabalhar no Windows, Linux e Mac.
Concordamos que precisamos de automação no projeto.	Portanto, precisamos de ferramentas que nos permitam preparar dados de teste (por exemplo, rolar scripts no banco de dados), permitir o lançamento no pipeline (por exemplo, newman) e criar stubs (por exemplo, WireMock).

10. Ferramentas de avaliação e monitoramento da qualidade do projeto

Nesta seção, propomos concordar com o que são os KPIs para avaliar a integridade do aplicativo (além do cálculo óbvio da cobertura do teste). Este indicador deve ser mensurável e alcançável. Em particular, entenda e responda às seguintes perguntas:

• Como rastrearemos os erros no prod
• Como coletaremos feedback dos usuários,
• Como vamos coletar estatísticas sobre o uso de nossos recursos.

Dado	Solução
Após o lançamento de um novo recurso do sistema, o monitoramento de uso é configurado (por exemplo, o número de vendas de serviços).	O declínio é um gatilho para a investigação. Talvez o recurso não funcione conforme o esperado ou não implementamos parte do script.
Configuramos o programa para monitorar a velocidade de execução das operações básicas.	O critério para a qualidade do trabalho será que, com um fluxo de usuários, a velocidade de execução não diminua.

Conclusão

Não existe uma estratégia de teste única e universal, adequada para todos. Ele é projetado individualmente para cada projeto.

• É importante entender que a estratégia não deve ser um fim em si mesma - é apenas uma ferramenta que nos permite alcançar nossos objetivos.
• É bastante normal que nem sempre seja possível responder imediatamente a todas as perguntas feitas. É uma ocasião para conversar novamente com o cliente ou usuários do produto.
• O projeto está crescendo e, se ontem foi muito cedo para se preocupar com a produtividade, amanhã provavelmente será a hora. Portanto, após elaborar uma estratégia, é importante atualizá-la e reabastecê-la regularmente e trazer mudanças para a equipe.
• Depois de escrever uma estratégia, geralmente fica claro onde estão as falhas nos testes e o que precisa ser feito. É uma ocasião para definir objetivos, observar a dinâmica e ... atualizar a estratégia depois de algum tempo.