O que eu aprendi em 3 anos atuando como QA — parte 1

agile testers 2016, o início.

A era atuando como desenvolvedor backend, front e mobile

Para começar, vou contar onde eu estava antes desses 3 anos.

Iniciei na carreira de tecnologia em uma empresa que sou muito grato pelo meu primeiro estágio. Lá eu fiquei 8 meses como estagiário e 10 meses como funcionário efetivo, foi um desafio gigante para mim. Antes de eu ser efetivado, todo os desenvolvedores Java foram embora da empresa. Que barra heim!! Com isso eu passei a cuidar de todos os sistemas escritos em Java e estudando Android. Mas a vida é assim, cheia de desafios e provações. Nessa empresa eu trabalhava com Java EE, Spring, JSF, WebApps, WebServices, SQL 2012, Jboss, TomCat, Glassfish, javascript, Android e infelizmente muito HTML e CSS.

Nesses quase dois anos tive muito contato com Jmeter e testes unitários, mas não tinha a mínima noção do que estava fazendo, até que surgiu a oportunidade de entrar na empresa que estou hoje.

O motivo da mudança de área (A mudança de area)

Escutava muito na faculdade "quem vira QA é desenvolvedor frustrado". Hoje eu falo que, quem ainda repete isso, não tem a menor idéia de como é ser um QA ágil rodando dentro de algum time. O motivo da mudança foi a chance de conhecer o outro lado da moeda. Como é que podemos garantir qualidade de software usando as famosas buzzwords do momento "agilidade", "escalabilidade", "scrum", etc? Seria um tiro no escuro. Porém, olhando para trás, foi um tiro certeiro e me encontrei, nunca parei de desenvolver, continuo muito firme e forte. Porém agora o foco é em passar meu conhecimento e atuar como um embaixador de qualidade, tentando evitar que seja falada a frase "agora passa para a coluna de QA que ele faz o teste".

A era atuando como QA

Meu primeiro dia foi um tanto engraçado, escritório novo, pessoas novas, processos novos e o mais importante uma nova área de atuação. O melhor de tudo foi ver um processo de trabalho totalmente diferente, pode parecer até mentira, mas as coisas ocorriam praticamente igual aos livros que eu tinha lido e onde citavam o Eldorado do desenvolvimento, porém nem tudo são rosas eu precisava estudar até porque eu vinha de outro contexto, o que um QA precisa saber ?!?!.

O que fui aprendendo durante o caminho…

O que um QA faz?

Isso pra mim foi o maior impacto, eu já sabia desde a entrevista que seria diferente, que eu teria que atuar como um QA inserido no contexto ágil, mas a ficha só caiu quando entrei para ser integrante de um projeto "estou inserido num ambiente onde os times são multidisciplinares, não existe esteira, não tinha ninguém com excel criando os famosos CT's (Casos de Testes) que eu vi na faculdade, e agora?!?!"
Estudar, procurar referências, conversar com QA's mais experientes no contexto ágil.

E foi o que eu fiz, procurei pessoas que já estavam inseridas nesse contexto e pedi indicações do que ler, onde procurar e como se mantiam atualizados, meu líder na época também me ensinou muito a respeito, mas ninguém evolui apenas fazendo as lições que passam na escola.

Lembrando que hoje um dos maiores desafios de um QA é fazer o time te enxergar como um integrante do time, não uma pessoa apartada que vem te dar a má notícia. Essa mudança de pensamento é um desafio gigante e envolve lidar com pessoas o que nem sempre é fácil, você precisa ter jogo de cintura e mostrar o seu real valor dentro do time. Ou seja passar o mindset que você possui de qualidade para o resto do time.

Plataformas

Iniciei com o papel de QA em testes mobile, como eu já tinha trabalhando como desenvolvedor Android antes, achei que já sabia muita coisa, mas foi outro balde de água fria, percebi que eu não sabia nada.

Descobri que iria olhar tanto para Android como iOS, mas o que precisaria saber para conseguir garantir qualidade nessas plataformas completamente diferentes?

Foi ai que tive que descer alguns degraus e novamente voltar a estudar, para conseguir andar pelo menos um pouco sozinho.

Hoje se alguém me perguntar o que um QA que vai iniciar em testes mobile precisa saber técnicamente, eu vou responder:

• Conhecer a arquitetura da sua plataforma
• Como sua plataforma trabalha
• Saber as fragmentações de sistemas
• Suporte
• Guide de cada plataforma
• Conhecer o mínimo sobre ciclo de vida de views
• Aprender a diferença entre instrumentado e funcional
• Mobile é um ambiente dinâmico então, se atente a acontecimentos inesperados como, falta de internet, background, orientação, etc…
• Quais as diferenças de rodar seus testes em emuladores/simuladores x device físico

Existem outros pontos, mas acredito que esses sejam os mais importantes.

Linguagem de programação

A linguagem que usaríamos era Ruby, por conta do Calabash, framework escrito em Ruby e desenvolvido tendo como base o Cucumber, ou seja a única maneira de utiliza-lo era com Ruby, até então eu só tinha tido contato com C e C++ na faculdade, Java, javascript e arriscava algo em python, confesso que o primeiro mês foi um tanto tenso , eu ainda não tinha me acostumado com a sintaxe de Ruby, nem a maneira que ele trabalha. Com isso voltei algumas casas e comecei a ler o The Well-Grounded Rubyist que o meu mentor na época me indicou, isso foi como se colocassem informação na minha cabeça e as coisas começaram a fazer sentido, hoje eu não me considero nenhum Dev ninja em Ruby, mas eu não passo apuros.

Frameworks

Para trabalhar com automação não é apenas a linguagem que vai salvar você, esse segundo obstáculo eu não senti tanto, o ecossistema que eu trabalhei por praticamente 2 anos me fizeram criar uma sede de saber como as coisas funcionam por baixo dos panos, JSON wire protocol, instrumentador dos testes, comunicação HTTP entre as ações que você envia para o seu app, o servidor que está rodando atrás de tudo isso recebendo seus requests, olhando para o cenário de testes de aceitação end-to-end tive um contato gigante com Calabash(descontinuado pela equipe que mantia, porém o repositório se mantém aberto) e Appium.

Se você ainda está lendo, vai se perguntar tá mas cadê o obstáculo? eu não sabia nada disso que descrevi acima, o obstáculo foi em aprender como a minha ferramenta de trabalho vai funcionar, o que vai acontecer quando eu pedir para que um elemento seja tocado, vejo muita gente com dúvidas básicas, que poderiam ser solucionadas se tivessem olhado pelo menos o README do framework, a mensagem que eu queria passar aqui nesse pedaço é que o seu melhor companheiro é seu conhecimento e ninguém pode tirar ele de você. Então invista um tempo e alimente esse seu melhor companheiro que ele pode te ajudar muito no futuro.

Frameworks voltados para testes que trabalhei ou já utilizei fora do trabalho:

• Calabash
• Appium (Java e Ruby)
• Rest Assured
• SuperTest
• HTTParty
• Rspec
• Espresso
• Cucumber
• Jmeter
• Junit
• Capybara
• Protractor

Bom galera essa foi a primeira parte da minha "mini" história, na próxima parte vou falar sobre, estratégia de testes, integração contínua e muito mais, fiquem ligados que sai em breve!

Sigam:
https://www.instagram.com/garoaqa/
https://www.meetup.com/pt-BR/garoaqa/