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:

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.

Abertura de Tarefa de Novo Recurso

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.

Exemplo de Tarefa de Novo Recurso:

Solicitante: Patricia.dsn.cir

Assunto: Criar endpoint para que os sistemas consigam confirmar download

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

Para que os sistemas realizem todo o processo de atualização de forma independente do Updater, é necessário criar um endpoint simplificado para a confirmação de downloads.

O endpoint existente (Post /api/confirmar_download) atualmente requer parâmetros que os sistemas não possuem (como o cliente_id), tendo acesso apenas ao crm.

Endpoint Atual:

POST /api/confirmar_download
{
  "computador": "string",
  "usuario": "string",
  "cliente_id": "string",
  "versao_id": 0
}

Regras de Negócio:

  • O novo endpoint deverá confirmar o download utilizando o código CRM e o ID da versão.

  • A confirmação de download deverá atualizar a última versão baixada nos relatórios do Updatecenter (Timeline, Detalhamento de Cliente e Alcance da Versão).

Observações:

O endpoint atual está disponível em: https://swagger-ui-updatecenter-qa.apps.production.clusters.alterdatasoftware.com.br/?urls.primaryName=Vers%C3%A3o#/Download/post_api_confirmar_download

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

Mockup: Não aplicável

Autorizado por: [Nome da pessoa que autorizou]