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
4.
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”.
6.
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
12.
13.
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
18.
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
23.
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
27.
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
33.
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
37.
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
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