DevQA: Enfim aprendi à resolver problemas 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?".

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

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/