Este conteúdo foi inicialmente publicado na Newsletter da Talking About Testing (e adaptado para o blog TAT).
Em diversas das empresas pelas quais passei enquanto vivendo e trabalhando na Europa, tive que realizar exercícios e entrevistas técnicas.
Saber como resolver tais exercícios pode te diferenciar de outros(as) candidatos(as) na hora de conseguir a tão desejada vaga.
Neste post, dou algumas dicas para você se destacar nesta parte do processo seletivo para vagas de QA.
Seguem alguns tipos de exercícios técnicos os quais tive já que realizar.
– Adição de um novo teste automatizado à uma suíte de testes pré-existente
– Fazer o setup de um ambiente local de desenvolvimento e de um projeto de testes automatizados
– Análise de requisitos para a criação de um plano e casos de testes
– Criação de testes automatizados de API e front-end
– Resolução de algorítimos usando TDD (test-driven development)
– Revisão de código
Para cada tipo de exercício, diferentes abordagens podem ser usadas.
Porém, para todos os casos citados acima, me preocupo em entender o problema antes de resolvê-lo. Este é o primeiro passo. E se algo não está claro, procuro esclarecer qualquer dúvida antes de seguir adiante.
Depois, tendo clareza do problema que preciso resolver, 1) quando tenho que criar um projeto novo (para testes de API e/ou front-end), ou 2) extender um projeto existente (seja este um projeto real ou um projeto exemplo), me preocupo em:
– Resolver o problema da forma mais simples antes de otimizar a solução
– Criar commits explicativos, os quais irão ajudar os(as) revisores(as) do meu código
– Deixar claro na descrição do pull request o seu propósito e as decisões de design tomadas
– Garantir que todos os testes estão passando
– Refatorar minha solução para torná-la mais fácil de compreender
– Documentar o mínimo necessário, tais como: o propósito do projeto, pré-requisitos, passos para instalação das dependências e como rodar os testes automatizados (veja um exemplo).
3) Quando se trata da criação de um plano de testes:
– Procuro ser objetivo e usar uma abordagem leve (tal como um plano de testes em formato Markdown, no GitHub mesmo)
– Encontrar inconsistências e apontá-las (ex.: documentação do back-end contradizendo a documentação do front-end)
– Executar os testes e apontar os respectivos resultados (passou ou falhou), com o máximo de evidências úteis
– Quando encontro um bug e tenho acesso ao código fonte, procuro entendê-lo e se possível até mesmo resolvê-lo
4) Quando tenho que resolver algoritmos, mesmo que não solicitem o uso da técnica de desenvolvimento guiado por testes (TDD), procuro usá-la, pois esta me ajuda a manter o foco, resolver um problema de cada vez e não escrever mais código do que o necessário.
5) Já quando se trata de revisão de código, procuro por:
– Inconsistências (códigos parecidos usando formatações diferentes, por exemplo)
– Más práticas (testes automatizados usando seletores XPath, sleeps, etc.)
– Excesso de engenharia ou over-engineering (soluções mais complexas que o necessário)
– Duplicação de código
Além disso, também procuro por:
– Boas práticas (separação de responsabilidades, otimização de testes, uso de seletores específicos para testes, tais como data-test-id)
– Qualidade da documentação (passos claros de como instalar e configurar o ambiente, rodar os testes, etc.)
Certamente, há muito mais em exercícios técnicos (especialmente para diferentes empresas e papéis), porém, espero que tais dicas lhe ajudem quando algum exercício similar à estes cruzarem o seu caminho.
Quer aprender sobre automação de testes web? Conheça meus cursos no Udemy.
- Cypress básico
- Cypress intermediário
- Cypress avançado
- Boas práticas em automação de testes com Cypress
- Testes end-to-end com Cypress
- Testes de regressão visual com Cypress e Percy (básico)
👋 Até a próxima e bons testes!
TALKING ABOUT TESTING 