Passado
A qualidade sempre foi uma necessidade, mesmo quando analisamos como ela era inserida nas linhas de montagem das fábricas no passado, validando manualmente o produto no final da linha de montagem para garantir que ele atendesse aos padrões esperados. As pessoas faziam validações manuais de uma série de parâmetros que se esperava encontrar em cada produto esperando o selo de aprovação. No passado, a qualidade pertencia aos testadores e eles eram os guardiões da qualidade.
Embora a qualidade fosse importante, o trabalho do testador sempre foi visto como menos importante do que, por exemplo, os montadores/construtores da cadeia. A ideia era que qualquer um pode testar, mas a construção exigirá habilidades, então os que não puderam ser construídos serão redirecionados para o teste, iniciando essa tendência de ver o teste como um trabalho menor.
Como queríamos ter entrega de software de qualidade também, trouxemos essas práticas para o nosso mundo, infelizmente fomos muito literais e acabamos tendo uma equipe separada esperando o produto finalizado (release) para realizar as validações. Assim, as equipes de desenvolvimento entregaram a versão para a equipe de testadores para ser testada, esperando obter a aprovação de qualidade.
Nós éramos os guardiões da qualidade, lutadores solitários da qualidade que aprovariam ou não um lançamento, únicos guardiões da qualidade que eram culpados se alguns erros/problemas chegassem à produção. Não estivemos envolvidos desde o início, mas as expectativas eram de que precisávamos entender tudo. Nessa idade das trevas, estávamos lutando sozinhos, vistos como aqueles que sempre bloqueavam uma liberação.
Ainda bem que o processo de desenvolvimento e o processo de testes evoluíram, o mercado reconhece e exige que a qualidade deve ser de todos e em todas as etapas do processo.
Presente
Os processos de desenvolvimento e teste foram alterados para se alinhar com as novas necessidades de lançamentos rápidos e feedback. As equipas sentiram a necessidade de mudar para terem lançamentos mais frequentes (exigidos por clientes mais exigentes) mas com um elevado nível de qualidade.
A composição e as responsabilidades da equipa mudaram, passamos a ter equipas mistas, com diferentes funções que se complementam com o objetivo de as tornar independentes. Mais independência significa que passaremos menos tempo esperando por outras equipes, pois dependemos apenas de nós mesmos (ou pelo menos esperávamos).
Daí nasceu a corrida da automação, não só dos testes mas de tudo, de repente todo mundo que não conhecia a automação passou a ser visto como alguém que não contribuiria tanto. A automação foi vista como a bala de prata para resolver todos os problemas de teste que podemos ter em nosso processo, tudo será mais rápido, melhor se você automatizar os testes.
Embora eu seja um grande defensor da automação, essa visão de que a automação de teste resolverá todos os nossos problemas tem feito mais mal do que bem. De repente, estávamos nos concentrando em resolver problemas de automação e esquecendo todas as outras melhorias que precisávamos fazer para sequer considerar pular para a automação. A área de testes começou a ver uma divisão entre os que sabem codificar e os outros. A pressão para aprender a codificar era alta porque parecia que, se você dominasse essa nova arte indispensável de codificar testes, estaria condenado na área de testes.
As funções nos testes começaram a ser redefinidas e novas funções começaram a aparecer, por exemplo, quando o SDET apareceu, fiquei muito feliz por finalmente ter uma definição de função que reconhece a capacidade técnica dos testadores… esse código testa apenas 🙁
O teste foi definido apenas pela automação e perdemos o foco do que era o teste. Felizmente, lições difíceis vêm dessa suposição e mudamos para mudar a mentalidade do que uma equipe é e deve fazer.
Quality is now a responsibility of everyone and the team members are helping and learning from each other.
Todos sabemos que não podemos automatizar tudo, a acessibilidade é difícil de automatizar, os testes exploratórios não podem ser automatizados, por isso continuaremos a ter espaço para testes assistidos. O que quero dizer com teste assistido? Acho que os testadores se beneficiarão de novas ferramentas e maneiras de fazer as coisas e as usarão para aprimorar a maneira como testamos nossos produtos/sistemas assistidos por essas ferramentas carregadas com AI/ML, aproveitando ao máximo.
Surgem novas formas de entregar software: DevOps, DevQAOps ou DevSecOps, que devem enfrentar todos os desafios de ter lançamentos frequentes com alta qualidade.
Futuro
Estamos à beira de uma nova mudança com o surgimento do Machine Learning e da Inteligência Artificial, essas novas áreas surgem com a necessidade de processar todos os dados que os sistemas estão produzindo e extrair dados valiosos para continuar aprimorando os sistemas de maneiras que beneficiem o usuário final.
Cada ferramenta/produto está tentando aproveitar a onda AI/ML e anunciar algum tipo de implementação de AI/ML, a maioria delas com usos muito ruins. Começamos a ver algumas ferramentas que usam AI/ML para escolher testes ou para analisar execuções de testes, mas cada uso que vemos aparecendo ainda está longe das capacidades de AI/ML. Acho que ainda estamos nos estágios iniciais de aproveitamento de IA/ML para testes, portanto, fique atento à medida que as coisas avançam rapidamente em nosso campo.
Mais do que nunca, os testadores devem se concentrar nas coisas que os testadores fazem de melhor, questionando, trazendo esse pensamento crítico para a mesa e o know-how adquirido com sua experiência. Os testadores estarão na primeira linha em relação aos produtos AI/ML, porque adivinhem? Eles precisam ser testados 🙂
Ao fazer parte das equipes que estão moldando o que as ferramentas AI/ML farão, temos a chance de influenciar o resultado e, como podemos ser os que mais as treinam e as utilizam, garantiremos nosso lugar no AI/ML mundo.
Precisamos ter uma compreensão de AI/ML, assim como precisamos ter algum conhecimento técnico para poder tirar proveito desse conhecimento em nossos testes. Essas ferramentas estão se tornando avançadas, na verdade, se forem construídas corretamente, seu uso deve ser transparente para o usuário, a ponto de serem mais fáceis de usar.
A Inteligência Artificial precisará ser regulamentada e essa necessidade, com certeza, gerará uma grande demanda de pessoas com mentalidade de testes. Se chegarmos a um momento em que todos os produtos terão AI/ML incorporado, o software de teste mudará para a validação do software AI/ML, garantindo que coisas ruins não aconteçam.
Acredito que AI/ML mudará a maneira como produzimos e testamos software, mas como os testadores farão parte dessa mudança, estaremos muito bem posicionados para usar sistemas baseados em AI/ML e aproveitá-los para acelerar seus testes.
Conclusão
O mundo dos testes e do desenvolvimento geral de software está mudando, novas práticas, novas tecnologias, e precisamos ser capazes de lidar com cada uma dessas mudanças e adaptar a maneira como fazemos as coisas a essas novas realidades.
Isso significa que todos nós precisamos nos tornar autômatos? Ou especialistas em AI/ML? Acho que não, definitivamente ajuda ter uma compreensão básica de como as coisas funcionam, mas um desenvolvedor de testes completo ou um desenvolvedor de python definitivamente não é o caminho a percorrer.
A forma como as coisas vão evoluindo vejo que as ferramentas e frameworks se tornam mais fáceis de usar e o foco está na mentalidade e na capacidade de perceber como tudo interage.
Para mim, os testadores estão em uma posição única para continuar sendo valiosos no futuro, serão eles que, auxiliados por ferramentas AI/ML, ajudarão a trazer qualidade a sistemas complexos.