O documento discute três eixos para pensar sobre qualidade de software: gestão, fatores humanos e engenharia. Também levanta provocações sobre sair da caixa de pensamento tradicional e reflexões sobre valores ágeis e desafios na garantia da qualidade.

1. Qualidade:
Pensando fora da caixa
@jorgediz
www.maps.com.br

2. Agenda

Contexto, mecânica

3 eixos arbitrários:
− gestão,
− fatores humanos
− engenharia

Provocações

Reflexões

Conclusões → dever de casa

3. 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

4. Personagens

5. Provocações

6. Saindo da caixa

7. O que anda acontecendo ?

8. Software como serviço

9. Segurança física

10. Privacidade ?

11. Redes sociais

12. Tempos

13. Ubiquidade

14. Complexidade

15. Procurar defeitos

16. Minimizar risco

17. Sexagem de código

18. 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:

19. Seu gestor promove qualidade ?

20. Escritório de projetos

21. Modelo de Fábrica

22. Recursos Humanos

23. Linha de montagem

24. Cascata

25. Regra 10x de Myers

26. '
Modelo V

27. Modelo V

28. Wilfredo Pareto: regra 20/80
31

29. Cobertor sempre é curto

30. Recursos escasos

Tempo

Atenção

Capacidade de aprendizagem

Remuneração das pessoas

Licenças de Software

Hardware

31. Just In Time

32. Quanto do software é usado
Standish Group, 2002

33. Estimativas

34. Expectativas

35. Dinâmica de sistemas

36. Qualidade vs Produtividade

37. '
Erro

38. '
Defeito

39. '
Falha

40. Fluxo ponta-a-ponta
erro defeito falha diagnóstico correção
ão, ão
k e , te ta ç cu ç de s ,
y o f or en x e o
tã ncia e ão
a- m s m e s s s
ok ge t te tr u de s ia te Ges dê o d ção gr
e
P a es es ns ha õe itor luen ci tã ra
tip to
t T I l
i eç ud s f in es gu Re
au P c a o
x / ad G n fi
E g c
o di co
L e
Pr
Integração contínua / agile operations

41. Lei de Murphy

42. Precisamos de heróis

43. Precisamos de heróis

44. Controle de qualidade

45. Garantia de Qualidade

46. Promoção de Qualidade

47. “Preciso de um template”

48. 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

49. Dev+Ops

Gestão de configuração

Provisionamento declarativo

Deployment contínuo

Monitoramento / alarmes

50. Fazer certo? da primeira vez?

51. caixa preta X caixa branca

52. A verdadeira caixa preta

53. A verdadeira caixa branca

54. Toda ocorrência será registrada

<< carimbo, funcionário de cartório>>


55. Só acredito vendo

56. Ambiente de homologação

57. “Isso é técnico”

58. Todo bug será corrigido

59. Métricas definem comportamento

60. Depois do periodo de garantia, não
me procurem

61. Context-driven testing

62. Documentação
69

63. Quadrantes de Marick
Negócio
Q3: Exploratório,
Q2: GUI, regras usabilidade,
de negócio aceitação
Produto
Processo
funcional
Q1: Unitários, Q4:Desempenho,
componentes segurança
Tecnologia

64. Teste de Interface Usuário
71

65. Teste de Unidade (XUnit)
72

66. Teste de Serviços / Negócio
73

67. Pirâmide de Cohn
74

68. Pirâmide Invertida (Naresh Jain)
75

69. Pirâmide de testes: frágil
Mundo Real Padrão de Mercado
á rio
Inter face usu

70. Pirâmide de testes: frágil
Mundo Real “somos ágeis”
Interface usuário
unidades

71. Mundo Real
78

72. Abrindo caminho através de um
campo minado

73. Limpando um campo minado
80

74. Teste Exploratório
81

75. 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.

76. 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

77. 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 ?

78. Nem ele explica

79. ?
! ! ?
? !
?