📑 Padrões de QA

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.

Utilize o texto padrão 'Descrição dos projetos Cirrus'
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:

Ao criar uma tarefa para um novo recurso, é essencial que a descrição seja clara e  detalhada. Isso garante que todo o time compreenda a solicitação e possa desenvolvê-la e testá-la de forma eficaz.

Sua tarefa deve explicar com clareza a solicitação do novo recurso, incluindo os seguintes pontos:

• Descrição do Novo Recurso: O que é este recurso? Qual é a sua funcionalidade principal?

• Onde Deve Ser Feito: Em qual sistema ou componente o recurso será implementado?

• Como Deve Funcionar: Detalhes sobre o comportamento esperado e as interações.

• Por que este Recurso é Importante: A justificativa ou o valor que ele trará para o cliente ou para o negócio.

• Regras de Negócio: Todas as regras específicas que governarão o funcionamento do recurso.

• Observações: Quaisquer informações adicionais relevantes.

• Mockups: Representações visuais (se houver) de como o recurso deve parecer ou funcionar.

O que é Levantamento de Requisitos?

O levantamento de requisitos é a fase inicial e crucial no ciclo de vida do desenvolvimento de software, onde o objetivo principal é identificar, coletar e documentar as necessidades e expectativas das partes interessadas em relação a um novo produto ou funcionalidade. É o processo de entender o que o cliente realmente precisa que o sistema faça, e não apenas o que ele diz que quer.

Como fazer um bom levantamento de requisitos:

• Comunicação Efetiva: Converse ativamente com os clientes e usuários. Use entrevistas, workshops, sessões de brainstorming e prototipagem.

• Documentação Clara: Registre todas as informações de forma concisa e padronizada. Utilize templates, como a separação entre requisitos funcionais e não funcionais, para garantir que nada seja esquecido e que todos compreendam as especificações.

• Validação Constante: Apresente os requisitos coletados de volta ao cliente para validação. Isso ajuda a corrigir mal-entendidos precocemente e assegura que o que está sendo construído realmente atenda às expectativas.

• Priorização: Trabalhe com o cliente para priorizar os requisitos, entendendo quais são essenciais para a primeira entrega e quais podem vir em fases futuras.

O uso de um padrão claro no levantamento, como a separação entre requisitos funcionais e não funcionais, é crucial para garantir que todas as necessidades sejam compreendidas, evitando ambiguidades e facilitando o desenvolvimento e os testes.

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?
  
• 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.
• Atualiza casos de teste? Sempre que necessário, na criação ou edição de uma funcionalidade importante do sistema, se faz necessário criar ou atualizar os casos de teste dos produtos. 
  Karoo chat One: https://drive.google.com/drive/folders/1-kA2Uo0sllqSAC9wKOed9XpstYGFdmv1
  Karoo BOT: https://drive.google.com/drive/folders/1mTUznEr-f-Dy_sHVbSEiEQMfWn5pFvJ7
  Omnichannel: https://drive.google.com/drive/folders/16g1mRERv09prncIinPVEu7N88mTd4NaB
• 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.

 [  ] Verificar pré-requisito da tarefa
 [  ] Utilizar ferramentas da IA para montar os casos de teste* e traçar quais técnicas de teste serão aplicadas
 [  ] Realizar os testes programados
 *Se necessário voltar a tarefa para o dev, faça o parecer quanto antes, e o sinalize também no Google chat no privado.
   Dê o máximo de detalhes possíveis no seu parecer da tarefa, explicando ao dev o passo a passo que deu problemas.
 [  ] Atualizar os casos de teste nas planilhas da qualidade
 [  ] Atualizar a documentação técnica do produto no KB
 [  ] Verificar se necessário atualizar alguma documentação do produto no Ajuda (futuramente será feito pela UCA)
 [  ] Já aprovada a tarefa, conclua no Jira com o texto padrão "Parecer tarefa de teste Cirrus", após já terem sido feitos os passos anteriores.