Menu

O que é STLC V-Model?

what is stlc v model

Experimente Nosso Instrumento Para Eliminar Problemas

O que é STLC V-Model?

Uma das maiores desvantagens de modelo STLC cachoeira foi que os defeitos foram encontrados em um estágio muito posterior do processo de desenvolvimento, uma vez que o teste foi feito no final do ciclo de desenvolvimento. Reparar os defeitos tornou-se muito desafiador e caro, uma vez que foi encontrado em um estágio muito posterior. Para superar este problema, um novo modelo de desenvolvimento foi introduzido, denominado “Modelo V”

O modelo V é agora um dos processos de desenvolvimento de software mais amplamente usados. A introdução do modelo V realmente provou a implementação dos testes desde a fase de requisitos. O modelo V também é chamado de modelo de verificação e validação.

STLC V-Model

O que você aprenderá:

Verificação e validação

Para entender o modelo V, vamos primeiro entender o que é verificação e validação em software.

Verificação : A verificação é uma técnica de análise estática. Nesta técnica, o teste é feito sem executar o código. Os exemplos incluem - revisões, inspeção e passo a passo.

Validação : A validação é uma técnica de análise dinâmica em que o teste é feito executando o código. Os exemplos incluem técnicas de teste funcionais e não funcionais.

V-Model

No modelo V, as atividades de desenvolvimento e QA são feitas simultaneamente. Não existe uma fase discreta chamada Teste, em vez disso, o teste começa logo na fase de requisitos. As atividades de verificação e validação caminham juntas.

Para entender o modelo V, vejamos a figura abaixo:

Modelo STLC V

ferramentas de teste de desempenho para aplicativos Java

Em um processo de desenvolvimento típico, o lado esquerdo mostra as atividades de desenvolvimento e o lado direito mostra as atividades de teste. Eu não estaria errado se dissesse que na fase de desenvolvimento a verificação e a validação são realizadas junto com as atividades de desenvolvimento reais.

Agora vamos entender a figura:

Lado esquerdo

Como dito anteriormente, as atividades do lado esquerdo são atividades de desenvolvimento. Normalmente sentimos, quais testes podemos fazer na fase de desenvolvimento, mas essa é a beleza desse modelo que demonstra que o teste também pode ser feito em todas as fases das atividades de desenvolvimento.

Análise de requisitos : Nesta fase, os requisitos são recolhidos, analisados ​​e estudados. Aqui, como o sistema é implementado, não é importante, mas o que o sistema deve fazer é importante. Sessões de brainstorming / passo a passo, entrevistas são feitas para ter os objetivos claros.

  • Atividades de verificação : Revisões de requisitos.
  • Atividades de validação : Criação de UAT ( Teste de aceitação de usuário ) casos de teste
  • Artefatos produzidos : Documento de compreensão de requisitos, casos de teste UAT.

Requisitos do sistema / design de alto nível : Nesta fase, o design de alto nível do software é construído. A equipe estuda e investiga como os requisitos podem ser implementados. A viabilidade técnica dos requisitos também é estudada. A equipe também apresenta os módulos que seriam criados / dependências, necessidades de hardware / software

  • Atividades de verificação : Críticas de design
  • Atividades de validação : Criação de Plano de teste do sistema e casos, Criação de métricas de rastreabilidade
  • Artefatos produzidos : Casos de teste do sistema, relatórios de viabilidade, plano de teste do sistema, requisitos de hardware-software e módulos a serem criados, etc.

Projeto arquitetônico: Nesta fase, com base no design de alto nível , arquitetura de software é criada. Os módulos, seus relacionamentos e dependências, diagramas arquitetônicos, tabelas de banco de dados, detalhes de tecnologia são finalizados nesta fase.

  • Atividades de verificação : Críticas de design
  • Atividades de validação : Plano de teste de integração e casos de teste.
  • Artefatos produzidos : Documentos de design, plano de teste de integração e casos de teste, designs de tabelas de banco de dados etc.

Projeto do módulo / Projeto de baixo nível: Nesta fase, cada módulo dos componentes de software são projetados individualmente. Métodos, classes, interfaces, tipos de dados etc. são finalizados nesta fase.

  • Atividades de verificação : Críticas de design
  • Atividades de validação : Criação e revisão de casos de teste de unidade.
  • Artefatos produzidos : Casos de teste de unidade,

Implementação / Código : Nesta fase, a codificação real é feita.

  • Atividades de verificação : Revisão de código, revisão de casos de teste
  • Atividades de validação : Criação de casos de teste funcional.
  • Artefatos produzidos : casos de teste, revisão da lista de verificação.

Lado Direito

O lado direito demonstra as atividades de teste ou a fase de validação. Começaremos de baixo.

Teste de Unidade: Nesta fase, são executados todos os casos de teste de unidade, criados na fase de design de baixo nível.

* O teste de unidade é uma técnica de teste de caixa branca, em que uma parte do código é escrita e invoca um método (ou qualquer outra parte do código) para testar se o trecho de código está fornecendo a saída esperada ou não. Esse teste é basicamente executado pela equipe de desenvolvimento. Em caso de qualquer anomalia, os defeitos são registrados e rastreados.

Artefatos produzidos : Resultados da execução do teste de unidade

Teste de integração : Nesta fase, os casos de teste de integração são executados, os quais foram criados na fase de projeto arquitetônico. Em caso de qualquer anomalia, os defeitos são registrados e rastreados.

* Teste de integração: o teste de integração é uma técnica em que os módulos de unidade testados são integrados e testados se os módulos integrados estão fornecendo os resultados esperados. Em palavras mais simples, ele valida se os componentes do aplicativo funcionam juntos conforme o esperado.

Artefatos produzidos : Resultados do teste de integração.

Teste de sistemas : Nesta fase todos os casos de teste do sistema, casos de teste funcionais e casos de teste não funcionais são executados. Em outras palavras, o teste real e completo do aplicativo ocorre aqui. Os defeitos são registrados e rastreados para o seu fechamento. O relatório de progresso também é uma parte importante desta fase. As métricas de rastreabilidade são atualizadas para verificar a cobertura e o risco mitigado.

Artefatos produzidos : Resultados de teste, logs de teste, relatório de defeito, relatório de resumo de teste e matrizes de rastreabilidade atualizadas.

Testes de aceitação do usuário : O teste de aceitação está basicamente relacionado ao teste de requisitos de negócios. Aqui, o teste é feito para validar se os requisitos de negócios são atendidos no ambiente do usuário. Teste de compatibilidade e, às vezes, teste não funcional ( Carga, estresse e volume ) testes também são feitos nesta fase.

Artefatos produzidos : Resultados do UAT, matrizes de cobertura de negócios atualizadas.

Quando usar o modelo V?

O modelo V é aplicável quando:

  • O requisito é bem definido e não ambíguo
  • Os critérios de aceitação são bem definidos.
  • O projeto é de tamanho curto a médio.
  • A tecnologia e as ferramentas utilizadas não são dinâmicas.

Prós e contras de usar o modelo V

PRÓSCONTRAS
- O desenvolvimento e o progresso são muito organizados e sistemáticos-Não é adequado para projetos maiores e complexos
- Funciona bem para projetos de pequeno a médio porte.- Não adequado se os requisitos não forem consistentes.
- O teste começa do início para que as ambigüidades sejam identificadas desde o início.- Nenhum software funcional é produzido no estágio intermediário.
- Fácil de gerenciar, pois cada fase possui objetivos e metas bem definidos.- Não há provisão para fazer análise de risco para que haja incerteza e riscos.

Leitura recomendada

^