5 dicas para iniciar como quality assurance engineer

Publicado por Thiago Medeiros no dia qa

image alt text

Aqui na Resultados Digitais, desenvolvemos um produto que deve satisfazer todos os tipos de clientes, inclusive os mais exigentes. Para isto, na área de desenvolvimento do produto, temos uma equipe de desenvolvedores trabalhando ativamente e bem atentos à demanda de produzir algo cada vez melhor. Para assegurar-se da qualidade de cada entrega, temos dentro da RD, a horizontal de Quality Assurance, onde nós, os QA Engineers, realizamos todos os processos e atividades necessárias para garantir que todo o trabalho realizado chegue nas mãos do cliente com todos os requisitos plenamente atendidos.

Mas o que fazemos? As tarefas diárias incluem melhorar os processos dentro dos times ágeis, participar ativamente do flow de entrega das features desde o momento de sua concepção, dando feedbacks ativos, até seu deploy em produção. Especificamos também novas features em linguagem orientada à comportamento seguindo a linha do ATDD (Acceptance Test Driven Development). E claro, desenvolvemos testes de aceitação em frameworks Ruby, como o RSpec, o Capybara, o Poltergeist, o FactoryGirl, o VCR e o SitePrism. Além disso, como Agile Testers, também realizamos testes exploratórios e engajamos todo o time com o mindset de qualidade.

Se você se identificou com o trabalho que estamos fazendo, elaborei 5 dicas para que você obtenha sucesso quando começar a atuar como QA Engineer seja dentro ou fora da RD.

1. Linguagem Gherkin e BDD(Behavior Driven Development):

Apesar de termos mais de 13 mil testes no build do RD Station, isso não livra nenhum QA de aplicar testes manuais, desde exploratórios, até de aceitação. Após realizar o mapeamento dos principais cenários da feature que você esteja focado, devem ser elencados e descritos os cenários de teste a serem realizados pelo QA.

Para o desenvolvimento dos cenários, é ideal que você conheça e utilize a linguagem Gherkin, que além de ser uma prática bastante utilizada pela comunidade de Quality Assurance, é um padrão já utilizado pela RD. Este padrão torna a leitura e entendimento dos cenários mais simples e prático. Além disso, a linguagem permite que desenvolvedores, QAs, UX Designers e Product Managers falem a mesma língua e consigam se comunicar sobre o comportamento que o software precisa ter.

Aliado a linguagem Gherkin, temos o BDD, que serve como metodologia para a criação e descrição dos cenários de teste. Como utilizamos o desenvolvimento ágil, a utilização do BDD é uma prática bem utilizada pela RD, tendo em vista que trata-se de mais uma prática de desenvolvimento ágil. Através do padrão apresentado no BDD, onde temos os cenários descritos basicamente por pré condições, passos executados e pós condições, é possível deixar mais claro e compreensível ao ponto de auxiliar o programador no desenvolvimento e também para a posterior execução dos casos de teste.

image alt text

Fonte: BDD In Action, pag. 146

2. Mapear os principais e mais críticos cenários da aplicação

Concentre-se em mapear os principais e mais críticos cenários da funcionalidade que você esteja focando. Elenque os fluxos principais, descreva os cenários de teste utilizando BDD, tenha os comportamentos descritos detalhadamente e procure abranger o maior número de cenários possível. A partir disso realize testes precisos e tente encontrar bugs relevantes e que impliquem no funcionamento esperado da aplicação.

Melhorias são bem vindas, mas não se atenha apenas a elas, afinal o foco é encontrar problemas que impeçam o usuário de realizar a ação que ele deseja e principalmente, que ao realizar, ele tenha o resultado que espera, de forma clara e concisa.

3. Testes automatizados:

Aqui na RD possuímos atualmente mais de 13 mil testes automatizados rodando diariamente nas builds. É essencial que você saiba realizar uma automação dos cenários de teste que forem elencados para tal, o que entra em paralelo com a dica citada anteriormente sobre conseguir mapear os principais cenários da aplicação.

Os testes que desenvolvemos aqui são todos utilizando a linguagem de desenvolvimento utilizada pela RD, o Ruby. Junto com a linguagem utilizamos algumas ferramentas específicas e de auxílio ao desenvolvimento de testes automatizados como: RSpec para cenários de teste em geral, Capybara para testes de aceitação, sendo que também aplicamos o conceito de PageObject com o SitePrism, preferimos o FactoryGirl para especificar exemplos dos modelos e utilizamos VCR para cachear requisições e deixar nossos testes de API’s mais rápidos. Para a estruturação dos testes de aceitação, o conceito de PageObject é um bom padrão para ser utilizado, tendo em vista que a sua criação e manutenção tende a ser mais fácil.

Sendo assim, é ideal que você possua tal conhecimento e saiba aplicá-lo com precisão. Como recomendação de leitura, sugiro você ler o post Ruby e RSpec: melhorando a legibilidade de seus testes para ficar por dentro das melhores práticas de teste automatizados.

4. Testes de aceitação

Testes de aceitação são os testes que definem o mínimo entregável em alto nível da aplicação. Isso significa que o sistema cumpre o seu objetivo, mesmo que observando “a caixa preta” apenas de fora, navegando nas telas e componentes e vendo a aplicação responder conforme o esperado. Tenha esse conceito na ponta da língua, testes de aceitação necessitam ser uma prática normal e cotidiana em seus testes, assim como a sua elaboração e execução com precisão e eficácia. Realizando um mapeamento eficaz dos cenários que serão efetuados os testes, também é possível elencar os principais cenários que são candidatos a serem automatizados e incluídos na suíte de testes do build. Caso este conceito e suas aplicações não sejam algo natural para você, vou sugerir aqui alguns materiais que podem te ajudar a aprimorar seus conhecimentos nessa técnica de teste:

5. Report de Issues

Depois de realizar todo o estudo da(s) feature(s), executá-las e ter um bom entendimento, você deve minuciosamente procurar defeitos, comportamentos inesperados e melhorias para criar um report do que você encontrar. Capriche no report destes itens, além de ser uma rotina para os QA’s da RD, isso deve ser feito de uma forma cada vez melhor, afinal, o report de um bug bem feito contribui bastante para um Pull Request preciso e sem novos erros.

Como um QA atento e detalhista, seu report pode vir a abranger desde pequenos erros e possíveis melhorias, e principalmente erros críticos, que afetam diretamente o sucesso do cliente na utilização da ferramenta. Preocupe-se em deixar claro o cenário realizado para atingir o erro encontrado, utilize a linguagens características de metodologias ágeis, que facilitam e padronizam este tipo de processo, colete evidências claras e que melhorem ainda mais o entendimento do que foi encontrado por você. Classificações fazem parte do processo ágil e são muito bem vindas, elas garantem uma melhor e mais fácil priorização nas próximas etapas do processo.

Por fim, a organização de todos estes fatores é de extremo valor para a construção de um report conciso, preciso e que tragam valor para a função do QA.

Conclusão

É exatamente assim que nós QA Engineers trabalhamos aqui na Resultados Digitais. Se tiver interesse em começar a trilhar este caminho conosco não deixe de participar do nosso processo seletivo. Estamos sempre em busca de profissionais apaixonados por engenharia e excelência!

Thiago Medeiros

Thiago Medeiros

Quality Assurance Engineer

Comentários