escolas de testes de software
TRANSCRIPT
| 2
Agenda
Motivação do estudo
Breve descrição dos autores
Escolas de Testes
Quadro comparativo entre as Escolas
Bibliografia
| 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”
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”.
Devemos usar IEEE 829?
Padrão para Documentação de Testes
PRESSMAN: SIM!
Lisa Crispin: NÃO!
James Bach: SIM e NÃO!
| 7
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
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
| 11
Definindo o termo “escola”
Definido por
Afinidade Intelectual
Integração Social
Objetivos em Comum
Composto por
Hierarquia de Valores
Técnicas
representativas
Instituições
Organizadoras
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?
| 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!
| 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
| 19
Escola Convencional
Mais utilizado em
Enterprise IT
Desenvolvimento para Governo
Instituições
IEEE Standards Boards
Instituições certificadoras de Teste
○ ISTQB, ALATS, etc...
| 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?
| 21
Técnica de Exemplo
Matriz de Rastreabilidade
Ter certeza que todos os requistos foram
testados
| 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.
| 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?
| 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!
| 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)
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?
| 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.
| 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
| 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
| 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?
| 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
| 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
Escolas de Testes
Quality School
Ênfase no processo,
monitoramento dos
desenvolvedores, agindo
como o gatekeeper;
Context-Driven School
Ênfase nas pessoas,
procurando os bugs mais
importantes para os
stakeholders;
Agile School
Usa os testes para provar
que o desenvolvimento
está completo. Ênfase nos
testes automatizados.
Analytic School
Encara os testes como uma
atividade técnica e
rigorosa. Possui muitos
proponentes na academia;
Standard School
Encara os testes como uma
maneira de medir o
progresso com ênfase nos
custos e em padrões
repetíveis;
| 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
| 40
Testes sem Especificação
A FAVOR
Context-Driven School
Faça o que for possível
para ser útil
Fazem questionamentos
e entrevistas se
necessário
Descobrem
especificações
Agile School
Conversa é mais
importante do que
documentação
CONTRA
Analytical School
Impossível
Standard School
Necessário algum tipo de
especificação
Quality School
Porque ela força que os
desenvolvedores sigam o
processo
| 41
Certificação de Testes
A FAVOR
Standard School
Torna os testadores mais
fáceis para contratar,
treinar e gerenciar
Quality School
Aumenta o Status
CONTRA
Context-Driven and
Agile School
Certificações Existentes
são baseados em
doutrinas ao invés de
habilidades
Analytic School
Preferem [pós-]
graduações às
certificações
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
| 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.
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
Obrigado...
| 46