O autor descreve sua jornada de aprendizado em automação de testes, desde o medo inicial do desconhecido até entender que pode aprender novas habilidades e trabalhar em equipe para garantir a qualidade do software.

1. DevQA:Enfimaprendiàresolverproblemas
22 JANUARY 2016 on DevQA, Testes de Software, Qualidade de Software
Quando tento me lembrar quando a automação de testes entrou na minha
vida profissional, preciso realmente parar alguns instantes e antes de me
lembrar desse ponto que poderia ser de partida, preciso me lembrar o que
esse termo significava naquele momento, pois lembro sem qualquer
dificuldade o prazer de aprender algo novo e o medo do desconhecido se
misturavam em minha mente.
Significava prazer, pois seria sinônimo de desafio e aprendizado, sair da minha
zona de conforto, deixar de ser uma parte da equipe que até então mantém
seu trabalho quase que independente da ajuda de qualquer outro colega.
Aliado ao medo, justamente pelos mesmos motivos, mas de forma totalmente
inversa, eu precisar pedir ajuda, auxílio e reconhecer que já não dominava
tão bem todas as nuances das atividades que precisavam ser executadas.
Nesse momento vem os pensamentos, "E se houvesse outro profissional mais
qualificado que pudesse ficar no meu lugar?", "E se por mais que insistisse,
nunca assimilasse a sintaxe Java, aquela chamada de tela, identificação de
componente, uma consulta em banco de dados ou a impressão de mensagem
na tela?".
Agora sim, consigo lembrar quando ganhei esse presente.
Estava começando em um novo projeto, por sua natureza já era um desafio,
uma realidade bem diferente da vivida até então, o elefante branco agora era
dentro de um ambiente bancário, um projeto do governo já iniciado e
desenvolvido por outras equipes, é, seria ali e agora que eu teria que
aprender mesmo. Ao iniciar, as atividades não seriam muito alheias ao que já
trabalhava, elaborar a Matriz de Rastreabilidade entre os cenários, analisar a
documentação e então desenvolver os Casos e Cenários de Testes, criar os
Planos de Testes para cada nova interação e não menos importante, realizar a
execução dos testes propriamente dito.
Até ai tudo bem, todas essas atividades ainda seria validada por uma equipe
interna de Qualidade de Software (que rufem os tambores), me obrigando a
ser mais criteriosa e trazendo melhoria continua ao meu trabalho, mas a
principio, não me causou nenhuma estranheza, medo ou algo assim. Porém,
naquela época eu estava com uma mentalidade bem diferente da que possuo
hoje, então pensei: "Alegria de pobre dura pouco... pouquíssimo!" e isso se
daria pela singela notícia que a partir dali, eu também ficaria responsável
pela A-U-T-O-M-A-Ç-Ã-O D-O-S T-E-S-T-E-S F-U-N-C-I-O-N-A-I-S do
projeto, "Hã? Hum? Oi?".

2. A notícia não foi apenas assustadora pela responsabilidade, pois junto com ela
vinham questões do tipo, "Não posso usar Recording and Play!", "Eu não sei
programar em Java!", "Eu não conheço as ferramentas de automação da
IBM!", "Vai dá tempo fazer algum curso?", "Será que eu consigo algum tutorial
ou guia fácil?","Alguém pode ou sabe me ajudar por onde começar?". Naquele
momento me resignei a procurar alternativas, pois não teria como me
revoltar, nem ficar com raiva ou até mesmo bater o pé e procurar alguma
justificativa que me fizesse reverter aquela situação, com isso, o mantra
agora é: "Ok, vamos lá!".
Busquei antes de mais nada encontrar algum contato dentro do meu
networking que tivesse experiência com a ferramenta, que então pudesse me
ofertar algum tipo de orientação. Conversei com alguns uns com uma visão
bem positiva até, outros já nem tanto. Então resolvi buscar, dentro do
ambiente de trabalho, alguma referencia ou documentação que eu pudesse
utilizar. Até que encontrei, pena não foi de muita valia, essa busca só me
rendeu um calhamaço de papel e uma cópia de um guia de usuário. No final,
só ficou a intenção foi boa.
Foi então que resolvi engolir todo o meu orgulho e busquei no âmago do meu
ser o meu tom mais cordial, enfim pedi ajuda aos desenvolvedores. Eu
precisava entender ao certo como a ferramenta funcionava, além do
simplestela.clickDropDown ou tela.clickButton. Precisava entender a
necessidade de mapear os elementos que compunham as páginas e escolher
entre os IDs e osNames. Além de que, também precisava entender como
funcionava as consultas num banco de dados, como também os retornos, e
claro, vê a execução de tudo aquilo que estava sendo escrito, o medo era que
se tudo aquilo ia dá certo, se aquele código todo faria parte da integração
contínua, que validaria diariamente o que estava sendo desenvolvido, afim de
garantir que as novas implementações não impactariam de forma negativa o
que já estava estável. Com isso passei a nutri um bom sentimento para aquele
novo aprendizado e o que estava sendo gerado a partir dali.
Infelizmente o que eu menos poderia esperar, era que o escopo não estava
tão bem definido assim, como eu imaginava. Como poderia, após dois meses
de trabalho árduo e aprendizado constante, haver mudanças dentro da
especificação de caso de uso? Como poderia conceber que tal mudança, por
menor que fosse, traria um impacto de re-trabalho que não poderia (ou não
queria) mensurar?
Com isso, me deparei com a triste porém realidade necessária, mudanças
podem e devem acontecer. E que apesar do re-trabalho, a oportunidade de
refatoração do código dos scripts escritos traria um novo aprendizado. "Onde
e como melhorar?".
O porém, era que a minha mudança de pensamento estaria apenas se
iniciando, pois eu me sentia confortável atuando daquela maneira e com

3. aquela equipe de profissionais específica. Novamente, o futuro me tirava da
zona de conforto, e durante uma mudança de projeto, com uma nova equipe,
ao pronunciarem A-U-T-O-M-A-Ç-Ã-O D-E T-E-S-T-E-S, mais uma vez o prazer e
o medo se fizeram companheiros a volta do pensamento de ser auto
suficiente, para gerir e garantir a execução das minhas atividades sem
qualquer dependência, "Mas eu não fazia parte de uma equipe?".
Aprendi a duras penas a configurar o meu ambiente e iniciar a automação.
Quando fui conhecer realmente a cultura Ágil num evento, pude perceber o
quanto meu pensamento era engessado, que por si só, engessava algumas, pra
não dizer a maioria das minhas atividades.
O conhecimento de como os testes eram feitos e como eles funcionavam me
trouxe como profissional o entendimento que eu não precisava ficar presa ou
amarrada à artefatos, que o mal uso poderia tornar esses obsoletos e eu
poderia fazer parte do processo desde do início, desda a concepção, passando
pelo desenvolvimento até os testes propriamente dito.
Entendi que não preciso ser auto suficiente em cem por cento das coisas que
preciso executar, que para ser uma boa profissional com um bom
conhecimento para automação, não preciso necessariamente ser uma
especialista em qualquer linguagem que seja, basta que eu tenha um bom
domínio sobre a lógica, para entender e conseguir chegar a uma solução. Eu
preciso por hora ter uma boa relação e se essa puder ser íntima com
uns if,ifelse e for, isso seria o ideal. Que é interessante que eu interaja na
maioria das etapas do desenvolvimento, pois eu, quanto uma boa profissional,
agora de qualidade e não apenas de testes, posso e devo assegurar que existe
qualidade nos códigos unitários dos meus desenvolvedores, bem como nos
códigos propriamente ditos e que para isso, eu disponho de ferramentas que
me ajudam nessa atividade, "Salvem o Sonar!".
Também é bem mais interessante, e eu poderia dizer até mais divertido,
trabalhar com especificações compiláveis. Agora faz muito mais sentido, o uso
de técnicas como BDD, e conhecida por alguns, a Specification By Example.
Deixei de ser uma simples executora de testes manuais e funcionais, para ser
parte ativa na garantia da qualidade daquele produto que também leva meu
nome.
Agora eu aprendi a resolver problemas, os meus e os do time.
- Links Relacionados:
Originalmente publicado em: http://mihqueiroz.com.br/2016/01/22/devqa-
enfim-aprendi-a-resolver-problemas/