Entregando um QA assertivo para sua equipe

Como preparar um processo de QA para garantir a entrega consistente de um software.

Por Giovanna Farias, Johnny Herbert e Leticia Burgos.

Antes de começarmos, é importante ressaltar que ao longo deste artigo não iremos falar sobre teste unitário, automação de testes e teste de integração. O foco será em testes relacionados a área de Produto.

O que é QA?

O Quality Assurance, também conhecido por QA, tem o objetivo de assegurar a qualidade de um software para uma equipe ou organização através de testes.

Em Engenharia de Software, o QA se baseia na análise de requisitos, fluxo principal, fluxo alternativo e regras de negócio, além da análise de comportamento de interação da UI.

Por que precisamos testar?

1. Com os teste podemos minimizar inconsistência na entrega do software;
2. Melhorar a experiência do usuário, pois a primeira oportunidade que um usuário pode dar ao seu produto também pode ser a última, caso não esteja bem feito na hora de acesso;
3. Investimento efetivo, uma vez que através dos testes é possível identificar os gaps de negócio necessários para a criação de novas estratégias de gestão de produto, de maneira que estejam validadas a partir do comportamento do usuário final.

Como é nosso processo de QA?

Para saber mais sobre nosso framework de gestão, clique aqui.

Processo de desenvolvimento de software utilizado na Mobix Software Studio

O discovery é realizado utilizando a técnica de Design Thinking denominada Double Diamond. No primeiro diamante são realizadas pesquisas com usuários para imergir no problema da pessoa cliente. Ao final do processo, entregamos uma síntese do que foi entendido e definido um ou mais objetivos.

Já no segundo diamante ideias são geradas para resolver os problemas e também é feita a prototipagem das telas, em baixa, média e alta fidelidade.

A fase de implementação começa com a definição e priorização de atividades que precisam ser realizadas, em seguida desenvolvemos e entregamos a funcionalidade da solução que está sendo implementada.

O QA vai estar atuando de forma mais ativa na parte de desenvolvimento e entrega.

É importante ressaltar que antes de uma nova funcionalidade estar disponível para o usuário final, ela passa por um processo de Code Review da equipe de desenvolvimento. Este processo de validação de entrega passa por dois ambientes de testes até a sua entrega definitiva.

O primeiro ambiente é chamado de Development, no qual é apenas acessado pela equipe de Desenvolvimento e QA que atua de forma mais assertiva. Aqui procuramos garantir a qualidade do produto, identificar erros e reportar problemas na entrega. Quando a funcionalidade estiver funcionando como esperado, ela irá para o ambiente de Homologação (ou Staging).

Neste ambiente, que é o segundo ambiente de teste, além da participação de uma pessoa de QA, é comum a presença de clientes realizando testes, é uma forma de verificar como está o andamento da funcionalidade e, também, ver se o que foi proposto está sendo desenvolvido corretamente.

Após a finalização desses testes, alguns usuários finais podem ser escolhidos para também utilizar esta nova funcionalidade antes dela ser disponibilizada para o público em geral. Os usuários finais podem ser escolhidos de acordo com seu engajamento no produto, enviando feedbacks com frequência e promovendo engajamento na entrega da solução

Ao final do processo, é realizada a entrega em Produção onde todos os usuários podem ter acesso às funcionalidades que já passaram por um período de testes.

Quais ferramentas são utilizadas nesse processo?

Na Mobix utilizamos três principais ferramentas para dar suporte ao funcionamento do processo de testes. São elas:

1. Jira

Utilizada para a gestão da empresa, através do Jira que é possível identificar quais atividades estão sendo realizadas numa Sprint, e avaliar quais os status referentes a cada atividade. Assim, conseguimos acompanhar as entregas e conseguimos iniciar o processo de testes.

Board kanban de deploy do Jira

Existe um kanban que é dividido em 5 colunas, onde cada coluna representa um status de desenvolvimento:

• To Do
• In Progress
• Block
• Commit
• PR

Após a aprovação do Pull Request (PR), a atividade é automaticamente enviada para o quadro de QA, onde a equipe poderá acompanhar as funcionalidades disponíveis e poderem realizar seus testes. O quadro de Deploy se estrutura da seguinte forma:

• QA
• Ready for Staging (Homologação)
• Staging (Homologação)
• Ready for Production
• Production

2. Productboard

O Productboard é uma ferramenta robusta para acompanhamento e gestão de produtos, porém a equipe de QA utiliza para acompanhar o andamento dos testes em cada estória.

A plataforma funciona por uma divisão de linhas e colunas, nas quais as linhas contém os épicos e estórias do produto e as colunas possuem diversos tipos de dados para acompanhamento. Um desses tipos é a coluna de status para a equipe de QA acompanhar o andamento dos testes em cada ambiente de desenvolvimento.

Na coluna de cada ambiente de desenvolvimento, existe uma integração com o Jira, que de acordo com o andamento da atividade, o status dela é automaticamente atualizado no Productboard. Ou seja, quando uma atividade é entregue pela equipe de desenvolvimento o status é atualizado e a equipe de Produto pode deliberar que uma determinada estória está disponível para teste.

Board de funcionalidades do Productboard e seus respectivos ambientes

Existem três colunas de ambientes:

• QA Dev
• QA Staging
• QA Production

Dentro de cada coluna é possível existir 7 status:

• Not Ready
• To Do
• In progress
• Small issues
• With bug
• Blocked
• Completed

“Small issues” indica impeditivos que não impactam no fluxo da funcionalidade, “With bug” indica problemas maiores que impedem que a pessoa finalize o fluxo, e quando a funcionalidade não consegue ser testada dizemos que está “Blocked”.

3. Notion

Serve para acompanhar o documento de requisitos de cada funcionalidade do produto. Ele é dividido em épicos e estórias, na qual cada estória possui dois tópicos: Backend e Design. Estes tópicos são utilizados para que a perspectiva da funcionalidade possa ser vista por todos os membros da equipe de desenvolvimento.

Backend

Nesse tópico são listados pontos importantes para os desenvolvedores de backend, como endpoints que precisam ser integrados e informações sobre a modelagem de banco de dados, além de diagramas que auxiliem na implementação dos fluxos (normalmente utilizamos Diagramas de Sequência).

Design

Informa detalhadamente as regras de negócio de cada funcionalidade e é separado em alguns tópicos.

1. Links do Figma: Nessa parte, é adicionado links para o fluxo da estória e para o protótipo navegável das telas.
2. Critérios de aceitação: Informa a equipe de desenvolvimento e de QA como chegar na funcionalidade pela navegação no software (entrada), o que a funcionalidade faz (comportamento) e como sair dela (saída).
3. Casos de uso: É nesse tópico que vai ser explicado as regras de negócio da funcionalidade.

Exemplo: O campo de telefone será obrigatório no momento do cadastro.

Checklist de realização de QA

1º passo: Ler o Changelog

Documentação que a equipe de desenvolvimento viabiliza elencando todas as atividades que foram finalizadas na versão, separando-as em três seções: Ajustes, Melhorias e Funcionalidades. Nas atividades listadas é adicionado um link que redireciona para o Jira, no qual irá conter mais detalhes sobre a mesma.

2º passo: Mapeamento de bugs

Mapeamento dos bugs que costumam surgir durante a realização de testes. O template de mapeamento encontra-se abaixo:

Título:

1. Resumo do bug: Colocar de forma breve o que é o bug.

Corpo:

1. Ambiente: Deve ser informado em qual ambiente o bug foi encontrado (Develop, Staging, Production);
2. Dispositivo: Desktop ou Mobile (Android ou iOS);
3. Navegador: Chrome, Edge, Safari etc;
4. Conta de usuário: Login e senha da conta utilizada para realizar os testes, caso a divulgação dessas informações forem permitidas;
5. Passos para reproduzir: O fluxo de páginas que foi feito até o bug ocorrer;
6. Comportamento real: O que está acontecendo no momento para ser considerado com bug;
7. Comportamento esperado: Como deveria ser o comportamento correto;
8. Imagem ou vídeo: Registro visual do bug para facilitar o entendimento.

3º passo: Clientes mapeando bugs

Algumas vezes é possível o cliente ou usuários finais encontrarem bugs e mapearem o que aconteceu. Eles não fornecerão todas as informações que são adicionadas no mapeamento de bugs, por isso a equipe de QA atua na coleta dessas informações.

Após a coleta, a equipe de QA tenta reproduzir o bug e fazer o mapeamento correto de bugs para a equipe de desenvolvimento corrigir.

Conclusão

Este processo permite que a equipe de QA faça um trabalho específico e detalhista nas funcionalidades da solução, já que os testes são muito baseados na documentação de requisitos.

Além disso, a pessoa responsável pela gestão de produtos consegue identificar de forma macro como está o andamento dos testes e diminuir os riscos para o lançamento de uma nova versão.

Outro fator importante é que o cliente também tem a liberdade de acompanhar esse processo através das ferramentas, gerando confiança na equipe e senso de pertencimento.