Aula 05 - Ciclo de Vida do Processo de Testes de Software

Qualidade e teste de software\nAula 5: Ciclo de Vida do Processo de Testes de Software\n\nApresentação\nNesta aula, vamos conhecer o modelo V de desenvolvimento de software para validação e verificação, identificando o paralelismo entre as atividades de desenvolvimento e teste de software.\n\nVamos identificar e reconhecer testes de verificação e de validação, diferenciar quando usar testes estáticos e dinâmicos, aprender as técnicas de teste e diferenciar os testes estruturais dos funcionais.\n\nObjetivos\n- Descrever o modelo V (verificação e validação), com paralelismo entre as atividades de desenvolvimento e teste de software;\n- Identificar os testes estáticos dos dinâmicos e suas técnicas;\n- Distinguir os testes estruturais dos funcionais.\n\n\n[Imagem do modelo V]\n\n\nFonte: Por TechnoVectors / Shutterstock Modelo V\nVocê se lembra do modelo cascata no processo de desenvolvimento de software? O modelo V é uma melhoria do cascata do desenvolvimento de produto, pois esse modelo tinha um problema de reatividade.\n\nEle permite que, durante a implementação de um sistema, os testes sejam feitos contra os próprios requisitos do componente ou interface que está sendo testado, em contraste com modelos anteriores, nos quais o componente era testado contra a especificação do componente/interface.\n\nNesse modelo, cada etapa deve ser concluída antes que a próxima inicie, e o teste é planejado em paralelo com a atividade correspondente do desenvolvimento, ou seja, o modelo considera o teste como uma atividade paralela, e não como uma atividade isolada que ocorre no final do desenvolvimento.\n\nQuais são os objetivos do modelo V?\n- Minimizar os riscos do projeto;\n- Melhorar e garantir a qualidade do projeto;\n- Reduzir os custos totais ao longo do ciclo de vida do projeto;\n- Melhorar a comunicação entre as partes interessadas. É um modelo mais robusto e completo do que o cascata, podendo produzir softwares de maior qualidade do que com ele.\n\nEsse modelo acrescenta duas partes importantes, que são:\n\nVerificação\n- Que está relacionado com a questão: O produto está sendo feito corretamente?\n\nValidação\n- Está relacionado com a questão: O produto está sendo feito, ou seja, o software atende ao objetivo pretendido com precisão?\n\nNo modelo V, podemos ver as mesmas fases do cascata, mas com uma melhor relação entre elas.\n\nVantagens:\n- A relação entre os estágios de desenvolvimento e os diferentes tipos de testes facilita a localização de falhas;\n- É um modelo simples e fácil de aprender;\n- Especifica os papéis dos diferentes tipos de testes para ser executada;\n- Envolve o usuário no teste.\n\nDesvantagens:\n- É difícil para o cliente expor explicitamente todos os requisitos;\n- O cliente deve ter paciência, pois receberá o produto no fim do ciclo de vida;\n- O teste pode ser caro e às vezes não ser suficientemente eficaz;\n- O produto final pode não refletir todas as necessidades dos utilizadores. Paralelismo entre as atividades de desenvolvimento e teste de software\n\nAlém do paralelismo entre as atividades, o teste paralelo também serve para comparar os resultados do teste do sistema atual com a versão anterior. Essa comparação é importante para determinar se os resultados do novo sistema são consistentes com o processamento do antigo sistema ou da antiga versão.\n\nTemos que executar o teste paralelo os mesmos dados de entrada utilizados nas duas versões da mesma aplicação.\n\nExemplo\n\nSe os requisitos não forem alterados na nova versão, os resultados com os dados de saída das duas versões (atual e nova) devem ser iguais.\n\nProcesso de teste\n\nCom relação aos custos, ao tratar os testes como um processo organizado e muitas vezes paralelo e integrado ao processo de desenvolvimento, os custos de manutenção ficaram bem reduzidos.\n\nSegundo Myers, o custo de correção tende a aumentar quanto mais tarde o defeito for detectado.\n\n\"Defeitos encontrados durante a produção tendem a custar muito mais que aqueles encontrados em modelos de dados e em outros documentos do projeto do software.\"\n\nAtenção Verificação da migração de dados\n\nCom relação aos dados, após o carregamento para o novo sistema, os resultados são submetidos a uma etapa de verificação dos dados para determinar se estes foram corretamente migrados, se ocorreu de forma completa.\n\nDurante essa verificação, pode ser necessário um processo de execução em paralelo de ambos os sistemas para identificar áreas de disparidade e evitar erros de perda de dados.\n\nVeja alguns processos de teste: Teste de migração de dados\n\nO paralelismo pode ser usado também pelas equipes de teste de aceitação e operacional, que irão realizar o teste de concepção e execução em paralelo em duas plataformas completamente diferentes e com objetivos e propósitos diferentes.\n\nJá a equipe de teste de legado irá trabalhar com cada um dos outros grupos separadamente.\n\nEquipe de teste operacional\n\nÉ composta de usuários que irão utilizar o sistema. O grupo operacional realiza testes em paralelo com a equipe de aceitação, mas com um objetivo completamente diferente.\n\nEsse grupo trabalha na futura plataforma e no ambiente sob todos os aspectos que não sejam só o ponto de vista do negócio, ou seja, de conectividade e interoperabilidade.\n\nEsse grupo também testa interfaces, desempenho, sistema de back-ups e demais elementos da nova plataforma.\n\nSimulação do novo sistema em substitutivo ao antigo\n\nNesta etapa do processo, deverá ser realizado um simulado do novo sistema em condições reais de funcionamento em paralelo ao antigo sistema, para que o usuário gestor possa avaliar possíveis necessidades de ajustes do fluxo operacional e computacional para o trazer benefícios com a instalação do novo sistema.\n\nScripts estruturados ou scripts compartilhados\n\nEsta técnica aciona mais de um comando, simulando a execução em paralelo de diversas ações.\n\nTeste de unidade\n\nO teste de unidade enfoca o esforço de verificação da menor unidade do projeto de software, que é o módulo.\n\nUsa-se como guia para a execução deste tipo de teste uma descrição detalhada do projeto. Importantes caminhos de controle são testados para descobrir erros nas interfaces dos módulos.\n\nO teste de unidade é do tipo caixa branca (veremos esse tipo de teste mais tarde). Pode ser conduzido em paralelo para vários módulos.\n\nTeste de validação\n\nOs testes são baseados no comportamento do software por meio das mais diversas condições baseadas e comparadas com as especificações levantadas pela área de negócio.\n\nDurante o desenvolvimento do software, deverão ser aplicadas diferentes categorias de testes empregando ferramentas, técnicas e abordagens diferentes.\n\nAs atividades de teste (conforme o modelo V, planejamento, modelagem, execução e conferência) deverão ocorrer em paralelo às atividades de construção de componentes executivos e respeitando os estágios de desenvolvimento.\n\nVerificação e validação\n\nA atividade de teste de software é elemento de um tema mais amplo chamado verificação e validação. Verificação\nRefere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica.\nA definição de verificação e validação abrange muitas das atividades às quais está diretamente ligada a garantia da qualidade de software (SQA).\nVamos ver de outra forma o modelo V como um U.\nFormato de \"U\"\nTestes de verificação\nModelo de negócios\nVerificação da solução\nEspecificação de requisitos\nAnálise e modelagem\nVerificação de implementação\nUnidade especificada\nVerificação de unidade\nValidação de integração\nValidação do aceita\nSistema especificado\nDisponibilidade do solução\nValidação de aceitação\n\nValidação\nRefere-se ao conjunto de atividades que garante que o software que foi construído segue as exigências do cliente.\n\nComo são esses momentos do processo de desenvolvimento de software?\nTeste = Verificação + Validação\nGarantir o processo\nGarantir a qualidade do produto Os testes de verificação e validação são complementares, não devendo ser encarados como atividades redundantes. Cada um possui natureza e objetivo distinto, fortalecendo desta forma o processo de detecção de erros e aumentando a qualidade final do produto. Teste de verificação\nÉ a coleta de informações de negócios e o planejamento da arquitetura do software.\nA principal preocupação é o entendimento e a coerção entre o negócio e a ser enviado o software a ser construído.\nNesta fase não existem componentes tecnológicos, mas documentos que especificam o comportamento a ser seguido pelo software a ser desenvolvido.\nÉ um processo de auditoria de atividades e avaliação de documentos gerados em todas as fases do processo de desenvolvimento de software (PDS).\nEsses testes não envolvem o processamento de softwares, pois eles ainda não nasceram.\n\nVejamos cada um dos processos de verificação.\nVerificação dos negócios\nSeu objetivo é garantir que os diversos documentos produzidos tenham total aderência às necessidades apontadas pelos clientes.\nVerificação dos requisitos\nSeu objetivo é fazer a verificação das especificações de levantamento dos requisitos funcionais e não funcionais do software a ser desenvolvido.\nVerificação da implementação\nSeu objetivo é garantir a qualidade do código-fonte gerado pela equipe de desenvolvimento.\nComo se garante essa qualidade?\nPela prática rígida na boa programação;\nPela conformidade do código produzido.\nTeste de validação\nÉ um processo formal de avaliação de produtos tecnológicos que podem ser aplicados em componentes isolados, módulos existentes ou no mesmo a totalidade do sistema.\nQual é o seu objetivo?\nAvaliar a conformidade do software com os requisitos e especificações analisadas e revisadas nas etapas iniciais do projeto.\nComo ele se caracteriza?\nPela presença física do software e de seu processamento em um ambiente tecnicamente preparado.\nVejamos cada um dos processos de validação.\nValidação da unidade\nA validação de unidade é a primeira etapa do processo de validação. Seu objetivo é testar os componentes individuais de uma aplicação.\nValidação da integração\nA validação de integração é uma continuidade natural dos testes unitários. Seu objetivo é validar a compatibilidade entre componentes de um software.\nValidação do sistema\nSeu objetivo é validar a solução como um todo. Quando este estágio é atingido, a maior parte das falhas de funcionalidade deve ter sido detectada pelos testes unitários e pelos de integrações. Validação do aceite\nÉ o último estágio do processo de validação, sendo o último processo formal de detecção de erros no sistema, antes de sua disponibilização no ambiente de produção.\n\nNessa etapa, o software é disponibilizado para clientes e usuários com o objetivo que eles mesmos validarem todas as funcionalidades requisitadas no início do projeto.\n\nExemplo de testes de validação\nValidação: testes que demonstram conformidade com os requisitos.\nPlano de teste: descreve classes de teste + procedimento de teste + casos de teste.\n\nApós a execução de cada caso de teste de validação ser conduzido:\n1) O a característica testada está de acordo com a especificação – é aceita;\n2) O que descobr-se um desvio da especificação – lista de deficiências.\n\nObjetivo: verificar o produto nas referências e padrões de usabilidade e de desempenho estabelecidos no planejamento da validação.\n\nAtenção! Aqui existe uma videoaula, acesse pelo conteúdo online\n\nTestes estáticos X testes dinâmicos\n\nFalhas de software são uma constante para quem trabalha com desenvolvimento.\n\nFalhas menores podem representar apenas pequenos problemas na execução de um sistema. Já em casos mais graves, um bug ou vulnerabilidade pode levar à exposição de dados de usuários e informações privadas de empresas.\n\nAlgumas divisões podem ser estabelecidas em relação ao teste de software. Uma delas corresponde à forma de utilização do código obtido na etapa de implementação (ou codificação). Segundo esta ótica, podem-se organizar os testes em estáticos e dinâmicos.\n\nOs métodos de verificação utilizam técnicas de testes estáticos para avaliar a qualidade dos documentos gerados durante todas as etapas do desenvolvimento do software.\n\nPara avaliarmos a qualidade de um sistema, os testes não podem ser estáticos; precisam ser dinâmicos, pois devemos submeter o software a determinadas condições de uso de forma a avaliar se o comportamento está de acordo com o esperado.