FL-2.1.1 (K2) Explicar as relações entre as atividades de desenvolvimento de software e as atividades de teste no ciclo de vida de desenvolvimento de software.

Tópico - Progresso:

Um modelo de ciclo de vida de desenvolvimento de software descreve as atividades realizadas em cada estágio do projeto, e como se relacionam logicamente e cronologicamente.

É importante para um testador estar familiarizado com os modelos mais comuns de desenvolvimento de software, de forma a executar as atividades de testes necessárias.

Características de um bom teste para qualquer modelo de desenvolvimento de software:

Modelo de Desenvolvimento Sequencial.

No modelo de desenvolvimento CASCATA as atividades de desenvolvimento, requisitos, análise, projeto, codificação e teste são finalizadas uma após a outra.

Aqui as atividades de teste somente ocorrem após todas as atividades de desenvolvimento serem finalizadas.

No modelo V tarefas de desenvolvimento e de testes possuem importâncias iguais.

O ramo direito do modelo V define um nível de teste para cada nível do desenvolvimento. A medida que se progride através destes níveis de desenvolvimento, o software é descrito em mais detalhes. Se os erros são feitos durante essas fases, a maneira mais fácil de encontrá-los é procurá-los no nível de abstração em que foram produzidos.

Validação

Em cada nível de teste, deve-se certificar que os resultados das fases do desenvolvimento atendem aos requisitos especificados.

Este processo de certificação dos resultados de desenvolvimento de acordo com suas necessidades originais é chamado de validação.

Estamos construindo o sistema correto?

Verificação

A verificação deve assegurar que o resultado de uma fase específica foi alcançado de forma correta e completa, de acordo com sua especificação.

Significa fazer verificações para saber se as especificações são implementadas corretamente e se o produto atende a sua especificação, mas não se o produto resultante é adequado para o uso pretendido.

Estamos construindo corretamente o sistema ?

Modelo de Desenvolvimento Incremental

→  Planejamento de iterações mais curtas entregam continuamente software de valor para o cliente.

→  Incrementos do software são realizados por iteração.

→  Execução contínua de testes e níveis sobrepostos.

→  Iterações podem envolver mudanças em funcionalidades desenvolvidas em iterações anteriores, juntamente com mudanças no escopo do projeto.

Exemplos:

  • Rational Unified Process: Cada iteração tende a ser longa (dois ou três meses), e um incremento de funcionalidade é grande, como por exemplo, dois ou três grupos de funcionalidades relacionadas.
  • Scrum: Cada iteração tende a ser curta (1 ou 2 semanas), e o incremento é pequeno, como alguma melhoria e ou duas ou três funcionalidades.
  • Kanban: Implementado com ou sem iterações de duração fixa, o qual pode entregar uma melhoria ou uma funcionalidade. Pode ainda agrupar funcionalidades para liberação em uma única vez.
  • Espiral (ou prototipação): Cria incrementos experimentais dos quais alguns pode ser pesadamente retrabalhado ou ainda abandonado em um trabalho subsequente.

Modelo de Desenvolvimento Ágil

Metodologias ágeis existem há anos. Desenvolvedores passaram a entender a metodologia ágil como algo que tudo pode, ou seja, podemos desenvolver sem documentação, sem padrão, sem cuidado. Isto não é verdade.

O Manifesto Ágil possui a seguinte base:

→  Os indivíduos e as interações são mais importantes do que os processos e as ferramentas.

→  O software funcionando é mais importante do que uma documentação completa.

→  A colaboração com e dos clientes acima de apenas negociações de contratos.

→  Respostas a mudanças acima de seguir um plano.

O desenvolvimento Ágil envolve:

→  Pequenas iterações de projeto.

→  Construção de teste de software acontecem de forma contínua, suportada pelo planejamento contínuo.

Mesmo em desenvolvimento sequencial, a sequência lógica de atividades escalonada envolverá sobreposição, combinação, simultaneidade ou omissão, de modo que a adaptação dessas atividades principais dentro do contexto do sistema e do projeto geralmente seja necessária.