Os Níveis de Teste Durante o Ciclo de Vida de Desenvolvimento de Software

[Kevin Silva]

No ramo do desenvolvimento de software, os níveis de teste são grupos de atividades de teste que são organizados e gerenciados juntos e que estão relacionados com outras atividades dentro do ciclo de vida de desenvolvimento de software. Eles são categorizados em Teste de componentes (testes de unidade ou teste unitário), Teste de integração, Teste do Sistema e Teste de aceite e são caracterizados pelos seguintes atributos:

• Objetivos específicos
• Base de teste (Produtos de trabalho que podem ser usados)
• Objeto de teste (ou seja, o que está sendo testado)
• Defeitos e falhas típicas
• Abordagens e responsabilidades específicas

 

Teste de Componente

O teste de componente se concentra em componentes que são testáveis separadamente e geralmente são realizados isoladamente do resto do sistema. Dependendo do modelo de ciclo de vida de desenvolvimento de software, pode exigir objetos simulados, virtualização de serviços, estrutura, simuladores e controladores.

Objetivos:

• Reduzir o risco
• Verificar se os comportamentos funcional (ex: correção de cálculos) e não funcional (ex. busca de vazamentos de memória) do componente correspondem ao que foi inicialmente projetado e especificado
• Construir a confiança na qualidade do componente
• Encontrar defeitos no componente
• Evitar que defeitos espalhem para níveis mais altos de teste

Base de teste:

• Projeto detalhado
• Código
• Modelo de dados
• Especificações de componentes

Objetos de teste

• Componentes, unidades ou módulos
• Estruturas de código e dados
• Classes
• Módulos de banco de dados

Defeitos típicos e falhas

Os defeitos geralmente são corrigidos assim que são encontrados e frequentemente sem gerenciamento formal. Entretanto, quando os desenvolvedores relatam tais defeitos, isso fornece informações importantes para análise de causa raiz e melhoria do processo

• Funcionalidade incorreta (ex: não conformidade descrita nas especificações do projeto)
• Problemas no fluxo de dados
• Código e lógica incorretos

Abordagens e responsabilidades específicas

Esse teste geralmente é executado pelo desenvolvedor que escreveu o código, mas obrigatoriamente requer acesso ao código que está sendo testado. O desenvolvimento de componentes pode ser alternado com a localização e a devida correção de defeitos. Geralmente, os desenvolvedores de software escrevem e executam testes depois de codificaram um componente. Entretanto, a escrita dos testes pode anteceder a codificação de um componente, como ocorre no TDD (Test Driven Development)

 

Teste de Integração

O teste de integração se concentra nas interações entre componentes ou sistemas.

• O teste de integração de componentes foca nas interações e interfaces entre componentes integrados. Ele é executado após o teste de componente e geralmente é automatizado e faz parte do processo de integração contínua.
• Por sua vez, o teste de integração do sistema concentra-se nas interações e interfaces entre sistemas, pacotes e micro serviços e pode ser feito após o teste do sistema ou em paralelo com as atividades de teste do sistema. Também pode abranger interações e interfaces fornecidas por entidades externas (ex: serviços da Web).  Nesse caso, a entidade em desenvolvimento não controla as interfaces externas e isso pode gerar vaŕios desafios para testes (ex: garantir que os defeitos de bloqueio de teste no código da organização externa estejam resolvidos, organizar ambientes de teste, etc.)

Objetivos:

• Reduzir o risco
• Verificar se os comportamentos funcionais e não-funcionais das interfaces estão projetados e especificados
• Construir Confiança na qualidade das interfaces
• Encontrar defeitos (nas próprias interfaces, nos componentes ou nos sistemas)
• Evitar que os defeitos se espalhem para os níveis mais altos de testes

Base de teste:

• Software e modelagem do sistema;
• Diagramas de sequência;
• Especificações de interface e protocolo de comunicação;
• Casos de uso;
• Arquitetura no nível de componente ou sistema;
• Fluxos de trabalho;
• Definições de interface externa.

Objetos de teste

• Subsistemas
• Banco de dados
• Infraestrutura
• Interfaces
• APIs
• Micros serviços

Defeitos típico e falhas

• Testes de integração de componentes:
  • Dados incorretos, dados ausentes ou codificação de dados incorreta;
  • Sequenciamento ou temporização incorretos de chamadas de interface;
  • Incompatibilidade de interface;
  • Falhas na comunicação entre componentes;
  • Falha de comunicação não manipulada ou tratada de forma errada entre componentes;
  • Suposições incorretas sobre o significado, as unidades ou limites dos dados que estão sendo
    transmitidos entre os componentes.
• Testes de integração de sistemas:
  • Estruturas de mensagens inconsistentes entre sistemas;
  • Dados incorretos, dados ausentes ou codificação de dados incorreta;
  • Incompatibilidade de interface;
  • Falhas na comunicação entre sistemas;
  • Falha de comunicação não manipulada ou tratada de forma errada entre sistemas;
  • Suposições incorretas sobre o significado, unidades ou limites dos dados que estão sendo
    transmitidos entre sistemas;
  • Falha no cumprimento dos regulamentos de segurança obrigatórios.

Abordagens e responsabilidades específicas:

No teste de integração, o foco deve ser na comunicação entre componentes ou sistemas diferentes e não nas suas funcionalidades individuais (como deveria ter sido coberto durante o teste de componentes). Testes de integração de componentes geralmente são de responsabilidade dos desenvolvedores, enquanto que os de integração de sistemas são atribuídos aos testadores (ex: analistas de qualidade). Quanto maior o escopo da integração, se torna mais difícil isolar os defeitos em um componente/sistema e por essa razão a prática de integração contínua tornou-se muito comum no desenvolvimento de software para a grande maioria das empresas.

Teste de Sistema

Já o teste de sistema se concentra no comportamento e nas capacidades de todo um sistema ou produto, geralmente considerando as execuções das tarefas de ponta a ponta (End-to-End ou E2E) do sistema e os comportamentos não-funcionais exibidos ao executar tais tarefas. Geralmente, esse tipo de teste produz informações que são usadas pelos stakeholders para tomar decisões de liberação e também podem satisfazer requisitos ou padrões legais e regulatórios.

Objetivos:

• Reduzir o risco
• Verificar se os comportamentos funcionais e não-funcionais do sistema estão como projetados e especificados
• Validar se o sistema está completo e funcionará como esperado
• Criar confiança na qualidade do sistema como um todo
• Encontrar defeitos e evitar que eles se espalhem para níveis mais altos de teste ou produção

Base de teste:

• Especificações de requisitos de sistema e software (funcionais e não-funcionais)
• Relatórios de análise de risco
• Casos de uso
• Épicos e histórias de usuários
• Modelos de comportamento do sistema
• Diagramas de estado
• Sistema e manuais do usuário

Objetos de teste:

• Aplicações
• Sistemas de hardware e software
• Sistemas operacionais
• Sistema sob teste (SUT)
• Configuração do sistema e dados de configuração

Defeitos típico e falhas:

• Cálculos incorretos;
• Comportamento funcional ou não funcional do sistema incorreto ou inesperado
• Controle e/ou fluxos de dados dentro do sistema incorretos
• Falha na execução correta e completa de tarefas funcionais de ponta a ponta
• Falha do sistema em funcionar adequadamente no(s) ambiente(s) de produção
• Falha do sistema para funcionar conforme descrito nos manuais do sistema e do usuário

Abordagens e responsabilidades específicas:

O teste de sistema deve focar no comportamento geral de ponta a ponta do sistema, seja esse comportamento funcional ou não. Um exemplo de teste de sistema envolve o uso de uma tabela de decisão para verificar se o comportamento funcional está de acordo com o que foi estabelecido nas regras de negócio. Esse e outros tipos de testes de sistema podem ser realizados por testadores independentes, que dessa forma conseguiriam ajudar no refinamento da história dos usuário e de requisitos de negócios que forem declarados incorretamente. Existem também ferramentas como Cypress e o Playwright, que permitem a criação de testes ponta a ponta automatizados tanto para o front-end quanto para o back-end de um sistema.

 

Teste de Aceite

O teste de aceite, assim como o teste de sistema, geralmente foca no comportamento e capacidade de todo um sistema ou produto. Ele pode produzir informações para avaliar a situação do sistema para implantação e uso pelo usuário final (no caso, o cliente). Os defeitos até podem ser encontrados durante o teste de aceite, mas esse nem sempre é o objetivo do teste, e encontrar uma quantidade significativa de defeitos durante o teste de aceite pode representar um grande risco de projeto. Geralmente, deseja-se comprovar, por meio do teste de aceite, se o sistema satisfaz os requisitos, os padrões legais e os padrões regulatórios.

Objetivos:

• Estabelecer confiança na qualidade do sistema como um todo
• Validar que o sistema está completo e funcionará como esperado
• Verificar se os comportamentos funcionais e não-funcionais do sistema são os especificados.

Teste de Aceite do usuário (UAT)

O UAT é focado em validar a adequação do uso do sistema pelos usuários pretendidos em um ambiente operacional real ou simulado. O objetico é comprovar que os usuários podem usar o sistema para atender às suas necessidades, atender aos requisitos e executar processos de negócios com o mínimo de dificuldade, custo e risco.

Teste de Aceite Operacional (OAT)

O OAT é um teste de aceite do sistema realizado pelas operações ou pela equipe de administração de sistemas, geralmente em um ambiente de produção (simulado). O seu objetivo principal é criar confiança de que os operadores ou administradores do sistema possam manter o sistema funcionando adequadamente para os usuários no ambiente operacional, mesmo sob condições excepcionais ou difíceis. OATs podem incluir:

• Teste de backup e restauração
• Instalar, desinstalar e atualizar
• Recuperação de desastres
• Gerenciamento de usuários
• Tarefas de manutenção
• Carregamento de dados e tarefas de migração
• Verifica vulnerabilidades de segurança
• Teste de performance (suportado por ferramentas como Jmeter e Grafana K6)

Teste de Aceite Contratual e Regulatório

O teste de aceite contratual se baseia nos critérios de aceite de um contrato para desenvolver softwares específicos. Tais critérios devem ser definidos quando as partes concordam com o contrato. Já o teste de aceite regulatório é realizado em relação a quaisquer regulamentos que devem ser seguidos, como governamentais, legais ou de segurança. Ambos os tipos de testes são frequentemente realizado por usuários ou testadores independentes (no caso do regulatório, os resultados podem ser testemunhados ou auditados por agências reguladoras) e possuem o objetivo de criar a confiança de que a conformidade contratual ou regulatória foi alcançada.

Alfa teste e Beta teste

São testes usados por desenvolvedores de software comercial de prateleira (COTS) que desejam obter feedback de usuários, clientes, operadores em potencial ou existentes antes que o produto seja colocado no mercado. O alfa teste é realizado no site da organização em desenvolvimento por clientes (existentes ou em potencial), operadores ou por uma equipe de teste independente. Já o beta teste é feito por esse mesmo conjunto de usuários da alfa, mas com os testes ocorrendo nos respectivos locais de cada usuário.

O objetivo desses dois testes é construir a confiança entre os clientes ou operadores de que o sistema pode ser usado no dia a dia para atingir suas metas sem o mínimo de dificuldade, custo e risco. Outro fator pode ser a detecção dos defeitos relacionados às condições e ambientes em que o sistema será utilizado, principalmente quando tais condições são difíceis de replicar pela equipe de desenvolvimento. 

 

Base de teste:

• Processos de negócios
• Requisitos do usuário ou de negócios
• Regulamentos, contratos legais e normas
• Casos de uso
• Requisitos de sistema
• Documentação do sistema ou usuário
• Procedimentos de instalação
• Relatórios de análise de risco

Objetos de teste típicos

• Sistema sob teste
• Configuração do sistema e dados de configuração
• Processos de negócios para um sistema totalmente integrado
• Sistemas de recuperação e hot sites (para continuidade de negócios e testes de recuperação de desastres)
• Processos operacionais e de manutenção
• Formulários
• Relatórios
• Dados de produção existentes e convertidos

Defeitos típico e falhas:

• Fluxos de trabalho do sistema não atendem aos requisitos do negócio ou do usuário
• Regras de negócios não são implementadas corretamente
• O sistema não satisfaz os requisitos contratuais ou regulatórios
• Falhas não-funcionais, como vulnerabilidades de segurança, eficiência de performance inadequada sob altas cargas ou operação inadequada em uma plataforma suportada

Abordagens e responsabilidades específicas:

O teste de aceite é geralmente responsabilidade dos clientes, usuários de negócios, proprietários de produtos ou operadores de um sistema, além de stakeholders que também podem estar envolvidos.

Normalmente, ele é realizado no final, como o último nível de teste em software. No desenvolvimento iterativo, as equipes de projeto podem empregar várias formas de testes de aceite durante e ao final de cada iteração. Além disso, o alfa e o beta testes, assim como o UAT, OAT e o teste de aceite contratual e regulatório podem ocorrer no final de cada iteração, após a conclusão de cada iteração ou após uma série de iterações.

 

Fonte: International Software Testing Qualifications Board: Certified Testes Foundation Level Syllabus