O documento apresenta conceitos de qualidade, processos e técnicas de qualidade de software, incluindo Six Sigma para software. Aborda ferramentas de teste de software, melhores práticas em automação e controle de qualidade, além de conceitos sobre pessoas e resultados.

1. Rodrigo A. Oliveira, Msc, pmp
http://www.linkedin.com/in/raoliveira

2. Agenda
- Conceitos de Qualidade
- Qualidade de Software
- Processos e Técnicas
- Ferramentas
- Six Sigma para Software
- Melhores Práticas em Automação
- Pessoas
- Resultados
- Referências bibliográficas

3. Conceitos de Qualidade

4. FEIGENBAUM: "Qualidade é a correção dos problemas e de suas
causas ao longo de toda a série de fatores relacionados com
marketing, projetos, engenharia, produção e manutenção, que
exercem influência sobre a satisfação do usuário.“

5. JURAN: "Qualidade é ausência de defeitos";  ZERO DEFEITOS

6. CROSBY: "Qualidade é a conformidade do produto às suas
especificações.", ou seja, é fornecer ao cliente exatamente aquilo
que foi prometido.

7. DEMING: "Qualidade é tudo aquilo que melhora o produto do
ponto de vista do cliente", dessa forma, para ele, qualidade é
algo que tem que mudar constantemente para se manter, já que
o ponto de vista do cliente também muda. Por exemplo, um
celular Micro-Lite no final dos anos 80 era considerado algo de
muita qualidade, hoje não é bem assim.

8. ISHIKAWA: "Qualidade é desenvolver, projetar, produzir e
comercializar um produto de qualidade que seja econômico,
mais útil e sempre satisfatório para o consumidor.“

9. Michael J Harry: Seis Sigma utiliza ferramentas e métodos
estatísticos para definir problemas e situações a melhorar, medir
para obter informações e dados, analisar a informação,
incorporar a melhoria e finalmente controlar os processos a fim
de se alcançar um ciclo de melhoria continua. Esta metodologia
para melhoria de processos faz com que se atinjam níveis de
defeitos de 3,4 ppm (defeitos por milhão) para as características
críticas de qualidade (CTQ´s) dos clientes

10. Qualidade de Software

11. • Garantia da Qualidade de Software
• Foco no Processo
• Prevenção  Auditoria
• Controle da Qualidade de Software
• Foco no Produto
• Detecção  Testes de Software

12. • Teste de software é a atividade de executar o software com o
objetivo de encontrar defeitos/falhas.
• Execução controlada.
• Máximo de erros com o mínimo de recursos.
• Minimizar Riscos: evitar falhas em produção.
• Aumentar a Qualidade: reduzir a quantidade de falhas com o
usuário/Cliente (produção).

14. • Grandes e complexos sistemas de software tem se tornado uma parte
importante da nossa sociedade
• Porém produzir software é ainda algo artesanal (ou manual), sujeito a
muitos defeitos
• Remover estes defeitos custa muito tempo e dinheiro, e com a
complexidade crescrente, é preciso otimizar este processo
• De acordo com o Research Triangle Institute (RTI)¹, o custo de defeitos de
software é cerca de 59 bilhões de dolares anualmente
• Mais de um terço dos defeitos podem ser removidos com testes de
software.
• Ainda sobram outros 2/3 de defeitos a serem detectados!!!
¹ NIST Planning Report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing (U.S. Department of Commerce’s National Institute
of Standards & Technology, 2002), <http://www.nist.gov/director/planning/upload/report02-3.pdf >.

15. c
u
s
t
o
qualidade agregada ao desenvolvimento
custo desenvolvimento
custo total
custo do risco = f(probabilidade, impacto, relevância)
Perda por falta de
qualidade
Perda por excesso de
qualidade
LUCRO

16. ISO 14598...........: Avaliação de produto de software
ISO 9126.............: Qualidade de produto
ISO 12119...........: Teste e requisitos de qualidade
ISO/IEC 15504....: processo de desenvolvimento de software. Ela é uma evolução da ISO/IEC
12207
ISO/IEC 12207....: define processo de desenvolvimento de software
IEE Std 829-1998 e 829-2008: Padrão para Documentação de Teste de Software
ISO 1779 / 27000: Técnicas de segurança
ISO/IEC 20000....: gerenciamento de qualidade de serviços de TI
CMMI: Capability Maturity Model - Integration  MPSBR
PMBOK: Project Management Body of Knowledge
ITIL v.3 :Information Technology Infrastructure Library
COBIT 4.1: Control Objectives for Information and related Technology
Agile Development:Método ágil é um conjunto de metodologias de desenvolvimento de
software
Normas, guias e melhores práticas

17. Processos/Técnicas

18. • Manter a estabilidade e QUALIDADE dos produtos.
• Realizar atividades sistemáticas, planejadas e
necessárias para assegurar que uma função, módulo
ou sistema esteja em conformidade com os requisitos
especificados.

19. • Processo: É um conjunto seqüencial de ações que objetivam
atingir uma meta.
• Em engenharia de software, processo é um conjunto de
passos parcialmente ordenados, cujo objetivo é atingir uma
meta.
• A meta normalmente está associada a um produto de
software.

20. Fase do
Desenvolvimento de
Software
Quando testar
1ª
2ª
3ª
O que testar
Como testar
Tipo de Teste
Técnicas de Teste
Teste de Funcionalidade
Teste de Interface
Teste de Desempenho
Teste de Carga(Stress)
Teste de Usabilidade
Teste de Volume
Teste de Segurança
Níveis de Teste
Teste de Unidade
Teste de Integração
Teste de Sistema
Teste de Aceitação
Teste Funcional
Teste Estrutural
Particion. De Equivalência
Ánalise de Valores Limites
Baseado em Casos de Uso
Teste de Caminhos
Teste de Comandos
Teste de Ramos
Teste de Condições
Teste de Cond. Múltiplas

21. Atributos
Nível
UNITÁRIO INTEGRAÇÃO SISTEMA ACEITAÇÃO
Escopo Unidade individual Unidades
agrupadas
Sistema inteiro Simulação de
Produção
Equipe
Responsável
Desenvolvedores Desenvolvedores Testadores Testadores e
usuários
Volume de
dados
Pequeno Pequeno Grande Grande
Origem dos
dados
Criação Manual Criação Manual Criação por
processos
Dados Reais
Interfaces Não existem Não existem Simulados Reais / Simulados
Ambiente Desenvolvimento Desenvolvimento Teste Produção

23. • O Modelo V ou Scrum ou Kamban  precisam de testes
• Os ciclos de vida de testes e de desenvolvimento são totalmente
interdependentes, sendo que o ciclo de testes é dependente da
conclusão dos produtos das atividades do ciclo de
desenvolvimento.

25. Ferramentas

29. Pagas:
MS Visual Studio Test Professional
HP Quick Test Professional
IBM Rational Functional Test
Testcomplete
Automated QA
Borland Silk Test
HP Load Runner
Hyper-V
VMware
Open Source:
Selenium
Watir
Jmeter
TestLink
Mantis/Bugzilla
Junit/Nuit
Virtual Box

30. Six Sigma para Software

32. • SIX SIGMA é uma forma de medir!
• Metodologia que fornece abordagem de medição orientada a
dados para melhoria contínua de processos
• Busca satisfação do cliente
• Objetivos:
• Mover o produto/atributos de serviço para dentro dos limites
especificados pelo cliente
• Reduzir a variação no processo (causa de defeitos)

33. • Surgiu na Motorola nos anos 80, com Michael J. Harry, aplicado a
processos de manufatura
• Primeiros “belts” em ferramental estatístico (CEP, análise de variância,
métodos comparativos)
• Nos anos 90 outras empresas adotaram Seis Sigma e diversificaram usos
• Em anos recentes, novas ferramentas e modelos específicos para uso em
várias áreas e fases de processos: desenvolvimento de produtos, serviços,
finanças, marketing, software.
• “Belts” com perfil menos estatístico e mais gerenciamento de mudança

34. • O conceito estatístico, primeiramente, considera que o comportamento do
processo segue a distribuição normal de probabilidades
Distribuição Normal
• Baseado nesta premissa, busca-se reduzir gradativamente a variabilidade de um
processo até que se atinja um fator de 99,9997% de sucesso (Seis vezes o
desvio padrão)

35. • O que a metodologia Six Sigma prega é a redução drástica da variabilidade até um
nivel de 3,4 ppm (6 desvios padrão) da média até a especificação, superior ou
inferior.
• Isso significa que a cada um milhão de produtos, 3,4 estão fora das especificações
Visualização do processo
original
Visualização do processo com
variação reduzida

36. • O conceito estatístico, primeiramente, considera que o comportamento do processo segue a
distribuição normal de probabilidades;
• Baseado nesta premissa, busca-se reduzir gradativamente a variabilidade de um processo até
que se atinja um fator de 99,99966% de sucesso ou seja 3,4 PPM (Seis vezes o desvio
padrão);

37. • A tabela abaixo apresenta os Limites de Especificação vs. Defeitos para
Distribuição com Deslocamento
• Se considerarmos uma variação da média µ = ± 1,5 σ, o que é bastante comum
na vida real, teremos o gráfico da Figura:
Tabela Limites de Especificação vs. Defeitos
para Distribuição com Deslocamento de ± 1,5

38. • Medida entre a média e a especificação mais próxima
(LIE ou LSE) em quantidade de desvios-padrão (s),
utilizando a norma reduzida (z).
 
s
 

LSELSEMIN
Z
,

s
LIE LIE
Índice Cpk = 2
  6
)6(,)6(



s
ss
Z
P(X<LIE) = P(z < -6) = 1,25 ppm
P(X>LSE) = P(z < 6) = 1,25 ppm
6s 6s

39. Não!!!!
3,4 PPM
Defeituosos
LSELIE
Outro programa para cortar e reduzir custos?..
Somente um monte de cálculos estatísticos que ninguém entende?..
É uma metodologia estruturada para fornecimento de
produtos e serviços melhores, mais rápidos com
custos mais baixos; com uma forte base em
conhecimento de processos e através da redução da
variabilidade dos processos.
O Processo Seis Sigma tem como foco:
• Redução do tempo de ciclo;
• Redução drástica de defeitos; e
• Satisfação dos clientes.

40. • Como é difícil manter um processo sempre centralizado, já que a longo prazo, vários
fatores provocam seu deslocamento (shift) para cima ou para baixo, a metodologia Seis
Sigma validou empiricamente que esse shift da produção era aproximadamente 1,5
desvios padrão.

1,5s
LIE LIE7,5s 4,5s
3,4 ppm~0 ppm
ZCP = ZLP + 1,5
P(X<LSE) = P(z > 4,5) = 3,4 ppm
O
Capacidade Potencial
do Processo

41. Quatro Sigma (99,38% conforme) Seis Sigma (99,99966% conforme)
Sete horas de falta de energia
elétrica por mês
Uma hora de falta de energia
elétrica a cada 34 anos
5.000 operações cirúrgicas incorretas
por semana
1,7 operação cirúrgica incorreta por
semana
3.000 falhas a cada 300.000 viagens Uma falha para cada 300.000 viagens
Quinze minutos de fornecimento de água
não potável por dia
Um minuto de fornecimento de água não
potável a cada sete meses.
1 erro a cada 30 páginas
1 erro / todos os livros de uma
pequena biblioteca

42. • Uma taxa de sucesso de 31%
(nível sigma 1) significa que para
cada 3 tentativas de uso de um
software, 2 resultarão em falha.

43. • Classificação de um software
quanto ao nível sigma:
• Sigma 1: inicial
• Sigma 2: básico
• Sigma 3: aceitável
• Sigma 4: maduro
• Sigma 5: excelente
• Sigma 6: sonho!!!

44. • No 6S, qualidade não tem a ver com conformidade com resoluções
internas ou normas;
• Qualidade Potencial - Qualidade Atual = Perda;
• Qualidade diretamente ligada com o nível sigma;
• Para avaliar qualidade do software usando Six Sigma, deve-se
considerar que:
• Cada clique é uma oportunidade de se gerar defeito
• Um clique dispara entradas, saídas, transações, processamentos,
armazenamentos internos e externos
• Casos de teste são considerados como sendo as oportunidades de
defeito

45. • Gráficos de Dispersão
• Diagrama de Controle
• Folha de Verificação
• Diagrama de Ishikawa também conhecido como
Diagrama de Causa e Efeito, Diagrama Espinha-de-
peixe ou Diagrama 6M
• Histograma
• Fluxograma
• Diagrama de Pareto

46. Melhores práticas em controle de
qualidade de software

48. 0
2
4
6
8
10
12
14
16
18
20
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
CUSTOEMR$PORTESTE
NÚMERO DE VERSÕES
Teste Manual x Teste Automatizado
MANUAL AUTOMATIZADO

49. • Garantir que o que funcionava continua funcionando
• Verificar e validar impacto das mudanças feitas no software
• Testes Efetivos em cada release (regressão)
• Executar teste com maior frequência
• Executar testes que seriam impossíveis de serem executados
• Consistência e repetibilidade.
• Testadores podem focar em testes avançados
• Maior cobertura dos testes funcionais em menos tempo
• Reuso dos testes

50. • Falsa expectativa
• Prática de teste “pobre”
• Expectativa que a automação irá achar uma série de novos
defeitos
• Falso senso de segurança
• Problemas técnicos (não saber automatizar!)
• Cultura organizacional
• Não substitui o teste manual
• Testes manuais acharão mais defeitos
• Ferramentas não tem imaginação

51. • A automação de testes não é um processo de testes
• Não é possível automatizar o caos
• Automatize os testes críticos primeiro
• Incorpore testabilidade ao aplicativo
• As ferramentas de automação de testes também têm defeitos
• Demonstração de ferramenta não é prova de conceito
• Dimensione a infra-estrutura adequadamente
• Encare a automação de testes como um projeto
• Alinhe as expectativas e garanta a colaboração de todos os envolvidos
• A automação de testes é um investimento de longo prazo
• O teste manual é insubstituível
Dicas sobre automação de testes

52. • Q1 – São os testes que focam na arquitetura. A responsabilidade é dos desenvolvedores e os analistas de teste auxiliam
na elaboração dos testes unitários automáticos
• Q2 – São os testes que focam no negócio. A responsabilidade é dos analistas de teste em conjunto com outros
envolvidos no projeto(clientes, usuários, etc.). Ajuda no entendimento das funcionalidades
• Q3 – São os testes que focam no negócio e encontrar defeitos. A responsabilidade é dos analistas de teste
• Q4 – São os testes que focam na arquitetura, estrutura do software. A responsabilidade é dos analistas de teste

58. Automatize o mais cedo possível, logo após o teste manual

59. Código de teste é tão importante quanto código de produção
Testes bem escritos e em grupos pequenos no mesmo contexto
Toda a equipe deve escrever a suíte de testes

60. Consistente e Confiável
A sua suíte de testes deve conquistar a confiança da sua equipe, do seu gerente e do cliente

61. Independente
Um teste não pode influenciar o resultado de outro e precisa ter feedback rápido

62. Duráveis
Mantém seu valor durante toda a vida do produto

63. Documentação
Testes servem como documentação
(são a melhor documentação que você vai ter)
Documentação viva, especificação executável.
Testes devem informar a intenção de um desenvolvedor

65. Foque a cobertura nas funcionalidades que mudam com maior frequência  maior uso
Faça testes para os erros encontrados em produção – você automaticamente estará
testando o mais crítico  maior uso, maior risco
Princípio de Pareto: princípio 80/20, no qual afirma que 80% dos resultados
estão relacionados a 20% dos nossos esforços.

66. Faça integração contínua
Não se preocupe com a performance
de execução de um teste, mas sim,
com o paralelismo e concorrência.
Não deixe o teste para o final
Não rode a suíte somente antes de gerar a versão.

67. Pessoas

68. Slide: 68
• Tem um forte auto-marketing;
• Sabe automotivar-se;
• Entende e defende o usuário/cliente;
• Seleciona talentos na equipe que farão a diferença na hora
da entrega do produto de software com qualidade;
• Estuda o processo negocial, aplica o conhecimento técnico
e acredita no seu taco ( pró-atividade)
• Conhece desenvolvimento de sistemas -> sabe programar
Um bom profissional de testes

69. 69
Slide: 69
• O programa de certificação do ISTQB é um dos mais aceitos internacionalmente.
• Caminho de certificação
Certificação Profissional

70. Resultados Alcançados

71. 22,20%
16,46%
5,48%
4,67%
3,54% 3,50% 3,91% 3,74% 3,37%
2007 2008 2009 2010 2011 2012 2013 2014 2015
Custo do erro em relação ao Faturamento
Erro Faturamento Total

72. 0
100
200
300
400
500
600
700
800
Mês
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
1
3
5
7
9
11
ano 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
%CUSTODAT.I.
Erros em produção x Defeitos nos testesSem
Processo
Processo em
implantação
Processo
Estabilizado
Usando regras
de negócio

73. Indicadores - Média Mensal
Versões Homologadas 190 Média de ciclos de teste por versão 3
Casos de Teste Atualizados 890 Casos de Teste executados por Ciclo 2638
Casos de Testes Executado 9092 % Eficácia na Detecção de Defeitos 90,34
Novos Casos de Teste
Gravados
1142
Média de de defeitos do tipo erro
2014
246
Defeitos por casos de teste
executado
15
Média de de defeitos do tipo erro
2015
308
Defeitos por ciclo de teste 2
Custo evitado com erros encontrados
no teste
R$ 600.500,00

75. R$-
R$1.000.000,00
R$2.000.000,00
R$3.000.000,00
R$4.000.000,00
R$5.000.000,00
R$6.000.000,00
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
Economia gerada com testes

76. • Aumento do lucro líquido das unidades de
negócio
• Melhoria da imagem do produto junto aos
clientes.
• Maior estabilidade dos sistemas no ambiente de
produção.

77. Evolução e Tendências em Qualidade
de Software

78. Análises do código fonte
para gerar dados, que
serão usados em
simulações estatísticas, a
fim de prever onde
haverá mais defeitos no
software
Uso de algoritmos e
heurísticas , bem como
recursos de Inteligência
Artificial para prevenção
de defeitos
Simulações dinâmicas de
processos de melhoria
de qualidade
Predição
Envolvimento do
cliente o mais
cedo possível
Testar requisitos
Especificação de
testes executável
Desenvolvimento
em pares
Integração
contínua
Testar o mais cedo
possível
Prevenção
Testar produto
construído
Testar no final do
projeto
Detecção

80. Referências bibliográficas

81. • CASPER, Jones. Measuring Defect Potentials and Defect Removal Efficiency. QAI JOURNAL, October 2008, volume 22, number 4 acessado em 14/03/2014.
• FEHLMANN, Thomas. Six sigma for software. In:Proceedings of the 1st SMEF Conference, Rome. 2004.
• CRISTALLI, Ricardo. Fábrica de Teste: Uso das Melhores Práticas. Insituto de Teste de Software. Disponível em: http://www.iteste.com.br/. Último acesso emagosto de 2007.
• DUSTIN, Elfriede, RASHKA, Jeff, PAUL, John. Automated Software Testing: Introduction, Management, and Performance. Addison-Wesley Professional; Bk&CD Rom edition,
1999.
• George Wilson (2009) The reality of software testing in an Agile Environment Testing Experience - The Magazine for Professional Testers 03/2009 (pág. 94 a 96)
• Myers, Glenford et al; The Art of Software Testing; John Wiley & Sons, New York,NY; ISBN 0471469122; 2004.
• Craig Larman, Victor R. Basili (2003) Iterative and Incremental Development: A Brief History – IEEE Computer (pág. 47 a 56)
• Cem Kaner (2006) Inefficiency and Ineffectiveness of Software Testing: A Key Problem in Software Engineering Software Engineering at the Florida Institute of Technology
• BARROS, Hugo. Retorno de Investimento em Testes de Software. In: Seminário Regional de Teste de Software . ALATS, 1., 2008, Porto Alegre.
• BASTOS, Anderson et al. Base de conhecimento em teste de software. Niterói: Traço &Photo, 2006. 300 p.
• CAETANO, Cristiano. Automação e Gerenciamento de Testes . Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas, 1º Edição, 2007a. 184p.
• CAETANO, Cristiano. Gestão de Defeitos . Ferramentas Open Source e melhores práticas na gestão de defeitos. Engenharia de Software, Ano 1, 1º Edição, p.60 . 67,
2007b.Disponível em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=8028. Acesso em: 18 jun. 2008.
• Associação Latino-Americana de Testes de Software - ALATS (http://www.alats.org.br )
• Livro: Base de Conhecimento em Testes de Software
• Brazilian Testing Qualifications Board - ISTQB/BSTQB (http://www.bstqb.org.br ) Livros: Syllabi e Glossário de Termos
• Quality Assurance Institute – QAI (http://www.qaibrasil.com.br/ Livro: CBOK
• Tmap Next http://www.tmap.net/en/tmap-next
• IEE Std 829-1998 e 829-2008 IEE Standart for Software Teste Documentation.
• BS 7928-2 Standard for software Component testing
• Britsh Computer Society Specialist Interest Grup in Software Testing (BCS SIGIST)
• TDC 2013 – Palestra sobre suíte de testes funcionais  http://www.thedevelopersconference.com.br/tdc/2013/
• Agile Testing: Lisa Crispin & Janet Gregory  http://agiletester.ca/

82. • http://www.fabricadetestes.com.br
• http://www.qualister.com.br/blog
• http://www.testadores.com
• http://eliasnogueira.com
• http://www.linhadecodigo.com.br/artigo/1083/os-7-habitos-dos-testadores-altamente-eficazes.aspx#OutrosArtigosAutor
• http://pts.datasus.gov.br/PTS/default.php
• http://kuldeepse.wordpress.com/2007/05/29/metrics-used-in-testing
• Lista de discussão no yahoo: DFTESTE
• Information Technology Metrics and Productivity Institute (ITMPI): www.ITMPI.org
• International Software Benchmarking Standards Group (ISBSG): www.ISBSG.org
• International Function Point Users Group (IFPUG): ww.IFPUG.org
• Software Engineering Institute (SEI): www.SEI.org
• Software Productivity Research (SPR): www.SPR.com
• Six Sigma: http://www.mikeljharry.com/milestones.php
• Six Sigma https://www.isixsigma.com/
• Sonar: http://www.sonarqube.org/

83. rodrigoalmeidadeoliveira@gmail.com

84. Obrigado!