Qualidade - pensando fora da caixa

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

?

!

?

??

! !!