Get best of the week

Os autotestes pensam em erros elétricos

Recentemente, a automação de testes foi chamada de "bala de prata" de todos os problemas do projeto. Muitas pessoas iniciam a automação de maneira espontânea e leve, sem calcular todos os prós e contras, prós e contras, manutenção e retorno. 

Em geral, a automação de teste é uma ferramenta muito cara e específica. Portanto, ele deve ser abordado com o nível adequado de maturidade do código e do próprio projeto. Caso contrário, você pode gastar milhões de horas e dinheiro, e o efeito é microscópico ou nada.

Neste artigo, tentei:

  • para iluminar as "feridas das crianças" do gerenciamento de testes, buscando automatizar tudo o que não está preso,
  • Explique como a automação de teste pode beneficiar o orçamento do projeto sem uma análise detalhada de seu escopo e preparação adequada,
  • compile um roteiro para se preparar para a automação do projeto.

Fonte 

A tendência é que agora o teste de automação faça buracos em todos os projetos, prendendo pregos com um microscópio. Chega ao ponto que fica difícil para um testador sem habilidades de automação encontrar um emprego, porque na maioria das vagas, faltam habilidades em análise e design de teste, mas é necessária experiência na automação de algo.

Gostaria de acreditar que, com o tempo, todos teremos um desejo obsessivo de automatizar tudo de uma só vez, mas, por enquanto, uma lista de verificação nos ajudaria muito a determinar se são necessários testes automáticos no projeto e se o projeto está pronto para eles. 

Na verdade, com esses pensamentos, fui fazer uma apresentação no “Strike-2019” e depois escrevi este post com base nele.

Falaremos sobre autotestes grandes e sérios, de ponta a ponta, que automatizam a regressão em termos de interface do usuário e serviços da web. E também o que está conectado com eles. Não abordaremos o tópico dos testes de unidade que os desenvolvedores escrevem ou devem escrever. Esta é uma camada separada de autoteste, e muitos artigos já foram escritos sobre isso:

 
Não vou citar o projeto, apenas direi que este é um sistema de informação projetado para várias dezenas de milhões de usuários. É integrado a vários portais estaduais, bem como a dezenas, se não centenas, de portais regionais e comerciais. Daí o aumento dos requisitos de confiabilidade, tolerância a falhas e segurança. Bem, em geral, para que tudo "gire e não caia". 

Nossa crença em todos os projetos de teste da LANIT é a melhoria contínua. Em geral, tudo o que nos permite testar mais rápido, melhor, mais alto, mais forte economiza tempo e esforço dos testadores e, como resultado, o orçamento. Implementamos neste projeto, provavelmente todas as melhores práticas que nos permitiram cumprir prazos e tarefas. Como resultado, dos grandes chips não realizados, apenas a automação de regressão permaneceu. Esse tópico em si por algum tempo ficou no ar e, durante muito tempo, nós o recusamos, descansando em todos os nossos membros, porque o lucro não era muito claro. Mas no final eles decidiram automatizar. E então houve um salto prolongado na água fria.
 

Uma pequena digressão. Métodos de automação


Existem duas maneiras principais de automatizar o teste da interface do usuário. 

Fonte

Automação por testadores manuais


Você não precisa ir longe para obter exemplos - tudo está em Habré. Eu não vou nomear a empresa. Aqueles que estavam interessados ​​no tópico provavelmente viram esses webinars de uma hora e meia, quão legais eles são, quão legais eles são, como toda a equipe de testadores de mão aprendeu o Java com eles, foi automatizar, tudo é coberto, tudo é ótimo, tudo funciona, tudo funciona, um futuro brilhante já chegou. Existe essa abordagem. 

Abordagem de design


E existe uma segunda abordagem: uma equipe de auto-testadores é recrutada - com experiência, com conhecimento e habilidades em OOP, e a automação é realizada diretamente pelas forças dessa equipe, e uma equipe de testadores manuais atua como clientes e especialistas. Sim, eles podem fluir para a equipe de automação após o treinamento, a seleção, mas nunca combinam duas funções ao mesmo tempo.

Abaixo, descrevi os recursos dessas abordagens, mas não as marquei especificamente como "vantagens" ou "desvantagens" - todos determinarão o sinal para si.

Recursos de automação "por conta própria"


Fonte

1) Quando automatizamos com a ajuda de testadores manuais, obtemos um efeito rápido "olha, esse teste levou um dia antes, agora eu posso substituí-lo por um robô, leva 2 dias, mas não participo aqui". Naturalmente, isso melhora as qualificações e amplia os horizontes dos especialistas: eles começam a entender o código. Mas não há resultado claro e tangível para os negócios. Quantas horas foram gastas no desenvolvimento e quanto poderia ser gasto se uma pessoa com experiência fizesse isso? Quantas horas são salvas? Com que frequência o caso de teste será lançado? Onde? Quem acompanhar? Quanto custa isso? Isso não é muito bom para mim, porque, infelizmente, ainda não vi clientes dispostos a pagar dinheiro infinitamente - pelo processo. Portanto, um resultado claro e tangível é sempre importante para mim.

2) Sem prazos. Por um lado, é bom: ninguém incentiva a equipe: "vamos automatizar tudo rapidamente, vamos aprender rapidamente", a tensão não cresce em uma pessoa. Ele continua testando com as mãos e mergulha calmamente na automação. Por outro lado, não há prazos, não podemos perguntar sobre os resultados e não entendemos quando estará pronto.

3) Não há suporte e continuidade de código. Por um lado, diferentes abordagens, pesquisas dão origem a melhores métodos de escrita, às vezes, reescrevendo do zero, você pode acelerar o autoteste várias vezes. Mas é megatrack. Além disso, quem acompanhará tudo isso se os especialistas abandonarem o projeto, e isso acontecerá se forem para outra área de negócios ou outra equipe? Também não é muito claro.

Características da abordagem do projeto


Fonte

1) Nesse caso, já estamos falando sobre o projeto. E o projeto é o que? Estes são recursos, tempo, dinheiro. Nesse sentido, o orçamento está sendo calculado aqui, levando em consideração todas as nuances contidas neste projeto. Todos os riscos são calculados, todo o trabalho adicional é calculado. E somente após o orçamento ser acordado, é tomada uma decisão de lançamento.

2) Com base nisso, é provável que a fase de preparação não seja rápida, uma vez que o cálculo do orçamento para algo deve ser construído.

3) Naturalmente, maiores demandas são impostas aos especialistas que participarão do projeto. 

4) Aqui também vou escrever soluções complexas de infraestrutura, mas mais sobre isso mais tarde. 

5) Modernização dos processos de teste e liberação existentes. Porque os autotestes são um novo elemento da equipe. Se não tiver sido fornecido anteriormente, respectivamente, você precisará integrá-lo ao processo. Os testadores automáticos não devem ficar do lado direito, esquerdo, do projeto.

6) A abordagem do projeto fornece regularidade, consistência, embora, por outro lado, sua implementação possa ser mais lenta que a implementação da primeira abordagem.

7) Bem, reportando. Muitos relatórios. Porque para qualquer orçamento, você será solicitado. Portanto, você deve entender como os autotestes funcionam (ruins, bons), quais tendências, quais tendências, o que precisa ser aumentado, o que deve ser aprimorado. Isso é controlado pelos relatórios.

Longo caminho para um futuro melhor


Disclaimer: Nós éramos tão inteligentes imediatamente (na verdade não).

Fonte

Aqui está uma classificação dos problemas que encontramos. Vou analisar cada um individualmente. Farei isso de propósito, para que você leve em consideração esse "rake". Como esses problemas, não solucionados no início do projeto, afetarão diretamente, pelo menos, sua duração, no máximo - eles aumentarão seu orçamento ou poderão até fechar o projeto.

Fonte

  • Equipes diferentes - abordagens diferentes.
  • Fraca imersão da automação no funcional.
  • Estrutura não ideal de casos de teste.
  • Documentação da estrutura.
  • Problemas de comunicação.
  • Compra oportuna de licenças.

Diferentes abordagens para automação


Fonte 

Tortura número de vezes


A primeira tentativa que tivemos foi de acordo com o primeiro modelo (consulte o método número 1). Um pequeno (mas orgulhoso) grupo de testadores da iniciativa decidiu tentar a automação. Em geral, queríamos ver o que saiu disso tudo. Agora, é claro, não faríamos isso, mas não havia experiência e decidimos tentar. 

Fonte

Tínhamos um líder de equipe com experiência em automação, 3 queimando com o desejo de automatizar o testador e muito desejo de dominar esse caminho. É verdade que Timlid era um recém-chegado e não podia dedicar muito tempo ao projeto, mas o efeito positivo de seu trabalho foi que escrevemos nossa própria estrutura. Observamos as estruturas existentes, eram caras, legais ou gratuitas, e as instruções "anexadas ao arquivo para provar após a montagem" foram anexadas a elas. Em geral, por vários motivos, não podemos usá-los. Assim, decidimos escrever nossa própria estrutura. A escolha em si e o processo de redação são um tópico para um artigo separado, ou mesmo não um.

Para não dizer que essa tentativa foi um fracasso, ela simplesmente sobreviveu a si mesma e terminou. Quando percebemos que precisávamos de um orçamento, precisávamos de forças adicionais, precisávamos de habilidades, precisávamos de outra organização de equipe. Automatizamos cerca de 100 casos, vimos que funcionava e terminamos.

Tentativa número dois


Fonte 

Nada acena como um sanduíche mordido.

Depois de um tempo, voltamos ao tópico de automação.

Mas, lembrando o primeiro experimento, passamos para o método n ° 2. Aqui já tínhamos uma equipe "hábil", automatizando mais de um projeto. Mas aqui estamos diante de outro desastre. Essa equipe seguiu o líder da equipe de testes da interface do usuário. Como isso aconteceu?

"Queremos automatizar isso!"
Talvez pensemos nisso.
- Não, não queremos pensar em nada, queremos esses autotestes.

Com esforços titânicos, eles automatizaram e até funcionou. Mas com o tempo, a estabilidade dos lançamentos começou a declinar e, quando montamos nossa própria equipe de engenheiros de automação e começamos a entregar o projeto a eles, verificou-se que metade dos testes foram feitos em muletas, meio que verificou o que a máquina pretendia e não o que o testador manual queria. 

E tudo porque os autotestes eram executados em código bruto, sujeito a correções diárias. Essa. o conjunto inicial de casos não estava correto. Tivemos que nos aprofundar nos tópicos que queremos automatizar, do ponto de vista de sua automação (doravante, manteiga). É muito crítico abordar os casos que oferecemos para automação e, em algum momento, descartar alguns deles, separá-los e assim por diante. Mas nós não fizemos. 

Qual é o resultado. Automatizamos outra peça, cerca de 300 casos, após o que o projeto terminou, porque não havia estabilidade de lançamentos e também não havia entendimento de como acompanhá-lo. E nós entendemos como não fazer isso ... pela segunda vez.

Tentativa número três


Fonte 

Na terceira tentativa, nos aproximamos, como uma corça tímida, de um poço de água. 

Around viu riscos (e quebra de termos). Eles abordaram criticamente, em primeiro lugar, os casos de teste e seus autores - testadores de interface do usuário - como clientes do processo. Encontramos a mesma equipe de engenheiros de automação e iniciamos um projeto normalmente calculado (como pensávamos) e totalmente preparado (ha ha).

O ancinho já estava mentindo e esperando por nós.

Fraca imersão da automação no funcional


Fonte 

No primeiro estágio (a seguir denominado terceira tentativa), quando as comunicações ainda estavam mal estabelecidas, os testadores automáticos trabalhavam atrás de uma certa tela: eles recebiam tarefas, automatizavam algo lá. Fizemos autoteste. Vimos estatísticas de que tudo está ruim conosco. Escavando logs de autoteste. E há, por exemplo, uma queda em um erro de ortografia no nome do arquivo que está sendo carregado. É claro que o testador, que testou essa funcionalidade com as mãos, iniciará um menor e pulará para verificar mais. O autoteste cai e bate em toda a cadeia, com base em sua base. 

E quando começamos a imergir os auto-testadores no funcional, a explicar exatamente o que verificamos nos casos, eles começaram a entender os erros dessas "crianças", como evitá-los, como contorná-los. Sim, existem erros de digitação, existem algumas inconsistências, mas o autoteste não cai, simplesmente os registra.

Estrutura de caso de teste não ideal


Fonte 

Esta é provavelmente a nossa maior dor de cabeça. Ela deu mais problemas, mais custos de tempo, mais horas e dinheiro que perdemos neles. Como resultado, agora resolveremos esse problema antes de tudo, se automatizarmos outra coisa.

Nosso projeto é bastante grande, várias dúzias de sistemas de informação estão girando nele, eles são unidos por grupos de trabalho. E parece que os padrões para escrever casos são os mesmos para todos, mas em um grupo essa peça é chamada de "função", em outro é chamada de "autoridade", e o autotester lê tanto "função" quanto "autoridade" e cai em um estupor. Este é apenas um exemplo. De fato, havia centenas de situações desse tipo. Eu tive que padronizar tudo isso, pentear meu cabelo.

O que mais você encontrou além de tais ambiguidades? Não encontramos casos de teste atômico. Esses são casos de teste, que em algumas etapas podem ser executados de forma variável. Por exemplo, na condição, diz "você pode executar a etapa 2 sob essa autoridade e sob essa autoridade" e na etapa 3, por exemplo, dependendo da autoridade utilizada, "pressione o botão" A "ou o botão" C ". Do ponto de vista de um testador manual, está tudo bem. O testador entende como passá-lo, o testador automático não entende como passá-lo. Em uma versão ruim, ele próprio escolherá o caminho, em uma boa, ele virá com esclarecimentos. Passamos bastante tempo convertendo casos de teste não atômicos.   

Documentação da estrutura


Fonte

Você sempre precisa pensar naqueles que vêm atrás de você. Como eles analisarão seu código, analisarão etc. É bom se houver engenheiros, programadores competentes. Ruim se não forem. Então você também pode enfrentar o fato de que precisa desmontar o legado das "vitórias" passadas, documentar novamente, atrair mais pessoas e passar mais tempo.

Problemas de comunicação


Fonte  

1. Falta de regulamentos para interação.

Uma equipe de automação veio, eles não sabem como se comunicar com a equipe de testes funcionais manuais e ninguém, de fato, sabe que tipo de pessoas são. Sim, existem leads que se comunicam entre si e todo o resto são apenas vizinhos do projeto. 

2. A presença de regulamentos para interação

Em seguida, os regulamentos foram escritos, mas os funcionários trabalharam por um tempo sem o outro, e quando os regulamentos foram escritos, eles consideraram isso a única ferramenta de interação. Tudo o que foi além disso foi ignorado. 

Ou seja, a princípio os caras simplesmente não sabiam se comunicar, pareciam estar nas mesmas salas de bate-papo, mas, se podiam fazer perguntas ou não, não sabiam. E quando já trabalhavam há algum tempo nessas condições, eles desenvolveram suas próprias comunidades informais e fechadas: somos “guardas de mão”, somos montadoras. Como se comunicar? Aqui temos o regulamento - de acordo com o regulamento. 

Compra oportuna de licenças de software especializadas


Em algum momento, verificou-se que, para o desenvolvimento de alguns casos, ainda precisamos de software pago, mas não há licença para isso. Eu tive que comprá-lo em ordem de incêndio (novamente, custos adicionais em dinheiro e tempo de inatividade). 

Roteiro


Istonik 

Assim, agora temos o Roteiro, como iniciar esses projetos, consiste, de fato, em etapas, cada etapa é dividida em certos pontos.

Estágio preliminar


Fonte 

Precisamos de um líder de equipe


Timlid, um arquiteto, em geral, aquele que estará conosco o tempo todo, aquele que entende de automação, que é tecnicamente experiente, competente. É aconselhável que este seja um desenvolvedor com 5 anos de experiência em certas linguagens de programação usadas em nosso projeto. Porque de uma maneira ou de outra, nossa estrutura funcionará com o nosso projeto. Portanto, é melhor que a estrutura e o projeto usem a mesma pilha de tecnologia.

Deve haver um grupo de foco


Além disso, este não deve ser um grupo focal de automação. Devem ser pessoas que tomarão decisões no futuro. É melhor fazê-los amigos desde o início, para que haja uma compreensão das decisões que eles tomam, por que e por quê.

Avaliação do status da base de casos de teste


Eu já falei sobre a avaliação do estado da base de casos de teste acima, respectivamente, isso também é feito na fase preliminar.

Descobrimos o que não está sujeito à automação


Frequentemente, existe um desejo de automatizar tudo o que se move (e tudo o que não se move, se move e automatiza); de fato, cerca de 40% dos casos de teste geralmente são tão caros para implementar que, em princípio, nunca serão recompensados. Portanto, aqui você precisa ter muita clareza sobre o que deseja: automatizar tudo e voar para dentro do tubo, ou deseja automatizar uma certa peça de teste funcional que o ajudará.

Avaliação de um projeto piloto


Avaliamos o projeto piloto na fase preliminar (quanto custará) e o executamos nos casos mais difíceis (nota).

Piloto


Fonte 

Normalização de casos de teste


O conjunto de casos coletados está sujeito a normalização. Ambiguidades e pré-condições desnecessárias são eliminadas. 

Preparação do quadro


Nós escrevemos nossa estrutura, adicionamos a existente ou usamos algum tipo de estrutura comprada.

A infraestrutura


Estamos preparando soluções de infraestrutura.

Aqui é muito importante não perder: você terá um desejo irresistível de usar, no primeiro estágio, algum tipo de computador doméstico embaixo da mesa para executar os autotestes. Isso não é necessário (os testes desaceleram e caem quando alguém acidentalmente bate no computador ou derrama um café nele). É necessário usar soluções de infraestrutura prontas, máquinas virtuais, observar a prática da aplicação. Portanto, calcule imediatamente seu poder para este projeto e para o próximo grande projeto. Para fazer isso, precisamos de um especialista em automação.

Subtotais e ajustes


Estamos escrevendo os primeiros casos. Avaliamos a velocidade de toda essa felicidade. Estamos avaliando as necessidades adicionais das pessoas, pois já entendemos o quanto esses casos serão automatizados. Ou seja, automatizamos cinco peças, agora precisamos entender quantas pessoas precisamos para automatizar, condicionalmente, outros 5 mil. Algumas licenças adicionais, hardware para o suporte, tanto para o suporte que executará autotestes quanto para o suporte do próprio aplicativo. Bem, e, de fato, a necessidade de finalizar casos de teste - quão ruim é tudo.

Resumindo o piloto


Resumimos, escrevemos um relatório e tomamos uma decisão se iremos para a automação ou não.

Eu já escrevi anteriormente que pode acontecer que não vamos. Ou seja, se, por exemplo, o retorno é de 18 anos e o prazo do seu projeto é de 5, você deve pensar por que precisa.

Fase de lançamento


 

Os itens de origem são listados sequencialmente, mas na verdade todos devem ser feitos em paralelo.

  • Começamos a seleção da equipe.
  • Nós determinamos os leads.
  • Vamos priorizar os estudos de caso.
  • Normalizamos casos de teste.
  • Resolvemos "dificuldades de infraestrutura".
  • Escrevemos regulamentos e instruções, estabelecemos comunicações, eliminamos gargalos.
  • Melhoramos a estrutura para o trabalho simultâneo de vários autotestes e paralelização de grupos de testes em execução.
  • Fazemos um módulo de relatórios e estatísticas (único e cumulativo).
  • Começamos a escrever autotestes.

Palco principal


Fonte 

No estágio principal, tudo é simples (haha): os autotestes são escritos, o suporte por escrito é fornecido, os resultados do lançamento são avaliados, as decisões de gerenciamento são tomadas, as decisões de gerenciamento são tomadas, os poderes são reforçados, os fluxos são adicionados e, de fato, a comunicação e a comunicação novamente com a equipe da UI. Todos devem navegar no mesmo barco e remar em uma direção.

Escort stage


Fonte 

O estágio de escolta é um pouco diferente do estágio principal. Uma diferença significativa está na sua duração. Além disso, possui uma porcentagem muito menor de novos autotestes em desenvolvimento. De acordo com nossas estimativas, 6-10% por versão, caso contrário, é muito semelhante ao estágio principal.

Qual é o resultado?


Automatizamos cerca de 1.500 casos de ponta a ponta. A estabilidade de lançamentos bem-sucedidos tem realizado vários lançamentos em torno de 92 a 95%.

Os custos do recurso diminuíram quase 2,5 vezes. As corridas ocorrem em 3-4 horas, isso é feito à noite, para que pela manhã tenha resultados prontos.

Os detalhes da implementação técnica são descritos em uma série de artigos pelos meus colegas:


Se começarmos agora, levando em conta tudo o que escrevi, acho que economizaremos muito nossos nervos, tempo e orçamento.

Obrigado pela atenção. Faça perguntas, discutiremos. 

Fonte 

E também estamos esperando nossa equipe de jovens testadores!
, , .

More articles:


All Articles