Aula 7 - Avaliação de SW

Prévia do material em texto

Unidade III – Testes de Validação 
14 – Analisando cada Fase 
Unidade III 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
Abr/2013 
2 
 Em determinado momento do projeto, todos os 
levantamentos e decisões realizadas são materializados em 
produtos tecnológicos que foram construídos para atender às 
especificações definidas na etapa inicial do processo. 
 
 Os testes de validação têm por objetivo avaliar a 
qualidade desse produto nas mais variadas dimensões possíveis. 
 
 Ao contrário dos testes de verificação, que atuam em 
artefatos e procedimentos de trabalho, os testes de validação 
são aplicados diretamente no software que está sendo 
construído, tendo a árdua missão de identificar erros que 
foram introduzidos na solução no decorrer do projeto. 
Fazendo uma Reflexão 
3 
Estágios dos Testes de Software 
Teste de 
Unidade 
 
Teste de 
Aceitação 
 
Teste de 
Sistema 
 
 
Teste 
de 
Baixo 
Nível 
Teste 
de Alto 
Nível 
 Estratégia Caixa-Branca; 
 Testam partes do software; 
 Requer conhecimento da estrutura interna; 
 Executado pelo desenvolvedor ou profissional de teste. 
 Estratégia de Caixa-Preta; 
 Os testes são aplicados no software como um todo; 
 Não requer conhecimento da estrutura interna do software; 
 Requer ambiente muito semelhante ao da produção; 
 Deve ser executado por um grupo de teste independente. 
 
 Estrutura Interna; 
 Funcionalidade; 
 Usabilidade 
 Segurança; 
 Funcionais; 
 Não Funcionais; 
o Performance; 
o Instalação; 
o Recuperação; 
o Carga; 
 Funcional; 
 Usabilidade; 
 Segurança; 
 Estratégia de Caixa-Preta; 
 Os testes são aplicados no software como um todo; 
 Não requer conhecimento da estrutura interna do software; 
 Requer ambiente muito semelhante ao da produção; 
 Deve ser executado pelos usuários finais. 
 
 Interfaces; 
 Dependências entre 
Componentes; 
 Estratégia de Caixa-Branca; 
 Testam integrações entre partes do software; 
 Requer conhecimento da arquitetura interna do software; 
 Executado pelo desenvolvedor ou profissional de teste. 
 
Teste de 
Integração 
Fase da 
Validação 
Categorias de 
Testes Aplicada 
Características da 
Fase de Validação 
4 
 Os testes de baixo nível são caracterizados por exigir 
dos profissionais de testes um profundo conhecimento da 
estrutura interna do produto. 
Podem ser realizados pelo próprio desenvolvedor ou por um 
profissional dedicado a esta finalidade. 
Esta decisão depende da maturidade da organização, 
criticidade da aplicação, disponibilidade de recursos e das 
restrições orçamentárias do projeto. 
Estágios dos Testes de Software 
5 
 Os testes de alto nível são caracterizados por não 
requererem conhecimento da estrutura interna do produto, 
possibilitando testes com maior “nível de abstração”. 
Estes testes são executados por uma equipe independente, 
sendo guiados pelas especificações de negócio e pela lista de 
requisitos do software. 
Estágios dos Testes de Software 
6 
É a primeira etapa do processo de validação que tem por 
objetivo testar os componentes individuais de uma aplicação. 
São orientados à estrutura interna, o que os caracteriza por 
testes de caixa branca. 
Mesmo um componente com uma estrutura interna validada 
adequadamente por um conjunto completo de testes caixa 
branca pode não estar contemplando adequadamente todos os 
requisitos, daí a necessidade de testes que os validem (caixa 
preta). 
Validação da Unidade 
 Traduzir os modelos em estruturas internas dos códigos. 
 Traduzir os requisitos de negócios, regras e comportamentos 
em código-fonte. 
 Unidade Especificada 
ou Modificada 
 
 Garantir máxima cobertura do código-fonte. 
 Garantir o processamento de diferentes caminhos. 
 Garantir que determinados requisitos estejam implementados. 
 Validação da Unidade 
5 
7 
Seguem alguns exemplos de pontos de validação que poderiam 
ser considerados críticos para avaliarmos a qualidade dos 
componentes: 
Testes que empregam métodos caixa branca: 
 Exercitar todas as linhas de código; 
 Exercitar todos os desvios condicionais; 
 Exercitar todos os fluxos alternativos. 
 Testes que empregam métodos Caixa Preta: 
 Validar todos os requisitos funcionais; 
 Validar todos os requisitos de usabilidade; 
 Validar todos os requisitos de sistema. 
Validação da Unidade 
8 
Têm por objetivo examinar detalhadamente segmentos do 
código-fonte e simular o processamento dos componentes de 
modo a exercitar a estrutura interna. 
A grande desvantagem desta configuração de teste é o fato de 
exigir um profissional de grande experiência na linguagem de 
desenvolvimento usada e um alto grau de compreensão de toda 
a arquitetura interna do componente, bem como padrões 
utilizados, modelos de dados, ferramentas de desenvolvimento, 
o que exigiria do profissional total envolvimento no processo de 
criação do software. 
Validação de Unidades – Caixa Branca 
9 
Por esses motivos, é natural que essas atividades sejam 
transferidas para o próprio desenvolvedor, pois ele possui 
todas estas características. 
O grande problema é o conflito de interesses, pois ele está 
sempre sendo pressionado a construir softwares com rapidez, 
o que significa que testar é uma atividade secundária. 
Validação de Unidades – Caixa Branca 
10 
É aconselhável a utilização de um ou mais profissionais para 
integrar o processo de desenvolvimento, pois eliminaria os 
riscos de testes superficiais. 
A percepção de que isto seriam custos adicionais não se 
sustenta, pois o modelo que estamos trabalhando há anos se 
baseia na premissa que essas correções são características 
naturais e nada podemos fazer, pois nenhum levantamento de 
custos com correção é efetuado. 
Devemos lembrar que estes erros encarecem o software e 
reduzem a produtividade. 
Validação de Unidades – Caixa Branca 
11 
As validações serão baseadas na arquitetura da aplicação, 
sendo possível identificar quais requisitos são mais adequados 
aplicar durante os testes de cada unidade. 
Projetos orientados a objetos normalmente são separados em 
pacotes de especialização (packages) que facilitam a 
organização e representam melhor a arquitetura aplicada. 
Cada pacote existente agrupa um conjunto de componentes que 
têm as mesmas características e finalidades, possibilitando 
identificar um padrão único de abordagem dos testes: 
Validação de Unidades – Caixa Preta 
12 
User Packages: para pacotes de componentes que lidam 
especificamente com a interface do usuário – baseados em 
requisitos de usabilidade. 
Business Packages: para pacotes de componentes que lidam 
especificamente com as transações de negócios da aplicação – 
baseados nos requisitos funcionais (cenários básico, 
alternativos e de exceção). 
Data Packages: para pacotes de componentes que lidam 
especificamente com as transações de dados (tabelas, stored-
procedures, transações de backup e recuperação de dados) – 
baseados em requisitos de armazenamento e recuperação. 
Validação de Unidades – Caixa Preta 
13 
Utilities-Packages: para pacotes de componentes utilitários 
que apoiam e reduzem os esforços de desenvolvimento de 
outros pacotes (controle de arquivos físicos, bibliotecas de 
criptografia, comunicação com sistemas office-automation) – 
baseados em requisitos de sistemas coletados durante o 
desenrolar do projeto. 
Esses requisitos são gerenciados corporativamente pela 
organização para que todos os outros projetos possam se 
beneficiar desses componentes utilitários. 
Validação de Unidades – Caixa Preta 
14 
As unidades são testadas de forma totalmente isoladas, 
eliminando a existência entre as outras unidades.Isto possibilita que os testes ocorram em qualquer sequência 
ou momento do projeto, uma vez que os componentes que são 
acionados por esta unidade não precisam estar prontos ou 
funcionando corretamente. 
Por outro lado, exige grande esforço de criação de simuladores 
(que não são simples de projetar e implementar) para cada 
componente que é acionado. 
Validação de Unidades – Abordagem Isolada 
15 
Validação de Unidades – Abordagem Isolada 
16 
Permitem uma condição perfeita para um ambiente de testes: 
 Eliminam dependências já que não é necessária a 
existência física de outros componentes para o teste; 
 Não existe sequencia de execução dos testes, 
permitindo a realização de testes paralelos de unidades 
(não preciso esperar a unidade xpto ficar pronta para 
testar tal componente). 
Como as chamadas realizadas a outros componentes são feitas 
de forma simulada, existe um risco real de que um determinado 
componente tenha modificado sua chamada (incluído um novo 
parâmetro), deixando incompatível a chamada para esse novo 
componente. Este teste não identificaria este problema. 
Validação de Unidades – Abordagem Isolada 
17 
Os testes unitários estão intimamente ligados à forma como eé 
conduzido o processo de desenvolvimento. 
Nos projetos estruturados, atendidos tipicamente por 
processos de análise estruturada ou análise essencial, as 
unidades são produzidas através de refinamentos sucessivos do 
projeto, ou seja, quando estamos criando uma unidade de 
software, os níveis superiores estão todos construídos e 
validados, enquanto que os níveis inferiores ainda não foram 
construídos. 
Dessa forma, quando uma determinada unidade será validada, 
todas as demais unidades que acionam seus serviços e que 
estão localizadas em níveis hierárquicos superiores estarão 
disponíveis para integrar os testes unitários como substituto 
natural dos controladores de teste. 
Validação de Unidades – Abordagem Top-down 
18 
Validação de Unidades – Abordagem Top-down 
 Unidade 
E 
Simulador 
H 
Simulador 
I 
Simulador 
J 
Arquitetura Completa do Aplicativo 
Top-down 
Arquitetura do Teste da Unidade E 
 Unidade 
A 
 Unidade 
D 
 Unidade 
E 
 Unidade 
H 
 Unidade 
G 
 Unidade 
F 
 Unidade 
I 
 Unidade J 
 Unidade 
B 
 Unidade 
C 
 Unidade 
B 
 Unidade 
C 
19 
Já as unidades inferiores não terão sido criadas, necessitando 
da construção de simuladores para responder a eventuais 
chamadas acionadas pela unidade a ser testada. 
A vantagem dessa abordagem é o direcionamento explícito dos 
testes com relação aos requisitos de negócio. 
Como é natural que as unidades de maior nível suportem as 
telas de navegação do sistema, os testes poderão ser 
direcionados facilmente por estas estruturas, facilitando a 
análise de requisitos que não estão sendo atendidos. 
A desvantagem é o fato de ela estar fortemente apoiada na 
construção de simuladores, o que aumenta significativamente 
os esforços de construção de um ambiente de testes, e que 
aumenta ainda mais quando avançamos e atingimos níveis mais 
baixos de estruturação. 
Validação de Unidades – Abordagem Top-down 
20 
Nessa abordagem, os testes unitários acompanham a 
estratégia de desenvolvimento baseados em projetos 
orientados a objetos, onde não existe uma hierarquia de 
unidades . 
Os problemas são fragmentados em um conjunto de 
pequenas unidades especializadas de software que 
atenderão isoladamente a uma pequena fração do 
processo, que poderão ser empregadas em outros 
processos serem modelados de forma a maximizar a 
reutilização do código. 
Validação de Unidades – Abordagem Bottom-up 
21 
 Unidade 
E 
Unidade 
H 
Unidade 
I 
Unidade 
J 
Arquitetura Completa do Aplicativo 
Bottom-Up 
Arquitetura do Teste da Unidade E 
 Unidade 
A 
 Unidade 
D 
 Unidade 
E 
 Unidade 
H 
 Unidade 
G 
 Unidade 
F 
 Unidade 
I 
 Unidade J 
 Unidade 
B 
 Unidade 
C 
 Controlador 
 Testes-E 
Validação de Unidades – Abordagem Bottom-up 
22 
Como característica do projetos orientados a objetos, uma 
única funcionalidade pode demandar a criação de um grande 
conjunto de unidades – chamadas classe. 
À medida que cada unidade é criada para atender a uma 
pequena fração da funcionalidade, esta deve ser testada 
isoladamente, avaliando se suas operações especializadas foram 
adequadamente implementadas. 
Após a validação isolada de cada unidade, torna-se necessário 
testar todas em conjunto, avaliando se a funcionalidade foi 
integralmente atendida. 
As unidades mais básicas serão codificadas antes das classes 
que utilizarão os serviços que serão disponibilizados, de forma 
que os testes exigirão controladores para simular as chamadas 
às rotinas especializadas das classes. 
Validação de Unidades – Abordagem Bottom-up 
23 
A vantagem dessa abordagem é a facilidade de realizar testes 
nas unidades mais básicas do projeto, o que potencializa os 
testes de classes. 
Os testes podem atingir a cobertura total da estrutura 
interna, possibilitando a simulação de todos os fluxos 
alternativos de processamento, além de exercitar os diversos 
desvios de condições existentes. 
A desvantagem é a crescente complexidade que os testes irão 
ganhando à medida que progredimos e subimos os níveis de 
interação com outras unidades, reduzindo o nível de cobertura 
estrutural alcançado pelos testes. 
Validação de Unidades – Abordagem Bottom-up 
24 
São uma natural continuação dos testes unitários, e podem ser 
entendidos como o segundo estágio do processo de validação. 
À medida que as unidades vão sendo construídas ou 
modificadas, estas devem manter a compatibilidade com outros 
componentes existentes. 
Esses testes são orientados pela própria arquitetura do 
projeto tecnológico, na qual são colocados diversos 
componentes para que sejam processados e tenham suas 
interfaces exercitadas e validadas. 
Validação da Integração 
 Traduzir o modelo de arquitetura em componentes tecnológicos. 
 Traduzir os requisitos de negócios, regras e comportamentos em 
código-fonte. 
 Unidade Especificada 
ou Modificada 
 
 Garantir a perfeita interface entre os diversos componentes 
existentes na arquitetura tecnológica 
 Garantir perfeita colaboração entre os componentes. 
 Garantir que determinados requisitos estejam implementados. 
 
 Validação da 
Integração 
6 
25 
Tem o objetivo de validar a compatibilidade entre componentes 
da mesma arquitetura, que é quebrada sempre que uma alteração 
ou exclusão de uma rotina ou propriedade pública de um 
componente. 
Quando isto ocorre, todos os outros componentes que empregam 
estas rotinas ou propriedades ficam automaticamente incompatí-
veis com o componente modificado, gerando erros. 
Abaixo estão relatados alguns pontos de validação críticos: 
 Exercitar todas as dependências entre componentes. 
 Exercitar todas as interfaces do componente. 
 Exercitar todas os parâmetros de interface do componente. 
 Exercitar todas as propriedades públicas do componente. 
Validação da Integração 
26 
Provavelmente é o mais usado, onde os componentes são 
testados individualmente (teste de unidade) e depois integrados 
todos de uma única vez. 
É o que requer menos esforço, mas por outro lado é o que traz 
menos benefícios, já que diagnosticar um erro é bastante 
complexo, pois é difícil identificar qual dos componentes está 
produzindo o efeito. 
Resume-se na aplicação de testes de integração após a 
construção de todas as unidades, ou seja, de todas as unidades 
ao mesmo tempo, não havendo ciclos parciais de integração. 
Validação da Integração – Abordagem Big-bang 
27 
Seguem a filosofia dedesenvolvimento estrutural comumente 
conhecido como desenvolvimento top-down. 
As unidades de maior nível hierárquico são criadas inicialmente, 
sofrendo um processo de refinamento e decomposição 
sucessivos, até que seja alcançado o menor nível estrutural do 
projeto e todas as unidades tenham sido criadas. 
À medida que as unidades são construídas e alteradas, estes 
testes avaliam se as interfaces com outras unidades continuam 
compatíveis. 
Pode ser realizada em largura ou em profundidade. 
Quando em profundidade, simuladores serão substituídos ao 
longo do projeto. Quando em largura, os simuladores serão 
substituídos verticalmente 
Validação da Integração – Abordagem Top-down 
28 
Validação da Integração – Abordagem Top-down 
No exemplo acima temos: 
 - através de profundidade: M1, M2, M5, M8, M6, M3, M7, M4. 
 - através de largura: M1, M2, M3, M4, M5, M6, M7, M8. 
M 1
M 3M 2 M 4
M 7M 6M 5
M 8
29 
Os componentes de níveis mais básicos da arquitetura do 
aplicativo são conjuntamente testados por controladores 
construídos para simular as interações dinâmicas e suas 
interfaces. 
À medida que evoluímos na integração, componentes reais 
substituem os controladores anteriores e novos controladores 
de testes são criados para simular as interfaces de um maior 
nível da arquitetura. 
Esses níveis de integração seguem até que não existam mais 
níveis a serem alcançados. 
Em cada nível de integração, existe um controlador criado 
exclusivamente para realizar os testes de interfaces entre os 
componentes do software. 
Validação da Integração – Abordagem Bottom-up 
30 
Validação da Integração – Abordagem Bottom-up 
Integração Nível 3 Integração Nível 2 Integração Nível 1 
S T 
S T 
S T 
S T 
S T 
S T 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
T S 
T 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
S 
T 
T 
S 
Componentes de Testware 
Componentes de Software 
31 
Representa uma combinação das abordagens Bottom-up e Top-
down, visando à utilização do que existe de melhor nelas: 
Validação da Integração – Abordagem Mista 
Bottom-up Top-down 
Principais 
Características 
• Permite que as unidades básicas (e 
talvez mais críticas) sejam testadas 
mais cedo. 
• As unidades podem ser integradas 
em vários ciclos, de acordo com a 
necessidade. 
• Maior ênfase na funcionalidade e no 
desempenho dos módulos. 
• O módulo principal é testado 
primeiro. 
• Apenas uma unidade é integrada 
a cada ciclo 
• Maior ênfase nos protótipos 
visuais. 
Vantagens • Não há necessidade de simuladores. 
• Maior facilidade de adaptar os testes 
aos recursos humanos disponíveis 
para executá-los. 
• Maior cobertura das unidades mais 
básicas e que atendem a aspectos 
críticos de processamento. 
• Erros na arquitetura são detectados 
mais cedo 
• Não há necessidades de 
controladores. 
• Com o módulo principal e alguns 
módulos se obtém um protótipo 
nas fases iniciais. 
• Erros de interfaces são 
detectados mais cedo. 
• Facilita a orientação dos testes 
de funcionalidades da aplicação. 
32 
Representa uma combinação das abordagens Bottom-up e Top-
down, visando à utilização do que existe de melhor nelas: (cont.) 
Validação da Integração – Abordagem Mista 
Bottom-up Top-down 
Desvantagens • Necessidade de controladores. 
• Muitas unidades devem ser 
integradas antes de se conseguir 
operacionalizar uma funcionalidade. 
• Erros nas interfaces visuais são 
detectados mais tarde. 
• Necessidade de simuladores. 
• Erros na arquitetura da solução 
são detectados tardiamente 
• Como s fases iniciais são muito 
prolongadas, torna-se difícil 
sincronizar o ritmo de 
desenvolvimento dos testes. 
Comentários • A produção do código avança mais 
rapidamente do que através da 
abordagem Top-down. 
• em geral esta abordagem é mais 
intuitiva. 
• Na prática, é muito difícil utilizar 
uma abordagem puramente Top-
down. 
33 
É um estágio mal compreendido e de difícil operacionalização. 
Validam a solução como um todo e a maior parte dos erros de 
funcionalidade já deve ter sido detectadas nos testes 
anteriores. 
Como estes testes contam com uma infraestrutura mais 
complexa de hardware, estes testes deveriam concentrar-se 
mais nos aspectos de performance, segurança, disponibilidade, 
instalação, recuperação e etc. 
Validação do Sistema 
 Atender os requisitos não funcionais da solução tecnológica. 
 Modelar uma arquitetura que atenda a todos os requisitos da 
solução. 
 Unidade Especificada 
ou Modificada 
 
 Garantir os requisitos não funcionais. 
 validar a infraestrutura a ser aplicada na solução. 
 validar interfaces com sistemas e dispositivos físicos. 
 
 Validação do Sistema 
7 
34 
Teremos ainda os testes de integração com sistemas externos 
(sem simulação), testes com dispositivos físicos (hardware), 
utilitários externos e operacionalização do ambiente 
tecnológico. 
O planejamento destes testes não é tarefa fácil, pois exige o 
perfeito entendimento dos requisitos não funcionais do 
software, que muitas vezes não são claramente descritos ou 
representam cenários extremamente complexos. 
Ex.: Processar um extrato em, no máximo , 30 segundos, 
existindo uma concorrência de acesso de 500 usuários 
simultâneos e com volume de dados da ordem de 2 milhões de 
correntistas e 350 milhões de movimentações bancárias. 
Validação do Sistema 
35 
Nessa fase, a falta de um método único de como planejar e 
operacionalizar os testes de requisitos não funcionais (testar 
uma carga de 100.000 registros ou validar o procedimento de 
recuperação de um backup) exige grande dose de criatividade 
por parte da equipe de testes. 
Uma das formas encontradas para organizar os testes é 
relacioná-los em categorias, com objetivos bem definidos e 
distintos. 
Esta organização facilitará o planejamento e a execução dos 
testes, uma vez que os cenários que possuem características e 
comportamentos semelhantes estarão agrupados em uma 
mesma categoria. 
Revisar 12 – categorias de teste de Software – aula 5 slide 16 
Validação do Sistema 
36 
Se nosso objetivo é validar os requisitos funcionais de toda uma 
aplicação, torna-se fundamental a execução de um conjunto de 
cenários de negócios que exigiria a interação de vários sistemas 
simultaneamente, o que inviabilizaria qualquer tentativa de 
realizar estes testes de forma integrada. 
Esta abordagem facilitaria a administração dos diversos 
cenários que estaremos simulando, evitando as dependências 
existentes. 
Cada sistema seria substituído por um simulador, que produziria 
as respostas necessárias para alimentar a execução do sistema 
que estamos testando, possibilitando a criação dos mais variados 
cenários, minimizando os esforços de planejamento e execução 
dos testes. 
Estes simuladores poderão ser aplicados nos testes unitário e de 
integração que também enfrentarão as mesmas dificuldades. 
Validação do Sistema – Abordagem isolada 
37 
Validação do Sistema – Abordagem Isolada 
 
Sistema 
Alvo 
 
Sistema 
D 
 
Sistema 
E 
<< Batch >> 
<< Batch >> 
<< On-Line >> 
<< On-Line >> 
 
Sistema 
F 
<< Batch >> 
<< Batch >> 
<< On-Line >> 
<< On-Line >> 
<< Batch >> 
<Simulador> 
 
Sistema 
A 
<Simulador> 
 
Sistema 
B 
<Simulador> 
 
Sistema 
C 
Simuladores nos testes de sistema deixam o ambiente mais gerenciável 
38 
Cada sistema que incluímosno contexto traz uma gama de 
dificuldades adicionais: lidar com um número maior de 
profissionais, disponibilizar uma infraestrutura, instalar e 
parametrizar o sistema, além de esbarrarmos com as 
dependências do sistema com outros aplicativos, o que torna 
esta atividade complexa e inviável. 
Em algumas situações, necessitamos validar condições que 
necessitam da interação real com as aplicações para que as 
medições sejam obtidas nas condições mais próximas do 
ambiente em produção, onde os simuladores poderiam “esconder” 
gargalos de processamento. 
Neste caso uma abordagem integrada forneceria um cenário 
mais favorável para aplicar os testes. É fundamental avaliar 
quando é necessário este testes definir quais integrações são 
relevantes (nitidamente as operações on-line). 
Validação do Sistema – Abordagem Integrada 
39 
Validação do Sistema – Abordagem Isolada 
 
Sistema 
Alvo 
 
Sistema 
D 
 
Sistema 
E 
<< Batch >> 
<< Batch >> 
<< On-Line >> 
<< On-Line >> 
 
Sistema 
F 
<< Batch >> 
<< Batch >> 
<< On-Line >> 
<< On-Line >> 
<< Batch >> 
Testes integrados identificam gargalos de processamento 
 
Sistema 
A 
 
Sistema 
B 
 
Sistema 
C 
40 
É o último processo formal de detecção de erros no sistema, 
antes da sua disponibilização no ambiente de produção. 
O software é disponibilizado para os usuários com o objetivo 
de estes validarem todas as funcionalidades requisitadas no 
início do projeto. 
Os usuários terão oportunidade de interagir com um sistema 
completo e exaustivamente testado pela equipe de testes. 
Validação do Aceite 
 Disponibiliza a solução para os usuários validarem o software e 
suas funcionalidades. 
 Estratégia de implantação gradativa da solução 
 Disponibiliza a Solução 
 
 Última etapa para detectar erros na solução. 
 Permite aos usuários validarem o software (Alpha-teste). 
 Permite realizar teste no ambiente do cliente (Beta-teste) 
 
 Validação do Aceite 
7 
41 
Se ao chegar nesta etapa e a solução ainda apresentar muitas 
falhas, é sinal de que os processos de detecção de erros não 
estão sendo efetivos, indicando falhas nos processos anteriores. 
Assim como nos testes de sistema, os procedimentos de aceite 
deverão ser realizados a cada ciclo de implementação da solução, 
permitindo correções antecipadas de determinados pontos que 
não foram adequadamente atendidos pelo software. 
Como esta é as última oportunidade efetiva de detectar falhas, 
podemos empregar o aceite como uma estratégia para reduzir 
riscos de uma implantação maciça, na qual um erro vital não 
detectado pode comprometer a imagem da solução toda. 
Dessa forma, podemos dividir o aceite em três momentos: o 
Aceite formal, Alpha-teste e o Beta-teste. 
Validação do Aceite 
42 
Validação do Aceite 
Estágios do processo de aceite de um software 
 
Aceite 
Formal 
Implantação Total 
Todos os clientes 
recebem o software 
devidamente testado. 
Implantação BETA 
Clientes selecionados 
recebem o software 
para operar em seu 
ambiente. 
Clientes planejam e 
realizam os testes do 
software. 
Aceite Formal 
 
ALPHA 
Teste 
 
BETA 
Teste 
 
Todos 
Clientes 
Clientes são convidados 
a operar o software no 
fornecedor. 
Implantação ALPHA 
Aceite da Solução Distribuição 
43 
O processo de aceite torna-se uma continuação natural do 
testes de sistema. 
Aproveitando-se toda a infraestrutura existente no ambiente de 
homologação (inclusive simuladores), o aceite formal segue 
rigoroso planejamento das atividades de testes, cabendo aos 
próprios usuários determinarem o que deverá ser testado e 
validar se os requisitos foram adequadamente atendidos. 
Na maior parte das vezes,restringe-se apenas às funcionalidade 
de negócio, deixando outros requisitos de fora. 
É muito empregado em projetos que são desenvolvidos para 
atender a um grupo de empresas, possibilitando a criação de um 
comitê que atestará a aderência do software às necessidades do 
grupo. 
Validação do Aceite – Aceite Formal 
44 
Os clientes são convidados a operar o software dentro de um 
ambiente simulado, localizado dentro da empresa criadora do 
software, porém fisicamente separada do ambiente de 
desenvolvimento. 
Os usuários poderão interagir diretamente com a aplicação, 
simulando operações e transações de todo os tipos. 
Cabe ao profissionais que estão gerenciando o processo de 
aceite garantir que todos os usuários convidados estão 
exercitando todos os pontos mais críticos da aplicação. 
Sua principal característica é a ausência de um formalismo no 
processo de validação, pois o objetivo é capturar a naturalidade 
dos próprios usuários e dar a eles a possibilidade de realizar 
seus próprios testes. 
Validação do Aceite – Alpha-teste 
45 
Os clientes são convidados a operar o software utilizando suas 
próprias instalações para que possa ser submetido às mesmas 
situações do dia-a-dia. 
Não se trata de uma implantação definitiva, mas sim uma 
implantação em paralelo e pode ocorrer até que o usuário sinta-
se seguro em realizar mudança definitiva. 
Durante a sua execução, o cliente contará com o 
acompanhamento direto da empresa fornecedora para que 
corrija qualquer eventual falha. 
Os clientes que participarão desse estágio deverão ser aqueles 
que executam toda ou grande parte das funcionalidades. 
Pode ser planejado em vários ciclos que englobam um número 
cada vez maior de usuários até que aceite seja efetivo e o 
processo de implantação do software seja iniciado. 
Validação do Aceite – Beta-teste