Olá Habr!
Decidi escrever minha opinião sobre se a automação dos testes substituirá os próprios testadores. Primeiro de tudo, porque muitas vezes ouço uma opinião semelhante entre o Junior QA, que está apenas dando os primeiros passos nos testes e já tem medo de não conseguir fazer algo.
Para ser justo, existe uma opinião semelhante entre as crianças mais velhas. Muitas vezes, acredita-se que a automação é quase a única maneira de desenvolver um testador manual. Sobre tudo isso e muito mais sob o corte.
Um pouco de esclarecimento antes de começarmos. Toda a discussão abaixo será sobre autotestes funcionais. Esses são testes de interface do usuário, que não devem ser confundidos com testes de unidade nesse contexto. Os últimos sempre foram escritos e devem ser escritos por desenvolvedores, e onde isso não é verdade, é objeto de uma discussão completamente diferente.Brevemente sobre a história da automação
Trabalho com testes há algum tempo e já assisti a vários estágios no desenvolvimento da automação de testes. Com seu desenvolvimento, sua atitude em relação a ela também mudou. Vamos ver como foi e tentar entender - o que é tudo isso?
Em 2010, quando eu estava dando meus primeiros passos no mundo da TI, nem todo mundo conhecia uma ferramenta como o Selenium. Naquela época, sua primeira versão estava em uso, chamada Selenium Remote Control.
Lembro como automatizamos nosso primeiro projeto no Selenium. Essa ferramenta era bastante simples, pois podia clicar em elementos invisíveis, às vezes se enganava em encontrar localizadores e até ao receber texto de alguns elementos complicados.
Ainda me lembro que nosso chefe os chamou de "cutucadas". Vendo como sentamos e escrevemos esses testes, ele disse: novamente, escreva suas cutucadas? Tipo, eu não teria verificado e lançado com minhas mãos há muito tempo.
Mas o tempo passou, Selenium desenvolveu, ele teve novas oportunidades. No início, houve uma segunda e agora sua terceira versão. Um padrão apareceu (os fabricantes de navegadores começaram a escrever drivers), o Selenium adquiriu vários protocolos, adquiriu concorrentes no mercado e agora quase todo mundo que trabalha em TI sabe disso, independentemente de pertencer ao controle de qualidade.
No momento, existem muitas soluções para testar a automação de aplicativos da Web e móveis.
Agora isso não é mais apenas uma cutucada, agora a conversa média do RH para a posição de controle de qualidade se parece com isso (exagerada, é claro):
Boa tarde De acordo com o seu currículo, não está claro, você sabe como escrever autotestes?
"Não, mas eu sou bom em ..."
- * já desliguei *
E se essa for uma posição de liderança, você ouvirá que eles gostariam de configurar a automação e só depois contratar engenheiros de controle de qualidade. Ou não contrate. E se você não? Bem, isso é uma economia. Mesmo depois de escrever todos os testes, você seria demitido. E os desenvolvedores, quando farão tudo ... Deixe no site um botão "Pague aqui" e pare no pôr do sol ... Algo deu errado para mim.
Obviamente, com essas tendências, surge a pergunta: os testes manuais substituirão a automação? E quando isso vai acontecer?
Autotestes através dos olhos dos desenvolvedores
Para responder a essa pergunta, vale a pena pensar primeiro - e quem escreve autotestes? Vi empresas nas quais os autotestes são escritos pelos próprios desenvolvedores. E vi empresas nas quais os engenheiros de controle de qualidade escrevem autotestes. O que você acha que é a diferença fundamental?
Eu gostaria de assumir que a diferença está no código. Como eles são desenvolvedores, eles escrevem melhor o código. Portanto - seus testes são melhores. Mas isso não é inteiramente verdade.
A qualidade do código é, sem dúvida, um parâmetro importante, mas para os próprios desenvolvedores, o teste não é a principal ocupação. E, portanto, eles não podem dedicar muito tempo a isso. Os testes são escritos às pressas e o código geralmente deixa muito a desejar. E esta é uma situação normal, repito - não é com isso que eles devem gastar uma quantidade significativa de seu tempo de trabalho.
Um código especialmente bom não é a coisa mais importante nos autotestes. O mais importante é que casos esses autotestes abrangem. E aqui o pensamento de um especialista em controle de qualidade já é significativamente diferente de como o desenvolvedor vê o produto.
Considere um exemplo. É necessário cobrir o registro no site com testes automáticos. É claro que, em primeiro lugar, abordaremos um caso positivo. Entramos, marcamos um formulário de cinco ou seis campos de entrada, passamos por algumas etapas adicionais, como confirmação por email ou SMS - o teste está pronto, você é ótimo!
Argumento que 90% dos desenvolvedores que caíram da responsabilidade de escrever autotestes param por aí. Eles não descreverão parte dos casos, porque consideram que eles não são essencialmente diferentes do que já foi coberto. Alguns simplesmente não serão levados em consideração. Enfim, "eu mesmo escrevi o código de produção, tudo é confiável lá e para sempre".
Classes de equivalência, valores-limite, casos negativos - tudo isso permanece em algum lugar à margem.
Abordagem de engenheiro de controle de qualidade
O engenheiro de controle de qualidade adota uma abordagem diferente. Ele tem experiência, um entendimento dos princípios do design de teste, uma quantidade de tempo suficiente e, o mais importante, procura por bugs e verifica se é sua responsabilidade direta. Além disso, na maioria das vezes, essas pessoas estão interessadas apenas em verificar algo. O que acontece se você cutucar aqui fora de turno? E se você inserir os dados aqui incorretamente?
É a abordagem que distingue o engenheiro de controle de qualidade do desenvolvedor. E é formado não pela capacidade de automatizar testes, mas por uma maneira de pensar. Um testador ruim escreverá testes ruins. Nesse caso, um bom testador encontrará mais problemas com a verificação manual do que um mau em seu conjunto de casos de teste mal concebidos.
Que conclusão eu gostaria de tirar disso? Tudo é muito simples. Um especialista em controle de qualidade é principalmente um entendimento dos princípios de teste e da experiência de teste que uma pessoa possui. E não as ferramentas que ele usa.
Claro, apenas ser um bom testador não é suficiente. Sem o conhecimento das ferramentas básicas, como bash, Git, SQL, etc., é impossível trabalhar efetivamente em qualquer empresa. Eles devem ser estudados.
A automação é a mesma ferramenta, por si só não é boa nem ruim. Isso não tornará seu trabalho mais eficaz simplesmente porque você o escolheu. Ele ainda precisa de certas habilidades.
Bem, e a verificação manual?
A verificação manual não irá a lugar algum. De uma maneira ou de outra, quando vemos um novo recurso ou um produto inteiro à nossa frente, vamos estudá-lo com as mãos. Ainda precisamos descobrir como funciona, quais casos devem ser considerados prioritários e, em geral, se eles funcionam agora. Qual o sentido de escrever um teste se o produto estiver com defeito?
E sempre será assim, com cada novo recurso ou alteração introduzida. Primeiro, haverá uma etapa de verificação manual. E só então - cobertura ou atualização de testes em torno dele.
Seria melhor se o teste e a gravação manuais dos autotestes fossem realizados por um especialista ou por responsabilidades compartilhadas? Eu não sei, isso já depende dos recursos de como o processo é construído na sua empresa. Em algum lugar, será eficaz e, portanto, benéfico. E em algum lugar - não.
Então, para a pergunta se vale a pena estudar a automação de testes, respondo categoricamente que sim. O engenheiro de controle de qualidade deve estar familiarizado com a automação. Normalmente, especialistas com essa habilidade têm mais currículos e salários e são mais valorizados no mercado. Mas a automação substituirá a verificação manual e o teste manual? Claro que não.
Sumário
Foi assim que este artigo surgiu. Eu compartilhei minha opinião e minha visão do problema. Ficarei feliz em saber sobre o seu, não deixe de compartilhar nos comentários!
E também um colega da Yandex desenvolveu um curso on-line para quem gostaria de mergulhar na automação de testes móveis. Informações e links podem ser encontrados na minha página de perfil. :)
Obrigado pela atenção!