Ir para o conteúdo principal

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

 

Abertura de tarefasTarefas 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.

Sua atenção a esses detalhes é muito valiosa para garantirmos a qualidade dos nossos produtos e a satisfação dos nossos clientes!

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:

Objetivo do teste:  (Explicar em poucas palavras qual é o objetivo à ser alcançado nesse teste)

Metodologia: (Como vai ser testado? Uma breve explicação de como vai ser feito o teste)

Cenários : (Casos de teste que foram pensados para validar o teste)

Resultados obtivos: (Quais foram os resultados dos testes feitos?)

Observações: (Se houver alguma informaçẽo adicional que julgue importante, inclua aqui)

Exemplo:

Objetivo: Validar o comportamento do sistema omnichannel, especificamente se um channelId inexistente no MongoDB Karoo retorna o status 404 Not Found conforme o esperado.

Contexto e Metodologia: Realizamos testes abrangentes em todo o fluxo omnichannel, cobrindo desde a criação de números em canais até o início de sessões (proativas e reativas) e o envio de diversos tipos de mensagens (texto, áudio, imagens e PDFs).

- Adicionalmente, foram conduzidos testes utilizando dados coletados do monitor-omc. O endpoint utilizado para esses testes foi http://review-lvct-24893-gony9d-gateway-karoo-chat.alterdatasoftware.com.br/atendimento/omnichannel/v2/webhook

E o payload da requisição

JSON{ "platformConfigId": "661d46adc735bdd70fa3309b", "channelId": "680910bafc2a5239cfcabeccb", "type": "MESSAGE_UPDATE", "payload": { "message": { "from": "5521982298844", "to": "5521973464872", "providerId": "web5521973464872", "messageId": "68388ec2f5d58878bc87f7de", "status": "DELIVERED", "sessionId": "6838400bf5d58878bc87f156" } } } 

Resultados:

* Ao enviar um channelId válido, o sistema retornou o status 200 OK.
* Ao enviar um channelId inválido, o sistema retornou o status 400 Bad Request com a seguinte mensagem- "OmnichannelConfig não foi encontrado". PlatformConfigID= 661d46adc735bdd70fa3309b, ChannelID= 680910bafc2a5239cfcabeccb"

Ambos os resultados estão em conformidade com o comportamento esperado para a tarefa.

Conclusão: Os testes confirmam a eficácia da implementação para o tratamento de channelIds inexistentes. O sistema agora lida corretamente com essa condição, retornando o status e a mensagem de erro esperados. Esta versão está aprovada para implantação.