2. Agend
a
 Motivação do estudo
 Breve descrição dos autores
 Escolas de Testes
 Quadro comparativo entre as Escolas
 Bibliografia
| 2

3. Detalhes importantes!
 Esta apresentação é baseada num artigo
de Bret Pettichord
 Famoso Consultor de testes
 Líder do desenvolvimento da Watir
 Co-autor de um dos principais livros de testes:
“Lessons Learned in Software Testing”
| 3

5. Roger S. Pressman é em engenheiro de software, escritor e consultor,
norte-americano, presidente da R.S. Pressman & Associates.
Livros:
1977. Numerical control and computer-aided manufacturing
1988. Making software engineering happen: a guide for instituting the
technology.
1988. Software engineering: a beginner's guide.
1991. Software shock: the danger & the opportunity
2005. Software engineering: a practitioner's approach
2009. Web engineering: a practitioner's approach
Lisa Crispin renomada autora na comunidade de Teste de Software,
escritora do livro “Agile Testing” e blogueira no site http://lisacrispin.com/.
James Marcos Bach é testador de software, escritor, consultor e membro
do “Board of Directors of the Association for Software Testing”. Também é
co-escritor do livro “Lessons Learned in Software Testing”.

7. Devemos usar IEEE
829?
 Padrão para Documentação de Testes
 PRESSMAN: SIM!
 Lisa Crispin: NÃO!
 James Bach: SIM e NÃO!
| 7

8. Qual o papel dos Testes
Exploratórios?
 Testes onde o design e a execução ocorrem
de forma simultânea.
 PRESSMAN: Complementa os testes com
roteiros!
 Lisa Crispin: Complementa os testes unitários
automatizados (TDD)!
 James Bach: A mais eficiente técnica de testes!
| 8

9. O que devemos usar para projetar os
testes?
 PRESSMAN: Apenas os requisitos
documentados!
 Lisa Crispin: As histórias contadas pelo
usuário!
 James Bach: Qualquer informação sobre o
contexto da aplicação!
| 9

10. Por que dividir Testes em
Escolas?
 Especialistas de testes não concordam
entre si
 Não é por causa de suas personalidades ou
experiências
 Melhorar a base para o estudo
 Diferenças de valores explicam a preferência
por certas políticas de testes
| 10

11. Definindo o termo “escola”
 Definido por  Composto por
 Afinidade Intelectual  Hierarquia de Valores
 Integração Social  Técnicas
 Objetivos em Comum representativas
 Instituições
Organizadoras

14. Escola Analítica
 Muito utilizado em:
 Indústrias de Telecom
 Sistemas Críticos (Aviões, Navios)
 Instituições que defendem:
 Academias
| 14

15. Principais Crenças
 Software é um artefato lógico
 Teste é uma ciência baseada em
Computação e Matemática
 Objetivo, rigoroso e compreensivo
 Técnicas de testes devem ser objetivas
 “apenas uma resposta certa”
 Teste é uma atividade técnica
 Principal Pergunta:
 Quais técnicas deveremos utilizar?
| 15

16. Escola Analítica
 Implicações
 Requer especificação precisa e detalhada
 Testadores verificam se o software está
conforme a sua especificação
 Qualquer outra coisa não é teste!
| 16

17. Técnica Exemplo
 Testes Caixa Branca
 Ou “Structural testing”
 Diversas métricas de cobertura de código são
utilizadas
 Provê uma medida objetiva dos testes
| 17

19. Escola Convencional
 Mais utilizado em
 Enterprise IT
 Desenvolvimento para Governo
 Instituições
 IEEE Standards Boards
 Instituições certificadoras de Teste
○ ISTQB, ALATS, etc...
| 19

20. Principais Crenças
 Testes devem ser gerenciados
 Previsível, repetível, planejado
 Testes devem ser lucrativos
 Trabalhadores com pouco conhecimento precisam de um
direcionamento
 Testes valida o produto
 Testes medem o progresso do desenvolvimento
 Principal Questão:
 Como podemos medir se estamos progredindo? Quando teremos
terminado o desenvolvimento?
| 20

21. Técnica de Exemplo
 Matriz de Rastreabilidade
 Ter certeza que todos os requistos foram
testados
| 21

22. Escola Convencional
 Implicações
 Requer fronteiras claras entre testes e outras
atividades (start/stop criteria)
 Incentiva padrões, melhores práticas e
certificação
 Utilização de variações do V-model
○ Atividades de testes ocorrem em paralelo.
| 22

24. Principais Crenças
 Qualidade de Software requer disciplina
 Testes determina se o processo de
desenvolvimento está sendo seguido
 Cada bug é um problema do PROCESSO!
 Testadores devem proteger os usuários
dos software ruins
 Principal Pergunta:
 Estamos seguindo um bom processo?
| 24

25. Técnica de Exemplo
 The Gatekeeper (O Porteiro)
 O software não está pronto até que o SQA (Controle
de Qualidade de Software) diga que está pronto!
| 25

26. Escola da Qualidade
 Implicações
 Preferem Garantia da Qualidade aos Testes
 Testes é o ponto de partida para a Melhoria do Processo
 Pode alienar os desenvolvedores
 Mais utilizado em
 Empresas burocráticas
 Organizações sob leis e obrigatoriedades
 Instituições
 American Society for Quality (ASQ)
 Software Engineering Institute (CMM)
 International Standards Organization (ISO)
| 26

28. Context Driven (Dirigido ao Contexto)
 Mais utilizado em
 Software Comerciais
 Market-driven Software (Software dirigido ao
Mercado)
 Instituições
 LAWST Workshops
○ Los Altos Workshop on Software Testing
○ StarEast/StarWest
| 28

29. Principais
Crenças
 Software é criado por Pessoas. Pessoas definem o
contexto.
 Possui 07 princípios básicos.
 Teste deve encontrar bugs.
 Teste provê informações para o projeto
 Teste é uma atividade mental que requer habilidade
 Teste é multidisciplinar
 Principal Pergunta:
 Que teste é o mais valioso agora?
| 29

30. 07 Princípios Básicos
 1. O valor de qualquer prática depende de seu contexto.
 2. Existem boas práticas em determinado contexto, mas não
existem melhores práticas.
 3. As pessoas, trabalhando em conjunto, são a parte mais
importante do contexto de qualquer projeto.
 4. Projetos se desdobram ao longo do tempo de maneiras
normalmente imprevisíveis.
 5. O produto é uma solução. Se o problema não foi resolvido,
então o produto não funciona.
 6. O bom teste de software é um processo intelectual
desafiador.
 7. Somente por meio de julgamento e habilidade, realizados
cooperativamente ao longo de todo projeto, somos capazes de
fazer as coisas certas nos momentos certos para testar nossos
produtos de forma efetiva.
| 30

31. Técnica de Exemplo
 Exploratory Testing
 Execução e Design feitos de forma concorrente
 Rapid learning
 Execução baseada em Missão e Estratégias
 Difícil Gerenciamento
 Ótimo resultados práticos
○ Eficiência
○ Eficácia
| 31

32. Escola “Context Driven”
 Implicações
 Preparado para mudanças. Adapta o planejamento
dos testes baseado nos resultados.
 Efetividade das estratégias são verificadas
colocando-as em prática
 Pesquisas de testes requerem estudos empíricos e
psicológicos
 Foco na habilidade ao invés da prática/método
| 32

34. Principais Crenças
 Software é desenvolvido a partir de uma
conversa
 Testes mostram que uma história está
completa
 Testes devem ser automatizados
 Principal Pergunta:
 A história está pronta?
| 34

35. Técnica de Exemplo
 Testes Unitários
 Usados para Test-Driven Development (TDD)
 Testes unitários são projetados antes do
desenvolvimento
 Suportado por ferramentas
| 35

36. Escola Ágil
 Implicações
 Desenvolvedores devem fornecer frameworks
para automação dos testes
 Demora para perceber o valor dos testes
exploratórios
 Mais utilizado em
 IT Consulting
 Desenvolvimento por equipe menores
 Instituições
 Agile Workshops
| 36

38. Escolas de Testes
 Analytic School  Quality School
 Encara os testes como uma  Ênfase no processo,
atividade técnica e monitoramento dos
rigorosa. Possui muitos desenvolvedores, agindo
proponentes na academia; como o gatekeeper;
 Standard School  Context-Driven School
 Encara os testes como uma  Ênfase nas pessoas,
maneira de medir o procurando os bugs mais
progresso com ênfase nos importantes para os
custos e em padrões stakeholders;
repetíveis;  Agile School
 Usa os testes para provar
que o desenvolvimento
está completo. Ênfase nos
testes automatizados.
| 38

39. O que é Teste?
 Analytic School:
 Um branch da ciência da computação e matemática
 Standard School:
 Um processo gerenciado
 Quality School:
 Um branch da garantia da qualidade
 Context-Driven School:
 Um branch do desenvolvimento
 Agile School:
 Parte do papel do cliente
| 39

40. Testes sem Especificação
 A FAVOR  CONTRA
 Context-Driven School  Analytical School
 Faça o que for possível  Impossível
para ser útil  Standard School
 Fazem questionamentos
 Necessário algum tipo de
e entrevistas se
especificação
necessário
 Descobrem  Quality School
especificações  Porque ela força que os
desenvolvedores sigam o
 Agile School processo
 Conversa é mais
importante do que
documentação
| 40

41. Certificação de Testes
 A FAVOR  CONTRA
 Standard School  Context-Driven and
 Torna os testadores mais Agile School
fáceis para contratar,  Certificações Existentes
treinar e gerenciar são baseados em
 Quality School doutrinas ao invés de
habilidades
 Aumenta o Status
 Analytic School
 Preferem [pós-]
graduações às
certificações
| 41

42. Conclusões
 Não existe escola MELHOR do que outra!
 Cada escola tem o seu contexto
 Analise o seu, e escolha as práticas de cada
uma para montar a sua própria solução!
| 42

43. | 43

44. Referências
 Context Driven School
 http://www.context-driven-testing.com/
 http://www.testinglessons.com/
 Lessons Learned in Software Testing
Kaner, Bach, and Pettichord
 Agile School
 http://www.testing.com/agile/
 http://www.qualitytree.com/
 Testing Extreme Programming
Lisa Crispin and Tip House.
| 44

45. Referências
 Standard School
 http://www.istqb.org
 http://en.wikipedia.org/wiki/IEEE_829
 Foundations of Software Testing: ISTQB Certification
Graham, Veenendaal, Evans and Rex Black
 Analitic School
 http://en.wikipedia.org/wiki/Model-based_testing
 Practical Model-Based Testing: A Tools Approach
Mark Utting , Bruno Legeard
 Quality School
 http://en.wikipedia.org/wiki/Quality_assurance
 Four Schools of Testing
 http://www.io.com/~wazmo/papers/four_schools.pdf
| 45

46. Obrigado...
| 46