Lendo artigos sobre o tópico de teste na web, dois tópicos aparecem condicionalmente: 1) o teste manual está acabando, os autotestes (doravante referidos como autotestes são Selenium UI e REST) são tudo; 2) o teste automático não é uma panacéia; o teste manual é indispensável. Ao mesmo tempo, a partir dos artigos, há uma tendência a um aumento nos requisitos de qualidade de software e velocidade de desenvolvimento de produtos. Wrike é apenas o caso quando esses requisitos são críticos.
O produto já tem 12 anos, mas ainda está crescendo ativamente. As implantações ocorrem uma vez ao dia, e às vezes duas. Portanto, é extremamente importante para nós que a regressão seja realizada exclusivamente em autotestes. No entanto, no Wrike (na empresa), existem mais de 30 equipes de scrum, e o pessoal da equipe de automação não é de borracha. Em tais circunstâncias, para esperar a automação de cenários manuais, na melhor das hipóteses, um ou dois sprints não são uma opção. A experiência de nossa empresa diz que um testador manual pode escrever autotestes independentemente, sujeito a certas nuances. No artigo, vou falar sobre eles e por que, na minha opinião, essa capacidade não apenas ajuda a acompanhar as tendências, mas também é útil para o próprio testador.
Processo padrão
A que processo muitas equipes estão acostumadas? Isso varia de caso para caso, mas os recursos comuns são praticamente os mesmos. Existem departamentos de teste automático e manual. Os testadores manuais podem ser distribuídos entre os comandos scrum. Nesse caso, a automação, por regra, não tem relação com uma equipe específica.
Ao trabalhar com novas funcionalidades, o testador cria scripts de teste, alguns dos quais ele marca de maneira predeterminada para os fabricantes de automóveis. Além disso, se já houver casos em que os ajustes forem feitos, eles também serão anotados para atualizar o código. Em seguida, os testes marcados são transferidos para o departamento de automação. Uma equipe de engenheiros de automação assume a tarefa de corrigir a corrente e escrever novos autotestes em um dos seguintes sprints. Além de programar cenários de teste, as tarefas do automatizador incluem executar autotestes, analisar os resultados, além de apoiar e desenvolver o projeto de teste. Acontece que o departamento de automação atua como executor de terceirização e os testadores manuais são um tipo de cliente.
Além disso, o cliente gasta tempo compilando um TOR detalhado e preciso, discutindo periodicamente os métodos de implementação e selecionando os testes necessários. Também há riscos de que, durante a ausência de autoteste, os erros possam ser ignorados. Não esqueça que há uma camada de problemas técnicos que só poderiam ser resolvidos em testes automáticos, o que economizaria muito tempo. Essas tarefas deverão ser verificadas manualmente na parte em que a automação ainda está ausente.
O contratado, não estando muito imerso na funcionalidade em que a equipe estava envolvida, levará tempo para mergulhar superficialmente na tarefa e na conscientização do TOR. Ao mesmo tempo, é provável que o teste não seja traduzido com precisão no código, pelo que não verificará o que gostaríamos. Por conseguinte, a eficiência da base de teste é reduzida.
A equipe de automação, sendo o único colaborador do projeto de teste, tem controle total sobre sua base de códigos, o que permite que ele seja facilmente desenvolvido em qualquer direção. No entanto, o tempo para isso se torna insuficiente devido ao aumento da carga de outras equipes. O problema pode ser resolvido com a expansão da equipe, mas o custo da automação excederá sua eficácia. Mesmo se você remover parte da carga, dando aos testadores manuais a oportunidade de executar testes e analisar os que caíram, isso não trará o resultado adequado. Como eles não possuem ferramentas para depurar testes, eles podem não entender que o teste travou devido a uma alteração no xpath e assim por diante.
Consequentemente, na saída, obtemos que os autotestes com esse esquema não acompanham o crescimento do produto, o que leva a uma cobertura ruim do código. Devido a uma interpretação imprecisa do TK, os testes podem ignorar os erros. Quando estão desatualizados por um longo tempo, os que caem não são reparados imediatamente, e é difícil para os testadores manuais saberem imediatamente qual parte do sistema está bem coberta pela automação. Os autotestes se tornam algum tipo de caixa preta, na qual os testadores desconfiam. Portanto, o número de verificações manuais desnecessárias está aumentando, os termos das tarefas são ampliados e a qualidade diminui a longo prazo.
Você pode trabalhar com essas deficiências, mas quanto maior o produto e a empresa, mais doloroso para os participantes do processo e, o mais importante, é difícil seguir a tendência de aumentar a velocidade e melhorar a qualidade. O próprio testador se torna refém da rotina e praticamente não permanece no desenvolvimento do tempo.
Maneira Wrike
Então, como funciona no exemplo da equipe em que trabalho. Existem equipes de teste automáticas e manuais. Os dados iniciais ainda são semelhantes, mas as diferenças começam. Os testadores manuais são distribuídos entre suas equipes de scrum. Cada equipe de scrum tem seu próprio autotester. Às vezes, pode ser alocado não a uma, mas a duas equipes, se a carga permitir.
Ao trabalhar com novas funcionalidades, o testador escreve listas de verificação, de acordo com as quais realiza verificações manuais. A parte mínima exigida dos testes desta lista de verificação é automatizada. O próprio testador grava esses autotestes no momento em que o recurso está em desenvolvimento ou teste. Além disso, o código escrito é fornecido ao revisor para revisão. Com raras exceções, uma tarefa sem autoteste não pode ser emitida.
Obviamente, não há exigência no Wrike de escrever autotestes por testadores manuais. Isso fica a critério da equipe. Você pode dar tudo para a automação. Você pode limitar-se a corrigir novos testes quebrados e / ou escrever por analogia e delegar tarefas mais complexas (criar novos testes ou expandir identificadores antigos de back-end, objeto de página ou etapas e classes de teste) a uma ferramenta de automação dedicada. Tudo depende de você, mas é estúpido perder essas vantagens que a gravação independente de testes automáticos oferece.
Toda a nossa regressão é baseada em autotestes, e as responsabilidades dos testadores manuais incluem executar e analisar falhas de autoteste. Para cada ramo em que a equipe está trabalhando, eles executam testes automáticos como garantidor inicial e final da qualidade. Portanto, é muito mais fácil para aqueles que escrevem autotestes entenderem por que um teste em execução na ramificação falhou. Às vezes, ferramentas como reexecução e um relatório no
Allure são realmente suficientes, onde você pode entender o motivo da falha do teste na captura de tela e nas etapas. No entanto, geralmente o melhor assistente é a capacidade de executar testes localmente, brincar com as etapas ou executá-las no modo de depuração, ver o xpath esperado e real. Sem experiência em trabalhar com um projeto de teste, isso levará muito tempo ou será necessário distrair a ferramenta de automação dedicada.
Além disso, a gravação independente de autotestes permite executá-los antes mesmo do lançamento do recurso. O testador sempre sabe o grau de cobertura de sua parte do sistema e as tarefas técnicas rolam apenas em testes automáticos, o que economiza significativamente tempo e recursos da equipe. Os testes em si são sempre relevantes, pois as falhas são ajustadas antes do lançamento. Os testes interrompidos são corrigidos imediatamente no mesmo ramo em que os novos são gravados.
O testador manual é imerso ao máximo na tarefa da equipe, portanto, o mínimo necessário de testes automáticos é selecionado, cobrindo a maioria dos casos. A amostra é revisada várias vezes durante o teste, pois durante as verificações manuais, a funcionalidade é estudada com mais detalhes com todas as nuances. Consequentemente, a eficiência desses testes está aumentando. Escrever autotestes permite entender melhor a arquitetura do aplicativo, os componentes usados e a interação do front-end com o back-end. Por fim, esse conhecimento ajuda a uma abordagem mais consciente e eficaz dos testes de produtos. Por exemplo, se algum comando faz alterações no componente geral, é mais provável que você saiba com antecedência se seu escopo será ou não afetado, pois ao trabalhar com o xpath, você entende quais componentes são usados em sua parte do aplicativo.
Pode-se argumentar que escrever autotestes leva tempo. Sim, as tarefas serão liberadas um a três dias depois do que o normal, mas a longo prazo vale a pena. Além disso, existem métodos de otimização. Por exemplo, enquanto um recurso está em desenvolvimento, você pode elaborar as listas de verificação necessárias e deixar um espaço em branco para os testes, economizando tempo. Se você possui uma estrutura de funcionalidade pronta, é possível adicionar ou corrigir xpaths existentes, se necessário, criar um novo Objeto de Página ou ajustar as etapas. Então, na fase de escrever autotestes, após verificações manuais, você só precisará adicionar os blocos de código na ordem correta.
Graças à estrutura desenvolvida por nossa equipe de automação, escrever autotestes na maior parte representa compilar código a partir de blocos - como o Lego. Essa simplicidade permite que você se adapte rapidamente aos testadores manuais e comece a escrever autotestes por analogia com os existentes. Por experiência própria, direi que demorou cerca de duas semanas desde o momento em que fui trabalhar no Wrike até os primeiros autotestes que escrevi, juntamente com outras tarefas.
O controle de qualidade dos testes automatizados escritos é realizado através da revisão do código. Nem uma única ramificação de teste entra no lançamento sem uma revisão. Este é um bom momento de treinamento, pois o testador extrai informações úteis dos comentários em seu código e desenvolve a experiência de boas soluções: por exemplo, ele gerencia a biblioteca Java padrão com mais eficiência ou define o xpath com mais precisão. Da próxima vez, ficará claro qual a melhor forma de trabalhar com uma situação específica.
Obviamente, o desenvolvimento de um projeto de teste, uma estrutura e o treinamento de testadores manuais consomem os recursos de automação, especialmente no estágio inicial, mas parece-me que esses esforços foram totalmente recompensados. Temos muitas melhorias no ambiente de teste automatizado que facilitam nosso trabalho. O produto em si tem uma boa cobertura, para que você possa confiar na regressão. Isso ajuda a acelerar o processo de implantação de recursos no ambiente do usuário e protege muito os nervos dos testadores.
De acordo com a experiência de nossa equipe, este é um dos melhores processos para trabalhar com um produto grande e de rápido desenvolvimento em uma grande empresa. Além disso, está alinhado com as tendências atuais em melhorar a qualidade do software e a velocidade de sua entrega aos usuários. O próprio testador praticamente se livra da rotina, desenvolve-se em várias direções e olha a aplicação sob vários ângulos.
Brevemente sobre o principal
Por conveniência, destacarei as vantagens de um testador manual em um único local, para que seja mais fácil perceber sua importância individualmente ou em conjunto:
- Uma imagem mais completa é formada sobre o nível e a qualidade da automação de seus escopos;
- Os autotestes estão disponíveis antes do lançamento do recurso, o que possibilita verificar rapidamente sua qualidade a qualquer momento;
- A eficiência dos autotestes aumenta, assim como a eficiência dos testes em geral;
- Uma abordagem mais informada e eficaz dos testes está sendo formada;
- Livrar-se de regressões manuais monótonas e longos testes de avaliação;
- Crescimento pessoal e desenvolvimento de competências.
Resumir
Claro, não há bala de prata. O que é adequado para uma empresa pode ser fortemente rejeitado por outra. No caso do Wrike, o produto cresce extremamente rápido e não há tempo para longas regressões manuais e testes de avaliação. Temos esse papel desempenhado por autotestes, que cobrem quase todos os componentes de um grande produto. Isso ajuda a manter a qualidade, otimizar recursos e fornecer novas funcionalidades aos usuários mais rapidamente.
A má notícia é que ele não pode ficar sem erros, mas no nosso caso, na maioria das vezes, esses são casos extremos. A boa notícia é que os erros durante as correções também são cobertos por autotestes.
Por alguma razão, tornou-se tão comum na comunidade que a idéia de escrever autotestes por testadores manuais é rejeitada. Existem dois argumentos mais populares por parte dos testadores: "Eles não pagam mais por isso" e "Já temos trabalho suficiente". Para mim, pessoalmente, ambos os argumentos desmoronam quando percebo que posso executar autotestes no momento em que um recurso é desenvolvido e, em pouco tempo, entendo como ele funciona corretamente. Vale muito a pena. Nosso trabalho é melhorar e manter a qualidade do produto, para que todas as oportunidades sejam usadas para facilitar isso. Desde o momento em que comecei a escrever autotestes, a rotina do meu trabalho se tornou cada vez menos consciente.
PS Este artigo reflete apenas a experiência de nossa equipe e pode não corresponder às suas crenças. Portanto, ficarei feliz em saber sobre as abordagens que o guiarão em seu trabalho. Também ficarei feliz com críticas saudáveis e com a oportunidade de discutir o artigo nos comentários.