O que eu aprendi em 3 anos atuando como QA — parte 2
Bom ou bom demais pessoal?
Essa é a última parte desse post, vou continuar contando o que aprendi e algumas reflexões sobre qualidade de software.
Só para recapitular na primeira parte eu falei sobre minha mudança de área, dificuldades encontradas com diversidade de plataformas, mudança de linguagem de programação e frameworks, para quem não viu a primeira parte pode ler aqui.
Continuando…
Estratégia de testes?
TESTA TUDO!
Esse foi o meu grito de guerra, mas não é bem assim que funciona :)
Onde você vai testar? como testar? em qual camada? vou bater direto nos serviços?
teste unitário? teste integrado? teste de contrato? teste de aceitação?
Agora que dividiu como vai planejar sua pipeline?
Eu não fazia a menor ideia do que era estratégia de testes, com isso veio minha primeira queda! Automatizei tudo o que podia e achava divertido, porém tudo onde? acho que vocês já devem saber! na camada de UI. Esse foi meu maior erro, eu não conseguia dar manutenção, eu não conseguia ter um feedback rápido do que eu tinha feito, essa suite rodava em 9 horas, isso se não tivesse alguma queda de ambiente, ou se por algum motivo o celular/emulador parasse de responder.
Sei que isso parece chato, mas galera se você quer ter uma pipeline confiável, se preocupe com seus testes flaky, distribuição errada de testes. Sobrecarga de testes em UI é custosa e gera uma dor de cabeça.
Todos esses novos conhecimentos não vieram do nada, foi conversando com muita gente e lendo muito. Vou deixar duas referências que me fizeram pensar muito sobre isso:
Specification by example — Gojko Adzic
Agile Testing — Lisa Crispin e Janet gregory
Integração contínua?
Essa cara aqui foi um tanto engraçado quando eu descobri que eu fazia isso a mais de 1 ano e não tinha ideia de que aquilo era uma integração contínua, eu já tinha uma Pipeline(na época eu não sabia o nome) que buildava meu projeto, rodava meus testes unitários e rodava alguns testes de performance. Isso tudo aconteceu quando me pediram para estudar Jenkins na outra empresa, como curioso eu fui estudar, mas pra mim aquilo era só uma “ferramenta”. Desde o momento que iniciei na nova empresa até hoje meu conhecimento só aumentou, vi que eu não sabia nada e precisava ir atrás , foi quando descobri o poder de uma pipeline bem estruturada, mas tudo isso só veio após eu passar pelo obstáculo que descrevi acima “Estratégia de testes”.
Projeto de testes também é código
DRY, Page Objects, Design Pattern, performance, legibilidade, boas prática ?!?!?!!?
Projetos sem o mínimo de arquitetura, alto acoplamento, copy and paste, não vão muito longe não e isso é a realidade rs. Teste também é código e por ser código precisa de manutenção e ou novas implementações, mas como fazer isso se você tem um filhote de frankenstein nas mãos?
Só tenho a dizer que isso vai ser uma dor de cabeça, já vi algumas coisas meio grotescas, mas somos seres humanos, eu mesmo já olhei código meu do passado e falei PUTA QUE PARIU eu realmente fiz isso. Ninguém é perfeito, mas se você olhar pra trás e conseguir enxergar isso a evolução foi realizada!
Eu aprendi a me preocupar com isso, sabem aquelas mensagens de banheiro
“Após você usar, outra pessoa também utilizará. Então mantenha a limpeza” ?
é exatamente assim que eu vejo código, se você não der a mínima pra tudo que é boas práticas e que fazem sentido serem aplicadas você vai estar não só desrespeitando a “regra” do banheiro, mas também se esquecendo que isso um dia você pode ter que colocar a mão nesse código novamente.
Uma coisa interessante é realizar técnicas de refatoração, pareamento para tentar diminuir a complexidade do que você anda escrevendo até porque qualidade também entra nesse pequeno/grande ponto que acabei de falar.
Não tinha a menor didática para ensinar alguém
Acredito que muita gente já deve ter escutado “Eu não entendi nada do que você tentou me passar”, o que pode vir a cabeça é que a pessoa não tem conhecimento e que você é mais esperto, mas calma lá!
Durante esses quase 3 anos acredito que esse soft skill, se é que posso chamar assim, foi um dos meus maiores ganhos, eu não tinha noção de que eu era acelerado, falava sem pausas, não tentava mostrar empatia sobre o ouvinte, traduzindo eu só cuspia as coisas e esperava que voltasse um 200 OK de entendimento. Logo não deu outra e recebi diversos feedbacks e vi que nem tudo era tão perfeito quanto imaginei, sou muito grato por esses feedbacks, foi nesse ponto que vi que eu precisava rever alguns conceitos básicos, fui conversar com meus gerentes e mais alguns feedbacks e algumas metas para cumprir, onde cada uma delas era ligada a esses feedbacks, tive uma grande dificuldade em olhar pra mim mesmo e falar é isso realmente está acontecendo, só assim essas metas começaram a andar. O mais legal disso tudo foi ver 3 ou 5 meses depois as mesmas pessoas que me deram feedbacks em relação a isso, me elogiando e contando como eu tinha evoluído, mas as metas ainda não tinham sido provadas um dos últimos desafios era conseguir palestrar em algum evento.
Palestras
Como o final round das metas que tinham me sido passadas eu precisava colocar a prova e ver se realmente o que eu estava tentando aplicar estava fazendo sentido, nada melhor que fazer isso de uma só vez para 200 pessoas né? ou será que não?
Fui palestrar em dupla com meu gerente em belo horizonte, assunto conhecido do meu dia a dia, pra minha surpresa consegui falar pausadamente e não interromper meu par.
Olhando os vídeos novamente enxerguei pontos de melhoria, quando se está em cima do palco o tempo voa e você parece estar dentro de um aquário, sim eu falei rápido e sem pausas em alguns momentos, mas os feedbacks foram muito bons.
Olhando um pouco mais longe no túnel do tempo quem diria que o cara que tinha vergonha de perguntar um nome de rua estaria em cima de um palco falando para 200 pessoas?
MTC -Pirâmide de testes mobile
Eventos
Essa é uma parte muito interessante da minha carreira, eu não tinha o costume de acompanhar os eventos que estavam rolando na comunidade, mas graças a um desafio profissional que meu gerente me passou(que também era um outro desafio após palestrar em eventos), comecei a frequentar alguns eventos e hoje eu organizo um meetup junto com o Júlio de Lima, batizamos ele de GaroaQA que é uma referência a São Paulo a terra da garoa.
Essa experiência de passar conhecimento de forma gratuita e conseguir ajudar as pessoas a consolidar mais o conhecimento é muito gratificante e toda vez aprendemos algo novo, não é porque somos os organizadores que sabemos tudo, a melhor parte disso tudo é poder compartilhar e absorver coisas novas.
Reflexões
Eu poderia escrever mais 5000 palavras aqui, mas acredito que fugiria do intuito do post que foi muito mais fazer uma avaliação do que passei e aprendi nesses 3 anos.
Vamos lá nem sempre vamos ser vistos como integrantes do time, qualidade é uma responsabilidade do time, não de um papel. Se você tem esse tipo de problema, não adianta ficar reclamando que não te enxergam como integrante, que entregam as coisas em cima da hora, se você nunca ao menos tentou explicar para eles como fazer alguns pequenos entregáveis durante a sprint, se você nunca se mostrou disposto a participar de um refining ou de talvez usar seu conhecimento e apresentar alguma coisa nova para ser aplicada.
Existem muitos ambientes no mercado corporativo, mas não se deixe ser vencido sem ao menos tentar.
Nossa evolução acontece por sede de mudanças e melhorias, tente se manter atualizado, participando de eventos, fóruns, rodas de discussões. Existem diversos lugares onde você pode obter conhecimento de forma gratuita e de forma paga:
Documentação dos seus frameworks
Agile testers
Udemy
QA Sampa meeting
GaroaQA
Slack comunidadeqa.slack.com
Slack qa-br.slack.com
Livros tais como os que citei acima (Specification by example, Agile tester, more agile testing)
Medium
Antes de sair falando que um framework é melhor do que o outro, avalie se ele é estável, quantidade de issues abertas e PR’s parados. Pesquise na comunidade se é um framework muito utilizado, faça uma POC seguindo as boas práticas, olhe se o framework possui roadmap de novas features e fix. Nós só vamos chegar numa maturidade boa e realmente ser técnicos quando pelo menos conseguirmos fazer isso.
Se estamos usando alguma coisa temos que no MÍNIMO explicar o motivo do uso e porque escolhemos esse tipo de abstração para trabalhar.
Questione se é a única forma de se fazer e se realmente é uma boa prática, muitas vezes nos vemos em um check mate, onde tentam forçar que você crie um teste na camada errada, ou coloque 10 sleeps na sua automação. Questione isso, porque precisamos criar um teste em UI que poderia muito bem estar na camada de serviço?.
Lembrem-se que um dos principais conceitos, se não o principal é feedback rápido e confiável, ninguém quer uma suite lenta e nada confiável.
Por último acreditem em vocês mesmos e busquem sempre melhorias!
