O documento apresenta o currículo e experiência profissional de um especialista em gestão de projetos, desenvolvimento e qualidade de software. Ele possui mais de 25 anos de experiência e diversas certificações, incluindo PMP e Brazilian Tester. O texto também discute conceitos como Agile, Lean, Toyota Kata, e Seis Sigma aplicados ao desenvolvimento e teste de software.

2. Quem sou eu?
Alguém que quer ajudar!
Casado desde 2002, pai de 4 filhos!
Trabalho com Desenvolvimento e Qualidade de Software desde 1993
Técnico em processamento de dados – 1994
Bacharel em Ciências da Computação – 2005
Especialista em Gestão de Negócios – 2007
Certified Brazilian Tester pela ALATS desde 2008
Project Management Professional (PMP) pelo PMI desde 2009
MBA em Gestão de Projetos – 2010
Mestre em Engenharia e Gestão de Sistemas e Processos – 2017

3. Pesquisa
Quem já ouviu sobre Agile?
Quem realmente está praticando Agile?
Quem ouviu sobre Lean?
Quem já ouviu falar da Toyota?

7. 3M da Toyota
https://ideiasesquecidas.com/2015/05/30/muri-mura-muda/

8. 3M da Toyota
Muda (ムダ), Mura (ムラ) e Muri (ムリ)
O modelo 3M do sistema Toyota de Produção
MUDA  Desperdícios
MURI  Sobrecarga, irracionalidade, muito difícil, excessos, falta de
moderação
MURA  Inconsistência, irregularidade dos processos  Sem
previsibilidade

9. Lean

10. Lean
Principios Lean
Eliminar desperdício
Concentre-se em aprender
Construa com qualidade (processo + produto)
Adiar compromisso
Entregue rápido
Respeite as pessoas
Otimize o todo

11. Lean
Eliminar desperdício (MUDAムダ)
Sobreprodução / Superprodução
Esperas
Transporte
Processamento inadequado
Inventário desnecessário
Movimento desnecessário / excesso
Defeitos

12. Lean – Sobreprodução / Superprodução

13. Simplificando, a superprodução é fabricar um item antes de ser realmente
necessário.
No teste, isso pode ser o que queremos: antes do início da execução real,
os casos de teste, dados de teste e ambiente de teste são preparados.
Por outro lado, temos a certeza de que fazemos uma distinção entre
esforço e profundidade de testes com base nos riscos?
Não temos demasiada sobreposição entre os níveis de teste?
E quanto ao potencial excesso de planos de teste?
Todos estes pontos podem ser vistos como superprodução no teste.
Lean – Sobreprodução / Superprodução

14. Fazer casos de testes a mais
Planos de testes intermináveis
Testes que não serão executados nunca
Testes inadequados
Metodologias/Técnicas inadequadas ao estágio do teste  Usar BDD
para testes de interface, fazer teste unitário para métodos GET/SET, etc.
Lean – Sobreprodução / Superprodução

15. Lean - Esperas

16. Sempre que os bens não estão sendo movidos ou sendo processados,
ocorre o desperdício de espera.
Os processos de vinculação em conjunto, de modo que um alimenta
diretamente para o próximo, podem reduzir drasticamente a espera.
Desperdícios muito comuns e bem conhecidos: aguardando build,
aguardando projetos, aguardando o ambiente certo, aguardando
suporte, etc.
Lean - Esperas

17. Lean - Transporte

18. Transportar um produto entre processos é um custo que não adiciona valor
ao produto.
Para testes, podemos ver a forma como as informações chegam ao testador
ou a quantidade de reuniões que existem com a equipe de teste.
Reuniões tem uma tendência muito grande de não agregar nada ao processo
de testes.
Num formato ágil de trabalho, ter a equipe unida e geograficamente próxima
ajuda muito no processo de testes.
Lean - Transporte

19. Lean - Processamento inadequado

20. Muitas vezes chamado de “Canhão para matar mosquitos.”, muitas
organizações usam equipamentos caros de alta precisão, onde ferramentas
mais simples seriam suficientes.
Todos nós podemos ter exemplos de ferramentas de automação de
teste ou uma administração de defeito cara da qual uma grande parte da
funcionalidade não é usada.
E podemos até pensar em ter muitos casos de teste preparados para
uma funcionalidade pequena e simples quando não consideramos os riscos
do produto e sua prioridade.
Lean - Processamento inadequado

21. Lean - Inventário desnecessário

22. O trabalho em andamento (WIP) é um resultado direto da
superprodução e da espera.
Em vez de ter bons casos de teste que terminam em prateleiras, o bom
controle de versão pode tornar possível a reutilização de casos de teste.
Talvez seja possível analisar as equipes de teste e torná-las mais flexíveis
para trabalhar em vários projetos.
Isso ajuda a ter o número certo de pessoas no momento certo em seus
projetos.
Outro exemplo: Criar mais casos de teste do que pode ser executado
no tempo disponível.
Os casos de teste que não podem ser executados não agregam valor
ao cliente.
Lean - Inventário desnecessário

23. Lean - Movimento desnecessário / excesso

24. Este desperdício está relacionado à ergonomia.
Como o teste não é tão físico, pode parecer difícil relacionar esse
desperdício com o teste.
Por outro lado, podemos traduzir isso como a quantidade de esforço
gasto para se montar um ambiente de testes adequado para a versão a ser
testada.
Quanto mais manual for esta atividade e menos despadronizada, maior
vai ser o esforço de montagem de ambiente de testes.
Estamos certos sobre a versão/configuração a ser testada?
Lean - Movimento desnecessário / excesso

25. Lean - Defeitos
http://distresstest.com/

26. Tendo um impacto direto para a qualidade, os defeitos resultantes em retrabalho
ou sucata são um tremendo custo para as organizações.
Aqui pode ser feita uma distinção entre defeitos no processo de teste e defeitos no
produto sob teste.
Com o teste, ajudamos a organização a eliminar o desperdício de defeitos do
produto.
Todo defeito de produto que um time de teste encontra pode ser corrigido antes
de entrar em produção. O ideal é trabalhar para não ter defeitos. Encontrar defeitos é
desperdício.
Este é provavelmente o desperdício mais reconhecido relacionado ao teste.
O defeito no processo de teste em si é, naturalmente, também um desperdício que
temos de estar cientes.
Os planos de melhoria também devem incluir nossos próprios processos de teste.
Lean - Defeitos

27. Kanban

28. Entregar Software funcionando ao cliente o mais rápido possível
Encurtar/diminuir ciclo de feedback (lead time)
Eficácia precede a eficiência  Fazer a coisa certa (Eficácia) primeiro
Aumentar ganho ($$$) do cliente a cada entrega de software
Lean – Kanban – Objetivo Maior

29. Lean - Kanban – Diretrizes
Visualizar o fluxo de trabalho
Limitar o WIP
Medir e Gerenciar o fluxo
Tornar as políticas explícitas
Implementar mecanismos de feedback
Melhorar colaborativamente utilizando modelos e método científico
(PDCA, SIX SIGMA)

30. Lean - Kanban – Cumulative Flow Diagram

32. Seis Sigma

33. 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);
Lean – Seis Sigma

34. Lean – Seis Sigma para Software
• 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

35. Jidoka

36. Lean – Jidoka
Os quarto passos Jidoka (ジドカ) são:
• Detecte a anomalia
• Pare.
• Conserte ou corriga imediatamente a condição
• Investigue a causa raiz e instale uma contramedida.
No mundo do Software
• Trabalhe com Integração Contínua/Entrega Contínua (CI/CD)
• Medir o tempo para corrigir builds e defeitos

37. Lean – Resumo
Otimize o todo
Elimine desperdício
Respeite as pessoas
Foco no aprendizado
Entregue rápido /
Limite o trabalho em
progresso / Trabalhe
em um sistema puxado
Construa com
qualidade durante todo
o processo
(BDD/TDD/automation/
DevOps / Jidoka)
LEAN
AGILE
KANBAN
XP
Adie compromissos

38. Estudo de Caso

39. Estudo de Caso - Contexto
• Processo Waterfall de desenvolvimento de software
• Projeto de redesenvolver um sistema cliente/server em arquitetura web
• Atrasos
• Conflitos
• Falhas de comunicação
• Construção de funcionalidades que nunca serão usadas
• Foco na eficiência
• Demora na entrega de software funcionando

40. Lean – Estudo de Caso – As Is
Especificação
Analista de
Negócio
Análise / Projeto
Analista de
Sistemas
Construção
Desenvolvedor
Gerar evidências
de teste
Desenvolvedor
Teste
Funcional
Manual
Tester
Especificação de
Teste Manual
Tester
Automação do
Teste Funcional
Tester
Automação
do Teste
exploratório /
smoke test
(Coded UI)
Tester
Validação
Analista de
Negócio
Silos

41. Lean – Estudo de Caso – As Is
Especificação
Analista de
Negócio
Análise / Projeto
Analista de
Sistemas
Construção
Desenvolvedor
Gerar evidências
de teste
Desenvolvedor
Teste
Funcional
Manual
Tester
Especificação de
Teste Manual
Tester
Automação do
Teste Funcional
Tester
Automação
do Teste
exploratório /
smoke test
(Coded UI)
Tester
Validação
Analista de
Negócio
Lead Time: 320 horas
Silos
Processo feito
via
Record/Replay
Especificação
não
aproveitável
/ Escalável

42. Lean – Estudo de Caso – To Be
Especificação
Analista de
Negócio
Construção
Desenvolvedor
Teste unitário do
Código
Desenvolvedor
Teste Funcional
Manual
Tester
Especificação de
Teste Manual (tdd)
Tester
Automação do Teste
Funcional
Tester
Automação do Teste
exploratório / smoke
test (Selenium)
Tester
Validação
Analista de
Negócio
Célula Unificada
Lead Time: 40 horas
Foi criado um
gerador de
testes
exploratórios /
Smoke test
Especificação
aproveitável
/ Escalável
usando excel
(tdd)
Passou a participar
do sprint planning

43. Estudo de Caso - Resultados
• Melhoria da qualidade percebida pelo cliente
• Diminuição do lead time em 87,50%
• Término de 2 fases do projeto antes do previsto
• Implantação de uma cultura de qualidade de desenvolvimento
(prevenção de defeitos)
• Diminuição dos custos de desenvolvimento em mais de 45%

44. Estudo de Caso - Resultados
• 44,82% menos tempo gasto com testes
• 45,94% de melhoria na qualidade do software entregue
• 50,16% de aumento na produtividade de desenvolvimento de software

45. Estudo de Caso – Aprendizados
• Pare de começar e comece a entregar.
• Foco no processo e não nas pessoas
• O sistema (processo) é que é ruim. Não são as pessoas.
• Não se conforme  Meça e melhore continuamente.

46. Referências

48. https://www.linkedin.com/in/raoliveira/
https://rodrigoalmeidadeoliveira.wordpress.com