Padrões de QA

A padronização na abertura de tarefas, nos comentários das tarefas de teste e na análise de requisitos é crucial para nós, QAs. Adotar esses padrões garante que a comunicação no time seja clara, minimizando mal-entendidos e acelerando a resolução de problemas. Ao seguir um modelo, facilitamos a colaboração, o rastreamento do trabalho e, consequentemente, elevamos a qualidade e a agilidade das entregas, tornando o processo mais suave para todos.

As tarefas em desenvolvimento de software são categorizadas para organizar o trabalho. Abaixo temos uma breve explicação das principais tarefas que lidamos em um sprint.

🔴 Erro (Bug): Usado para reportar comportamentos inesperados ou falhas no sistema que o impedem de funcionar como deveria.
✨ Melhoria: Aplicado para otimizar ou refinar uma funcionalidade já existente, tornando-a mais eficiente, rápida ou fácil de usar (ex: otimizar um relatório já existente).
🚀 Novo Recurso: Criado para adicionar uma funcionalidade completamente nova ao sistema que antes não existia (ex: criar um novo tipo de relatório do zero).

A principal diferença entre melhoria e novo recurso é que a melhoria aperfeiçoa algo que já existe, enquanto um novo recurso implementa algo totalmente inédito.

Abertura de Tarefa de Erro

No nosso dia a dia, as tarefas de erro (bugs) têm uma prioridade especial sobre melhorias e novos recursos. Isso acontece porque elas impactam diretamente a satisfação dos nossos clientes e ajudam a conter demandas de atendimento.

Para identificar e corrigir esses problemas da forma mais rápida e eficiente possível, é fundamental que a documentação das tarefas de erro siga alguns passos essenciais. Ao reportar ou investigar um bug, lembre-se de incluir:

Ambiente para Simulação: Indique claramente em qual ambiente (produção, staging, review, etc.) o erro foi reproduzido ou pode ser simulado.
Passo a Passo para Simulação: Descreva detalhadamente a sequência de ações necessárias para que o erro ocorra. Quanto mais preciso, mais fácil será a reprodução e a identificação da causa.
Comportamento Esperado vs. Comportamento Real: Explique qual seria o resultado correto do sistema e qual foi o comportamento inesperado que gerou o erro. Isso ajuda a entender a falha.
Log Completo do Erro: Quando disponível, inclua o log completo do erro. Não se limite apenas ao título; o log detalhado é crucial para que nossos desenvolvedores identifiquem a causa raiz do problema e otimizem o tempo de correção.

Exemplo:

Assunto: Reprodução de Áudio em Loop com Mensagens do Bot no Karoo

Descrição do problema e sugestão a ser implementada:

Componente Afetado: Karoo (Interface do Operador - Reprodução de Áudio)

1. Descrição do Problema Ao atender múltiplos clientes no Karoo, se um cliente tiver enviado um áudio durante a fase de atendimento com o bot, e o operador alternar entre as conversas, o Karoo pode se confundir e reproduzir o áudio do primeiro cliente em um loop contínuo, mesmo ao tentar reproduzir o áudio de outro cliente.

2. Passos para Reprodução

Para simular o problema, siga os passos abaixo:

Ambiente de Simulação:

Configuração: Utilizar um Provider ID configurado tanto para o bot quanto para o Karoo. (Exemplo de conta usada no teste: Immobile, com número 21 9xxxx-xxxx).

Cenário:

Cliente 1: Envie uma mensagem para o bot. Após a resposta do bot, envie um áudio e, em seguida, solicite a transferência para o Karoo (operador). Cliente 2: Repita o processo: envie uma mensagem para o bot, após a resposta, envie um áudio e solicite a transferência para o Karoo.

No Karoo (Operador): Reproduza o áudio enviado pelo Cliente 1. Imediatamente, clique na conversa do Cliente 2 para alternar o atendimento. Observe que uma barra superior com o áudio do Cliente 1 sendo reproduzido aparecerá. Aguarde o áudio do Cliente 1 terminar ou paralise e tente reproduzir o áudio do Cliente 2.

Resultado Esperado vs. Resultado Obtido Esperado: Ao tentar reproduzir o áudio do Cliente 2, o áudio do Cliente 2 deveria ser reproduzido. Obtido: O áudio que será reproduzido é, persistentemente, o áudio do Cliente 1 em loop, independentemente da conversa ativa.

Observação: Esta situação não ocorre com áudios enviados após a transferência para o Karoo (ou seja, áudios enviados já na conversa com o operador humano); o problema se manifesta apenas com áudios enviados durante o atendimento do bot.

Existe paliativo para essa solicitação?: Não

Mockup: Não aplicável

Autorizado por:

Texto Padrão nas tarefas de teste

Para garantir uma compreensão clara e eficiente de todo o processo de qualidade, desde o planejamento até a execução dos testes, adotamos um padrão para nossos pareceres.

Este modelo foi pensado para que todos no time, especialmente os novos QAs e nossos desenvolvedores, possam entender facilmente:

O que foi testado: A funcionalidade ou o item em foco.
Como foi testado: A metodologia aplicada.
Em que ambiente: Onde os testes foram executados.
Quais casos de teste foram abordados: Os cenários específicos verificados.
Quais casos de teste falharam: Onde foram encontradas inconsistências ou bugs.

Ao seguir esse padrão, não apenas aprimoramos a comunicação interna, mas também facilitamos a continuidade dos testes por qualquer membro da equipe, garantindo um fluxo de trabalho coeso e uma entrega de qualidade superior.

Modelo:

Objetivo do Teste: Descreva de forma clara e concisa o que se pretende validar ou alcançar com o teste. Qual funcionalidade está em foco e qual é o resultado esperado após a validação?
Metodologia: Detalhe como o teste será executado. Quais etapas, ferramentas ou abordagens serão utilizadas para verificar o objetivo?
Cenários: Liste os casos de teste específicos que foram planejados e executados para cobrir as diferentes situações e caminhos de validação da funcionalidade.
Resultados Obtidos: Apresente os comportamentos observados no sistema durante a execução dos cenários de teste, indicando se os resultados foram conformes (sucesso) ou não conformes (falha) com o esperado.
Observações: Espaço para incluir informações adicionais relevantes, como desvios do plano original, insights sobre o problema, sugestões de melhoria ou qualquer detalhe que julgue importante para a compreensão do parecer.

Exemplo:

1. Objetivo do Teste

Verificar se, após os ajustes implementados, o Karoo está notificando corretamente sobre os limites de quantidade e tamanho de arquivos ao tentar enviar múltiplos arquivos que ultrapassem esses limites.

2. Metodologia

A metodologia consistiu em enviar diversos arquivos com diferentes características de quantidade e tamanho através da interface do operador do Karoo. Foi observado o comportamento do sistema quando a notificação de bloqueio no envio ocorria e quando o usuário tentava reenviar os mesmos arquivos que excediam os limites.

Em todos os casos onde houve notificação sobre limite excedido repeti a operação para garantir que a notificação foi apresentada novamente.

3. Cenários de Teste e Resultados Obtidos

Cenário: Envio de 10 arquivos com tamanho menor que 50 MB.
- Resultado: Envio realizado com sucesso.
Cenário: Envio de 10 arquivos com tamanho maior que 50 MB.
- Resultado: Notificado sobre limite de tamanho excedido.
Cenário: Envio de 11 arquivos com tamanho menor que 50 MB.
- Resultado: Notificado sobre limite de quantidade excedido.
Cenário: Envio de 11 arquivos com tamanho maior que 50 MB.
- Resultado: Notificado sobre limite de quantidade e tamanho excedido.
Cenário: Envio de 01 arquivo com 49.8 MB.
- Resultado: Envio realizado com sucesso.
Cenário: Envio de 01 arquivo com 50.2 MB.
- Resultado: Notificado sobre limite de tamanho excedido.

4. Observação

Durante a fase inicial dos testes, foi verificado que o cenário de "10 arquivos com tamanho maior que 50 MB" estava notificando o limite, mas, ainda permitindo o envio. Uma correção foi solicitada a Charles para endereçar essa questão. Após a correção, os resultados foram conforme o esperado nos cenários mencionados.

5. Conclusão: A tarefa é encerrada, considerando que as notificações de limite de arquivos estão funcionando corretamente após os ajustes e validações.