FL-2.4.1 (K2) Resumir os gatilhos para o teste de manutenção.

Tópico - Progresso:

Teste de Manutenção

 

 

 

Software não se desgasta, mas se deteriora.

 

 

O objetivo da manutenção de software não é manter a capacidade de operar ou para reparar danos causados ​​por uso intensivo. Defeitos não se originam a partir de desgaste. São falhas de design que já existem na versão original.

 

Falamos de manutenção de software quando:

 

 

Testar se as alterações foram bem sucedidas pode ser difícil, pois as especificações do sistema estão muitas vezes desatualizadas ou são inexistentes, especialmente no caso de sistemas legados.

 

 

Veja as respostas da equipe de desenvolvimento para cada um dos problemas apresentados:

 

  Alguns revendedores usam o sistema em uma plataforma com uma versão antiga do sistema operacional. Nesses ambientes, algumas vezes o sistema falha durante o acesso ao mainframe.

R: É de responsabilidade do revendedor, pois o sistema é executado em uma plataforma para a qual não foi concebido.

 

  Muitos clientes consideram a seleção de acessórios opcionais desagradável, é difícil comparar preços entre diferentes pacotes de acessórios opcionais. Os usuários gostaria de salvar configurações acessórios e poder recuperá-las posteriormente.

R: Esses problemas sempre irão surgir e se deve ao fato de que o novo sistema gera novas experiências e  novas exigências surgirão naturalmente.

 

  Alguns preços de seguros não podem ser calculados completamente, porque a implementação do cálculo foi esquecido.

R: É um problema que poderia ter sido detectado durante o teste do sistema. Um bom gerente de teste irá analisar que tipo de teste teria detectado este problema para melhorar o plano de teste.

 

  As vezes, leva mais de 15 minutos para a confirmação de um pedido pelo servidor. O sistema corta a ligação após 15 minutos, para evitar que as conexões não utilizadas permaneçam ativas. Os clientes se irritam, pois perdem muito tempo para a confirmação do pedido de compra. Quando a linha é cortada, o revendedor tem que introduzir o pedido novamente e  depois enviar a confirmação para o cliente.

R: Esse problema foi corrigido no teste de integração. O sistema VSR espera por uma confirmação até 15 minutos, sem perder a conexão. Pode ocorrer um longo tempo de espera porque os processos batch são executados no mainframe. O fato de que o cliente não quer esperar na loja por um tempo tão longo é um outro assunto.

 

Gatilhos para o teste de manutenção.

 

Modificação: Como aprimoramentos planejados (p.e., baseados em versão), alterações corretivas e
emergenciais, alterações no ambiente operacional (como sistema operacional ou atualizações de
banco de dados), atualizações de software de prateleira (COTS) usados e correções para defeitos e
vulnerabilidades.

Migração: Como de uma plataforma para outra, que pode exigir testes operacionais do novo
ambiente, bem como do software alterado, ou testes de conversão de dados quando os dados de
outro aplicativo serão migrados para o sistema que está sendo mantido.

Aposentadoria: Como quando um aplicativo atinge o fim de sua vida útil.

 

Em um sistema além do trabalho de manutenção, há mudanças e novas funcionalidades que são previstas desde o início do projeto.

No plano de desenvolvimento para a versão 2 do  VSR, está previsto que:

 

 

Essas tarefas não fazem parte da manutenção do software (oriunda de defeitos), mas da evolução normal  do software.

 

Após cada lançamento, o projeto começa novamente e passa por todas as fases do projeto.  Esta abordagem é chamada de desenvolvimento de software iterativo.

 

 


No desenvolvimento incremental o projeto não é feito de um entrega única, mas como uma série de desenvolvimentos e entregas menores.


 

As funcionalidades e confiabilidade do sistema vão crescer ao longo do tempo.

 

A partir de uma versão inicial apenas para o grupo de desenvolvimento ou para usuários especiais,  e posteriormente com versões lançadas para o cliente. Cada incremento , adicionado a outros incrementos desenvolvidos anteriormente , formarão gradualmente o sistema desejado. Modelos incrementais tentam reduzir o risco de desenvolver o sistema errado , fornecendo partes úteis do sistema mais cedo e assim receber feedback do cliente.

 

 

 

Exemplos de modelos iterativos e ou incrementais:

 

 

Os testes devem ser adaptados a tais modelos de desenvolvimento e testes de integração contínua e de regressão são necessários.

 

Deve haver casos de teste reutilizáveis ​​para todos os componentes e incrementos. Caso contrário a confiabilidade do produto tende a diminuir ao longo do tempo , em vez de aumentar.

 

De forma prática nesses projetos é conveniente executar vários modelos V em sequência. Cada lado do “V” reutiliza material de teste existente e acrescenta os testes necessários para um novo desenvolvimento.