A vida do QA no Moip

Quem somos, o que fazemos e como fazemos!

Mariana Santana

Published in

Wirecard Brasil

5 min readApr 4, 2017

Olá! Eu sou a Mariana e trabalho no Moip há um ano como QA.

Quando cheguei aqui ainda não havia uma equipe de QA. Os testes eram divididos entre os desenvolvedores e os Product Owners.

Com o crescimento das equipes e das aplicações desenvolvidas a demanda de testes no Moip aumentou. Neste último ano nosso desafio foi começar esse time do zero e fazer com que as equipes de desenvolvimento entendam o papel do time de QA e consigam trabalhar juntos.

Qual é o nosso papel?

Chamamos de QA um perfil que pode ser definido como uma mistura de três funções:

Programador: Porque precisamos criar scripts de testes automatizados.
Product Owner: Porque precisamos entender o que o sistema faz e quais suas regras de negócio.
Tester: Porque precisamos ser apaixonados por qualidade de software. :)

Cada QA é responsável pelos testes de pelo menos um produto. Não temos uma equipe apartada de testes, tentamos manter cada QA o mais próximo o possível de seu produto e do time que o desenvolve. Nos reunimos apenas para ajudar uns aos outros e definir os padrões de testes.

Como é a nossa Rotina?

Hoje contamos com dois ambientes para testes:

Homolog: Usado apenas internamente pelos desenvolvedores e QAs para testes.
Sandbox: Usado pelos QAs e pelos clientes para testes de integração.

Nossas atividades são executadas de acordo com o ciclo de desenvolvimento do produto:

Sprint Planning

Participamos do Sprint Planning e tentamos antecipar problemas e/ou riscos com base nas User Stories apresentadas.
Começamos a elaborar os cenários de testes.
Fazemos Pair Testing com outros testers ou desenvolvedores.

2. Desenvolvimento/Codificação

Começamos a elaborar os testes de sistema baseados nas histórias, dando preferência à automação.
Executamos os testes de regressão diariamente para verificar se está tudo ok.
Participamos do daily meeting e informamos o status das atividades.

3. Após o Deploy em Homolog

Desenvolvemos e executamos casos de testes para assegurar que as novas features estão funcionando corretamente, e que não afetam negativamente outras já implementadas, sempre priorizando a automação.
Caso necessário, relatamos os bugs encontrados no Jira.

4. Após o Deploy em Sandbox

Encerramos os bugs encontrados em Homolog.
Executamos os testes elaborados na fase anterior para certificar que eles estão funcionando também em Sandbox.
Liberamos a task para ser implementada em produção.

5. E depois?

Consultamos o backlog do JIRA e encerramos os bugs corrigidos.
Elaboramos novos testes para funcionalidades que ainda não foram testadas.
Atualizamos os testes de regressão caso seja necessário.

Quais tipos de testes fazemos?

Testes feitos pelos desenvolvedor

Q1 e Q2: Testes unitários, testes de componentes, testes de integração, protótipos e simuladores
Testes unitários ajudam o desenvolvedor a entender exatamente o que o código faz. Ajudam a focar na história que será entregue e dão uma pequena amostra de que ela vai funcionar. O QA pode ajudar na elaboração dos cenários fazendo um Pair Testing com o desenvolvedor.

2. Testes feitos pelo QA

Q3 e Q4: Testes funcionais, exploratórios, usabilidade, aceitação, carga, performance, segurança etc.
Os testes unitários ajudam a verificar se o código está livre de bugs mas nem sempre podem avaliar se fazem aquilo que o cliente solicitou.
Os testes feitos por QA focam nas expectativas do cliente. Tentamos simular o que um usuário real faria no sistema.

Como mantemos a qualidade no time de QA?

Tentamos seguir algumas regras para ter um aproveitamento melhor do nosso time:

O QA faz parte do desenvolvimento do projeto. Ele pode e deve estar presente do início ao fim (da revisão e validação das User Stories até a implantação no ambiente de produção). Um QA que participa ativamente do projeto pode ajudar a antecipar bugs antes do desenvolvimento do software.
O trabalho do QA não pode ser mensurado pela quantidade de bugs abertos. Avaliar a produtividade pela quantidade de bugs abertos pode gerar um grande número de bugs irrelevantes.
O QA não pode ser deixado de lado o projeto todo e ser solicitado apenas no final quando todo o projeto for implantado. Essa situação é muito semelhante à metodologia Waterfall, onde o QA fica ocioso durante todo o processo e recebe as tasks para testes no último dia da Sprint.
O Pair Testing deve ser incentivado pois ajuda a compartilhar conhecimento com outros QAs e/ou Devs e também a criar novos cenários de testes a partir de um novo ponto de vista.
O QA é responsável por parte dos testes mas a qualidade de software é responsabilidade de todo o time.

Que ferramentas usamos?

Por que usamos o Gauge?

O Gauge é uma ferramenta de testes pouco conhecida, então acho interessante frisar o motivo de utilizarmos ela:

Principal: Não te deixa preso no “given-when-then” — queremos elaborar as especificações de testes em um formato livre, de forma que os cenários de testes possam ser escritos em uma linguagem de negócios.
Suporte a várias linguagens (Java, Ruby, C#, etc.).
Open Source. :)
Suporte a algumas IDEs (IntelliJ, Visual Studio e Eclipse).
Sintaxe simples de entender.

Hoje todos os nossos testes podem ser executados através do Docker e qualquer pessoa tem acesso ao projeto facilmente. Testes regressivos que antes eram solicitados frequentemente aos QAs podem ser executados diretamente pelos próprios desenvolvedores.

Além de hospedar nosso projetos de testes no Github também utilizamos sua Wiki para compartilhar nossos tutoriais e processos de trabalho do time de QA.

No Jira temos acesso às User Stories de cada produto, acompanhamos as tasks que estão em desenvolvimento e abrimos os bugs.

Conclusão

Ainda temos muito trabalho para fazer no nosso time de QA, no futuro queremos ficar cada vez mais próximos do desenvolvimento, seja ajudando a elaborar os testes unitários ou até desenvolvendo nossas próprias aplicações para auxiliar na execução e reporte dos bugs. Também queremos ficar próximos dos clientes e entender suas necessidades e dificuldades.

Quer contar como funciona o time de QA na sua empresa? Depoimentos, críticas e sugestões são bem-vindos! ;)