QUALIDADE DE

SISTEMAS
  O que um determinado produto apresenta para considerarmos
que o mesmo tem qualidade?
 Pensem em um carro, quais aspectos definem um carro de
qualidade?
O QUE É
QUALIDADE?
QUALIDADE É UM CONCEITO RELATIVO. DIVERSOS
ASPECTOS SÃO LEVADOS EM CONTA. NO CASO DE UM
AUTOMÓVEL, FATORES COMO CONFORTO, SEGURANÇA,
DESEMPENHO, BELEZA E CUSTO TÊM ESTREITA RELAÇÃO
COM A QUALIDADE.
  Qualidade está fortemente relacionada à conformidade com os
requisitos. Mas, o que é “conformidade em relação a
requisitos”?

O QUE É
QUALIDADE? observado x especificado

Pode haver problemas na observação.

Pode haver problemas na especificação.
  Requisitos são especificados por pessoas e com o objetivo
de satisfazer outras pessoas.
 Qualidade diz respeito à satisfação do cliente. Se atendeu
aos seus requisitos.
 Uma especificação depende das escolhas feitas (clientes
O QUE É alvo).
QUALIDADE?  O dicionário Aurélio (Ferreira, 2000) traz a seguinte
definição: Em uma escala de valores, qualidade é a
característica que permite avaliar e, consequentemente,
aprovar, aceitar ou recusar qualquer coisa.
Este é o princípio fundamental da qualidade: os padrões e
as medidas!
O QUE É QUALIDADE?

“Um produto ou serviço de qualidade

é aquele que atende, de forma
confiável, acessível, segura e no
tempo certo às necessidades do
cliente” (CAMPOS, 1992).
  Somente o processo de desenvolvimento não garantirá
que o produto seja livre de defeitos;
 Os testes indicam a presença de defeitos no produto;
POR QUE  Gastos com retrabalho
TESTAR?  Maior tempo gasto devido à manutenção do produto;
 Insatisfação dos clientes;
 Imagem negativa da organização para presentes ou
futuros clientes;
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
POR QUE
TESTAR?
 Estudantes têm dificuldades em se inscrever para
universidades:
 Por conta de ocupações estudantis nos locais de aplicação de
prova, o ENEM de 2016 teve que ser aplicado em duas datas,
2017 ocasionando a realocação de mais de 270 mil candidatos para
uma segunda data de aplicação.
TRADUZIDO  Segundo relatos de estudantes, o sistema do Sisu não
EM BUGS permitia que os candidatos que realizaram a prova na data
alternativa fizessem o cadastro. O erro do sistema fez com
que 20 mil estudantes ficassem impossibilitados de se
inscrever para qualquer curso, independente da nota.
 A Yahoo revelou que um ataque malicioso resultou no
vazamento de dados de 1 bilhão de contas de e-mail
A situação aconteceu em 2013, mas só veio a tona no final de
2017 2016. Contudo, o caso gerou reflexos práticos apenas em 2017,
trazendo consequências notáveis: em fevereiro, a Verizon, que
TRADUZIDO negociava um contrato de compra com a Yahoo, conseguiu
EM BUGS fechar negócio por U$ 350 milhões de dólares a menos do que
a oferta inicial por conta dos ataques cibernéticos. Além
disso, recentemente a justiça americana resolveu processar o
Yahoo por conta do vazamento.
 O inverno chegou para a HBO
A emissora americana se viu alocada em uma verdadeira
“Guerra dos Tronos” após hackers roubarem 1.5 terabytes de
2017 informações da empresa.

TRADUZIDO Em julho, a empresa confirmou que hackers invadiram

sistemas da empresa e tiveram acesso a episódios e
EM BUGS roteiros de suas séries de TV, informações financeiras e
outros documentos importantes. Qual o impacto disso?
Episódios de Game of Thrones foram vazados online antes de
sua exibição na TV.
 Waze contribuiu para piorar congestionamento em São
Paulo
2017 O aplicativo apresentou uma falha durante o pico de trânsito
TRADUZIDO na Avenida 23 de Maio e insistiu em redirecionar os motoristas
para o local, já congestionado. Resultado? O trânsito na
EM BUGS região no horário em questão foi três vezes maior do que a
média.
 Bug na American Arlines garante as férias de seus pilotos e
cancela a de seus clientes
2017 Segundo a empresa, o software que regula as férias dos
pilotos permitiu que todos eles tirassem férias durante o
TRADUZIDO Natal, ignorando a premissa que requer um número mínimo
EM BUGS de pilotos operantes para manter os voos em curso. O
impacto deste erro pode ter afetado 15 mil voos que seriam
realizados entre os dias 17 e 31 de dezembro.
ERRO, DEFEITO OU FALHA?
TESTE DE SOFTWARE

 Testar é o processo de executar um programa ou sistema com a intenção de

encontrar defeitos (Myers,1979)
 Testar é qualquer atividade que a partir da avaliação de um atributo ou
capacidade, permita determinar se o programa ou sistema obtém resultados
desejados. (Hetzel,1988)
 Testar é verificar se o software está fazendo o que deveria fazer, de acordo com
seus requisitos, e se não está fazendo o que não deveria fazer. (Rios, Cristalli,
2003)
Encontrar defeitos

Ganhar confiança sobre o nível de OBJETIVOS DO

qualidade TESTE DE
SOFTWARE
Prover informações para tomadas
de decisão

Prevenir defeitos
TESTES DE SOFTWARE: PRÉ-CONCEITOS
TESTES DE SOFTWARE: PRÉ-CONCEITOS
TESTES DE SOFTWARE: PRÉ-CONCEITOS
DIMENSÕES DA
QUALIDADE
CARACTERÍSTICAS DE BONS TESTADORES

Aprendizado contínuo;
Capacidade analítica (ler nas entrelinhas, ter opinião forte, compreender os requisitos);
Boa comunicação
Criativo
Perfeccionista
Observador
Detalhista
CARREIRA
 Tester (Testador) – é a posição de entrada na área. O Tester é responsável pela execução dos testes,
que em muitas vezes incluem as seguintes atividades: testar configurações de hardware e software,
executar scripts simples de teste, reproduzir e reportar bugs.
 Analista de Teste – é o profissional responsável pela modelagem e elaboração dos casos de teste e
pelos scripts de teste. Em algumas vezes, ele também é o responsável pela execução de testes mais
específicos.
 Analista de Automação de Teste – é o cargo mais recente da área de Testes. O Analista de
Automação de Teste é um profissional que tem como objetivo principal, buscar a automatização de
testes, sempre que ela for possível e viável.
 Arquiteto de Teste – é o responsável pela montagem da infra-estrutura de teste, monta o ambiente
de teste, escolhe as ferramentas de teste e capacita a equipe para executar seu trabalho nesse
ambiente de teste. É uma função que exige um bom conhecimento em hardware e redes para projetar
ambiente de testeque seja o mais próximo do de produção.
 Líder de Teste – é o profissional responsável pela condução dos testes e pela equipe de Testes.
Geralmente é um profissional com alto grau de conhecimento em ciclos de vida de testes, automação
de testes, ambientes de testes e documentação de testes.
 Gerente de Teste – o Gerente de Teste tem como função primordial o gerenciamento do projeto de
teste a ser realizado no produto a ser testado. Suas qualificações e competências se assemelham a um
gerente de projetos típico:
 elaborar o plano do projeto de teste, aquisição de novos recursos, orçamento, riscos, prazos, elaboração de
relatórios, limitações do escopo do projeto de teste e outras atividades gerenciais como constante
comunicação com sua equipe, controle e monitoração das atividades, geração de métricas para alimentar
indicadores, etc.
CERTIFICAÇÕES
QUANDO É IMPORTANTE TESTAR?
QUANDO É IMPORTANTE TESTAR?
PROCESSO DE TESTE NO MODELO
CASCATA
PROCESSO DE TESTE HOJE
VERIFICAÇÃO X VALIDAÇÃO
 Diagrama de Pareto
Diagrama de causa e efeito (ou Diagrama de Ishikawa)
Histograma
FERRAMENTAS Folhas de verificação
DA QUALIDADE
Gráficos de dispersão
Fluxograma
Cartas de Controle.
 MAS COMO A QUALIDADE PODE SER
AVALIADA?
 A figura ao lado mostra os
fatores de qualidade
propostos por McCall
(1977).

 Esses fatores foram

divididos em três
principais categorias:
o operação do produto;
o revisão do produto;
o transição do produto
MAS COMO A QUALIDADE PODE SER
AVALIADA?
MAS COMO A QUALIDADE PODE SER
AVALIADA?
MAS COMO A QUALIDADE PODE SER
AVALIADA?
 MAS COMO A QUALIDADE PODE SER
AVALIADA?

1. Os fatores de qualidade citados representam características que

podem ser desejadas num produto de software.
2. Para cada software, algumas dessas características podem ser mais
importantes que outras.
3. Algumas ,por outro lado, podem ser irrelevantes para a avaliação de
algum software
MÉTRICAS DA QUALIDADE DE
SOFTWARE
 As métricas são as formas de medir a qualidade. Elas normalmente estão
associadas a uma escala de valores. Por exemplo (Entre 0-min e 10-max).
MÉTRICAS DA QUALIDADE DE
SOFTWARE
 As métricas são as formas de medir a qualidade. Elas normalmente estão
associadas a uma escala de valores. Por exemplo (Entre 0-min e 10-max).
MÉTRICAS DA QUALIDADE DE
SOFTWARE
 As métricas são as formas de medir a qualidade. Elas normalmente estão
associadas a uma escala de valores. Por exemplo (Entre 0-min e 10-max).
FATORES DE
QUALIDADE X
MÉTRICAS DE
QUALIDADE
FATORES DE
QUALIDADE X
MÉTRICAS DE
QUALIDADE
PILARES DA QUALIDADE DE
SOFTWARE
PILARES DA QUALIDADE DE
SOFTWARE
1. Planejamento da qualidade: visa a identificar os padrões de qualidade que
serão utilizados e a definir como satisfazê-los.

2. Garantia da qualidade: envolve estruturação, sistematização e execução de

atividades que garantam a qualidade em todas as etapas do
desenvolvimento do software, sempre atendendo ao planejamento da
qualidade anteriormente estabelecido.

3. Controle da qualidade: diz respeito ao monitoramento dos resultados das

atividades de garantia de qualidade. Isso significa que o controle da
qualidade acompanha as ações de garantia de qualidade e, quando
necessário, propõe ações corretivas e preventivas.
QUALIDADE DO PRODUTO X QUALIDADE DO
PROCESSO
 A qualidade do produto foca o resultado do processo produtivo, isto é, aquilo que
é produzido.
 A qualidade do processo tem como foco a forma como se realiza a produção, ou
seja, o processo produtivo.
QUALIDADE DO PROCESSO X QUALIDADE DO
PRODUTO
 Dimensão da qualidade do processo de software: tem como foco a avaliação da
qualidade dos diversos artefatos gerados durante o ciclo de desenvolvimento de
software. Esses artefatos incluem documentos, como os requisitos levantados,
diagramas, tabelas, modelos etc., que devem ser verificados à medida que são
produzidos. As atividades de verificação desses artefatos são conhecidas como
testes de verificação, ou testes estáticos.

 Dimensão da qualidade do produto: tem como foco a validação dos produtos de

software gerados durante o processo de desenvolvimento. Os testes feitos nos
produtos são conhecidos como testes de validação, ou testes dinâmicos.
QUALIDADE DO PROCESSO X QUALIDADE DO
PRODUTO
 No teste estático:
TESTE ESTÁTICO X TESTE • O código é examinado.
DINÂMICO
No teste dinâmico

• O código é testado.
NORMAS DE QUALIDADE DO PRODUTO
DE SOFTWARE
RESUMO
 ISO/IEC

 ISO (Organização Internacional para Padronização): uma

entidade que estabelece normas e padrões para os mais
variados segmentos em todo o mundo.

 IEC (Comissão Internacional de Eletrotécnica): entidade

que ajuda no estabelecimento de padrões.

 Quando estabelecem normas em conjunto elas têm sua

denominação ISO/IEC.
NORMAS DA SÉRIE ISO 9000

 Empresas de qualquer segmento que implantam uma norma ISO da série 9000
passam a ser reconhecidas como empresas organizadas, que têm seus processos
bem estabelecidos e padronizados. Dessa família de normas, as mais
importantes são:
1. ISO 9001: é a mais completa, pois abrange todo o ciclo de vida de um
produto ou serviço e inclui requisitos para garantir a qualidade em todas
as etapas do processo.
2. ISO 9002: possui requisitos para garantir a qualidade na produção, na
instalação e em serviços associados.
3. ISO 9003: foca apenas a garantia da qualidade em inspeções e ensaios
finais de produtos.
NORMA 9001
NORMA ISO/IEC 9126
NORMA ISO/IEC 9126

 A norma ISO/IEC 9126 trata de um conjunto de características que visam à

avaliação de um produto de software.
NORMA ISO/IEC 9126

 Ela apresenta três diferentes visões possíveis para se alcançar um software de qualidade:

 Visão do usuário – diz respeito ao atendimento das expectativas do usuário, para quem o
software será desenvolvido. Essa visão está associada às funcionalidades, ao
desempenho e à facilidade de uso.

 Visão do desenvolvedor – está relacionada a medidas internas de qualidade do software,

conhecidas apenas por quem participa do processo de desenvolvimento. Uma das
preocupações pode ser a facilidade para dar manutenção no software.

 Visão do gerente de desenvolvimento – diz respeito a uma visão mais abrangente, que
busca medir a qualidade geral do software em desenvolvimento.
NORMA ISO/IEC 14598

 A norma ISO/IEC 14598 deve ser usada em conjunto com a ISO/IEC 9126 e
tem como objetivo a avaliação dos produtos de software.
NORMA ISO/IEC 12119

 A norma ISO/IEC 12119 estabelece requisitos de qualidade para “pacotes

de software”.

 Entende-se por “pacote de software” aqueles produtos vendidos de forma

idêntica a usuários distintos.

 Eles são também conhecidos como “softwares de prateleira” ou “pacotes

fechados”, pois os clientes que os adquirem não o fazem por encomenda.
NORMA ISO/IEC 12119
NORMA ISO/IEC 12207

A norma ISO/IEC 12207 refere-se aos processos de ciclo de vida de

software. Veja os 03 principais:
1. Processos fundamentais: refere-se ao conjunto de processos básicos que
vão desde o início até o fim do ciclo de vida do software. Esses processos
são: aquisição, fornecimento, desenvolvimento, operação e
manutenção.
2. Processos de apoio: refere-se ao conjunto de processos que auxiliam na
qualidade do processo de desenvolvimento de software.
3. Processos organizacionais: refere-se ao conjunto de processos que devem
ser usados pela empresa do ponto de vista administrativo a fim de
contribuir para o sucesso na busca pela garantia da qualidade no
desenvolvimento do software.
NORMA ISO/IEC 12207

 Ela também prevê os princípios da gerência da qualidade. Veja:

1. Integração da qualidade no ciclo de vida: recomenda a utilização do Ciclo

PDCA durante todo o ciclo de vida do software.

2. Processo de garantia da qualidade: recomenda que o processo de garantia

3. da qualidade seja implementado durante todo o ciclo de vida do software.

4. Processo de melhoria: recomenda a busca pela melhoria contínua da

qualidade.
NORMA ISO/IEC 15504 (SPICE)

 A norma ISO/IEC 15504 originou-se de um projeto denominado SPICE que

é uma sigla em inglês para Software Process Improvement and Capapility
dEtermination, que poderia ser traduzido para português como melhoria
dos processos de software e dimensão da capacidade.

 A norma ISO/IEC 15504 possui duas dimensões:

1. dimensão de processos: que trata de requisitos relativos ao processo
de desenvolvimento de software e segue . Segue modelo proposto pela
ISO 12207
2. dimensão da capacidade: determina seis níveis de maturidade dos
processos de uma organização.
 NORMA ISO/IEC 15504 (SPICE)

 Na dimensão de processos:
Processos de Gestão: Processos de Recursos e Infraestrutura:
 Alinhamento aos objetivos estratégicos da  Gestão de RH;
organização;  Treinamento;
 Estabelecimento de práticas de gestão em geral, e  Gestão do conhecimento;
especialmente gestão de projeto;
 Infraestrutura: Recursos materiais, ambiente de
 Gestão da qualidade;
trabalho, ferramentas;
 Gestão de riscos;
 Medição;
Processos de Reuso:
Processos de Melhoria de Processos:  Gestão de Ativos
 Definição de processos; (Componentes/módulos/informações) suscetíveis
 Avaliação de processos: Avaliar como os processos de reuso;
estão contribuindo para a organização alcançar seus  Gestão do programa de Reuso: Estratégia,
objetivos; definição de domínios, procedimentos, melhoria;
 Melhoria de processos: Comprometimento, priorização,
gestão das ações de melhoria;
NORMA ISO/IEC 15504 (SPICE)

 Na dimensão de capacidade, essa norma classifica o processo de

desenvolvimento de software de uma organização em seis possíveis níveis,
acompanhe:
 Nível 0, ou incompleto: O processo não é implementado ou não
consegue gerar os produtos de trabalho esperados. Existe pouca ou
nenhuma evidência de qualquer tipo de sucesso sistemático
 Nível 1, ou executado: O processo consegue alcançar os objetivos de
alguma maneira e gerar os produtos de trabalhos esperados.
 Nível 2, ou gerenciado: indica que há padrões, tanto de
planejamento como de execução dos processos, que garantem que
os resultados sempre sejam alcançados com um nível de qualidade
satisfatório.
NORMA ISO/IEC 15504 (SPICE)

 Nível 3, ou estabelecido: indica que os padrões de planejamento e

de execução existentes seguem os princípios estabelecidos pela
engenharia de software, o que garante que os resultados terão
sempre o mesmo padrão de qualidade.
 Nível 4, ou previsível: indica que há padrões de planejamento e de
execução coerentes com aqueles estabelecidos pela engenharia de
software, além de medições detalhadas de desempenho e de
medidas quantitativas de capacidade do processo. Essas medidas
permitem prever as medidas de qualidade dos resultados com
relevante grau de precisão.
 Nível 5, ou em otimização: indica que todos os níveis anteriores
foram atingidos e que o objetivo passa a ser a busca contínua pela
melhoria do processo.
MODELO DE CAPACITAÇÃO
CMM/CMMI
 A sigla CMM origina-se de Capability Maturity Model, que pode ser traduzido
como Modelo de Capacidade e Maturidade. Foi idealizado pelo Instituto de
Engenharia de Software da Universidade Carnegie Mellon, nos Estados
Unidos, com o objetivo de estabelecer um padrão de qualidade para
desenvolvimento de software.
 Desde a sua criação, surgiram várias versões do modelo CMM. Para
padronizá-lo em um só, foi desenvolvido o modelo CMM integradoou,
simplesmente, CMMI. O CMMI estabelece cinco níveis de maturidade para o
processo de desenvolvimento de software.
 GERENCIAMENTO DE PROCESSO

Para o modelo CMMI, um processo é

composto de três elementos-chave:
▪▪ as pessoas que participam do
planejamento, da execução e do
controle do processo;
▪▪ os procedimentos e métodos que
indicam como o processo deve ser
realizado;
▪▪ as ferramentas e os equipamentos
que são utilizados ao longo do processo.
 NÍVEIS DE MATURIDADE -CMMI

Nível 1 - Inicial: imaturidade organizacional; os processos são improvisados e geralmente não são
seguidos; compromissos de prazo e custo não são cumpridos; o planejamento não é feito com base
em estimativas; as qualidades, procedimentos e conhecimentos pertencem às pessoas e não aos
projetos; as chances de sucesso dependem das habilidades pessoais dos gerentes e desenvolvedores;
Nível 2 - Gerenciado: políticas e procedimentos para gerenciar o desenvolvimento de software estão
definidas e são obedecidas; o planejamento é baseado em estimativas e na experiência anterior de
outros projetos; os projetos utilizam processos definidos, usados, disseminados, documentados,
medidos e fiscalizados com rotinas de melhoria; os processos afetados são puramente gerenciais (não
técnicos) e pertencem aos projetos e não às pessoas;
Nível 3 - Definido: os processos utilizados são estabelecidos e padronizados em toda a organização;
processos técnicos passam a ser considerados ao lado dos processos gerenciais; tanto os processos
gerenciais quanto os técnicos passam a ser repetidos; os processos pertencem a organização e não
mais aos projetos;
 NÍVEIS DE MATURIDADE - CMMI

Nível 4 - Quantitativamente Gerenciado: são estabelecidas metas quantitativas para os processos e

produtos, medidas de qualidade e produtividade são coletadas em todos os projetos; é estabelecido
controle estatístico de processos; a gestão passa a ser feitas com bases quantitativas;

Nível 5 - Otimização: a organização está engajada na melhoria contínua de seus processos;

identificação de pontos fracos e defeitos; ações preventivas sobre causas; mudanças mais
significativas de processos e/ou tecnologias são feitas a partir de análise de custo/benefício com base
em dados quantitativos.
NÍVEIS DE MATURIDADE CMM
PAUSA PARA PENSAR NO
FUTURO
O QUE É SER UM BOM
PROGRAMADOR?
Habilidades de Projeto
• Aprenda a reusar código.
• Aprenda padrões de projeto.
• Aprenda bem uma linguagem de programação.
• Aprenda um pouco sobre várias linguagens.
• Aprenda a documentar com sabedoria.
• Aprenda a manipular a IDE.
• Aprenda a realizar testes de unidade.
O QUE É SER UM BOM
PROGRAMADOR?
Habilidades de Grupo
• Aprenda a fazer estimativas de esforço.
– Estimativas individuais e de grupo.
• Aprenda a encontrar informações.
– Utilizando pessoas como fontes de informação.
• Aprenda a trabalhar com código ruim.
• Aprenda a usar ferramentas de controle de versão.
• Aprenda a lidar com código de terceiros.
• Aprenda a discordar.
O QUE É SER UM BOM
PROGRAMADOR?
Habilidades Individuais
• Aprenda a aprender novas habilidades.
• Aprenda a parar de trabalhar quando estiver cansado.
• Aprenda a lidar com pessoas difíceis.
• Aprenda a trocar qualidade por tempo de
desenvolvimento.
• Aprenda a decidir entre comprar e fazer.
• Aprenda a se manter motivado.
• Aprenda a apresentar e defender suas ideias.
FIM DA PAUSA
 Abandono de planos
Acúmulo e procedimentos Produto funciona, mas com
de trabalho defeitos; prazo e custo maiores; e
menos funcionalidade

Clientes e
Sucesso depende muito do esforço funcionários
heróico das pessoas Pouca insatisfeitos
repetibilidade
VOCÊ ESTARIA SATISFEITO COM UM
NÍVEL DE QUALIDADE DE 99,9%?

 20.000 prescrições médicas erradas por ano;

 Beber água não confiável uma hora por mês;
 Nenhum serviço telefônico durante 10 minutos por
semana;
 Falta de água e luz 10 horas por ano;
 500 cirurgias incorretas por semana;
 2.000 envios dos correios perdidos por semana.
TOTAL QUALITY MANAGEMENT (TQM)
GESTÃO DA QUALIDADE TOTAL

 Aspectos Fundamentais

 Atender as necessidades e expectativas do cliente (a “parte” mais importante da

organização).
 Considerar o cliente e fornecedor interno/externo.
 Envolver todas as pessoas da organização.
 Examinar custos relacionados com a qualidade.
 Desenvolver sistemas e procedimentos que suportem qualidade e melhoria.
 Desenvolver um processo de melhoria contínua.
EVOLUÇÃO DA QUALIDADE
BENEFÍCIOS DA QUALIDADE

 Na visão do fornecedor (ex: equipe interna de TI ou fornecedor externo – do

mercado)
 Maior produtividade
 Maior precisão nas estimativas
 Redução de defeitos no produto
 Aumento da confiabilidade do produto
 Menos esforço de re-trabalho
 Menos horas extras de trabalho
 Redução do tempo para atender o mercado
 Redução de custo de desenvolvimento e manutenção
 Maior competitividade
 Maior índice de satisfação do cliente/usuário final
BENEFÍCIOS DA QUALIDADE

 Na visão do contratante
 Auxilia a definição de critérios para seleção e descredenciamento de fornecedores
 Auxilia a definição de processos de acompanhamento do progresso e desempenho dos
fornecedores nas etapas de desenvolvimento, entrega e pós-entrega dos produtos
 Auxilia a definição de critérios para avaliação e aceitação dos produtos entregues pelo
fornecedor
GESTÃO DA QUALIDADE

 “Atividades coordenadas para orientar e controlar uma organização com

relação à qualidade”
 Princípios de Gestão da Qualidade da ISO
 Foco no cliente
 Liderança
 Competência e comprometimento das pessoas
 Abordagem de processo
 Melhoria (contínua)
 Decisão baseada em informações
 Gestão de relacionamento (relações de “ganha-ganha”).
 MAIOR MITO DE TODOS

 Mito: Criar programas é uma arte que não pode seguir regras, normas ou padrões.

Causas:
• Produtos de software são complexos.
• Software não tem produção em série. Custo está no projeto e desenvolvimento.
• Software não se desgasta.
• Software é invisível. Sua representação em grafos e diagramas não é precisa.
• A Engenharia de Software ainda não está madura, é uma tecnologia em evolução.
• Não há um acordo entre os profissionais sobre o que é qualidade de software.
TESTES DE SOFTWARE
TESTE DE SOFTWARE

 É o processo de executar um programa com o objetivo de encontrar defeitos

(Myers, 1979).
 Do ponto de vista psicológico, o teste de software é uma atividade com um certo
viés destrutivo, ao contrário de outras atividades do processo de software.

Erro: é uma ação humana que produz um resultado

incorreto
Defeito: A manifestação de um erro no software.
Falha: quando o sistema se comporta de forma
inesperada devido ao defeito.
 O CICLO DE VIDA DOS TESTES

 Planejamento
 Nesta fase é elaborada a Estratégia de Teste e o Plano de Teste, em cima dos requisitos.
 Preparação
 O objetivo desta fase é preparar o Ambiente de Teste (equipamentos, pessoal, ferramentas de automação,
massa de testes) para que os testes sejam executados conforme planejados.
 Especificação
 Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e Elaborar/ Revisar roteiros de
testes.
 Execução
 Os testes são executados e os resultados obtidos são registrados.
 Entrega
 Esta é a última fase do ciclo de vida de testes, onde o projeto é finalizado e toda documentação é finalizada
e arquivada.
TESTE DE SOFTWARE
ARTEFATOS

 O caso de teste geralmente consiste de uma referência a um identificador ou

requisito de uma especificação, pré-condições, eventos, uma série de passos a se
seguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado
obtido.
 A série de passos (ou parte dela) pode estar contida num procedimento separado,
para que possa ser compartilhada por mais de um caso de teste: O roteiro de teste.
 Um roteiro de teste é a combinação de um caso de teste, um procedimento de
teste e os dados do teste.
 Uma coleção de casos de teste é chamada de suíte de teste. Geralmente, ela
também contém instruções detalhadas ou objetivos para cada coleção de casos de
teste, além de uma seção para descrição da configuração do sistema usado..
 PERSPECTIVA DE TESTE

 Bons testadores necessitam de um conjunto especial de habilidades. Um testador deve

abordar um software com a atitude de questionar tudo sobre ele (McGregor e Sykes, 2001).

 A perspectiva de teste é, um modo de olhar qualquer produto de desenvolvimento e

questionar a sua validade.

 Habilidades requeridas na perspectiva de teste:

 Querer prova de qualidade,
 Não fazer suposições,
 Não deixar passar áreas importantes,
 Procurar ser reproduzível.
CENÁRIO TÍPICO DA ATIVIDADE
DE TESTE
 Se os resultados obtidos coincidem com os resultados esperados, então nenhum
defeito foi identificado (“O software passou no teste”).
 Se, para algum caso de teste, o resultado obtido difere do esperado, então um
defeito foi detectado (“O software não passou no teste”).
 De maneira geral, fica por conta do testador, baseado na especificação do
programa, decidir sobre a correção da execução (Delamaro et al., 2007).
PERSPECTIVA DE TESTE

 A perspectiva de teste requer que um fragmento de software demonstre não

apenas que ele executa de acordo com o especificado, mas que executa apenas o
especificado (McGregor e Sykes, 2001).

 O software faz o que deveria fazer e somente isso?

 TESTE DE SOFTWARE

 Ao se testar , devem-se selecionar alguns pontos específicos de para executar.

 Portanto, testes podem mostrar apenas a presença de defeitos, mas não a ausência
deles.
 Um aspecto crucial para o sucesso na atividade de teste é a escolha correta dos
casos de teste. Um teste bem-sucedido identifica defeitos que ainda não foram
detectados.
 Um bom caso de teste é aquele que tem alta probabilidade de encontrar um defeito
ainda não descoberto.
TESTE X DEPURAÇÃO

 Teste: Processo de execução de um programa com o objetivo de revelar a

presença de erros. Contribuem para aumentar a confiança de que o software
desempenha as funções especificadas.
 Depuração: Consequência não previsível do teste. Após revelada a presença do
erro, este deve ser encontrado e corrigido.
FASES OU NÍVEIS DE TESTE
 FASES (OU NÍVEIS) DE TESTE

 Teste de Unidade
 Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores
unidades de software desenvolvidas (pequenas partes ou unidades do sistema).[10] O universo alvo
desse tipo de teste são as subrotinas, métodos, classes ou mesmo pequenos trechos de código.
Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema
funcionando independentemente do todo.Teste de Integração
 Identificar erros associados às interfaces entre os módulos do software
 Teste de Integração
 Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos
componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de
dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar
um método do componente B; porém, B pode retornar um valor Y, gerando uma falha. O teste de
integração conduz ao descobrimento de possíveis falhas associadas à interface do sistema. Não faz
parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração
entre sistemas).
 FASES (OU NÍVEIS) DE TESTE

 Teste de Sistema
 Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final,
varrendo as funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são
executados em condições similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas
que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de
uma organização, podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas
de dados.
 Teste de Aceitação
 Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do
sistema, que simulam operações de rotina do sistema de modo a verificar se seu comportamento
está de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou
não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema.
Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou
cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de
falhas, de segurança e de desempenho.
FASES OU NÍVEIS DE TESTES
TESTE DE SOFTWARE

 Existem duas maneiras de se selecionar elementos de cada um dos

subdomínios de teste (Delamaro et al., 2007):

 Teste Aleatório: um grande número de casos de teste é selecionado

aleatoriamente, de modo que, probabilisticamente, se tenha uma boa
chance de ter todos os subdomínios representados no teste.

 Teste de Subdomínios ou Teste de Partição: procura-se estabelecer

quais são os subdomínios a serem utilizados e, então, selecionam-se os
casos de teste em cada subdomínio.
TESTE DE SUBDOMÍNIOS

 A identificação dos subdomínios é feita com base em critérios de teste.

Dependendo dos critérios estabelecidos, são obtidos subdomínios diferentes.
 Tipos principais de critérios de teste:
 Funcionais
 Estruturais
 Baseados em Modelos
 Baseados em Defeitos
 Esses tipos de teste correspondem às chamadas técnicas de teste.
TESTE DE SUBDOMÍNIOS

 Técnica Funcional (ou caixa preta)

 Os testes são baseados exclusivamente na especificação de requisitos do programa. Nenhum
conhecimento de como o programa está implementado é requerido.

 Técnica Estrutural (ou caixa branca)

 Os testes são baseados na estrutura interna do programa, ou seja, na implementação do
mesmo.
 Técnica Baseada em Defeitos (ou erros)
 Erros históricos mais frequentes cometidos durante o processo de desenvolvimento de
software

 Técnica Baseada em Modelos

 A partir da especificação é criado um modelo (representação do funcionamento de um
software)
TÉCNICA FUNCIONAL (CAIXA PRETA)

 Baseia-se na especificação do software para derivar os requisitos

de teste;
 Aborda o software de um ponto de vista macroscópico
 Envolve dois passos principais:
 Identificar as funções que o software deve realizar (especificação
dos requisitos)
 Criar casos de teste capazes de checar se essas funções estão
sendo executadas corretamente
TÉCNICA FUNCIONAL (CAIXA PRETA)
TÉCNICA FUNCIONAL (CAIXA PRETA)
TÉCNICA ESTRUTURAL (CAIXA
BRANCA)
 Baseada no conhecimento
da estrutura interna
(implementação) do
programa. A maioria dos
critérios dessa técnica utiliza
uma representação de
programa conhecida como
grafo de programa ou grafo
de fluxo de controle.
TÉCNICA BASEADA EM
DEFEITOS
 Os requisitos de teste são derivados a partir dos erros mais
frequentes cometidos durante o processo de desenvolvimento do
software.
TÉCNICA BASEADA EM
MODELOS
 São modelos derivados dos requisitos.
TIPOS DE TESTES
RESUMO DOS TIPOS DE TESTES DE SOFTWARE

Tipo de Teste Descrição

Teste de Unidade Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.

Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é
Teste de Integração
composto por diversos testes de unidade

Teste Operacional Garante que a aplicação pode rodar muito tempo sem falhar.

Teste Positivo-negativo Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção.

Teste de regressão Toda vez que algo for mudado, deve ser testada toda a aplicação novamente.

Não se está preocupado com o código, cada saída indesejada é visto como um erro. Testar as funcionalidades,
Teste de caixa-preta
requerimentos, regras de negócio presentes na documentação. Validar as funcionalidades descritas na documentação (pode
(funcional)
acontecer de a documentação estar inválida)

Teste caixa-branca
O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas.
(estrutural)
RESUMO DOS TIPOS DE TESTES DE SOFTWARE

Tipo de Teste Descrição

Teste de Interface (ou Teste de Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem
Usabilidade) da melhor forma ao usuário.

Teste de Performance Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.

Verifica o funcionamento da aplicação com a utilização de uma quantidade grande de usuários

Teste de carga
simultâneos.

Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para
Teste de aceitação do usuário executar uma função, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da
interface, também).

Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou além de grande)
Teste de Volume
durante muito tempo de uso.
RESUMO DOS TESTES DE SOFTWARE

Tipo de Teste Descrição

Testar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes
Testes de stress não previstos no desenvolvimento/documentação.
Testar se a aplicação funciona corretamente em diferentes ambientes de
Testes de Configuração hardware ou de software.

Testes de Instalação Testar se a instalação da aplicação foi OK.

Testar a segurança da aplicação das mais diversas formas. Utilizar os diversos

Testes de Segurança papéis, perfis, permissões, para navegar no sistema.
TESTE DE CAIXA CINZA
(GRAYBOX)
 O conceito de teste de caixa cinza não é muito bem definido nem muito bem
aceito por todos. Há muitos autores que dizem que o teste de caixa cinza é
simplesmente o teste de integração. Há quem diga que o teste de caixa cinza é
uma mistura do teste de caixa preta e teste de caixa branca, mas isso é um
conceito muito vago e sem muitos argumentos plausíveis que o defendam.
DOCUMENTAÇÃO DE TESTE
Baseada na IEEE 829-1998 (IEEE,1998)
NORMA IEEE 829-1998
(IEEE,1998)
Prevê documentos para as atividades de teste
de um produto de software. Esses documentos
serão usados na tarefa de planejamento,
especificação e relato de testes.
 DOCUMENTOS:

Documento
Utilizado na tarefa de planejamento para execução do teste, no qual
Plano de Teste
Especificação de Projeto de Teste
Especificação de Caso de Teste
Uso
serão identificadas as funcionalidade a serem testadas com ênfase
nas datas, pessoas envolvidas e riscos.
Refina a abordagem apresentada no Plano de Teste, que além de
identificar os casos e os procedimentos de teste, se existirem,
apresenta os critérios de aprovação.
Identifica os casos de teste com os dados de entrada, resultados
esperados, ações e condições gerais pra a execução do teste.
 Documento Uso
Especificação de
Procedimento de Identifica quais serão os passos para executar os casos de teste.
Teste
Composto por 4 documentos: Diário de Teste, Relatório de Incidente de Teste,
Relatórios de Teste
Relatório-Resumo de Teste e Relatório de Encaminhamento de Item de Teste.
Diário de Teste: Exibe registros cronológicos dos dados relevantes relacionados com a execução dos teste.
Relatório de Incidente de Teste: Documenta qualquer evento que ocorra durante a atividade de teste e
que necessite de análise depois.
Relatório-Resumo de Teste: Resumo dos resultados das atividades de teste
Relatório de Encaminhamento de Item de Teste: identifica os itens encaminhados para teste no caso de
equipes distintas serem responsáveis pelas tarefas de desenvolvimento e de teste.
A) PLANO DE TESTE

 Nome do projeto, nome das pessoas que participarão do s testes e suas

respectivas responsabilidades, cronograma com datas e horários para os testes,
critérios para considerar o teste como finalizado, funcionalidades e módulos que
serão testados, equipamentos e/ou softwares necessários, forma de escalar
problemas : e-mail direto aos envolvidos ou aos superiores responsáveis.

 Exemplo no próximo slide

A) PLANO DE TESTE
B) CASOS DE TESTE

 Para facilitar foram unificados os documentos: Especificação do Projeto de Teste,

Especificação dos Casos de Teste e Especificação dos Procedimentos de Teste.
 As informações neste documento são: nome do projeto, número identificados do
teste que deverá ser único, módulo ou rotina a ser testada, descrição sucinta do
teste, roteiro de teste contendo descrição do teste e passos a serem seguidos,
resultado esperado, resultado final do teste obtido pelo desenvolvedor
constando data e nome de quem testou e resultado final do teste obtido pelo
usuário constando data e nome de quem testou.

 Exemplo no próximo slide

B) CASOS DE TESTE
B) MODELO CASO DE TESTE QUE
UTILIZAMOS
C) RELATÓRIO DE INCIDENTE

 O relatório de incidentes é a união dos documentos Diários de Teste e Relatório

de Incidente, sendo ilustrado pela Tabela a seguir.
 As informações contidas neste documento são: número do caso de teste, status,
nome da pessoa responsável pela correção, prioridade pra correção do erro pelo
desenvolvedor, descrição detalhada do erro podendo conter a mensagem de erro
exibida na tela e nome e data de quem fez a correção.
C) RELATÓRIO DE INCIDENTE
D) RELATÓRIO RESUMO DE TESTE

 É o documento final a ser preenchido pela equipe de teste com as seguintes

informações:
 Nome do projeto, data do início e fim do teste, descrição detalhada de como foi o
teste, pessoas envolvidas, os principais números dos testes, como por exemplo,
número de casos de teste criados antes e durante a execução dos testes e o
número de execuções com sucesso, tipo de status: completado com sucesso,
completado com restrições, e não completado, percentual de casos de teste
executados...
D) RELATÓRIO RESUMO DE TESTE