Testes de Software

TESTES DE SOFTWARE
Fundamentos
MATERIAL OFICIAL TARGETTRUST

Testes de Software – Fundamentos
1
Sumário
Software ...................................................................................................... 8
O que é Software ...................................................................................... 8
Modelos Prescritivos de Software .................................................................. 9
Modelo Cascata ......................................................................................... 9
Modelo Incremental ................................................................................. 11
Modelo Evolucionário ............................................................................... 12
Prototipagem ....................................................................................... 13
Modelo espiral ...................................................................................... 14
Modelos Especializado de Processo ........................................................... 15
Desenvolvimento baseado em componentes .......................................... 15
Modelo de métodos formais .................................................................. 16
Processo Unificado .................................................................................. 17
Desenvolvimento Ágil de Software ............................................................... 21
Premissas do Desenvolvimento Ágil ....................................................... 22
EXTREME PROGRAMMING ....................................................................... 23
As boas práticas do XP ......................................................................... 24
SCRUM ................................................................................................... 26
Histórico .............................................................................................. 26
Definição ............................................................................................. 26
Pilares ................................................................................................. 27
Como Funciona?................................................................................... 27
Sprints ................................................................................................. 27
Product Sprint Backlog.......................................................................... 27
Kanban (Quadro de Trabalho) ............................................................... 28
........................................................................................................... 28
Daily Scrum ......................................................................................... 28
Sprint Review Meeting .......................................................................... 28
Burn Down Chart ................................................................................. 28
Papéis e Responsabilidades ................................................................... 29
Product Owner ..................................................................................... 29
Scrum Master ....................................................................................... 29
2
Scrum Team ........................................................................................ 29
Teste de software ...................................................................................... 30
O que é teste de software? ...................................................................... 30
De onde surgiram os Testes de Software? ................................................ 30
História do primeiro BUG... ...................................................................... 31
Porque investir em Testes de Software? ................................................... 32
Formas de condução dos Testes............................................................... 33
Custos .................................................................................................... 33
Regra 10 de Meyers ................................................................................... 34
Ciclo de desenvolvimento em V ................................................................... 35
Ciclo de desenvolvimento em W .................................................................. 36
Validação e Verificação ............................................................................... 36
Níveis de Teste .......................................................................................... 37
Objetivos do Teste .................................................................................. 37
Principais causas do fracasso em Teste ..................................................... 38
Até quando devemos testar? .................................................................... 38
Defeito, erro e falha ................................................................................ 39
Cargos comuns na área de Teste de Software .............................................. 40
Analista de Teste ..................................................................................... 40
Responsabilidades: ............................................................................... 40
Diferenciais: ......................................................................................... 40
Testador de Software .............................................................................. 40
Diferenciais: ......................................................................................... 40
Automatizador de Teste ........................................................................... 40
Diferenciais: ......................................................................................... 40
Técnico de Teste de software................................................................... 41
Diferenciais: ......................................................................................... 41
Líder de Teste ......................................................................................... 41
3
Diferenciais: ......................................................................................... 41
Arquiteto de Teste ................................................................................... 41
Diferenciais: ......................................................................................... 42
Engenheiro de Teste................................................................................ 42
Diferenciais: ......................................................................................... 42
Gerente de Teste - Coordenador de Teste................................................. 42
Consultor em Teste ................................................................................. 43
Diferenciais: ......................................................................................... 43
Perfil dos profissionais ............................................................................. 43
Certificações da área de Teste de Software ............................................... 43
O que é Qualidade? .................................................................................... 45
Porque as empresas buscam a qualidade? ................................................ 46
O que é Qualidade de Software? ................................................................. 46
Qualidade do Produto ................................................................................. 47
Qualidade do Processo................................................................................ 47
Certificação da Qualidade ........................................................................ 47
O Sistema de Certificação ..................................................................... 48
Quais são as vantagens da certificação? ................................................ 49
ISO/IEC 9126 ............................................................................................. 49
Modelo de Qualidade de Software ............................................................ 50
Atributos de Qualidade ............................................................................ 50
Funcionalidade ..................................................................................... 51
Confiabilidade ...................................................................................... 52
Usabilidade .......................................................................................... 52
Eficiência ............................................................................................. 53
Manutenibilidade .................................................................................. 53
Portabilidade ........................................................................................ 54
Modelo de qualidade em uso .................................................................... 54
4
Efetividade ........................................................................................... 55
Produtividade ....................................................................................... 55
Segurança ........................................................................................... 56
Satisfação ............................................................................................ 56
O que é o CMMI®? .................................................................................... 56
Histórico ................................................................................................. 57
Sobre o CMMI ......................................................................................... 58
Dimensões: .......................................................................................... 58
Formas de representação......................................................................... 60
Componentes das Áreas de Processo ........................................................ 60
O que é uma área de processo? ............................................................ 61
Quais são as áreas de processos do CMMI? ........................................... 61
NÍVEL 2 – Gerenciado.............................................................................. 61
Áreas de processos do nível 2 – Gerenciado ........................................... 61
NÍVEL 3 – Definido .................................................................................. 62
Áreas de processos do nível 3 – Definido ............................................... 62
NÍVEL 4 – Gerenciado Quantitativamente ................................................. 63
Áreas de processos do nível 4 – Gerenciado Quantitativamente ............. 63
NÍVEL 5 – Em Otimização ........................................................................ 63
Áreas de processos do nível 5 – Em Otimização ..................................... 63
Níveis de Capacidade ............................................................................ 64
Níveis de Maturidade ............................................................................ 65
Áreas de Processos e Categorias ........................................................... 66
Níveis e Áreas de Processos .................................................................. 67
MPSBr ....................................................................................................... 67
Introdução .............................................................................................. 67
Quem é a SOFTEX? ................................................................................. 67
O Projeto MPs-BR .................................................................................... 68
Metas do programa a médio e longo prazo ............................................ 68
MPS.BR em números ............................................................................ 69
MPS Software ......................................................................................... 70
Norma ISO/IEC 12207 .......................................................................... 72
5
Norma ISO/IEC 15504 .......................................................................... 73
O Modelo de Referência ........................................................................... 73
Processos ............................................................................................ 74
Métodos de Avaliação .............................................................................. 76
MPS Serviços .......................................................................................... 77
Tipos de Teste ........................................................................................... 78
Técnicas de Teste (Funcional x Estrutural) ................................................... 79
Técnicas de Testes Funcionais ................................................................. 80
Teste de Requisitos (Teste Funcional) ................................................... 80
Regressão ............................................................................................ 81
Testes de Tratamento de Erros ............................................................. 82
Testes de Suporte Manual..................................................................... 82
Testes de Interconexão ........................................................................ 83
Testes de Controle ............................................................................... 84
Testes Paralelos ................................................................................... 84
Técnicas de Testes Estruturais ................................................................. 84
Teste de Estresse ou Carga................................................................... 85
Performance (Desempenho ou Execução) .............................................. 85
Recuperação ........................................................................................ 86
Operação ............................................................................................. 88
Teste de Conformidade......................................................................... 89
Testes de Segurança ............................................................................ 89
Testes de manutenção: ........................................................................... 91
Estratégias de teste de software.................................................................. 92
Caixa preta : ........................................................................................... 92
Caixa branca: .......................................................................................... 92
Técnicas de Teste de Caixa Preta: ............................................................ 92
Particionamento de equivalência ........................................................... 93
Análise de valor limite........................................................................... 95
Gráfico Causa Efeito ............................................................................. 96
Fluxo de Dados .................................................................................... 97
Pair Wise ............................................................................................ 104
6
Técnicas de Teste de Caixa Branca .......................................................... 105
Revisão formal .................................................................................... 105
Teste do caminho básico ..................................................................... 106
Ambientes de Teste ................................................................................... 107
Definição: .............................................................................................. 107
Preparação do ambiente de teste ............................................................ 108
Uso de ambientes virtuais ....................................................................... 109
Bibliografia ................................................................................................ 110
7
Software
O que é Software
O termo inglês "software" foi usado pela primeira vez em 1958 em um artigo escrito
pelo cientista americano John Wilder Tukey.
Software: sequência de instruções escritas para serem interpretadas por um

computador com o objetivo de executar tarefas específicas. Também pode ser definido
como os programas que comandam o funcionamento de um computador.
Em um computador, o software é classificado como a parte lógica cuja função é

fornecer instruções para o hardware (toda a parte física que constitui o computador,
por exemplo, a CPU, a memória e os dispositivos de entrada e saída). O software é
constituído por todos os programas que existem para um referido sistema.
Os softwares podem ser classificados em três tipos:
Software de Sistema: é o conjunto de informações processadas pelo sistema

interno de um computador que permite a interação entre usuário e os periféricos do
computador através de uma interface gráfica. Engloba o sistema operativo e os
controladores de dispositivos (memória, impressora, teclado e outros).
Software de Programação: é o conjunto de ferramentas que permitem ao

programador desenvolver sistemas informáticos, geralmente usando linguagens de
programação e um ambiente visual de desenvolvimento integrado.
Software de Aplicação: são programas de computadores que permitem ao

usuário executar uma série de tarefas específicas em diversas áreas de atividade como
arquitetura, contabilidade, educação, medicina e outras áreas comerciais. São ainda os
vídeos jogos, as bases de dados, os sistemas de automação industrial, etc.
Existe também o conceito de software livre, que remete para um programa que dá
liberdade ao utilizador, permitindo que ele o estude, modifique e compartilhe com
outras pessoas. Para isso, é preciso que o utilizador possa aceder o código-fonte, para
mudá-lo conforme as suas necessidades.
Hoje, o software de computadores é a tecnologia única mais importante no palco

mundial. Ninguém na década de 1950 poderia ter previsto que o software fosse se
tornar uma tecnologia indispensável para negócios, ciência e tecnologia. Ainda, seria
impossível acreditar que uma indústria de software poderia ser maior e mais influente
do que a maioria das empresas da era industrial; que uma vasta rede guiada por
softwares chamada Internet, evoluiria e modificaria tudo, desde a pesquisa na
biblioteca até a maneira dos consumidores comprarem e até mesmo a forma das
pessoas marcarem encontros.
A medida que a importância do software cresceu, a comunidade de software tem

tentado continuamente desenvolver tecnologias que tornem mais fácil, mais rápido e
menos dispendioso construir e manter programas de computador de alta qualidade.
8
Hoje o software assume um duplo papel: é o produto e ao mesmo tempo é o veículo
que entrega o produto. Como produto ele disponibiliza o potencial de computação
presente no hardware do computador ou, mais amplamente, por uma rede de
computadores acessível pelo hardware local. Quer seja em um celular ou em um
computador de grande porte o software é um transformador de informações –
produzindo, gerindo, adquirindo, modificando, exibindo ou transmitindo informações,
desde as mais simples até as mais complexas. Como veículo usado para entrega do
produto, o software age como base para o controle do computador (sistemas
operacionais), para a comunicação da informação (redes) e para a criação e controle
de outros programas (ferramentas e ambiente de software).
O software entrega o mais importante produto da nossa época, a informação. Ele

transforma os dados pessoais de forma que eles possam ser mais úteis em um
determinado contexto; organiza informações comerciais para melhorar a
competitividade; fornece um portal para as redes de informação de âmbito mundial e
proporciona os meios para obter informações em todas as suas formas.
Modelos Prescritivos de Software
Os modelos de prescritivos de processo foram originalmente propostos para colocar

ordem no caos do desenvolvimento de software. A história tem indicado que esses
modelos convencionais têm trazido uma certa dose de estrutura útil para o trabalho de
engenharia de software e tem fornecido um roteiro razoavelmente efetivo para as
equipes de software. Os Modelos prescritivos de processo definem um conjunto
distinto de atividades, ações, tarefas, marcos e produtos de trabalho que são
necessários para fazer engenharia de software com alta qualidade. Esses modelos de
processo não são perfeitos, mas efetivamente fornecem um roteiro útil para o trabalho
de engenharia de software.
É importante porque fornece estabilidade, controle e organização a uma atividade que

pode ser deixada sem controle, tornar-se bastante caótica. Alguns tem-se referido a
modelos prescritivos de processos com “modelos de processos rigorosos”, porque eles
frequentemente incluem as capacitações sugeridas pelo CMMI. No entanto, cada
modelo de processo deve ser adaptado para que seja usado efetivamente em um
projeto de software específico.
Modelo Cascata
O Modelo Cascata, também chamado de Clássico ou Linear, caracteriza-se por possuir

uma tendência na progressão sequencial entre uma fase e a seguinte. Eventualmente,
pode haver uma retroalimentação de uma fase para a fase anterior, mas de um ponto
de vista macro, as fases seguem fundamentalmente de forma sequencial.
A figura abaixo nos dá uma ideia visual do conceito apresentado acima.
9
Figura 1 – Modelo Cascata
Podemos utilizar o modelo cascata quando um software necessita de uma nova

funcionalidade e os requisitos estão bem definidos e são estáveis.
Basicamente na etapa de levantamentos de requisitos ou necessidades estabelecemos
junto aos clientes os requisitos do produto desejado pelo cliente que consiste dos
serviços que devem ser fornecidos, limitações e objetivos do software. Esta etapa
também consiste da documentação e o estudo de viabilidade do projeto para
determinarmos o processo de início de desenvolvimento do projeto do sistema. Na
etapa de planejamento temos a definição de estimativas, cronograma e
acompanhamento baseando-se nos requisitos e na determinação das tarefas que, por
sua vez, são determinadas pelos requisitos. A etapa de modelagem é uma prévia da
próxima etapa de construção, nesta etapa define-se a estrutura de dados, arquitetura
do software, interfaces, etc. A etapa de construção abrange a implementação, onde os
programas são efetivamente criados e também os testes que é onde se testam as
lógicas internas do software e as funcionalidades externas. As funcionalidades internas
normalmente são realizadas com o uso de testes unitários e as fases externas podem
ser realizadas por testadores e pelo próprio cliente. Por fim, a etapa de emprego ou
implantação abrange e entrega efetiva do software no cliente que é onde instalamos o
software no servidor ou na máquina do cliente junto com outros utilitários como banco
de dados ou outros itens dependendo do software sendo construído. O suporte é onde
tiramos dúvidas dos clientes e a manutenção consiste na correção de erros que não
foram previamente detectados.
O modelo cascata é o paradigma mais antigo da engenharia de software. Porém,

mesmo sendo bastante antigo e ainda utilizado na indústria esse processo recebe
muitas críticas que gerou questionamentos sobre a sua eficácia até mesmo pelos seus
maiores defensores.
Os principais problemas encontrados no modelo cascata são:
Os projetos de software reais construídos e evoluídos na indústria de software

raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo
em forma sequencial possa conter iterações, onde poderíamos passar diversas vezes
pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que
10
mudanças podem provocar bastante confusão na medida em que a equipe de projeto
prossegue.
É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas
necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade
para adequar a incerteza natural que existem no inicio dos projetos.
O cliente precisa ter muita paciência, o que raramente acontece. Uma versão
operacional (pronta para ser executada no cliente) não estará disponível até estarmos
próximo ao final do projeto.
Se tivermos um erro grave nas etapas iniciais, como uma especificação mal
compreendida e mal especificada, podemos ter um resultado desastroso.
Outro grande problema que temos com os projetos que usam modelos cascata é o
bloqueio que existe em alguns membros da equipe que precisam esperar que os outros
completem as suas tarefas para que eles possam dar sequência ao trabalho.
Modelo Incremental
Alguns projetos de software definem requisitos iniciais de software razoavelmente bem

definidos. Pode ser necessário o rápido fornecimento de um determinado conjunto
funcional aos usuários, para que após esse fornecimento, possamos melhorar e
expandir suas funcionalidades em versões de software posteriores. Nesses casos,
podemos optar por um modelo de processo que desenvolve softwares de uma forma
incremental.
O modelo de processo incremental combina elementos dos fluxos de processos tanto

lineares quanto paralelos.
Figura 2 – Modelo Incremental
11
O modelo de processo incremental combina elementos do modelo em cascata aplicado
de forma iterativa à medida que o tempo for avançando. Cada uma das sequencias
lineares gera um incremento do software. Esses incrementos são entregáveis e prontos
para o cliente. Podemos citar um exemplo de processo incremental em um software de
Business Inteligence que em um primeiro momento emitiria relatórios pré-formatados.
Em um segundo incremento o software poderia adicionar funções de seleção de
períodos e no próximo incremento o software poderia adicionar o acréscimo de um
segundo filtro e assim sucessivamente.
No primeiro incremento de um produto que utiliza o modelo incremental temos apenas

o essencial do produto, ou seja, os requisitos básicos que devem ser atendidos para o
software entrar em operação. Portanto, no primeiro incremento muitos recursos
complementares ainda não são entregues para os clientes. Após o término do primeiro
incremento o cliente utiliza e avalia esse incremento fornecendo posteriormente um
resultado ou feedback. Com base nesse resultado fornecido pelo cliente o próximo
incremento é planejado considerando a modificação do primeiro incremento, caso seja
necessário, de acordo com o feedback do cliente. Após a liberação de cada incremento
é realizado esse mesmo processo até que o produto esteja completo.
O modelo de processo incremental entrega um produto operacional a cada incremento,

ou seja, um produto sem erros e pronto para o usuário utilizar. Mesmo que os
primeiros incrementos sejam partes do produto, essas partes são operacionais e
funcionam sem as outras. Portanto, os incrementos possuem totais condições de
atender ao usuário.
De forma geral, os primeiros incrementos podem ser implementados com um número

reduzidos de pessoas. Nos próximos incrementos um pessoal adicional poderá ser
acrescido de forma a implementar o incremento seguinte. Também podemos
administrar alguns riscos através de um planejamento baseado nos incrementos. Por
exemplo, se uma determinada versão de um software utilitário fornecido por terceiros
que será integrado ao nosso projeto estiver disponível apenas numa data mais
posterior, poderíamos deixar para desenvolver um determinado complemento do
software que use essa versão mais atual numa data posterior quando esse utilitário já
estiver disponível para uso.
Modelo Evolucionário
O software evolui ao longo do tempo e conforme o desenvolvimento deste software

avança também temos mudanças nas necessidades de negócio e de produtos que
mudam frequentemente. Isso torna inadequado seguirmos um planejamento em linha
reta de um produto. Os modelos de processo evolucionário tornaram-se realidade para
que possamos desenvolver um produto que evolua ao longo do tempo.
Modelos evolucionários são caracterizados por serem iterativos e apresentarem

características que possibilitem desenvolvermos versões cada vez mais completas do
software. Os processos evolucionários se caracterizam por dois modelos comuns:
Prototipagem e Espiral.
12
Prototipagem
A prototipagem é utilizada quando o desenvolver não tem certeza quanto à eficiência

de um algoritmo, ou quanto à adaptabilidade de um sistema operacional ou ainda
quanto à forma em que deva ocorrer a interação entre o cliente e o sistema. Quando
temos essa situação a prototipagem é uma excelente alternativa. Vale ressaltar que a
prototipagem pode ser utilizada em qualquer processo de software, visto que a
prototipagem auxilia os interessados a compreender melhor o que está para ser
construído.
A prototipagem se dá basicamente com a comunicação que ocorre através de uma
reunião com todos os envolvidos a fim de definir objetivos gerais do software e
identificar quais requisitos já estão bem conhecidos e esquematizar as áreas que
realmente necessitam de uma definição mais ampla. Uma iteração de prototipagem
deve ser planejada rapidamente e dessa forma ocorre a modelagem na forma de um
projeto rápido. O projeto rápido foca na representação dos aspectos do software que
serão visíveis aos usuários como layout da interface e os formatos de exibição. Esse
projeto rápido leva à construção de um protótipo que será avaliado pelo cliente. O
cliente por sua vez retornará um feedback á equipe de software que irá aprimorar os
requisitos. A iteração vai ocorrendo conforme vamos ajustando o protótipo às
necessidades dos usuários.
Figura 3 – Prototipagem
Etapas da Prototipagem de forma iterativa.
De forma geral o protótipo auxilia na identificação dos requisitos do software. Os

protótipos podem ser descartados quando usamos apenas para entender um
determinado requisito ou pode ser utilizado como um produto evolucionário que servirá
para o cliente.
13
Modelo espiral
O famoso modelo espiral foi proposto por Boehm. Esse é um modelo de processo de
software evolucionário que também é iterativo como a prototipagem, porém com
aspectos sistemáticos e controlados do modelo cascata. O modelo espiral fornece um
grande potencial para que possamos ter rápido desenvolvimento de versão cada vez
mais completas.
Um modelo espiral possui diversas atividades definidas pela engenharia de software,

onde cada uma dessas atividades representa um segmento do caminho espiral.
Figura 4 - Ilustrando o Modelo espiral.
Sempre iniciamos pelo centro da espiral e prosseguimos no sentido horário. Os riscos

são considerados à medida que cada evolução é realizada. A primeira atividade se dá
com o desenvolvimento de uma especificação de produto, as próximas passagens
podem ser usadas para desenvolver um protótipo e, assim sucessivamente vamos
evoluindo para versões cada vez mais sofisticadas do software. Cada passagem pela
parte de planejamento, por exemplo, resulta em ajustes no planejamento do projeto.
O custo e o cronograma são sempre ajustados de acordo com o feedback obtido do
cliente após uma entrega. Também teremos um ajuste no número de iterações
planejadas para completar o software.
Podemos notar que diferente de outros modelos que terminam quando o software é
entregue, o modelo espiral pode ser adaptado a cada entrega. O projeto finaliza
quando o cliente fica satisfeito, quando o software é retirado de operação ou uma data
encerra definitivamente o projeto.
O modelo espiral é largamente utilizado e é considerada uma abordagem realista para

desenvolver sistemas em larga escala.
14
Modelos Especializado de Processo
Um modelo de processo especializado leva em conta muitas das características de um

ou mais modelos tradicionais, tais como o modelo espiral, modelo evolucionário, entre
outros. Esses modelos tendem a ser aplicados quando optamos por uma abordagem
mais especializada de engenharia de software ou quando definida de uma forma mais
restritiva.
Temos um conjunto de três modelos de processo especializado, são eles: Modelo

Desenvolvimento baseado em componentes, Modelo de métodos formais e o
Desenvolvimento de software orientado a aspectos.
Desenvolvimento baseado em componentes
O desenvolvimento de software baseado em componentes tem como ênfase criar

sistemas de software que envolvam a composição de componentes, permitindo que
sejam adicionadas, adaptadas, removidas e substituídas partes do sistema sem que
seja necessário à sua completa substituição.
Este tipo de desenvolvimento auxilia bastante a manutenção dos sistemas, visto que
ele foca na integração de novos componentes já prontos ou então a atualização dos
componentes já existentes. Dessa forma, essa abordagem enfatiza a criação ou
adaptação de componentes para que sejam utilizados em diversos sistemas. Com isso,
temos como resultado a reutilização que busca flexibilizar o desenvolvimento.
Um tipo de componente bastante conhecido e utilizado são os componentes de

software comercial de prateleira ou COTS (Commercial Off-The-Shelf). Estes são
componentes desenvolvidos por vendedores que os oferecem como produtos e
disponibilizam as suas funcionalidades juntamente com interfaces bem definidas que
permitem que esses componentes sejam integrados ao software a ser desenvolvido.
Nesse caso, o engenheiro de software conhece pouco ou nada sobre o funcionamento
interno de um componente, porém, é fornecida ao engenheiro uma interface externa
bem definida com a qual ele deve trabalhar. Esses componentes podem ser comprados
e a sua principal desvantagem, na maioria dos casos, é que não há código fonte
disponível. Assim, a definição de como usar o componente é dada pelo fabricante.
De forma geral, um componente é algo quase independente e uma parte substituível

de um sistema que tem uma função bastante clara. Os componentes possuem uma
interface e também empregam regras de herança.
O modelo de desenvolvimento baseado em componentes possui diversas

características do modelo espiral, possuindo uma abordagem iterativa e evolucionária.
A essência do desenvolvimento baseado em componentes é desenvolver aplicações a
partir de componentes de software pré-empacotados.
Diferente de outros modelos, no modelo de desenvolvimento baseado em

componentes as atividades de modelagem e construção começam com a identificação
de possíveis candidatos a componentes que podem ser projetados como módulos de
software convencionais, como classes ou pacotes. O modelo de desenvolvimento
baseado em componentes possui as seguintes etapas:
15
Diversos produtos baseados em componentes existentes no mercado são pesquisados
e avaliados.
Os itens de integração de componentes são considerados.
Projeta-se uma arquitetura de software para acomodar os componentes.
Integram-se os componentes à arquitetura.
Realizam-se todos os testes para assegurar a funcionalidade adequada.
Todas essas etapas são independentes da tecnologia utilizada para criar os

componentes.
Uma das maiores vantagens do desenvolvimento baseado em componentes é que ele

aumenta o reuso, que por sua vez, proporciona uma série de benefícios como redução
no tempo do ciclo de desenvolvimento, redução no custo do projeto, etc.
Um exemplo de componente bastante utilizado na indústria é a tecnologia de

componentes EJB (Enterprise Java Beans). Os EJBs são utilizados em praticamente
todos os sistemas comerciais desenvolvidos em Java. O EJB é uma arquitetura de
componentes para o desenvolvimento e utilização de aplicações corporativas baseadas
em componentes distribuídos que são posicionados do lado servidor e acessados por
diferentes aplicações cliente. O interessante é sabermos que os EJBs são componentes
que implementam serviços e podem ser utilizados em qualquer sistema que tenham os
requisitos que esses componentes disponibilizam.
Modelo de métodos formais
O Modelo de Métodos Formais possui um conjunto de atividades que conduzem a uma

especificação matemática formal do software. Eles possibilitam a especificação,
desenvolvimento e a verificação de um sistema baseado em computador através da
aplicação de uma rigorosa notação matemática.
Os métodos formais ainda podem ser empregados em três diferentes níveis, são eles:
Nível 0, em que o software é descrito através de uma especificação formal que será
usada como base para a implementação do sistema. Esse nível é considerado uma
opção de menor custo-benefício;
Nível 1, em que o desenvolvimento e a verificação formal são utilizados para produzir

um programa de maneira mais formal. Este nível é mais apropriado para sistemas de
alta-integridade que necessitem de segurança ou confiança;
Nível 2, em que provadores de teoremas podem ser utilizados afim de conduzir teste
completos das propriedades de um sistema de forma mais automatizada. Este nível é
mais apropriado em sistemas que o custo provocado por erros é extremamente alto.
A vantagem dos métodos formais durante o desenvolvimento é que eles oferecem a

eliminação de diversos problemas encontrados em outros modelos como a
ambiguidade, incompletude e a inconsistência. Todos esses problemas podem ser
16
descobertos e corrigidos mais facilmente com a aplicação da análise matemática. Nos
outros paradigmas eliminamos esses problemas por meio de uma revisão local, o que
de certa forma é menos eficaz. Os métodos formais, quando utilizados durante o
projeto, servem para verificar a programação, possibilitando assim a descoberta e a
correção de erros que poderiam passar despercebidos.
Mesmo oferecendo a garantia de software sem defeitos, o modelo de métodos formais

está longe de ser uma abordagem predominante em ambientes de negócios. Um dos
motivos para o modelo não ser uma abordagem muito utilizada nesses ambientes é
que eles consomem muito tempo e dinheiro. Além disso, esse método requer
desenvolvedores com formação e experiência necessária para a aplicação dos métodos
formais, além de treinamento extensivo. Por fim, os métodos formais também são
difíceis de serem utilizados como um meio de comunicação com clientes, já que os
mesmos não são tecnicamente preparados para usar esses modelos.
Modelos de métodos formais são mais utilizados quando precisamos desenvolver

softwares com fator crítico de segurança, assim como software que sofreriam pesados
problemas econômicos se ocorressem erros no software. Exemplos de software onde
os métodos formais são aplicados são os sistemas aviônicos para aeronaves,
engenharia aeroespacial e equipamentos médicos.
Processo Unificado
O Processo Unificado é um processo de desenvolvimento fortemente ligado à

orientação a objetos, porém, pode-se utilizá-lo em qualquer projeto mesmo sendo ele
estruturado, sem que perca suas características básicas. Ele utiliza alguns princípios
modernos (componentização, revisões, etc) na área de engenharia de software.
Algumas características básicas do Processo Unificado são:
Direcionado por casos de uso: O início do processo deve ser marcado pela utilização
dos casos de uso, a fim de se definir uma linguagem entre os usuários e o sistema,
facilitando a especificação dos requisitos.
Centrado na arquitetura: O processo procura modelar uma arquitetura através dos

aspectos estáticos e dinâmicos de um projeto, que podem ser obtidos junto a um
estudo direcionado pelos casos de uso mais significativos.
É iterativo e incremental: Uma das práticas do processo é dividir grandes projetos em

miniprojetos. Cada miniprojeto possui uma iteração, que quase sempre abrange todo o
fluxo de trabalho. Olhando como um todo, essa iteração resulta em um incremento
para o projeto. É válido lembrar que as iterações são planejadas de acordo com os
casos de uso.
O Processo Unificado visa tornar clara a necessidade de atribuições de tarefas a

grupos ou indivíduos envolvidos diretamente no desenvolvimento de um projeto. Além
disso, deve-se definir o quanto antes, quais as etapas (iterações) e os artefatos que
serão envolvidos durante o processo. Com essas características, conclui-se que o
17
Processo Unificado é um modelo configurável, ou seja, deve ser ajustado de acordo
com os tipos de projeto que se necessita desenvolver.
Figura 5 - Overview do Processo Unificado
Concepção ou iniciação: Essa fase tem como objetivo verificar a viabilidade do projeto,
bem como os riscos e um dos fatores não menos importantes: definir os casos de uso
mais críticos obtendo as funções chave do sistema. É através do tipo do projeto, dos
casos de uso e consequentemente dos requisitos, que se realizará o ajuste de quantas
iterações o processo terá. De acordo com os casos de uso, pode-se definir também
quais as etapas exigirão maior cuidado.
Elaboração: Durante essa fase, a maioria dos casos de uso são especificados e
detalhados. A arquitetura do sistema é projetada utilizando artefatos que podem ser
estáticos ou dinâmicos. Neste instante são apresentados, o Baseline completo do
projeto, os componentes que formarão a equipe de desenvolvimento, etc. No final
dessa fase os envolvidos devem estar aptos a planejar a fase de construção em
detalhes.
Construção: A fusão de vários artefatos de software ocorre neste momento,

possibilitando que o sistema seja implementado quase que completamente. Tem-se
uma visão geral de como o Baseline do projeto está sendo seguido. No final dessa
fase, o sistema deve estar totalmente preparado para a transição ao usuário.
Transição: O objetivo dessa fase é garantir que todos os requisitos do projeto foram
atendidos e implementados corretamente. O produto final pode ser liberado em uma
versão beta. Existem ainda outras atividades que, de acordo com o projeto, podem
ocorrer de maneira paralela, por exemplo, a preparação do ambiente, a conclusão do
manual do usuário, identificação e correção de defeitos. No final dessa fase deve-se
tirar uma conclusão geral do projeto, obtendo os pontos positivos e negativos os quais
devem ser utilizados durante a concepção de projetos futuros.
Em relação aos fluxos de trabalho, ou disciplinas, tem-se os seguintes

esclarecimentos.
18
Modelo do negócio: O objetivo principal desse fluxo é que o fornecedor entenda muito
bem o problema a ser resolvido, elaborando se necessário uma análise de risco e de
viabilidade para o projeto como um todo. Neste momento, existe uma grande
interação entre o fornecedor e o cliente. A fim de que possam ser gerados os casos de
uso e consequentemente a extração dos requisitos. Entender o modelo de negócio do
cliente é peça fundamental antes que um requisito possa ser definido.
Requisitos: Nesse fluxo procura-se extrair os requisitos do sistema a ser desenvolvido.

A grande dificuldade nesta etapa e no desenvolvimento de software é capturar
requisitos de forma que os clientes possam entender claramente o que o sistema se
propõe a fazer. A base para isso é que o fornecedor entenda o domínio do problema e
consequentemente construa um bom modelo de casos de uso. A extração dos
requisitos, através dos casos de uso, irá compor um artefato que será evoluído durante
todo o projeto.
Análise e Projeto: No início desse fluxo de trabalho, desenvolve-se uma visão

“arquitetural”, incluindo os artefatos significativos para o modelo de projeto. O objetivo
aqui é compreender os casos de uso mais importantes, que serão insumos para a
elaboração de alguns artefatos, como: um diagrama de classes, de estado, de iteração,
de sequência, de colaboração, etc. É válido lembrar que não é necessária a utilização
de todos os artefatos, mas apenas aqueles que sejam relevantes a fim de que o cliente
entenda perfeitamente o que será construído. Com artefatos bem elaborados, a equipe
de desenvolvimento terá grandes facilidades em realizar a implementação. No início
deste fluxo encontra-se, caso necessário, protótipos de funcionalidade e de interface,
como também uma descrição da arquitetura básica do sistema. Durante o
desenvolvimento do projeto alguns artefatos poderão sofrer ajustes de acordo com as
implementações realizadas.
Implementação: No início desse fluxo, os desenvolvedores poderão buscar

componentes (funções) que foram utilizados em outro sistema. Ainda na fase de
concepção, pode-se ter um protótipo de funcionalidade como um produto final em
primeira instância. No decorrer deste fluxo, procura-se ter um sistema executável a
cada iteração, além da implementação baseada nos artefatos criados no modelo de
análise e projeto. O conceito de componentização deve ser sempre levado em
consideração, com o intuito de que estes segmentos de códigos possam ser
aproveitados mais tarde por outros sistemas.
Testes: Neste fluxo, um plano de teste deve ser elaborado, definindo e identificando
qual procedimento e quais tipos de testes serão realizados. Esse plano poderá ser
alterado de acordo com a melhor definição dos requisitos do sistema. Ele também
poderá ser utilizado durante todo o projeto, sendo modificado a cada iteração,
mostrando a situação do executável que foi entregue ao cliente. Nas fases de
concepção e de elaboração têm-se os testes de módulos e na fase de construção têm-
se os testes de integração. O número de testes de integração poderá se repetir de
acordo com a quantidade de alterações nos requisitos do sistema.
Implantação: Descreve-se nesse fluxo de trabalho, a instalação do sistema no

ambiente do cliente. Durante toda a fase de elaboração, até o meio da fase de
construção, um simples documento especificando algumas características do ambiente
do cliente poderá ser realizado. Este artefato pode conter, por exemplo, especificações
técnicas sobre a infraestrutura de rede e de sistemas suportada pela empresa
contratante. Além disso, algumas dicas de instalação podem ser acrescentadas nesse
19
artefato de forma a reduzir mais tarde, o número de erros de instalação e
consequentemente o tempo de testes. No final da fase de construção, inicia-se a
migração do sistema para o ambiente de testes do cliente. Posteriormente, no final da
fase de transição, já se pode observar a completa migração e configuração do sistema
no ambiente de produção do cliente.
Gerência de configuração e mudança: É durante esse fluxo de trabalho que são

controlados todos os artefatos do projeto, bem como suas versões. Antes de realizar
uma mudança, deve-se fazer uma análise em relação ao que deve ser modificado e
saber em quais artefatos e áreas da implementação isso irá afetar. Um bom controle
de mudança é crucial para garantir o sucesso e a qualidade do projeto. À medida que
o projeto entra na fase de construção, a dificuldade no controle de mudança e
gerência de configuração aumenta. Isso ocorre porque o projeto está maior, com mais
requisitos implementados e com maiores chances de que uma alteração possa afetar
outras áreas do sistema. Ter rastreabilidade e saber relacionar os requisitos é uma
tarefa importante do engenheiro de software. Após uma modificação, necessita-se de
novos testes em várias áreas do sistema, garantindo que a mudança foi implementada
corretamente. Não menos importante, a alteração da documentação deve estar
completamente condizente com o que foi implementado.
Gerenciamento de projeto: Nesse fluxo se escolhe os artefatos a serem utilizados no

desenvolvimento da aplicação, de acordo com o tipo do projeto e o entendimento do
cliente. O gerente deve ter uma visão clara do que o cliente deseja, do que está
documentado e do que está sendo implementado. A atividade de gerenciamento de
projeto é constante durante todo o ciclo de vida do software, elaborando reuniões com
RTF (Revisão Técnica Formal), garantindo a correta mudança dos artefatos, além da
necessidade de manter um bom relacionamento com o cliente.
Ambiente: Esse fluxo representa o ambiente de trabalho da empresa que desenvolverá

o projeto. Ele pode ser caracterizado pelo tipo de plataforma, pela rede, pela
organização dos diretórios no qual ficarão os artefatos e os códigos fonte, pelo sistema
de backup etc. Pode-se perceber que no final de cada iteração, têm-se ajustes no
ambiente. Esses ajustes podem ser do tipo: criação de diretórios, o backup das versões
do software, etc.
As iterações, nada mais são do que marcos durante a construção de um sistema

utilizando o Processo Unificado. Um aspecto muito importante é que o número de
iterações deve ser definido logo no início de cada projeto (elas podem variar de
número de acordo com o tamanho do sistema a ser desenvolvido). Uma iteração
normalmente é marcada pela entrega de uma versão executável do sistema e uma
reunião formalizada através de uma RTF (Revisão Técnica Formal). Em geral, o
resultado de uma iteração é um incremento para o sistema. Entende-se também que
uma iteração é como se fosse uma “foto” tirada da aplicação num determinado
instante. É um marco indicando o final de um miniprojeto.
20
Desenvolvimento Ágil de Software
Desenvolver softwares é uma atividade difícil e arriscada. Segundo as estatísticas,
entre os maiores riscos estão: gastos que superam o orçamento, consumo de tempo
que supera o cronograma, funcionalidades que não resolvem os problemas dos
usuários, baixa qualidade dos sistemas desenvolvidos e cancelamento do projeto por
inviabilidade.
No conceito tradicional, metodologia de desenvolvimento de software é um conjunto

de atividades e resultados associados, que auxiliam na produção de software. Todas as
metodologias de desenvolvimento tentam, entre outras coisas, reduzir o alto risco
associado ao desenvolvimento de software.
O desenvolvimento ágil é um fruto da constatação feita, de forma independente, por

diversos profissionais renomados na área de engenharia de software, de que, apesar
de terem aprendido segundo a cartilha tradicional, só conseguiam minimizar os riscos
associados ao desenvolvimento de software, pensando e agindo de forma muito
diferente do que tradicionalmente está nos livros. Estes profissionais, a maioria
veteranos consultores para projetos de softwares, decidiram reunir-se no início de
2001 durante um workshop realizado em Snowbird, Utah, EUA.
Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos
concordavam que, em suas experiências prévias, os projetos de sucesso tinham em
comum um pequeno conjunto de princípios. Com base nisso eles criaram o Manifesto
para o Desenvolvimento Ágil de Software, ou apenas Manifesto Ágil. Este identifica
metodologias de desenvolvimento que adotam os princípios do manifesto ágil. Estes
princípios são os seguintes:
· Indivíduos e interação entre eles mais que processos e ferramentas
· Software em funcionamento mais que documentação abrangente
· Colaboração com o cliente mais que negociação de contratos
· Responder a mudanças mais que seguir um plano
No desenvolvimento ágil, os projetos adotam o modelo iterativo e em espiral. Neste

processo, todas as fases descritas no modelo em cascata são executadas diversas
vezes ao longo do projeto, produzindo ciclos curtos que se repetem ao longo de todo o
desenvolvimento, sendo que, ao final de cada ciclo, sempre se tem um software
funcional, testado e aprovado. Os ciclos são chamados de iterações e crescem em
número de funcionalidades a cada repetição, sendo que, no último ciclo, todas as
funcionalidades desejadas estarão implementadas, testadas e aprovadas.
21
Figura 6 - Desenvolvimento iterativo em espiral
Premissas do Desenvolvimento Ágil

 O cliente aprende ao longo do desenvolvimento, à medida que é capaz
de manipular o sistema.
Um dos problemas mais complexos que afetam o desenvolvimento de software é a

enorme quantidade de detalhes que precisam ser considerados. Normalmente, ao
especificar um sistema, o cliente tem o conhecimento de alguns aspectos do software
que deseja. Entretanto, muitos outros só ficam claros quando ele tem a oportunidade
de utilizar o sistema. Portanto, o cliente não especifica estes detalhes no início do
projeto por uma razão muito simples: ele não os conhece. Além do mais, mesmo que
tais detalhes fossem conhecidos previamente, seria muito difícil especificá-los através
de documentos, devido à grande quantidade de elementos que precisariam ser
descritos.
Perceber que o cliente aprende ao longo do desenvolvimento é a chave para se

compreender o grande desafio existente no desenvolvimento de software. O cliente
aprende à medida que tem acesso ao sistema e se envolve em discussões sobre ele.
Este aprendizado pode ser utilizado para realimentar o processo de desenvolvimento
ou pode ser ignorado. Esta última alternativa é o caminho adotado normalmente no
desenvolvimento tradicional, pois ele parte da premissa que o cliente já sabe o que
quer no início do projeto e a ele cabe apenas descrever os requisitos. Depois, ao final,
ele receberá o sistema e não haverá ciclos de realimentação entre a especificação e a
entrega do sistema.
 O custo de uma alteração mantém-se estável a partir de um certo ponto

no projeto.
Ao contrário do desenvolvimento tradicional que acredita que o custo de uma mudança

cresce exponencialmente a medida que o tempo de desenvolvimento avança, no
desenvolvimento ágil acredita-se que o custo de mudança do software ao longo do
tempo tende a se tornar constante. Tal ideia se fundamenta, entre outros, nos
seguintes fatores: avanços ocorridos na microinformática, adoção da orientação a
objetos, uso da refatoração para aprimorar e simplificar o design, adoção de testes
automatizados, melhores linguagens e ambientes de desenvolvimento.
22
Figura 7 - Custo de alterações no desenvolvimento ágil e no desenvolvimento
tradicional.
As duas premissas anteriores ajudam a explicar algumas das posições totalmente

opostas adotas pelos dois modos de desenvolvimentos. Por exemplo, no
desenvolvimento ágil, modificações no projeto são naturais, pois não existe nenhum
custo exponencial associado às alterações. Ou seja, não existe nenhuma necessidade
de tentar especificar detalhadamente tudo que ocorrerá durante a implementação do
sistema, para tentar minimizar possíveis alterações, até porque, isto dificilmente traz os
resultados esperados.
EXTREME PROGRAMMING
XP é um apelido carinhoso de uma nova metodologia de desenvolvimento designada
Extreme Programming, com foco em agilidade de equipes e qualidade de projetos,
apoiada em valores como simplicidade, comunicação, feedback e coragem que nos
submetem ao reconhecimento de que XP é uma metodologia baseada em
comportamentos e atitudes. Dessa forma, ela propicia que o projeto seja executado
dentro do prazo e do orçamento, fazendo então com que o cliente esteja satisfeito e a
equipe de desenvolvimento não fique maluca por causa do projeto.
Vale lembrar, que ao contrário do que se pensa, XP pode ser aplicada em projetos de
vários portes, pois seu dinamismo é tão latente, que permite seu uso por equipes
criativas em qualquer projeto.
É importante lembrar também que os valores citados acima, alicerçam a metodologia,
pelos seguintes motivos:
 A simplicidade é necessária desde a forma como se levanta requisitos até a

codificação e os testes da solução desenvolvida;
 A comunicação é obrigatória para que não haja lacunas em processos e
problemas entre equipe, cliente e fornecedor;
 O feedback é a pratica fundamentada em retornar informações entre os
membros da equipe e também na relação com o cliente, desde responder e-
mails, telefonemas bips e demais meios. Devido a isso, é um mecanismo para
melhorar a prática de comunicação explanada acima;
23
 E a coragem para saber dizer NÃO quando necessário, ou então para dizer que
o projeto vai demorar além do estimado, pois os novos requisitos precisam ser
codificados ou o código já em funcionamento precisa ser refatorado.
Extreme Programming é dinâmica e flexível, porém, é necessário muita disciplina para

usá-la em um projeto. Para demonstrar isso, abaixo temos um conjunto sugerido de
"boas práticas" em projetos usando XP.
As boas práticas do XP
O cliente sempre disponível: Constante disponibilidade do cliente para colaborar em
dúvidas, alterações, e prioridades em um escopo, ou seja, dando um dinamismo ativo
ao projeto.
Uso de metáforas no projeto: Visando facilitar a comunicação da equipe, caso seja

possível, é estabelecido o uso de metáforas em pontos chaves ao projeto como, por
exemplo, a definição de um nome que seja comum à equipe e simbolize algo de fácil
assimilação como, por exemplo: "Vamos chamar nosso projeto de "cartão de ponto",
para um sistema que gerencie as batidas de ponto de funcionários, gerando o
provisionamento financeiro e mensal para módulo de folha de pagamento".
Planejando o jogo: Entre o cliente e os técnicos são estimuladas reuniões usando

quadros brancos, com o objetivo de captar e definir as "user stories" (estórias, que são
textos claros ou diagramas com notação UML com as especificações de regras de
negócios inerentes ao sistema). E, também para poder estimar o tempo ideal das
interações, o projeto como um todo, elaborar estratégias e tentar prever as
contingências para projeto.
Essa prática é fundamental para elaborar a estratégia das interações, que é a forma
como se trabalha o "cronograma" de um projeto com XP, onde basicamente define-se
um tempo padrão para as interações e especifica-se quais e quantas estórias podem
ser implementadas em uma interação.
Exemplo: digamos que seja definido o tempo padrão de 2 semanas para cada
interação e que temos 60 estórias a serem implementadas. Em seguida, iremos
analisar os requisitos (estórias) e priorizá-las junto ao cliente. Após esse processo,
definimos que iremos implementar 4 estórias por interação, fazendo com que as 60
estórias sejam implementadas em 15 interações (60/4), chegando a um total estimado
de 30 semanas (15*2) para que se implemente todas as estórias.
Claro que esse exemplo é bem genérico, pois nem sempre é possível estabelecer uma
organização tão exata na implementação das estórias, até mesmo porque existe uma
variação na necessidade de esforço que cada estória exige para ser implementada. É
comum que uma única estória necessite de mais uma interação ou que existam
estórias tão pequenas que devam ser agrupas em uma só interação.
Pequenas versões: Conforme as interações são concluídas, o cliente recebe pequenas

versões/releases do sistema, visando com que seja colocado em prática e validado
24
aquilo que está sendo implementado. Isto também permite que mais cedo possam ser
detectadas necessidades de alterações de requisitos no software.
Testes de Aceitação: São definidos pelo usuário na fase inicial do projeto e são os
critérios de aceitação do software conforme a estratégia de entrega e representa
exatamente a métrica de aderência do software desenvolvido/implantado ao universo
do cliente.
Primeiro os testes: Aplicados a partir de testes unitários do código produzido, além

de serem preparados utilizando os critérios de aceitação definidos previamente pelo
cliente. Garante também a redução de erros de programação e aumenta a fidelidade
do código produzido ao padrão estabelecido para o projeto. Através da prática de
testes unitários, definimos antes da codificação os testes dos métodos críticos do
software ou métodos simples que podem apresentar alguma exceção de
processamento.
Integração Contínua: Os diversos módulos do software são integrados diversas vezes

por dia e todos os testes unitários são executados. O código não passa até obter
sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de
implementação da solução.
Simplicidade de Projeto: O código está, a qualquer momento, na forma mais simples

e mais clara, conforme os padrões definidos pela equipe de desenvolvimento,
facilitando a compreensão e possível continuidade por qualquer um de seus membros.
Refatoração - melhoria constante do código: A cada nova funcionalidade

adicionada, é trabalhado o design do código até ficar na sua forma mais simples,
mesmo que isso implique em "mexer" em um código que esteja em funcionamento.
Claro que a prática de refatoração nem sempre é aceita, pois envolve questões como
prazo e custo. Além disso, e essa prática em si pode ser minimizada caso o projeto
esteja usando 100% de orientação a objeto, onde podemos criar códigos os mais
genéricos e reutilizáveis possíveis, diminuindo o trabalho em caso de uma possível
refatoração.
Programação em dupla: Todo código de produção é desenvolvido por duas pessoas

trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor, somando
forças para a implementação do código. À primeira vista pode parecer loucura, pois se
imagina estar gastando dois recursos humanos ao mesmo tempo para fazer a mesma
tarefa e sem possibilidade de avanço substancial no projeto. Mas na verdade, essa
prática tem pontos positivos como:
 Compartilhamento de conhecimento sobre das regras de negócio do projeto por

todos da equipe de desenvolvimento;
 Fortalece a prática de Propriedade Coletiva do Código;
 Nivelação de conhecimento técnico dos programadores;
 Elevação dos níveis de atenção ao código produzido, pois um “supervisiona” e
orienta o trabalho do outro. Dessa forma, minimiza-se a possibilidade de erros
25
no código, erros de lógica e produção de um código fora dos padrões
estabelecidos pela equipe.
Rodízio de pessoas: As duplas de programação são revezadas periodicamente, com o

objetivo de uniformizar os códigos produzidos, deixar todos os módulos do sistema
com mesmo padrão de código/pensamento e compartilhar o código com todos da
equipe.
Propriedade coletiva: O código é de todos da equipe: Uma vez aplicados a

Programação em Dupla e o Rodízio de Pessoas, a equipe como um todo é responsável
por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer
arquivo, mantendo claro, um padrão prático de comunicação da equipe.
Padronização do código: Todo código é desenvolvido seguindo um padrão, qualquer

que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma, todos da equipe
terão a mesma visão do código.
Otimizando as jornadas de trabalho: Trabalhar por longos períodos é

contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de
trabalho de todos da equipe, criando condições favoráveis ao uso da carga normal de
trabalho. É necessário deixar a equipe livre para relaxar, brincar, ou fazer o que bem
entender para equilibrar o trabalho mental e físico. Existe até uma frase que diz:
trabalhe a 100% durante as 40 horas e descanse a 100% no resto. Se algum deles
não for feito com 100%, um afetará o outro.
SCRUM
Histórico
A primeira referência são Takeuchi e Nonaka na Harvard Business Review de 1986, o
artigo “The New New Product Development Game” apresentou iterações, valor, times
pequenos, multifuncionais e auto-organizados.
Em 1995, Jeff Sutherland e Ken Schwaber publicaram este método e chamaram de

“Scrum” no artigo “Scrum and the Perfect Storm”, Jeff era vice-presidente na Easel e
Ken da Advanced Development Methods.
O termo Scrum vem do Ruby, é aquela jogada em que ficam todos juntos, frente a
frente ao time adversário, sempre que a bola para ou sai de campo, forçando cada
time a reagrupar, reorganizar-se e reiniciar o jogo.
Definição
O Scrum é um processo de desenvolvimento iterativo e incremental para
gerenciamento de projetos e desenvolvimento ágil de software. É utilizado para
trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer.
26
Pilares
O Scrum possui 3 pilares:
 Transparência: garante clareza e realismo

 Inspeção: leva todos a analisarem cada momento em busca de riscos e
oportunidades
 Adaptação: melhorando sempre
Como funciona?
Figura 8 - Ciclo de Vida Scrum
Sprints
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de
Sprints. O Sprint representa um tempo definido dentro do qual um conjunto de
atividades deve ser executado. Metodologias ágeis de desenvolvimento de software
são iterativas, ou seja, o trabalho é dividido em iterações, que no Scrum são chamadas
de Sprints e geralmente duram de 2 a 4 semanas.
Product Sprint Backlog

As funcionalidades a serem implementadas no projeto são mantidas em uma lista que
é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning
Meeting (uma reunião de planejamento), na qual o Product Owner (quem representa
os envolvidos) prioriza todos os itens do Product Backlog e a equipe seleciona as
funcionalidades que ela será capaz de implementar durante o Sprint que se inicia. As
funcionalidades alocadas em um Sprint são transferidas do Product Backlog para o
Sprint Backlog.
27
Kanban (Quadro de Trabalho)
O time também pode possuir um “quadro de trabalho”, também chamado de Kanban,
para organizar as atividades dos itens de Backlog da Sprint, separando-as em
basicamente em quatro estados (isso pode variar de projeto a projeto): A fazer, em
andamento, Em Testes e Concluído. Esse “quadro” é muito produtivo, pois basta olhar
para ele para realizar a leitura do progresso da Sprint.
Figura 8 – Kanban
Daily Scrum
Diariamente, em uma Sprint, a equipe faz uma breve reunião de no máximo 15
minutos com todos os participantes em pé, chamada Daily Scrum. O objetivo é cada
integrante dizer o que fez no dia anterior, o que pretende fazer no dia que se inicia e
se existe algum impedimento que está atrapalhando o seu trabalho.
Sprint Review Meeting

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma
Sprint Review Meeting onde o time mostra o que foi alcançado neste sprint.
Finalmente, faz-se uma Sprint Retrospective para identificar o que funcionou bem e o
que pode ser melhorado e a equipe inicia o planejamento do próximo Sprint.
Burn Down Chart

O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que
não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no
Sprint e o eixo Y os dias que representam o tamanho do Sprint.
28
Figura 9 – Burn Down Chart
Papéis e Responsabilidades
São 3 os papéis principais:
Product Owner
 Define os requisitos do produto, decide a data de release e o que deve conter
nela.
 É responsável pelo retorno financeiro (ROI) do produto.
 Prioriza os requisitos de acordo com o seu valor de mercado.
 Pode mudar os requisitos e prioridades a cada Sprint.
 Aceita ou rejeita o resultado de cada Sprint.
Scrum Master
 Garante que o time esteja totalmente funcional e produtivo.
 Facilita a colaboração entre as funções e áreas e elimina os impedimentos do
time.
 Protege o time de interferências externas.
 Garante que o processo está sendo seguindo. Participando das reuniões diárias,
revisão da Sprint, e planejamento.
Scrum Team
 Multifuncional, entre 5-9 membros.
 Seleciona, entre os itens priorizados, os que irão ser executados durante a
Sprint.
 Tem todo o direito de realizar o que quiser dentro da Sprint
29
Teste de software
O que é teste de software?
Investigação do software a fim de fornecer informações sobre sua qualidade em

relação ao que foi definido como necessário no contexto em que ele deve operar.
Testar também inclui o processo de utilizar o produto para encontrar seus defeitos.
O teste é um processo realizado pelo analista de testes ou pelo testador de software,

incluso nos processos da engenharia de software. Pode ocorrer na forma de testes
estáticos nas etapas de levantamento e especificação dos requisitos como também, de
forma dinâmica depois que o software já foi desenvolvido para localizar
inconformidades.
O teste de software pode ser visto como uma parte do processo de qualidade de
software. A qualidade da aplicação pode e, normalmente, varia bastante de sistema
para sistema.
Não se pode garantir que todo software funcione perfeitamente, sem a presença de
erros, visto que os softwares muitas vezes possuem um grande número de processos
com fórmulas, atividades e algoritmos complexos. O tamanho do projeto a ser
desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais
a complexidade.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode
estar errada ou incompleta, ou pode conter requisitos impossíveis de
serem implementados, devido a limitações de hardware ou software. A implementação
também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto,
uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.
Podemos ter outras definições para testes de software, como:
 Verificar que o software está fazendo o que deveria fazer, de acordo com os
seus requisitos, e não está fazendo o que não deveria fazer;
 Processo de executar um programa ou sistema com a intenção de encontrar
defeitos
De onde surgiram os Testes de Software?
Testes de Software tiveram o seu grande início no final da década de 70 na época do

lançamento de dois livros do autor Glenford Myers:
- Software Reliability Principles and Practices
- The Art of Software Testing (considerado uma das bíblias da qualidade de

Software/onde foi criado o conceito de testes de Software.
30
Os modelos prescritivos de desenvolvimento de software surgiram na década de 80.
Estes modelos, cascata, espiral, entre outros foram criados para organizar e inserir
padrões no processo de desenvolvimento de software. São compostos por vários
processos genéricos: comunicação, planejamento, modelagem, construção e
implantação.
Dentro do processo construção, estão presentes as atividades de desenvolvimento e

testes. Foi a partir desta organização que o conceito de testes de softwares tornou-se
mais conhecido. Cabe lembrar que testes também está presente em outros processos,
como planejamento, modelagem e implantação.
Neste ano, surgiram também as primeiras ferramentas para o auxílio de testes
funcionais. Com seu sucesso, surgiram novas ferramentas para gerenciamento de
testes com a intenção de organizar, manter dados, resultados e apresentar relatórios.
Sendo assim, em 1990 os fornecedores passaram a integrar em uma suíte única,

ferramentas para testes funcionais e de gerenciamento.
A partir do ano de 1995 surgiram as primeiras ferramentas para automação de testes
de performance para algumas plataformas.
No ano de 2002, surgiu no Brasil a Associação Latino Americana de Teste de Software

(ALATS). A ALATS é uma entidade sem fins lucrativos que foi criada com a finalidade
de reunir profissionais das áreas de teste e de qualidade de sistemas com o intuito de
servir de apoio a troca constante de informações objetivando a melhoria dos processos
de teste, mantendo-se a sua integração como o processo de desenvolvimento de
aplicações. (ALATS).
Em 2002 também profissionais brasileiros puderam contar com instituições

internacionais que começaram a atuar no país, como o International Software Testing
Qualifications Board (ISTQB) fundado em Edinburgh (Reino Unido).
A primeira certificação brasileira de testes foi criada pela ALATS e no ano de 2006
surgiram os primeiros profissionais certificados com a Certificação Brasileira de Testes
de Software (CBTS).
O ISTQB chegou ao Brasil em 2006 com o nome de Brazilian Software Testing

Qualifications Board (BSTQB).
Atualmente podemos encontrar uma grande quantidade de certificações, ferramentas e

conteúdo sobre testes de software. Livros, blogs, listas de discussões, são alguns
exemplos de conteúdos que podem ser facilmente encontrados.
História do primeiro BUG...
Thomas Edison teve problemas de leitura em seu fonógrafo com um inseto em 1878 e
em todos os defeitos industriais passou a denominá-los como bug. Já o primeiro bug
em computadores foi encontrado em 1945, os engenheiros que trabalhavam com a
máquina Harvard Mark I, encontraram um inseto nos circuitos. Este inseto estava
causando um erro nos cálculos da máquina. Ao ser encontrado, o inseto foi retirado e
31
colado no livro de registro com a intenção de registrá-lo como o primeiro bug
encontrado.
Figura 10 – Primeiro “bug” encontrado
Porque investir em Testes de Software?
Nas últimas décadas, a qualidade de Software tem vindo a tornar-se numa área cada
vez mais importante para o mundo da informática. A criticidade e complexidade cada
vez maior dos sistemas de informação no mundo empresarial explicam a necessidade
de melhorar a sua qualidade.
Muitos dos aviões que usamos para deslocamento (senão todos) são controlados por
softwares, o carro que utilizamos tem softwares, sistemas de pagamentos de contas,
sistemas bancários, enfim, uma afinidade de softwares doa quais todos nós
dependemos. Um erro pode colocar a vida de pessoas em risco, perdas de negócio e
produtividade, prejuízos financeiros, comprometimento da reputação da empresa, etc.
Vemos seguidamente notícias de empresas prejudicadas devido a erros em softwares
e, certamente nem todos são divulgados.
Softwares se comunicam com tudo: WebService de nota fiscal eletrônica, celulares,

internet, rede, etc. Devem se portar para os mais diversos sistemas operacionais, os
mais diversos browsers, e tudo isso leva a uma maior complexidade, não apenas de
código como também de análise, e uma boa documentação para manutenção e
continuidade dos softwares.
32
Sem um bom levantamento de requisitos, especificação e verificação a chance de erros
é enorme. Se tudo não for verificado antes do desenvolvimento haverá um grande
problema, difícil para resolver.
Se a engenharia em geral gasta seu tempo em análise, documentação, projeto e uma

série de bateria de testes, porque a engenharia de software deve ser diferente? É
preciso mudar a cultura das empresas de software para que invistam mais nestes
itens, não apenas para a melhora na qualidade do software, mas para melhorar o
rendimento da equipe interna, de novos contratados, criação de novos produtos ao
invés do foco reativo, diminuição da equipe de suporte técnico, consecutivamente dos
custos da empresa, maior competitividade no mercado e um lucro maior.
Muitas empresas na busca de “maior produtividade” reduzem etapas de análise e

aumentam a de desenvolvimento. Com isso, além de ocasionar erros acabam
comprometendo o resto do processo.
Formas de condução dos Testes
Os testes podem ocorrer ainda na fase de levantamento e especificação de requisitos,

quando o analista de testes está recebendo essa documentação para fazer sua análise
de teste. Desta forma os custos de um erro ainda estão baixos, pois requer um
pequeno retrabalho para arrumar e corrigir os requisitos. Tais testes são conhecidos
como estáticos, pois ocorrem antes de ter um software desenvolvido.
Os testes dinâmicos ocorrem após o software estar desenvolvido e são executados

pelos testadores, com base na análise de testes (feita pelo analista de teste). Eles
visam detectar inconformidades que ocorreram no desenvolvimento antes que o
software seja liberado ao cliente.
Custos
O custo da qualidade sempre vai existir. Podemos comparar este custo ao de

apresentação de qualquer profissional, como nós, por exemplo. Se nos vestirmos
adequadamente ao ambiente que convivemos, vamos ter um “custo” com isso, porém,
se não fizermos isso e andarmos em desacordo isso também vai ter um custo, que
embora não seja um valor financeiro, pode até ser um valor maior e é um valor social
que pode ser representado por uma falta de oportunidade de crescimento, falta de
convites para frequentar determinados locais ou até pelo descaso das pessoas daquele
meio.
No mundo do software ocorre da mesma forma, a medição da qualidade está implícita

ao software e naturalmente terá um custo, assim como o próprio processo de
desenvolvimento tem. Este custo vem na forma de profissionais para a área,
ferramentas, softwares e hardware que são necessários para efetuar o trabalho.
Caso a empresa opte por não ter esta área, não terá também a qualidade
assegurada... com isto aumenta significativamente o retrabalho do desenvolvimento e
também a insatisfação e insegurança do cliente, perda de oportunidades, degradação
da imagem e desgastes profissionais.
33
Porém, há uma forma correta de trabalho que apresenta um custo aceitável para
assegurar qualidade ao software e garantir a satisfação à empresa, que é incluir os
testes nas primeiras etapas do ciclo de vida de desenvolvimento.
Regra 10 de Meyers
Glenford Myers é o autor do livro “The Art of Software Testing“, considerado por
muitos como a primeira obra de real valor sobre teste de software e a criadora de
termos muito usados como “Caixa Branca e Caixa Preta” e “Caso de Teste”. Quase
todas as palestras, seminários e obras acadêmicas que existem no mercado tem
influência direta desse autor, sem falar em uma das “leis” mais citadas em
certificações, livros e empresas: A Regra 10 de Myers.
Esta regra estabelece que o custo da correção de defeitos é bem mais custoso quanto
mais tarde o defeito é encontrado. Ou seja, um defeito encontrado em produção custa
muito mais do que se fosse encontrado na fase de análise ou em modelos de dados.
Figura 11 – Regra 10 de Myers
Meyer diz que um erro for encontrado na fase de levantamento de requisitos, o custo
dele é de $ 1,00 - quando um erro for encontrado na etapa de especificação de
requisitos, o custo é de $ 10,00 - quando o erro for encontrado na etapa de
estrutura/layout, o custo é de $ 100,00 - quando o erro for encontrado na etapa de
programação, o custo é de R$ 1000,00.
Desta forma, quando executamos testes com o sistema já pronto, a única coisa que
evitamos é que este erro tenha o valor de $ 10.000,00 que é o preço que Meyer diz
que ele vale, quando encontrado em produção.
Também por este fator é que se torna tão importante que se teste a documentação do
software, pois, se encontrarmos erros nesta fase, o custo será bem menor.
34
Ciclo de desenvolvimento em V
O Modelo V é uma variação do modelo cascata, que demonstra como as atividades de
testes estão relacionadas com analise e projeto.
Este modelo propõe que os níveis de teste obedecem e estão relacionados diretamente
a cada fase de análise e desenvolvimento e que, a cada nível de teste esta
documentação, no nível de detalhamento dela, deve ser verificada e validada.
Também, durante os testes de unidade e de integração, os programadores e a equipe
de testes devem garantir que todos os aspectos do projeto foram implementados
corretamente no código.
A conexão entre os lados esquerdo e direito do modelo em V implica que, caso sejam
encontrados problemas durante a verificação e a validação, o lado esquerdo do V pode
ser executado novamente para corrigir e melhorar os requisitos, o projeto e a
codificação, antes da execução das etapas de testes que estão no lado direito.
Em outras palavras o modelo V torna mais explicitas algumas iterações e repetições do
trabalho, ocultas no modelo cascata. Enquanto o enfoque do modelo cascata está nos
documentos e nos artefatos, o enfoque do V está na atividade e na correção.
Figura 12 – Ciclo de Desenvolvimento em V
35
Ciclo de desenvolvimento em W
Figura 13 – Ciclo de Desenvolvimento em W
O ciclo de desenvolvimento em W é baseado no V, porém demonstra de forma mais

enfática a questão dos testes atrelada a todas as fases, desde o levantamento dos
requisitos, especificação... Isto garante um ciclo de vida saudável, redução do tempo
total de entrega do software e principalmente, não ter que arrumar, que é uma
atividade que compromete cerca de 70% do tempo das empresas, corrigindo
problemas ocasionados por versões colocadas em produção com erros.
Validação e Verificação
O objetivo da Validação e da Verificação é assegurar que o SW seja adequado e se
atende às necessidades, ou seja, a confirmação de que este cumpra suas
especificações.
A Verificação é uma atividade, a qual envolve a análise de um sistema para certificar

se este atende aos requisitos funcionais e não funcionais. Já a Validação, é a
certificação de que o sistema atende as necessidades e expectativas do cliente. O
processo de Validação e Verificação, não são processos separados e independentes.
A verificação é o processo de certificar que a documentação (requisitos, definições,

diagramas, etc) estão corretas e fornecendo o grau de detalhamento necessários para
que a solução possa ser testada.
A validação só é possível de ser feita depois que o software está desenvolvido. Neste
momento pode-se validar se este atende o que o cliente precisa (de acordo) com o
que foi levantado como necessidade.
36
Níveis de Teste
Níveis de teste de software
O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao

desenvolvimento do software.
Os principais níveis de teste de software são:
Teste de Unidade: também conhecido como testes unitários. Tem por objetivo
explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por
defeitos de lógica e de implementação em cada módulo, separadamente. O universo
alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de
código. – Realizado pelos desenvolvedores.
Teste de Integração: visa provocar falhas associadas às interfaces entre os

módulos quando esses são integrados para construir a estrutura do software que foi
estabelecida na fase de projeto. – Realizado pelos desenvolvedores com o auxílio dos
testadores.
Teste de Sistema: avalia o software em busca de falhas por meio da utilização do

mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos
mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada
que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o
produto satisfaz seus requisitos. - Realizado pelos testadores com base na
documentação (Casos de Teste) que foram especificados pelos Analistas de Teste.
Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários

finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se
seu comportamento está de acordo com o solicitado. – Realizado unicamente pelo
cliente (usuário final). Pode ocorrer em dois ambientes:
Ambiente BETA: é o ambiente do cliente, onde o software vai rodar quando

estiver em produção.
Ambiente ALPHA: é o ambiente nativo do sistema, onde ele foi desenvolvido.
Objetivos do Teste
Os objetivos do teste são prover a qualidade esperada pelo cliente na solução que vai
ser entregue a ele, no sentido de atender à sua necessidade, fazendo o que necessário
que seja feito e não fazendo o que não deve ser feito. Dessa forma o cliente se sente
seguro e atendido. À medida que isto é garantido, todo o ciclo natural também é
mantido, a empresa pode viver o seu ciclo de projeto e os profissionais que ela atuam
se sentem confortáveis e confiantes.
37
Principais causas do fracasso em Teste
Sem dúvida o maior problema do fracasso em testes de software, ou, no projeto como
um todo são os requisitos mal definidos. Isto somado a uma cultura de testar apenas
quando o software está pronto somo por si só um sério problema de qualidade, de
custo, desgaste, etc. Ainda, quando a cultura da empresa não permite ao Analista de
Teste questionar os requisitos ou, ele não faz por se sentir “envergonhado”, os casos
de teste ficam incompletos e os testes não são válidos, sendo impossível garantir a
qualidade.
Outro problema bastante comum de ocorrer é o mau dimensionamento da equipe de

testes. Tal fato ocorre por dois motivos:
A gerencia do projeto não pede orçamento para a área de testes e

simplesmente define um valor e uma equipe de acordo com o seu conhecimento
O escopo do projeto não é bem definido no início, quando é alocada a equipe

de testes. Durante o andamento é que se vê a real necessidade e aí não tem mais
tempo ou orçamento. Muitas vezes descobrimos que precisávamos efetuar outros
tipos de teste ou utilizar estratégias que não foram pensadas no início.
Quando o projeto apresenta muitos erros, a equipe de testes não vê o seu trabalho
“dar resultado” e se desmotiva, a ponto de não dar a devida atenção. Isto também é
comum de ocorrer quando o conserto de alguns erros entra em descrédito, ou porque
as correções ditas como feitas não ocorreram na realidade, ou porque geraram mais
erros.
Também é comum a equipe de desenvolvimento usar mais tempo do que o previsto e

sobrar pouco tempo para testar a aplicação, de forma que não se possa efetuar todos
os testes programados.
Outro problema menos comum, mas bastante sério é uma equipe de desenvolvimento
usar mais tempo do que o previsto e sobrar pouco tempo para estar a aplicação, de
forma que não se possa efetuar todos os testes programados.
Outro problema menos comum, mas bastante sério é uma equipe de testes pouco
qualificada. Isto hoje em dia não é mais uma realidade constante, mas, já foi. Épocas
atrás não existiam formações e quem atuava na área eram antigos programadores e
técnicos da área de negócios sem utilizar qualquer metodologia para definir cenários
de teste ou para testar, apenas seu conhecimento.
Até quando devemos testar?
A questão: “Até quando testar? ” Está intimamente ligada ao tipo de cenário que você
possui.
38
De uma forma geral podemos dizer que devemos testar todos os cenários positivos,
negativos e alternativos. Depois de testados e registradas as inconformidades, temos
que nos certificar que pelo menos as inconformidades registradas como críticas foram
resolvidas. Se o contexto permitir, pode-se aguardar até os de prioridade normal,
mínima, etc. Porém, dependendo do tipo de software, por exemplo, algum que
represente um risco de vida, temos que nos certificar que “todos” os cenários foram
pensados, executados e tudo está resolvido. Assim como, o teste de regressão foi
executado com sucesso.
Defeito, erro e falha
O ser humano está sujeito a cometer um erro (engano), que produz um defeito (falha,
bug), no código, em um software ou sistema ou em um documento. Se um defeito no
código for executado, o sistema falhará ao tentar fazer o que deveria (ou, em algumas
vezes, o que não deveria), causando uma falha. Defeitos no software, sistemas ou
documentos resultam em falhas, mas nem todos os defeitos causam falhas.
Os defeitos ocorrem porque os seres humanos são passíveis de falha e porque existe
pressão no prazo, códigos complexos, complexidade na infraestrutura, mudanças na
tecnologia e/ou muitas interações de sistema.
Falhas também podem ser causadas por condições do ambiente tais como: radiação,
magnetismo, campos eletrônicos e poluição, que podem causar falhas em software
embarcado (firmware) ou influenciar a execução do software pela mudança das
condições de hardware.
Figura 14 – Defeito, erro e falha
39
Cargos comuns na área de Teste de Software
A maioria dos cargos de teste de software se engloba dentro destas categorias:
Analista de Teste
Responsabilidades:
 Elaborar Plano de Teste
 Elaborar Casos de Teste
 Identificar e definir os testes necessários
 Monitorar a abrangência dos testes
 Avaliar a qualidade geral obtida ao testar
 Definir necessidades
 Avaliar e apresentar os resultados
Diferenciais:
Conhecer áreas de negócio/processos.
Testador de Software
Responsabilidades:
 Executar os testes funcionais de acordo com os Casos de Teste
 Registrar inconformidades encontradas
 Re-testar inconformidades resolvidas
Diferenciais:
Automatizador de Teste
Responsabilidades:
 Elaborar Scripts de Teste
Diferenciais:
Conhecer ferramentas de automação de teste
Habilidades de Programação
40
Conhecer áreas de negócio/processos
Técnico de Teste de software
Responsabilidades:
 Configurar hardware e software para teste
 Executar scripts de teste
 Isolar e reproduzir erros
 Registrar inconformidades encontradas
Diferenciais:
Conhecer hardware/suporte.
Noções básicas de programação
Líder de Teste
Responsabilidades:
 Liderança de um projeto de teste específico
 Elaborar Plano de Teste
 Elaborar Casos de Teste
 Identificar e definir os testes necessários
 Avaliar e apresentar os resultados
Diferenciais:
Habilidade para liderar pessoas.
Arquiteto de Teste
Responsabilidades:
 Definir a infraestrutura de teste
 Criar a arquitetura e o ambiente para execução dos testes
 Escolher as ferramentas de teste
41
 Treinar/Capacitar as pessoas para executarem o trabalho no ambiente
criado.
Diferenciais:
Engenheiro de Teste
Responsabilidades:
 Criar estratégias de teste
 Executar testes especiais, tais como:
o testes de performance
o carga
o stress
o segurança, etc
Diferenciais:
Gerente de Teste - Coordenador de Teste
Responsabilidades:
 Gerenciar/Coordenar a equipe de testes
 Planejar/Acompanhar:
o os processos de teste
o todos os testes
o cronograma de atividades dos demais papéis da equipe de teste
o indicadores de produtividade para medir o esforço
o índice de qualidade do processo de validação do software.
o métricas dos testes
o Planos e Casos de Teste
42
Consultor em Teste
Responsabilidades:
 Apoiar os gestores na área de qualidade
 Auxiliar na tomada de decisões estratégicas da área
 Definir alternativas para a área
 Trazer conhecimento de mercado à empresa
Diferenciais:
Experiência na área
Visão holística
Perfil dos profissionais

• Detalhista
• Criativo
• Organizado
• Questionador
• Comunicativo
• Perfeccionista
• Conhecimentos Técnicos
Certificações da área de Teste de Software

Porque é importante fazer uma certificação?
 Aumenta as chances de se colocar no mercado

 Pode ser uma porta de entrada para quem não tem experiência
 Potencial aumento de salário
 Satisfação pessoal
 Atualização de conhecimentos
ALATS - Associação Latino Americana de Testes de Software
CBTS - Certificação Brasileira de Teste de Software
Valor: 90 dólares
Maiores informações no site:

http://www.alats.org.br/portal/certificacao.html
43
Prova em português
Não é necessário comprovar experiência na área
Prova on-line
Material: Livro Base de Conhecimento em Teste de Software
BSTQB – Brazilian Software Testing Qualifications Board
CFTL – Certified Testes Foundation Level
Valor: R$ 350,00 (trezentos reais)

http://www.bstqb.org.br/
Prova em português
Prova presencial feita em algumas capitais
Obs.: Possui outra prova para extensão para Métodos Ágeis (CFTL – AT)
Bibliografia recomendada:
– ISTQB - Glossário de Termos de Teste (BSTQB)
– Syllabus Foundation Level (BSTQB).
CTAL – Certified Tester Advanced Level
Valor: R$ 350,00 (trezentos e cinquenta reais)

http://www.bstqb.org.br/
Prova em português
É necessário comprovar experiência na área e ser certificado CTFL
O CTAL é dividido em três tipos: (cada um com sua prova)
CTAL-TA (Advanced Level Test Analyst)
CTAL-TM (Advanced Level Test Manager)
CTAL-TTA (Advanced Level Technical Test Analyst).
IBQTS – Instituto Brasileiro de Qualidade em Testes de Software
ATC – Analista de Testes Certificado
Valor: R$ 500,00 (quinhentos reais)
44
http://ibqts.com.br/
Prova em português
Bibliografia recomendada:
– Syllabus IBQTS ATC-NF
CPRE – Certified Professional for Requirements Engineering
Data da prova: São Paulo – 30 de setembro de 2016
Brasília – 07 de outubro de 2016
Valor: R$ 590,00 (quinhentos e noventa reais)

http://ibqts.com.br/
Prova em português, inglês ou espanhol
O que é Qualidade?
Qualidade é a adequação ao uso. É a conformidade às exigências. ISO -
INTERNATIONAL STANDARDIZATION ORGANIZATION.
É difícil chegar a uma definição de qualidade, se você questionar dez pessoas a

respeito dessa definição, provável que receba 10 definições diferentes. Qualidade está
ligada a sentimentos subjetivos que refletem as necessidades internas de cada um.
Muitas pessoas avaliam a Qualidade pela aparência; outras se voltam à qualidade do
material com que é feito o produto. Outras, ainda, avaliam a Qualidade de alguma
coisa pelo preço. Existem várias dimensões da Qualidade.
O aspecto objetivo, mensurável da Qualidade, é o processo e o produto é a resultante.
45
Porque as empresas buscam a qualidade?
As empresas precisam de qualidade, pois ela é hoje uma das principais estratégias
competitivas. Está intimamente ligada à produtividade, melhoria de resultados e
aumento de lucros, através da redução de perdas e do desperdício, do envolvimento
de todos na empresa e consequente motivação.
O que é Qualidade de Software?

Conformidade a: (Pressmann)
 requisitos do sistema (funcionais e não funcionais)

 padrões e convenções de desenvolvimento pós-estabelecidos
 atributos implícitos que todo o software desenvolvido profissionalmente deve
ter
“Conjunto de características que devem ser alcançadas em um determinado grau para

que o produto atenda às necessidades de seus usuários. ” [Ana R.C.Rocha 2001]
"Qualidade de software é um processo sistemático que focaliza todas as etapas e

artefatos produzidos com o objetivo de garantir a conformidade de processos e
produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002, p. 16)
A qualidade do software então, depende de determinar sob qual o ponto de vista que
vai ser medida. Podemos dizer que que cada software vai precisar focar em
determinados atributos de qualidade e, de uma forma geral, os Pilares da qualidade,
de acordo com B.Bügner seguem este modelo:
Figura 15 – Qualidade/Pontos de Vista
46
Qualidade do Produto
Esta última definição está totalmente ligada com Qualidade de Software / Qualidade do
Produto, na qual se faz uma analogia para exemplificar, iniciasse a partir da visita a
uma cafeteria, na qual a solicitação feita foi a de uma sobremesa (produto) que está
relacionada com a satisfação das necessidades (requisitos) que podem ser: aparência,
sabor, temperatura, rapidez no serviço, preço, higiene, valor nutricional, etc.
A Qualidade do produto (software) resulta das atividades realizadas no seu

desenvolvimento. Avaliar a qualidade de um produto significa verificar, através de
técnicas e atividades, o quanto os requisitos estão sendo atendidos.
Qualidade do Processo
Antes de entender qualidade do processo de software, há a necessidade de entender o
conceito de processo de software, que pode ser definido como uma sequência de
estágios para desenvolver ou manter o software, apresentando estruturas técnicas e
de gerenciamento para o uso de métodos e ferramentas e a inclusão de pessoas para
as tarefas do sistema.
Seguindo nosso exemplo de uma cafeteria, o processo seria como a sobremesa

solicitada foi realizada, ou seja, todas as etapas até chegar à sua mesa. Analisando sob
este cenário, podemos descrever mais sobre qualidade, se o que foi servido foi
desenvolvido com uma certa higiene, valor nutricional, etc.
Segundo [Jose Barreto Junior Qualidade de Software] não basta que a qualidade
exista, ela deve ser reconhecida pelo cliente, dessa forma, surgiram o que conhecemos
por certificações, as quais são emitidas utilizando como referência base algum padrão
de qualidade. Tais como:
• O selo do SIF – referente à inspeção da carne
• O selo da ABIC – existentes nos pacotes de café
• A classificação em estrelas – referência para os hotéis
• Os certificados de qualidade da série ISO
Certificação da Qualidade
Esta seção tem por objetivo tornar familiar o tema da certificação de qualidade.
Abordaremos assuntos relacionados à certificação, como: conceito de certificação,
sistema de certificação, auto certificação, vantagens
A certificação pode ser entendida como um instrumento para as empresas gerenciarem

e garantirem o nível de qualidade de seus produtos e, para informar e garantir aos
47
consumidores que os produtos certificados possuem os atributos procurados, que
podem ser intrínsecos aos produtos.
Atributos intrínsecos devem ser entendidos como atributos que não podem ser
visualizados e percebidos externamente.
A certificação, portanto, pode ser utilizada como uma ferramenta de redução da

diferença informacional. Ao comprovar a existência dos atributos intrínsecos em
determinados produtos, torna o consumidor mais seguro em relação a sua aquisição.
De acordo com [Spers, 2000] [apud LAZZAROTTO, 2001] uma utilidade dos
certificados é evitar ações oportunistas, que podem surgir quando a informação sobre
o produto específico é distribuída pelo próprio fabricante por parte de algumas
empresas, ou seja, impedir que estas aleguem processos ou ingredientes que não
realizam ou utilizam, mas que são explorados na comunicação junto aos consumidores
por serem de difícil comprovação. Daí surge à importância da reputação das
instituições certificadoras e regulamentadoras, que devem ser confiáveis e evitar essas
ações oportunistas.
O Sistema de Certificação
A certificação por terceiros envolve três fatores principais:
1. Normas;
2. Órgãos certificadores;
3. Organismos credenciadores.
Portanto, deve possuir um agente regulamentador (que dita às normas), que pode ser
o governo ou uma instituição internacional e um agente coordenador (órgão
certificador que coordena o processo), podendo ser uma associação privada, uma
organização não governamental, uma empresa privada ou uma empresa estatal.
Existe um órgão do governo responsável pelo credenciamento dessas instituições que

realizam a certificação de sistemas de qualidade no Brasil que é o INMETRO.
"O organismo certificador é uma organização coletiva que estabelece regras de

qualidade e meios para fazer respeitar essas regras, permitindo que os mercados se
formem e funcionem. (...). Esses organismos certificadores participam na construção
de referências coletivas de qualidade". [Nassar, 1999].
É importante dizer que nem sempre um certificado é diretamente de qualidade,

existem outros tipos de certificações. Além disso, nem sempre o organismo certificador
dita as normas, muitas vezes ele pode se utilizar de normas já existentes, como as
normas ISO ou ABNT e controlar se as empresas e/ou produtos certificados estão
dentro dessas normas.
Os certificados podem ser emitidos por organizações independentes, sejam elas

privadas ou públicas, nacionais ou internacionais, e pela própria empresa o que
denominaria a auto certificação.
48
O processo de certificação deve ser monitorado, ou seja, controlado para garantir que
os agentes certificados estejam realmente seguindo as normas impostas pelo agente
regulador. Esse monitoramento pode ser feito de três formas: pelo órgão regulador,
por terceiros ou através de um autocontrole, chamado também de auditoria.
Assim, segundo [Machado 2000], "a certificação é um sinal de qualidade fornecido por
uma instituição formal (terceira parte ou o Estado), essas organizações assumem a
responsabilidade de garantir a veracidade do que certificam, fundamentados nas suas
habilidades e conhecimentos técnicos, com apoio de instrumentos de testes e de
controle."
Assim, é necessária a reputação de uma entidade independente que diga que o

processo de certificação e monitoramento são confiáveis. Por isso, no mercado de
certificação é muito importante a existência da terceira parte dentro do negócio.
Quais são as vantagens da certificação?

A certificação passa sem dúvida por uma opção estratégica de desenvolvimento das
organizações, no sentido de quererem evoluir, melhorar e ganhar mercado. São
apontadas diversas vantagens, quer a nível interno ou nível externo, podendo assim
referir-se:
 Melhoria do prestígio e da imagem;

 Aumento da competitividade e entrada em novos mercados;
 Aumento da confiança dos trabalhadores, clientes e administração;
 Cultura da melhoria contínua;
 Redução de custos;
 Prevenção e minimização de aspectos, perigos e acidentes.
Quem busca por certificações entende garantir a eficiência dos processos e a

excelência dos produtos.
Abordando de forma geral, trouxemos algumas das normas mais conhecidas no

mercado.
A fim de guiar a qualidade dos produtos de software o subcomitê de software

juntamente com o Comitê Técnico Conjunto da ISO e IEC vêm trabalhando em normas
e relatórios para garantir a qualidade do produto software.
Iremos abordar em seguida a Norma ISO/IEC 9126 no que tange a Qualidade do

Produto e CMMI e MPSBr no que tange à Qualidade do Processo.
ISO/IEC 9126
ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, ela define um
conjunto de parâmetros com o objetivo de padronizar a avaliação da qualidade de
software. Ela se enquadra no modelo de qualidade das normas da família 9000. A
norma brasileira correspondente é a NBR ISO/IEC 9126.
49
Modelo de Qualidade de Software
A qualidade de um sistema de software pode ser entendida de diversas formas e

utilizando diferentes abordagens.
A norma ISO/IEC 9126, ou conjunto de normas que tratam deste assunto no âmbito
da ISO, estabelece um modelo de qualidade com os seguintes componentes:
 Produto, compreendendo os atributos de qualidade do produto (sistema) de

software. Estes atributos de qualidade podem ser divididos entre
atributos internos e externos. Estes se diferenciam pela forma como são
aferidos (interna ou externamente ao produto de software) e em conjunto
compõem a qualidade do produto de software em si;
 Qualidade em uso que consiste na aferição da qualidade do software em cada
contexto específico de usuário. Esta é, também, a qualidade percebida pelo
usuário.
Atributos de Qualidade
A norma 9126 se foca na qualidade do produto de software, propondo Atributos de

Qualidade, distribuídos em seis características principais, com cada uma delas divididas
em sub-características, conforme podemos ver na figura abaixo:
50
Figura 16 – Atributos da Qualidade
No nível mais alto temos as características de qualidade e nos quadros abaixo as suas
sub-características. Cada característica/sub-característica compõe um Atributo de
Qualidade do software.
Note que em todas as características temos uma subcategoria com o nome

de Conformidade. A conformidade é utilizada para avaliar o quanto o software obedece
aos requisitos de legislação e todo o tipo de padronização ou normalização aplicável ao
contexto.
Funcionalidade
A capacidade de um software prover funcionalidades que satisfaçam o usuário em suas

necessidades declaradas e implícitas, dentro de um determinado contexto de uso.
Suas sub-características são:
 Adequação, que mede o quanto o conjunto de funcionalidades é adequado às

necessidades do usuário;
 Acurácia (ou precisão) representa a capacidade do software de fornecer
resultados precisos ou com a precisão dentro do que foi acordado/solicitado;
51
 Interoperabilidade que trata da maneira como o software interage com outro
(s) sistema (s) especificados;
 Segurança mede a capacidade do sistema de proteger as informações do usuário
e fornecê-las apenas (e sempre) às pessoas autorizadas
 Conformidade trata da padronização, políticas e normas de um projeto.
Confiabilidade
O produto se mantém no nível de desempenho nas condições estabelecidas.
 Maturidade, entendida como sendo a capacidade do software em evitar falhas

decorrentes de defeitos no software;
 Tolerância a Falhas representando a capacidade do software em manter o
funcionamento adequado mesmo quando ocorrem defeitos nele ou nas suas
interfaces externas;
 Recuperabilidade que foca na capacidade de um software se recuperar após
uma falha, restabelecendo seus níveis de desempenho e recuperando os seus
dados;
Usabilidade
A capacidade de o produto de software ser compreendido, seu funcionamento

aprendido, ser operado e ser atraente ao usuário.
Note que este conceito é bastante abrangente e se aplica mesmo a programas que não
possuem uma interface para o usuário final. Por exemplo, um programa batch
executado por uma ferramenta de programação de processos também pode ser
avaliado quanto a sua usabilidade, no que diz respeito a ser facilmente compreendido,
aprendido, etc. Suas sub-características são:
 Inteligibilidade que representa a facilidade com que o usuário pode

compreender as suas funcionalidades e avaliar se o mesmo pode ser usado para
satisfazer as suas necessidades específicas;
 Apreensibilidade identifica a facilidade de aprendizado do sistema para os seus
potenciais usuários;
52
 Operacionalidade é como o produto facilita a sua operação por parte do usuário,
incluindo a maneira como ele tolera erros de operação;
 Atratividade envolve características que possam atrair um potencial usuário para
o sistema, o que pode incluir desde a adequação das informações prestadas para o
usuário até os requintes visuais utilizados na sua interface gráfica;
Eficiência
O tempo de execução e os recursos envolvidos são compatíveis com o nível de

desempenho do software.
 Comportamento em Relação ao Tempo que avalia se os tempos de resposta

(ou de processamento) estão dentro das especificações;
 Utilização de Recursos que mede tanto os recursos consumidos quanto a
capacidade do sistema em utilizar os recursos disponíveis;
Manutenibilidade
A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as

melhorias ou extensões de funcionalidade quanto as correções de defeitos, falhas ou
erros.
 Analisabilidade identifica a facilidade em se diagnosticar eventuais problemas e

identificar as causas das deficiências ou falhas;
 Modificabilidade caracteriza a facilidade com que o comportamento do software
pode ser modificado;
 Estabilidade avalia a capacidade do software de evitar efeitos colaterais
decorrentes de modificações introduzidas;
 Testabilidade representa a capacidade de se testar o sistema modificado, tanto
quanto as novas funcionalidades quanto as não afetadas diretamente pela
modificação
53
Portabilidade
A capacidade de o sistema ser transferido de um ambiente para outro.
Como "ambiente", devemos considerar todo os fatores de adaptação, tais como

diferentes condições de infraestrutura (sistemas operacionais, versões de bancos de
dados, etc.), diferentes tipos e recursos de hardware (tal como aproveitar um número
maior de processadores ou memória). Além destes, fatores como idioma ou a
facilidade para se criar ambientes de testes devem ser considerados como
características de portabilidade.
 Adaptabilidade, representando a capacidade do software se a adaptar a

diferentes ambientes sem a necessidade de ações adicionais (configurações);
 Capacidade para ser Instalado identifica a facilidade com que pode se instalar
o sistema em um novo ambiente;
 Coexistência mede o quão facilmente um software convive com outros instalados
no mesmo ambiente;
 Capacidade para Substituir representa a capacidade que o sistema tem de
substituir outro sistema especificado, em um contexto de uso e ambiente
específicos. Este atributo interage tanto com adaptabilidade quanto com
a capacidade para ser instalado;
Modelo de qualidade em uso
Abrange uma visão do usuário sobre a qualidade do produto quando em uso em um

ambiente especificado, dentro de um contexto de uso.
54
Figura 17 – Modelo da Qualidade
É medida em relação ao resultado da utilização do software e não em relação à

características do produto, por isso representa o efeito combinado da qualidade
externa e interna.
Figura 18 – Atributos da Qualidade em Uso
Efetividade
Definida como sendo a capacidade do produto de software possui de possibilitar ao

usuário atingir metas especificadas com acurácia e completeza, em um contexto de
uso especificado.
Produtividade
Definida como sendo capacidade do produto de software possui de possibilitar aos

usuários utilizar uma quantidade adequada de recursos em relação à efetividade
alcançada em um contexto de uso especificado.
55
Segurança
Definida como sendo a capacidade do produto de software possui de oferecer níveis

aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ao
ambiente, em um contexto de uso especificado.
Satisfação
Refere-se à capacidade de o produto de software satisfazer usuários em um contexto

de uso especificado.
O que é o CMMI®?
O CMMI® - Capability Maturity Model Integration - é um modelo de referência para

melhoria de processos criado pelo Software Engineering Institute e atualmente
mantido pelo CMMI Institute, que é vinculado à Carnegie Mellon University, situada em
Pittsburgh - EUA. A versão 1.1 do modelo foi publicada em 2002 a partir dos antigos
modelos CMM (Capability Maturity Model) para disciplinas específicas, além de outros
modelos de referência e normas então existentes.
Atualmente, o CMMI® é o modelo mais recomendado para empresas que pretendem

exportar softwares ou serviços de TI, devido à sua ampla aceitação no mercado
comprador internacional.
A versão atual do modelo CMMI® para Desenvolvimento - CMMI®-DEV, v1.3 -,

publicada em novembro de 2010, possui 22 áreas de processos distribuídas em 4
níveis de maturidade. Além do modelo para desenvolvimento, foram publicados
também os modelos de referência para aquisição de software (CMMI®-ACQ) e para
Serviços (CMMI®-SVC).
O CMMI® é um modelo de referência muito difundido e utilizado por empresas nos

cinco continentes. Segundo o relatório sobre perfil de maturidade, publicado em
março/2014* pelo CMMI Institute, desde 2007 foram realizadas 9.580 avaliações com
base no CMMI® (nas versões 1.2 e 1.3) em 6.575 diferentes organizações de 84
países.
Os 10 países com maior número de avaliações reportadas ao CMMI Institute são:
56
Figura 19 – Número de avaliações CMMi
Histórico
Na década de 1930, Walter Shewhart começou a trabalhar na melhoria de processos

com os seus princípios de controle estatístico da qualidade. Esses princípios foram
refinados por W. Edwards Deming, Philip Crosby , e Joseph Juran . Watts Humphrey,
Ron Radice, e outros estenderam esses princípios ainda mais e começaram a aplicá-los
aos softwares em seus trabalhos na IBM e do SEI. O livro de Humphrey, gerenciando o
Processo de Software, fornece uma descrição dos princípios e conceitos básicos sobre
os quais muitos dos CMMs se baseiam.
Em 1980 surgiu o CMM, como um modelo feito para a Força Aérea Norte-Americana
para avaliação de risco na contratação de empresas de software. Eles desejavam algo
para ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas
que concorriam em licitações, como indicação da previsibilidade da qualidade, custos e
prazos nos projetos contratados.
Para desenvolver este modelo, a Força Aérea constituiu, junto à Carnegie-Mellon

University, o SEI (Software Engineering Institute), o qual, além de ser o responsável
pela evolução do CMM, realiza diversas outras pesquisas em Engenharia de Software.
A partir de 1991, foram desenvolvidos CMMs® para várias disciplinas (Engenharia de

Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento
da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora
estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou
problemático. O CMMI® surgiu para resolver o problema de utilização de vários
modelos e é o resultado da evolução do SW-CMM®, SECM® (System Engineering
Capability Model) e IPD-CMM® (Integrated Product Development Capability Maturity
Model).
Os processos de melhoria nasceram de estudos realizados por Deming (Out of the

Crisis), Crosby (Quality is Free: The Art of Making Quality Certain) e Juran, cujo
57
objetivo principal era a melhoria da capacidade dos processos. Entende-se
por capacidade de um processo a habilidade com que este alcança o resultado
desejado.
Um modelo tem como objetivo estabelecer - com base em estudos, históricos e

conhecimento operacional - um conjunto de "melhores práticas" que devem ser
utilizadas para um fim específico.
O CMMI tem como origens em três outros modelos de maturidade - SW-CMM (SEI
Software CMM), EIA SECM (Electronic Industries Alliances's Systems Engineer
Capability Model) e IPD-CMM (Integrated Product Development CMM).
Sobre o CMMI
Um Capability Maturity Model, incluindo o CMMI, é uma representação simplificada do

mundo. CMMs contêm os elementos essenciais dos processos eficazes. Esses
elementos são baseados nos conceitos desenvolvidos por Crosby, Deming, Juran e
Humphrey.
1 O SEI adotou a premissa de gestão de processos, "a qualidade de um sistema ou o

produto é altamente influenciada pela qualidade do processo utilizado para
desenvolvê-lo e mantê-lo", e definiu CMMs que incorporaram essa premissa.
Dimensões:
O CMMI foi construído considerando três dimensões principais: pessoas, ferramentas e

procedimentos. O processo serve para unir essas dimensões.
58
Figura 11 – Dimensões do CMMI
Segundo o CMMI, quais são as dimensões críticas das organizações?
Figura 12 – Dimensões críticas segundo o CMMi
59
Formas de representação
Por estágio e continua.
Como funciona uma representação Por Estágio?
A representação por estágio avalia um grupo de processo e determina o grau de

maturidade da empresa.
Como funciona uma representação continua?
Identifica o grau de maturidade de apenas um processo.
Quais são os fatores de decisão da representação?

 Estratégicos: Quando a organização tem bastante conhecimento do framework
e do seu objetivo estratégico, além do forte mapeamento dos processos e
objetivos.
 Cultural: Quando a organização já tem a cultura de melhoria de processos
(representação continua) ou quando não possui cultura de melhoria de
processo (por estágio);
 Legado: Quando já utilizava um framework que pode estar mais voltado para
representação por estágio ou continua.
Componentes das Áreas de Processo
Figura 13 – Componentes das Áreas de Processo
O que são Componentes Requeridos?
Basicamente são as metas específicas e genéricas que definem o que deve ser
implementado nos processos da organização para alcança certo nível de maturidade.
O que são Componentes Esperados?
São sugestões do que pode ser implementado para satisfazer um componente
60
requerido.
O que são Componentes Informativos?
São informações para auxiliar na implementação dos Componentes Esperado e

Componentes Específicos. Como:
 Subpráticas;
 Produtos de trabalho típicos;
 Extensões;
 Orientações para aplicação de prática genérica;
 Títulos de metas e práticas, notas de metas e práticas, e referências a outras áreas de
processo.
O que é uma área de processo?
Segundo o CMMI-DEV: Uma área de processo é um conjunto de práticas relacionadas

a uma área que, quando implementadas, satisfazem a um conjunto de metas
consideradas importantes para realizar melhorias significativas naquela área.
Quais são as áreas de processos do CMMI?
NÍVEL 2 – Gerenciado
 É um processo de nível de capacidade 1 que dispõem de infraestrutura adequada
para apoiar os processos;
 É planejado e executado de acordo com uma política;
 É monitorado, controlado e revisado;
 E sua aderência em relação à descrição de processo é avaliada. Assegura que as
práticas sejam mantidas.
 Os padrões, descrições de processos e os procedimentos podem ser diferentes em
cada instância ou projeto.
Áreas de processos do nível 2 – Gerenciado

 Gerência de configuração: estabelecer e manter a integridade dos produtos de
trabalho.
 Medição e análise: desenvolver e sustentar mecanismos de medições de
processos da organização. Os resultados destas medições devem ser analisados
frequentemente a fim de identificar desvios ou variações fora dos padrões
esperados.
 Planejamento de projetos: estabelecer e manter planos para as atividades
inerentes a projetos.
61
 Acompanhamento de projetos: prover informações suficientes para o
gerenciamento eficaz do projeto. Caso o desempenho saia dos limites
especificados, ações corretivas devem ser tomadas.
 Garantia da qualidade do processo e produto: garantir que o projeto está
seguindo o processo definido e o produto atende a qualidade esperada. E prover
a visibilidade da situação atual do projeto as partes interessadas.
 Gerenciamento de requisitos: estabelecer a gestão de requisitos e seus
produtos de trabalho. E identificar inconsistências dos requisitos e dos produtos
de trabalho.
 Gerenciamento de acordos com fornecedores: gerenciar aquisições de
produtos, componentes ou serviços de fornecedores.
NÍVEL 3 – Definido
É um processo de nível 2 adaptado a partir do conjunto de processos-padrão da
organização, contribui com produtos de trabalho, medidas e outras informações de
melhoria de processo para os ativos de processo da organização. Uma distinção
importante entre os níveis 2 e 3 é o escopo de padrões, descrições de processo e
procedimentos.
Os padrões, descrições de processos e os procedimentos são adaptados a partir do
conjunto de processos-padrão da organização para se ajustar as necessidades de um
projeto específico ou uma unidade organizacional (homogeneidade)
Áreas de processos do nível 3 – Definido

 Integração de produto: integrar componentes, produtos, funções, módulos e
outros produtos de software e garantir que o mesmo seja entregue com
conformidade.
 Desenvolvimento de requisitos: analisar e desenvolver os requisitos para
compor o produto.
 Solução técnica: realizar o design, desenvolver e implementar soluções aos
requisitos identificados.
 Validação: demonstrar que o produto atende às especificações definidas quando
colocado no ambiente definido. Avalia se o produto certo está sendo
desenvolvido.
 Verificação: auditar os principais produtos a fim de verificar se eles atendem aos
requisitos definidos. Avalia se o produto está sendo desenvolvido corretamente.
 Definição do processo organizacional: estabelecer e manter um conjunto de
ativos e padrões da organização.
 Foco no processo organizacional: planejamento e implementação de
melhorais baseadas no conhecimento das forças e fraquezas da organização dos
processos e ativos da organização.
 Treinamento organizacional: desenvolver o conhecimento das pessoas para
que possam executar melhor suas atividades.
 Gerenciamento integrado de projeto: estabelecer e manter o gerenciamento
e comunicação entre as diversas equipes integradas de um projeto.
 Decisão formal: estabelecer critérios de tomada de decisão.
 Gerenciamento de riscos: gerenciar os riscos de forma pró ativa.
62
NÍVEL 4 – Gerenciado Quantitativamente
É um processo de nível 3, controlado por meio de técnicas estatísticas e outras
técnicas quantitativas.
Objetivos quantitativos para qualidade e para o desempenho de processo são
estabelecidos e utilizados como critérios de gestão do processo. A qualidade e o
desempenho de processo são entendidos em termos estatísticos e gerenciado ao longo
da vida do processo.
Áreas de processos do nível 4 – Gerenciado Quantitativamente

 Gerenciamento quantitativo de projeto: gerenciar quantitativamente os
processos definidos para alcançar a qualidade e performance estabelecidos e
previstos
 Desempenho do processo organizacional: estabelecer e manter um
entendimento quantitativo de performance do conjunto de processos da
organização bem como o entendimento dos mesmos. Também tem a função de
estabelecer linhas de base e modelos para o gerenciamento quantitativo
NÍVEL 5 – Em Otimização
É um processo de nível 4 melhorado com base no entendimento das causas comuns da
variação inerentes ao processo. O foco de um processo em otimização é a melhoria
contínua do desempenho de processo tanto por meio de melhorias incrementais
quanto de inovação.
Áreas de processos do nível 5 – Em Otimização

 Análise de Causa: identificar as causas reais dos defeitos e problemas bem
como tomar ações para prevenir que estes problemas ocorram novamente no
futuro.
 Inovação organizacional: desenvolver melhorias que estatisticamente
comprovem que houve melhora no desempenho dos processos.
Qual a diferença entre nível de capacidade e nível de maturidade?
Nível de Capacidade diz respeito a representação "Contínua" enquanto o nível de

Maturidade está relacionado à representação por Estágio.
Quais são os níveis existentes de acordo com a representação?
63
Níveis de Capacidade
Quando uma organização possui o nível de Capacidade Incompleto?
É definido quando um processo não é executado ou quando é executado parcialmente.
Quando uma organização possui o nível de Capacidade Executado?
Quando o processo satisfaz as metas específicas da área de processo em questão. Ele

ainda não está institucionalizado na organização, mas realiza o trabalho necessário
para produzir o produto esperado.
Quando uma organização possui o nível de Capacidade Gerenciado?
Quando o processo é executado de forma controlada e de acordo com a política da

organização. Nesse nível o processo é mantido mesmo em períodos de stress, além de
ser planejado e gerenciado de acordo com o plano.
Quando uma organização possui o nível de Capacidade Definido?
Quando o processo gerenciado é adaptado a partir do conjunto de processos-padrão

da organização, ele é estabelecido e aprimorado ao logo do tempo e o seu escopo em
relação ao processos, procedimento e padrões são bem maiores, além de ser mais
detalhado e rigoroso.
64
Níveis de Maturidade
Figura 14 – Níveis CMMI
Quando uma organização possui o nível de Maturidade Inicial?
Quando os processos são caóticos e a organização não fornece um ambiente estável

para apoiar os processos, nada garante que o sucesso de um produto gerado possa
ser repetido novamente.
Quando uma organização possui o nível de Maturidade Gerenciado?
Quando o processo é executado de forma controlada e de acordo com a política da

organização. Nesse nível o processo é mantido mesmo em períodos de stress, além de
ser planejado e gerenciado de acordo com o plano.
Quando uma organização possui o nível de Maturidade Definido?
Quando a descrição dos processos passa a serem utilizados em todos os projetos e em

toda a organização. Eles são evoluídos e adaptados de acordo com o conjunto de
65
processos-padrão da organização e tem características bem definidas.
Quando uma organização possui o nível de Maturidade Quantidade Gerenciado?
Quando a organização estabelece objetivos quantitativos. Enquanto no nível 3 apenas

era possível prever um resultado qualitativo, no nível 4 é possível prever um
resultado qualitativo e quantitativo.
Quando uma organização possui o nível de Maturidade Otimizado?
Quando a organização foca na melhoria continua dos processos. As melhorias são

avaliadas e medidas em relação aos objetivos quantitativos.
Áreas de Processos e Categorias
Figura 15 – Áreas de Processos e Categorias do CMMI
66
Níveis e Áreas de Processos
Figura 16 – Níveis e Áreas de Processos do CMMI
MPSBr
Introdução
Atualmente o Brasil é um país cujo desenvolvimento de produtos de software está
entre os maiores do mundo. Isto traz consigo a necessidade de padrões a serem
adotados para cumprir as exigências quanto à qualidade e complexidade dos
produtos.
É impossível competir internacionalmente no desenvolvimento de software sem dar a
devida importância à qualidade pois, “assim como para outros setores, qualidade é
fator crítico de sucesso para o setor de serviços”.
Contudo, uma certificação para melhoria dos processos de software tal qual a CMMI
possui um valor por demais elevado, inviabilizando para empresas de pequeno e médio
porte sua adoção.
Para suprir essa necessidade de melhoria dos processos de software do Brasil, foi
criada uma importante alternativa através de uma parceria entre a Softex, Governo e
Universidades, o projeto MPS.Br (melhoria de processo de software brasileiro).
Quem é a SOFTEX?
A Sociedade para Promoção da Excelência do Software Brasileiro (SOFTEX) é a
entidade responsável pelo Programa SOFTEX, que têm como objetivo o apoio à
produção e comércio do software brasileiro. Criado pelo CNPq em 1993 como
Programa Softex 2000, foi reformulado juntamente com a SOFTEX, de acordo com a
67
nova política brasileira de software e as necessidades da nova economia.
A sociedade SOFTEX é uma entidade privada, com sede em Campinas(SP), sem fins
lucrativos, que promove ações de empreendedorismo, capacitação, apoio à
capitalização e ao financiamento, e apoio a geração de negócios no Brasil e no
exterior, visando aumentar a competitividade da indústria brasileira de software. Sua
missão é transformar o Brasil em um centro de excelência mundial na produção e
exportação de software. A SOFTEX coordena as ações de 31 agentes SOFTEX,
localizados em 23 cidades de 13 unidades da federação, com mais de 300 empresas
associadas.
O Projeto MPs-BR
Iniciado em 2003, a partir de dezembro, conta com a participação de sete instituições

brasileiras: a SOFTEX, coordenadora do projeto; três instituições de ensino, pesquisa e
centros tecnológicos (COPPE / UFRJ, CESAR, CenPRA); uma sociedade de economia
mista, a companhia de Informática do Paraná (CELEPAR), hospedeira do Subcomitê de
Software da Associação Brasileira de Normas Técnicas (ABNT); e duas organizações
não governamentais integrantes do Programa SOFTEX (Sociedade Núcleo de Apoio à
Produção e Exportação de Software do Rio de Janeiro – RIOSOFT e Sociedade Núcleo
SOFTEX 2000 de Campinas). A Universidade Católica de Brasília também faz arte do
projeto.
Metas do programa a médio e longo prazo

 Meta técnica, visando à criação e aprimoramento do modelo MPS
 Meta de mercado, visando à disseminação e adoção do modelo MPS em todas as
regiões do país, em um intervalo de tempo justo, a um custo razoável,
em Pequenas e Médias Empresas (foco principal) e Grandes organizações (públicas
ou privadas)
Foram criados três modelos:
-Modelo de Referência para Melhoria do Processo de Software (MR mps).
-Modelo de Negócio para Melhoria de Processo de Software (MN mps).
-Modelo de Avaliação para Melhoria de Processo de Software (MA mps).
Este modelo de negócios prevê duas situações: -A implementação do MR mps de

forma personalizada para uma empresa (MNE – Modelo de Negócio Específico); -A
implementação do MR mps de forma cooperada em grupo de empresas (MNC –
Modelo de Negócio Cooperado), é um modelo mais acessível às micro, pequenas e
médias empresas por dividir de forma proporcional parte dos custos entre as empresas
e por se buscar outras fontes de financiamento.
68
Dois modelos de referência se destacam:
MPS-SW para Software
MPS-SV para Serviços de TI (mais recente).
Como objetivos secundários, e não menos importantes, estes modelos visam apoiar
tanto as mPME - micro, pequenas e médias empresas (foco principal) quanto as
grandes organizações públicas e privadas (foco secundário) a estabelecer um caminho
economicamente viável para que alcancem os benefícios da melhoria de processos e
da utilização de boas práticas da engenharia de software e da prestação de serviços de
TI em um intervalo de tempo razoável, a um valor justo.
Com o MPS-SW foi possível estabelecer um caminho economicamente viável para que
organizações, incluindo as pequenas e médias empresas, alcancem os benefícios da
melhoria de processos e da utilização de boas práticas da engenharia de software em
um intervalo de tempo razoável. Ele trouxe para a indústria nacional ganhos
comprovados de competitividade, por isso é considerado um marco que representa a
evolução da qualidade do software desenvolvido no país.
A iniciativa conta com o financiamento do Banco Interamericano de Desenvolvimento

(BID), a Financiadora de Estudos e Projetos (FINEP), o Ministério da Ciência,
Tecnologia e Inovação (MCTI) e o Serviço Brasileiro de Apoio às Micro e Pequenas
Empresas (SEBRAE).
MPS.BR em números
• Avaliações realizadas: 596 Software, 22 Serviços e 2 Gestão de pessoas = TOTAL

620
• Instituições Implementadoras (II): 19
• Instituições Organizadoras de Grupos de Empresas (IOGES): São 17 instituições e 72
projetos. Instituições Avaliadoras: 13
• Cursos realizados: 277
• Provas realizadas: 60
• Participantes de cursos oficiais MPS presenciais: 5974
• Participantes de cursos oficiais MPS EAD: 117
• Aprovados em provas oficiais MPS: 1416
(Dados com base em maio de 2015)
O modelo MPS-SW, ao longo de seus 10 anos de existência e graças à colaboração

ativa da Tripla Hélice (atuação sinérgica da academia, indústria e governo), permitiu
que mais de 500 empresas se beneficiassem de sua adoção. Com isso, as empresas
puderam combinar e internalizar em seus processos normas internacionais, modelos
internacionalmente reconhecidos, boas práticas da engenharia de software e as
69
necessidades de negócio da indústria de software brasileira. A evolução do
desempenho das empresas que adotaram o MPS-SW vem sendo acompanhado através
do projeto iMPS – Resultados de Desempenho das Organizações que Adotaram o
Modelo MPS, que anual e sistematicamente realiza a coleta de dados das organizações
participantes. Até o ano de 2013, o iMPS registrou em sua base histórica o total de 923
questionários referentes a 364 organizações que participaram das coletas de dados
desde 2008.
Interessante observar a variação de desempenho de um conjunto de 18 organizações

que participaram de forma consistente das últimas cinco coletas de dados anuais do
iMPS, reforçando a confiança de que o MPS-SW está internalizado e vem sendo
devidamente utilizado nestas organizações. A variação de desempenho apresentada
por estas empresas reforça a evidencia de que a busca por níveis mais altos de
maturidade é acompanhada de perspectivas de crescimento (aumento do número de
funcionários, clientes e/ou projetos). Com base nos dados históricos de caracterização
fornecidos pelas empresas que responderam aos questionários, e reforçado pela
análise dos dados históricos de desempenho mais recente de 292 organizações
distintas, sabemos que, quanto mais alto o nível de maturidade no MPS-SW da
empresa: Maior número de funcionários; Maior presença no exterior; Maiores os
projetos que consegue desenvolver (aos quais também dedica mais esforço); Maior
precisão de estimativa, fazendo com que as entregas sejam próximas dos prazos
estimados; Maior capacidade produtiva (Pontos por Função/Mês); Maior qualidade dos
produtos que entrega (menos defeitos), e; x y Menor o nível de retrabalho. A
distribuição das organizações pelas regiões do país, e a distribuição das organizações
em relação à faixa de receita operacional bruta anual (critério BNDES) e ao número de
colaboradores (critério SEBRAE/IBGE) também é objeto de análise. A distribuição pelas
regiões, pela receita operacional e pelo total de colaboradores permitiu ampliar a
compreensão a respeito de alguns resultados obtidos e evidenciar que os objetivos do
MPS-SW, ou seja, oferecer conhecimento e tecnologias de processos de software
principalmente às mPME
MPS Software
O MPS.BR é dividido em 3 componentes:
 MR-MPS – Modelo de referência

 MA-MPS – Método de avaliação
 MN-MPS – Modelo de negócio
70
Figura 17 – Componentes do MPS
Método de Avaliação (MA-MPS) – descreve o processo de avaliação, os requisitos para

os avaliadores e os requisitos para atender ao modelo de referência (MR-MPS). O MA-
MPS está descrito no Guia de Avaliação.
Modelo de Negócio (MN-MPS) – contém uma descrição das regras de negócio para três
domínios:
 do projeto MPS.BR (coordenado pela Softex),
 das instituições implementadoras do modelo MPS.BR (II_MPS) e das
instituições avaliadoras do modelo MPS.BR (IA_MPS)
 das empresas e organizações que querem fazer uso do modelo MPS.BR
para melhorar seus processos de software.
O detalhamento das regras está descrito no documento do projeto do MPS.
Modelo de Referência (MR-MPS) – contém os requisitos que as organizações devem

atender para estar em conformidade com o modelo MPS.BR. Contém as definições dos
níveis de maturidade e de capacidade dos processos, e dos processos em si.
Foi baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e é adequado ao CMMI.
O MR-MPS está descrito no Guia Geral.
71
O Guia de Aquisição é um documento complementar para empresas que pretendem
adquirir software. Não contém requisitos do MR-MPS, mas sim boas práticas para
aquisição de softwares ou serviços correlatos.
Os Guias de Implementação sugerem formas de implementar o MPS.BR nas

organizações.
Norma ISO/IEC 12207
Publicada internacionalmente em 1995 e no Brasil em 1998, passou por uma

atualização em 2002 para acompanhar a evolução da engenharia de software, as
necessidades vivenciadas pelos usuários da norma e a harmonização com a série de
normas ISO/IEC15504 – Avaliação de processos de software.
Ela estabeleceu uma estrutura comum para os processos de ciclo de vida de software
para ajudar as organizações a obter um melhor entendimento das atividades a serem
executadas nas operações que envolvem de alguma forma o software.
A estrutura da norma é composta de processos, atividades e tarefas que envolvam o

software.
A atualização de 2002 inseriu processos e acrescentou na sua descrição propósito e

resultados de implementação o que possibilita a avaliação de capacidade do processo.
A norma, incluindo o seu anexo é composta por:
 -Processos fundamentais: Aquisição, fornecimento, desenvolvimento, operação

e manutenção.
 -Processos de apoio: Documentação, Gerência de configuração, Garantia de
qualidade, Verificação, Validação, Revisão Conjunta, Auditoria, Resolução de
problemas e usabilidade.
 -Processos Organizacionais: Gerência, Infraestrutura, Melhoria, Recursos
Humanos, Gestão de Ativos, Gestão de Programa de Reuso e engenharia de
Domínio.
Cada processo é dividido em termos de suas próprias atividades e cada atividade é

definida em termos de suas tarefas. A norma estabelece uma arquitetura de alto nível
abrangendo desde a concepção até a descontinuidade do software.
72
Norma ISO/IEC 15504
Em setembro de 1992, a ISO realizou um estudo chamado “Necessidades e Exigências

para uma Norma de Avaliação de Processo de Software”. O trabalho concluiu que era
pertinente a elaboração de um padrão que fosse aplicável à melhoria de processos e a
determinação da capacidade. Este padrão deveria considerar os métodos e normas já
existentes e abranger todos os processos de software.
A ISO/IEC 15504 (SPICE) foi publicada em 2003 e contempla a realização de

avaliações de processos de software com dois objetivos: a melhoria de processos e a
determinação da capacidade de processos de uma organização.
Se o objetivo for a melhoria de processos, a organização pode realizar a avaliação

gerando um perfil dos processos que será usado para a elaboração de um plano de
melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os
riscos inerentes aos processos. No segundo caso, a empresa tem o objetivo de avaliar
um fornecedor em potencial obtendo o seu perfil de capacidade. O perfil de capacidade
permite ao contratante estimar o risco associado à contratação daquele fornecedor em
potencial para auxiliar na tomada de decisão de contratá-lo ou não. (Salviano, 2001,
ISO/IEC,2003).
O Modelo de Referência
O Modelo de Referência MR-MPS define níveis de maturidade de uma organização, que
é uma combinação entre seus processos e sua capacidade.
O MPS.BR define sete níveis de maturidade:
A – Em Otimização;
B – Gerenciado quantitativamente;
C – Definido;
D – Largamente Definido;
E – Parcialmente Definido;
F – Gerenciado;
G – Parcialmente Gerenciado.
Algumas definições para um melhor entendimento do modelo:
73
Processos
Os processos no MR-MPS são descritos em termos de:
 Propósito: Descreve o objetivo geral a ser atingido durante a execução do

processo
 Resultados esperados do processo
o - Estabelecem os resultados a serem obtidos com a efetiva implementação
do processo
o - Podem ser evidenciados por: Um produto de trabalho
produzido e/ou uma mudança significativa de estado ao se executar o
processo
Abaixo, uma imagem dos Níveis de Maturidade do MPS.BR e seus respectivos

processos:
Figura 18 – Níveis de Maturidade MPSBr
Atributo de Processo
É uma característica mensurável da capacidade do processo, aplicável a qualquer

processo [ISO/IEC 15504-1, 2004].
74
Resultado Esperado do Processo
É resultado observável do sucesso do alcance do propósito do processo [ISO/IEC
12207:1995/Amd 1:2002]. Um resultado pode ser:
 Um artefato produzido, uma mudança significativa de estado e o atendimento das

especificações, como por exemplo: requisitos, metas etc.
 Uma lista com os principais resultados do processo faz parte da descrição de cada
processo no Modelo de Referência
Capacidade do Processo
Uma caracterização da habilidade do processo em atingir os objetivos de negócio

atuais ou futuros. A capacidade do processo é representada por um conjunto de
atributos de processo descritos em termos de resultados esperados.
A capacidade de um processo no MPS.BR possui 9 atributos de processo:
 AP 1.1 – O processo é executado

 AP 2.1 – O processo é gerenciado
 AP 2.2 – Os produtos de trabalho do processo são gerenciados
 AP 3.1 – O processo é definido
 AP 3.2 – O processo está implementado
 AP 4.1 – O processo é medido
 AP 4.2 – O processo é controlado
 AP 5.1 – O processo é objeto de inovações
 AP 5.2 – O processo é otimizado continuamente
No MPS, à medida que a organização evolui nos níveis de maturidade, um maior nível
de capacidade para desempenhar o processo deve ser atingido pela organização.
Abaixo, uma imagem contendo os níveis, seus processos e respectivos AP’s em cada
nível:
75
Figura 19 – Níveis e Processos do MPSBr
Para cada um destes níveis de maturidade citados acima, foram atribuídas áreas de
processo, com base nos níveis 2, 3,4 e 5 do CMMI em estágios. Esta divisão tem uma
graduação diferente do CMMI em estágios como objetivo de possibilitar uma
implementação mais gradual e adequada às micro, pequenas e médias empresas
brasileiras. A possibilidade de realizar avaliações considerando mais níveis permite uma
visibilidade dos resultados de melhoria do processo, na empresa e no país, com prazos
mais curtos. Para cada área de processo são considerados objetivos e práticas
específicas, de acordo com o nível de maturidade em questão.
Métodos de Avaliação
A avaliação das organizações segundo o MR mps deverá ser realizada considerando-se
a aderência às áreas de processos estabelecidas para cada nível de maturidade e a
adequação das práticas que implementam as áreas de processo. O método de
avaliação foi definido com base na ISO/IEC 15504.
O nível de implementação das práticas relacionadas a uma área de processo é avaliado
a partir de indicadores. Esses indicadores, que devem ser definidos pela empresa para
cada prática relacionada a uma área de processo, podem ser de um dos três tipos a
seguir:
-Direto: São produtos intermediários, resultantes de uma atividade.
76
-Indicadores Indiretos: São, em geral, documentos que indicam que uma atividade foi
realizada.
-Afirmações: São resultantes de entrevistas com a equipe dos projetos avaliados de
acordo com quatro níveis: TI (Totalmente implementada), LI (Largamente
Implementada), PI (Parcialmente Implementada), NI (Não Implementada).
A decisão final sobre o grau de implantação de um processo é da equipe de avaliação
considerando os resultados da avaliação nos projetos avaliados.
Uma empresa é considerada nível A, B, C, D, E, F ou G se todas as suas áreas,
unidades, divisões ou setores tiverem sido avaliados como naquele nível. Uma
empresa, entretanto, pode desejar ter avaliado apenas um ou alguns de seus setores,
áreas, unidades ou divisões (organização a ser avaliada). É possível que, como
resultado de uma ou mais avaliações, partes de uma empresa tenham alcançado um
determinado nível e partes da mesma um outro nível. Em qualquer caso, o documento
comprobatório da avaliação deverá explicitar o que foi objeto da avaliação (escopo da
avaliação) e o nível resultante da maturidade.
Para realização de uma avaliação devem ser submetidos todos os projetos concluídos e
todos os projetos em andamento a partir da implementação do MR mps na empresa ou
na organização que será avaliada. Durante o planejamento da avaliação, a instituição
avaliadora deve selecionar um conjunto suficiente de projetos que garanta
representatividade da organização a ser avaliada. Este número, entretanto, não deve
ser inferior a dois projetos concluídos e dois projetos em andamento.
Algumas empresas podem desenvolver um único produto. Isto, entretanto não é
impedimento para avaliação, pois projetos são entendidos em sentido amplo, incluindo
projetos de manutenção no produto. O resultado de uma avaliação tem validade de
dois anos.
MPS Serviços
O mercado brasileiro é composto por um forte setor prestador de serviços de TI e,
assim como para outros setores, qualidade é fator crítico de sucesso para esse setor.
Para que se tenha uma indústria competitiva, nacional e internacionalmente, é
essencial que os provedores de serviços coloquem a eficiência e a eficácia dos seus
processos em foco nas empresas, visando à oferta de serviços conforme padrões
internacionais de qualidade.
Ele é baseado na Norma Internacional ISO/IEC 20000, nas práticas ITIL e no modelo
CMMI-SVC e serve para melhorar tanto os processos de serviços quanto o desempenho
nos negócios das organizações públicas e privadas de qualquer porte.
77
Tipos de Teste
Cada tipo de teste tem foco em um objetivo particular, que pode ser o teste de uma
funcionalidade, a ser realizada pelo software; uma característica da qualidade não
funcional, tal como a confiabilidade ou usabilidade, a estrutura ou arquitetura do
software ou sistema; ou mudanças relacionadas, ex.: confirmar que os defeitos foram
solucionados (teste de confirmação) e procurar por mudanças inesperadas (teste de
regressão). Modelos do software podem ser elaborados e/ou usados no teste estrutural
ou funcional.
Teste de Função (Teste funcional): As funções que um sistema, subsistema ou

componente devem realizar podem ser descritas nos seguintes produtos de trabalho:
especificação de requisitos; casos de uso, especificação funcional, ou podem não estar
documentados. As funções representam “o que” o sistema faz. Testes funcionais são
baseados em funções (descritas nos documentos ou compreendidas pelos testadores),
e devem ser realizados em todos os níveis de teste (ex.: teste de componente deve ser
baseado na especificação do componente). Técnicas baseadas em especificação
podem ser utilizadas para derivar as condições de teste e casos de testes a partir da
funcionalidade do software ou sistema (Ver Capítulo 4). Teste funcional considera o
comportamento externo do software (teste caixa-preta). Um tipo de teste funcional, o
teste de segurança, investiga as funções (ex.: um “firewall”) relacionados à detecção
de ameaça de vírus ou de ações mal-intencionadas.
Teste de características do produto de software (testes não funcionais):

Testes não funcionais incluem, mas não se limita a: teste de performance; teste de
carga; teste de estresse; teste de usabilidade; teste de interoperabilidade; teste de
manutenibilidade; teste de confiabilidade e teste de portabilidade. É o teste de “como”
o sistema trabalha. Testes não funcionais podem ser realizados em todos os níveis de
teste. O termo teste não funcional descreve que o teste é executado para medir as
características que podem ser quantificadas em uma escala variável, como o tempo de
resposta em um teste de performance. Estes testes podem ser referenciados a um
modelo de qualidade como definido na norma ”Engenharia de Software – Qualidade de
Produto de Software” (ISO 9126).
Teste de estrutura/arquitetura do software (teste estrutural): Teste estrutural

(caixa-branca) pode ser feito em todos os níveis de testes. Recomenda-se utilizar as
técnicas estruturais após as técnicas baseadas em especificação, já que ela auxilia a
medição da eficiência do teste através da avaliação da cobertura de um tipo de
estrutura. Cobertura é a extensão que uma estrutura foi exercitada por um conjunto
de testes, expresso como uma porcentagem de itens cobertos. Se a cobertura não
atinge 100%, então mais testes devem ser construídos a fim de testar aqueles itens
78
que não foram contemplados para, desta forma, aumentar a cobertura. Em todos os
níveis de teste, mas especialmente no teste de componente e teste de integração de
componentes, ferramentas podem ser usadas para medir a cobertura do código dos
elementos assim como as declarações ou decisões. Teste estrutural deve ser baseado
na arquitetura do sistema, como uma hierarquia de chamadas. Teste de estrutura
também pode ser aplicado no sistema, integração de sistema ou nível de teste de
aceite (por exemplo, para modelos de negócios ou estrutura de menu).
Teste relacionado a mudanças (teste de confirmação e regressão): Quando

um defeito é detectado e resolvido, o software pode ser retestado para confirmar que
o defeito original foi realmente removido. Isto é chamado de teste de confirmação.
Depurar (resolver defeitos) é uma atividade do desenvolvimento, e não uma atividade
do teste. Teste de regressão é o teste repetido de um programa que já foi testado,
após sua modificação, para descobrir a existência de algum defeito introduzido ou não
coberto originalmente como resultado da mudança. Estes defeitos podem estar no
software ou em um componente, relacionado ou não ao software. É realizado quando
o software, ou seu ambiente é modificado. A quantidade de teste de regressão é
baseada no risco de não se encontrar defeitos no software que estava funcionando
previamente. Os testes devem ser repetíveis se forem utilizados nos testes de
confirmação e para suportar o teste de regressão. Teste de regressão pode ser
realizado em todos os níveis de teste, e se aplicam aos testes funcionais, não
funcionais e estruturais. Testes de regressão são executados muitas vezes e
geralmente desenvolve-se vagarosamente, o que faz com que seja um forte candidato
à automação.
Teste de Usabilidade: É um tipo de testes que enfatiza Atores Humanos, Estética,

Consistência na Interface do Usuário, Ajuda Online e Contextual, Assistentes e
Agentes, Documentação do Usuário e Material de Treinamento.
Técnicas de Teste (Funcional x Estrutural)

A realização dos testes tem por objetivo descobrir erros introduzidos durante a
produção do software, seja nas especificações ou na codificação.
As técnicas de Testes Funcionais objetivam garantir que os requisitos e as

especificações do sistema tenham sido atendidos, o foco dos testes é justamente a
comparação do que foi planejado com o que foi produzido. Ou seja, são técnicas de
teste dinâmico funcional, que serão desempenhados com a dependência da execução
do software.
Já as técnicas de Testes Estruturais buscam garantir que o produto seja

estruturalmente sólido e que funcione corretamente. O foco dos testes é averiguar o
comportamento do sistema em determinadas situações. Vale lembrar, linkando com o
conteúdo anteriormente mencionado, que existem técnicas de teste estático, aqueles
79
feitos sobre a documentação do software, como por exemplo, em modelos, requisitos,
código, classes e módulos.
Mas ainda existem técnicas dinâmicas de teste Estrutural que podem ser executadas
para revelar a lógica interna e bugs omissos.
Cada tipo de teste traz consigo diversas técnicas, sendo elas o processo que
asseguram o funcionamento adequado de alguns aspectos do sistema.
As técnicas de Testes Estruturais buscam garantir que o produto seja estruturalmente

sólido e que funcione corretamente.
Técnicas de Testes Funcionais

Essa técnica garante que os requisitos e especificações do produto de software sejam
atendidos através do seu uso. Dentro dessa técnica se encaixam os seguintes testes:
Teste de Requisitos (Teste Funcional)

Os testes de requisitos (testes funcionais) têm por objetivo simular todos os cenários
de negócio e garantir que todos os requisitos funcionais sejam implementados. Esses
testes exigem profundo conhecimento das regras de negócio da aplicação para que
todas as variações possíveis sejam simuladas, obtendo o máximo de cobertura de
cenários de negócio possíveis.
Devem ser direcionados pelos documentos de especificação funcional, pois esses

descrevem o comportamento que o software deve assumir nos diversos cenários
existentes para cada requisito de negócio. Esse tipo de teste é caracterizado pelo foco
no negócio.
Os testes funcionais não se preocupam com o algoritmo interno do software,

empregando apenas dados de entrada e resultados esperados como referência para
validar a conformidade com o requisito.
O teste funcional deverá:
 concentrar-se em todos os requisitos de teste que possam ser diretamente

associados a casos de uso ou funções e regras de negócios;
 simular todos os cenários de negócio e garantir que todos os requisitos
funcionais que envolve o sistema sobre o ponto de vista comportamental,
funcional, nos níveis de recursos / funções e perfis operacionais sejam
implementados;
 envolver descrições detalhadas dos dados de entrada, arquivos e base de
dados. Geração de base de dados para verificar as funções do sistema e as
entradas / saídas;
 avaliar o fluxo principal e os fluxos alternativos do caso de uso a fim de prover
entradas válidas e inválidas e verificar a resposta do sistema quanto às
entradas fornecidas e os fluxos de exceção.
80
É realizado seguindo um caso de teste previamente elaborado com todos os passos
que o testador deve seguir para testar a funcionalidade do sistema como um todo.
Esses casos devem ser elaborados, levantando todas as possibilidades de
preenchimento dos campos, bem como todas as opções de acessos e saídas de dados.
Devem prever todos os tipos de telas do software, como por exemplo: tela de filtro,
lista, inclusão e alteração.
Esse tipo de teste baseia-se em técnicas de caixa preta, ou seja, é realizado a fim de
verificar o aplicativo e seus processos internos interagindo com o aplicativo através da
Interface Gráfica do Usuário (GUI) e analisar a saída ou os resultados.
Esse tipo de teste pode ser executado validando as seguintes situações: execute os
recursos e os fluxos ou as funções de cada um dos cenários de caso de uso, utilizando
dados válidos e inválidos para verificar se:
 os resultados esperados ocorrerão quando forem usados dados válidos;

 as mensagens de erro ou de aviso apropriadas serão exibidas quando for
utilizado dados inválidos;
 cada regra de negócio será aplicada de forma adequada.
Regressão
O teste de regressão é um teste seletivo de um software que foi modificado ou de
iterações anteriores. Tem como propósito garantir que qualquer falha tenha sido
reparada e que nenhuma operação que funcionava anteriormente tenha falhado após
os reparos, ou seja, garante que as novas características adicionadas não criaram
problemas com as versões anteriores ou com outros sistemas.
O objetivo do teste é verificar se as alterações realizadas geraram alguma

inconsistência no aplicativo.
Pode-se dizer ainda que testes de regressão é o re-teste de segmentos já testados e

não alterados. Geralmente, significa aplicar os mesmos testes realizados previamente
para garantir que os resultados não foram afetados pelas mudanças realizadas em
outros segmentos do sistema. Os roteiros (scripts) desenvolvidos anteriormente são
executados progressivamente para verificar que nenhuma falha foi introduzida após as
mudanças.
Os testes de regressão devem ser usados quando existe um alto risco de que novas
mudanças podem afetar áreas não alteradas do sistema. No processo de
desenvolvimento, os testes devem ser aplicados após um pré-determinado número de
alterações realizadas no sistema. No processo de manutenção, os testes de regressão
devem ser aplicados caso as implicações potenciais nas partes não alteradas do
sistema forem muito altas.
O grande problema dos testes de regressão é que eles demandam um tempo

excessivo e a cansativa repetição das operações contribui para que eles não sejam
realizados ou sejam parcialmente aplicados.
81
Como esses testes são vitais para garantir a qualidade final dos sistemas, é altamente
justificável a automação dos mesmos.
Testes de Tratamento de Erros

Em alguns sistemas, aproximadamente 50% do esforço de codificação é dedicado ao
tratamento de condições de erro. Os Testes de Tratamento de Erros determinam a
habilidade do sistema em tratar apropriadamente transações incorretas.
Os objetivos dos testes de tratamento de erros são:
 determinar que todas as condições de erros esperadas sejam reconhecidas pelo

sistema;
 determinar que a responsabilidade para processar os erros identificados foi
atribuída e que os procedimentos conduzirão a uma alta probabilidade de
correção apropriada;
 determinar que é mantido um razoável controle sobre os erros durante o
processo de correção.
Esses testes devem ocorrer durante todo o ciclo de vida de desenvolvimento do

sistema com o objetivo de minimizar o impacto em todos os pontos do processo de
desenvolvimento a fim de se tomar as ações para a redução a níveis aceitáveis.
Uma forma eficaz para a realização desses testes é realizar um brainstorm com
pessoas de TI, da área de negócio (usuários) e auditores, procurando identificar o que
pode dar errado com o sistema. O resultado deve ser organizado por função do
sistema, de forma que conjuntos de transações de teste possam ser criados.
Esses testes devem testar a introdução, o processamento do erro, a condição de

controle e a reentrada da condição, apropriadamente corrigida.
Podem ser executados testes, tais como:
 produzir um conjunto representativos de transações contendo erros e introduzi-

los no sistema para determinar se o sistema identifica os problemas;
 através de testes iterativos, entrar com erros que resultarão em correções e
então reentrá-los com mais erros que não foram incluídos no conjunto original
de transações;
 entrar com dados cadastrais impróprios, tais como preços, salários, etc., para
determinar que erros desse tipo estão sujeitos a maior número de erros
repetitivos resultantes.
Testes de Suporte Manual

Os testes de suporte manual envolvem inicialmente a avaliação da adequação do
processo e posteriormente a execução do processo. A execução do processo pode ser
feita juntamente com o teste normal do sistema. Os testes podem ser feitos com o
pessoal envolvido preparando e dando entrada às transações, usando o sistema e
utilizando os resultados do sistema de aplicação.
82
Os testes de suporte manual podem ocorrer sem o apoio do pessoal de sistemas,
bastando que esses treinem o pessoal de apoio manual e forneçam os procedimentos
a serem executados. Os resultados, porém, devem ser avaliados pelo pessoal de
sistemas para verificar se os procedimentos foram executados adequadamente.
Os objetivos desses testes são:
 validar se os procedimentos de suporte manual estão documentados e

completos;
 determinar se as responsabilidades pelo suporte manual foram estabelecidas;
 determinar se o pessoal que dará suporte manual está adequadamente
treinado;
 determinar se o suporte manual e o segmento automatizado estão interligado
apropriadamente.
Os testes de suporte manual podem ser executados da seguinte maneira:
 fornecer ao pessoal que entra com os dados, o tipo de informação que eles
normalmente recebem dos seus clientes (ou usuários) e então ter essas
transformadas para permitir a entrada no sistema automatizado;
 fornecer relatórios do sistema baseados em condições típicas aos usuários e
solicitar a eles a tomada de ações em função das informações neles contidas;
 fornecer aos usuários uma série de condições e então solicitar que eles
respondam quais são adequadas.
Esses testes não devem ser deixados totalmente para os últimos estágios do ciclo de
desenvolvimento de software, pode-se dizer que o melhor momento para executar
esses tipos de testes é durante a fase dos testes de aceitação, para que o pessoal que
estará envolvido na operação do sistema não perca o esforço e o conhecimento
adquirido pela demora entre os testes e a utilização prática do sistema.
Testes de Interconexão
Os Testes de Interconexão envolvem a operação de múltiplos softwares, podem ser
custosos e demorados. Consiste em passar dados previstos entre diversos softwares
envolvidos e validar se a transferência foi adequadamente realizada.
Devem ser conduzidos sempre que existir uma mudança em parâmetros entre os
softwares envolvidos nos testes.
Os objetivos dos testes são:
 determinar que os parâmetros e dados são corretamente transferidos entre as

aplicações;
 garantir o momento certo de execução e a existência de coordenação das
funções entre os softwares;
 determinar que a documentação pertinente é correta e completa.
83
Testes de Controle
Os testes de controle, embora presentes em outras técnicas de testes, são realizados
para assegurar o funcionamento dos mecanismos que supervisionam o funcionamento
dos sistemas. Incluem a validação de dados, integridade de arquivos, trilhas de
auditoria, backup e recuperação, documentação e outros aspectos do sistema
relacionados à integridade.
Pode ser considerado um sistema dentro de um sistema. Controles são criados para
reduzir riscos e para isso, os riscos devem ser identificados. Os testes de controle
devem criar situações de risco.
Os testes de controle podem ser executados da seguinte maneira:
 determinar se existe adequada segurança sob o total de registros de um

arquivo, verificando se o mesmo é igual ao registro no arquivo de controle do
sistema. Isso normalmente é feito executando uma rotina que acumula os
registros e reconcilia com o total do arquivo do controle. Pode também somar
campos dos registros e reconciliar com os totais no arquivo de controle;
 determinar que os controles manuais, usados para a garantia de que o
processamento do sistema está correto, estão implantados e sendo usados
apropriadamente;
 selecionar transações de testes e validar que o processamento para essas
transações pode ser reconstituído.
Testes Paralelos
Testes paralelos são usados para determinar que os resultados de um novo sistema
sejam consistentes com o processamento do sistema antigo ou da antiga versão do
sistema.
Esses testes requerem que os mesmos dados de entrada sejam utilizados em versões
diferentes da aplicação, podendo ser feitos com o sistema todo ou com apenas
algumas partes.
Mesmo que os resultados da nova aplicação sejam diferentes da anterior, há a

necessidade de conciliar manualmente os resultados, para garantir que a aplicação
nova atende adequadamente ao negócio a que se propõem.
Os testes paralelos podem ser executados da seguinte maneira:
 operar a antiga e a nova versão do software para determinar se os resultados

são compatíveis;
 rodar a antiga versão do software para assegurar que o “status” operacional
desse foi mantido no retorno do seu processamento.
Técnicas de Testes Estruturais

Essas técnicas garantem que a estrutura do software funcione, seja sólida e esteja
estruturalmente robusto. Essas técnicas não garantem que o sistema funcione
84
corretamente, mas garantem que sua arquitetura, tecnologia e componentes estão
adequados e funcionam de forma satisfatória. As técnicas para esse tipo de teste não
objetivam garantir que o sistema é funcionalmente correto, mas sim se ele é
estruturalmente robusto. Dentro dessa técnica se encaixam os seguintes testes:
Teste de Estresse ou Carga

O teste de estresse pode ser realizado colocando o software sob condições mínimas de
operação ou submetendo o mesmo a variadas cargas de dados acima das médias
esperadas.
Esse teste simula condições de utilização do software sob a provocação de aumentos e

reduções sucessivas de transações que superem os volumes máximos previstos para o
software, gerando contínuas situações de pico e avaliando como o software e toda a
infraestrutura está se comportando.
Devem ser estressadas transações, tabelas internas, espaço em disco, saídas,

capacidade do computador e iteração com pessoas.
A ideia é avaliar como todo o conjunto da solução lida com variações sucessivas de
processamento.
Há vários métodos que podem ser usados para executar esse teste, incluindo:
 elevando sucessivamente o número de transações simultâneas;

 aumentando e reduzindo o tráfego de rede;
 aumentando o número de usuários simultâneos;
 criar carga de usuário “virtual” para simular muitos clientes, geralmente
algumas centenas deles;
Para obter essa carga, geralmente são usadas ferramentas de Emulação de Terminal
Remoto.
Essa técnica também pode ser usada para que a rede fique repleta de “tráfego”.
 encaminhar as transações diretamente para o servidor, geralmente como

chamadas de Linguagem de Consulta Estruturada (SQL);
 usar vários clientes físicos, cada qual executando scripts de teste a fim de
inserir carga no sistema.
Os testes de estresse devem simular, o mais próximo possível, o ambiente de

produção.
Performance (Desempenho ou Execução)

Os testes de execução, mais conhecidos como performance ou desempenho, devem
ser executados para avaliar o comportamento do sistema no ambiente de produção e
validar se são atendidas as premissas de desempenho estabelecidas. São medidos e
avaliados os tempos de resposta, as taxas de transação e outros requisitos que mudam
com o tempo.
85
São conduzidos para avaliar a conformidade do sistema ou componente com requisitos
de performance especificados em Tempo de Execução e Análise de Recursos,
envolvendo monitoramento da execução para estabelecer possíveis áreas ineficientes.
A meta desse teste é verificar se os requisitos de desempenho, definidos na

especificação técnica, foram alcançados. Experimentar comportamentos referentes a
funções de negócios ou transações funcionais, a fim de observar e registrar o
comportamento-alvo e os dados de desempenho do aplicativo. Entre os objetivos
estão:
 determinar o desempenho da estrutura do sistema;

 verificar o nível de utilização do hardware e do software;
 determinar o tempo de resposta das transações on-line;
 determinar os tempos de processamento das transações.
Os testes de desempenho podem ser executados:
 usando monitores de hardware e software;

 simulando o funcionamento de todas as partes ou apenas de uma determinada
seção de um sistema, usando um modelo de simulação;
 criando programas temporários para avaliar o desempenho.
Quanto mais cedo a técnica for aplicada, maior será a garantia de que a aplicação
atenderá os critérios de desempenho. Por isso, devem ser empregados no início do
processo de desenvolvimento, pois se essa informação só for conhecida um pouco
antes ou depois de o sistema se tornar operacional, poderá ser muito tarde para
realizar as modificações necessárias ou muito custosas. Dessa forma, é melhor que se
possa realizar esses testes enquanto ainda se pode modificar as estruturas do sistema,
como por exemplo, otimizar as consultas em banco (SQL).
Os casos e procedimentos de teste, bem como ferramentas de testes devem ser

selecionados adequando-se as necessidades específicas de obtenção de informações
de desempenho.
Há dois níveis para o teste de desempenho:
 caso de uso - identificar o tempo que determinada operação de um ator do

sistema leva para ser executada desde o momento do acionamento da
operação pelo ator até a resposta do sistema para o mesmo;
 transação - identificar o tempo que operações, tais como: chamadas de
métodos e conjunto de métodos em classes levam para serem executadas
desde o momento da chamada do método pela classe chamadora até a
obtenção da resposta da classe chamada.
Recuperação
A recuperação é a capacidade de reiniciar operações após a integridade de uma
aplicação. Geralmente, para avaliar a recuperação de um sistema é necessário voltar
86
ao ponto do processamento, no qual a integridade do sistema está garantida e então
se reprocesse as transações até o ponto de falha.
O tempo necessário para recuperar as operações é afetado pelos seguintes fatores: a

extensão da recuperação, o volume de aplicações processadas no CPD, o nível de
treinamento e a habilidade das pessoas que conduzem a operação de recuperação,
além de ferramentas disponíveis para esse tipo de teste.
Esse teste é responsável por garantir a continuidade das operações, após uma falha ou
um desastre, 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.
Entre alguns objetivos específicos estão:
 manter o backup dos dados;

 armazenar os dados de backup em local seguro;
 documentar os procedimentos de recuperação;
 nomear as pessoas encarregadas da recuperação e verificar se foram treinadas;
 disponibilizar ferramentas para a recuperação (desenvolvidas ou adquiridas).
Os testes de recuperação podem ser conduzidos de duas maneiras:
1º. os procedimentos, métodos, ferramentas e técnicas são acessados para avaliar a

adequação;
2º depois do desenvolvimento uma falha é introduzida e é verificada a capacidade de

recuperação.
A avaliação de procedimentos e documentação é um processo que usa o bom senso e

checklists, além de contar com a atuação de analistas de sistemas, testadores e
gerentes experientes. Por outro lado, os testes de recuperação podem necessitar de
locais de processamento alternativos e deve ser realizado pela área de operações, ou
seja, pelos operadores de computador e pelo pessoal administrativo envolvido no caso
de um desastre.
O desastre simulado serve para avaliar um aspecto da recuperação, com base num
plano de recuperação previamente elaborado.
Esses testes podem envolver operação manual da aplicação, perda da capacidade de

entrada de dados, perda de comunicação, falhas de hardware e software básicos,
perda de integridade da base de dados, erro de operação e falha no sistema de
aplicação...
Alguns exemplos
Induzir um dos programas do sistema a falhar, inserindo uma instrução especial para
criar um código de transação que, quando identificado, causaria o encerramento
anormal do programa.
87
A recuperação poderia ser conduzida a partir de um ponto conhecido, no qual se
garante a integridade dos dados. O exercício seria recuperar esses dados a partir de
uma posição mais adiante e garantir que o backup dos dados se adéque ao processo
de recuperação. Completada a recuperação, os arquivos devem voltar ao ponto em
que os dados eram conhecidos para que possam ser comparados com os arquivos
recriados durante o processo de recuperação.
Essa operação deve ser realizada sempre que a continuidade da operação for essencial
para as operações de área de negócio ou da organização.
Os usuários devem estimar a perda associada com a incapacidade de recuperar as

operações nos diversos intervalos de tempo (em cinco minutos, uma hora, oito horas,
uma semana). A quantidade de perda potencial determina a quantidade de recursos a
serem alocados no planejamento de contingência, bem como nos testes de
recuperação.
Operação
Os testes de operação são realizados para validar, antes da entrada em produção real,
se os procedimentos da produção e os operadores podem executar adequadamente a
aplicação. Deverá ser executado usando os operadores, os procedimentos e a
documentação da área de operações.
Os objetivos específicos são:
 determinar se a documentação da operação está completa;

 garantir que os mecanismos de suporte, tais como os procedimentos de
schedulling, foram corretamente preparados e funcionam de modo adequado;
 avaliar se o treinamento dos operadores está completo;
 testar se os operadores, usando a documentação preparada, conseguem
efetivamente operar o sistema.
Esses testes avaliam o processo e sua execução. Durante a fase de análise de

requisitos, são verificados os requisitos operacionais para determinar se são racionais e
estão completos. Durante a fase de design do software, os procedimentos operacionais
identificados são projetados e avaliados. Essas definições contínuas dos procedimentos
operacionais devem ser submetidas a verificações.
Em geral, a execução dos testes operacionais pode ser realizada em conjunto com
outros testes. Entretanto, se os testes de operação forem incluídos, os operadores não
devem ser avisados, nem obter ajuda externa durante o processo de teste: os testes
precisam ser executados como se fizessem parte da operação normal do computador,
de modo que seja avaliada a efetividade da operação em processar a aplicação num
ambiente real.
Alguns exemplos:
88
 determinar se as instruções para a operação foram preparadas e documentadas
de acordo com os procedimentos da produção e se os operadores foram
treinados para situações anormais;
 testar se os procedimentos de schedulling e outras características requeridas
pelo sistema operacional realizam uma tarefa específica;
 verificar se a rotulagem de arquivos e os procedimentos de proteção funcionam
adequadamente.
Teste de Conformidade
Os testes de conformidade validam se a aplicação foi desenvolvida de acordo com os
padrões, procedimentos e guias de TI. As metodologias são usadas para aumentar a
probabilidade de sucesso, permitir a transferência de pessoal técnico com custo
mínimo e aumentar a manutenibilidade do sistema de aplicação. Os tipos de teste
variam dependendo do ciclo de desenvolvimento. Entretanto, pode ser mais importante
executar testes de conformidade durante a fase de requisitos do que nos estágios
finais do ciclo de vida, pois é muito mais difícil corrigir aplicações quando os requisitos
não estão adequadamente documentados.
Esses testes são realizados para garantir a conformidade com as metodologias, além
de:
 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.
A conformidade aos padrões e procedimentos de TI para desenvolvimento de

aplicações depende do desejo de fazer com que os procedimentos sejam seguidos e os
padrões sejam aplicados. Para isso, devem ser realizados testes suficientes para
determinar o grau de conformidade com as metodologias e identificar aqueles que não
as cumprem, a fim de que sejam efetivadas as ações gerenciais. Entretanto, é
importante avaliar se a falta de conformidade decorre de problemas no processo e nos
padrões ou se, porque os mesmos foram mal-entendidos ou mal divulgados. Nesses
casos, é desejável avaliar os diversos processos envolvidos e realizar as modificações
necessárias.
Testes de Segurança
Os testes de segurança garantem a confidencialidade das informações e a proteção
dos dados contra o acesso indevido de terceiros. A quantidade de segurança fornecida
depende dos riscos associados. A garantia de confidencialidade das informações é
desenhada para proteger os recursos da organização. Algumas informações, se
reveladas ou adulteradas, podem comprometer o negócio ou aumentar a vantagem
competitiva dos concorrentes.
Entre os objetivos estão:
89
 determinar se foi dada a atenção adequada à identificação de riscos de
segurança;
 determinar se foi preparada uma definição realista das regras de acesso ao
sistema e se essas foram implementadas de acordo com as definições;
 determinar se existe pessoal suficientemente habilitado para executar o teste
de segurança adequado;
 conduzir testes racionais para garantir que as medidas de segurança tenham
sido corretamente implementadas;
 detectar as falhas de segurança que podem comprometer o sigilo e fidelidade
das informações, bem como provocar perdas de dados ou interrupções de
processamento.
Podem, inicialmente, 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ção para acessar indevidamente as informações.
Em segundo lugar, o controle de acesso pode ser dividido por possíveis tipos de
invasores, tais como: empregados, terceiros, público etc., ou por categorias de
empregados. O tipo de teste a ser conduzido dependerá da condição a ser testada,
que poderá ser:
 determinar se os recursos a serem protegidos estão identificados e os acessos

estão definidos para cada recurso (o acesso pode ser estabelecido por
programa ou por pessoa);
 avaliar se os procedimentos de segurança desenhados foram implementados
adequadamente e funcionam de acordo com as especificações;
 tentar o acesso não autorizado em software on-line para garantir que o sistema
seja capaz de identificá-lo e impedi-lo.
O Teste de Segurança deverá concentra-se em duas áreas de segurança principais:
 segurança no nível do aplicativo: incluindo o acesso aos dados ou às regras de

negócio; um ator poderá acessar somente as funções ou os dados para o quais
seu tipo de usuário tenha recebido permissão.
 Identifique e liste cada tipo de usuário e as funções ou os dados para os
quais cada um deles tem permissão de acesso.
 Crie testes para cada tipo de usuário e verifique cada permissão criando
transações específicas para cada tipo de usuário.
 Modifique o tipo de usuário e execute novamente os testes para os
mesmos usuários. Em cada caso, verifique se as funções ou dados
adicionais estão corretamente disponíveis ou se tem seu acesso negado.
 segurança no nível do sistema:
 tentar invadir / derrubar o servidor de dados / interne;
 tentar extrair backups de informações sigilosas;
 tentar descobrir senhas e quebrar protocolos de segurança;
 tentar processar transações geradas de fontes inexistentes;
 tentar simular comportamento / infecção por vírus.
90
Testes de manutenção:
Uma vez desenvolvido, um sistema pode ficar ativo por anos ou até mesmo décadas.
Durante este tempo o sistema e seu ambiente podem ser corrigidos, modificados ou
completados. Teste de manutenção é realizado no mesmo sistema operacional e é
iniciado por modificações, migrações ou retirada de software ou sistema.
Alguns exemplos de modificações incluem melhorias planejadas (ex.: baseadas em

“releases”), mudanças corretivas e emergenciais, além de mudanças de ambiente,
como atualização em sistema operacional ou banco de dados, e correções (“patches”)
para expor e encontrar vulnerabilidades do sistema operacional.
Teste de manutenção por migração (ex.: de uma plataforma a outra) pode incluir
testes operacionais do novo ambiente tanto quanto a mudança de software.
Teste de manutenção para retirada de um sistema pode incluir o teste de migração de

dados, ou arquivamento se longos períodos de retenção de dados forem necessários.
Além de testar o que foi alterado, o teste de manutenção inclui teste de regressão
massivo para as partes do sistema que não foram testadas. O escopo do teste de
manutenção está relacionado ao risco da mudança, o tamanho do sistema existente e
o tamanho da mudança. Dependendo da mudança, o teste de manutenção pode ser
feito em todos ou alguns níveis, e em todos ou alguns tipos de testes.
A determinação de como um sistema pode ser afetado por mudanças é chamado de

análise de impacto, e pode ser usado para ajudar a decidir quantos testes de regressão
serão realizados.
Teste de manutenção pode se tornar uma tarefa complicada se as especificações

estiverem desatualizadas ou incompletas.
91
Estratégias de teste de software
Para que os testes sejam mais eficientes e tenham uma maior probabilidade de
encontrar falhas, devem ser usadas técnicas de teste. Existem as estratégias de teste
caixa preta e as técnicas caixa branca.
Caixa preta:
Encara um programa/componente como uma “caixa preta”
É baseado na especificação do sistema, e não no código fonte.
O planejamento dos testes pode começar no início do ciclo de desenvolvimento.
Figura 20 – Testes de Caixa Preta
Caixa branca:
É baseado no código fonte do sistema.
Leva em consideração a estrutura interna do programa.
Figura 21 – Testes de Caixa Branca
Caixa preta:
Exemplo:
Controle da TV: você seleciona o canal e testa para ver se está sintonizado no canal
que você selecionou, sem se importar como é o funcionamento interno para chegar até
a sintonização.
Técnicas de Teste de Caixa Preta:

Particionamento por Equivalência
92
Análise de Valor Limite
Causa Efeito
Fluxo de Dados
Pair Wise (Combinação por Pares)
Figura 22 – Técnicas
Particionamento de equivalência
Reduz um conjunto grande de entradas (infinito) a um conjunto finito: pequeno, mas
eficiente. Divide o domínio de entrada de um software (ou programa) em classes de
dados a partir das quais os casos de teste podem ser derivados.
Classe de equivalência representa um conjunto de estados válidos ou inválidos para

condições de entrada
Duas ou mais classes são equivalentes, se elas produzem o mesmo resultado.
Se uma situação funciona como o esperado, então podemos assumir que a outra
também funciona. Devem conter entradas válidas e invalidas
Uma condição de entrada pode ser: um valor numérico; um intervalo de valores; um

valor alfabético; etc.
93
Figura 23 – Particionamento de Equivalência
Se a condição de entrada especifica um intervalo, então é definida uma classe de

equivalência válida e duas inválidas. Exemplo: O campo login deve ter entre 4 e 10
caracteres.
Figura 24 – Particionamento de Equivalência com classes
Se a condição de entrada requer um valor específico, então é definida uma classe de

equivalência válida e duas inválidas. Exemplo: O funcionário A deve estar associado
ao departamento 4.
Figura 25 – Particionamento de Equivalência com limites
Exemplo: Para o cálculo do importo X temos as seguintes regras:
Salário abaixo de R$ 5000,00 não recolhe o imposto. Salário entre R$ 5000,00 e

8000,00 recolhe 2% de imposto e salário acima de R$ 8000,00 recolhe 5% de imposto.
94
Figura 26 – Exemplo de Particionamento de Equivalência com limites
Desta forma, temos 3 classes de equivalência.
Análise de valor limite

A Análise de Valor Limite (Boundary Value Analysis – BVA) é uma técnica de projeto de
casos de teste que complementa o particionamento de equivalência; Em vez de
selecionar qualquer elemento de uma classe de equivalência, a BVA leva à seleção de
casos de teste nas “extremidades” da classe.
Essa ideia está associada à forma como a programação é feita: Por exemplo, no caso
acima, onde é feito o cálculo do valor do imposto, entenda que o programador deve
ter feito algo similar a isto:
If salário >5000 imposto=0
If salário between 5000 and 8000 imposto=2%
Then imposto=5%
Caso o programador tenha se enganado, ele pode ter escrito:
If salário >=5000 imposto=0
If salário between < 5000 and 8000 imposto=2%
Then imposto=5%
Ou seja, tendo em vista que toda a programação quando se refere a conjuntos de

dados é feita utilizando operadores relacionais, é muito provável que os erros sejam
procurados também desta forma.
Exemplos:
Figura 27 – Exemplo de Particionamento com limites inf e superior
95
Figura 28 – Exemplo de Particionamento de com limites e resultados
Gráfico Causa Efeito

Verifica o efeito combinado de dados de entrada. As condições de entrada (causa) e
as ações (efeitos) são identificados e combinados em um gráfico e a partir deste é
montado uma tabela de decisão. Então são escritos os casos de teste.
Veremos um exemplo:
Em um programa de compras de livros pela Internet, a cobrança do frete obedece aos

seguintes critérios:
Se a compra for maior do que R$ 50,00 e a quantidade de itens for menor do

que 3 livros, o frete será gratuito, senão, será cobrado.
1º - São atribuídos identificadores para cada módulo de causa-efeito.
1 – Causa: valor da compra > 50,00 e produtos < 3
Efeito: Frete grátis
2º - Desenho do gráfico causa-efeito
3º - Transforma o gráfico em uma Tabela de Decisão:
96
Causa Efeito
Frete
Valor da compra Quant. Produtos Grátis Frete Cobrado
> 50,00 <3 X
> 50,00 >= 3 X
=< 50,00 -- X
4º - Transforma em Casos de Teste
Causa /Efeito
(Valor da compra = 51,00 – Quant. Produtos=2) - (Resultado Esperado=Frete Grátis)
Fluxo de Dados
Recomenda-se utilizar a técnica principalmente quando a empresa trabalha com Casos
de Uso, de forma a facilitar a extração dos mesmos:
Figura 29 – Exemplo de Fluxo de Dados
Após cada caminho possível através do caso de uso mostrado no diagrama acima, é
possível identificar os diversos cenários de caso de uso. Começando pelo fluxo básico e
depois combinando esse fluxo com os fluxos alternativos, é possível identificar os
seguintes cenários de caso de uso:
97
Agora vamos verificar um Caso de Uso de retirada de dinheiro para poder obter os
Casos de Teste.
98
Fluxo Básico Esse Caso de Uso começa com o caixa eletrônico no Estado Pronto.
1. Iniciar Retirada - O cliente insere o cartão bancário no leitor

de cartões do caixa eletrônico
2. Verificar o Cartão Bancário - O caixa eletrônico lê o código da
conta a partir da tarja magnética do cartão bancário e verifica
se ele é um cartão aceitável.
3. Digitar a senha - O caixa eletrônico pede a senha do cliente (4

dígitos)
4. Verificar o código da conta e a senha - O código da conta e a
senha são verificados para determinar se a conta é válida e se a
senha digitada está correta. Para esse fluxo, a conta é válida e a
senha está corretamente associada a essa conta.
5. Opções do caixa eletrônico - O caixa eletrônico exibe as
diversas alternativas disponíveis. Nesse fluxo, o cliente do
banco sempre seleciona "Retirada em Dinheiro."
6. Digitar o Valor - O caixa eletrônico solicita o valor a ser

retirado. Para esse fluxo o cliente seleciona um valor
predefinido (R$ 10, R$ 20, R$ 50 ou R$ 100).
7. Autorização - O caixa eletrônico inicia o processo de
verificação com o Sistema Bancário, enviando o ID do Cartão, a
Senha, o Valor e as Informações de conta como uma transação.
Para esse fluxo, o Sistema Bancário está on-line e responde com
uma autorização para concluir a retirada em dinheiro,
atualizando o saldo da conta de forma apropriada.
8. Fornecimento - O Dinheiro é fornecido.
9. Devolução do Cartão - o Cartão do Banco é devolvido.
10. Recibo - O recibo é impresso e fornecido. O caixa eletrônico

também atualiza o log interno de forma apropriada.
O Caso de Uso termina com o caixa eletrônico no Estado Pronto.
99
Fluxo Alternativo 1 - Cartão Inválido. No Passo 2 do Fluxo Básico - Verificar o Cartão Bancário, se o
cartão não for válido, será ejetado com uma mensagem
apropriada.
Fluxo Alternativo 2 - Caixa Eletrônico sem No Passo 5 do Fluxo Básico - Opções do Caixa Eletrônico, se o
Dinheiro caixa eletrônico estiver sem dinheiro, a opção "Retirada em
Dinheiro" não estará disponível.
Fluxo Alternativo 3 - Fundos insuficientes no No Passo 6 do Fluxo Básico - Digitar o Valor, se o caixa eletrônico
caixa eletrônico não contiver fundos suficientes para fornecer o valor solicitado, o
sistema exibirá uma mensagem apropriada e retornará ao Passo 6
do fluxo básico - Digitar o Valor.
Fluxo Alternativo 4 - Senha Incorreta No Passo 4 do Fluxo Básico - Verificar a Conta e a Senha, o cliente
tem três chances de digitar a senha correta.
Se for digitada uma senha incorreta, o caixa eletrônico exibirá a

mensagem apropriada, e se houver novas tentativas, esse fluxo
retornará ao Passo 3 do Fluxo Básico - Digitar a Senha.
Se na última tentativa o número PIN digitado estiver incorreto, o

cartão será retido, o caixa eletrônico retornará ao Estado Pronto,
e esse caso de uso será encerrado.
Fluxo Alternativo 5 - Nenhuma Conta No Passo 4 do Fluxo Básico - Verificar a Conta e a Senha, se o
Sistema bancário retornar um código indicando que a conta não
foi encontrada ou que ela não permite retiradas, o caixa
eletrônico exibirá a mensagem apropriada e retornará ao Passo 9
do Fluxo Básico - Devolver o Cartão.
Fluxo Alternativo 6 - Fundos Insuficientes na No Passo 7 do Fluxo Básico - Autorização, o Sistema bancário
Conta exibe um código indicando que o saldo da conta é inferior ao
valor digitado no Passo 6 do Fluxo Básico - Digitar o Valor; o
caixa eletrônico exibe a mensagem apropriada e retorna ao Passo
6 do Fluxo Básico - Digitar o Valor.
Fluxo Alternativo 7 - Atingido o valor máximo No Passo 6 do Fluxo Básico - Autorização, o Sistema bancário
diário para retirada exibe um código indicando que, com essa solicitação de retirada,
o cliente terá excedido o valor máximo permitido em um período
de 24 horas; o caixa eletrônico exibe a mensagem apropriada e
retorna ao Passo 6 do Fluxo Básico - Digitar o Valor.
Fluxo Alternativo x - Erro de Log Se no Passo 10 do Fluxo Básico - Recibo, não for possível atualizar
o log, o caixa eletrônico entrará no "modo de segurança" em que
todas as funções serão suspensas. Um alarme apropriado será
enviado ao Sistema Bancário para indicar que o caixa eletrônico
suspendeu a operação.
Fluxo Alternativo y - Encerramento O cliente pode, a qualquer momento, decidir terminar a transação
(encerrar). A transação é interrompida e o cartão é ejetado.
Fluxo Alternativo z - "Paralisação" O caixa eletrônico contém vários sensores que monitoram funções
distintas, como alimentação, pressão exercida nas várias portas e
passagens, e detectores de movimento. Se a qualquer momento
um sensor for ativado, um sinal de alarme será enviado à Polícia,
e o caixa eletrônico entrará no "modo de segurança" em que todas
as funções serão suspensas até que sejam executadas as ações de
reinício/reinicialização apropriadas.
Na primeira iteração, de acordo com o plano de iteração, é necessário verificar se o caso de uso
Retirada em Dinheiro foi implementado corretamente. O caso de uso não foi totalmente implementado.
Fluxo Básico - Retirada de um valor predefinido (R$ 10, R$ 20, R$ 50, R$ 100)
Fluxo Alternativo 2 - Caixa Eletrônico sem Dinheiro
Fluxo Alternativo 3 - Fundos insuficientes no caixa eletrônico
Fluxo Alternativo 4 - Senha Incorreta
Fluxo Alternativo 5 - Nenhuma Conta/Tipo de Conta Incorreto
100
Fluxo Alternativo 6 - Fundos Insuficientes na Conta
É possível obter os cenários a seguir a partir desse caso de uso:
OBSERVAÇÃO: Por praticidade, os loops nos Fluxos alternativos 3 e 6 (Cenários 3 e 7)

e as combinações de loops não foram incluídos na tabela acima.
Para cada um desses sete cenários, é necessário identificar casos de teste. É possível
identificar e gerenciar os casos de teste usando matrizes ou tabelas de decisão. Veja a
seguir um formato comum, em que cada linha representa um caso de teste individual,
e as colunas identificam informações de caso de teste. Nesse exemplo, para cada caso
de teste, há um ID, uma Condição (ou descrição) e todos os elementos que participam
do caso de teste (como entrada ou já no banco de dados) e o resultado esperado.
Para desenvolver a matriz, primeiro identifique quais elementos de dados são

necessários para a execução dos cenários de caso de uso. Em seguida, para cada
cenário, identifique pelo menos um caso de teste que contenha a condição apropriada
para executar o cenário. Por exemplo, na matriz a seguir, V (válido) é usado para
indicar que essa condição deve ser VÁLIDA para que o fluxo seja executado, e I
(inválido) é usado para indicar a condição que disparará o fluxo alternativo
desejado. Na tabela a seguir, "n/a" indica que essa condição não é aplicável ao caso de
teste.
101
Na matriz acima, os seis casos de teste executam os quatro cenários. Para o Fluxo
Básico, o caso de teste CW1 acima é denominado caso de teste positivo. Ele executa,
sem desvios, o caminho do Fluxo Básico através do caso de uso. O teste abrangente
do Fluxo Básico deve incluir casos de teste negativos para garantir que esse fluxo só
seja utilizado quando as condições estiverem corretas. Os casos de teste negativos são
representados pelos casos de teste CW2 a 6 (a célula sombreada indica a condição
necessária para executar os fluxos alternativos). Embora esses casos de teste sejam
negativos para o Fluxo Básico, são positivos para os Fluxos alternativos 2 a 4, e existe
pelo menos um caso de teste negativo em cada um desses Fluxos Alternativos (CW1 -
o Fluxo Básico).
O Cenário 4 é um exemplo em que não é suficiente haver apenas um caso de teste

positivo e um negativo por cenário. Para testar completamente o Cenário de teste 4 -
Senha Incorreta, são necessários pelo menos três casos de teste positivos (para
disparar o Cenário 4):
 a senha incorreta é digitada, há novas tentativas, e esse Fluxo Alternativo retorna

ao Passo 3 do Fluxo Básico - Digitar a Senha)
 A senha incorreta é digitada, não há novas tentativas, esse Fluxo Alternativo retém
o cartão e termina o caso de uso.
 a senha CORRETA é digitada quando não há mais novas tentativas. Esse Fluxo
Alternativo retorna ao Passo 5 do Fluxo Básico - Digitar o Valor.
Observe que, na matriz acima, nenhum valor real foi digitado para as condições
(dados). A vantagem de criar a matriz do caso de teste dessa maneira é a facilidade de
ver as condições que estão sendo testadas. Também é muito fácil determinar se casos
de teste suficientes foram identificados, já que você precisa apenas observar os Vs e Is
(ou como feito aqui - as células sombreadas). Na tabela acima, há diversas condições
102
para as quais não há células sombreadas. Portanto, estão faltando casos de teste
como, por exemplo, para o Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto e
para o Cenário 7 - Saldo Insuficiente em Conta.
Depois que todos os casos de teste forem identificados, será necessário revisá-los e
validá-los para garantir a exatidão e adequação, bem como para eliminar casos de
teste redundantes ou equivalentes. Após a aprovação dos casos de teste, será possível
identificar os valores reais dos dados (na matriz de implementação do caso de teste) e
criar os dados de teste
Os casos de teste acima são apenas alguns dos necessários para verificar o Caso de
Uso de Retirada em Dinheiro, referente a essa iteração. Outros casos de teste
necessários contêm:
 Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: Conta não encontrada ou

não disponível
 Cenário 6 - Nenhuma Conta ou Tipo de Conta Incorreto: A conta não permite
retiradas
 Cenário 7 - Saldo em Conta Insuficiente: Valor solicitado maior que o valor contido
na conta.
Em futuras iterações, quando outros fluxos forem implementados, os casos de teste

serão necessários para:
 Cartões inválidos (informa-se que o cartão foi perdido, roubado, não é de um banco
aceito, tem uma tarja danificada etc.)
 Incapacidade de ler um cartão (o leitor de cartões está obstruído, fora de linha ou
com defeito)
 A conta está fechada, paralisada ou de outra maneira indisponível
 O valor no caixa eletrônico é insuficiente ou incapaz de compor o valor solicitado
(diferente do CW3, visto que uma denominação está fora, mas não todas)
 Incapaz de entrar em contato com o sistema bancário para aprovação
 A rede do banco está fora de linha ou há uma falha de energia durante a transação
103
Ao identificar os casos de teste funcionais, verifique se:
 foram identificados casos de teste suficientes, positivos e negativos, para cada

cenário de caso de uso
 os casos de teste abordam qualquer regra de negócio implementada pelos casos de
uso, garantindo que haja casos de teste, dentro, fora e na condição ou no valor de
fronteira da regra de negócio
 os casos de teste abordam quaisquer sequências de eventos ou ações, como
aquelas identificadas nos diagramas de sequência do modelo de design, ou estados
ou as condições de objetos de interface do usuário.
 os casos de teste abordam qualquer requisito especial definido para o caso de uso,
como o desempenho mínimo/máximo, às vezes combinado com as cargas ou os
volumes de dados mínimos/máximos durante a execução dos casos de uso.
Pair Wise
Uma abordagem científica e metodológica é a utilização da menor quantidade de
combinações de variáveis dos cenários de testes que levem a uma cobertura eficaz dos
testes. A teoria “Pairwise Testing” faz exatamente isso agrupando as variáveis dos
testes em pares.
Vamos a um exemplo: imagine que você tivesse um que testar o funcionamento de um

requisito em:
Sistema Operacional: Windows e Linux
Processador: Intel e AMD
Protocolo: IPv4 e IPv6
Para testar todas as combinações possíveis, a conta é imediata: 23 = 8.
Seguindo a abordagem Pairwise Testing, os cenários a testar seriam 4 — a metade! O

conceito é que todas as combinações possíveis de pares sejam testadas pelo menos
uma vez (daí o nome Pairwise Testing). Veja na tabela abaixo quais seriam os cenários
que cobririam todos os pares possíveis:
Para 3 variáveis, talvez o impacto não seja tão relevante assim, mas se considerarmos
que uma das grandes vantagens é que o crescimento da quantidade de cenários passa
a ser logarítmico ao invés de exponencial, quanto maior a quantidade de variáveis,
maior o impacto da diminuição de cenários.
104
Técnicas de Teste de Caixa Branca
Nos testes caixa-branca, o código da aplicação deve ser analisado, revisado em busca
de falhas.
Todos os caminhos independentes de um módulo devem ser exercitados pelo menos

uma vez.
As decisões lógicas devem ser exercitadas para o resultado verdadeiro e falso.
Os ciclos devem ser executados dentro dos intervalos e nos limites.
Todas as estruturas internas devem ser executadas.
Algumas técnicas de teste caixa branca são: revisão formal (peer review, inspeção e,
walktrough), teste de caminho básico.
Revisão formal
É uma revisão do código fonte sem executá-lo. Os elementos da revisão formal são:
Identificar problemas. Sejam eles falhas ou coisas que estão faltando
Seguir as regras. Antes de iniciar a revisão, devem ser definidas regras como, por
exemplo, quantos linhas de código serão revisados, quanto tempo durará a revisão,
etc. Estas regras devem ser seguidas para que cada participante saiba qual é o seu
papel e o que esperar da revisão
Preparação. Cada participante deve se preparar para a revisão. Ele deve saber com
antecedência quais serão suas tarefas e responsabilidades. Muitos dos problemas são
encontrados durante a preparação.
Reporte. Elaborar um relatório com os resultados da revisão descrevendo quais foram

os problemas encontrados, onde eles foram encontrados, etc.
Como consequências da revisão formal temos:
Melhora da comunicação interna. Programadores inexperientes aprendem com os mais

experientes, os testadores passam a ter uma ideia do que eles estão testando…
Aumento da qualidade. Como o código será analisado por outras pessoas, os

programadores passam a ter mais cuidado com o que estão produzindo (“para não
passar vergonha”)
As revisões formais são:
Peer review: revisão feita por pares (1 ou 2 pessoas, no máximo) do programador.
Walkthrough: o programador faz uma apresentação formal para um grupo pequeno

de revisores (programadores). Os revisores devem receber uma cópia do programa
antes da revisão e estudá-la.
105
Inspeção: é a mais formal das revisões. O apresentador não é o desenvolvedor do
código. Isto o obriga a estudar e entender o código. Os inspetores devem avaliar o
código sob as diferentes visões, tais como usuário e do suporte. Um dos inspetores
deve avaliar o código de trás para a frente. Deve existir um moderador e um redator.
Depois de encontrados os problemas, o redator faz um relatório, o programador
corrige as falhas e o moderador verifica se elas foram corrigidas.
Teste do caminho básico

Garante que cada comando do programa será executado pelo menos uma vez durante
o teste. O programa deve ser representado utilizando grafos de fluxo de controle.
Figura 30 – Exemplo de Caminho básico
Um caminho independe é um caminho que possui pelo menos um novo comando no

grafo de fluxo de controle (uma aresta que ainda não foi utilizada).
Figura 31 – Exemplo de Caminho Independente
Caminhos:
Caminho 1: 1-11
Caminho 2: 1-2-3-4-5-10-1-11
106
Caminho 3: 1-2-3-6-8-9-10-1-11
Caminho 4: 1-2-3-6-7-9-10-1-11
O caminho 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 não é um caminho independente,

porque é apenas uma combinação de caminhos já especificados e não atravessa
nenhuma nova aresta.
Para saber quantos caminhos um software tem, usa-se a Complexidade ciclomática

(teoria dos grafos). Ela é uma métrica que fornece uma medida quantitativa da
complexidade lógica de um programa. Ou seja, quantos caminhos, no máximo, terão
que se exercitados para garantir a cobertura de todos os comandos do programa.
Ambientes de Teste
Definição:
Ambiente de teste é o "local" onde o teste será executado, compreendendo

configurações da infraestrutura para hardware, software, ferramentas de automação,
equipe envolvida, aspectos organizacionais, suprimentos, rede e documentação. Sua
finalidade é propiciar a realização de testes em condições conhecidas e controladas.
A criação de um ambiente isolado, organizado, representativo e mensurável,

pela equipe de teste, garante a descoberta de erros reais, ou seja, erros que realmente
ocorreriam em produção e que por ventura não foram descobertos em tempo de
desenvolvimento, e o mais importante, oferecem a garantia de que não houve
influência externa.
O ambiente de teste já deve ser previsto no Plano de Teste. O mesmo deve ser o mais
similar possível ao ambiente que o usuário utilizará para o software em questão, sendo
considerado assim como uma das fases mais difíceis, tendo como responsável o
arquiteto de teste.
O ambiente de teste deve totalmente separado no ambiente de desenvolvimento e, a

criação desse ambiente separado libera a equipe de desenvolvimento a
continuar a produzir novos códigos, sem prejuízo à integridade do ambiente,
mesmo durante a execução dos testes e ainda possibilita a realização dos testes de
iteração e sistema, permitindo com isso, integrar as diferentes camadas e ou
ambientes.
107
A preparação do ambiente deve ser discutida o quanto antes, suas necessidades
básicas (equipamentos, softwares, browser em aplicações web etc.) devem ser
identificadas no momento inicial do projeto. Com o andamento do projeto, este
ambiente ganha detalhamento e começa a ser implementado. Mais tarde, geralmente
na fase de Implementação do Teste, a Massa de Teste será criada e o ambiente
previamente estabelecido será utilizado para executar os cenários de teste elaborados.
Veja a seguir os elementos do ambiente de testes que devem ser levados em

consideração para o planejamento do ambiente de testes.
Preparação do ambiente de teste
Alguns atributos do ambiente de testes precisam ser analisados e planejados para a

realização dos testes. Veja na tabela abaixo a organização destes:
108
Uso de ambientes virtuais
Na realidade atual, a maioria das empresas não prevê orçamento para preparação dos
ambientes de testes na contratação de novos projetos de software.
Uma solução que vem ganhando espaço, por ser mais econômica, é a criação de
ambientes virtuais (‘máquinas virtuais’).
Máquina virtual é um software que permite ao arquiteto de testes criar vários

ambientes de testes, com diferentes configurações de software, hardware, sistemas
operacionais, etc, utilizando na realidade a mesma máquina física
** É aconselhável que a base de teste tenha 30% do tamanho da base de produção
109
Bibliografia
 BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA,

S.R.S. e JINO, M.. “Introdução ao Teste de Software. XIV Simpósio Brasileiro de
Engenharia de Software”, 2000.
 BARTIÉ,A.; “Garantia da Qualidade de Software”; Campus, Rio de Janeiro,
2002.
 BASTOS, A.; RIOS, E.;CRISTALLI, R.; MOREIRA,T.;”Base de conhecimento em
teste de software”, Martins, São Paulo, 2007.
 CRAIG, R.D.; JASKIEL, S. P., “Systematic Software Testing”, Artech House

Publishers, Boston, 2002.
 FERRAZ, L.O.”Avaliação de uma associação de Produtores para a certificação do
café”, Minas Gerais, 2007. Dissertação (Pós graduação em Fitotecnia),
Universidade Federal de Viçosa.
 IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering
Terminology, IEEE Press.
 GUERRA, A.C; COLOMBO, R.M.T., “Qualidade de Produto de Software”, PBQP

Software, Brasilia, 2009.
 MACHADO, R.T.M.”Rastreabilidade, tecnologia da Informação e coordenação de
sistemas agroindustriais”, São Paulo, 2000. Tese (Doutorado em administração)
Faculdade de Economia, Administração.
 NASSAR, A.M.; “Certificação no agronegócio. Estudo temático apresentado no
IX Seminário Internacional PENSA de Agrobusiness, 1999. Águas de São Pedro.
 PEZZÉ, M.;YOUNG, M.; “Teste e Análise de Software”, Bookman, Porto Alegre,
2008.
 PFLEEGER, S. L., “Engenharia de Software: Teoria e Prática”, Prentice Hall-
Cap. 08, 2004.
 POMPILHO,S; “Análise Essencial”, Ciência Moderna, Rio de Janeiro, 2002.
 PRESSMAN, R. S., “Software Engineering: A Practitioner’s Approach”, McGraw-

Hill, 6th ed, Nova York, NY, 2005.
 RAPPS, S., WEYUKER, E.J., “Data Flow analysis techniques for test data
selection”, In: International Conference on Software Engineering, p. 272-278,
Tokio, Sep. 1982.
 ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., “Qualidade de

software – Teoria e prática”, Prentice Hall, São Paulo, 2001.
 RIOS, E, “Documentação de Teste de Software”, Art Studio, São Paulo, 2007.
110
 SPERS, E.E. “Qualidade e Segurança em Alimentos”. In: ZYLBERSTAJN., ET
AL.”Economia e gestão dos negócios agroalimentares”, Pioneira, São Paulo,
2002.
 http://www.alats.org.br
 http://www.bstqb.org.br
 http://www.devmedia.com.br/
 https://www.sei.cmu.edu/cmmi/
 http://www.tecmundo.com.br/
 http://www.softex.br/mpsbr/
 http://www.softex.br/mpsbr/mps/mps-br-em-numeros/
 http://www.wthreex.com/rup/portugues/process/modguide/md_tstcs.htm
 https://guimaraesdani.wordpress.com/tecnicas-de-teste-parte-ii/
 https://viniciussabadoti.wordpress.com
 http://blog.prasabermais.com/2010/02/15/histrico-da-evoluo-das-ferramentas-
para-testes-e-qualidade-de-software/
111

Testes de Software - Fundamentos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Testes de Software - Fundamentos

Transféré par

Droits d'auteur :

Formats disponibles

MATERIAL OFICIAL TARGETTRUST

Software: sequência de instruções escritas para serem interpretadas por um

Em um computador, o software é classificado como a parte lógica cuja função é

Os softwares podem ser classificados em três tipos:

Software de Sistema: é o conjunto de informações processadas pelo sistema

Software de Programação: é o conjunto de ferramentas que permitem ao

Software de Aplicação: são programas de computadores que permitem ao

Hoje, o software de computadores é a tecnologia única mais importante no palco

A medida que a importância do software cresceu, a comunidade de software tem

O software entrega o mais importante produto da nossa época, a informação. Ele

Modelos Prescritivos de Software

Os modelos de prescritivos de processo foram originalmente propostos para colocar

É importante porque fornece estabilidade, controle e organização a uma atividade que

O Modelo Cascata, também chamado de Clássico ou Linear, caracteriza-se por possuir

A figura abaixo nos dá uma ideia visual do conceito apresentado acima.

Podemos utilizar o modelo cascata quando um software necessita de uma nova

O modelo cascata é o paradigma mais antigo da engenharia de software. Porém,

Os principais problemas encontrados no modelo cascata são:

Os projetos de software reais construídos e evoluídos na indústria de software

Alguns projetos de software definem requisitos iniciais de software razoavelmente bem

O modelo de processo incremental combina elementos dos fluxos de processos tanto

Figura 2 – Modelo Incremental

No primeiro incremento de um produto que utiliza o modelo incremental temos apenas

O modelo de processo incremental entrega um produto operacional a cada incremento,

De forma geral, os primeiros incrementos podem ser implementados com um número

O software evolui ao longo do tempo e conforme o desenvolvimento deste software

Modelos evolucionários são caracterizados por serem iterativos e apresentarem

A prototipagem é utilizada quando o desenvolver não tem certeza quanto à eficiência

Etapas da Prototipagem de forma iterativa.

De forma geral o protótipo auxilia na identificação dos requisitos do software. Os

Um modelo espiral possui diversas atividades definidas pela engenharia de software,

Figura 4 - Ilustrando o Modelo espiral.

Sempre iniciamos pelo centro da espiral e prosseguimos no sentido horário. Os riscos

O modelo espiral é largamente utilizado e é considerada uma abordagem realista para

Um modelo de processo especializado leva em conta muitas das características de um

Temos um conjunto de três modelos de processo especializado, são eles: Modelo

Desenvolvimento baseado em componentes

O desenvolvimento de software baseado em componentes tem como ênfase criar

Um tipo de componente bastante conhecido e utilizado são os componentes de

De forma geral, um componente é algo quase independente e uma parte substituível

O modelo de desenvolvimento baseado em componentes possui diversas

Diferente de outros modelos, no modelo de desenvolvimento baseado em

Os itens de integração de componentes são considerados.

Projeta-se uma arquitetura de software para acomodar os componentes.

Integram-se os componentes à arquitetura.

Realizam-se todos os testes para assegurar a funcionalidade adequada.

Todas essas etapas são independentes da tecnologia utilizada para criar os

Uma das maiores vantagens do desenvolvimento baseado em componentes é que ele

Um exemplo de componente bastante utilizado na indústria é a tecnologia de

Modelo de métodos formais

O Modelo de Métodos Formais possui um conjunto de atividades que conduzem a uma

Nível 1, em que o desenvolvimento e a verificação formal são utilizados para produzir

A vantagem dos métodos formais durante o desenvolvimento é que eles oferecem a

Mesmo oferecendo a garantia de software sem defeitos, o modelo de métodos formais

Modelos de métodos formais são mais utilizados quando precisamos desenvolver

O Processo Unificado é um processo de desenvolvimento fortemente ligado à

Algumas características básicas do Processo Unificado são:

Centrado na arquitetura: O processo procura modelar uma arquitetura através dos

É iterativo e incremental: Uma das práticas do processo é dividir grandes projetos em

O Processo Unificado visa tornar clara a necessidade de atribuições de tarefas a

Figura 5 - Overview do Processo Unificado

Construção: A fusão de vários artefatos de software ocorre neste momento,

Em relação aos fluxos de trabalho, ou disciplinas, tem-se os seguintes