Agenda

 Motivação do estudo
 Breve descrição dos autores
 Escolas de Testes
 Quadro comparativo entre as Escolas
 Bibliografia




                                        | 2
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
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
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
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
Escola Analítica
     Muito utilizado em:
       Indústrias de Telecom
       Sistemas Críticos (Aviões, Navios)
     Instituições que defendem:
       Academias




                                             | 14
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
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
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
Escola Convencional
   Mais utilizado em
     Enterprise IT
     Desenvolvimento para Governo
   Instituições
     IEEE Standards Boards
     Instituições certificadoras de Teste
      ○ ISTQB, ALATS, etc...




                                             | 19
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
Técnica de Exemplo
   Matriz de Rastreabilidade
     Ter certeza que todos os requistos foram
     testados




                                                 | 21
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

Escolas de testes de software

  • 2.
    Agenda  Motivação doestudo  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 IEEE829?  Padrão para Documentação de Testes  PRESSMAN: SIM!  Lisa Crispin: NÃO!  James Bach: SIM e NÃO! | 7
  • 8.
    Qual o papeldos 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 devemosusar 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 dividirTestes 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  Qualidadede 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 (Dirigidoao 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ãoexiste 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. | 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.