O dia em que uma QA corrigiu seu primeiro bug
Uma reflexão sobre sair da zona de conforto
Muito se fala em sair da zona de conforto e o quanto isso é importante para o nosso crescimento no trabalho e na vida. O medo do desconhecido misturado à empolgação e desejo por algo novo formam uma mistura realmente única.
Mas para nós QAs, o que significa sair da zona de conforto? O que significa chegarmos no próximo nível?
Recentemente, cheguei em um lugar tão, mas tão longe da minha zona de conforto, que isso me motivou a escrever um artigo para contar para vocês como tem sido essa experiência.
A ideia é motivar e encorajar a comunidade a desbravar lugares cada vez mais distantes do lugar comum do nosso dia a dia. Isso pode ser transformador para nós e para o nosso time!
Vou começar meu relato pela parte mais bombástica: o dia em que corrigi meu primeiro bug. E depois, vou contar para vocês que estrada trilhei para chegar até aqui.
Então vamos lá!
O dia em que corrigi meu primeiro bug
Eu estava testando uma implementação que demorei um pouco para entender como funcionava por debaixo dos panos. Pedi ajuda a um dev do time para entender melhor como era o funcionamento e esclarecer várias dúvidas que surgiram enquanto eu lia os códigos. Ele gentilmente me ajudou e me explicou um monte de coisas.
Segui com os testes e identifiquei um pequeno problema cuja correção me pareceu simples: um arquivo estava sendo incluído indevidamente, enquanto outro que deveria estar sendo incluído não estava.
A correção consistia em poucas linhas de código, e seria algo bem parecido com o que já estava implementado. Então criei coragem e decidi fazer eu mesma a correção (claro, depois de reportar o problema, anexando as evidências e etc).
Novamente, pedi ajuda a um dev do time para subir a mudança para o nosso repositório. Antes de fazer isso, fizemos juntos um code review e vimos que precisaríamos fazer pequenos ajustes na correção que fiz (se você é QA e nunca fez code review, super recomendo ler este artigo da Bruna Fernandes).
Tudo ajustado, subimos a mudança no nosso repositório no Git.
E foi isso. Simples assim.
Não foi um dia em que acordei e pensei: “hoje vou corrigir um bug!!!”. Foi algo que aconteceu naturalmente. Mas como? De onde simplesmente criei coragem, fui lá e corrigi um bug que eu encontrei? Pois é, até este dia eu trilhei um longo caminho.
Senta que lá vem história…
O princípio de tudo
Há um tempo eu vinha querendo me aprofundar mais nos estudos na área de QA. Vinha fazendo o possível dentro do tempo que eu tinha disponível, mas eu queria estudar num ritmo mais intenso do que eu estava estudando. A minha evolução vinha lenta demais. Mas por limitações de tempo, isto não estava sendo possível.
Aí veio a pandemia. E tudo mudou.
O Home Office, que era bastante esporádico, tornou-se rotina. Meu tempo de deslocamento para o escritório se reduziu a zero. E aí, ficou bem mais viável aumentar o meu ritmo de estudos diários.
Nesses meses de quarentena, fiz vários cursos, todos relacionados de alguma forma com a área de QA. E conforme eu fui ganhando mais conhecimento, fui vendo que tinha muito mais coisas para aprender. Um círculo virtuoso.
E conforme fui aprendendo mais, me encorajei cada vez mais a ir além, a fazer coisas que nunca fiz, a desbravar o desconhecido. É incrível como o conhecimento faz a gente se sentir cada vez mais capaz de sair da zona de conforto.
E meu dia a dia no trabalho começou a mudar.
Código, vem cá, seu lindo!
A primeira grande transformação que vivi nesses tempos foi começar a olhar para o código, sem medo, mas sim com curiosidade. Fiz milhões de perguntas aos devs do meu time para entender melhor como tudo funcionava por debaixo dos panos. E eles sempre me explicavam tudo 💜
Inclusive fiz curso da linguagem de programação que usamos no backend, para me ajudar ainda mais a entender os códigos (e também automatizar testes no backend). Dessa forma, pude melhorar muito o planejamento dos meus testes, pois eu passei a ter um entendimento muito mais completo do produto que eu testo.
Entender mais o código e o funcionamento do backend como um todo me possibilitou investigar de forma muito profunda o problema que encontrei. Desta forma, consegui encontrar o trecho de código que teria de ser corrigido. E foi isso que me levou a corrigir meu primeiro bug :)
Eu conto um pouco mais sobre como foi a experiência de desbravar o backend neste artigo.
SonarQube: a porta de entrada para o outro lado
Profundo esse título, né?! Mas acho que ele resume bem o que aconteceu. As primeiras vezes que mexi no código foi para corrigir pequenos code smells reportados pela ferramenta SonarQube.
Para quem não conhece, o SonarQube é uma ferramenta maravilhosa para análise estática de código. Através de um conjunto de regras (chamadas de Quality Profiles, que são personalizáveis inclusive), o SonarQube analisa o código procurando por vários tipos de problemas, desde erros de formatação de código até vulnerabilidades de segurança.
É possível rodar o SonarQube na integração contínua (por exemplo, no Jenkins). Além dele, também existe o SonarLint, que você pode instalar na sua IDE e já ser alertado sobre problemas no código antes mesmo de subi-lo. Legal, não? Se quiser saber mais sobre o SonarLint, super recomendo este artigo do Flavio Souza.
Mas voltando à minha história: consegui consertar esses pequenos code smells reportados pelo SonarQube justamente porque eu já tinha adquirido um conhecimento razoável tanto da linguagem de programação quanto do funcionamento do backend. Então eu tinha condições de saber como consertar. Eram problemas bem pequenos, super pontuais, mas que me ajudaram muito a ganhar confiança em mexer no código.
Uma pitada de integração contínua
Sim, me aventurei por essas bandas também!
No dia a dia, eu aprendi com o meu time a usar o Jenkins, uma ferramenta maravilhosa de integração contínua. Ele é bastante poderoso e intuitivo, então o basicão eu já sabia.
Porém, já aconteceu de termos problemas em nossos jobs e eu não conseguir ajudar muito. E isso me incomodava. Eu queria poder ajudar mais.
Então decidi fazer um curso específico de Jenkins para me aprofundar. E foi maravilhoso! Pouco tempo depois, já consegui ajudar o meu time, implementando melhorias nos nossos jobs e recentemente criei um novo, que estávamos precisando.
E que lições tirei dessas aventuras todas?
Conhecimento é poder e ter um time unido é tudo!!! Eu consegui me aventurar em lugares tão distantes porque eu me esforcei em aprender, mas também porque meu time sempre me apoiou.
Hoje eu me sinto mais capaz de ajudar o meu time em momentos de sufoco, porque eu consigo ajudar se ocorrer algum problema na integração contínua, ou mesmo se for necessário fazer alguma pequena correção que seja simples, mas super urgente.
Sem contar que entendendo bem mais como o backend funciona, eu consigo investigar de forma mais profunda os problemas que encontro e consigo entregar para os devs um report de bug confiável e fácil de entender, já indicando a causa raiz do problema, o que agiliza a correção.
Quando todos se ajudam, todos ganham!!
Espero que este relato te inspire a ir além, a buscar sempre mais conhecimento, e a incentivar a colaboração dentro do seu time. O segredo não está em ser melhor do que ninguém, mas sim em buscar ser melhor do que você era ontem :)
Colaboração e revisão: Gabriel Santos e Rafael Targino
