Aula 2 - Avaliação de SW

Prévia do material em texto

4 – Entendendo o processo de 
Qualidade de Software 
Unidade I 
mar/2013 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
2 
Não é possível conceber um processo de garantia 
da qualidade de software sem integrá-lo com o 
ciclo de desenvolvimento d software. 
Um bom processo de qualidade é aquele que cria 
uma relação um para um entre as fases de 
desenvolvimento e as atividades a serem 
acompanhadas pela equipe de qualidade. 
Esta relação bilateral promove a colaboração 
entre as áreas e reforça a ideia do objetivo 
comum. 
(Bartié) 
Introdução 
3 
Modelo de Qualidade em “U” 
Especificação de 
Requisitos 
 
 
Verificação 
de 
Requisitos 
2 
Análise e 
Modelagem 
 
 
Verificação 
Análise e 
Modelagem 
3 
Integração 
Especificada ou 
Modificada 
 
 
Validação 
da 
Integração 
6 
Unidade 
Especificada ou 
Modificada 
 
 
Validação 
da 
Unidade 
5 
Implementação 
 
 
Verificação 
da 
Implementação 
4 
Sistema 
Especificado ou 
Modificado 
 
Validação 
do 
Sistema 
7 
Testes de Validação Testes de Verificação 
Clientes 
Patrocinadores 
Usuários 
Modelo 
de 
Negócios 
 
Verificação 
de 
Negócios 
1 
Disponibiliza 
Solução 
 
Validação 
do 
Aceite 
8 
4 
O processo de qualidade de software está decomposto em 
fases que se organizam em um formato de “U”. 
Cada fase tem uma numeração indicando a sequencia de 
execução dos testes. 
Seu objetivo é garantir a produção efetiva de todos os 
produtos previstos na metodologia empregada e 
adequados com os requisitos documentados. 
Os testes de verificação visam garantir o processo de 
engenharia de software. 
Os testes de validação estão focados na garantia de 
qualidade do produto de software. 
Modelo de Qualidade em “U” 
5 
O processo de desenvolvimento de software pressupõe 
dois momentos muito bem definidos. 
 
O primeiro é a fase de coleta de informações de 
negócios e o planejamento da arquitetura do software, 
que caracteriza-se pelo esforço em criar um 
entendimento entre o negócio e o software. 
 
Nesse momento não existem componentes tecnológicos, 
mas documentos que especificam o comportamento a 
ser assimilado pelo software a ser construído. 
 
É nesse momento que temos os testes de verificação. 
Formas Básicas de um Teste 
6 
A segunda fase caracteriza-se pela existência de um 
componente computacional (seja parte ou num todo de 
uma solução). 
 
Devemos aplicar um conjunto de testes que avaliam a 
qualidade do produto de software desenvolvido em 
relação aos requisitos identificados nas fases 
anteriores. 
 
É neste momento que temos os testes de validação 
Formas Básicas de um Teste 
7 
Historicamente, as empresas vêm aplicando seus testes 
baseando-se nos testes de validação, de forma que não 
estão dirigindo os seus esforços para as fases iniciais do 
processo de desenvolvimento, portanto, os custos de 
correções e o número de erros serão muito altos na fase de 
teste de validação. 
 
Teste= Verificação + Validação 
Requisitos Análise e 
Modelagem 
Teste de 
Software 
Código Produção 
Ciclo de Desenvolvimento de Software 
1 
100 
10 
1.000 
10.000 
8 
Os testes de verificação e validação são complementares e 
não excludentes, pois possuem natureza e objetivos 
distintos. 
 
Um bom processo de qualidade deverá potencializar as duas 
formas de teste, de modo que os esforços sejam 
minimizados e os resultados os melhores possíveis. 
Teste= Verificação + Validação 
9 
Podem ser entendidos como um processo de auditoria de 
atividades e avaliação md documentos gerados durante o 
processo de desenvolvimento. 
 
As verificações devem ser aplicadas em todos os artefatos 
(documentos, gráficos, manuais, códigos-fonte etc.), 
evitando que dúvidas e inadequações migrem para a próxima 
fase. 
 
Sua principal característica é o fato de não envolver o 
processamento do software, pois elas antecedem a criação 
do aplicativo, de forma a garantir que todas as decisões e 
definições foram adequadamente entendidas e aceitas pelos 
envolvidos. 
Testes de Verificação 
10 
Serão aplicados respeitando os estágios de desenvolvimento: 
 Definição das necessidades e características de negócios a serem 
atendidas; 
 Identificação dos requisitos funcionais e não funcionais que a 
solução tecnológica deverá contemplar; 
 Definição do modelo de arquitetura da solução tecnológica; 
 Construção dos softwares que atenderão às definições da 
arquitetura estabelecida. 
Testes de Verificação 
Especificação de 
Requisitos 
 
 
Verificação 
de 
Requisitos 
2 
Análise e 
Modelagem 
 
 
Verificação 
Análise e 
Modelagem 
3 
Implementação 
 
 
Verificação 
da 
Implementação 
4 
Modelo 
de 
Negócios 
 
Verificação 
de 
Negócios 
1 
11 
 
 
 
 
 
 
 
 
 
 
Teste de Validação 
Processo formal de avaliação de produtos tecnológicos 
que podem ser aplicados em componentes isolados, 
módulos ou nos sistemas como um todo. 
Seu objetivo principal é avaliar a conformidade do 
software com os requisitos e especificações analisadas e 
revisadas nas etapas iniciais. 
Sua principal característica á a presença física do 
software e seu processamento em um ambiente 
preparado para tal atividade. 
 
 
12 
 
 
 
 
 
 
 
 
 
 
Teste de Validação 
Os testes serão baseados no comportamento do 
software, segundo diversas situações que serão 
simuladas, para que sejam comparados com as 
especificações produzidas pela área de negócios. 
A maioria dos erros de um software não se apresenta na 
forma mais explícita (não execução de uma 
funcionalidade), mas sim na forma mais camuflada e 
difícil de diagnosticar (ajuste financeiro errado), 
portanto os resultados serão os principais pontos de 
validação. 
 
 
13 
 
 
 
 
 
 
 
 
 
 
Teste de Validação 
As atividades relacionadas a planejamento, modelagem, execução e 
conferência dos testes de software deverão ocorrer em paralelo às 
atividades de construção de componentes executáveis. As validações 
serão aplicadas respeitando-se os estágios de desenvolvimento: 
 Testes em componentes executáveis isolados recém-criados e alterados; 
 Testes de interface entre componentes à medida que eles vão sendo 
integrados; 
 Testes em sistemas ou módulos completos; 
Aceite de um sistema ou módulos pelos clientes e usuários. 
 
 
Integração 
Especificada ou 
Modificada 
 
 
Validação 
da 
Integração 
6 
Unidade 
Especificada ou 
Modificada 
 
 
Validação 
da 
Unidade 
5 
Sistema 
Especificado ou 
Modificado 
 
Validação 
do 
Sistema 
7 
Disponibiliza 
Solução 
 
Validação 
do 
Aceite 
8 
6 – Por que os processos de 
Qualidade de Software fracassam 
Unidade I 
mar/2013 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
15 
Muitas tentativas de implantação de processos de 
qualidade de software fracassaram. Isto ocorreu 
porque muitos processos foram distorcidos e 
inadequadamente executados, o que gerou 
grandes frustrações, além de significativos 
prejuízos financeiros. 
(Bartié) 
Introdução 
16 
 
 
 
 
 
 
 
 
 
 
Ausência de gerência de qualidade independente 
Apesar de todo o investimento realizado na estruturação de 
ambiente de testes, aquisição de ferramentas e contratação de 
profissionais, muitas organizações não criam uma área de qualidade 
de software, deixando o gerenciamento para outra área existente. 
A faltade gerenciamento direto sob essa estrutura disponibilizada 
minimizará os benefícios que poderão ser conseguidos com um 
processo de qualidade de software 
17 
 
 
 
 
 
 
 
 
 
 
Ausência de procedimentos de teste automatizados 
Apesar de sabermos que um processo 100% automatizado é difícil de 
ser alcançado, devemos investir o máximo que pudermos na 
automação dos processos de teste. 
A utilização de procedimentos manuais deve ser muito bem avaliada, 
já que se trata de um modelo extenuante e pouco confiável. 
As interferências humanas no processo tornam o modelo muito 
frágil, o que pode desacreditar todo o esforço que está sendo 
realizado. 
18 
 
 
 
 
 
 
 
 
 
 
É sempre aplicada tardiamente 
Muitas organizações ainda acreditam que os testes devem ocorrer 
somente após o software pronto. 
Inserir profissionais ligados ao processo d qualidade na equipe de 
desenvolvimento somente reforça o conceito de qualidade como uma 
única etapa dentro do processo de criação de um software, 
possibilitando o efetivo gerenciamento do projeto de 
desenvolvimento. 
19 
 
 
 
 
 
 
 
 
 
 
Ausência de profissionais qualificados 
É muito comum observarmos organizações utilizarem seus 
profissionais de desenvolvimento para estruturar e organizar 
processos de qualidade de software. 
Essa falta de especialização afetará a eficiência do processo d 
garantia da qualidade, podendo comprometer todo os esforço de sua 
implantação. 
Enquanto um deve planejar a sua construção, o outro deve avaliar a 
sua solidez. 
Profissionais de qualidade devem possuir metodologias totalmente 
desenhadas para atender o seu maior objetivo – encontrar falhas. 
Eles devem direcionar os seus esforços em aperfeiçoar esta 
metodologia, padronizar documentações e procedimentos e ainda 
reduzir esforços no planejamento e operacionalização dessas 
atividades. 
20 
 
 
 
 
 
 
 
 
 
 
Falta de um modelo corporativo de qualidade 
Ligado diretamente à ausência de uma gerência de qualidade, de 
forma que cada projeto encontre sua forma mais particular e 
“eficiente” de estruturar um processo de qualidade, tornando-o 
frágil. 
O processo de qualidade deve ser um modelo único que gerencie as 
diversas atividades que ocorrem nos vários ambientes existentes, de 
forma a garantir rigorosos processos de qualidade em todas as 
etapas do desenvolvimento. 
 
21 
 
 
 
 
 
 
 
 
 
 
Foco em Testes Progressivos aumentam riscos 
Muitas organizações direcionam seus esforços nos chamados testes 
progressivos, que somente focalizam as novas implementações 
realizadas, desconsiderando as anteriores. 
A desculpa é a redução drástica do esforço do teste, mas em 
contrapartida não garante que as antigas funcionalidades continuem 
comportando-se adequadamente, que o teste de regressão 
provavelmente pegaria. 
 
22 
 
 
 
 
 
 
 
 
 
 
Deficiência no planejamento dos testes 
O planejamento é um exercício mental que produz uma visão sobre 
como resolver um conjunto de situações, antecipando os passos de 
realização de um trabalho. Estudamos o problema, analisamos as 
soluções, operacionalizamos uma sequência de atividades e prevemos 
eventuais riscos e insucessos. 
Se pensarmos no curto prazo, o planejamento exigirá maior esforço 
de trabalho, que é sinônimo de maiores custos quantidade de pessoas 
e horas trabalhadas. Se pensarmos no longo prazo, temos de planejar 
as atividades de forma a reduzir os custos para este longo prazo! 
O planejamento deve valorizar aspectos como reaproveitamento de 
cenários de testes já realizados, testes de regressão, redução do 
impacto das mudanças nas documentações etc. 
 
23 
 
 
 
 
 
 
 
 
 
 
Sob pressão os testes são sacrificados 
No cronograma de projeto, a etapa de testes é descrita como uma 
fase posterior à codificação, já considerado, nesse momento, um 
produto acabado. 
 
 
Modelo 
Negócios 
 
 
Requisitos 
 
 
 
 
Análise e 
modelagem 
 
 
 
Implemen 
tação 
 
 
Testes de 
Software 
 
 
 
 
Disponibili 
zação 
Tempo 
Fases com maior consumo de tempo e recursos 
24 
 
 
 
 
 
 
 
 
 
 
Sob pressão os testes são sacrificados 
Por diversas razões, os prazos de entrega de um software são 
sempre maiores do que o planejado e os custos extrapolam o 
orçamento inicial. 
Com isso é comum se buscar atalhos com a finalidade de compensar 
atrasos, e os atalhos serão obtidos da redução de tempo dedicado às 
fases que mais consomem recursos, tempo neste que será 
direcionado à etapa de codificação do produto final. 
 
 
Modelo 
Negóci
os 
 
 
Requisi
tos 
 
 
Análise 
e 
modela
gem 
 
 
 
Imple
men 
tação 
Testes 
de 
Softwa
re 
 
 
 
 
Disponi
bili 
zação 
Tempo 
Pressão Pressão 
Foco 
25 
 
 
 
 
 
 
 
 
 
 
Ausência de um ambiente de testes isolado 
O processo de validação de um software exige um ambiente 
exclusivo de testes, isolado de qualquer interferência dos demais 
ambientes. 
A interferência entre ambientes pode comprometer a qualidade dos 
testes, bem como a confiabilidade das informações e processos 
executados. E vice e versa. 
Este isolamento garante que nenhuma atividade externa prejudicará 
a execução dos procedimentos de teste. Aumentando o nível de 
eficiência dos trabalhos. 
 
 
26 
 
 
 
 
 
 
 
 
 
 
Transferir o planejamento ao analista de sistemas 
Somente o analista de testes tem a percepção e experiência das 
diversas categorias de testes existentes, sabe como organizá-los e 
como empregá-los, propiciando mais eficiência na detecção de erros. 
O analista de sistemas tem uma tendência natural de produzir testes 
válidos, aqueles já suportados pela aplicação. Ele sabe o que o 
sistema está consistindo e o que não está. Ele já decidiu o que vale a 
pena tratar dentro da aplicação. Ele não tentará submeter o 
software a condições que ele tem consciência de que o aplicativo não 
terá êxito, mesmo que inconscientemente. Obteremos um conjunto 
de testes “viciados”, já que baseiam-se em condições já tratadas. 
O analistas de testes atua com imparcialidade no planejamento no 
planejamento e na criação dos cenários para validar o software. Sua 
missão é criar variações de comportamento, nas quais apontem 
situações não previstas pelo desenvolvedor. 
27 
 
 
 
 
 
 
 
 
 
 
Dificultar o acesso do analista de teste de software 
Isto compromete a qualidade da compreensão do sistema. O 
software não é apenas o objeto do teste, mas também uma 
importante fonte de informações. 
Usando a aplicação, é possível identificar regras de negócio muitas 
vezes esquecidas nas documentações nas documentações e pelos 
analistas de sistemas. É comum descobrirmos regras de negócio, 
exercitando ações dos usuário. 
O software, além de ampliar a compreensão do negócio, auxilia no 
processo de refinamento e validação do planejamento dos testes. 
À medida que o analista de testes estabelece determinados cenários 
e condições para execução, é possível verificar se essas informações 
têm a qualidade necessária a ser empregada durante a realização dos 
testes. 
28 
 
 
 
 
 
 
 
 
 
 
Benefícios do Processo de Qualidade de Software 
 Torna o Ciclo de Desenvolvimento Confiável; 
 Garante Ações Corretivas no Ciclo de Desenvolvimento; 
 Evita a Ingerência do Projeto de Software; 
 Amplia as Chances de Sucesso do Projeto de Software; Amplia a Produtividade do Desenvolvimento; 
 Evita a Propagação de Erros; 
 Automação de Testes Reduz Custos do Projeto.