| 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