FL-2.2.1-C (K2) Compare os diferentes níveis de teste da perspectiva de seus objetivos, da base de teste, dos artefatos de teste, das falhas e defeitos típicos e das abordagens e responsabilidades.

Tópico - Progresso:

Visão Geral – Teste de Sistema

 

 

O teste de sistema verifica se o produto de software atende aos requisitos especificados. É necessário depois do teste unitário e de integração, porque:

 

→  Os testes unitário e de integração são feitos com as especificações técnicas, e sobre o ponto de vista técnico do desenvolvedor.

→  O teste de sistema é feito a partir da perspectiva do cliente e os testadores validam se os requisitos estão completamente atendidos.

→  Muitas funcionalidades do sistema resultam da interação de todos os seus componentes, de forma que só podem ser testadas nesse nível.

 

 

O teste de sistema tem o objetivo de validar se o sistema atende aos  os requisitos funcionais e não-funcionais especificados, e como ele faz isso.

 

→  Requisitos implementados de forma incorreta, incompleta ou inconsistente devem ser detectados.

→  Requisitos não documentados ou que tenham sido esquecidos devem ser identificados.

 

O principal objetivo do Sistema VSR é fazer com que os pedidos de carro sejam feitos de forma fácil. Ao fazer o pedido de um carro , o usuário exercita todos os componentes do sistema VSR:

 

 

  O carro é configurado (DreamCar).

  Financiamento e seguro são calculados (Easy-Finance, NoRisk ).

  O pedido é transmitido à produção (JustInTime).

  Os contratos são arquivados (ContractBase).

 

O sistema executa a sua finalidade quando todas estas funções do sistema e todos os  componentes colaboraram corretamente. O teste do sistema valida isso.

O teste de sistema é feito num ambiente tão semelhante quanto possível ao ambiente operacional pretendido. Em vez de drivers  e stubs, os produtos de hardware e software devem ser instalados na plataforma de teste ( hardware , software, driver de dispositivo, redes , sistemas externos , etc.).

 

 

Na tentativa de reduzir os custos e esforços, um erro é comum é em vez de testar o sistema em um ambiente separado, o teste do sistema é executado no ambiente operacional do cliente. Isso não é bom devido a:

 

  Durante os testes podem ocorrer falhas, e resultar em danos para o ambiente do cliente.

  Falta de controle sobre as configurações do ambiente de produção.

  Mudança na condições de testes devido a execução simultânea de outros sistemas no ambiente do cliente.

  Os testes do sistema que foram executados não pode ser reproduzidos ou são reproduzidos com dificuldades.

 

Esforço de teste do sistema é muitas vezes subestimado.

 

Os problemas mais comuns na prática dos testes de sistemas são:

 

  Documentação escrita incompleta ou inexistente.

  • os testadores enfrentam problemas para entender o comportamento correto do sistema.
  • Isto dificulta a localização de defeitos.

 

  Falta de clareza nos requisitos do sistema.

  • Requisitos são escritos de forma inadequada.
  • E eles só existem na cabeça de algumas pessoas envolvidas no projeto.
  • Os testadores ficam com o papel de coletar informações sobre o comportamento do software.
  • O teste exploratório pode ajudar nessa situação.

 

  Decisões não tomadas.

  • Ao identificar os requisitos os testadores descobrem que pessoas diferentes têm visões e ideias completamente diferentes sobre o mesmo assunto.
  • Isso não é surpresa, pois os requisitos nunca foram documentados, revisados ou aprovados durante o projeto.
  • Os testadores devem fazer cumprir a tomada de decisões que deveriam ter sido feita muitos meses atrás.
  • A identificação dos requisitos pode ser onerosa e atrasar o final dos testes e a liberação do sistema.

Nesses projetos a única coisa que o teste de sistema pode fazer é anunciar o colapso do projeto.