Eu identifiquei 7 estágios-chave na evolução dos testes para ilustrar como as abordagens à garantia da qualidade nas empresas estão mudando. Durante a leitura do artigo, você poderá rastrear a evolução dos testes, determinar seu estágio atual e descobrir o que deve ser feito para melhorar o processo e a qualidade dos testes.
O artigo foi originalmente escrito para a revista CIS, mas acho que também será interessante para os usuários do Habr.
Então, os estágios.
- Não há testador. Suas funções são desempenhadas pelo desenvolvedor ou gerente.
- Os testadores aparecem, mas apenas testam projetos no estágio de conclusão.
- Os testadores verificam todas as tarefas dos desenvolvedores quanto à conformidade do resultado com a declaração original do problema.
- Os testadores estão envolvidos no design do teste.
- Um sistema de gerenciamento de testes está sendo introduzido.
- A automação de teste é exibida.
- A hierarquia se torna mais complexa, novas funções aparecem na equipe de teste.
Agora, sobre cada estágio com mais detalhes.
Etapa 1. O teste é realizado pelo desenvolvedor e / ou gerente
"Verifique - você mesmo" - a abordagem mais simples e "instintiva" dos testes. Uma coisa comum em pequenas empresas. Quando não é possível contratar um testador profissional ou não há entendimento da necessidade do teste, essa frente de trabalho é realizada por si só. Testar a si mesmo é a abordagem mais irracional e problemática. Por isso.
- O próprio desenvolvedor testa apenas os cenários que ele implementou com os dados que ele usou no processo de desenvolvimento. Com esses testes "no vácuo", cenários alternativos são omitidos. Como resultado, a vida faz ajustes e, como regra, ocorrem erros para os usuários finais.
- Se o gerente estiver testando, ele fará isso como um fardo adicional, sem possuir experiência e sem ter tempo e força moral para se engajar nos testes. Assim, você pode encontrar erros grosseiros, mas muitas nuances são negligenciadas.
- A atitude subjetiva em relação ao projeto, o desejo de aprová-lo rapidamente levam à tentação de fechar os olhos para uma série de problemas aparentemente "insignificantes".
Um caso extremo em que a empresa não realiza nenhum teste e um relatório de bug traz ... o cliente. Ele recebeu o lançamento, tudo já está no campo de batalha, informou o desenvolvedor no lançamento. O cliente abre o projeto e vê algum erro comum no banco de dados ou no servidor. Então, mais e mais erros. O cliente se torna um testador de seu próprio dinheiro.
Etapa 2. O testador verifica o projeto no final
A verificação de todo o projeto no estágio de pré-lançamento é um método clássico ao trabalhar no modelo Waterfall. O projeto é dividido em etapas globais (às vezes o projeto inteiro é uma etapa). Em cada estágio, o software é feito primeiro e somente depois testado. Os testes já estão lá, e isso é bom. Mas também existem problemas e problemas muito específicos.
Primeiro, quando testamos no final, erros sérios no nível da arquitetura serão encontrados tarde demais. Será necessário refazer uma grande parte, ou mesmo todo o projeto. Isso não é benéfico para ninguém.
Em segundo lugar, na ausência de documentação, só podemos realizar testes de superfície usando o método de pesquisa livre. Isso desativa imediatamente alguns dos cenários alternativos. Acontece que existe documentação, mas, no processo, as tarefas mudam e o produto final difere da figura no papel. Novamente, há dificuldades em testar e analisar relatórios de erros.
Terceiro, quase todo o tempo em que um projeto é geralmente colocado no desenvolvimento como uma tarefa prioritária. Deixe algum tempo para verificar. Mas não há tempo para corrigir erros, como resultado, algumas vezes, melhorias impressionantes desaceleram o projeto e interrompem os prazos.
O teste separado das etapas levanta outro problema. Entre as etapas, o testador esquece os detalhes do projeto e cada vez que precisa se aprofundar no que está acontecendo. Isso também é um desperdício de horas de trabalho.
Em geral, a verificação do projeto no final é lógica e aparentemente correta, mas esse método não leva em consideração o risco de detectar erros globais. Portanto, o teste evolui ainda mais.
Etapa 3. Todas as tarefas são verificadas quanto à conformidade do resultado com a tarefa original.
Além disso, a empresa entende que é melhor detectar erros à medida que eles se acumulam. Portanto, estamos mudando do modelo Waterfall para a metodologia Agile. Nesse ponto, os testadores estão mais intimamente integrados ao processo de desenvolvimento. Todas as tarefas começam a ser repetidamente testadas sequencialmente: separadamente, como parte do lançamento, em um ambiente de combate.
Nesta fase, as tarefas são verificadas quanto à conformidade com os requisitos estabelecidos. O Agile ajuda a funcionar melhor, mas nem todos os testadores, e especialmente seus líderes, estão prontos para se relacionar com os testes de uma nova maneira.
A cabeça espera velocidade e qualidade dos testadores, mas não há entendimento da necessidade de documentação de teste e realização de testes de regressão. Daí os problemas típicos desse estágio de evolução.
O teste é mais intuitivo do que estruturado. O princípio de "o que vejo é o que estou testando" domina. A cada iteração, diferentes verificações são feitas e em uma sequência diferente. Como resultado, você pode pelo menos pular o erro em uma das etapas de teste ou não vê-lo. Cenários alternativos e alterações na funcionalidade relacionada também podem desaparecer.
Além disso, o problema está no teste de regressão, que, se realizado, não é sistemático. De fato, o testador verifica o que considera necessário ou o que o desenvolvedor / gerente o aconselhou a verificar.
Etapa 4. Os testadores estão envolvidos no design do teste.
Nesta fase, o design do teste entra em cena. Os testadores começam a prestar atenção conscientemente à análise de requisitos. A funcionalidade é dividida em blocos lógicos, que são cobertos por listas de verificação ou casos de teste.
Lista de verificação - uma lista de verificações necessárias para testar a funcionalidade. As listas de verificação são mais comuns, pois são mais fáceis de manter atualizadas, especialmente como parte de um projeto grande e dinâmico.
Um caso de teste é uma sequência de etapas que devem ser executadas para verificar a funcionalidade. Uma descrição de cada etapa é acompanhada por uma indicação do comportamento esperado do sistema.
Aparece uma
documentação de teste completa, de acordo com a qual você pode acompanhar como uma determinada funcionalidade é verificada. A documentação de teste é útil não apenas para testes iniciais, mas também em testes de regressão.
Tudo isso é chamado de design de teste. Pode-se dizer que testes profissionais significativos começam nesta fase. Isso é mais do que apenas uma montanha de tarefas que precisam ser verificadas, mas um processo estruturado para analisar requisitos, gerar documentação de teste e teste direto. Incluindo a alteração da abordagem para testar dados. Os dados não são mais inventados espontaneamente no processo, mas são retirados de conjuntos pré-preparados.
Não há desvios óbvios na fase de design do teste. Em geral, este é um nível decente de teste. Para sites de produção de streaming ou projetos similares, o design de teste é mais do que suficiente. O principal é abordar o processo de teste corretamente: analisar o produto, elaborar documentação e realizar testes nele.
Etapa 5. Um sistema de gerenciamento de testes está sendo introduzido
Além disso, a empresa cresce com a necessidade de usar sistemas especializados para armazenar casos de teste (listas de verificação) e executar execuções de teste.
Esse sistema permite:
- armazenar requisitos e casos de teste;
- Associar requisitos a casos de teste
- analisar cobertura de teste;
- armazene versões diferentes de casos de teste;
- Executar execuções de teste
- realizar uma análise comparativa das execuções de teste;
- manter relatórios de teste;
- Acompanhe as cargas de trabalho da equipe para ajustar tarefas e recursos.
Um sistema é sempre um novo passo na evolução. No nosso caso, antes de tudo, o controle sobre o processo de teste é aprimorado. Gerenciamos melhor os testes e obtemos um novo nível de qualidade do produto.
Nos estágios posteriores do desenvolvimento do projeto, esse sistema ajuda todos os participantes a se lembrarem de como algo deve funcionar e como verificá-lo. O sistema acelera a introdução de novos participantes no projeto.
Etapa 6. As verificações regulares são automatizadas
No processo de desenvolvimento de projetos a longo prazo, é necessário automatizar verificações individuais. Para isso, desenvolvedores e testadores escrevem autotestes. Os desenvolvedores geralmente fazem testes de unidade, testadores fazem testes de interface do usuário. Eles começam cobrindo com autoteste cenários positivos do uso das principais funcionalidades: autorização, registro, publicação de registros e similares.
Os autotestes desenvolvidos são incluídos no processo de integração contínua (
CI / CD ), que permite à equipe aprender sobre erros imediatamente no momento da confirmação.
Os autotestes reduzem significativamente os custos dos testes de regressão e melhoram a qualidade do produto final. Mas para fazê-las, você precisa de um certo nível de testador. Também vale a pena saber que os autotestes não fazem sentido nos estágios iniciais de um projeto. O sistema está mudando rapidamente, portanto, para evitar erros fantasmas, também é necessário alterar os autotestes, o que leva tempo.
Etapa 7. A hierarquia se torna mais complexa, novos papéis aparecem
Chegamos ao estágio mais alto da evolução, quando a hierarquia no departamento de testes é significativamente complicada e especialistas estreitos aparecem: um gerente de testes, um líder de testes, um analista de testes, um projetista de testes e assim por diante.
A equipe está crescendo, as tarefas estão se tornando mais complicadas. Por exemplo, um
gerente de teste conhece mais sobre um produto e organiza os testes em um nível superior. Ele se comunica com mais frequência e proximidade com os clientes e o desenvolvimento do que com a equipe de teste.
O líder de teste organiza os testes no projeto e distribui tarefas dentro da equipe.
O analista de teste está envolvido na análise de requisitos, sua decomposição e priorização, prepara o material para o design do teste e os testes subsequentes. E o
designer de teste transforma os requisitos em listas de verificação e casos de teste.
Novas funções são necessárias em grandes projetos onde toda uma equipe de testadores trabalha. O surgimento de tais funções leva a um processo de teste ainda mais estruturado, sem o qual é impossível trabalhar em projetos de TI grandes e complexos.
Conclusões
Examinamos as principais etapas da evolução dos testes em uma empresa. O teste profissional consciente começa na fase de design do teste. O design do teste fornece uma melhoria constante na qualidade do produto.
O processo de desenvolvimento de teste nem sempre é linear. Você pode pular, combinar, misturar certos estágios ou ir imediatamente para um nível superior. Por exemplo, temos um sistema de gerenciamento de testes na Qualitica, ou seja, estamos no estágio 5. Agora, quase simultaneamente, temos especialistas restritos (novas funções, estágio 7) e automação (estágio 6).
Nem todo mundo precisa do sistema de gerenciamento de testes, autotestes e, mais ainda, de um projetista de testes. Mas, permanecendo na fase de testes instintivos ou nos limitando a verificações finais, é improvável que faça projetos complexos de longo prazo. Portanto, desejo que você encontre o ponto certo no desenvolvimento de testes e chegue a ele para melhorar a qualidade dos testes e oferecer aos clientes um produto de alta qualidade.