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

 

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:

Objetivo:1. Objetivo do TesteValidar

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 omnichannel,quando especificamentea senotificação umde channelId inexistentebloqueio no MongoDBenvio Karooocorria retornae quando o statususuário 404tentava Notreenviar Foundos 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.esperado nos cenários mencionados.

Metodologia:5. Conclusão: RealizamosA testestarefa abrangentesé emencerrada, todoconsiderando oque fluxoas omnichannel, cobrindo desde a criaçãonotificações de números em canais até o iníciolimite 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 Obtidos:

* 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 resultadosarquivos 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 lidafuncionando corretamente comapós essaos condição, retornando o statusajustes e a mensagem de erro esperados. Esta versão está aprovada para implantação.validações.