ResumoLivroBaseConhecimentoTesteSoftware

Prévia do material em texto

Capítulo 2 – Processo de teste
1.1. Ciclo de vida de desenvolvimento de software (CVDS)
O CVDS é formado pelas seguintes fases:
• Estudo preliminar;
• Análise de requisitos; Também nesta fase são levantadas as primeiras informações necessárias para a realização 
dos testes, tais como as regras para testar os requisitos e os pré-requisitos que permitem tal realização. Inclui-se 
ainda o Plano de Teste, que contempla o planejamento das principais atividades de teste, bem como recursos e 
os prazos para realizá-los.
• Desenho do sistema;
• Construção; Nos programas preparados, devem ser aplicados os testes unitários conforme os planos de teste e 
os casos de teste preparados.
• Implantação; Nesta fase são efetuados os testes de integração e sistema. Finalmente o sistema deve ser aceito 
pelo usuário ou cliente.
• Operação.
1.2. Conceito “V” de teste
O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de 
desenvolvimento.
Os ciclos de vida de testes e de desenvolvimento são totalmente interdependentes, mas o ciclo de teste é 
dependente da conclusão dos produtos das atividades de desenvolvimento.
As atividades do ciclo de vida de teste devem ser realizadas por um grupo formalmente definido para tal. Esse 
grupo pode ser :
• Interno; formado por profissionais pertencentes ao projeto ou por uma área especial para as atividades de 
teste.
• Externo; Formado por profissionais especializados em teste de uma empresa externa.
No conceito de ciclo de vida de testes, os processos de desenvolvimento e teste têm início simultaneamente: a 
equipe que desenvolve o sistema inicia o processo de desenvolvimento do sistema, e a equipe que está 
conduzindo os testes começa o planejamento do processo de teste.
A equipe de teste usa os mesmos requisitos com o propósito de testar o sistema.
No conceito “V” de teste, os processos de FAZER e CONFERIR convergem do início até fim do projeto. O grupo 
que FAZ trabalha com o objetivo de implementar o sistema, e a equipe que CONFERE, simultaneamente, executa 
procedimentos de teste visando minimizar ou eliminar riscos.
1.3. Processo de teste de software
Baseado no conceito “V” de teste, o processo de teste de software tem como atividades de testes, onze passos a 
serem realizados paralelamente às atividades do desenvolvimento. Os primeiros cinco passos usam técnicas de 
verificação como principal meio de avaliar a correção dos produtos do desenvolvimento de software. Os outros 
passos usam técnicas de validação para testar o software durante as atividades que vão desde construção até a 
implantação. A verificação e validação devem ser usadas para o desenvolvimento e a manutenção de software.
Os passos do processo de teste são:
• Acesso ao Plano de Desenvolvimento; Pré-requisito para a construção do Plano de Teste.
• Desenvolvimento do Plano de Teste; A preparação do Plano de Teste deve seguir os mesmos padrões da 
preparação do plano de desenvolvimento.
• Inspeção ou teste dos requisitos do software; Avaliação dos requisitos do software por meio do uso de técnicas 
de verificação.
• Inspeção ou teste de desenho do software; Avaliação do desenho – interno ou externo – do software através do 
uso de técnicas de verificação.
• Inspeção ou teste da construção do software;
• Execução dos testes; Envolve testar o código em estado dinâmico.
• Teste de aceitação; Avaliação da aplicabilidade e usabilidade do software pelos usuários.
• Informação dos resultados dos testes; informação dos defeitos, etc.
• Teste de instalação do software; Visa verificar a interoperabilidade com o sistema operacional, etc.
• Teste de mudança no software; Cobre mudanças que ocorrem em todo processo de desenvolvimento e as que 
vão ocorrer após a implantação do software.
• Avaliação da eficácia dos testes; Responsável pelas melhorias no processo de teste.
1.4. Ciclo de vida do processo de teste
O ciclo de vida do processo de teste abordado é composto por diversas etapas ou fases, sendo quatro delas 
seqüenciais ou em cascata e duas paralelas. Este modelo é baseado na metodologia TMap. Este modelo é 
conhecido como Modelo 3PX3E.
• Procedimentos Iniciais;
• Planejamento;
• Preparação;
• Especificação;
• Execução e
• Entrega.
1.4.1. Procedimentos iniciais
Nesta etapa deverá ser aprofundado um estudo dos requisitos do negócio que dará origem ao sistema de 
informação a ser testado, de modo a garantir que o mesmo esteja completo e sem nenhuma ambigüidade. No 
final desta etapa é elaborado o GOT – Guia Operacional de Teste.
1.4.2. Planejamento
Consiste em elaborar a Estratégia de Teste e o Plano de Teste a ser utilizados de modo a minimizar os principais 
riscos do negócio e fornecer os caminhos para as próximas etapas.
A atividade de planejamento deve permanecer até a conclusão do projeto.
1.4.3. Preparação
Nesta etapa, o objetivo básico é preparar o ambiente de teste (equipamentos, pessoal, ferramentas de 
automação, hardware e software), para que os testes sejam executados corretamente.
A atividade de preparação deve permanecer até a conclusão do projeto.
1.4.4. Especificação
Os objetivos básicos desta etapa são:
• Elaborar/revisar casos de teste;
• Elaborar/revisar roteiros de test.
Os casos de teste e os roteiros de teste devem ser elaborados dinamicamente durante o decorrer do projeto de 
teste.
1.4.5. Execução
Os testes deverão ser executados de acordo com os casos de teste e os roteiros de teste.
Devem ser usados scripts de teste, caso seja empregada alguma ferramenta de automação de testes.
1.4.6. Entrega
Nesta etapa o projeto de teste é finalizado.
1.5. Técnicas de teste
1.5.1. Teste Estrutural versus Teste funcional
Teste Funcional; Os testes funcionais do sistema são desenhados para garantir que os requisitos e as 
especificações do sistema tenham sido atendidos.
Teste Estrutural; Garante que os softwares e os programas sejam estruturalmente sólidos e que funcionem no 
contexto técnico onde serão instalados. Isto implica (1) testar a robustez e o funcionamento da estrutura do 
programa; (2) testar o funcionamento de todos os aspectos da estrutura em toda a sua extensão.
As técnicas para esse tipo de teste são desenhadas não para garantir que o sistema seja funcionalmente correto, 
e sim para que ele seja estruturalmente robusto.
Técnicas de Teste Funcional 
Testes de Requisitos;
Testes de Regressão;
Testes de Tratamento de Erros;
Testes de Suporte Manual;
Testes de interconexão com outros softwares;
Testes de Controle;
Testes Paralelos;
Técnicas de Teste Estrutural
Testes de Estresse;
Testes de Execução;
Testes de Recuperação (contingência);
Testes de Operação;
Testes de Conformidade;
Testes de Segurança;
1.5.1.1. Técnicas de Teste Estrutural
Teste de Estresse
O objetivo desse teste é avaliar o comportamento do software sob condições críticas, tais como restrições 
significativas de memória, de área de disco e de CPU. Os testes de estresse visam também identificar o 
comportamento do software quando submetido a variados volumes de dados e acima das médias esperadas.
Nos testes de estresse, o sistema deve ser executado como seria de fato executado no ambiente de produção.
Os testes de estresse são empregados quando existe incerteza quanto à quantidade ou ao volume de trabalho 
que a aplicação pode tratar sem falhas.
Testes de Execução
Os testes de execução são desenhados para avaliar o comportamento do sistema no ambiente de produção e 
verificar se são atendidas as premissas de desempenho estabelecidas.
O teste de execução é empregado para determinar se o sistema pode atingir os critérios de desempenho 
específicos.
• Determinar o desempenho da estrutura do sistema;
• Verificar o nível de utilização do hardware e software;
• Determinar o tempo de resposta das transações on-line;
• Determinar o tempo de processamento das transações.
Os testes de execução devem ser empregados no início do processo de desemvolvimento.
Testes de Recuperação (Contingência)
A recuperação é a capacidade de reiniciar operaçõesapós a perda da integridade de uma aplicação.
O teste de recuperação não só verifica o processo de recuperação como também a eficácia das partes 
componentes do processo.
• Manter backup dos dados;
• Armazenar os dados do backup em local seguro;
• Documentar os procedimentos de recuperação;
• Etc.
Testes de Operação
Os testes de operação são desenhados principalmente para estabelecer se o sistema é executável durante a 
operação normal. Os objetivos são:
• Determinar se a documentação da operação está completa;
• Avaliar se o treinamento dos operadores está completo;
• Garantir que mecanismos de suporte foram preparados e funcionam de modo adequado. Ex: Scheduling.
• Etc.
Testes de Conformidade
Os testes de conformidade verificam se a aplicação foi desenvolvida de acordo com os padrões, procedimentos e 
guias de TI. Pode ser mais importante executar testes de conformidade durante a fase de requisitos.
Os testes de conformidade são realizados para garantir a conformidade com as metodologias e encorajar e 
auxiliar os profissionais de TI a adotá-las. Os objetivos são:
• Verificar se as metodologias de desenvolvimento de software e de manutenção são seguidas;
• Garantir a conformidade aos padrões, procedimentos e guias de TI;
• Avaliar se a documentação do sistema de aplicação é racional e está completa.
Teste de Segurança
São um processo necessário para garantir a confidencialidade das informações e a proteção dos dados contra 
acesso indevido de terceiros.
Os testes de segurança são desenhados com o intuído de avaliar a adequação dos procedimentos de proteção e 
contramedidas projetadas.
Os testes de segurança visam descobrir defeitos muito difíceis de identificar.
Entre os objetivos temos:
• Determinar se foi dada atenção adequada á identificação de riscos de segurança;
• Determinar se foi preparada uma definição de regras de acesso e se estas foram implementadas de acordo com 
as regras;
• Etc.
Os testes de segurança podem ser divididos em segurança física e lógica. A física trata da invasão por pessoas 
não autorizadas, ao passo que a lógica trata do uso dos recursos computacionais e de comunicações para acessar 
indevidamente as informações.
Os testes de segurança devem ser empregados quando a informação e/ou o ativo protegido pelo sistema de 
aplicação são de valor significativo para a organização e realizados antes e depois de o sistema ser passado para 
a produção.
1.5.1.2. Técnicas de Testes Funcionais
Testes de Requisitos
Os testes de requisitos visam verificar se o sistema executa corretamente as funcionalidades e se é capaz de 
sustentar essa correção após sua utilização por um período de tempo contínuo.
Os objetivos dos testes consistem em verificar se:
• Os requisitos dos usuários estão implementados;
• A correção é mantida por períodos prolongados de tempo;
• O processamento da aplicação está em conformidade com as políticas e os procedimentos da organização.
Os testes de requisitos são realizados basicamente através da criação de condições de testes e checklists de 
funcionalidades. Recomenda-se que as condições de teste sejam derivadas diretamente dos requisitos.
Teste de Regressão
Os testes de regressão voltam a testar segmentos já testados após a implementação de uma mudança em outra 
parte do software.
Sempre que mudanças são efetuadas num segmento de código, problemas podem ocorrer em outros segmentos 
já testados. Desse modo, entre os objetivos dos testes de regressão temos:
• Determinar se a documentação do sistema permanece atual;
• Determinar se os dados e as condições de teste permanecem atuais;
• Determinar se as funções previamente testadas continuam funcionando corretamente após a introdução de 
mudanças no sistema.
O teste de regressão deve ser executado sempre que o software sofre uma alteração.
Os testes de regressão são empregados quando é muito alto os riscos de novas mudanças afetarem áreas não 
alteradas da aplicação.
Teste de Tratamento de Erros
Os testes de tratamento de erros determinam a capacidade do sistema de tratar apropriadamente transações 
incorretas.
Os objetivos específicos são:
• Determinar se todas as condições de erro esperadas são reconhecidas pelo sistema;
• Determinar se foi atribuída responsabilidade para processar os erros identificados;
• Determinar se é mantido um controle sobre os erros durante o processo de correção.
Um ótimo método para desenvolver testes de tratamento de erros é realizar um brainstorm com pessoas de Ti, 
da área usuária e de auditoria, procurando identificar o que pode dar errado no sistema.
Teste de Suporte Manual
• Verificar se os procedimentos de suporte manual estão documentados e completos;
• Determinar se as responsabilidades pelo suporte manual foram estabelecidas;
• Determinar se o suporte manual e o segmento automatizado estão interligados apropriadamente;
Os testes manuais envolvem a avaliação da adequação do processo e, sua execução que pode ser feita 
juntamente com o teste normal do sistema.
Testes de Interconexão
Estes testes são desenhados para garantir que a interconexão entre software de aplicação funcione 
corretamente. Entre os objetivos temos:
• Determinar se os parâmetros e dados são transferidos corretamente entre os softwares;
• Garantir o momento certo de execução e a existência de coordenação das funções entre os softwares;
• Determinar se a documentação pertinente é correta e completa.
Testes de Controle
Os testes de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado 
conforme sua intenção. Os objetivos são garantir que:
• Os dados estejam completos e corretos;
• As transações sejam autorizadas;
• A manutenção das informações de trilha de auditoria seja realizada;
• Os processamentos sejam eficientes, eficazes e econômicos;
• O processamento atenda às necessidades dos usuários.
O teste de controle pode ser considerado um sistema dentro do outro.
Testes Paralelos
O teste paralelo serve para determinar se os resultados de um novo software de aplicação são consistentes com 
o processamento do antigo sistema ou da antiga versão do sistema.
Objetivos:
• Assegurar que a nova versão do software de aplicação execute corretamente;
• Demonstrar consistências e inconsistências entre duas versões do mesmo software de aplicação.
1.5.2. Atributos de qualidade
Os atributos de qualidade a serem atendidos devem também fazer parte do Plano de Teste.
1.5.2.1. Procedimentos para identificar a importância dos fatores de qualidade
Existem diversas técnicas para identificar os fatores de qualidade do software. Sugerimos que sejam seguidos os 
passos adiante:
• Considerar as características básicas da aplicação;
• Considerar as implicações no ciclo de vida;
• Realizar uma avaliação de custo versus benefício da lista de fatores de qualidade;
• Identificar os fatores de qualidade mais importantes;
• Fornecer explicações para as escolhas.
Fatores de qualidade:
• Correção; satisfaz as especificações e atende aos objetivos do usuário;
• Confiabilidade; executa as funções programadas com a precisão requerida;
• Eficiência; A quantidade de recursos computacionais e de dados para executar uma função.
• Integridade; o acesso ao software ou aos dados por pessoa autorizada pode ser controlada;
• Usabilidade; esforço requerido para aprender e operar o sistema;
• Manutenibilidade; esforço requerido para localizar e corrigir um erro;
• Testabilidade; esforço requerido para testar um programa;
• Flexibilidade; esforço requerido para modificar um programa;
• Reusabilidade; um programa pode ser usado em outra aplicação;
• Interoperabilidade; esforço requerido para juntar um sistema com outro;
• Portabilidade; facilidade do software operar em vários ambientes.
Os fatores de qualidade não devem ser confundidos com as características ou subcaracterísticas de qualidade da 
norma ISO 9126-1. Aqui trata-se apenas de uma abordagem didática.
1.5.3. Garantia da qualidade versus Controle da qualidade
Métodos de qualidade podem ser segmentadosem duas categorias: métodos preventivos e métodos de 
detecção. Essa distinção é o mecanismo usado para diferenciar atividades de garantia da qualidade das 
atividades de controle da qualidade.
• Garantia da qualidade; A garantia da qualidade é um conjunto sistemático e planejado de atividades, 
necessárias para proporcionar a confiança adequada de que produtos e serviços estarão em conformidade com 
requisitos especificados e atenderão às necessidades do usuário.
• Controle de qualidade; O controle de qualidade é um processo pelo qual a qualidade do produto é comparada 
com os padrões aplicáveis; quando uma não-conformidade é detectada, são tomadas as devidas providências.
Tanto a garantia da qualidade quanto o controle da qualidade se distinguem da função de auditoria interna. A 
auditoria interna é uma atividade independente dentro da organização, tem o propósito de revisar as operações 
e é uma tarefa de gerenciamento.
A qualidade tem duas definições de trabalho:
• Do ponto de vista do produtor, a qualidade é o comprimento de requisitos.
• Do ponto de vista do consumidos, é o atendimento às necessidades do cliente.
Na visão do CMMI, o propósito da Garantia da Qualidade de Software (GQS) é fornecer ao gerenciamento a 
visibilidade da eficácia, no sentido de produzir um software de qualidade. A GQS envolve rever e auditar partes 
do produto, de maneira a verificar se estão de acordo com os padrões definidos e fornecer os resultados dessas 
revisões para os implicados no processo.
A garantia da qualidade é uma atividade que estabelece e avalia o processo que gera os produtos. Caso não 
exista processo, não há razão para a garantia da qualidade.
As atividades de controle da qualidade se concentram na identificação de defeitos em produtos. Essas atividades 
começam no início do processo de desenvolvimento do software, com revisão dos requisitos, e continuam até 
que o teste do aplicativo esteja completo e o sistema esteja implementado.
• O controle da qualidade
o Está relacionado a um produto ou serviço específico;
o Verifica se um produto ou serviço específico tem um atributo específico;
o Identifica defeitos com o propósito principal de corrigi-los;
o É responsabilidade da equipe/do funcionário.
• A garantia da qualidade
o Ajuda a estabelecer processos;
o Determina programas de medida para avaliar processos;
o Identifica fraquezas em processos e os aperfeiçoa;
o É uma responsabilidade de gerenciamento;
o Está relacionada com todos os produtos que serão gerados por um processo;
o Avalia se o controle da qualidade está funcionando.
FURPS
Uma metodologia muito usada no mercado é a FURPS. Uma metodologia que faz parte do RUP.
• Funcionalidade (Functionality);
• Usabilidade (Usability);
• Confiabilidade (Reability);
• Desempenho (Performance);
• Suportabilidade (Suportability).
Funcionalidade
Para atender a categoria da funcionalidade, o software em teste tem de estar de acordo com a especificação 
funcional.
Testes que podem ser aplicados:
• Teste funcional;
• Teste de regressão (smoke test);
• Teste de volume;
• Teste de segurança.
Usabilidade
Representa a facilidade de uso do sistema pelos usuários.
Testes que podem ser aplicados:
• Teste de interface;
• Teste de usabilidade.
Confiabilidade
Garante a confiabilidade do sistema, a permanência de operação, a integridade dos dados, a confiabilidade da 
estrutura de dados e também da aplicação.
Testes que podem ser aplicados:
• Teste de integridade;
• Teste de estrutura;
• Teste de estresse;
• Smoke teste.
Desempenho
Garante a velocidade de processamento da informação.
Testes que podem ser aplicados:
• Teste de avaliação de desempenho ou benchmark;
• Teste de contenção;
• Teste de carga;
• Perfil de desempenho.
Suportabilidade
Representa a capacidade do programa de funcionar em diversos ambientes diferentes. 
Testes que podem ser aplicados:
• Teste de configuração;
• Teste de instalação.
Capítulo 4 – Análise de Riscos
1.1. Definição de risco
Ao avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrências poderão acarretar perdas 
para empresa. Nem sempre é possível aliar um risco a uma perda – um risco presente nem sempre vai gerar uma 
perda. Em resumo, podemos dizer que o risco é a possibilidade de ocorrência de uma perda para empresa.
Segundo o dicionário Houaiss, Risco é a “probabilidade de insucesso, de malogro de determinada coisa, em 
função de acontecimento eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos 
interessados.”
O que leva um risco a potencialmente se tornar uma perda é a ameaça de sua ocorrência.
As ameaças podem ser reduzidas através de mecanismos de controle. Controlar as ameaças é uma das maneiras 
de evitar sua ocorrência.
Quando os meios de controle são insuficientes ou inadequados para administrar a ocorrência de um risco, 
surgem então as vulnerabilidades.
Análise de riscos é o processo de avaliar os riscos, ameaças , controles e vulnerabilidades.
Conceito usados em gerenciamento de riscos
Risco O risco é uma perda em potencial para organização.
Análise de Riscos É uma avaliação dos recursos de informação de uma organização, seus controles e suas 
vulnerabilidades.
Ameaça Capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação
Vulnerabilidade É uma falha no desenho, implementação ou operação que permite a concretização de uma 
ameaça.
Controle É uma maneira de tentar reduzir as causas dos riscos, evitando desse modo sua ocorrência ou, pelo 
menos reduzindo sua freqüência de ocorrência.
1.2. Riscos decorrentes da tecnologia da informação
O risco é, portanto, a materialização de uma ameaça. A análise de risco tenta identificar os riscos e medir seu 
nível de severidade. Desse modo, uma ameaça é a possível ocorrência de um evento que causa danos.
Os riscos presentes na área de tecnologia da informação podem ser gerados por ameaças físicas ou decorrentes 
da ação de pessoas.
O trabalho do audito de sistemas é procurar e identificar esses riscos, estimar sua severidade e montar processos 
de teste de auditoria para mapear os possíveis riscos derivados de sua ocorrência.
1.3. Riscos relativos ao teste de software
Em geral, os testadores tentam cobrir as partes mais importantes do software, aquelas nas quais se concentrarão 
os maiores riscos para o negócio. No Plano de Testes, esses riscos receberão os maiores níveis de prioridade.
Ao fazer a análise de riscos, devemos levar em conta o seguinte:
• A probabilidade de ocorrência do risco.
• O impacto e a perda associada a esse risco.
Esses dois pontos deverão ser levados em conta para definição da cobertura dos testes.
Podemos afirmar que o total de testes a ser executado está diretamente ligado ao total de riscos envolvidos.
1.4. Riscos do Processo de teste
Dentre os possíveis riscos para o processo de teste, a ser identificados pelo gerente de teste, destacamos:
• Orçamento; insuficiente para execução dos serviços de teste;
• Qualificação da equipe de teste; equipe sem treinamentos;
• Ambiente de teste; ambiente de teste mais próximo do ambiente de produção;
• Ferramentas; faltas de ferramentas necessárias para sucesso de um tipo de teste;
• Metodologias; falta de metodologia adequada e condizente com o desenvolvimento;
• Cronograma de recebimento de programas para teste e cronograma para devolução; Caso os prazos sejam 
exíguos. Negociar.
• Testware; ter metodologia para guardar a documentação de teste para uso futuro;
• Novas Tecnologias; uso de tecnologias não dominadas pela equipe de teste.
1.5. Determinação da magnitude dos riscos
O problema muitas vezes, consiste em determinar como classificar o risco e qual o custo de criação de um 
controle que evite a ocorrência desse risco. O controle de risco custa dinheiro, é necessário fazer uma análise de 
custo versus benefício para determinar se vale a pena investir em algum tipo de controle de risco.
Em resumo, quando se fala em risco, existe uma relação entre o custo da ocorrênciado risco e o custo dos 
mecanismos de controle para evitar que o risco ocorra.
O QAI estabelece que um risco pode ser determinado por quatro maneiras, descritas a seguir:
• Intuição ou discernimento Um técnico experiente da área de testes usa sua intuição, aliada a sua experiência 
para dizer que a ocorrência de um dado risco pode custar mais caro que os controles necessários para evitá-lo.
• Consenso; Trata-se de um consenso entre a equipe de que aquele risco te um nível elevado de severidade.
• Fórmula de risco; Existe dados financeiros que permitem medir o custo da perda pela ocorrência do risco.
• Estimativas de perdas anuais; Este caso é uma combinação do consenso com a fórmula de risco.
Outras definições de riscos e avaliação de riscos:
Avaliar Riscos: Avaliar os danos para o sucesso do negócio causados pelos defeitos não detectados antes da 
operação do software e que poderão ocorrer quando o software estiver sendo usado.
Risco: possibilidade de falha X prejuízo causado pela falha
1.6. Riscos baseados nas características de qualidade
O risco de ocorrência de defeitos é maior num software mal testado.
Considerando as características de qualidade da norma ISO 9126-1, podemos relacionar os seguintes testes.
• Funcionalidade; Teste de Funcionalidade;
• Confiabilidade; Teste de Estresse;
• Usabilidade; Teste de Usabilidade;
• Eficiência; Teste de Desempenho;
• Manutenibilidade; Teste Caixa-Branca, etc.
• Portabilidade; Teste de Produção, Alfa, etc.
1.6.1. Outros riscos do projeto de testes
• Ausência do cronograma detalhado do projeto de desenvolvimento;
• Datas finais dependentes da execução dos testes;
• Bases de testes não disponíveis nas datas programadas;
• Baixa qualidade da base de testes;
• Falta de métrica adequada para medir o sistema e o processo de teste;
• Disponibilidade de pessoal para testes;
• Crescimento do sistema;
• Disponibilidade do ambiente de teste.
Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente.
1.7. Controle dos riscos
A melhor maneira de controlar um risco é tentar identificá-lo na análise de requisitos de negócio, no momento 
em que os requisitos de teste são criados, pois assim haverá tempo hábil para que algumas ações possam ser 
planejadas enquanto o projeto segue seu curso normal.
Duas abordagens que podemos usar são:
• Se aumentarmos o esforço de teste, a tendência será minimizar os riscos de ocorrência de defeitos.
• Tomar como base o Princípio de Pareto de que 20% do software é responsável por 80% de suas 
funcionalidades.
1.8. Gerenciamento dos riscos dos projetos – Conforme PMBOK
Segundo o PMI, o gerenciamento de risco é um processo sistemático de identificar e analisar os riscos do projeto, 
bem como responder a eles.
Fluxo de atividades do gerenciamento de riscos.
O modelo PMI divide o gerenciamento de Riscos nos seguintes processos:
• Planejamento do Gerenciamento de Riscos;
• Identificação dos Riscos;
• Análise Qualitativa dos Riscos;
• Análise Quantitativa dos Riscos;
• Planejamento de Resposta a Riscos;
• Controle e Monitoração de Riscos.
O PMI acrescenta uma terminologia que não havíamos abordado anteriormente, pois, segundo o instituto, os 
riscos podem ser tanto ameaças ao sucesso do projeto quanto oportunidades de implementar melhorias.
1.8.1. Identificação dos riscos
Consiste em listar todos os riscos do projeto de teste. Pode ser:
• Através de reuniões com os técnicos envolvidos no projeto;
• Listas de riscos publicadas;
• Base de informações de projetos anteriores.
1.8.2. Análise de riscos
De acordo com o PMI os riscos devem ser analisados qualitativa e quantitativamente.
A análise qualitativa dos riscos é feita com base na definição da probabilidade de ocorrência do risco e de sua 
severidade.
Muitas vezes a análise quantitativa PE realizada em conjunto com análise qualitativa. O objetivo da análise 
qualitativa é analisar numericamente a probabilidade de cada risco, de modo que seja possível, depois definir seu 
tratamento. Essa análise é feita dentro do contexto global do projeto.
1.8.3. Planejamento dos riscos
O planejamento dos riscos envolve a escolha dos planos para responder aos riscos. É realizado de acordo com o 
caminho de melhor custo-benefício.
Os seguintes planos devem ser elaborados:
• Plano de Mitigação;
• Plano de Contingência.
1.8.4. Controle e monitoração dos riscos
Controlar e monitorar riscos é acompanhar a evolução dos riscos no desenvolvimento dos projetos, o que envolve 
a avaliação permanente dos riscos e, caso algum já tenha ocorrido, como funcionou a resposta atribuída a sua 
ocorrência.
Capítulo 5 - Planejamento dos Testes
 
Ambiente, técnicas, processo, análise de riscos – servirão de alicerce para o planejamento dos testes.
 
O documento básico do planejamento de testes é o PLANO DE TESTES.
 
No Plano de Testes define-se o nível de cobertura dos testes e a abordagem dos testes.
 
Plano de Teste deve ter como base os requisitos da aplicação e os requisitos de teste.
 
O Plano de Teste descreve como o teste deverá ser executado e traça uma linha mestra a ser seguida.
 
O Plano de Teste é um acordo formal entre testadores, desenvolvedores e usuários.
 
O teste de software é o processo que visa executar o software de maneira controlada, com o objetivo de avaliar 
seu comportamento de acordo com o que foi especificado.
 
A execução dos testes é considerada um tipo de VALIDAÇÃO.
 
Os testes caixa-preta cobrem as funcionalidades, mas não todo código do programa, portanto, é impossível 
testar completamente todo sistema e afirmar que ele está livre de defeitos.
 
Segundo a estimativa de Beizer, a média do número de defeitos em programas liberados para testes e de 1 a 3 a 
cada 100 instruções executáveis.
 
CMMI nível 3
 
Validação; Executar Testes
Verificação; Revisão, inspeção técnica
Análise de Riscos;
 
Testes exaustivos só são justificados em sistemas críticos em que a taxa de defeitos deve ser próximo de zero, 
levando em conta que testar exaustivamente um software aumenta substancialmente e custo do projeto de 
teste.
 
O planejamento estabelece o que vai ser testado, durante quanto tempo e quando os testes serão 
interrompidos.
 
A metodologia TMAP (Matin Pol, Teunissem e Veernendaal) definem um docuemto chamado Estrutura de Teste, 
elaborado antes do Plano de Teste.
 
TMAP = Estratégia de Testes
QAI = Estrutura de Testes
 
1. Por que os Planos de Testes são importantes?
 
A partir do momento que o teste passa a ser tratado como um projeto ou processo e não mais como uma etapa 
no processo de desenvolvimento, precisamos planejá-lo.
 
O Plano de Teste é uma maneira de documentar o projeto de teste.
 
O Plano de Teste permite que os testes sejam repetidos e controlados e define o nível de cobertura segundo o 
qual os elementos mais críticos do software serão testados com prioridade e com cobertura mais ampla. Por 
elementos críticos, consideramos aqueles classificados pela análise de riscos ou caracterizado pelo cliente.
 
O Plano de Teste é elaborado nos moldes do padrão definido pelo IEEE 829. Mas, nem o IEEE, nem o QAI falam 
sobre estimativas e métricas de teste em seus modelos.
 
O IEEE define a seguinte hierarquia entre os documentos de teste:
 
• Plano de Teste;
• Estrutura de Teste;
• Casos de Teste e
• Procedimentos de Teste.
2. Desenvolvimento do Plano de Teste
 
Escopo; O Escopo define exatamente a extensão do projeto de teste, até mesmo suas interfaces com outros 
softwares.
 
Custo; É preciso medir o tamanho do projeto de teste para saber quanto ele vai custar. Como métricas de teste 
temos: Análise de Pontos de Teste ou Pontos de Caso de Teste.
 
Tempo; A estimativa de tempo - , e, conseqüentemente, a elaboração do cronograma – está ligada diretamente 
ao tamanho do projeto, que por sua vez, servirá de base para o cálculo dos custos.
 
Qualidade; É acompanhada através de um programa de indicadores a ser implementado no decorrer do projeto.
 
Comunicação; A função dessa “atividade” é garantir a maneira como as partes envolvidasno projeto receberão as 
informações de que precisas para tomar decisões. Além disso, é necessário prever no projeto como e com que 
freqüência serão feitas as reuniões de controle. Relatórios de defeitos servirão de elemento de comunicação 
entre equipes de teste e de desenvolvimento.
 
Integração; Descrever a integração com os projetos de desenvolvimento e até mesmo com outros projetos de 
teste.
 
Recursos Humanos; Definição de recursos humanos envolvidos em cada etapa do projeto. Definir funções e 
responsabilidades.
 
Riscos; O projeto de teste implica seus riscos específicos. Não misturar os riscos do projeto de teste com os riscos 
do negócio.
 
Suprimentos; Aquisição de software e ferramentas.
3. Significado do Plano de Teste
 
Segundo o QAI, o Plano de teste toma aproximadamente um terço do projeto de teste.
 
Problemas levantados pelo QAI que podem afetar um projeto de testes/plano de teste:
 
• Falta de treinamento; a equipe independente de testes de vê conhecer o processo de teste, seu ciclo de vida, 
metodologia usada e também técnicas específicas de teste.
 
• Desenvolvedores versus testadores; Os desenvolvedores não gostam que outras pessoas apontem seus erros, e 
os testadores tendem a apontar esses erros de maneira sarcástica. Brigas internas são ruins para o sucesso do 
projeto.
 
• Falta de ferramenta de teste; realizar testes de regressão manualmente.
 
• Falta de apoio da gerência; Além do suporte financeiro, algumas decisões não podem ser tomadas por técnicos.
 
• Falta de envolvimento dos usuários e dos clientes; Os usuários e clientes precisam estar envolvidos no projeto 
de teste, inclusive na elaboração do Plano de Teste.
 
• Falta de tempo para testar; Os desenvolvedores esgotam o prazo e transferem a pressão para a equipe de 
teste.
 
• Quem testa é a equipe de testa; por existir uma equipe de teste independente, os desenvolvedores não se 
preocupam em realizar os testes unitários e de integração ou o fazem de maneira incipiente.
 
• Alterações rápidas; O uso de ferramentas RAD que geram alterações rápidas e que nem sempre é possível 
testar com a mesma agilidade. Fazer uso de ferramentas.
 
• Os testadores são sempre os culpados; Quando os testadores acham muitos defeitos os desenvolvedores 
reclamam se deixam passar defeitos sérios também há reclamações.
 
• Os testadores precisam aprender a dizer não;
4. Tarefas para construir um Plano de Teste
 
A lista de tarefas e sub-tarefas para se construir um plano de teste é proposta pelo QAI 
• Montar a equipe de teste;
•Testar usando a equipe de desenvolvimento como equipe de teste
•Testar usando equipes independentes de teste e
•Testar usando equipes de não-especialistas em TI.
•Entender os riscos do Projeto; 
•Procure entender o que significam os objetivos do projeto
•Entenda as áreas-chave e os processos-chave do negócio
•Identifique o grau de severidade das potenciais falhas
•Identifique os componentes do sistema
•Identifique, priorize e estime com precisão os recursos necessários para a execução do projeto
•Fases de teste
•Defina os requisitos de seu ambiente de teste
•Identifique as ferramentas necessárias
•Avalie os planos de contingência do plano do projeto
•Avalie outras vulnerabilidades fora da área de TI
•Construir o Plano de Teste;
•Estabelecer os objetivos do teste
•Desenvolver os roteiros de teste
•Definir a administração do teste e
•Escrever o plano de teste.
•Informações gerais
•Plano,
•Especificações e avaliação
•Descrição dos testes.
 5. Atividades pós-plano
 
Quando se trata de teste, é muito importante que: todos os artefatos gerados durante projeto de teste sejam 
supervisionados por um gerenciamento de configuração.
 
Entre os artefatos de teste que devem estar sob os cuidados do gerenciamento de configuração, listamos:
 
• Casos de teste;
• Plano de teste;
• Requisitos de teste;
• Script de teste e 
• Outros artefatos usados nos testes.
 
6. Estratégia de Teste
 
O objetivo maior dos testes é reduzir a probabilidade de ocorrência de defeitos quando o sistema ou software 
estiver em produção.
 
A Estratégia de Teste, quando empregada, deve ser escrita antes do Plano de Teste.
 
A Estratégia de Teste é composta por Fatores de Teste e Fases de teste.
 
Fatores de teste; São os riscos que precisam ser tratados através da Estratégia de teste. Em resumo, podemos 
dizer que os riscos associados aos testes são chamados Fatores de Teste. Mas nem todos os fatores de teste são 
transformados necessariamente em risco.
 
Fases de teste; São as fases do desenvolvimento do software nas quais o teste será executado.
 
7. Criação da Estratégia de Teste baseada em riscos
 
Como podemos ver, o que foi chamado anteriormente de fatores de teste poderia guardar semelhança com as 
características de qualidade, embora não façam parte da norma ISO 9126-1.
 
Características de qualidade segundo a norma ISO 9126-1
 
1. Funcionalidade;
2. Confiabilidade;
3. Usabilidade;
4. Eficiência;
5. Manutenibilidade e 
6. Portabilidade.
 
Um método de montar a estratégia de teste é associar o risco a uma característica ou sub-característica de 
qualidade da norma ISO 9126.
 
O importante dos riscos é definir a probabilidade de sua ocorrência e sua severidade em relação ao negócio.
 
8. Criação da Estratégia de Teste baseada nos tipos, nas técnicas e nos estágios de teste
 
Na formulação da estratégia de testes devem ser levados em consideração diversos fatores, tais como o porte e 
importância do software, os seu requisitos, os prazos estabelecidos, riscos do negócio e os custos envolvidos.
 
Uma estratégia de teste deve, portanto incluir:
 
• Estágios ou níveis de teste a serem abordados (unitário, integração, sistema e aceitação); 
• Fase do desenvolvimento em que se aplica o referido teste; 
• Os tipos de teste que devem ser executados (funcional, desempenho, carga, estresse etc.) 
• As técnicas e ferramentas a serem empregadas no teste (funcionais ou estruturais) e 
• Os critérios de conclusão com êxito do teste que serão aplicados.
 
Exemplo: Critérios podem permitir que o software evolua para o teste de aceitação quando 95% dos casos de 
teste estiverem sido executados com êxito.
 
Dimensões do teste
 
1. Estágios ou níveis de teste. (quando testar?) – Teste unitário, Teste de integração, Teste de Sistema ou Teste de 
Aceitação.
2. Tipos de Teste. (o que testar?) – Teste de performance, Teste de carga ...
3. Técnica de Teste. (como testar?) – Estrutural ou Funcional.
 
Técnicas de teste
 
É o processo que assegura o funcionamento correto de alguns aspectos ou de uma unidade do software. 
Segundo a norma IEEE 610.12-1990, as técnicas são procedimentos técnicos e gerenciais que ajudam a avaliação 
e melhoria do processo.
 
As técnicas podem ser Funcionais ou Estruturais
 
A técnica de teste Funcional garante que os requisitos especificados foram devidamente cumpridos pelo sistema. 
Valida se o que foi especificado foi implementado de modo correto. A preocupação funcional não é COMO o 
processo ocorre, e sim QUAIS SÃO os resultados do processo.
 
O teste funcional é realizado para assegurar que as especificações e os requisitos do software foram atendidos.
 
Técnicas de teste funcional
 
• Teste de requisitos;
• Teste de regressão;
• Teste de erro de manuseio (usabilidade);
• Teste de suporte manual;
• Teste de integração;
• Teste de controle e 
• Teste paralelo.
 
A técnica de teste Estrutural garante que a implementação de uma funcionalidade foram devidamente testada 
em sua totalidade. O objetivo do teste estrutural é acessar a implementação, de modo a gerar uma massa de 
teste que force a cobertura de toda a estrutura presente na implementação da aplicação, garantindo que a 
estrutura do produto desenvolvido funcione corretamente.
 
Os testes estruturais foram criados para verificar se o sistema desenvolvido e os programas funcionam. A técnica 
não determina o funcionamento correto da aplicação, e sim da estrutura.
 
Técnicas de teste estrutural
 
• Teste de estresse;
• Teste de execução;• Teste de contingência ou recuperação;
• Teste de operação;
• Teste de conformidade; (processo)
• Teste de segurança.
 
Os testes estrutural e funcional, podem ser realizados com o emprego de um conjunto pré-determinado de 
técnicas. Selecionada a técnica, é preciso determinar um método de teste para implementá-la, que pode ser 
dinâmico ou estático. As técnicas dinâmicas determinam se o sistema funciona corretamente quando está 
rodando, e o teste estático “olha” para o sistema quando este não é executado.
 
A análise dinâmica requer que o programa seja executado.
 
A análise estática, por outro lado, não envolve a execução do programa. Entre as técnicas comuns de análise 
estática temos as tarefas que verificam a sintaxe.
 
Uma ferramenta é um veículo para executar um processo de teste, é um recurso para o testador, mas sozinha, é 
insuficiente para a condução de um teste.
 
Estágio ou nível de teste
 
É uma das dimensões do teste que representa o “quando”, ou melhor, a que fase do desenvolvimento se aplica 
determinado teste.
 
Teste de unidade; Costuma ser feito pelo programador e testa as unidades individuais: funções, objetos e 
componentes.
 
Teste de iteração ou integração; Em geral, é realizado pelo analista de sistemas para um módulo ou conjunto de 
programas.
 
Teste de Sistema; Costuma se feito pelo analista de teste (caso de teste) em ambiente de teste.
 
Teste de aceitação; Sua execução é de responsabilidade do cliente. Em geral é feito pelo usuário em ambiente de 
homologação.
Capítulo 7 – Execução dos testes
 Segundo Cem Kaner:
 
No teste estático, o código é examinado.
No teste dinâmico, o código é testado.
 
Conforme já definido, os testes devem ser executados em todas as etapas do ciclo de vida do processo de 
desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o 
software para a produção. O projeto de teste deve ser desenvolvido em paralelo e estar integrado ao projeto de 
desenvolvimento.
 
A responsabilidade de cada um na execução dos testes devem ser documentadas no Plano de Teste. Por 
exemplo, os programadores ou desenvolvedores sãoresponsáveis pela execução dos testes unitários, ao passo 
que os testadores são os responsáveis pela execução dos testes de sistema.
 
Responsáveis pelos testes:
 
• Testes Unitários -- Programadores
• Testes de Integração -- Analistas de Sistemas
• Testes de Sistema -- Analistas de Testes
• Testes de Aceitação -- Usuários com a ajuda dos Analistas de Testes.
 
O plano de teste deve incluir todos os elementos necessários para que os testes sejam executados corretamente. 
Como elementos podemos considerar os procedimentos a serem cumpridos, o ambiente necessário e as 
ferramentas.
 
1.1. Teste Unitário
 
Os testes unitários devem ser feitos pelos programadores e garantir o funcionamento adequado do programa.
 
1.2. Teste de Integração
 
O teste de integração deve ter início quando os componentes a ser integrados já tenham passado pelo teste 
unitário. Esse tipo de teste deve ser executado pelo Analista de Sistemas, restando ao Analista de Teste a 
responsabilidade de testar o sistema.
 
O teste de integração deve garantir que os componentes da aplicação, ou daquele módulo de aplicação, possam 
ser integrados com sucesso para executar determinada funcionalidade.
 
Considerando as aplicações cliente/servidor, o teste de integração deve levar em conta as seguintes camadas:
 
• Camada de apresentação;
• Camada de execução;
• Camada de dados;
• Camada de rede.
1.3. Teste de Sistema
 
O teste de sistema deverá ter início apenas quando o teste de integração for dado como encerrado, ou seja, 
executado com sucesso. Por outro lado, o teste de sistema será dado como terminado quando a equipe de teste 
perceber que a aplicação está apta a ser liberada para a produção.
 
Para o sucesso na execução dos testes de sistema, algumas atividades devem ser seguidas:
 
• O ambiente de teste deve ser semelhando ao de produção;
• Devem ser criados casos de teste, de preferência com uso de ferramentas;
• Devem ser definidos os casos de testes que serão executados;
• Preparar os scripts ou procedimentos a serem seguidos pelos testadores;
• Avaliar os resultados e identificar problemas encontrados;
• Registrar defeitos, de preferências em um sistema de gestão de defeitos;
• Re-testar defeitos corrigidos. Fechar ou reabri o defeito, se não corrigido;
• Garantir que os ciclos de testes foram cumpridos.
 
O teste de sistema precisa garantir que os requisitos do software foram cumpridos, e implementados 
corretamente. Posteriormente, a aplicação ainda passará pelo teste de aceitação, que será conduzido pelos 
próprios usuários com o apoio da equipe de teste.
 
1.4. Teste de Aceitação
 
O teste de aceitação é realizado pelos usuários ou gestores do software para garantir que tudo que foi definido 
por eles nos requisitos tenha sido incluído no produto que lhes está sendo entregue. Muitas vezes recebem 
auxílio dos testadores.
 
1.5. Quando o teste termina?
 
Algumas métricas podem auxiliar o gerente de teste a tomar a decisão de liberar ou não a aplicação para 
produção. Podemos destacar:
 
• Tempo médio entre defeitos encontrados;
• Porcentagem de cobertura alcançada na aplicação do teste;
• Número de defeitos encontrados e ainda não corrigidos por grau de severidade;
• Avaliar os riscos envolvidos com a liberação da aplicação para produção, comparando tias riscos com os riscos 
da não-liberação.
 
1.6. Considerações
 
Existem algumas considerações ou preocupações que os testadores devem sempre levar em conta durante a 
execução dos testes:
 
• O software ainda não está em condições de ser testado adequadamente;
• Os recursos ou o prazo são insuficientes;
• Problemas importantes não serão revelados durante os testes;
• Atenção com o que vai ser testado.
1.7. Processo de execução de testes
 
Para que seja bem sucedida, a etapa de execução dos testes, dentro do ciclo de vida dos testes, vai depender de 
tudo que foi feito anteriormente e que servirá de base para o cumprimento dessa etapa.
 
Um pré-requisito para o início desta etapa é o Plano de Teste.
 
1.7.1. Teste segundo as características de qualidade de software
 
Tendo como base algumas características ou sub-características da norma ISO 9126-1, listamos alguns tipos de 
testes que se enquadram para atender as características listadas:
• Funcionalidade
•Teste de Autorização;
•Teste de Integridade dos arquivos;
•Teste de Trilha de auditoria;
•Teste de Conformidade com a metodologia;
•Teste Negativo
• Continuidade
•Teste de Recuperação;
•Segurança
•Teste de Segurança
•Performance
•Teste de Estresse;
•Teste de Performance;
•Usabilidade
•Teste Manual;
•Manutenibilidade
•Inspeções
•Portabilidade
•Teste de Desastre;
•Conectividade
•Teste de Regressão;
•Teste de Conexão;
•Operacionalidade
•Teste Operacional.
Capítulo 8 – Gestão de Defeitos
 
Erro: resultado de uma falha humana.
Defeito: resultado de um erro existente num código ou num documento.
 
O processo de gestão de defeitos se baseia nos seguintes princípios:
 
• O objetivo primordial é evitar defeitos;
• Um dos princípios básicos para evitar defeitos é minimizar riscos, não só do projeto de desenvolvimento, mas 
também do projeto de teste;
• Integração entre desenvolvedores e testadores através de uma ferramenta de gestão de defeitos;
• Automação da gestão de defeitos é um fator muito importante para o sucesso;
• Melhoria contínua e
• Utilizar práticas de modelos de processo (Ex: CMMI).
 1.8. Conceito de defeito 
O Defeito ocorre em função de algum desvio em relação ao requisito:
 
• Defeitos decorrentes de falta de concordância com a especificação do produto As especificações dizem uma 
coisa e o software faz outra.
• Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto O gestor ou 
usuário não definiu nada nas especificações, porém o software age de maneira inesperada em determinadas 
situações.
 
No entanto, defeitospodem decorrer da falta de entendimento do requisito ou simplesmente da falta de 
definição do requisito.
 
1.8.1. Tipos de Defeito
• Defeito de interface com o usuário;
•Defeitos de funcionalidade quando o sistema não faz algo que o usuário espera que o faça
•Defeitos de usabilidade dificuldades de navegação
•Defeitos de desempenho não atende com rapidez necessária as solicitações do usuário
•Defeitos de saída o resultado apresentado pelo software não corresponde ao que foi definido pelo 
usuário nas especificações ou foram mal projetadas 
 • Defeitos introduzidos no tratamento de defeitos;
•Prevenção dos defeitos o programa não se protege de entradas de dados imprevistas
•Detecção dos defeitos o programa não trata, ou trata inadequadamente, as indicações de defeitos 
esultantes de suas ações
•Recuperação dos defeitos mesmo detectando o defeito, o programa falha porque não trata 
adequadamente a situação
• Defeitos de limite não consegue tratar ou trata inadequadamente valores extremos
• Defeitos de cálculo efetua cálculo e produz resultado errado
• Defeitos de inicialização ou fechamento ausência de inicialização ou fechamento de rotinas, arquivos, etc.
• Defeitos de controle de fluxo declaração de variável erroneamente
• Defeitos de manuseio ou de interpretação de dados ocorre quando um programa tem que passar um grupo 
de dados para outro programa
• Defeitos de condição de disputa ocorre quando o programa espera uma resposta dos eventos A e B, sendo 
presumido que A sempre termina primeiro, mas B terminou primeiro
• Defeitos de carga o programa não suporta um pico de serviço num determinado momento (estresse) ou uma 
carga alta de serviço por um tempo muito prolongado
• Defeito de hardware e software incompatibilidades entre o programa e o ambiente onde é processado
• Defeitos de controle de versão falha no processo de gestão de configuração
 
1.9. Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são:
 
• Prevenção de defeitos;
•Identificar os riscos críticos; 
•Estimar os impactos esperados; 
•Minimizar os impactos;
 • Linha-de-base (baseline) a ser entregue; 
• Identificação dos defeitos;
•Encontrar defeito; 
•Relatar defeito; 
•Reconhecer defeito;
 • Solução do defeito;
•Priorizar a correção; 
•Programar a correção; 
•Corrigir o defeito; 
•Relatar a solução;
• Melhoria do processo;
• Relatório de gestão.
 
1.9.1. Prevenção de Defeitos
 A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do 
software.
 
Passos para prevenção de defeitos:
 
• Identificar os riscos críticos;
• Estimar os impactos esperados;
• Minimizar os impactos;
 
 1.9.1.1. Identificar os Riscos Críticos
 A melhor maneira de fazer isso é identificar os tipos de defeitos que representam as maiores ameaças, ou seja, 
defeitos que podem colocar em risco o sucesso da construção, entrega e/ou operação do software.
 
A ênfase desse passo não é identificar todos os riscos, e sim identificar os riscos críticos que podem prejudicar o 
sucesso do projeto e que merecem atenção especial.
 
1.9.1.2. Estimar os impactos esperados
 Segundo Beizer, a importância do defeito está diretamente ligada à:
 
• Freqüência com que o defeito ocorre;
• Custo da correção do defeito;
• Custo da instalação;
• Conseqüência.
 
 1.9.1.3. Minimizar os impactos esperados
 Minimizar os impactos esperados envolve a combinação das seguintes estratégias:
 
• Eliminar o risco; (às vezes não é possível)
• Reduzir a probabilidade de o risco se tornar um problema; (Mitigar os riscos)
• Reduzir o impacto se houver problema. (contigenciar o risco)
Algumas técnicas podem se utilizadas para reduzir o impacto esperado. Entre essas técnicas temos:
 
• Garantia da Qualidade  área de GQA
• Treinamento e educação  voltado para desenvolvimento, teste e usuários
• Metodologias e padrões  processos bem definidos, metodologias adequadas e padrões consistentes
• Desenho defensivo;
• Código defensivo.
 
 1.9.2. Linha-de-base (Baseline) a ser entregue
 Um produto a ser entregue é considerado baseline quando alcança um marco pré-definido em seu 
desenvolvimento.
 
Depois de o produto se tornar baseline, recomenda-se que este seja colocado sob gerenciamento de 
configuração. Um defeito é caracterizado quando um componente de um produto baseline não satisfaz seu 
conjunto de requisitos.
 
1.9.3. Identificação do defeito
O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito 
válido.
 
As etapas envolvidas na identificação dos defeitos são:
 
• Encontrar defeito;
• Relatar defeito;
• Reconhecer defeito;
 
 1.9.3.1. Encontrar defeito
Esta etapa utiliza de técnicas como:
 
• Técnicas estáticas  Revisões, walkthrough e inspeções
• Técnicas dinâmicas  realização de Testes
• Técnicas operacionais defeito descoberto como resultado de uma falha na operação do sistema
 
1.9.3.2. Relatar defeito
Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:
 
• Resumo;
• Precisão;
• Neutralidade;
• Isolamento;
• Generalização;
• Reprodução;
• Impacto;
• Provas.
 
Ao relatar um defeito, devemos indicar, entre outras coisas, o impacto que ele representa tato para o sistema 
quanto para os negócios.
 
1.9.3.3. Reconhecer defeito
Depois de detectado o defeito, o desenvolvedor deve decidir se ele é válido ou não.
 
Quando um grupo achar que é defeito (os usuário, por exemplo) e outro grupo achar que não é, as abordagens 
mais eficazes são:
 
• Arbitragem pelo usuário;
• Arbitragem pelo gerente de desenvolvimento.
 
1.9.4. Solução do defeito
Tendo defeitos validados pelos desenvolvedores, se dá início ao processo de correção. Para isso são realizados os 
seguintes passos:
 
• Priorizar a correção;
• Programar a correção;
• Corrigir o defeito;
• Relatar a solução;
 
 1.9.4.1. Priorizar a correção
Um método sugerido para priorização é classificar o defeito conforme os critérios a seguir:
 
• Crítico sério impacto no negócio 
• Grave  erro grave ou pára de funcionar
• Menor  algo errado, mas não afeta os usuários
 
 1.9.4.2. Programar a correção
Refere-se ao processo de alocação de recursos para a correção do defeito.
 
1.9.4.3. Corrigir o defeito
Envolve a verificação de um ou mais produtos necessários para a remoção do defeito (p.e.: programas, 
documentos) e a execução da correção.
 
1.9.4.4. Relatar a solução
Notificar todos os envolvidos a correção, natureza da correção e como a correção será liberada.
 
1.9.5. Melhoria do processo
A ocorrência de defeitos, independente de sua importância, pode oferecer a oportunidade de avaliar o processo 
que os originou, de estudar como melhorá-los e prevenir possíveis falhas.
 
Essa atividade deve abranger:
 
• Avaliação do processo que originou o defeito e a compreensão do que o causou;
• Se pertinente, propostas de mudanças processuais capazes de minimizar ou eliminar a causa do defeito.
 
 1.9.6. Relatórios de gestão
O propósito dessa atividade é criar um registro completo dos desvios identificados durante o processo de teste 
para que sirvam de base a várias utilizações no decorrer do projeto, o que inclui as medições de qualidade.
 
O defeito pode ser definido por duas óticas:
 
• Pelo ponto de vista do produtor o defeito é causado por um desvio em relação às especificações; 
• Pela ótica do cliente defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É 
chamada de visão “ajustada para uso”.
 
1.9.7. Qualificação do defeito
É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos.
 
É recomendada a seguinte estrutura de qualificação:
 
• Definição do defeito;
• Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;
• Categoria do defeito. (ausente, impreciso, incompleto inconsistente)
Capítulo 11 - Estimativas
1. Análise de pontos de Teste – (APT)
Toda técnica de medição e estimativaprecisa considerar o ambiente e o local onde está sendo usada.
APT é uma medida de tamanho de teste que, com acertos e calibragens, gera previsões de esforço e estimativas 
de tempo.
APT toma como premissa básica o tamanho do sistema em pontos de função e também considera todas as suas 
funcionalidades como ponto de partida.
1.1. Filosofia da medição de pontos de teste
Além das informações coletadas com o desenvolvimento, os testes também são afetados pelos seguintes 
fatores:
• O grau de complexidade do processo de teste - Sistemas mais complexos, mais horas de testes serão 
consumidas.
• O nível de qualidade que se pretende alcançar com os testes - Nível mais alto de qualidade demanda maior 
esforço que demanda maior custo.
• Grau de envolvimento dos usuários com os testes - Quanto mais os usuários participarem melhor o resultado 
obtido e menor pode ser o esforço de testar.
• As interfaces que as funções tem com os arquivos - quanto maior o número de arquivos envolvidos nos casos de 
teste, mais difícil será testar.
• A qualidade do sistema testado (o ciclo de reincidência dos defeitos) - Defeitos de desenvolvimento ou de 
projeto, tornam o trabalho de testar muito mais oneroso.
• O nível de cobertura esperado com os testes - Os requisitos do sistema normalmente vão estabelecer o nível de 
cobertura exigido pelos testes.
• A experiência e a produtividade da equipe de teste (medidos através de indicadores históricos)
• O grau de automação dos testes - Permite níveis maiores de produtividade e facilita a documentação dos 
testes.
• A qualidade do ambiente de teste, até mesmo sai capacidade de simular o ambiente de produção - O ambiente 
de teste deve estar próximo ou ser igual ao ambiente de produção.
• A qualidade da documentação do sistema e, em especial, dos requisitos.
Abaixo, estão descritas as atividades para estimativa de Tamanho.
1.2. Total de pontos de teste (PT)
O número total de pontos de teste (PT) é dado pela soma das seguintes medidas
• Pontos de teste dinâmicos (PTDf);
• Pontos de teste estáticos (PTE).
Considerando-se o tamanho do sistema em pontos de função e uma constante igual a 500, que representa o 
tamanho mínimo do sistema em pontos de função.
1.2.1. Pontos de teste dinâmico (PTDf)
Os pontos de teste dinâmicos são calculados com base nas funções do sistema.
As funções medidas em pontos de função e tratadas em pontos de teste são:
• Entradas Externas (EE);
• Saídas Externas (SE) e
• Consultas Externas (CE).
Os pontos de teste dinâmicos tomam como base também os seguintes elementos:
• Funções dependentes (FDf);
• Qualidades dos requisitos relacionados às características de qualidade a serem testadas dinamicamente (QRd).
 1.2.1.1. Fatores Funções dependentes - FDf
O cálculo de funções dependentes é realizar de funcionalidade por funcionalidade e considera os seguintes 
fatores:
• Importância do Usuário (Ue) - Grau de importância que o usuário dá à função a ser testada;
• Intensidade de Uso (Uy) - Nível de uso da função por intervalo de tempo;
• Interface (I) - Nível de relacionamento entre data-sets (arquivos) e as funções que estão sendo medidas;
• Complexidade (C) - Medido pela quantidade de comandos IF ou Cases existentes no algoritmo.
• Uniformidade (U) - Mede o nível de re-utilização do material de teste.
• Funções padronizadas - já possuem uma formula própria de contagem, como as:
• Funções de mensagens de defeitos;
• Funções de ajuda e
• Estrutura de menu.
1.2.1.2. Características de qualidade dinâmica (QRd)
As características de qualidade dinâmica (QRd) medem como a qualidade dos requisitos pode, afetar a qualidade 
dos testes.
Para essa medição, são consideradas:
• Medidas Explícitas e
• Medidas Implícitas.
1.2.1.2.1. Características Explicitas (CE)
Temos as seguintes características explícitas:
• Funcionalidade (F); [Peso = 0,75]
• Performance (P); [Peso = 0,10]
• Segurança (S) e [Peso = 0,05]
• Aderência e Efetividade (A). [Peso = 0,10]
Fatores de medição para as CE em relação à qualidade dos requisitos:
0 – não é importante;
3 – não é importante, mas precisa ser considerada;
4 – tem importância média;
5 – muito importante e
6 – extremamente importante.
F = [Fator Medição x Peso]/4
Fórmula de cálculo para Características Explicitas:
CE = F + P + S + A
As características de Aderência e Efetividade dizem respeito aos testes de alto nível (sistema e aceitação).
Testes de alto nível geralmente usam técnicas de caixa-preta em sua execução. Os testes de alto nível mais 
conhecidos são os testes de sistemas e de aceitação.
Teste funcional - é o grupo de testes que avalia se o que foi especificado pelo usuário foi realmente 
implementado.
Teste de usabilidade está diretamente ligado a Funcionalidade (F) da aplicação.
Teste de Usabilidade - Avalia a facilidade de uso do sistema pelos usuários.
1.2.1.2.2. Características Implícitas (CI)
As características implícitas são utilizadas quando há coleta de dados e/ou indicadores para futuras medições 
quanto a qualidade dos testes. Sempre que houver indicadores que possam ser utilizados para avaliar uma das 
características explícitas (funcionalidade, performance, segurança e aderência), consideramos que pode existir 
uma característica implícita associada.
Fórmula de cálculo para Características Implicitas:
CI = n x 0,02 (onde n varia entre 0 e 4)
Fórmula de cálculo para QRd:
QRd = CE + CI
Fórmula de cálculo para Ponto de Teste Dinâmico:
PTDf = PFf x FDf x QRd
1.2.2. Ponto de Teste Estático (PTE)
Os pontos do teste estático levam em considerações o sistema como um todo, diferentimente dos pontos de 
testes dinâmico, que consideram cada característica isoladamente.
Os testes estáticos só devem ser considerados quando a equipe de teste adotar processos de revisão de 
documentação e de códigos usando checklists; caso contrário, devem ser descartados e terão valor nulo.
O cálculo dos PTE toma como base os critérios de qualidade para avaliação das características anteriormente 
citadas (funcionalidade, performance, segurança e aderência).
PTE = 16 x n
Fórmula de cálculo do Total de Pontos de teste:
PT = ∑PTDf + (PF x PTE)/500
Abaixo, estão descritas as atividades para estimativa de Esforço.
1.3. Estimativa de horas de teste primárias (HTP)
O cálculo da estimativa do número de horas de teste primárias depende dos seguintes elementos:
• Qualificação da equipe de teste e
• Ambiente de teste.
1.3.1. Qualificação da Equipe de Teste (QET)
Este valor é determinado por base histórica e deve variar entre 0,7 e 2,0 considerando-se a experiência e 
qualificação da equipe de teste. Estes fatores estão ligados diretamente com a produtividade da equipe de 
testes.
QET = 0,7 a 2,0
Quanto melhor e mais qualificada a equipe, menor será o índice do QET.
1.3.2. Ambiente de Teste (AT)
O ambiente de teste é medido levando em conta alguns fatores ambientais, tais como:
• Ferramentas de teste - existência e aplicabilidade de uma ferramenta de automação nas fases do teste.
• Teste de Precedência - Para cada etapa do processo de teste, a atividade imediatamente anterior deve produzir 
bons resultados para que a atividade seguinte seja bem executada.
• Documentação de teste - Uso de documentos padronizados.
• Ambiente de desenvolvimento - faz referência à linguagem de programação utilizada.
• Ambiente de teste - utilização do ambiente de teste.
• Testware - Existência de materiais de teste disponíveis.
AT = soma dos fatores/21
HTP = PT x QET x AT
1.4. Número total de horas de teste (THT)
As horas primárias de teste devem ser corrigidas com a inclusão das atividades relacionadas ao Índice de 
Planejamento e Controle (IPC), cujo percentual é dado pelos seguintes fatores:
• Tamanho da Equipe (TE);
• Ferramentas de gerenciamento (FG).
IPC = 1 + (TE + FG) onde: THT = HTP x IPC
1.5. Estimativa baseada no tamanho e na complexidade do caso de uso
Esta forma de estimativa utiliza como imputs os seguintes dados:
• Contagem do número de fluxo de um determinado caso de uso;
• Média de passosde cada fluxo;
• Contagem do número de exceções;
• Contagem das regras de negócio (classificação: simples, média, complexas).