📑 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.

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.

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]

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.

Este documento detalha os requisitos funcionais e não funcionais para o sistema de backup, com base nas funcionalidades e comportamentos descritos.

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.

Estudo de Caso Real: Solicitação do Cliente Prosoft

Recentemente, a equipe da Prosoft nos procurou com uma solicitação clara para um novo sistema de backups. Em nossa conversa, eles detalharam as seguintes necessidades:

"Precisamos de um sistema de backups que seja capaz de realizar backups de pastas e, muito importante, que envie esses backups diretamente para a nuvem. Queremos a flexibilidade de poder realizar backups tanto de forma manual, quanto agendados para horários específicos.

Quanto à instalação, o sistema deverá ser instalado em todas as máquinas dos nossos usuários que desejarem fazer backups, sejam do sistema Prosoft ou de arquivos pessoais. É crucial que cada máquina possa configurar apenas diretórios locais para o backup; não será permitido configurar diretórios em rede.

O gerenciamento do espaço em nuvem será controlado por faixas de planos. Uma regra fundamental para nós é que, se o espaço em nuvem não for suficiente para armazenar no mínimo dois backups, o sistema deve realizar um upgrade de plano automaticamente.

Além disso, o sistema precisa ter um mecanismo de rotacionamento de arquivos. Ou seja, ao gerar um novo backup de uma determinada pasta e não houver espaço suficiente na nuvem, os backups mais antigos deverão ser deletados automaticamente para liberar espaço para os mais recentes.

Por fim, é imprescindível haver um sistema de notificações por e-mail para o cliente, alertando sobre falhas ou outros avisos importantes."

O Processo de Levantamento com o Cliente Prosoft

Através de reuniões com o time da Prosoft, nos dedicamos a entender suas expectativas em relação ao sistema. Realizamos um levantamento detalhado dos requisitos, os quais foram documentados e apresentados a todos os envolvidos. O objetivo principal dessas apresentações era garantir que o cliente compreendesse plenamente o que planejávamos desenvolver, além de permitir uma discussão aberta para assegurar que nossas propostas estivessem totalmente alinhadas às suas necessidades. Durante essas reuniões, os requisitos foram refinados, e um documento final de aceite foi gerado, pavimentando o caminho para o início da implementação do software.

Requisitos Funcionais (RF)

Os requisitos funcionais descrevem o que o sistema DEVE fazer.

RF.1 Instalação

• RF.1.1 O sistema DEVE ser instalável em todas as máquinas da rede designadas para realizar backup.

RF.2 Configuração de Backup

• RF.2.1 O sistema DEVE permitir ao usuário configurar o backup de qualquer pasta local à sua escolha.

• RF.2.2 O sistema NÃO DEVE permitir a configuração de backup de pastas de rede.

• RF.2.3 O sistema DEVE permitir ao usuário configurar o backup de bancos de dados PostgreSQL.

• RF.2.4 O sistema DEVE permitir ao usuário configurar o backup de bancos de dados SQLServer.

• RF.2.5 O sistema DEVE permitir ao usuário configurar o backup de bancos de dados SQLite.

RF.3 Diretório de Backup

• RF.3.1 O sistema DEVE permitir ao usuário definir o diretório de destino dos backups no servidor.

• RF.3.2 O sistema DEVE utilizar um diretório padrão para backups caso o usuário não defina um.

RF.4 Agendamento de Backup

• RF.4.1 O sistema DEVE permitir ao usuário definir o horário de execução dos backups agendados.

• RF.4.2 O sistema DEVE utilizar um horário padrão para o agendamento de backups caso o usuário não defina um.

• RF.4.3 O sistema DEVE criar um agendamento de backup para cada pasta configurada.

RF.5 Execução de Backup

• RF.5.1 O sistema DEVE realizar backups "completos" das pastas configuradas.

• RF.5.2 O sistema DEVE compactar o arquivo de backup gerado.

• RF.5.3 O sistema DEVE permitir a execução de um backup manual diretamente pela tela principal.

RF.6 Envio para Nuvem

• RF.6.1 O sistema DEVE enviar o backup para a nuvem imediatamente após a conclusão da rotina de backup local.

RF.7 Armazenamento de Backups

• RF.7.1 O sistema DEVE armazenar os backups na nuvem por padrão.

• RF.7.2 O sistema DEVE permitir ao usuário configurar o armazenamento opcional de backups em disco físico.

• RF.7.3 O sistema DEVE excluir os arquivos de backup do disco físico após a confirmação de seu envio para a nuvem.

RF.8 Rotacionamento de Backups na Nuvem

• RF.8.1 O sistema DEVE realizar o rotacionamento de arquivos na nuvem de acordo com as configurações definidas pelo cliente.

• RF.8.2 O sistema DEVE deletar o arquivo de backup mais antigo na nuvem para liberar espaço para um novo backup durante o rotacionamento.

• RF.8.3 O sistema DEVE sugerir opções de rotacionamento otimizadas com base na relação entre o tamanho do backup e o tamanho do plano de armazenamento.

RF.9 Notificações por E-mail

• RF.9.1 O sistema DEVE notificar o cliente por e-mail quando a capacidade do plano de armazenamento não for suficiente para o tamanho do backup.

• RF.9.2 O sistema DEVE notificar o cliente por e-mail em caso de erros de backup.

• RF.9.3 O sistema DEVE notificar o cliente por e-mail em caso de erros de upload.

• RF.9.4 O sistema DEVE notificar o cliente por e-mail em caso de agendamentos de backup perdidos.

RF.10 Upgrade de Planos

• RF.10.1 O sistema DEVE realizar um upgrade automático para a próxima faixa de plano quando não for possível armazenar no mínimo dois arquivos de backup.

RF.11 Gerenciamento de Arquivos

• RF.11.1 O sistema DEVE permitir o download de um backup através da interface de gerenciamento de arquivos.

• RF.11.2 O sistema DEVE permitir a geração de um link de download para um backup através da interface de gerenciamento de arquivos.

• RF.11.3 O sistema DEVE permitir a exclusão de um backup através da interface de gerenciamento de arquivos.

• RF.11.4 O sistema DEVE permitir a restauração de um backup através da interface de gerenciamento de arquivos.

• RF.11.5 O sistema DEVE exibir o nome do arquivo de backup na área de gerenciamento de arquivos.

• RF.11.6 O sistema DEVE exibir o tamanho do arquivo de backup na área de gerenciamento de arquivos.

• RF.11.7 O sistema DEVE exibir a data de upload do arquivo de backup na área de gerenciamento de arquivos.

• RF.11.8 O sistema DEVE exibir o status de armazenamento do arquivo de backup na área de gerenciamento de arquivos.

RF.12 Restauração

• RF.12.1 O sistema DEVE permitir a restauração de um arquivo de backup.

• RF.12.2 O sistema NÃO DEVE permitir a restauração de arquivos de backup que não foram gerados pelo próprio sistema.

• RF.12.3 O sistema DEVE descompactar o arquivo de backup em um diretório especificado durante o processo de restauração.

Requisitos Não Funcionais (RNF)

Os requisitos não funcionais descrevem como o sistema DEVE funcionar, focando em qualidades e restrições.

RNF.1 Usabilidade e Instalação

• RNF.1.1 O sistema DEVE priorizar a instalação no servidor da rede para otimização de recursos.

RNF.2 Desempenho e Eficiência

• RNF.2.1 O sistema DEVE compactar os arquivos de backup gerados para otimização do armazenamento.

RNF.3 Escalabilidade e Capacidade

• RNF.3.1 O sistema DEVE monitorar a capacidade do plano de armazenamento na nuvem para garantir a possibilidade de armazenamento de novos backups.

• RNF.3.2 O sistema DEVE garantir a capacidade de armazenamento de no mínimo dois arquivos de backup antes de acionar um upgrade de plano.

RNF.4 Confiabilidade

• RNF.4.1 O sistema DEVE garantir a notificação de erros (backup, upload, agendamento perdido) para assegurar a confiabilidade do processo.