qualidade - pensando fora da caixa
DESCRIPTION
Apresentação feita no Agile BR 2012, São PauloTRANSCRIPT
Qualidade:Pensando fora da caixa
@jorgedizwww.maps.com.br
Agenda
Contexto, mecânica 3 eixos arbitrários:
− gestão, − fatores humanos− engenharia
Provocações Reflexões Conclusões → dever de casa
Esclarecimentos
Uso de boa fé de imagens de outros Opiniões são minhas, não necessariamente
as das pessoas com quem trabalhei História não é necessariamente factual Posso estar errado, e vc tb Não sou politicamente correto o tempo todo
Personagens
Provocações
Saindo da caixa
O que anda acontecendo ?
Software como serviço
Segurança física
Privacidade ?
Redes sociais
Tempos
Ubiquidade
Complexidade
Procurar defeitos
Minimizar risco
Sexagem de código
Valores ágeis
Fluidez na comunicação Transparência, Foco em entrega de valor, Sustentabilidade do esforço, Compreensão dos fatores humanos Reavaliação constante:
Seu gestor promove qualidade ?
Escritório de projetos
Modelo de Fábrica
Recursos Humanos
Linha de montagem
Cascata
Regra 10x de Myers
Modelo V'
Modelo V
31
Wilfredo Pareto: regra 20/80
Cobertor sempre é curto
Recursos escasos
Tempo Atenção Capacidade de aprendizagem Remuneração das pessoas Licenças de Software Hardware
Just In Time
Quanto do software é usado Standish Group, 2002
Estimativas
Expectativas
Dinâmica de sistemas
Qualidade vs Produtividade
Erro'
Defeito'
Falha'
Fluxo ponta-a-ponta
Poka-yo
ke,
tipagem fo
rte
Testes
Instrumentaçã
o,
Pilha de exe
cuçã
o
Exceçõ
es
Log / audito
ria
Predica
dos fluentes
Gestão de
incidênc
ias,
Gestão de
config
uraçã
o
Regress
ão
Integração contínua / agile operations
autotest
erro defeito falha diagnóstico correção
Lei de Murphy
Precisamos de heróis
Precisamos de heróis
Controle de qualidade
Garantia de Qualidade
Promoção de Qualidade
“Preciso de um template”
Bebendo na fonte do XP Pareamento Automação de testes de aceitação Automação de testes do programador Testes como especificação Retrospectivas Integração Contínua Metáforas Refatoramento Propriedade coletiva do código
Dev+Ops
Gestão de configuração Provisionamento declarativo Deployment contínuo Monitoramento / alarmes
Fazer certo? da primeira vez?
caixa preta X caixa branca
A verdadeira caixa preta
A verdadeira caixa branca
Toda ocorrência será registrada
<< carimbo, funcionário de cartório>>
Só acredito vendo
Ambiente de homologação
“Isso é técnico”
Todo bug será corrigido
Métricas definem comportamento
Depois do periodo de garantia, não me procurem
Context-driven testing
Documentação
69
Q2: GUI, regras de negócio
Q3: Exploratório, usabilidade, aceitação funcional
Q1: Unitários, componentes
Q4:Desempenho,segurança
Tecnologia
Negócio
Pro
cesso
Pro
duto
Quadrantes de Marick
Teste de Interface Usuário
71
Teste de Unidade (XUnit)
72
Teste de Serviços / Negócio
73
Pirâmide de Cohn
74
Pirâmide Invertida (Naresh Jain)
75
Pirâmide de testes: frágil
Interface usuário
Mundo Real Padrão de Mercado
Pirâmide de testes: frágil
Interface usuário
unidades
Mundo Real “somos ágeis”
Mundo Real
78
Abrindo caminho através de um campo minado
Limpando um campo minado
80
Teste Exploratório
81
O que já sabemos
Quanto maior a distância entre o erro e a correção, muito maior o custo de corrigir e o risco de não corrigir
Uso ingênuo de métricas geralmente tem efeito oposto ao esperado
Registrar o que não é necessário atrapalha a comunicação.
Um sistema só começa a gerar valor depois de entrar em produção.
O que já sabemos
Registro não garante comunicação Inspeções / revisões são úteis Testes através da interface usuário são
caros e frágeis Ciclos precisam ser de poucas semanas no
máximo Estimativas furam Intermediários geram ruído
Então por que ...?
… não desapegamos do modelo em cascata / V ?
… investimos tanto esforço em teste automatizado através da interface de usuário ?
… documentamos com o principal objetivo de tirar o nosso da reta ?
… definimos padrões de codificação onde código bom = código comentado ?
Nem ele explica
?
!
?
??
! !!