Em qualquer equipa de desenvolvimento há um papel fundamental que, muitas vezes, só ganha visibilidade quando algo corre mal: o do QA Engineer. Mas garantir a qualidade de um software vai muito além de simplesmente encontrar bugs. Mais do que testar, um Quality Assurance Engineer é responsável por antecipar problemas, definir estratégias de validação e garantir que cada funcionalidade cumpre os requisitos esperados. A sua colaboração com developers, product managers e outros stakeholders é essencial para entregar produtos robustos e fiáveis.
Neste artigo, damos-te a conhecer o dia a dia de um QA Engineer através da perspetiva de uma das nossas consultoras, a Marcella Pacobahyba. Falámos sobre as suas responsabilidades, os desafios da profissão, a importância da automação de testes e até os bugs mais inesperados que já encontrou. Se estás a considerar uma carreira em QA ou queres saber mais sobre esta área, continua a ler!
O que faz exatamente um QA Engineer e qual é a sua importância num projeto de software?
O QA garante a qualidade do produto ou do serviço que o cliente pede. Temos de garantir e fazer toda a análise de riscos que podem surgir, tratar esses riscos e a análise para que entreguemos o produto com qualidade. Temos de assegurar que o produto ou o software tem a qualidade esperada pelo utilizador e que seja responsivo, que vá ao encontro do que o cliente pediu exatamente e que também está de acordo com o que foi pedido lá no início.
Como é o teu dia-a-dia enquanto QA Engineer? Quais são as principais tarefas que realizas no projeto atual?
As minhas principais tarefas focam-se em ler documentação (isso é principal) e ter uma comunicação muito boa com todas as partes para poder entender como realmente o produto ou serviço funciona. Nalgumas grandes empresas a documentação não é toda feita, então faz com que existam algumas lacunas, por isso temos sempre de ir atrás das respostas. Depois, planear como nós vamos testar, onde vamos testar, quais ferramentas nós vamos testar e qual é a melhor forma desse planeamento ser otimizado.
E todos os dias tens bugs para resolver?
Todos os dias (risos). Atualmente eu trabalho com apenas um produto, mas que serve três clientes diferentes, então o produto é customizado de forma diferente para cada cliente, porque ele pede da forma que ele precisa. Então pode acontecer que algum detalhe ou ferramenta seja necessário para um cliente, mas não para outro. Há essas diferenças e temos um deadline diferente para cada cliente também. Uns trabalham com a metodologia Scrum, então fazemos entregas de duas em duas semanas ou a cada semana.
Sempre que vêm novos requisitos nós fazemos a análise do que é preciso, percebermos se é um requisito que já existe, se é uma melhoria ou se é de facto um novo requisito, ou seja, se é uma nova função dentro daquele produto ou serviço para o qual será necessário ter um planeamento dos riscos. Depois fazemos todos os testes de regressão de tudo o que já foi feito porque mesmo que o código seja implementado na versão do novo requisito, pode haver conflitos no código e o bug é algo que se espalha (risos). É por isso que fazemos testes de regressão, para sabermos que tudo o que estava feito se manteve depois desta nova release.
Falamos muitas vezes em bugs, mas o que é mesmo um bug? E o que são testes de regressão?
Testes de regressão é fazer novamente todos os testes anteriores que já fizemos. Já o bug tem várias nomenclaturas e isso vai de acordo com a forma como ele é visto.
Erro é quando alguém erra. O ser humano erra e nós encontramos o erro. Pode ser um erro de escrita, a aplicação ou o serviço são em portugues e há algo em inglês, por exemplo.
Já um defeito é quando algo não está a funcionar bem, da forma que precisava de funcionar. Deveria ter um resultado que não é o que está a ter. Está a ter uma falha ou um erro inesperado ou desconhecido.
Existem diferentes tipos de testes em QA. Podes explicar alguns e em que situações são utilizados?
Testes end-to-end são usados quando mais do que uma aplicação se comunicam entre si e precisamos de testar todo o fluxo. Esta é uma técnica de teste que normalmente é muito utilizada.
Testes de carga são testes usados quando sabemos que vai existir um fluxo muito grande de pessoas a utilizar uma aplicação e se essa aplicação aguenta de facto aquele fluxo grande. Por exemplo, um cliente que tem Black Friday tem de se preparar para que naquela sexta-feira, todos os utilizadores que estão registados naquela plataforma e no banco de dados, possivelmente venham a utilizar a sua aplicação. Então temos de nos preparar para que as falhas e o erro não aconteçam.
Hoje em dia isto é um requisito muito relevante, porque na era da modernidade, da internet e das pessoas que fazem tudo pelo telemóvel, elas procuram o instantâneo para não perder tempo. Então se você encontrar um erro numa ferramenta e conhece outra que faz a mesma coisa, você muda para essa, por isso é muito necessário ter um teste para garantir que as coisas vão correr bem.
Depois há os testes manuais e automáticos. Dentro dos manuais, temos os testes exploratórios que são com base na minha experiência e no meu conhecimento, ou seja, eu sei como aquela aplicação ou serviço se comporta. Normalmente quem faz este tipo de teste não é só o QA. Existem outras pessoas também que podem fazer testes como os Product Owners ou o próprio cliente.
Dentro dos teste manuais existem ainda os testes funcionais que é basicamente termos o resultado da funcionalidade daquela aplicação. O que é que aquela aplicação se propõe a fazer e se está a responder, se os resultados dos testes estão a garantir que a aplicação faz o que deve.
Já os testes automáticos permitem-nos otimizar o nosso tempo. A automatização é utilizada para os testes de regressão. Basicamente é isso. Quem tem mais experiência consegue fazer um teste automatizado muito mais rápido e testar a aplicação.
Normalmente costumamos misturar os dois tipos de testes porque apesar da Inteligência Artificial estar aí para nos ajudar a otimizar o nosso tempo, não há nada como o olho do ser humano para validar tudo.
Como é que decidiste seguir esta carreira? Houve algum momento específico que te fez escolher o Quality Assurance?
O perfil do QA tem de ser um crítico e um pessimista no bom sentido da palavra e o meu perfil é um pouco assim. Estou sempre preparada para o pior (risos). Ok isso pode ser um pouco misturado com ansiedade, mas tudo acaba por girar em torno do que já falei.
Temos de ter tudo planeado e estar preparados para o risco que aquilo pode causar para o cliente. Por exemplo, eu hoje trabalho com telecomunicações, com serviços que são entregues ao cliente como internet, chamadas, ligações, televisão, etc. Hoje em dia está toda a gente em teletrabalho, por isso se o cliente fica sem internet em casa, como é que ela trabalha? Então esse é um risco. Ela possivelmente vai abrir uma reclamação com a operadora e isso acarreta vários outros transtornos. Ela pode pedir um desconto porque ficou sem internet um dia, possivelmente está a trabalhar e pode perder prazos, datas, contratos, então o problema só aumenta. A gente tem de se precaver e planear os riscos.
Eu antes trabalhava com Marketing Digital que é focado em atender clientes e lidar com o público. O QA também precisa de ter uma boa comunicação porque ele precisa de falar com toda a gente. Precisa de perceber tudo do que aquele produto ou serviço se propõe a cumprir e eu me identifiquei por eu ter esse perfil, achei que iria combinar.
Basicamente foi o meu marido que me incentivou a entrar para a área. Ele me conhece também há bastante tempo e ele sabe como é o meu comportamento, o que eu gosto e com o que me conseguiria identificar e foi por isso que eu escolhi. Ele é desenvolvedor e eu sou tester, basicamente eu testo o que ele fala. Também tive amigos que já trabalhavam na área e que me incentivaram a fazer essa mudança.
Qual foi o bug ou falha mais complexo que encontraste até agora? Como o resolveste?
Pergunta difícil. Eu trabalho com telecomunicações e o mais difícil é quando nós enviamos um pedido para adicionar uma ativação na casa de um cliente e aquele pedido vai quebrado.
Por exemplo: você Marina contratou um serviço de telefone, internet e tv e eu enviei um pedido de ativação para sua casa, para a sua morada, de tv, internet e telefone, mas o pedido só foi de tv e faltou a internet porque alguma aplicação falhou. A aplicação ou equipamento que deveria se comunicar com a aplicação falhou ou estava fora do ar.
Atualmente nós trabalhamos com testes reais, então são equipamentos reais que estão próximos da casa do cliente a funcionar aos quais enviamos pedidos recorrentes para que tenhamos um resultado o mais próximo da realidade possível. Então o bug mais chato para resolver é esse. E como eu resolvo? Temos que analisar para saber qual foi a resposta do erro, tratar aquela resposta e, se possível, fazer o delete do pedido e enviar novamente.
Trabalhar como QA implica estar em constante colaboração com Developers e outros stakeholders. Como é a comunicação dentro da equipa?
A comunicação tem de ser a mais clara possível e sem ruídos, mesmo. Gosto também de falar pessoalmente. Eu hoje estou em teletrabalho mas gosto de ir ao escritório de vez em quando porque frente a frente nós conhecemos as pessoas e sabemos como elas se comportam, como falar com cada uma e tentar ser o mais respeitoso possível dentro da área de trabalho.
Eu por acaso sou brasileira e para que a comunicação seja mais clara, eu uso as palavras de português de Portugal. Eu consigo adaptar ao sentido do que eu preciso para me comunicar e tenho tido bons resultados (risos). Nunca ninguém reclamou de não ter percebido nada. Às vezes falha só uma palavra ou outra, porque estou no automático.
E a comunicação entre os QAs e os Developers? É difícil comunicar por estarem a chamar a atenção para problemas?
Tem sempre essa briga, essa rixa entre os dois, mas é uma questão de saber falar. Não devemos apontar os defeitos. É dizer “olha de acordo com o que está escrito na documentação…” ou a forma como você questiona. Normalmente quando nós perguntamos é mais bem recebido do que quando nós apontamos. Ter uma rixa é desnecessário.
A automação de testes tem vindo a ganhar destaque. Qual a tua opinião sobre testes manuais vs. automação?
Os dois são muito importantes.
Na minha opinião os testes manuais são muito importantes. As ferramentas de automação e a IA estão aí para otimizarmos o nosso tempo. Principalmente o [tempo] do QA, porque acabam por surgir muitos casos de testes e os automatizados ajudam na produtividade. Mas o QA tem de saber um pouco dos dois, porque o mercado de trabalho está muito aquecido em relação a isso.
Há muita procura de clientes que querem implementar testes automatizados, muitos até já estão implementados há muito tempo. É uma exigência que o mercado tem e se você não souber as suas chances são menores. Não fica para trás porque nada como o olho humano e o pensamento crítico do ser humano que é quem vai usar, isso nunca vai ser suprido por nenhum AI. Mas você tem menos chances no mercado de trabalho se não tiver um conhecimento dos testes automatizados.
Quais as ferramentas ou tecnologias que consideras indispensáveis para um QA Engineer?
O Jira para gestão de casos de testes, testes manuais, e gestão e planeamento dos testes.
O Postman para testes de API backend - é uma ferramenta bem completa que se consegue perceber mesmo com pouca experiência.
Para testes web: Selenium e Cucumber. Estes são os melhores para qualquer pessoa que usa linguagem TDD perceber como aqueles testes foram implementados. São o que eu uso e gosto. Há muita gente que não gosta de trabalhar com o Selenium, preferem outras ferramentas. As outras ferramentas que entraram recentemente no mercado vieram para melhorar cada vez mais, mas algumas mais antigas também funcionam com qualidade.
As novas ferramentas que eu penso que vão conquistar o mercado são o Playwright e Robot Framework. Essas duas estão a crescer cada vez mais no mercado e otimizam ainda mais o nosso tempo.
Como te manténs atualizado sobre novas metodologias e ferramentas em QA?
Tenho de pesquisar. Participo de grupos no Whatsapp, no Telegram e no Linkedin.
Que conselhos darias a alguém que esteja a considerar uma carreira em QA?
Ultimamente tenho feito muito isso. Muita gente vem ter comigo, porque fiz essa mudança de área recentemente.
Primeiro é importante tentar pesquisar. Há muitos conteúdos na internet gratuitos que você pode pesquisar para saber se é mesmo com isto que quer trabalhar.
Segundo, é importante perceber a sua responsabilidade relativamente à área de QA. Como disse, existem muitos riscos que temos que ter em atenção para aquele produto ou serviço e é a sua responsabilidade.
Resumindo, primeiro pesquisa sobre a área, depois pesquisa se gostas de fazer código, se preferes a área de testes manuais ou se consegues trabalhar com código. A máquina é responsiva, ela faz o que você disser, se pedir errado ela vai fazer errado então é algo que, a meu ver, não é um bicho de sete cabeças. Muitas pessoas acham que é só para pessoas muito inteligentes, mas não. Tente, veja primeiro, faça uma pesquisa sobre que tipos de projetos quer trabalhar - banca, retalho, telecom, seguros, etc - porque isso também faz toda a diferença. Muita gente leva a carreira para só aquele tipo de produto específico e quanto mais você se especializa em algo, melhor você fica e mais você é recomendado. Pesquisa também nomes de pessoas que estão no mercado há muito tempo, que são referência e que têm livros. Leia esses livros e faça uma trajetória. Coloque metas curtas para que não se frustre no final.
O que é que gostas mais na tua função? E o que menos te agrada?
Não ter rotina, cada dia é uma experiência e tem uma coisa inesperada que você vai encontrar e isso é muito gratificante para mim. Ter rotina é bom porque você fica organizado e sabe o que vai fazer no dia, mas quando sai do planeado é uma adrenalina muito boa.
O que eu não gosto é quando encontro muitos bugs e não consigo trabalhar ou quando dependo de algo para avançar com o meu trabalho.
Para terminar, qual foi o projeto mais desafiante em que já trabalhaste e porquê?
Por acaso quando eu estava a trabalhar enquanto freelancer eu tinha vários tipos de projetos e clientes diferentes. O mais estranho que eu já testei foi uma página de conteúdo adulto (risos). Foi algo engraçado no qual eu participei. Nessa altura eu trabalhava através de uma plataforma onde você se inscreve e fica disponível para vários tipos de projetos e os clientes podem contratar o serviço de um tester para testar certa funcionalidade. E aí eu me inscrevi e o nome não tinha nada a ver com o conteúdo, então eu não tinha noção do que era. Quando abri a aplicação e vi o que era disse “Whaaat!?” (risos). Foi engraçado.
Se também te vês a evoluir enquanto engenheiro de QA, conhece os nossos projetos nesta área aqui. Ouve mais sobre temas como carreira, produtividade, tecnologia, gestão ou liderança no nosso podcast:
