Há algum tempo, escrevi
um artigo sobre minha experiência na organização do trabalho do engenheiro de controle de qualidade em um projeto. Agora, quero continuar esse tópico, mas em uma direção mais restrita - a automação de teste. Será
sobre o mesmo projeto , é pequeno, mas em desenvolvimento de acordo com as solicitações dos clientes regulares. Talvez minha abordagem não seja muito adequada para equipes com dezenas de funcionários e cada uma seja responsável por sua parte (na minha opinião, cada projeto deve ser estritamente regulamentado; caso contrário, é simplesmente impossível gerenciar um colosso, embora eles encontrem um grão saudável), mas ele certamente será interessante para aqueles que, como eu, chegaram a um novo emprego e ficaram na encruzilhada de como organizar seu próprio lugar sob o novo sol.
Preparando-se para estudar
Então, como você pode organizar a automação de teste em um projeto? Se sua resposta é levar o maravilhoso Selenium e algum tipo de estrutura para ele e assim por diante, a partir dos 13 anos de experiência em testes, eu não faria isso com certeza. Terá que dominar novos horizontes.
O que é preocupante com a abordagem de "entrar em ciclos de selênio"? E o fato de você já ter lido e ouvido mais de uma vez. O fato de esses testes serem da interface do usuário é caro e demorado, tanto na escrita quanto na execução, e na manutenção do desempenho. Todo mundo sabe disso, mas toda a dor dessa verdade é encontrada apenas quando é ignorada. Os autotestes de ponta a ponta da interface do usuário devem ser obrigatórios; ninguém, exceto eles, dará a você a confiança de que o que o cliente
vê após a próxima implantação não será uma decepção para ele. Mas eles não devem se tornar o centro de automação dos seus testes.
Tome os
Princípios da Pirâmide de Teste como seu Centro de Controle de Qualidade. Os mesmos, sobre os quais muito já foi dito, mas, na prática, nem todo controle de qualidade entende como aplicar essa pirâmide.
É desenhado assim:
E assim:
Todos encontrarão uma opção para sua arquitetura.
Colocando os princípios da pirâmide de teste no controle de qualidade
Primeiro, por mais preguiçoso e incomum que seja, domine os testes de pele branca e torne-se um "desenvolvedor parcial".Crie o projeto localmente, assim como todo desenvolvedor (com certeza, o projeto possui documentação sobre como fazer isso, localize-o). Você provavelmente deixará de xingar esse negócio uma dúzia de vezes, e pela primeira vez terá um milhão de perguntas e problemas, mas quando fizer isso já saberá muito: quais são as idéias arquitetônicas, qual banco de dados, onde de onde são encaminhadas e onde estão as configurações necessárias e, mais importante, onde os autotestes são armazenados e como executá-los.
Em segundo lugar, lide com os autotestes escritos pelos próprios desenvolvedores.Encontre seu lugar na estrutura do projeto, que tipos de teste e ferramentas são usados, como eles são lançados. Avalie a cobertura do projeto com autotestes, saiba como navegá-los. Existem muitas ferramentas para avaliação automática da cobertura, você pode usá-la, mas não estou falando sobre isso agora. Eu sou mais sobre o desenvolvimento de seus instintos: pegue uma funcionalidade e veja como ela é coberta por testes automáticos: bom ou ruim. Se for bom, fique calmo para esta parte; se for ruim, você se encontrará como uma frente de trabalho para aqueles dias em que não há tarefas urgentes na agenda. Enquanto isso, lembre-se de que, durante cada execução, lembre-se de que esse lugar no código é vulnerável.
Em terceiro lugar, tenha coragem, revise a solicitação de recebimento dos desenvolvedores.Toda vez que você começar a desenvolver um novo funcional, anote todos os casos de teste. Marque aqueles que você deve necessariamente automatizar para não retornar ao teste manual dessa funcionalidade. Revise as solicitações de recebimento dos desenvolvedores e exija razoavelmente a implementação dos autotestes que eles perderam. Muitas vezes me deparei com desenvolvedores muito legais que escreveram testes interessantes, mas mesmo eles renderam um bom controle de qualidade para entender como exatamente o cliente final provavelmente usará o produto. Portanto, mesmo para especialistas experientes, há algo a recomendar ao escrever autotestes.
Quarto, seja ainda mais corajoso e escreva autotestes diretamente no código do produto.Sim, assim como os desenvolvedores. Em pé de igualdade com eles. Toda vez que você encontrar um caso de teste que precisa ser automatizado, não se apresse em implementá-lo imediatamente com ferramentas separadas que são usadas apenas na equipe de controle de qualidade. E antes de tudo, faça a si mesmo a pergunta: ele pode ser automatizado através de autotestes de unidade / integração no código do produto? Se sim, faça exatamente isso. Se é assustador, isso é assustador apenas pela primeira vez, mas qual o nível de suas habilidades, porque programadores experientes analisarão suas solicitações de recebimento. Sim, a princípio tudo o que você fez será explodido em pedacinhos, mas o desenvolvimento sempre envolve dor :) Mas, no final, você receberá dividendos maravilhosos:
- esses testes serão suportados por toda a equipe de desenvolvimento
- eles trabalharão continuamente, continuamente e rapidamente
- eles serão integrados ao CircleCi e executados toda vez que forem implantados automaticamente (se isso for implementado no projeto)
- os buracos serão corrigidos no teste (você escreve o que não foi escrito antes de você)
- você pode ajudar os desenvolvedores a escrever testes se não tiverem tempo
Quinto, crie um pequeno conjunto limitado de autoteste de interface do usuário que imitam as ações de um usuário final em um navegador.Esses testes serão suportados apenas pela equipe de controle de qualidade. Eles podem ser incorporados
- os cenários críticos mais populares do cliente
- o fato de que em testes de integração no código principal não é possível implementar completamente, por exemplo, trabalhar com serviços de terceiros
E sim, agora você tem acesso ao projeto e não precisa atualizar o front-end do projeto para ter localizadores convenientes e confiáveis para o Selenium. Não é preciso esperar e pedir a ninguém - abra solicitações pull no código principal do produto.
O que vem disso
Agora estou trabalhando exatamente nesse cenário. Como resultado, no topo da minha pirâmide de testes, existem apenas 9 peças de ponta a ponta. E o apoio deles é de minha responsabilidade. E todas as outras dezenas e centenas de testes convivem com o código principal do produto, iniciam seu trabalho no computador local do desenvolvedor e são suportadas por toda a equipe de engenheiros.
Meus testes de ponta a ponta funcionam por algum tempo, devido ao fato de que eles carregam arquivos de vídeo na plataforma e os convertem com parâmetros diferentes, os enviam para processamento em serviços de terceiros, esperam por uma resposta e assim por diante, sem stubs. Portanto, nos autotestes, há muitos momentos de espera pelo final da operação. A equipe não gostou da perspectiva de realizar esses testes no CircleCi e realmente não precisa. Então, eu os implementei como trabalho em Jenkins.
Quando todas as verificações de teste no código do produto são concluídas, implantamos o brunch testado no ambiente de teste e executamos testes de ponta a ponta usando o Jenkins. Mais alguns testes funcionais manuais para maior fidelidade do controle de qualidade e é tudo, você pode mesclar brunch no mestre. Hoje, não sou o único que conduz o Jenkins para autotestes em um ambiente de teste; os desenvolvedores os iniciam constantemente quando precisam gerar novos dados de teste e simular a atividade do usuário. Existem alguns deles, portanto eles são estáveis e sempre funcionam. Conveniente para todos.
Observarei outra vantagem agradável para o engenheiro de controle de qualidade em uma implementação dessa pirâmide de teste. Acontece que você se torna parte de uma equipe de engenheiros por completo. Você realmente faz parte integrante de um único trabalho - escreva código com todos, analise o código dos desenvolvedores, comunique-se com eles e eles farão o mesmo com você. Você vê o trabalho um do outro, melhor colaboração, formação de equipe mais forte. Você entenderá o projeto não apenas de fora, mas também de dentro, digno de respeito, não é?
Adeus final
Meu artigo não afirma ser uma pílula universal que pode ser usada a qualquer hora, em qualquer lugar. Todos os projetos são muito diferentes, todas as equipes são muito diferentes - cada um deve construir seu próprio melhor caminho, geralmente essa é a quintessência de diferentes abordagens e ferramentas. Até o famoso Scrum, quantos projetos já vi, cada um professa à sua maneira :) Geralmente não acredito em instruções estritas, acredito que são necessárias como diretrizes e preciso agir de acordo com a situação.
No entanto, o mundo da TI está se desenvolvendo e cada vez mais pessoas estão entrando nele, por isso estou certo de que, entre os leitores deste material, certamente haverá alguém para quem minhas pequenas instruções me ajudarão a escolher o caminho certo. Sorria para mim nos comentários, se for útil :), o feedback será agradável para mim!