Quatro em cada cinco candidatos a controle de qualidade desejam aprender como trabalhar com testes automatizados. Nem todas as empresas podem atender a esses desejos dos testadores manuais durante o horário de trabalho. Wrike realizou uma escola de automação para funcionários e realizou esse desejo de muitos. Participei desta escola justamente como aluno de QA.
Aprendi como trabalhar com Selenium e agora suporto de forma independente um certo número de autotestes, praticamente sem ajuda externa. E, com base nos resultados de nossa experiência conjunta e em minhas conclusões pessoais, tentarei derivar a fórmula para a escola de automação mais ideal.
A experiência do Wrike na organização de uma escola
Quando a necessidade de uma escola de automação ficou clara, sua organização coube a Stas Davydov, líder técnico de automação. Quem mais, senão ele, pode explicar porque criaram esta iniciativa, se alcançaram resultados e se lamentam o tempo gasto? Vamos dar a palavra a ele:
— Em 2016, escrevemos um novo framework para autotestes e facilitamos a escrita de testes: surgiram etapas normais, a estrutura ficou muito mais compreensível. Tivemos uma ideia: precisamos envolver todos que desejam escrever novos testes e, para facilitar o entendimento, criamos uma série de palestras. Elaboramos coletivamente um plano de temas, cada um dos futuros palestrantes pegou um para si e preparou um relatório sobre ele.
— Que dificuldades os alunos tiveram?
— Principalmente, claro, arquitetura. Houve muitas dúvidas sobre a estrutura dos nossos testes. Nos comentários, muito foi escrito sobre esse tema e tivemos que realizar palestras adicionais para explicar com mais detalhes.
— A escola valeu a pena?
- Sim definitivamente. Graças a ela, muita gente se envolveu na redação dos testes e, em média, no hospital, todos começaram a entender melhor o que são os autotestes, como são escritos e como são lançados. A carga sobre os engenheiros de automação também diminuiu: agora recebemos muito menos pedidos de ajuda na análise de testes, uma vez que testadores e desenvolvedores começaram a lidar com isso sozinhos em quase todas as situações. Pois bem, são várias vantagens internas para o departamento: ganhamos experiência em apresentações e palestras, graças às quais alguns engenheiros de automação já conseguiram fazer apresentações em conferências, e também recebemos um poderoso conjunto de vídeos e apresentações para onboarding de recém-chegados.
Em meu nome, acrescentarei que a comunicação entre os nossos departamentos foi simplificada a um nível ridiculamente fácil. Por exemplo, agora praticamente não preciso pensar em quais casos e em que nível de atomicidade automatizar. Com isso, todos os interessados estão cuidando ao máximo da cobertura de testes, que está em constante crescimento. Ninguém exige o impossível dos outros.
De uma forma geral, o impacto no trabalho das equipas é definitivamente positivo. Talvez os colegas que estão lendo este artigo também estejam pensando em fazer algo semelhante? Então o conselho será simples: vale a pena se os testes automatizados forem uma prioridade para você. A seguir falaremos sobre uma questão mais complexa: como organizar tudo isso da maneira mais correta possível, para que os custos de todas as partes sejam mínimos e o rendimento máximo.
Dicas de organização
A escola foi útil, mas, como admitiu Stas, houve algumas dificuldades, pelas quais foi necessário organizar palestras adicionais. E foi como um estudante recente, comparando a mim mesmo, na ignorância, e a mim mesmo, agora, que formulei as seguintes etapas para criar, em minha opinião, a maneira ideal de ensinar os testadores a compreender os testes automatizados.
Passo 0. Crie um dicionário
É claro que esta etapa não é necessária apenas para controle de qualidade. No entanto, quero deixar isso explícito: a base de código de automação deve ser mantida em um formato legível. Linguagens de programação – não menos importante línguas, e a partir daí você pode começar seu mergulho.
Aqui está uma captura de tela de uma visualização de tarefas com os nomes dos elementos. Vamos imaginar que você está testando o taskview como uma caixa preta e nunca viu Selenium em sua vida. O que faz este código?
(Spoiler - a tarefa é excluída via rest em nome do administrador, e então vemos que há um registro disso no stream.)
Esta etapa por si só aproxima as linguagens QAA e QA. É mais fácil para as equipes de automação explicar os resultados de uma execução; os testadores manuais precisam despender menos esforço na criação de casos: eles podem ser menos detalhados. Mesmo assim, todos se entendem. Recebemos os ganhos antes mesmo do início do treinamento propriamente dito.
Passo 1. Repetir frases
Continuemos o paralelo com a linguagem. Quando aprendemos a falar quando crianças, não partimos da etimologia e da semântica. Repetimos “mãe”, “compre um brinquedo”, mas não entramos imediatamente nas raízes proto-indo-europeias destas palavras. Então é aqui: não faz sentido mergulhar nas profundezas dos recursos técnicos dos autotestes sem tentar escrever algo que funcione.
Parece um pouco contra-intuitivo, mas funciona.
Na primeira lição, vale a pena dar uma base de como escrever autotestes diretamente. Ajudamos a configurar o ambiente de desenvolvimento (no meu caso, Intellij IDEA), explicamos as regras mínimas de linguagem necessárias para escrever outro método em uma classe existente usando as etapas existentes. Escrevemos um ou dois testes com eles e damos-lhes trabalhos de casa, que eu formataria assim: um ramo ramificado do mestre, mas vários testes foram removidos dele. Apenas suas descrições permanecem. Pedimos aos testadores que restaurem esses testes (não através de show diff, é claro).
Com isso, quem ouviu e fez tudo poderá:
- aprender a trabalhar com a interface do ambiente de desenvolvimento: criando branchs, hotkeys, commits e pushes;
- dominar o básico da estrutura da linguagem e das classes: onde inserir injeções e onde importar, por que são necessárias anotações e que tipo de símbolos são encontrados ali, além de etapas;
- entender a diferença entre ação, esperar e verificar, onde usar o quê;
- observe a diferença entre autotestes e verificações manuais: nos autotestes você pode puxar um ou outro manipulador em vez de realizar ações através da interface. Por exemplo, envie um comentário diretamente para o backend em vez de abrir uma visualização de tarefas, selecionar a entrada, digitar o texto e clicar no botão Enviar;
- formular perguntas que serão respondidas na próxima etapa.
O último ponto é muito importante. Estas respostas podem ser facilmente dadas com antecedência, mas é um princípio de ensino importante que as respostas sem perguntas formuladas não sejam lembradas e não sejam usadas quando finalmente necessárias.
Seria ideal se neste momento um engenheiro de automação da equipe de controle de qualidade atribuísse a ele a tarefa de escrever alguns testes em batalha e permitisse que ele se submetesse à sua filial.
O que não dar:
- conhecimento mais aprofundado da funcionalidade do ambiente de desenvolvimento e da própria linguagem de programação, que só será necessário ao trabalhar com filiais de forma independente. Não vai ser lembrado, vai ter que explicar duas ou três vezes, mas valorizamos o tempo dos engenheiros de automação, certo? Exemplos: resolver conflitos, adicionar arquivos ao git, criar classes do zero, trabalhar com dependências;
- tudo relacionado ao XPath. Seriamente. Você precisa falar sobre isso separadamente, de uma vez e com muita concentração.
Passo 2. Analisando mais de perto a gramática
Vamos lembrar a captura de tela do Taskview da etapa 0. Temos uma etapa chamada checkCommentWithTextExists. Nosso testador já entende o que essa etapa faz e podemos olhar por dentro da etapa e decompô-la um pouco.
E dentro temos o seguinte:
onCommentBlock(userName).comment(expectedText).should(displayed());Onde onCommentBlock está
onCommonStreamPanel().commentBlock(userName);Agora aprendemos a dizer não “compre um brinquedo”, mas “compre um brinquedo na loja Detsky Mir, localizada no armário azul na terceira prateleira a partir de cima”. É necessário explicar que apontamos para um elemento sequencialmente, a partir de elementos maiores (fluxo -> bloco com comentários de uma determinada pessoa -> aquela parte deste bloco onde fica o texto especificado).
Não, ainda não é hora de falar sobre XPath. Basta mencionar brevemente que todas essas instruções são descritas por eles e a herança passa por elas. Mas precisamos falar sobre todos esses matchers e garçons; eles se relacionam especificamente com essa etapa e são necessários para entender o que está acontecendo. Mas não sobrecarregue: seu aluno poderá estudar afirmações mais complexas sozinho mais tarde. Muito provavelmente, deveria, waitUntil, display();, exist();, not(); deveria ser suficiente.
O dever de casa é óbvio: um ramo do qual foram retirados os conteúdos de diversas etapas necessárias para um determinado número de testes. Deixe os testadores restaurá-los e fazer com que a corrida fique verde novamente.
Além disso, se a equipe de testes não tiver apenas novos recursos em seu trabalho, mas também algumas correções de bugs, você pode pedir a ele que escreva imediatamente testes para esses bugs e os libere. Muito provavelmente, todos os elementos já foram descritos; apenas alguns passos podem estar faltando. Este será o treino perfeito.
Passo 3. Imersão total
O mais completo possível para um testador que continuará exercendo suas funções diretas. Finalmente, precisamos falar sobre XPath.
Primeiro, vamos deixar claro que todos esses onCommentBlock e comentários são descritos por eles.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"A ordem da história é muito importante. Primeiro, pegamos qualquer XPath existente e mostramos como a aba de elementos contém um e apenas um elemento. A seguir falaremos sobre a estrutura: quando você precisa usar WebElement e quando precisa criar um arquivo separado para um novo elemento. Isso permitirá que você entenda melhor a herança.
Deve ser explicitamente declarado que um único elemento é toda a visualização de tarefas, contém um elemento filho - o fluxo inteiro, que contém um elemento filho - um comentário separado, etc. Os elementos filhos estão dentro dos elementos pais na página e na estrutura da estrutura de autoteste.
Neste ponto, o público deve ter entendido firmemente como eles são herdados e o que pode ser inserido após o ponto em onCommentBlock. Neste ponto, explicamos todos os operadores: /, //, ., [] e assim por diante. Acrescentamos conhecimento sobre o uso na carga @class e outras coisas necessárias.
Os alunos devem entender como traduzir o XPath desta forma. Para consolidar - isso mesmo, lição de casa. Excluímos as descrições dos elementos, deixamos que restaurem o funcionamento dos testes.
Por que esse caminho específico?
Não devemos sobrecarregar uma pessoa com conhecimentos complexos, mas devemos explicar tudo de uma vez, e este é um dilema difícil. Este caminho nos permitirá primeiro fazer com que os ouvintes façam perguntas e não entendam algo e respondam no momento seguinte. Se você falar sobre toda a arquitetura, então no momento em que o tópico passos ou xpath for analisado, suas partes mais importantes já estarão esquecidas devido à sua incompreensibilidade.
No entanto, alguns de vocês provavelmente poderão compartilhar sua experiência sobre como o processo pode ser otimizado ainda mais. Ficarei feliz em ler sugestões semelhantes nos comentários!
Fonte: habr.com