Ctal Syllabus 2007br

Brazilian Software Testing Qualifications Board
Certificao em Teste Advanced Level Syllabus

Verso 2007br
Comisso Internacional para Qualificao de Teste de Software
Nota de copyright Este documento pode ser copiado integralmente ou em partes, desde que haja referncia fonte.
Certified Tester
Advanced Level Syllabus
Copyright ao International Software Testing Qualifications Board (denominado doravante de ISTQB). Grupo de trabalho do nvel avanado: Bernard Homs (presidente), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Klaus Olsen, Randy Rice, Jurgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal; 20062007.
Verso 2007br
International Software Testing Qualifications Board
Pgina 2 de 124
02 Fev 2010
Certified Tester
Histrico de Revises
Verso ISEB v1.1 ISTQB 1.2 E V2007 V2007br V2007br
Data Setembro 2001 Setembro 2003 Outubro 2007 Abril 2009 Fevereiro 2010
Observaes ISEB Practitioner Syllabus ISTQB Advanced Level Syllabus de EOQ SG Certified Tester Advanced Level Syllabus verso 2007 Traduo para o portugus do Brasil Reviso final da verso 2007br
Verso 2007br
Pgina 3 de 124
02 Fev 2010
Certified Tester
ndice
Histrico de Revises ............................................................................................................................ 3 ndice...................................................................................................................................................... 4 Agradecimentos ..................................................................................................................................... 8 0. Introduo a Este Syllabus ............................................................................................................ 9 0.1 O International Software Testing Qualifications Board ......................................................... 9 0.2 Expectativas........................................................................................................................ 11 0.2.1 Advanced Level Test Manager ....................................................................................... 11 0.2.2 Advanced Level Test Analyst ......................................................................................... 11 0.2.3 Advanced Level Technical Test Analyst ......................................................................... 11 0.3 Objetivos de Aprendizagem / Nveis de Conhecimento ...................................................... 12 0.4 Objetivos de Aprendizagem para Test Manager................................................................. 13 0.5 Objetivos de Aprendizagem para Test Analyst ................................................................... 16 0.6 Objetivos de Aprendizagem para Technical Test Analyst ................................................... 18 1. Aspectos Bsicos de Teste de Software ..................................................................................... 22 1.1 Introduo ........................................................................................................................... 22 1.2 O Teste no Ciclo de Vida de Software ................................................................................ 22 1.3 Sistemas Especficos .......................................................................................................... 24 1.3.1 Sistemas de Sistemas .................................................................................................... 24 1.3.2 Sistemas de Segurana Crtica ...................................................................................... 25 1.4 Mtricas & Medies ........................................................................................................... 26 1.5 tica .................................................................................................................................... 27 2. Processos de Teste ..................................................................................................................... 28 2.1 Introduo ........................................................................................................................... 28 2.2 Modelos de Processo de Teste .......................................................................................... 28 2.3 Planejamento & Controle de Teste ..................................................................................... 29 2.4 Modelagem & Anlise de Teste .......................................................................................... 29 2.4.1 Identificao de Condies de Teste .............................................................................. 30 2.4.2 Criao de Casos de Teste ............................................................................................ 30 2.5 Implementao e Execuo de Teste ................................................................................. 31 2.5.1 Implementao de Teste ................................................................................................ 31 2.5.2 Execuo de Teste ......................................................................................................... 32 2.6 Avaliao do Critrio de Sada e Relatrio ......................................................................... 33 2.7 Atividades de Encerramento de Teste ................................................................................ 34 3. Gerenciamento de Teste ............................................................................................................. 36 3.1 Introduo ........................................................................................................................... 36 3.2 Documentao de Gerenciamento de Teste ...................................................................... 36 3.2.1 Poltica de Teste ............................................................................................................. 36 3.2.2 Estratgia de Teste......................................................................................................... 37 3.2.3 Plano Mestre de Teste.................................................................................................... 38 3.2.4 Plano de Nvel de Teste ................................................................................................. 39 3.3 Modelos de Documentao do Plano de Teste .................................................................. 39 3.4 Estimativa de Teste ............................................................................................................ 39 3.5 Planejamento da Programao de Teste............................................................................ 41 3.6 Monitorao e Controle do Progresso do Teste ................................................................. 41 3.7 Valor de Negcio do Teste ................................................................................................. 42 3.8 Teste Distribudo, Outsourced & Insourced ........................................................................ 43 3.9 Teste Baseado em Risco .................................................................................................... 44 3.9.1 Introduo ao Teste Baseado em Risco ......................................................................... 44 3.9.2 Gerenciamento de Risco ................................................................................................ 45
Verso 2007br
Pgina 4 de 124
02 Fev 2010
Certified Tester
4.
5.
6.
7.
3.9.3 Gerenciamento de Risco no Ciclo de Vida ..................................................................... 48 3.10 Anlise de Modo e Efeito de Falha ..................................................................................... 49 3.10.1 reas de Aplicao .................................................................................................... 49 3.10.2 Fases de Implementao ........................................................................................... 50 3.10.3 Custos & Benefcios ................................................................................................... 50 3.11 Questes de Gerenciamento de Teste ............................................................................... 50 3.11.1 Questes de Gerenciamento para Teste Exploratrio ............................................... 50 3.11.2 Questes de Gerenciamento para Sistemas de Sistemas ......................................... 51 3.11.3 Questes de Gerenciamento para Sistemas de Segurana Crtica ........................... 51 3.11.4 Outras Questes de Gerenciamento de Teste ........................................................... 52 Tcnicas de Teste ....................................................................................................................... 55 4.1 Introduo ........................................................................................................................... 55 4.2 Baseado em Especificao ................................................................................................. 55 4.3 Baseado em Estrutura ........................................................................................................ 57 4.4 Baseado em Defeito e Experincia ..................................................................................... 59 4.4.1 Tcnicas Baseadas em Defeito ...................................................................................... 59 4.4.2 Tcnicas Baseadas em Experincia............................................................................... 59 4.5 Anlise Esttica .................................................................................................................. 61 4.5.1 Anlise Esttica do Cdigo ............................................................................................. 61 4.5.2 Anlise Esttica da Arquitetura....................................................................................... 62 4.6 Anlise Dinmica ................................................................................................................ 62 4.6.1 Viso Geral ..................................................................................................................... 62 4.6.2 Detectando Vazamentos de Memria ............................................................................ 63 4.6.3 Detectando Wild Pointers ............................................................................................... 63 4.6.4 Anlise de Desempenho................................................................................................. 64 Teste de Caractersticas de Software.......................................................................................... 65 5.1 Introduo ........................................................................................................................... 65 5.2 Atributos de Qualidade para Teste de Domnio .................................................................. 65 5.2.1 Teste de Acurcia ........................................................................................................... 66 5.2.2 Teste de Adequao....................................................................................................... 66 5.2.3 Teste de Interoperabilidade ............................................................................................ 66 5.2.4 Teste de Segurana Funcional ....................................................................................... 66 5.2.5 Teste de Usabilidade ...................................................................................................... 66 5.2.6 Teste de Acessibilidade .................................................................................................. 68 5.3 Atributos de Qualidade para o Teste Tcnico ..................................................................... 68 5.3.1 Teste Tcnico de Segurana .......................................................................................... 69 5.3.2 Teste de Confiabilidade .................................................................................................. 70 5.3.3 Teste de Eficincia ......................................................................................................... 72 5.3.4 Teste de Mantenabilidade .............................................................................................. 74 5.3.5 Teste de Portabilidade .................................................................................................... 74 Revises ...................................................................................................................................... 77 6.1 Introduo ........................................................................................................................... 77 6.2 Os Princpios das Revises ................................................................................................ 77 6.3 Tipos de Reviso ................................................................................................................ 78 6.3.1 Reviso Gerencial e Auditoria ........................................................................................ 78 6.3.2 Revises de Produtos de Trabalho Especficos ............................................................. 78 6.3.3 Execuo de uma Reviso Formal ................................................................................. 79 6.4 Introduo s Revises ...................................................................................................... 79 6.5 Fatores de Sucesso para Revises .................................................................................... 80 Gerenciamento de Incidente ....................................................................................................... 82 7.1 Introduo ........................................................................................................................... 82 7.2 Quando um Defeito Pode Ser Detectado?.......................................................................... 82 7.3 Ciclo de Vida do Defeito ..................................................................................................... 82
Verso 2007br
Pgina 5 de 124
02 Fev 2010
Certified Tester
7.3.1 Passo 1: Reconhecimento .............................................................................................. 83 7.3.2 Passo 2: Investigao..................................................................................................... 83 7.3.3 Passo 3: Ao ................................................................................................................ 83 7.3.4 Passo 4: Disposio ....................................................................................................... 83 7.4 Campos de Defeito ............................................................................................................. 83 7.5 Mtricas & Gerenciamento de Incidente ............................................................................. 84 7.6 Comunicao de Incidentes ................................................................................................ 84 8. Normas & Processo de Melhoria de Teste .................................................................................. 85 8.1 Introduo ........................................................................................................................... 85 8.2 Considerao sobre Normas .............................................................................................. 85 8.2.1 Aspectos Gerais das Normas ......................................................................................... 86 8.2.2 Normas Internacionais .................................................................................................... 86 8.2.3 Normas Nacionais .......................................................................................................... 87 8.2.4 Normas de Domnio Especfico ...................................................................................... 87 8.2.5 Outras Normas ............................................................................................................... 88 8.3 Processo de Melhoria de Teste .......................................................................................... 89 8.3.1 Introduo Melhoria de Processo ................................................................................ 89 8.3.2 Tipos de Melhoria de Processo ...................................................................................... 89 8.4 Melhoria do Processo de Teste .......................................................................................... 90 8.5 Melhoria do Processo de Teste com TMM ......................................................................... 91 8.6 Melhoria do Processo de Teste com TPI ............................................................................ 92 8.7 Melhoria do Processo de Teste com CTP .......................................................................... 93 8.8 Melhoria do Processo de Teste com STEP ........................................................................ 93 8.9 Integrao do Modelo de Maturidade e Capacidade, CMMI ............................................... 94 9. Ferramentas de Teste e Automatizao...................................................................................... 95 9.1 Introduo ........................................................................................................................... 95 9.2 Conceitos de Ferramentas de Teste ................................................................................... 95 9.2.1 Custo-benefcio e Riscos de Ferramentas de Teste e Automatizao ........................... 96 9.2.2 Estratgias de Ferramenta de Teste .............................................................................. 97 9.2.3 Integrao & Troca de Informao entre Ferramentas ................................................... 97 9.2.4 Linguagens de Automatizao: Scripts, Linguagem de Script........................................ 98 9.2.5 O Conceito de Orculos de Teste .................................................................................. 98 9.2.6 Implantao de Ferramenta de Teste ............................................................................. 98 9.2.7 Uso de Ferramentas de Teste de Cdigo Aberto ........................................................... 99 9.2.8 Desenvolvendo sua Prpria Ferramenta de Teste ......................................................... 99 9.2.9 Classificao de Ferramenta de Teste ......................................................................... 100 9.3 Categorias de Ferramentas de Teste ............................................................................... 100 9.3.1 Ferramentas de Gerenciamento de Teste .................................................................... 100 9.3.2 Ferramentas de Execuo de Teste ............................................................................. 101 9.3.3 Ferramentas de Depurao & Investigao ................................................................. 102 9.3.4 Ferramentas de Semeadura de Faltas & Injeo de Faltas ......................................... 102 9.3.5 Ferramentas de Simulao & Emulao ...................................................................... 102 9.3.6 Ferramentas de Anlise Esttica e Dinmica ............................................................... 103 9.3.7 Automatizao de Teste Orientado a Palavra-chave ................................................... 103 9.3.8 Ferramentas de Teste de Desempenho ....................................................................... 104 9.3.9 Ferramentas Web ......................................................................................................... 105 10. Competncias de Pessoas Composio de Equipe........................................................... 106 10.1 Introduo ......................................................................................................................... 106 10.2 Competncias Individuais ................................................................................................. 106 10.3 Dinmica da Equipe de Teste ........................................................................................... 107 10.4 Ajustando o Teste em uma Organizao .......................................................................... 107 10.5 Motivao.......................................................................................................................... 108 10.6 Comunicao .................................................................................................................... 109
Verso 2007br
Pgina 6 de 124
02 Fev 2010
Certified Tester
11. Referncias ........................................................................................................................... 110 11.1 Normas ............................................................................................................................. 110 11.1.1 Por Captulo ............................................................................................................. 110 11.1.2 Alfabtico.................................................................................................................. 110 11.2 Livros ................................................................................................................................ 111 11.3 Outras referncias ............................................................................................................ 112 12. Apndice A Syllabus background....................................................................................... 113 13. Apndice B Aviso aos Leitores........................................................................................... 114 13.1 Comisses de Exame ....................................................................................................... 114 13.2 Candidatos & Provedores de Treinamento ....................................................................... 114 14. Apndice C Aviso aos Provedores de Treinamento ........................................................... 115 14.1 Modularidade .................................................................................................................... 115 14.2 Ritmo de Treinamento ...................................................................................................... 115 14.2.1 Treinamento por Mdulo .......................................................................................... 115 14.2.2 Partes em Comum ................................................................................................... 115 14.2.3 Fontes ...................................................................................................................... 115 14.3 Exerccios Prticos ........................................................................................................... 115 15. Apndice D Recomendaes ............................................................................................. 117 15.1 Recomendaes para Industrializao ............................................................................. 117 16. ndice ..................................................................................................................................... 120
Verso 2007br
Pgina 7 de 124
02 Fev 2010
Certified Tester
Agradecimentos
Este documento, em sua verso original ISTQB 2007, foi desenvolvido pela comisso principal do grupo de trabalho do nvel avanado do International Software Testing Qualifications Board: Bernard Homs (presidente), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Thomas Mueller, Klaus Olsen, Randy Rice, Jurgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson e Erik Van Veenendaal. A comisso principal agradece a comisso de reviso e os conselhos nacionais por suas sugestes e contribuies. Na ocasio da finalizao do Advanced Level Syllabus, o grupo de trabalho do nvel avanado era composto pelos seguintes membros (em ordem alfabtica): Graham Bath, Rex Black, Robert Bender, Chris Carter, Maria Clara Choucair, Sigrid Eldh, Dorothy Graham, Bernard Homs (presidente), Jayapradeep Jiothis, Vipul Kocher, Anastasios Kyriakopoulos, Judy McKay, Thomas Mueller, Klaus Olsen, Avinoam Porat, Meile Posthuma, Erkki Pyhnen, Jurgen Richter, Eric Riou Du Cosquer, Jan Sabak, Hans Schaefer, Maud Schlich, Rajesh Sivaraman, Mike Smith, Michael Stahl, Geoff Thompson e Erik Van Veenendaal. As seguintes pessoas contriburam com a reviso, comentrios e decises para este syllabus: Bernard Homs (presidente) Meile Posthuma Phillip Isles Eric Riou Du Cosquer Pr. Paul C. Jorgensen Stefan Ruff Vipul Kocher Hans Schaefer Anastasios Kyriakopoulos Maud Schlich Junfei Ma Rajesh Sivaraman Fergus McClachlan Mike Smith Judy McKay Katja Stalder Don Mills Neil Thompson Gary Mogyorodi Benjamin Timmermans Richard Morgan Chris van Bael Silvio Moser Jurian van de Laar Ernst Muller Marnix van den Ent Reto Muller Mark van der Zwan Thomas Muller Stephanie van Dijck Peter Mullins Jan van Moll Beat Nagel Erik Van Veenendaal Richard Neeve Roland Weber Klaus Olsen Phillip Whettlock Dale Perry Derek Young Helmut Pichler Mike Young Jrg Pietzsch Wenqiang Zheng. Avionam Porat Iris Pinkster Horst Pohlmann Este documento foi formalmente liberado pela assembleia geral do ISTQB em 12 de outubro de 2007. Reto Armuzzi Sue Atkins Graham Bath Paul Beekman Armin Beer Rex Black Francisca Blunschi Armin Born Con Bracke Chris Carter Maria Clara Choucair Robert Dankanin Piet de Roo Sigrid Eldh Tim Edmonds Erwin Engelsma Graham Freeburn Dorothy Graham Brian Hambling Jeff B Higgott Bernard Homs Rob Hendriks Dr Suhaimi Ibrahim A traduo desta verso brasileira teve a contribuio de: Edmilson Cavalcante Torres, Eduardo Medeiros Rodrigues, Eloiza Helena Sonoda, Emlio Silva de Castro, Jos Roberto Murillo Zamora, Osmar Higashi, Raul Passos, Stnio Pereira Viveiros.
Verso 2007br
Pgina 8 de 124
02 Fev 2010
Certified Tester
0. Introduo a Este Syllabus

0.1 O International Software Testing Qualifications Board
O International Software Testing Qualifications Board (que ser referenciado como ISTQB nas citaes futuras) composto por Conselhos Membros que representam diversos pases e regies do mundo. No momento da liberao deste, o ISTQB consistia de 33 Conselhos Membros. Maiores detalhes da estrutura e dos membros do ISTQB podem ser encontrados em www.istqb.org.
Objetivo deste documento

Este syllabus apresenta a base para o nvel avanado da Qualificao Internacional de Teste de Software (International Software Testing Qualification). O ISTQB disponibiliza este syllabus da seguinte maneira: 1. Aos Conselhos Membros, para traduzirem-no em seu idioma local e para credenciar provedores de treinamento. Os conselhos nacionais podem adaptar o syllabus para as necessidades de seu idioma local e modificar as referncias para adaptar a suas publicaes locais. 2. s Comisses de Exame, para elaborar questes de exame em seu idioma local adaptadas aos objetivos de aprendizado de cada mdulo. 3. Aos provedores de treinamento, para desenvolverem seus cursos e determinarem os mtodos apropriados de ensino. 4. Aos candidatos certificao, para se prepararem para o exame (como parte de um curso de treinamento ou independentemente). 5. comunidade internacional de software e engenharia de sistemas, para promover o profissionalismo em testes de software e sistemas, e como base para livros e artigos. O ISTQB pode permitir que outras entidades usem este syllabus para outros propsitos, desde que eles procurem e obtenham permisso escrita a priori.
O Certified Tester Advanced Level em testes de software

A qualificao em Nvel Avanado destinada a pessoas que tenham alcanado um ponto avanado em suas carreiras em testes de software. Essa situao inclui pessoas como testadores, analistas de teste, engenheiros de teste, consultores de teste, gerentes de teste, executores de teste de aceite e desenvolvedores de software. Essa qualificao de Nvel Avanado apropriada tambm para todo aquele que pretende adquirir um conhecimento profundo de testes de software, tais como gerentes de projeto, gerentes de qualidade, gerentes de desenvolvimento de software, analistas de negcios, diretores de TI e consultores de gerenciamento. Para receber a certificao em Nvel Avanado, os candidatos devem apresentar o certificado em Nvel Fundamental e satisfazer a Comisso de Exame que analisa se eles apresentam experincia prtica suficiente para serem considerados qualificados ao Nvel Avanado. A Comisso de Exame relevante deve ser consultada para entender seus critrios especficos para experincia prtica.
Nvel de conhecimento
Objetivos de aprendizagem so divididos para cada captulo de tal forma que eles podem ser claramente identificados para cada mdulo individual. Maiores detalhes e exemplos de objetivos de aprendizagem so apresentados na seo 0.3. O contedo deste syllabus, termos e elementos principais (objetivos) de todos os padres listados devem ser ao menos lembrados (K1), mesmo que no mencionados explicitamente nos objetivos de aprendizagem.
Verso 2007br
Pgina 9 de 124
02 Fev 2010
Certified Tester
Exame
Todos os exames para Certificao em Nvel Avanado devem ser baseados neste syllabus e no Foundation Level Syllabus. As respostas das questes do exame podem requerer o uso de material baseado em mais do que uma seo deste e do Foundation Level Syllabus. Todas as sees deste e do Foundation Level Syllabus so passveis de avaliao. O formato do exame definido pelas Orientaes para Exame Avanado do ISTQB. Os Conselhos Membros podem adotar individualmente outros esquemas de exame se desejado. Os exames podem fazer parte de um curso de treinamento credenciado ou realizado independentemente (por exemplo, em um centro de avaliaes). Os exames podem ser realizados em papel ou eletronicamente, mas todos os exames devem ser supervisionados/observados (supervisionados por uma pessoa enviada pelo Conselho Nacional ou pelo Conselho de Exame).
Credenciamento
Um Conselho Membro do ISTQB pode credenciar provedores de treinamento cujo material de curso siga este syllabus. Os provedores de treinamento podem obter as orientaes ao credenciamento com o conselho nacional ou grupo que realiza esse credenciamento. Um curso credenciado reconhecido como em conformidade com este syllabus, e permitido que tenha um exame ISTQB como parte dos seus cursos. Maiores detalhes para os provedores de treinamento so dados no Apndice C Notas aos Provedores de Treinamento.
Nvel de detalhe
O nvel de detalhe deste syllabus permite que tanto o treinamento como o exame sejam feitos internacionalmente de forma consistente. Com foco em alcanar esses objetivos, o syllabus consiste de: Objetivos de instruo geral que descrevem as intenes do Nvel Avanado; Objetivos de aprendizagem para cada rea de conhecimento, descrevendo os resultados do aprendizado e das metas a serem atingidos; Uma lista de informaes para ensino, incluindo uma descrio e referncias a fontes adicionais, se necessrias; Uma lista de termos que os estudantes precisam estar aptos a relembrar e compreender; Uma explicao dos conceitos principais a serem ensinados, incluindo as fontes como a literatura aceita ou padres. O contedo do syllabus no uma descrio completa da rea de conhecimento de teste de software; ele reflete o nvel de detalhe a ser coberto em treinamentos para o Nvel Avanado.
Como este syllabus est organizado

H dez captulos principais cada um com uma seo introdutria que apresenta uma viso geral de como eles se aplicam aos diferentes profissionais de teste (mdulos). Para o propsito de treinamento, as sees 0.3 e 0.6 apresentam os objetivos de aprendizagem especficos para cada mdulo, por captulo. Essas sees tambm apresentam o tempo mnimo esperado para o estudo desses tpicos. fortemente sugerida a leitura simultnea desse syllabus e o estudo dos objetivos de aprendizagem de cada captulo especfico. Isso permitir que o leitor compreenda completamente o que requerido e qual a parte essencial de cada captulo para cada um dos trs mdulos.
Termos e definies
Muitos termos da literatura de software so usados de forma intercambivel. As definies usadas neste Advanced Level Syllabus esto disponveis no glossrio de termos de teste de software, publicado pelo BSTQB.
Verso 2007br
Pgina 10 de 124
02 Fev 2010
Certified Tester
Abordagem
H vrias possibilidades de abordagem de teste, tais como aquelas baseadas em especificaes, estrutura de cdigo, dados, riscos, processos, padres e listas de taxonomias. Diferentes processos e ferramentas fornecem apoio para os processos de teste; mtodos esto disponveis para melhorar os processos existentes. Este Advanced Level Syllabus est organizado usando as abordagens propostas na ISO 9126, com a separao em abordagens funcionais, no-funcionais e de apoio. Processos de apoio e alguns mtodos de melhoria so mencionados. A seleo dessa organizao e processos foi feita de forma arbitrria considerada para proporcionar uma base slida para os testadores em Nvel Avanado e gerentes de teste.
0.2 Expectativas
A certificao em Nvel Avanado descrita neste syllabus ser examinada em trs principais perfis, cada qual representando responsabilidades e expectativas bsicas dentro de uma organizao. Em qualquer organizao, responsabilidades e tarefas associadas podem se dividir entre indivduos diferentes, ou cobertas por uma s pessoa. As responsabilidades de trabalho esto listadas a seguir.
0.2.1 Advanced Level Test Manager

Profissionais Test Manager em Nvel Avanado devem ser capazes de: Definir objetivos e estratgias gerais do teste para um sistema que esteja sendo testado Planejar, programar e rastrear as tarefas Descrever e organizar as atividades necessrias Selecionar, adquirir e distribuir os recursos adequados s tarefas Selecionar, organizar e conduzir equipes de teste Organizar a comunicao entre os membros de equipes de teste, e entre as equipes de teste e todos os outros interessados Justificar as decises e fornecer reporte adequado de informaes quando aplicvel
0.2.2 Advanced Level Test Analyst

Test Analysts em Nvel Avanado devem ser capazes de: Estruturar tarefas definidas na estratgia de teste em termos de requisitos de negcio Analisar o sistema em um nvel de detalhamento suficiente para corresponder s expectativas de qualidade do usurio Analisar os requisitos de sistema para determinar a validade dentro do domnio Preparar e executar atividades adequadas, e relatar seu progresso Fornecer as evidncias necessrias para apoiar as avaliaes Implementar as ferramentas necessrias e tcnicas para atingir metas definidas
0.2.3 Advanced Level Technical Test Analyst

Technical Test Analysts em Nvel Avanado devem ser capazes de: Estruturar as tarefas definidas na estratgia de teste em termos de requisitos tcnicos Analisar a estrutura interna de um sistema em um detalhamento suficiente para corresponder ao nvel de qualidade esperado Analisar o sistema em termos de atributos tcnicos de qualidade tais como desempenho, segurana, etc. Preparar e executar as atividades adequadas, e relatar seu progresso
Verso 2007br
Pgina 11 de 124
02 Fev 2010
Certified Tester
Conduzir atividades tcnicas de teste Fornecer as evidncias necessrias para apoiar avaliaes Implementar as ferramentas e tcnicas necessrias para atingir metas definidas
0.3 Objetivos de Aprendizagem / Nveis de Conhecimento

Os seguintes objetivos de aprendizagem so definidos para aplicao deste syllabus. Cada tpico no syllabus ser examinado de acordo com o seu objetivo de aprendizagem. Nvel 1: Lembrar (K1) O candidato deve reconhecer, lembrar e retomar um termo ou conceito. Palavras chave: Lembrar, retomar, reconhecer, saber. Exemplo: Pode reconhecer a definio de falha como: a no entrega de um servio a um usurio final ou a algum outro stakeholder ou desvio real de um componente ou sistema, servio ou resultado esperado. Nvel 2: Compreender (K2) O candidato pode selecionar as razes e justificativas para afirmaes relacionadas ao tpico, e pode resumir, diferenciar, classificar e exemplificar fatos (tal como comparar termos), os conceitos de teste, procedimentos de teste (explicando a sequncia de tarefas). Palavras chave: Resumir, classificar, comparar, mapear, contrastar, exemplificar, interpretar, traduzir, representar, inferir, concluir, categorizar. Exemplos: Explique o motivo pelo qual os testes devem ser modelados to cedo quanto possvel: Para encontrar defeitos quando eles so mais baratos para serem removidos. Para encontrar os defeitos mais importantes primeiro. Explique as similaridades e diferenas entre teste de integrao e de sistema: Similaridades: teste de mais de um componente alm de poderem testar aspectos nofuncionais. Diferenas: o teste de integrao se concentra nas interfaces e interaes, e o teste de sistema se concentra nos aspectos do sistema como um todo, tal como o processamento end-to-end. Nvel 3: Aplicar (K3) O candidato pode selecionar a aplicao correta de um conceito ou tcnica e aplicar em um determinado contexto. K3 normalmente aplicvel ao conhecimento de procedimento. No h atividade criativa como a de avaliar um software aplicativo ou de criar um modelo para um software dado. Quando temos um modelo definido e cobrimos no syllabus os passos do procedimento de criao de casos de teste a partir do modelo, ento isso K3. Palavras chave: Implementar, executar, usar, seguir um procedimento, aplicar um procedimento. Exemplo: Identificar os valores limites para parties vlidas e invlidas. Usar um procedimento genrico para a criao de um caso de teste para selecionar casos de teste de um diagrama de transio de estado (e um conjunto de casos de teste) para cobrir todas as transies. Nvel 4: Analisar (K4) O candidato pode separar as informaes relacionadas a procedimentos ou tcnicas em suas partes constituintes para melhor entendimento, e pode verificar a separao entre fatos e inferncias. Uma aplicao tpica seria analisar um documento, software, situao de projeto, e propor aes apropriadas para resolver um problema ou uma tarefa. Palavras chave: Analisar, diferenciar, selecionar, estruturar, focar, atribuir, decompor, avaliar, julgar, monitorar, coordenar, criar, sintetizar, gerar, planejar, modelar, construir, produzir. Exemplo:
Verso 2007br
Pgina 12 de 124
02 Fev 2010
Certified Tester
Analisar riscos de produto e propor atividades de mitigao preventivas e corretivas. Descrever quais pores de um relatrio de incidente so factuais e quais so inferidas atravs dos resultados.
Referncia (Para os nveis cognitivos dos objetivos de aprendizagem) Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, David McKay, Co. Inc. Anderson, L. W. and Krathwohl, D. R. (eds) (2001). A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon.
0.4 Objetivos de Aprendizagem para Test Manager

Esta seo apresenta uma lista detalhada de objetivos de aprendizagem para o mdulo de Test Manager. Em geral, todas as partes deste syllabus so passveis de avaliao no nvel K1. Isso significa que o candidato dever reconhecer, lembrar e retomar um termo ou conceito. Por este motivo a tabela a seguir somente contm os objetivos de aprendizagem nos nveis K2, K3 e K4.
Introduo ao Advanced Level Syllabus [60 minutos]
(Incluindo reviso ao Foundation Level Syllabus do ISTQB)

Captulo 1: Aspectos Bsicos de Teste de Software [150 minutos] 1.2 Teste no Ciclo de Vida de Software
(K2) Descrever como o teste parte de qualquer atividade desenvolvimento de software e de manuteno. (K4) Analisar os modelos de ciclo de vida de software e listar as tarefas/atividades de teste mais apropriadas para executar. (distinguir entre as atividades de teste e desenvolvimento). (K2) Explicar atravs de exemplos as especificidades do teste de Sistemas de Sistemas. (K2) Explicar porque os trs principais resultados de teste de sistemas de segurana crtica so necessrios para demonstrar a aderncia s regulamentaes. (K2) Descrever e comparar as mtricas tradicionais relacionadas a teste. (K3) Monitorar as atividades de teste atravs de medies no objeto de teste e no processo de teste.
1.3 Sistemas Especficos
1.4 Mtricas & Medies
Captulo 2: Processos de Teste [120 minutos] 2.3 Planejamento e Controle de Teste
(K2) Descrever, com exemplos, como as estratgias de teste afetam o planejamento de teste. (K2) Comparar os produtos de trabalho do teste e explicar, atravs de exemplos, as relaes entre os produtos de trabalho de desenvolvimento e de teste. (K2) Classificar as atividades de controle de teste relacionadas determinao se a misso de teste, as estratgias e os objetivos foram alcanados. (K2) Explicar as pr-condies para a execuo do teste. (K2) Explicar, atravs de exemplos, as vantagens e desvantagens de implementao de teste o mais cedo possvel considerando diferentes tcnicas de teste. (K2) Explicar os motivos pelos quais os usurios e/ou clientes podem ser includos nas execues de teste. (K2) Descrever como o nvel de registro de teste pode variar dependendo do nvel de teste. (K2) Resumir a informao necessria a coletar durante o processo de teste para apoiar um relato preciso e avaliao mediante os critrios de sada.
2.5 Implementao e Execuo de Teste
2.6 Avaliao de Critrio de Sada e Reporte
Verso 2007br
Pgina 13 de 124
02 Fev 2010
Certified Tester
2.7 Atividades de Encerramento de Teste
(K2) Resumir os quatro grupos de atividades de encerramento de teste. (K3) Generalizar as lies aprendidas na fase de encerramento de teste para descobrir reas para melhoria ou repetio. (K4) Listar documentos de gerenciamento de teste tais como Plano de Teste, Especificao de Modelagem de Teste e Procedimento de Teste de acordo com a IEEE 829. (K2) Descrever ao menos 4 elementos importantes para uma estratgia/abordagem de teste e quais documentos, de acordo com a IEEE 829, contm os elementos da estratgia de teste. (K2) Ilustrar como e porque desvios da estratgia de teste so gerenciados em outros documentos de gerenciamento de teste. (K2) Resumir a estrutura de um plano mestre de teste da IEEE 829. (K2) Parafrasear e interpretar os tpicos sugeridos pela estrutura da norma IEEE 829 para o plano de teste com respeito adequao a uma empresa, risco de produto e risco, tamanho e formalidade de um projeto. (K3) Estimar o esforo de teste para uma amostra pequena de sistema usando mtricas referentes a uma abordagem baseada em experincia considerando os fatores que influenciam custo, esforo e durao. (K2) Entender e dar exemplos dos fatores listados no syllabus que podem conduzir a imprecises nas estimativas. (K2) Explicar os benefcios de planejamento de teste cedo e iterativo. Apoiar suas explicaes atravs de exemplos. (K2) Comparar os diferentes procedimentos para controlar o progresso do teste. (K2) Dar pelo menos 5 exemplos conceitualmente diferentes de como os resultados do progresso de teste influenciam o processo de teste. (K4) Usar resultados observados relativos ao progresso de teste durante as atividades de monitoramento e controle, e medidas para esboar um plano de ao para melhoria do processo de teste corrente. Sugerir melhorias. (K4) Analisar os resultados de teste e determinar o progresso de teste, documentado em um relatrio de monitoramento e em um relatrio final de resumo de teste cobrindo todas as 4 dimenses de relatrio. (K2) Dar exemplos (medies) para cada uma das 4 categorias que determinam o custo de qualidade. (K3) Listar, para um dado contexto, valores quantitativos e/ou qualitativos que se aplicam. (K2) Listar riscos, similaridades e diferenas entre as trs estratgias de contratao de equipe (teste distribudo, outsourced & insourced) (K2) Explicar as diferentes formas de como o teste baseado em riscos respondem aos riscos. (K4) Identificar os riscos dentro de um projeto e de um produto, e tambm determinar a estratgia de teste adequada e o plano de teste adequado baseados nesses riscos. (K3) Executar uma anlise de risco para o produto a partir de uma perspectiva dos testadores, seguindo a abordagem especfica do FMEA.
Captulo 3: Gerenciamento de Teste [1120 minutos] 3.2 Documentao de Gerenciamento de Teste
3.3 Documentao de Plano de Teste
3.4 Estimativa de Teste
3.5 Programando o Planejamento de Teste
3.6 Monitoramento & Controle do Progresso de Teste
3.7 Valor de Negcio do Teste
3.8 Teste Distribudo, Outsourced & Insourced
3.9 Teste Baseado em Riscos 3.9.1 Introduo ao Teste Baseado em Riscos
3.9.2 Gerenciamento de Risco
Verso 2007br
Pgina 14 de 124
02 Fev 2010
Certified Tester
(K4) Resumir os resultados de vrias perspectivas do risco, tipicamente de posse de stakeholders chave do projeto e usar seu julgamento coletivo para esboar as atividades de teste para minimizar os riscos.
3.9.3 Gerenciamento de Risco em um Ciclo de Vida
(K2) Descrever as caractersticas de gerenciamento de risco que necessitam de um processo iterativo. (K3) Traduzir uma estratgia dada de teste baseado em risco para atividades de teste e monitorar seus efeitos durante o teste. (K4) Analisar e reportar os resultados de teste e determinar / propor riscos residuais para permitir aos gerentes de projeto tomar decises inteligentes sobre a liberao. 3.10 Anlise de Modo de Falha e Efeitos (K2) Descrever o conceito de FMEA, explicar sua aplicao e benefcios em projetos atravs de exemplos.
3.11 Desafios de Gerenciamento de Teste
(K2) Comparar os desafios do gerenciamento de teste para Teste Exploratrio, Sistemas de Sistemas e teste de sistemas de segurana crtica, relacionado estratgia, benefcios e desvantagens, adequao e seu impacto no planejamento, cobertura e monitoramento e controle.
Captulo 4: Tcnicas de Teste [0 minutos] No h objetivos de aprendizagem (em algum nvel K) aplicados para o Test Manager. Captulo 5: Teste de Caractersticas de Software [0 minutos] No h objetivos de aprendizagem (em algum nvel K) aplicados para o Test Manager. Captulo 6: Revises [120 minutos] 6.2 Os Princpios das Revises
(K2) Explicar os benefcios das revises comparados aos de teste dinmico e de outras tcnicas de teste esttico. (K2) Comparar os tipos de reviso entre si, mostrar seus pontos fortes e fracos e seu campo de uso. (K3) Conduzir uma equipe de reviso em uma reviso formal seguindo passos identificados. (K4) Esboar um plano de reviso como parte do plano de qualidade/teste para um projeto, considerando tcnicas de reviso levando em conta os defeitos a serem encontrados, as habilidades disponveis na equipe e alinhamento com abordagens apropriadas de teste dinmico. (K2) Explicar os riscos resultantes de no considerar os desafios tcnicos, fatores organizacionais e pessoais para a realizao de revises. (K3) Processar um defeito seguindo o procedimento do gerenciamento de incidente de ciclo de vida como proposto pelo padro IEEE 1044 1993. (K3) Avaliar os relatrios de defeito mediante o padro IEEE 1044 1993 e aplicar uma taxonomia de defeito para melhorar sua qualidade. (K4) Analisar os relatrios de defeito criados e atualizar a taxonomia de defeito. (K2) Resumir as fontes de normas e explicar sua utilidade para o teste de software. (K3) Escrever e testar um plano de melhoria usando etapas genricas envolvendo as pessoas certas.
6.4 Introduo s Revises
6.5 Fatores de Sucesso para Revises
Captulo 7: Gerenciamento de Incidente [80 minutos]
Captulo 8: Normas & Processo de Melhoria de Teste [120 minutos] 8.4 Melhoria nos Processos de Teste
Verso 2007br
Pgina 15 de 124
02 Fev 2010
Certified Tester
(K2) Resumir o processo de melhoria de teste como definido por TMM, TPI, CTP, STEP e as reas de processo de verificao e validao no CMMI. (K2) Explicar o critrio de avaliao dos modelos de melhoria de teste TMM, TPI, CTP, STEP e as reas de processo de verificao e validao no CMMI.
Captulo 9: Ferramenta de Teste e Automatizao [90 minutos] 9.2 Conceitos de Ferramentas de Teste
(K2) Comparar os elementos e aspectos de cada um dos conceitos de ferramenta de testes: Benefcios e Riscos, Estratgias de Ferramentas de Teste, Ferramenta de Integrao, Linguagens de Automatizao, Orculo de Teste, Implantao de Ferramenta, Ferramentas de Cdigo Aberto, Desenvolvimento de Ferramentas e Classificao de Ferramentas. (K2) Descrever por que e quando importante criar uma estratgia de ferramenta de teste ou um guia para sua ferramenta de teste. (K2) Entender as diferentes fases da implementao de uma ferramenta de teste. (K2) Resumir as categorias de ferramentas de teste por objetivos, uso intencionado, pontos fortes, riscos e exemplos. (K2) Resumir requisitos especficos para ferramentas de teste e ferramentas de teste de cdigo aberto usadas para teste de sistemas de Segurana Crtica. (K2) Descrever aspectos importantes e consequncias de diferentes ferramentas de teste, e sua implementao, uso e efeitos no processo de teste. (K2) Descrever quando e como a implementao de sua prpria ferramenta uma opo, e seus benefcios, riscos e consequncias.
9.3 Categorias de Ferramenta de Teste
Captulo 10: Competncias de Pessoas Composio de Equipe [240 minutos] 10.2 Competncias Individuais
(K3) Usar um questionrio dado para determinar os pontos fracos e fortes dos membros da equipe relacionado ao uso de sistemas de software, conhecimento do domnio e do negcio, reas de desenvolvimento de sistema, teste de software e habilidades interpessoais. (K3) Realizar gap analysis para determinar as habilidades tcnicas e superficiais para posies em aberto na empresa. (K2) Caracterizar as vrias opes organizacionais e compar-las com in/out-source e in/offshoring. (K2) Fornecer exemplo de fatores motivadores e desmotivadores para testadores. (K2) Descrever, atravs de exemplos, a comunicao profissional, objetiva e efetiva em um projeto sob a perspectiva do testador. Podem ser considerados os riscos e oportunidades.
10.3 Dinmica da Equipe de Teste
10.4 Adequando o Teste a uma Empresa
10.5 Motivao 10.6 Comunicao
0.5 Objetivos de Aprendizagem para Test Analyst

Esta seo apresenta uma lista detalhada dos objetivos de aprendizagem para o mdulo de Test Analyst. Em geral, todas as partes deste syllabus so passveis de avaliao no nvel K1. Isso significa que o candidato dever reconhecer, lembrar e retomar um termo ou conceito. Por este motivo a tabela a seguir somente contm os objetivos de aprendizagem nos nveis K2, K3 e K4.

Captulo 1: Aspectos Bsicos de Teste de Software [30 minutos]
Verso 2007br
Pgina 16 de 124
02 Fev 2010
Certified Tester
Captulo 2: Processos de Teste [180 minutos] 2.4 Anlise e Modelagem de Teste
(K2) Explicar os motivos pelos quais o teste funcional ocorre em fases especficas em um ciclo de vida da aplicao. (K2) Exemplificar o critrio que influencia a estrutura e o nvel do desenvolvimento da condio de teste. (K2) Descrever como a anlise e modelagem de teste so tcnicas de teste estticas que podem ser usadas para descobrir defeitos. (K2) Explicar, atravs de exemplos, o conceito de orculo de teste e como um orculo de teste pode ser usado na especificao de teste. (K2) Explicar as pr-condies para a execuo do teste, incluindo: testware, ambiente de teste, gerenciamento de configurao e gerenciamento de defeitos. (K3) Determinar, a partir de um conjunto de medidas, se um critrio de concluso de teste foi correspondido.
Captulo 3: Gerenciamento de Teste [120 minutos] 3.9.2 Teste Baseado em Riscos
(K3) Priorizar a seleo de casos de teste, cobertura de teste e dados de teste baseado no risco e documentar apropriadamente em uma programao de teste e procedimento de teste. (K2) Listar as atividades de uma abordagem baseada em riscos para o planejamento e execuo do domnio de teste.
Captulo 4: Tcnicas de Teste [1080 minutos] 4.2 Baseado em Especificao
(K2) Listar exemplos de defeitos tpicos a serem identificados para cada tcnica especfica baseada em especificao, fornecendo um critrio correspondente de cobertura. (K3) Escrever casos de teste a partir de uma dada modelagem de software usando as seguintes tcnicas de modelagem de teste (os testes devem alcanar um dado modelo de cobertura): o Partio de equivalncia o Anlise de valor limite o Tabelas de deciso o Teste de transio de estado o Mtodo de classificao por rvore o Teste por pares o Casos de uso (K4) Analisar o sistema, ou sua especificao de requisitos, para determinar quais tcnicas baseadas na especificao aplicar para objetivos especficos e esboar uma especificao de teste baseado na IEEE 829, com foco em casos e procedimentos de teste funcionais e de domnio. (K2) Descrever o princpio e motivos para tcnicas baseadas em defeito e diferenciar seu uso de tcnicas baseadas em especificao e estrutura. (K2) Explicar atravs de exemplos a taxonomia de defeitos e seu uso. (K2) Entender o princpio e motivos para usar tcnicas baseadas em experincia e quando utiliz-las. (K3) Especificar, executar e relatar os testes usando teste exploratrio. (K2) Classificar defeitos a serem identificados pelos diferentes tipos de ataques a falhas de software de acordo com os defeitos alvo. (K4) Analisar um sistema para determinar quais tcnicas baseadas em especificao, defeito ou experincia aplicar para objetivos especficos.
4.4 Baseado em Defeito e Experincia
Verso 2007br
Pgina 17 de 124
02 Fev 2010
Certified Tester
Captulo 5: Teste de Caractersticas de Software [210 minutos] 5.2 Atributos de Qualidade para Teste de Domnio
(K4) Explicar, atravs de exemplos, quais tcnicas listadas no captulo 4 so apropriadas para o teste de preciso, adequao, interoperabilidade, segurana funcional e caractersticas de acessibilidade. (K3) Esboar, modelar, especificar e executar testes de usabilidade usando tcnicas apropriadas e cobrindo objetivos de teste e defeitos alvos. (K2) Explicar os motivos para incluir testes de eficincia, confiabilidade e segurana tcnica na estratgia de teste e fornecer exemplos de defeitos que se espera encontrar. (K2) Caracterizar tipos de teste no-funcionais para teste tcnico atravs de defeitos tpicos a serem alvo (atacados), sua aplicao tpica dentro do ciclo de vida da aplicao e tcnicas de teste apropriadas para uso em modelagem de teste. (K3) Usar uma lista de checagem de reviso para verificar o cdigo e a arquitetura a partir da perspectiva do testador. (K3) Usar uma lista de checagem de reviso para verificar os requisitos e casos de uso a partir da perspectiva do testador. (K2) Comparar tipos de reviso entre si, mostrar suas foras e fraquezas relativas e campos de uso. (K4) Analisar, classificar e descrever defeitos funcionais e no-funcionais em relatrios inteligveis de defeito.
5.3 Atributos de Qualidade para Teste Tcnico
Captulo 6: Revises [180 minutos]
Captulo 8: Normas & Processo de Melhoria de Teste [0 minutos] No h objetivos de aprendizagem (em algum nvel K) aplicados para Test Analysts. Captulo 9: Ferramenta de Teste e Automatizao [90 minutos] 9.2 Conceitos de Ferramentas de Teste
(K2) Comparar os elementos e aspectos de cada um dos conceitos de ferramenta de testes: Benefcios e Riscos, Estratgias de Ferramentas de Teste, Ferramenta de Integrao, Linguagens de Automatizao, Orculo de Teste, Implantao de Ferramenta, Ferramentas de Cdigo Aberto, Desenvolvimento de Ferramentas e Classificao de Ferramentas. (K2) Resumir as categorias de ferramentas de teste por objetivos, uso intencionado, pontos fortes, riscos e exemplos. (K2) Mapear as ferramentas de categorias de ferramentas para diferentes nveis e tipos de teste.
Captulo 10: Competncias de Pessoas Composio de Equipe [30 minutos] 10.6 Comunicao
(K2) Descrever, atravs de exemplos, a comunicao profissional, objetiva e efetiva em um projeto sob a perspectiva do testador. Podem ser considerados os riscos e oportunidades.
0.6 Objetivos de Aprendizagem para Technical Test Analyst

Esta seo apresenta uma lista detalhada dos objetivos de aprendizagem para o mdulo de Technical Test Analyst.
Verso 2007br
Pgina 18 de 124
02 Fev 2010
Certified Tester
Em geral, todas as partes deste syllabus so passveis de avaliao no nvel K1. Isso significa que o candidato dever reconhecer, lembrar e retomar um termo ou conceito. Por este motivo a tabela a seguir somente contm os objetivos de aprendizagem nos nveis K2, K3 e K4.

Captulo 1: Aspectos Bsicos de Teste de Software [30 minutos] Captulo 2: Processos de Teste [180 minutos] 2.4 Anlise e Modelagem de Teste
(K2) Explicar as fases de um ciclo de vida de aplicao onde testes no-funcionais e testes baseados na arquitetura podem ser aplicados. Explicar as causas de testes no-funcionais acontecerem somente em estgios especficos em um ciclo de vida da aplicao. (K2) Exemplificar o critrio que influencia a estrutura e o nvel do desenvolvimento da condio de teste. (K2) Descrever como a anlise e modelagem de teste so tcnicas de teste estticas que podem ser usadas para descobrir defeitos. (K2) Explicar, atravs de exemplos, o conceito de orculo de teste e como um orculo de teste pode ser usado na especificao de teste. (K2) Explicar as pr-condies para a execuo do teste, incluindo: testware, ambiente de teste, gerenciamento de configurao e gerenciamento de defeitos. (K3) Determinar, a partir de um conjunto de medidas, se um critrio de concluso de teste foi correspondido.
Captulo 3: Gerenciamento de Teste [120 minutos] 3.9.2 Teste Baseado em Riscos
(K2) Listar as atividades de uma abordagem baseada em riscos para o planejamento e execuo tcnica de teste
Captulo 4: Tcnicas de Teste [930 minutos] 4.2 Baseado em Especificao
(K2) Listar exemplos de defeitos tpicos a serem identificados para cada tcnica especfica baseada em especificao (K3) Escrever casos de teste a partir de um modelo de software real usando as seguintes tcnicas de modelagem de teste (os testes devem alcanar um dado modelo de cobertura) o Partio de equivalncia o Anlise de valor limite o Tabelas de deciso o Teste de transio de estado (K4) Analisar o sistema, ou sua especificao de requisitos, para determinar quais tcnicas baseadas na especificao aplicar para objetivos especficos e esboar uma especificao de teste baseado na IEEE 829, com foco em casos e procedimentos de teste de componente e no-funcionais. (K2) Listar exemplos de defeitos tpicos a serem identificados para cada tcnica especfica baseada em especificao (K3) Escrever casos de teste reais a partir das seguintes tcnicas de modelagem de teste (os testes devem alcanar um dado modelo de cobertura) o Teste de comando o Teste de deciso o Teste de cobertura de determinao
4.3 Baseado em Estrutura
Verso 2007br
Pgina 19 de 124
02 Fev 2010
Certified Tester
o Teste de condio mltipla (K4) Analisar um sistema para determinar quais tcnicas baseadas em estrutura aplicar para objetivos de teste especficos. (K2) Compreender cada tcnica baseada em estrutura e seu critrio de cobertura correspondente e quando utiliz-la. (K4) Ser capaz de comparar e analisar cada tcnica baseada em estrutura para utilizar em diferentes situaes. (K2) Descrever o princpio e motivos para tcnicas baseadas em defeito e diferenciar seu uso de tcnicas baseadas em especificao e estrutura. (K2) Explicar atravs de exemplos a taxonomia de defeitos e seu uso. (K2) Entender o princpio e motivos para usar tcnicas baseadas em experincia e quando utiliz-las. (K3) Especificar, executar e relatar os testes usando teste exploratrio. (K2) Classificar defeitos a serem identificados pelos diferentes tipos de ataques a falhas de software de acordo com os defeitos alvo. (K4) Analisar um sistema para determinar quais tcnicas baseadas em especificao, defeito ou experincia aplicar para objetivos especficos. (K3) Uso dos algoritmos anlise de fluxo de controle, anlise de fluxo de dados para verificar se o cdigo no apresenta nenhuma anomalia de fluxo de controle ou dados. (K4) Interpretar resultados de fluxo de controle e dados fornecidos por uma ferramenta para verificar se o cdigo apresenta alguma anomalia de fluxo de controle ou dados. (K2) Explicar o uso de grafos de chamada para avaliar a qualidade da arquitetura. Isso pode incluir os defeitos a serem identificados, o uso da modelagem e planejamento de teste, limitaes de resultados. (K2) Explicar como a anlise dinmica para o cdigo pode ser executada e resumida para defeitos que podem ser identificados por aquela determinada tcnica e suas limitaes.
4.5 Anlise Esttica
4.6 Anlise Dinmica
Captulo 5: Teste de Caractersticas de Software [240 minutos] 5.2 Atributos de Qualidade para Teste de Domnio
(K2) Caracterizar tipos de teste no-funcionais para teste de domnio atravs de defeitos tpicos a serem alvo (atacados) e sua aplicao tpica dentro do ciclo de vida da aplicao, e tcnicas de teste apropriadas para uso em modelagem de teste. (K4) Especificar casos de teste para tipos particulares de testes no-funcionais e cobrindo objetivos de teste dados e defeitos alvo. (K2) Caracterizar os tipos de teste no-funcionais para teste tcnico atravs de defeitos tpicos a serem alvo (atacados) e sua aplicao tpica dentro do ciclo de vida da aplicao, e tcnicas de teste apropriadas para uso em modelagem de teste. (K2) Compreender e explicar os estgios em um ciclo de vida de aplicao onde testes de segurana, confiabilidade e eficincia devem ser aplicados (incluindo suas sub-caractersticas correspondentes ISO 9126). (K2) Distinguir entre os tipos de falhas encontradas com testes de segurana, confiabilidade e eficincia (incluindo suas sub-caractersticas correspondentes ISO 9126). (K2) Caracterizar abordagens de teste para os atributos de qualidade de segurana, confiabilidade e eficincia e suas sub-caractersticas correspondentes ISO 9126. (K3) Especificar casos de teste para os atributos de qualidade de segurana, confiabilidade e eficincia e suas sub-caractersticas correspondentes ISO 9126. (K2) Compreender e explicar os motivos para incluir teste de manuteno, portabilidade e acessibilidade em uma estratgia de teste.
5.3 Atributos de Qualidade para Teste Tcnico
Verso 2007br
Pgina 20 de 124
02 Fev 2010
Certified Tester
(K3) Especificar casos de teste para tipos no-funcionais de teste de manuteno e portabilidade.
Captulo 6: Revises [180 minutos]
(K4) Esboar uma lista de verificao de reviso para encontrar defeitos tpicos a serem encontrados em revises de cdigo e arquitetura. (K2) Comparar tipos de reviso entre si e mostrar suas foras e fraquezas relativas, e campos de uso. (K4) Analisar, classificar e descrever defeitos funcionais e no-funcionais em relatrios inteligveis de defeito.
Captulo 8: Normas & Processo de Melhoria de Teste [0 minutos] No h objetivos de aprendizagem (em algum nvel K) aplicados para Technical Test Analysts Captulo 9: Ferramenta de Teste e Automatizao [210 minutos] 9.2 Conceitos de Ferramentas de Teste
(K2) Comparar os elementos e aspectos de cada um dos conceitos de ferramenta de testes: Benefcios e Riscos, Estratgias de Ferramentas de Teste, Ferramenta de Integrao, Linguagens de Automatizao, Orculo de Teste, Implantao de Ferramenta, Ferramentas de Cdigo Aberto, Desenvolvimento de Ferramentas e Classificao de Ferramentas. (K2) Resumir as categorias de ferramentas de teste por objetivos, uso intencionado, pontos fortes, riscos e exemplos. (K2) Mapear as ferramentas de categorias de ferramentas para diferentes nveis e tipos de teste (K3) Criar tabelas de palavras-chave/aes usando os algoritmos de seleo de palavrachave a serem usados por uma ferramenta de execuo de teste (K3) Gravar testes com ferramentas de captura/replay para tornar o teste de regresso possvel com alta qualidade, muitos casos de teste cobertos, em um curto espao de tempo. (K3) Modelar um teste de desempenho usando ferramentas de teste de desempenho, incluindo planejamento e medies das caractersticas de um sistema.
9.3.7 Automatizao de Teste Dirigido a Palavra-chave
9.3.8 Ferramentas de Teste de Desempenho
Captulo 10: Competncias de Pessoas Composio de Equipe [30 minutos] 10.6 Comunicao
(K2) Descrever, atravs de exemplos, a comunicao profissional, objetiva e efetiva em um projeto sob a perspectiva do testador. Podem ser considerados os riscos e oportunidades.
Verso 2007br
Pgina 21 de 124
02 Fev 2010
Certified Tester
1. Aspectos Bsicos de Teste de Software

Termos:
tica, medio, mtrica, sistemas de segurana crtica, sistemas de sistemas, ciclo de vida de software
1.1 Introduo
Este captulo introduz alguns temas centrais de teste que tm relevncia geral para todos os profissionais de teste, tanto Test Manager, Test Analysts, ou Technical Test Analysts. Provedores de treinamento explicaro esses temas gerais no contexto do mdulo que estar sendo discutido e daro exemplos relevantes. Por exemplo, no mdulo Technical Test Analyst, o tema geral de Mtricas e Medies (seo 1.4) usar exemplos de mtricas tcnicas especficas, tais como medidas de desempenho. Na seo 1.2 o processo de teste considerado como parte de um ciclo de vida de desenvolvimento completo. Esse tema forma a base de conceitos introduzidos no Syllabus Foundation Level e d particular ateno ao alinhamento do processo de teste com o modelo de ciclo de vida de desenvolvimento de software e com outros processos de TI. Os sistemas podem variar de forma, o que influencia significativamente como o teste abordado. Na seo 1.3 dois tipos especficos de sistema so introduzidos, dos quais todos os testadores devem estar a par, sistemas de sistemas (algumas vezes referenciados como multissistemas) e sistemas de segurana crtica. Testadores avanados encaram vrios desafios quando introduzem os diferentes aspectos de teste descritos neste syllabus no contexto de suas prprias empresas, equipes e tarefas.
1.2 O Teste no Ciclo de Vida de Software

O teste uma parte integral de vrios modelos de desenvolvimento de software, tais como: Sequencial (modelo em cascata, modelo V e modelo W) Iterativo (Rapid Application Development RAD e modelo em espiral) Incremental (evolucionrio e metodologias geis) A abordagem de longo prazo do ciclo de vida do teste deve ser considerada e definida como parte da estratgia de teste. Isso inclui a organizao e definio dos processos, e seleo de ferramentas e de mtodos. O processo de teste no realizado isoladamente, mas sim interconectado e relacionado a outros como: Engenharia de requisitos e gerenciamento Gerenciamento de projeto Gerenciamento de configurao e mudana Desenvolvimento de software Manuteno de software Suporte tcnico Produo de documentao tcnica
Verso 2007br
Pgina 22 de 124
02 Fev 2010
Certified Tester
O planejamento de teste precoce e a execuo de teste so apresentados em modelos de desenvolvimento de software sequencial. As tarefas de teste podem se sobrepor e/ou serem concorrentes. Gerenciamento de mudana e configurao so tarefas de suporte importantes para o teste de software. Sem um gerenciamento de mudana apropriado, o impacto de mudanas no sistema no pode ser avaliado. Sem um gerenciamento de configurao evolues concorrentes podem ser perdidas ou mal gerenciadas. Dependendo do contexto do projeto, nveis adicionais de teste queles definidos no Foundation Level Syllabus podem ser definidos, tais como: Teste de integrao de hardware-software Teste de integrao de sistema Teste de interao de funcionalidade Teste de integrao de produto cliente Cada nvel de teste tem as seguintes caractersticas: Objetivos do teste Escopo do teste Rastreabilidade base de teste Critrio de entrada e sada Entregveis do teste incluindo o relatrio Tcnicas de teste Medies e mtricas Ferramentas de teste Aderncia com a organizao e outros padres Dependendo do contexto, objetivos e escopo para cada nvel de teste podem ser considerados isoladamente ou para um nvel de projeto (por exemplo, para evitar duplicao desnecessria atravs de diferentes nveis de teste similares). Atividades de teste devem ser alinhadas ao modelo de ciclo de vida de desenvolvimento de software escolhido, cuja natureza pode ser sequencial (por exemplo, Cascata, Modelo V, Modelo W), iterativo (por exemplo, Rapid Application Development RAD e modelo em espiral) ou incremental (por exemplo, evolucionrio e metodologias geis). Para exemplificar, em um modelo V, o processo fundamental de teste do ISTQB aplicado ao nvel de teste de sistema poderia ser alinhado da seguinte forma: O planejamento de teste de sistema ocorre concorrentemente com o planejamento do projeto e o controle de teste continua at a finalizao da execuo do teste de sistema e atividades de encerramento. A anlise e modelagem de teste de sistema ocorrem concorrentemente com especificao de requisitos, especificao de modelagem de sistema e arquitetura (alto nvel) e especificao de modelagem de componente (baixo nvel). A implementao de ambiente de teste de sistema (por exemplo, test beds, test rig) deve iniciar durante a modelagem de sistema, apesar de que a maior parte dela poderia acontecer tipicamente de forma concorrente com a codificao e teste de componente, com o trabalho nas atividades de implementao de teste de sistema sendo estendido at alguns dias antes do incio da execuo do teste de sistema. A execuo do teste de sistema inicia-se quando o critrio de entrada do teste de sistema foi todo satisfeito (ou abandonado), o que normalmente significa que pelo menos o teste de componente, e comumente o teste de integrao de componentes, est completo. A execuo do teste de sistema continua at que o critrio de sada do teste de sistema tenha sido satisfeito.
Verso 2007br
Pgina 23 de 124
02 Fev 2010
Certified Tester
Avaliao do critrio de sada do teste de sistema e relato dos resultados do teste de sistema poderia acontecer por toda a execuo do teste de sistema, geralmente com maior frequncia e urgncia com a aproximao dos prazos limites do projeto. As atividades de encerramento do teste de sistema ocorrem depois que os critrios de sada do teste de sistema tenham sido satisfeitos e a execuo do teste de sistema seja declarada completa, apesar de que algumas vezes elas podem ser adiadas para depois de um teste de aceite ter sido completado e todas as atividades do projeto ter sido finalizadas. Para cada nvel de teste, e para cada combinao selecionada de ciclo de vida de software e processo de teste, o gerente de teste deve realizar um alinhamento durante o planejamento do teste e/ou projeto. Para projetos particularmente complexos, tais como projetos de sistemas de sistemas (comum no mbito militar e grandes corporaes), os processos de teste no devem ser somente alinhados, mas tambm modificados de acordo com o contexto do projeto (por exemplo, quando mais fcil detectar um defeito em um nvel mais alto do que em um nvel mais baixo).
1.3 Sistemas Especficos

1.3.1 Sistemas de Sistemas
Um sistema de sistemas um conjunto de componentes colaborativos (incluindo hardware, aplicaes de software individual e comunicaes), interconectados para alcanar um propsito em comum, sem uma nica estrutura de gerenciamento. Caractersticas e riscos associados com sistemas de sistemas incluem: Unio progressiva de sistemas independentes colaborativos para evitar a criao de um sistema inteiro do seu incio. Isso pode ser alcanado, por exemplo, atravs da integrao de sistemas COTS somente com um desenvolvimento adicional limitado. As complexidades tcnica e organizacional (por exemplo, entre os diferentes interessados/stakeholders) representam riscos para um gerenciamento efetivo. Diferentes abordagens de ciclo de vida de desenvolvimento podem ser adotadas para sistemas colaboradores as quais podem levar a problemas de comunicao entre as diferentes equipes envolvidas (desenvolvimento, teste, manufatura, linha de montagem, etc.). O gerenciamento por todo o sistema de sistemas deve ser possvel de combater com a complexidade tcnica inerente de combinar os diferentes sistemas colaboradores, e ser capaz de lidar com as vrias finalidades organizacionais, tais como outsourcing e offshoring. Confidencialidade e proteo de conhecimento especfico, interfaces entre diferentes organizaes (por exemplo, setor governamental e privado), ou decises regulamentares (por exemplo, proibio de comportamento monopolista) podem significar que um sistema complexo deve ser considerado como um sistema de sistemas. Sistemas de sistemas so intrinsecamente menos confiveis do que sistemas individuais, na medida em que qualquer limitao de um (sub)sistema automaticamente aplicvel a todo o sistema de sistemas. O alto nvel de interoperabilidade tcnica e funcional requerido dos componentes individuais em um sistema de sistemas torna o teste de integrao criticamente importante e requer interfaces bem especificadas e em concordncia.
1.3.1.1 Gerenciamento & Teste de Sistemas de Sistemas O alto nvel de complexidade para o gerenciamento de projeto e gerenciamento de configurao de componente so questes comuns associadas a sistemas de sistemas. Uma forte implicao para a Garantia de Qualidade e processos definidos normalmente associada a sistemas complexos e sistemas de sistemas. Um ciclo de vida de desenvolvimento formal, marcos e revises so comumente associados aos sistemas de sistemas.
Verso 2007br
Pgina 24 de 124
02 Fev 2010
Certified Tester
1.3.1.2 Caractersticas de Ciclo de Vida para Sistemas de Sistemas Cada nvel de teste para um sistema de sistemas apresenta as seguintes caractersticas adicionais quelas descritas na seo 1.2 O Teste no Ciclo de Vida de Software: Mltiplos nveis de integrao e gerenciamento de verso Projetos de longa durao Transferncia formal de informao entre membros do projeto Evoluo no concorrente de componentes e requisitos para testes de regresso em nvel de sistema de sistemas Teste de manuteno devido troca de componentes individuais resultante de desuso ou atualizao Dentro de sistemas de sistemas, o nvel de teste deve ser considerado no nvel de detalhe e nos nveis mais altos de integrao. Por exemplo, nvel de teste de sistema para um elemento pode ser considerado como nvel de teste de componente para componentes de mais alto nvel. Normalmente cada sistema individual (dentro de sistema de sistemas) passar atravs de cada nvel de teste, e ento ser integrado no sistema de sistemas com os testes associados extra requeridos. Para questes gerenciais especficas de sistemas de sistemas, referencie a seo 3.11.2.
1.3.2 Sistemas de Segurana Crtica

Sistemas de segurana crtica so aqueles que, se suas operaes so perdidas ou degradadas (por exemplo, como resultado de operaes incorretas ou inadvertidas), podem resultar em consequncias catastrficas ou crticas. O fornecedor de sistemas de segurana crtica deve ser responsvel pelos danos ou compensaes e as atividades de teste so usadas tambm para reduzir essa responsabilidade. As atividades de teste fornecem evidncias de que o sistema estava adequadamente testado para evitar consequncias catastrficas ou crticas. Exemplos de sistemas de segurana crtica incluem sistemas de controle de voo de aeronaves, sistemas de comrcio automtico, sistemas centrais de regulagem de usinas nucleares, sistemas mdicos, etc. Os seguintes aspectos devem ser implementados em sistemas de segurana crtica: Rastreabilidade para requisitos regulamentares e objetivo de conformidade Abordagem rigorosa para desenvolvimento e teste Anlise de segurana Arquitetura redundante e sua qualificao Foco em qualidade Alto grau de documentao (profundidade e amplitude de documentao) Alto grau de auditabilidade A seo 3.11.3 considera as questes de gerenciamento de teste relacionadas a sistemas de segurana crtica. 1.3.2.1 Conformidade com Regulamentao Sistemas de segurana crtica so frequentemente sujeitos a regulamentao e padres governamentais, internacionais, ou setoriais especficos (veja tambm 8.2 Consideraes de Normas). Eles podem ser aplicados ao processo de desenvolvimento e estrutura organizacional, ou ao produto sendo desenvolvido. Para demonstrar a conformidade da estrutura organizacional e o processo de desenvolvimento, grficos organizacionais e de auditorias podem ser suficientes. Para demonstrar a conformidade com regulamentao especfica para o sistema desenvolvido (produto), necessrio mostrar que cada requisito nessas regulamentaes foi atendido
Verso 2007br
Pgina 25 de 124
02 Fev 2010
Certified Tester
adequadamente. Nesses casos, rastreabilidade completa dos requisitos s evidncias necessria para demonstrar a conformidade. Isso impacta no gerenciamento, ciclo de vida de desenvolvimento, atividades de teste e qualificao/certificao (por uma autoridade reconhecida) atravs do processo de desenvolvimento. 1.3.2.2 Sistemas de Segurana Crtica & Complexidade Muitos sistemas complexos e sistemas de sistemas tm componentes de segurana crtica. Algumas vezes o aspecto de segurana no evidente no nvel do sistema (ou subsistema), mas somente em um nvel mais alto, no qual os sistemas complexos so implementados (por exemplo, componentes eletrnicos em avies, sistemas de controle de trfego areo). Exemplo: um roteador no um sistema crtico por si s, mas pode se tornar quando uma informao crtica necessita dele, tal como um servio de telemedicina. Gerenciamento de risco, o qual reduz a probabilidade e/ou o impacto de um risco, essencial para o desenvolvimento e contexto de teste para segurana crtica (referencie o Captulo 3). Alm disso, Anlise de Modo e Efeito de Falha (FMEA) (veja seo 3.10) e Anlise de Causas Comuns de Falha de Software so comumente usados nesse contexto.
1.4 Mtricas & Medies

Vrias mtricas (nmeros) e medies (tendncias, grficos, etc.) devem ser aplicadas por todo o ciclo de vida de desenvolvimento de software (por exemplo, planejamento, cobertura, carga, etc.). Em cada caso, uma linha de base deve ser definida, e ento o progresso rastreado em relao a essa linha de base. Possveis aspectos que podem ser cobertos incluem: 1. Cronograma planejado, cobertura, e sua evoluo no tempo. 2. Requisitos, sua evoluo e seu impacto em termos de cronograma, recursos e tarefas. 3. Demanda de trabalho e uso de recursos, e sua evoluo no tempo. 4. Marcos e escopo, e sua evoluo no tempo. 5. Custos, reais e planejados para finalizar as tarefas. 6. Riscos e aes de mitigao, e sua evoluo no tempo. 7. Defeitos encontrados, defeitos corrigidos, durao da correo. O uso de mtricas permite aos testadores relatar os dados de forma consistente para sua gerncia, e permite um rastreamento coerente do progresso pelo tempo. Trs reas so consideradas: Definio de mtricas: um conjunto limitado de mtricas teis deve ser definido. Uma vez que essas mtricas tenham sido definidas, sua interpretao deve ser aprovada por todos os stakeholders, para que evite futuras discusses com a evoluo dos valores medidos. Mtricas podem ser definidas de acordo com os objetivos para um processo ou tarefa, para componentes ou sistemas, para indivduos ou equipes. H a frequente tendncia em definir mtricas em demasia, ao invs de somente as mais pertinentes. Rastreamento de mtricas: relato e unio de mtricas devem ser automatizados assim que possvel para reduzir o tempo gasto em produzir os valores iniciais de mtricas. As variaes dos dados no tempo para uma mtrica especfica podem refletir em outra informao ento a interpretao est de acordo com a fase de definio da mtrica. Relato de mtricas: o objetivo fornecer um entendimento imediato da informao, para o propsito de gerenciamento. Apresentaes podem mostrar uma viso das mtricas em um dado tempo ou mostrar a evoluo da mtrica(s) pelo tempo para que as tendncias possam ser avaliadas.
Verso 2007br
Pgina 26 de 124
02 Fev 2010
Certified Tester
1.5 tica
O envolvimento em teste de software permite que pessoas conheam informaes confidenciais e privilegiadas. Um cdigo de tica necessrio, entre outros motivos, para garantir que a informao no usada de forma inapropriada. Reconhecendo o cdigo de tica para engenheiros da ACM e IEEE, o ISTQB estabelece o seguinte cdigo de tica : PBLICO Testadores certificados devem atuar consistentemente com o interesse pblico. CLIENTE E EMPREGADOR Testadores certificados devem agir da melhor forma para os interesses de seus clientes e empregadores, consistente com o interesse pblico. PRODUTO Testadores certificados devem garantir que os entregveis que eles fornecem (produtos e sistemas que eles testam) correspondem aos mais altos padres profissionais possveis. JULGAMENTO Testadores certificados devem manter integridade e independncia em seu julgamento profissional. GERENCIAMENTO Gerentes e lderes de teste certificados devem se submeter e promover uma abordagem tica ao gerenciamento do teste de software. PROFISSO Testadores certificados devem promover a integridade e reputao da profisso, consistentemente com o interesse pblico. COLEGAS Testadores certificados devem ser agradveis e incentivadores com seus colegas, e promoverem a cooperao com os desenvolvedores de software. INDIVDUO Testadores certificados devem praticar um aprendizado vitalcio em considerao prtica de sua profisso e devem promover uma abordagem tica nessa prtica.
Verso 2007br
Pgina 27 de 124
02 Fev 2010
Certified Tester
2. Processos de Teste
Termos:
BS 7925/2, critrio de sada, IEEE 829, caso de teste, encerramento de teste, condio de teste, controle de teste, modelagem de teste, execuo de teste, implementao de teste, planejamento de teste, procedimento de teste, script de teste, relatrio de resumo de teste, registro de teste
2.1 Introduo
No ISTQB Foundation Level Syllabus, o seguinte processo fundamental de teste foi descrito com as seguintes atividades: Planejamento e controle Anlise e modelagem Implementao e execuo Avaliao do critrio de sada e relatrio Atividades de encerramento de teste Essas atividades podem ser implementadas sequencialmente ou algumas podem ocorrer em paralelo, por exemplo, anlise e modelagem podem ser implementadas em paralelo com implementao e execuo, ao passo que outras atividades podem ser implementadas sequencialmente. Como o gerenciamento de teste fundamentalmente relacionado ao processo de teste, os gerentes de teste devem ser capazes de aplicar todo o contedo dessa seo ao gerenciamento de um projeto especfico. Para Test Analysts e Technical Test Analysts, no entanto, o conhecimento adquirido com o Nvel Fundamental grande o suficiente, com a exceo das tarefas de desenvolvimento listadas a seguir. O conhecimento necessrio para essas tarefas coberto de forma geral nessa seo, e ento aplicado em detalhe no Captulo 4 Tcnicas de Teste, e Captulo 5 Teste de Caractersticas de Software.
2.2 Modelos de Processo de Teste

Modelos de processos so aproximaes e abstraes. Os modelos de processo de teste no capturam o conjunto total de complexidades, nuances e atividades que fazem parte de qualquer projeto ou esforo reais. Modelos devem ser vistos como um auxlio para entender e organizar, no como uma imutvel verdade revelada. Enquanto este syllabus utiliza o processo descrito no ISTQB Foundations Level Syllabus (veja acima) como um exemplo, h importantes modelos de processo de teste adicionais, e trs deles so listados a seguir. Eles so todos modelos de processo de teste e modelos de melhoria de processo de teste (Practical Software Testing inclui o Modelo de Maturidade de Teste), e so definidos em termos de nveis de maturidade que eles suportam. Os trs modelos de processo de teste, juntamente com o TPI, so discutidos adiante na seo 8.3 Processo de Melhoria e Software. Practical Software Testing Test Maturity Model [Burnstein03] Critical Testing Processes [Black03] Systematic Test and Evaluation Process (STEP)
Verso 2007br
Pgina 28 de 124
02 Fev 2010
Certified Tester
2.3 Planejamento & Controle de Teste

Esta seo trata do processo de planejamento e controle de teste. A maior parte do planejamento de teste ocorre no incio do esforo de teste, e envolve a identificao e implementao de todas as atividades e recursos requeridos para corresponder misso e objetivos identificados na estratgia de teste. O teste baseado em risco (veja Captulo 3 Gerenciamento de Teste) usado para informar ao processo de planejamento de teste sobre as atividades de mitigao necessrias para reduzir os riscos de produto identificados. Por exemplo, se identificado que defeitos srios so normalmente encontrados na especificao de modelagem, o processo de planejamento de teste poderia resultar em testes estticos adicionais (revises) da especificao de modelagem antes que seja convertido em cdigo. O teste baseado em risco informar tambm ao processo de planejamento de teste em relao s prioridades relativas atividade de teste. Relacionamentos complexos podem existir entre a base de teste, condies de teste, casos de teste e procedimentos de teste, de tal forma que relacionamentos de muitos para muitos podem existir entre esses produtos de trabalho. Eles devem ser compreendidos para permitir que o planejamento e controle de teste sejam efetivamente implementados. O controle de teste uma atividade contnua. Ele envolve a comparao do progresso real mediante o plano e relato do status, incluindo desvios do plano. O controle de teste conduz o teste para satisfazer a misso, estratgias e objetivos, incluindo rever as atividades de planejamento de teste conforme necessrio. O controle de teste deve tratar das informaes geradas pelo teste, assim como das mudanas de condies nas quais um projeto ou um objetivo existe. Por exemplo, se um teste dinmico revela aglomerados de defeitos em reas que eram consideradas difceis de conter muitos defeitos, ou se o perodo de execuo do teste encurtado devido a um atraso no incio do teste, a anlise de risco e o plano devem ser revisados. Isso pode resultar em uma nova definio de prioridades de testes e realocao do esforo da execuo de teste restante. Os contedos dos documentos de planejamento de teste so tratados no captulo 3 Gerenciamento de Teste. As mtricas para monitorar o planejamento e controle de teste devem incluir: Risco e cobertura de teste Descoberta de defeito e informao Horas planejadas versus horas reais para desenvolver o testware e executar os casos de teste
2.4 Modelagem & Anlise de Teste

Durante o planejamento de teste, um conjunto de objetivos de testes ser identificado. O processo de anlise e modelagem de teste usa os seguintes objetivos para: Identificar as condies de teste Criar casos de teste que exercitem as condies de teste identificadas O critrio de priorizao identificado durante a anlise de risco e o planejamento de teste deve ser aplicado atravs do processo, da anlise e modelagem at a implementao e execuo.
Verso 2007br
Pgina 29 de 124
02 Fev 2010
Certified Tester
2.4.1 Identificao de Condies de Teste

Condies de teste so identificadas atravs da anlise da base de teste e de objetivos para determinar o que testar usando tcnicas de teste identificadas na Estratgia de Teste e/ou o Plano de Teste. A deciso de determinar o nvel e estrutura das condies de teste pode ser baseada em caractersticas funcionais e no-funcionais dos itens de teste usando o seguinte: 1. Granulosidade da base de teste: Exemplo: requisitos de alto nvel podem gerar inicialmente condies de alto nvel. Exemplo: prove que a tela X funciona, a partir da qual possvel derivar condies de teste de baixo nvel. Exemplo: prove que a tela X rejeita um nmero que um dgito menor que o comprimento correto. 2. Riscos de produtos correspondidos: Exemplo: para uma caracterstica de alto nvel de risco, condies de teste detalhadas devem ser um objetivo definido. 3. Requisitos para relatrio gerencial e rastreabilidade de informao 4. Quando a deciso for tomada para trabalhar com condies de teste somente e no desenvolver caso de teste. Por exemplo, usando condies de teste para foco de teste sem script.
2.4.2 Criao de Casos de Teste

Casos de teste so projetados por uma elaborao passo a passo e refinamento de condies de teste identificadas usando tcnicas de teste (veja Captulo 4) discriminadas na estratgia de teste. Eles podem ser repetveis, verificveis e rastreveis aos requisitos. A modelagem de caso de teste inclui a identificao de: pr-condies tais como o projeto ou os requisitos do ambiente de teste localizados e os planos para sua entrega os requisitos de dados de teste os resultados esperados e as ps-condies Um desafio particular geralmente a definio do resultado esperado de um teste; isto , a identificao de um ou mais orculos de teste que podem ser usados para o teste. Na identificao de resultados esperados, os testadores se concentram no somente nas sadas na tela, mas tambm com as ps-condies dos dados e do ambiente. Caso a base de teste esteja claramente definida, isso pode ser teoricamente simples. No entanto, bases de teste so frequentemente vagas, contraditrias, com lacunas na cobertura de reas importantes, ou completamente inexistentes. Em tais casos, o testador deve ter, ou ter acesso a, conhecimento no assunto. Tambm, mesmo quando a base de teste bem especificada, interaes complexas de estmulos e respostas podem dificultar a definio de resultados esperados, ento um orculo de teste essencial. A execuo de teste sem nenhuma forma de determinar a preciso dos resultados tem um valor adicional ou benefcios bem baixos, gerando relatrios de incidentes esprios e uma falsa confiana no sistema. As atividades descritas acima podem ser aplicadas a todos os nveis de teste, ainda que a base de teste varie. Por exemplo, testes de aceite de usurio podem ser baseados primariamente na especificao de requisitos, casos de uso e processos de negcios definidos, enquanto que testes de componentes podem ser baseados primariamente em especificaes de modelagem de baixo nvel. Durante o desenvolvimento de condies e casos de teste, comumente alguma documentao feita resultando nos produtos do trabalho de teste. Um padro para tal documentao encontrado na IEEE 829. Essa norma discute os principais tipos de documentos aplicveis anlise e modelagem de teste, Especificao de Modelagem de Teste e Especificao de Caso de Teste, assim como implementao de teste. Na prtica, a extenso de quais produtos de teste so documentados varia consideravelmente. Como exemplo, isso pode ser influenciado por:
Verso 2007br
Pgina 30 de 124
02 Fev 2010
Certified Tester
riscos de projeto (o que deve/no deve ser documentado) o valor agregado que a documentao traz ao projeto padres a serem seguidos modelo de ciclo de vida usado (por exemplo, uma abordagem gil tenta minimizar a documentao garantindo comunicao prxima e frequente da equipe) os requisitos para rastreabilidade da base de teste, atravs de anlise e modelagem de teste Dependendo do escopo do teste, a anlise e modelagem de teste podem tratar das caractersticas de qualidade para o objeto de teste. A norma ISO 9126 fornece uma referncia til. No teste de sistemas de hardware/software, caractersticas adicionais podem ser aplicadas. O processo de anlise e modelagem de teste pode ser melhorado pela interao com revises e anlise esttica. Por exemplo, realizar a anlise e modelagem de teste baseadas nas especificaes de requisitos uma forma excelente de preparao para encontros de reviso de requisitos. De modo similar, produtos de trabalho de teste como testes, anlises de riscos e planejamento de testes podem ser sujeitos reviso e anlise esttica. Durante a modelagem de teste os requisitos detalhados da infraestrutura de teste requerido podem ser definidos, apesar de que na prtica eles podem no ser finalizados at a implementao do teste. necessrio lembrar que a infraestrutura do teste inclui mais do que os objetos de teste e testware (exemplo: salas, equipamento, pessoal, software, ferramentas, perifricos, equipamento de comunicao, autorizao de usurios e outros itens necessrios para executar os testes). Mtricas para monitorar a anlise e modelagem de teste podem incluir: Porcentagem dos requisitos cobertos pelas condies de teste Porcentagem das condies de teste cobertas pelos casos de teste Nmero de defeitos encontrados durante a anlise e modelagem de teste

2.5.1 Implementao de Teste
A implementao de teste inclui a organizao dos casos de teste em procedimentos (scripts de teste), finalizando os dados e o ambiente de teste, e formando a programao da execuo de teste para viabilizar o incio da execuo dos casos de teste. Isso tambm inclui a verificao mediante critrios explcitos e implcitos de entrada para o nvel de teste em questo. Os procedimentos de teste devem ser priorizados para garantir que os objetivos identificados em uma estratgia tenham sido alcanados de uma forma eficiente, por exemplo, executando os procedimentos de teste mais importantes primeiro pode ser uma abordagem. O nvel de detalhe e a complexidade associada para o trabalho realizado durante a implementao de teste devem ser influenciados pelo detalhe dos produtos de trabalho do teste (casos e condies de teste). Em alguns casos so aplicadas regras regulamentares, e os testes devem fornecer evidncia da adequao a padres aplicveis tais como a DO-178B/ED 12B da Administrao Federal de Aviao dos Estados Unidos. Como identificado em 2.4, os dados de teste so necessrios para o teste e, em alguns casos, esses conjuntos de dados podem ser realmente grandes. Durante a implementao, os testadores criam dados de entrada e de ambiente para carregar os bancos de dados e outros repositrios. Testadores tambm criam scripts e outros geradores de dados que iro criar dados que so enviados para o sistema como carga de entrada durante a execuo do teste. Durante a implementao de teste, os testadores devem finalizar e confirmar o pedido no qual os testes manuais e automatizados devem ocorrer. Quando a automatizao contratada, a
Verso 2007br
Pgina 31 de 124
02 Fev 2010
Certified Tester
implementao de teste inclui a criao do ambiente preparado de teste e scripts de teste. Testadores devem verificar cuidadosamente as restries que podem requerer que os testes sejam realizados em uma determinada ordem. Dependncias no ambiente e nos dados de teste devem ser conhecidas e verificadas. A implementao de teste tambm se preocupa com o ambiente de teste. Durante esse estgio ele deve ser completamente iniciado e verificado antes da execuo do teste. Um ajuste do ambiente de teste essencial: o ambiente de teste deve ser capaz de permitir a exposio dos defeitos presentes nas condies de teste, operando normalmente quando falhas no ocorrem, e replicados adequadamente se requisitado, por exemplo, na produo ou no ambiente do usurio final para nveis mais altos de teste. Durante a implementao de teste, os testadores devem assegurar que os responsveis pela criao e manuteno do ambiente de teste so conhecidos e disponveis e que todo o testware e as ferramentas de suporte ao teste e processos associados esto prontos para o uso. Isso inclui o gerenciamento de configurao, gerenciamento de incidentes, e registro e gerenciamento do teste. Juntamente a isso, os testadores devem verificar os procedimentos que coletam dados para a verificao do critrio de sada e o relatrio dos resultados de teste. bom usar uma abordagem balanceada para a implementao de teste. Por exemplo, estratgias de teste analtica baseada em risco so frequentemente aliadas a estratgias dinmicas de teste. Nesse caso, alguma porcentagem do esforo da execuo de teste alocada para o teste que no segue scripts predeterminados. O teste sem script no deve ser ad hoc ou a esmo j que este pode ser imprevisvel em durao a menos que com tempo limitado (veja gerenciamento de teste baseado em seo). Os testadores tm desenvolvido uma grande variedade de tcnicas baseadas em experincia, tais como ataques (veja seo 4.4 e [Whittaker03]), suposio de erro [Myers79] e teste exploratrio. Anlise, modelagem e implementao de teste ainda ocorrem, mas elas acontecem primariamente durante a execuo do teste. Seguindo tais estratgias de teste dinmico, os resultados de cada teste influenciam a anlise, modelagem e implementao dos testes subsequentes. Ao passo que essas estratgias so leves e diversas vezes efetivas no encontro de bugs, elas necessitam de testadores experientes, podem ser imprevisveis em durao, vrias vezes no fornecem uma boa cobertura de informao, e podem ser difceis de repetir sem auxlio de ferramentas especficas para teste de regresso.
2.5.2 Execuo de Teste

A execuo de teste comea quando o objeto de teste entregue e o critrio de entrada para a execuo do teste foi satisfeita. Os testes devem ser executados de acordo com os procedimentos de teste, apesar de que algum grau de liberdade deve ser dado aos testadores para garantir a cobertura de cenrios adicionais de teste de interesse e de comportamentos que so observados durante o teste (qualquer falha detectada durante tal desvio deve descrever as variaes dos procedimentos de teste que so necessrios para reproduzir a falha). Testes automatizados seguiro suas instrues definidas sem desvios. No mago da atividade de execuo de teste est a comparao dos resultados reais com os esperados. Os testadores devem prestar a maior ateno e manter o foco nessas tarefas, seno todo o trabalho de modelagem e implementao de teste pode ser desperdiado quando falhas esto faltando (falsos positivos) ou comportamentos corretos so mal classificados como incorretos (falsos negativos). Se os resultados atuais e os esperados no se correspondem, um incidente aconteceu. Os incidentes devem ser cuidadosamente esmiuados para estabelecer a causa (que deve ou no ser um defeito no objeto de teste) e para coletar dados para auxiliar a resoluo do incidente. Gerenciamento de incidente discutido em detalhes no Captulo 7. Quando um defeito identificado, a especificao de teste deve ser cuidadosamente analisada para assegurar que correto. Uma especificao de teste pode ser incorreta por diversas razes, incluindo
Verso 2007br
Pgina 32 de 124
02 Fev 2010
Certified Tester
problemas nos dados de teste, defeitos na documentao de teste, ou um engano na forma que foi executado. Se ele no correto, ele pode ser corrigido e re-executado. A partir do momento que mudanas na base e no objeto de teste podem resultar em uma especificao incorreta mesmo depois de vrias execues de sucesso, os testadores devem se manter atentos possibilidade de que os resultados observados podem ser devidos a testes incorretos. Durante a execuo de teste, os resultados de teste devem ser registrados de forma apropriada. Os testes que foram executados e que no foram registrados devem ser repetidos para identificar o resultado correto, trazendo ineficincia e atrasos. (Note que um registro adequado pode tratar de preocupaes sobre cobertura e repetibilidade associadas com estratgias de teste dinmicas). Desde que os objetos de teste, testware e ambiente de teste podem estar todos evoluindo, o registro poder identificar as verses especficas testadas. O registro de teste fornece uma gravao cronolgica de detalhes relevantes sobre a execuo dos testes. O registro de resultados aplicado tanto para testes individuais como para eventos. Cada teste deve ser unicamente identificado e seu status registrado com a execuo do teste. Quaisquer eventos que afetem a execuo do teste devem ser registrados. Informaes suficientes devem ser registradas para medir a cobertura dos testes e documentar os motivos dos atrasos e interrupes no teste. Alm disso, informaes devem ser registradas para apoiar o controle do teste, o relato de progresso do teste, as medies de critrio de sada e a melhoria do processo de teste. O registro varia de acordo com o nvel do teste e a estratgia. Por exemplo, se um teste de componente automatizado estiver acontecendo, os testes automatizados recolhem vrias das informaes registradas. Se um teste de aceite manual estiver sendo feito, o gerente de teste pode compilar ou organizar o registro. Em alguns casos, assim como com a implementao dos testes, o registro influenciado por regulamentos ou requisitos de auditoria. A norma IEEE 829 inclui uma descrio da informao que poderia ser capturada em um registro de teste: Identificador do registro de teste Descrio Entradas de atividades e eventos
A BS-7925-2 tambm contm uma descrio da informao a ser registrada. Em alguns casos, os usurios ou clientes podem participar da execuo de teste. Isso pode servir como uma forma para construir confiana no sistema, apesar de que assume que os testes no tero grande sucesso em encontrar defeitos. Tais suposies so frequentemente invlidas em nveis de teste mais iniciais, mas podem ser vlidos durante testes de aceite. Mtricas para monitorar a implementao e execuo dos testes podem incluir: Porcentagem de ambientes de teste configurados Porcentagem de registros de dados de teste carregados Porcentagem de condies e casos de teste executados Porcentagem de casos de teste automatizados
2.6 Avaliao do Critrio de Sada e Relatrio

A documentao e relatrio para o progresso da monitorao e controle de teste so discutidos em detalhes na seo 3.6. Do ponto de vista do processo de teste, o progresso da monitorao do teste acarreta na garantia da coleta de informaes apropriadas para apoio de requisitos a serem relatados. Isso inclui medio do progresso em direo ao encerramento.
Verso 2007br
Pgina 33 de 124
02 Fev 2010
Certified Tester
As mtricas para monitorar o progresso e finalizao do teste incluiro um mapeamento do critrio de sada combinado (acertado durante o planejamento de teste), o qual pode incluir um ou todos dos seguintes itens: Nmero de condies, casos e especificaes de teste, planejados e aqueles executados e discriminados por quando eles passaram ou falharam Defeitos totais encontrados, discriminados pela severidade e prioridade para aqueles corrigidos ou pendentes Nmero de alteraes (mudanas solicitadas) promovidas, aceitas (construdas) e testadas Custos planejados versus custos reais Tempo gasto planejado versus tempo gasto real Riscos identificados discriminados por sua mitigao pela atividade de teste e qualquer um mantido pendente Porcentagem de tempo de teste perdido por eventos bloqueadores Itens retestados Tempo total de tempo planejado mediante o tempo de teste efetivamente gasto
Para um relatrio de teste a IEEE especifica um Relatrio de Resumo de Teste, consistindo das seguintes sees: Identificador de relatrio de resumo de teste Resumo Variaes Contribuio compreensiva Resumo dos resultados Avaliao Resumo das atividades Aprovaes
O relato de teste pode ocorrer aps cada nvel de teste esteja completo assim como no final de todo o esforo de teste
2.7 Atividades de Encerramento de Teste

Uma vez que a execuo do teste determinada como completa, as sadas importantes devem ser capturadas e passadas s pessoas relevantes para serem arquivadas. De forma coletiva, essas so as atividades de encerramento de teste. As atividades de encerramento de teste so separadas em quatro grupos principais: 1. Garantindo que todo o trabalho de teste foi de fato concludo. Por exemplo, todos os testes planejados deveriam ser executados ou deixados de lado deliberadamente, e todos os defeitos conhecidos deveriam ser corrigidos e realizados testes para confirmao, deferidos para uma release futura, ou aceitos com restries permanentes. 2. Entregando produtos de trabalho valiosos para aqueles que necessitam deles. Por exemplo, defeitos conhecidos deferidos ou aceitos deveriam ser comunicados para aqueles que usaro e fornecero suporte ao uso do sistema, e os testes e o ambiente de teste passados aos responsveis pelos testes de manuteno. Outro produto de teste poderia ser um pacote de teste de regresso (tanto automatizado como manual). 3. Realizando ou participando de encontros de retrospectiva (lies aprendidas) onde lies importantes (tanto em um projeto de teste como em todo um ciclo de vida de desenvolvimento de software) podem ser documentadas e planos estabelecidos para
Verso 2007br
Pgina 34 de 124
02 Fev 2010
Certified Tester
garantir que eles no se repetiro no futuro ou onde questes que no puderem ser resolvidas sejam acomodadas dentro de planos de projeto. Por exemplo: a. Devido descoberta tardia de aglomerados de defeitos no previstos, a equipe deveria ter descoberto que uma grande variedade de usurios representativos deveria participar nas sees de anlise de risco de qualidade em futuros projetos. b. Estimativas reais devem ter sido significativamente subjugadas e, portanto, atividades futuras de estimativa precisaro contar com isso juntamente com os motivos por trs deles; por exemplo, o teste foi ineficiente ou a estimativa foi aqum do que deveria ter sido. c. Tendncias e anlises de causa e efeito de defeitos, atravs do seu relacionamento com o porqu e quando elas ocorreram e procurando por alguma tendncia (por exemplo, quando uma requisio de mudana tardia afeta a qualidade da anlise e desenvolvimento), ou procurando por ms prticas (por exemplo, deixando de lado um nvel de teste, o qual poderia encontrar defeitos mais cedo e de forma menos custosa, para uma economia de tempo). Tambm, relacionando tendncias de defeitos a reas como novas tecnologias, mudanas de pessoal, ou falta de capacidades. d. Identificao de oportunidades de melhorias de processo em potencial. 4. Arquivando resultados, registros, relatrios, e outros documentos e produtos de trabalho no sistema de gerenciamento de configurao, relacionado ao sistema. Por exemplo, o plano de teste e plano de projeto podem ser armazenados em um arquivo de planejamento, com uma ligao clara com o sistema e a verso na qual foram usados. Essas tarefas so importantes, frequentemente dispensadas e deveriam ser includas explicitamente como parte em um plano de teste. comum uma ou mais dessas tarefas serem omitidas, normalmente devido dissoluo prematura da equipe, presses de recursos ou planejamento em projetos subsequentes, ou fadiga da equipe. Em projetos conduzidos sob contrato, tal qual um desenvolvimento customizado, o contrato deveria especificar as tarefas requeridas. Mtricas para monitorar as atividades de encerramento de teste poderiam incluir: Porcentagem de casos de teste executados durante uma execuo de teste (cobertura) Porcentagem de casos de teste verificados em um repositrio de casos reutilizveis de teste Razo dos casos de teste automatizados a serem automatizados Porcentagem de casos de teste identificados para testes de regresso Porcentagem de relatrios de defeitos pendentes fechados (por exemplo, deferidos, sem nenhuma prxima ao, com pedido de mudana, etc.) Porcentagem de produtos de trabalho identificados e arquivados.
Verso 2007br
Pgina 35 de 124
02 Fev 2010
Certified Tester
3. Gerenciamento de Teste
Termos:
FMEA, nvel de planejamento de teste, plano mestre de teste, risco de produto, risco de projeto , teste baseado em risco, anlise de risco, identificao de risco, nvel de risco, gerenciamento de risco, mitigao de risco, tipo de risco, controle de teste, gerenciamento de teste baseado em seo, estimativa de teste, nvel de teste, gerenciamento de teste, monitorao de teste, plano de teste, poltica de teste, anlise de pontos de teste, programao de teste, estratgia de teste, wide band delphi.
3.1 Introduo
Este Captulo cobre reas de conhecimento necessrias especialmente para Test Manager.
3.2 Documentao de Gerenciamento de Teste

Documentao frequentemente produzida como parte de um gerenciamento de teste. Enquanto os nomes especficos e escopo dos documentos de gerenciamento de teste tendem a variar, os seguintes tipos so documentos comuns de serem encontrados em organizaes e projetos: Poltica de teste, a qual descreve a filosofia da organizao em relao ao teste (e possivelmente quanto garantia de qualidade). Estratgia de teste (ou handbook de teste), a qual descreve os mtodos de teste da organizao, incluindo gerenciamento de risco de produto e projeto, a diviso do teste em passos, nveis, ou fases, e as atividades de alto nvel associadas com o teste. Plano mestre de teste (ou plano de projeto de teste, ou abordagem de teste), o qual descreve a aplicao da estratgia de teste para um projeto em particular, incluindo os nveis particulares a serem considerados e o relacionamento entre esses nveis. Plano de nvel de teste (ou plano de fase de teste), o qual descreve as atividades particulares a serem consideradas em cada nvel de teste, incluindo a expanso no plano mestre de teste para o nvel especfico sendo documentado. Em algumas organizaes e em alguns projetos, esses tipos de documento podem ser combinados em um s documento, o contedo desses de documento podem ser encontrados em outros documentos, e alguns dos contedos podem ser considerados como intuitivos, no escritos, ou como metodologias tradicionais para teste. Organizaes e projetos maiores e mais formais tendem a apresentar todos esses tipos de documentos como produtos de trabalhos escritos, enquanto que organizaes e projetos menores e menos formais tendem a apresentar poucos desses produtos de trabalho escritos. Este syllabus descreve cada um desses tipos de documento separadamente, apesar de que na prtica o contexto organizacional e de projeto determina o uso correto de cada tipo.
3.2.1 Poltica de Teste

A poltica de teste descreve a filosofia da organizao em relao ao teste (e possivelmente quanto garantia de qualidade). Ela estabelecida, tanto com a sua redao como pelo direcionamento da gerncia, dispondo os objetivos gerais sobre o teste que a organizao pretende alcanar. Essa poltica pode ser desenvolvida pelo departamento de Tecnologia da Informao, Pesquisa e Desenvolvimento, ou Desenvolvimento de Produto, mas deve refletir os valores e objetivos organizacionais que se relacionam ao teste.
Verso 2007br
Pgina 36 de 124
02 Fev 2010
Certified Tester
Em alguns casos, a poltica de teste ser complementar ou um prprio componente de uma poltica de qualidade maior. Essa poltica de qualidade descreve os valores e objetivos gerais do gerenciamento relacionado qualidade. Quando existe uma poltica de teste escrita, ela pode ser um documento curto e de alto nvel que: Fornece uma definio de teste, tal como construir a confiana que o sistema funciona como intencionado e detectar defeitos. Estabelece um processo fundamental de teste, por exemplo, planejamento e controle de teste, anlise e modelagem de teste, implementao e execuo de teste, avaliao do critrio de sada e relatrio de teste, e, atividades de encerramento de teste. Descreve como avaliar a efetividade e eficincia do teste, por exemplo, a porcentagem dos defeitos a serem detectados (Porcentagem de Deteco de Defeito DDP ou Defect Detection Percentage) e o custo relativo de defeitos detectados no teste como oposio aos detectados aps a liberao. Define os objetivos de qualidade desejados, tais como confiabilidade (por exemplo, medido em termos de taxa de falha) ou usabilidade. Especifica atividades para a melhoria do processo de teste, por exemplo, aplicao do Modelo de Maturidade de Teste ou Modelo de Melhoria de Processo de Teste, ou implementao de recomendaes de retrospectivas de projetos. A poltica de teste pode tratar das atividades de teste para novos desenvolvimentos assim como para manuteno. Ela pode tambm ser um padro de referncia para a terminologia de teste a ser usada por toda a organizao.
3.2.2 Estratgia de Teste

A estratgia de teste descreve os mtodos de teste da organizao, incluindo gerenciamento de risco de produto e de projeto, a diviso do teste em passos, nveis, ou fases, e as atividades de alto nvel associadas com o teste. A estratgia de teste e o processo e atividades descritas nela, devem ser consistentes com a poltica de teste. necessrio fornecer os requisitos genricos de teste para a organizao ou para um ou mais projetos. Como descrito no Foundation Syllabus, as estratgias de teste (tambm chamadas de abordagens de teste) podem ser classificadas baseadas em quando a modelagem de teste inicia: Estratgias preventivas, que modelam os testes mais cedo para prevenir defeitos Estratgias reativas, nas quais a modelagem do teste vem depois do software ou sistema estar em produo Estratgias tpicas (ou abordagens) incluem: Estratgias analticas, tais como o teste baseado em risco Estratgias baseadas em modelo, tais como perfil operacional Estratgias metodolgicas, tais como as baseadas em caractersticas de qualidade Estratgias compatveis com processos ou padres, tais como as baseadas na IEEE 829 Estratgias dinmicas e heursticas, tais como as que utilizam ataques baseados em bugs Estratgias baseadas em conselho, tais como o teste direcionado pelo usurio Estratgia de teste de regresso, tais como automatizao extensiva Diferentes estratgias podem ser combinadas. A estratgia especfica selecionada deveria ser apropriada para as necessidades e propsitos da organizao, e as organizaes podem adaptar as estratgias para ajustar s operaes e aos projetos particulares. Em vrias instncias, uma estratgia de teste explica os riscos de projeto e produto e descreve como o processo de teste gerencia esses riscos. Em tais casos, a conexo entre riscos e teste deve ser explicada explicitamente, assim como as opes para reduzir e gerenciar esses riscos.
Verso 2007br
Pgina 37 de 124
02 Fev 2010
Certified Tester
A estratgia de teste pode ser descrita pelos nveis de teste que sero realizados. Em tais casos, poderia ser dada uma orientao em alto nvel no critrio de entrada e critrio de sada para cada nvel e as relaes entre os nveis (por exemplo, diviso dos objetivos de cobertura de teste). A estratgia de teste tambm pode descrever: Procedimentos de integrao Tcnicas de especificao de teste Independncia do teste (o qual pode variar dependendo do nvel) Normas mandatrias e opcionais Ambiente de teste Automatizao de teste Reutilizao dos produtos de trabalho de software e dos produtos de trabalho de teste Reteste e teste de regresso Controle e reporte de teste Medies e mtricas de teste Gerenciamento de incidente Abordagem de gerenciamento de configurao do testware Tanto estratgias de longa como de curta durao deveriam ser definidas. Isso pode ser feito em um ou mais documentos. Diferentes estratgias de teste so adequadas a diferentes organizaes e projetos. Por exemplo, quando aplicaes de segurana e segurana de acesso crticas esto envolvidas, uma estratgia mais intensiva pode ser mais apropriada do que em outros casos.
3.2.3 Plano Mestre de Teste

O plano mestre de teste descreve a aplicao da estratgia de teste para um projeto em particular, incluindo os nveis particulares a serem considerados e o relacionamento entre esses nveis. O plano mestre de teste deveria ser consistente com a poltica e estratgia de teste e, em reas especficas onde no , deveria explicar os desvios e excees. O plano mestre de teste deveria complementar o plano de projeto ou orientaes de operaes nos quais ele poderia descrever o esforo de teste que parte de um projeto ou de operaes maiores. Enquanto que o contedo e estrutura especficos de um plano mestre de teste variam dependendo da organizao, seus padres de documentao e a formalidade do projeto, tpicos tpicos para um plano mestre de teste inclui: Itens a serem ou no testados Atributos de qualidade a serem ou no testados Cronograma e oramento do teste (o qual poderia estar alinhado com o oramento operacional ou do projeto) Ciclos de execuo de teste e seu relacionamento como plano de liberao do software Justificativa de negcio e o valor do teste Relaes e entregveis entre o teste e outras pessoas ou departamentos Definio de quais itens de teste esto no escopo e quais esto fora para cada nvel descrito Critrio de entrada especfico, critrio de continuao (suspenso/retomada), e critrio de sada para cada nvel e o relacionamento entre os nveis Risco do projeto de teste Em projetos ou operaes menores, onde somente um nvel de teste formalizado, o plano mestre de teste e o plano de teste para aquele nvel formalizado frequentemente se combinaro em um s documento. Por exemplo, se um teste de sistema o nico nvel formalizado, com os testes de componente e integrao informais realizados por desenvolvedores e um teste informal de aceite realizado por clientes como parte de um processo de teste beta, ento o plano de teste de sistema deve incluir os elementos mencionados nessa seo.
Verso 2007br
Pgina 38 de 124
02 Fev 2010
Certified Tester
Alm disso, o teste depende tipicamente de outras atividades no projeto. Essas atividades podem no ser suficientemente documentadas, particularmente em termos de sua influncia e relacionamento com o teste, e tpicos relacionados com aquelas atividades podem ser cobertos por um plano mestre de teste (ou em um plano de teste em um nvel apropriado). Por exemplo, se o processo de gerenciamento de configurao no documentado, o plano de teste deveria especificar como os objetos de teste sero liberados para a equipe de teste.
3.2.4 Plano de Nvel de Teste

O plano de nvel de teste descreve as atividades particulares a serem consideradas em cada nvel de teste, incluindo a expanso no plano mestre de teste para o nvel especfico sendo documentado. Ele fornece detalhes de cronograma, tarefa e marcos no cobertos necessariamente no plano mestre de teste. Alm disso, o alcance que diferentes normas e modelos aplicam especificao de testes em diferentes nveis, esses detalhes devem ser cobertos no plano de nvel de teste. Em projetos ou operaes menos formais, um s nvel de plano de teste frequentemente o nico documento de gerenciamento de teste que escrito. Em tais situaes, alguns dos elementos de informao mencionados nas sees 3.2.1, 3.2.2 e 3.2.3 poderiam ser cobertos nesse documento.
3.3 Modelos de Documentao do Plano de Teste

Assim como mencionado na seo 3.2, o contedo especfico e estrutura do plano mestre de teste variam dependendo da organizao, dos seus padres de documentao e da formalidade do projeto. Muitas organizaes desenvolvem e adaptam modelos para garantir padronizao e legibilidade entre os projetos e operaes, e os modelos esto disponveis para a documentao do plano de teste. A IEEE 829 Norma para Documentao de Teste de Software contm modelos de documentao de teste e orientaes para sua aplicao, incluindo a preparao dos planos de teste. Ela tambm apresenta o tpico relacionado de transmisso de item de teste (ou seja, a liberao dos itens de teste ao teste).
3.4 Estimativa de Teste

A estimativa, como uma atividade de gerenciamento, a criao de um objetivo aproximado para custos e datas de finalizao associadas com as atividades envolvidas em uma operao ou projeto em particular. As melhores estimativas: Representam uma viso coletiva de pessoas experientes e apresentam suporte para os participantes envolvidos Fornecem catlogos especficos e detalhados de custos, recursos, tarefas e pessoas envolvidas Apresentam, para cada atividade estimada, os custos, esforos e durao mais provveis Estimativa de software e engenharia de sistema tm sido conhecidas como repletas de dificuldades, tanto tcnicas quanto polticas, embora as melhores prticas de gerenciamento de projeto para estimativa sejam bem estabelecidas. Estimativa de teste a aplicao dessas melhores prticas para as atividades de teste associadas com um projeto ou operao. A estimativa de teste deve incluir todas as atividades envolvidas no processo de teste, isto , planejamento e controle de teste, anlise e modelagem de teste, implementao e execuo de teste, avaliao e relatrio de teste, e atividades de encerramento de teste. O custo, esforo, e, especialmente, a durao da execuo de teste estimado so frequentemente de grande interesse gerncia, assim como a execuo do teste tipicamente um caminho crtico do projeto. No entanto, a estimativa da execuo do teste tende a ser difcil de gerar e no realista quando a qualidade geral
Verso 2007br
Pgina 39 de 124
02 Fev 2010
Certified Tester
do software baixa ou desconhecida. Uma prtica comum tambm estimar o nmero de casos de teste requeridos. Suposies feitas durante a estimativa devem ser sempre documentadas como parte da estimativa. A estimativa de teste deve considerar todos os fatores que influenciam o custo, esforo e durao das atividades de teste. Esses fatores incluem (mas no so limitados a) o seguinte: Nvel de qualidade requerido para o sistema Tamanho do sistema a ser testado Dados histricos de projetos de teste anteriores (isso pode incluir tambm dados de benchmark) Fatores de processo, incluindo: desenvolvimento de estratgia de teste ou manuteno do ciclo de vida e maturidade do processo; e a preciso da estimativa do projeto Fatores materiais, incluindo: automatizao de teste e ferramentas, ambiente de teste, dados de teste, ambiente(s) de desenvolvimento; documentao de projeto (por exemplo, requisitos, modelos, etc.) e produtos de trabalho de teste reutilizveis Fatores pessoais, incluindo: gerentes e lderes tcnicos; acordo e expectativa do gerenciamento executivo e snior; competncias, experincias e atitudes da equipe do projeto; estabilidade da equipe de projeto; relacionamento da equipe de projeto; suporte ao ambiente de teste de depurao; disponibilidade de contratante e consultores capacitados e conhecimento do domnio. Outros fatores que podem influenciar a estimativa de teste incluem a complexidade do processo, tecnologia, organizao, nmero de stakeholders relacionados ao teste, muitas subequipes, especialmente geograficamente separadas; necessidade significativas de crescimento, treinamento e orientao; assimilao ou desenvolvimento de novas ferramentas, tcnicas, hardware customizado, nmero de testware; requisitos para um alto nvel de detalhamento de especificao de teste, especialmente para norma de documentao no familiar; temporizao complexa de chegada de componentes, especialmente para teste de integrao e desenvolvimento de teste; e, dados de teste frgeis (por exemplo, dado que sensvel hora). A estimativa pode ser realizada tanto bottom-up ou top-down. As seguintes tcnicas podem ser usadas na estimativa de teste: Intuio e suposio Experincia passada Work-breakdown-structures (WBS) Sees de estimativa de equipe (por exemplo, Wide Band Delphi) Estimativa de trs pontos Anlise de ponto de teste (Test Point Analysis (TPA) [Pol02]) Padres e normas da empresa Porcentagens do esforo geral do projeto ou nveis de funcionrios (por exemplo, razo entre testadores e desenvolvedores) Histrico e mtricas organizacionais, incluindo modelos derivados de mtricas que estimam o nmero de defeitos, o nmero de ciclos de teste, o nmero de casos de teste, mdia de cada esforo do teste e o nmero de ciclos de regresso envolvidos Mdias da indstria e modelos preditivos tais como pontos de teste, pontos de funo, linhas de cdigo, esforo estimado do desenvolvedor ou outros parmetros do projeto Em muitos casos, a estimativa, uma vez preparada, deve ser entregue gerncia, com uma justificativa (veja seo 3.7). Frequentemente, algumas negociaes seguem, resultando em retrabalho da estimativa. Idealmente, a estimativa final de teste representa o melhor possvel o balano da organizao e objetivos do projeto em reas de qualidade, programao, oramento e caractersticas.
Verso 2007br
Pgina 40 de 124
02 Fev 2010
Certified Tester
3.5 Planejamento da Programao de Teste

Em geral, o planejamento antecipado de qualquer conjunto de atividades permite a descoberta e o gerenciamento de riscos daquelas atividades, a coordenao cuidadosa e temporizada com outros envolvidos, e um plano de alta qualidade. O mesmo verdade para o planejamento de teste. No entanto, no caso do planejamento de teste, benefcios adicionais resultam de um planejamento avanado baseado na estimativa de teste, incluindo: Deteco e gerenciamento de riscos de projeto e problemas fora do escopo do teste Deteco e gerenciamento de riscos de produto (qualidade) e problemas anteriores execuo de teste Reconhecimento de problemas no plano de projeto ou outros produtos de trabalho do projeto Oportunidades de aumento de funcionrios de teste alocados, oramento, esforo e/ou durao para alcanar maior qualidade Identificao de componentes crticos (e tambm a oportunidade de acelerar a entrega daqueles componentes) A programao do teste deve ser realizada em cooperao prxima com o desenvolvimento, devido ao fato de o teste ser fortemente dependente da programao do desenvolvimento (entrega). Desde que, no momento em que toda a informao necessria para completar o plano de teste chegue a capacidade de capitalizar esse benefcio potencial pode ter sido perdida, os planos de teste devem ser desenvolvidos e editados em um formato de rascunho o mais cedo possvel. Com a chegada de novas informaes, o autor do plano de teste (tipicamente um gerente de teste), pode adicionar essa informao ao plano. Essa abordagem iterativa criao do plano de teste, liberao e reviso permite que o plano(s) de teste sirva como um veculo promotor de consenso, comunicao e discusso sobre teste.
3.6 Monitorao e Controle do Progresso do Teste

H cinco dimenses primrias sob as quais o progresso de teste monitorado: Riscos de produto Defeitos Testes Cobertura Confiana Riscos de produto, incidentes, testes e cobertura podem ser, e frequentemente o so, medidas e reportadas em formas especficas durante o projeto ou operao. Preferencialmente, essas medies so relatadas para definir critrio de sada como estabelecido no plano de teste. Confiana, apesar de que mensurvel atravs de exames, comumente relatada de forma subjetiva. Mtricas relacionadas a risco de produto incluem: Nmero de riscos remanescentes (incluindo tipo e nvel de riscos) Nmero de riscos mitigados (incluindo tipo e nvel de riscos) Mtricas relacionadas a defeitos incluem: Nmero cumulativo relatado (identificado) versus o nmero cumulativo resolvido (finalizado) Tempo mdio entre falhas ou razo de chegada de falha Decomposio do nmero de defeitos associados a: itens ou componentes de teste em particular; causas razes, fontes; liberaes de teste; fase que foi introduzido, detectado ou removido; e, em alguns casos, o proprietrio Tendncias de atraso no tempo desde o reporte do defeito at a resoluo Mtricas relacionadas a testes incluem:
Verso 2007br
Pgina 41 de 124
02 Fev 2010
Certified Tester
Nmero total planejado, especificado (desenvolvido), executado, passado, falhado, bloqueado e passados por cima Estado dos testes de regresso e confirmao Horas de teste planejados por dia versus horas realmente alcanadas Mtricas relacionadas cobertura de teste incluem: Cobertura de requisitos e elementos de modelagem Cobertura de risco Cobertura de ambiente/configurao Essas mtricas podem ser relatadas verbalmente em uma forma narrativa, numericamente em tabelas, ou pictoricamente em grficos, e podem ser usadas para diversos propsitos, incluindo: Anlise, para descobrir o que est acontecendo com o produto, projeto, ou processo atravs dos resultados de teste Reporte, para comunicar as descobertas do teste para os participantes e stakeholders do projeto Controle, para mudar o curso do teste ou do projeto como um todo e para monitorar os resultados de tal correo de curso Formas apropriadas de reunir, analisar e reportar as medidas de teste dependem de necessidades especficas de informao, objetivos e competncias das pessoas que utilizaro aquelas medies. Quando forem usados os resultados do teste para influenciar ou medir o esforo de controle no projeto, as seguintes opes devem ser consideradas: Revisar a anlise de risco de qualidade, prioridades de teste, e/ou planos de teste Adicionar recursos ou aumentar de outra maneira o esforo de teste Dilatar a data de liberao Relaxar ou reforar os critrios de sada de teste Implementar tais opes requer tipicamente consenso entre os stakeholders do projeto ou operao e consentimento pelos gerentes do projeto ou operao. A forma com a qual um relatrio de teste elaborado depende largamente do pblico alvo, por exemplo, a gerncia do projeto ou a gerncia de negcios. Para um gerente de projeto, obter informao detalhada dos defeitos de interesse; para o gerente de negcios, o status dos riscos de produto poderia ser o objetivo central no relatrio. A IEEE 829 Padro para Documentao de Teste de Software fornece um modelo para relatar informao de resumo de teste. Baseado na divergncia do plano de teste como estabelecido no relatrio do progresso do teste, o controle de teste deveria ser realizado. O controle de teste destinado a minimizar a divergncia do plano de teste. Medidas possveis de controle incluem: Rever a prioridade dos casos de teste Obter recursos adicionais Estender a data de liberao Alterar o escopo (funcionalidade) do projeto Rever o critrio de encerramento de teste (somente com a aprovao dos stakeholders)
3.7 Valor de Negcio do Teste

Enquanto que muitas empresas consideram o teste valioso em algum sentido, poucos gerentes, incluindo gerentes de teste, podem quantificar, descrever, ou articular sobre esse valor do teste. Alm disso, muitos gerentes de teste, lderes de teste e testadores mantm o foco em detalhes tticos do teste (aspectos especficos da tarefa ou nvel), enquanto ignoram objetivos estratgicos maiores (de
Verso 2007br
Pgina 42 de 124
02 Fev 2010
Certified Tester
mais alto nvel) relacionados ao teste que outros participantes do projeto, especialmente gerentes, se importam. O teste retorna valor organizao, projeto, e/ou operao tanto de forma quantitativa quanto qualitativa: Valores quantitativos incluem encontrar defeitos que so prevenidos ou corrigidos antes da liberao, encontrar defeitos que so conhecidos antes da liberao, reduzir riscos com a execuo de testes, e entregar informaes do estado do projeto, processo ou produto. Valores qualitativos incluem melhoria da reputao para qualidade, liberaes mais suaves e previsveis, aumento da confiana, construo de confiana, proteo a obedincias legais e reduo de risco de perdas de misses inteiras ou inclusive vidas. Gerentes de teste e lderes de teste devem entender quais desses valores se aplicam para suas empresas, projeto, e/ou operao, e serem capazes de comunicar o teste em termos desses valores. Um mtodo bem estabelecido para medir o valor quantitativo e a eficincia do teste chamado de custo de qualidade (ou, s vezes, custo de qualidade baixa). Custo de qualidade envolve classificar custos de projeto ou operacional em quatro categorias: Custos de preveno Custos de deteco Custos de falha interna Custos de falha externa Uma poro do oramento do teste um custo de deteco, enquanto que o restante custo de falha interna. Os custos totais de deteco e falha interna so tipicamente abaixo dos custos de falha externa, os quais tornam o teste muito valioso. Determinando o custo nessas quatro categorias, os gerentes de teste e lderes de teste podem criar um caso de negcio de teste convincente.
3.8 Teste Distribudo, Outsourced & Insourced

Em muitos casos, nem todo o esforo de teste realizado por uma s equipe de teste, composto por funcionrios membros da equipe do projeto, na mesma e nica localizao que todo o restante da equipe do projeto. Caso o esforo de teste ocorra em mltiplas localizaes, esse esforo de teste pode ser chamado de distribudo. Se o esforo de teste realizado em uma ou mais localizaes por pessoas que no so funcionrios membros do resto da equipe de projeto e os quais no esto coalocados com a equipe do projeto, esse esforo de teste pode ser chamado de outsourced. Caso o esforo de teste seja realizado por pessoas que esto coalocadas com a equipe de projeto, mas por pessoas que no so funcionrios membros da equipe, ento o esforo de teste pode ser chamado de insourced. Comum em todos os tipos de esforos de teste a necessidade de canais abertos de comunicao e expectativas bem definidas das misses, tarefas e entregveis. A equipe de projeto deve confiar menos em canais de comunicao informais como conversas de corredor e outras atividades sociais em conjunto. Localizao, fuso horrio, diferenas culturais e de idioma tornam essas questes ainda mais crticas. Tambm comum para tais tipos de esforos de teste a necessidade de alinhamento de metodologias. Se dois grupos de teste usam metodologias diferentes ou se o grupo de teste usa uma metodologia ou gerncia de projetos diferente do que o desenvolvimento, isso resultar em problemas significativos, especialmente durante a execuo do teste. Para o teste distribudo, a diviso do trabalho de teste entre as mltiplas localizaes deve ser decidida de forma explcita e inteligente. Sem tal orientao, nem o grupo mais competente no ser capaz de realizar o trabalho de teste de acordo com sua alta qualificao. Alm do mais, o trabalho de teste como um todo sofrer com as lacunas (as quais aumentam o risco residual de qualidade na entrega) e a sobreposio (a qual reduz a eficincia).
Verso 2007br
Pgina 43 de 124
02 Fev 2010
Certified Tester
Finalmente, para tais esforos de teste, crtico que toda a equipe do projeto desenvolva e mantenha a certeza que cada uma das equipes de teste realizar suas obrigaes apropriadamente, apesar dos limites organizacionais, culturais, de idioma e geogrficos. A falta de certeza conduz a ineficincias e atrasos associados com atividades de verificao, diviso de responsabilidades dos problemas e uso de polticas organizacionais.
3.9 Teste Baseado em Risco

3.9.1 Introduo ao Teste Baseado em Risco
Risco a possibilidade de acontecer algo indesejvel. Os riscos existem sempre que algum problema que pode acontecer diminuir a percepo do cliente, usurio, participante, ou stakeholder na qualidade do produto e no sucesso do projeto. Quando o efeito primrio do problema em potencial na qualidade do produto, esses problemas potenciais so chamados de riscos de produto (ou riscos de qualidade). Exemplos incluem um possvel defeito (bug) afetando a confiabilidade que poderia causar uma queda do sistema durante uma operao normal. Quando o efeito primrio reside no sucesso do projeto, esse problema potencial chamado de risco do projeto (ou risco de planejamento). Exemplos incluem possvel falta de funcionrios que poderia atrasar a finalizao de um projeto. Nem todos os riscos apresentam a mesma preocupao. O nvel de risco influenciado por diferentes fatores: a probabilidade do problema acontecer o impacto do problema se ele acontecer No teste baseado em risco, o teste conduzido de forma que ele responde aos riscos de trs formas: A alocao do esforo de teste, seleo de tcnicas, ordem das atividades de teste e reparao de defeitos (bugs) devem ser feitos de forma que seja apropriado ao nvel de risco associado a cada risco significativo do produto (qualidade) identificado. Planejando e gerenciando o trabalho de teste de forma a fornecer mitigao e contingncia de respostas para cada risco significativo de projeto (planejamento) identificado. Relatando os resultados de teste e o estado do projeto em termos de riscos residuais; por exemplo, baseado em testes que ainda no foram executados ou foram deixados de lado, ou defeitos que ainda no foram corrigidos ou retestados. Esses trs tipos de repostas ao risco deveriam acontecer atravs de todo o ciclo de vida, no simplesmente no incio e no final do projeto. Especificamente, durante o projeto, os testadores devem procurar pelo seguinte: Reduzir o risco encontrando os defeitos mais importantes (para riscos de produto) e por colocar em ao atividades apropriadas de mitigao e contingncia descritas na estratgia e no plano de teste. Fazer uma avaliao do risco, aumentando ou diminuindo a probabilidade ou impacto dos riscos previamente identificados e analisados, baseado em informaes adicionais colhidas com o desenvolvimento do projeto. Em ambos os casos, as aes tomadas influenciam como o teste responde ao risco. Teste baseado em risco pode se visto como anlogo a um seguro de diversas maneiras. Algumas pessoas contratam seguros quando esto preocupados com algum risco potencial, e alguns ignoram os riscos ou no esto preocupados com eles. A anlise quantitativa similar avaliao de risco de um corretor ou outro profissional da seguradora tambm pode ser aplicvel, mas o teste baseado em risco tipicamente fia-se em anlises qualitativas.
Verso 2007br
Pgina 44 de 124
02 Fev 2010
Certified Tester
Para ser capaz de conduzir apropriadamente um teste baseado em risco, os testadores devem ser capazes de identificar, analisar e mitigar riscos tpicos de produto e projeto relacionados segurana, negcios ou preocupaes econmicas, segurana de sistema e de dados, e fatores tcnicos e polticos.
3.9.2 Gerenciamento de Risco

O gerenciamento de risco pode ser pensado como consistindo de trs atividades primrias: 1. Identificao de risco 2. Anlise de risco 3. Mitigao de risco (tambm referida como controle de risco) Essas atividades so de alguma forma sequenciais, mas as necessidades de gerenciamento contnuo dos riscos mencionadas nas sees anteriores e nas posteriores significam que, durante a maior parte do projeto, todos os trs tipos de atividades de gerenciamento de risco deveriam ser usados iterativamente. Para ser mais efetivo, o gerenciamento de risco inclui todos os stakeholder no projeto, apesar de que algumas vezes a realidade do projeto resulta na atuao de alguns stakeholders como representantes de outros stakeholders. Por exemplo, em um desenvolvimento de software de massa, uma pequena amostra dos clientes potenciais deve ser chamada para auxiliar na identificao de defeitos em potencial que poderiam impactar mais fortemente no seu uso do software; nesse caso, a amostra de clientes potenciais serve como um representante da base total de possveis clientes. Devido ao seu conhecimento especfico, os analistas de teste devem ser envolvidos ativamente na identificao de risco e processo de anlise. 3.9.2.1 Identificao de Risco Tanto para risco de produto quanto de projeto, os testadores podem identificar os riscos atravs de uma ou mais das seguintes tcnicas: Entrevistas com especialistas Contribuies independentes Uso de modelos de risco Lies aprendidas (por exemplo, sees de avaliao de projeto) Workshops de risco (por exemplo, FMEA) Brainstorming Listas de checagem (checklists) Uso de experincia prvia Com a invocao de uma amostra de stakeholders o mais ampla possvel, o processo de identificao de risco mais capaz de detectar um maior nmero de riscos significativos. Em algumas abordagens de identificao de risco, o processo pra na identificao do risco propriamente dito. Certas tcnicas, tal como FMEA, requerem que para cada modo de falha em potencial seja realizada a identificao dos efeitos do modo de falha no resto do sistema (incluindo sistemas de mais alto nvel no caso de Sistemas de Sistemas) e aos potenciais usurios do sistema. Outras tcnicas, tais como Anlise de Ameaas (Hazard Analysis), requerem uma antecipao da fonte do risco. Para uma descrio do uso do Efeito de Modo de Falha, Modo de Falha e Anlise de Efeito e Anlise da Criticidade veja as sees 3.10 e [Stamatis95], [Black02], [Craig02], [Gerrard02].
Verso 2007br
Pgina 45 de 124
02 Fev 2010
Certified Tester
3.9.2.2 Anlise de Risco Enquanto a identificao de risco relativa identificao de tantos riscos pertinentes quanto possvel, a anlise de risco o estudo desses riscos identificados. Especificamente, categorizando cada risco e determinando a probabilidade e impacto associado a cada risco. Categorizar um risco significa colocar cada risco em uma tipificao apropriada. Tipos de risco de qualidade clssicos so discutidos na norma ISO 9126 de caractersticas de qualidade para classificar riscos. Algumas empresas tm seu prprio conjunto de caractersticas de qualidade. Note que, quando so usadas listas de checagem como uma base para identificao de risco, a seleo do tipo do risco frequentemente ocorre durante a identificao. Determinar o nvel do risco tipicamente envolve a estimativa para cada item de risco, a probabilidade de ocorrncia e o impacto na ocorrncia. A probabilidade da ocorrncia frequentemente interpretada como a probabilidade daquele problema potencial poder existir no sistema sob teste. Em outras palavras, ele origina-se de risco tcnico. Fatores que influenciam os riscos tcnicos incluem: Complexidade da tecnologia e das equipes Questes pessoais e de treinamento para os analistas de negcios, designers e programadores Conflitos internos na equipe Problemas contratuais com fornecedores Distribuio geogrfica da empresa de desenvolvimento Abordagens legadas vs novas Ferramentas e tecnologia M liderana gerencial ou tcnica Presses de tempo, recurso e gerncia Falta de garantia de qualidade anterior Alta taxa de mudanas Alta taxa de defeitos anteriores Questes de interface e integrao O impacto da ocorrncia frequentemente interpretado como a severidade dos efeitos nos usurios, nos clientes, ou em outros stakeholders. Em outras palavras, ele origina-se de risco de negcio. Fatores que influenciam os riscos de negcio incluem: Frequncia do uso da funcionalidade afetada Prejuzo imagem Perda de negcios Potenciais perdas ou encargos financeiros, ecolgicos ou sociais Sanes legais cveis ou criminais Perdas de licenas Falta de workarounds razoveis Visibilidade da falha conduzindo a uma publicidade negativa Testadores podem usar a abordagem de estabelecer um nvel de risco tanto quantitativa quando qualitativamente. Caso a probabilidade e o impacto possam ser apurados quantitativamente, possvel multiplicar os dois valores para o custo da exposio. Essa a perda esperada associada ao risco particular. Tipicamente, entretanto, o nvel de risco somente pode ser apurado qualitativamente. Ou seja, possvel falar da probabilidade como sendo muito alta, alta, mdia, baixa, ou muito baixa, mas no possvel dizer com certeza se a probabilidade 90%, 75%, 50%, 25%, ou 10%. Essa abordagem qualitativa no deve ser vista como inferior a abordagens quantitativas; de fato, quando abordagens quantitativas so usadas de forma inapropriada, elas enganam os stakeholders a respeito do alcance que se aplica realmente e que pode gerenciar o risco. Abordagens informais tais como aquelas
Verso 2007br
Pgina 46 de 124
02 Fev 2010
Certified Tester
descritas em [vanVeenendaal02], [Craig02] e [Black07b] so frequentemente qualitativas e menos rigorosas. A menos que a anlise de risco seja baseada em dados de risco extensivos e estatisticamente vlidos (assim como no caso da indstria de seguros), e indiferentemente se a anlise de risco qualitativa ou quantitativa, a anlise de risco ser baseada na percepo da probabilidade e impacto. Isso significa que percepes pessoais e opinies sobre esses fatores influenciaro o nvel de risco determinado. Gerentes de projeto, programadores, usurios, analistas de negcios, arquitetos e testadores comumente tero diferentes percepes, e, portanto, possivelmente diferentes opinies sobre o nvel de risco de cada item de risco. O processo de anlise de risco deveria incluir alguma forma de alcanar um consenso, ou, no pior caso, estabelecer atravs da imposio um acordo sobre o nvel de risco. De outra forma, os nveis de risco no podem ser usados como guias para as atividades de mitigao de risco. 3.9.2.3 Mitigao de Risco Uma vez que um risco tenha sido identificado e analisado, existem quatro principais possibilidades de tratar aquele risco: 1. Minimizar o risco atravs de medidas preventivas para reduzir a probabilidade e/ou impacto. 2. Fazer planos de contingncia para reduzir o impacto caso o risco se torne realidade. 3. Transferir o risco para outro lidar. 4. Ignorar e aceitar o risco. As escolhas para selecionar uma dessas possibilidades dependem dos benefcios e oportunidades criadas por cada opo, assim como o custo e, potencialmente, riscos adicionais associados a cada opo. Estratgias de Mitigao Na maioria das estratgias de teste baseadas em riscos, identificao de risco, anlise de risco e estabelecimento de atividades de mitigao de risco so a fundao para o plano mestre de teste e para outros planos de teste. O nvel de risco associado com cada item de risco determina a extenso do esforo de teste (isso , ao de mitigao) tomado para lidar com cada risco. Alguns padres de segurana relacionados (por exemplo, FAA DO-178B/ED 12B, IEC 61508), prescrevem as tcnicas de teste e o grau de cobertura baseados no nvel de risco. Mitigao de Risco do Projeto Se riscos de projeto so identificados, eles podem ter a necessidade de serem comunicados e influenciados pelo gerente do projeto. Tais riscos no esto sempre sob o controle da organizao de teste para sua reduo. Porm, alguns riscos de projeto podem e devem ser mitigados com sucesso pelo gerente de testes, tais como: Prontido do ambiente de teste e ferramentas Disponibilidade e qualificao do quadro de funcionrios de teste Baixa qualidade das entradas para o teste Trfego muito fortemente altervel de entradas para o teste Falta de normas, regras e tcnicas para o esforo de teste As abordagens de mitigao de risco incluem preparao antecipada do testware, pr-teste dos equipamentos de teste, pr-teste de verses anteriores do produto, critrio de entrada mais robusto para o teste, requisitos para testabilidade, participao em revises de resultados de projetos anteriores, participao no gerenciamento do problema e mudana, e monitorao do progresso do projeto e qualidade. Mitigao do Risco do Produto Quando algum est falando sobre um risco de produto (qualidade), ento o teste uma forma de mitigao de tais riscos. medida que os defeitos so encontrados, os testadores reduzem os riscos promovendo o conhecimento dos defeitos e as oportunidades de lidar com eles antes da liberao.
Verso 2007br
Pgina 47 de 124
02 Fev 2010
Certified Tester
Na medida em que os testadores no encontram defeitos, o teste reduz o risco com a garantia de que, sob determinadas condies (ou seja, as condies testadas), o sistema opera corretamente. Riscos de produto (qualidade) podem ser mitigados por atividades fora do teste. Por exemplo, se identificado que os requisitos no esto bem escritos, uma soluo eficiente poderia ser implementar revises completas como uma ao de mitigao, em oposio a escrever e priorizar testes que executaro uma vez o software mal escrito torna-se um modelo e cdigos reais. O nvel de risco tambm usado para priorizar os testes. Em alguns casos, todos os testes de mais alto risco so executados antes de quaisquer testes de mais baixo risco, e testes so executados estritamente na ordem dos riscos (frequentemente chamado de profundidade-primeiro ou depth-first); em outros casos, uma abordagem por amostragem usada para selecionar uma amostra de testes atravs dos riscos identificados usando o risco para ponderar a seleo enquanto ao mesmo tempo garante cobertura de cada risco pelo menos uma vez (frequentemente chamado largura-primeiro ou breadth-first). Outras aes de mitigao de risco que podem ser usadas por testadores incluem: Escolha de uma tcnica de modelagem de teste apropriada Revises e inspees Revises da modelagem de teste Nvel de independncia Pessoal mais experiente A forma de realizao do reteste Teste de regresso Em [Gerrard02] o conceito de efetividade de teste introduzido para indicar (como uma porcentagem) o quo efetivo o teste esperado a ser como uma medida de reduo de risco. Seria possvel tender a no aplicar o teste para reduzir o risco onde h um nvel baixo de efetividade de teste. Quer o teste baseado em risco proceda em profundidade-primeiro ou em largura-primeiro, possvel que o tempo alocado para o teste seja consumido sem que todos os testes tenham sido executados. O teste baseado em risco permite que os testadores se reportem gerncia em termos de nvel de risco remanescente em determinado ponto, e permite gerncia decidir quando estender o teste ou transferir o risco remanescente aos usurios, clientes, suporte de help desk e tcnico, e/ou funcionrios operacionais. Ajustando o Teste para os Demais Ciclos de Teste Se h tempo disponvel para teste adicional, quaisquer ciclos subsequentes de teste deveriam ser adaptados a uma nova anlise de risco. Os fatores principais aqui so quaisquer riscos de produto totalmente novos ou bastante alterados; reas instveis ou susceptveis a defeitos descobertas durante o teste; riscos dos defeitos corrigidos; a tentativa de concentrar o teste em falhas tpicas encontradas durante o teste; e, reas potencialmente subtestadas (baixa cobertura de teste). Qualquer ciclo de teste novo ou adicional deveria ser planejado usando uma anlise para tais riscos como entrada. tambm uma prtica fortemente recomendvel ter uma planilha de risco atualizada a cada marco do projeto.
3.9.3 Gerenciamento de Risco no Ciclo de Vida

Idealmente, o gerenciamento de risco ocorre atravs de todo o ciclo de vida. Se uma empresa tem um documento de poltica de teste e/ou estratgia de teste, ento eles podem descrever o processo geral atravs do qual os riscos de produto e de projeto so gerenciados no teste, e mostrar como o gerenciamento de risco integrado e afeta todas as fases de teste. As atividades de identificao de riscos e anlise de risco podem iniciar durante a fase inicial do projeto, a despeito do modelo de ciclo de desenvolvimento de software seguido. As atividades de mitigao de risco podem ser planejadas e colocadas em prtica como parte do processo de
Verso 2007br
Pgina 48 de 124
02 Fev 2010
Certified Tester
planejamento de teste como um todo. No plano mestre de teste e/ou planos de nvel de teste, ambos os riscos de projeto e produto podem ser focados. O tipo e o nvel do risco influenciaro os nveis de teste nos quais os riscos sero tratados, a extenso do esforo a ser usado na mitigao de risco, o teste e outras tcnicas a aplicar para reduzir o risco, e o critrio pelo qual julgar a adequao da mitigao de risco. Aps o planejamento estar completo, o gerenciamento de risco, incluindo identificao, anlise e reduo, deveria ser contnuo no projeto. Isso inclui a identificao de novos riscos, re-estimando o nvel dos riscos existentes, e avaliando a efetividade das atividades de mitigao de riscos. Para tomar um exemplo, se a identificao de um risco e seo de anlise forem baseadas na especificao de requisitos durante a fase de requisitos, uma vez que a especificao de modelagem esteja finalizada, deveria acontecer uma reavaliao dos riscos. Para pegar outro exemplo, se durante os testes um componente identificado como contendo consideravelmente mais defeitos do que o nmero esperado seria possvel concluir que a probabilidade de defeitos nessa rea era maior que a antecipada e, portanto, ajustar a probabilidade e o nvel geral de risco para cima. Isso poderia resultar em uma quantidade crescente de teste a ser realizado em confronto a esse componente. Uma vez que as atividades iniciais de identificao de risco e anlise esto completas, e com as atividades de reduo tendo sido encaminhadas, seria possvel medir o grau ao qual os riscos foram reduzidos. Isso pode ser feito rastreando os casos de teste e defeitos descobertos relacionados aos seus riscos associados. Com a execuo dos testes e os defeitos encontrados, os testadores podem examinar o nvel de risco remanescente, residual. Isso apoia o uso do teste baseado em risco determinando o momento exato para a liberao. Para um exemplo de relato de resultados de teste baseados na cobertura de risco, veja [Black03]. O relato de teste deveria tratar dos riscos cobertos e ainda abertos, assim como os benefcios alcanados e ainda no alcanados.
3.10
Anlise de Modo e Efeito de Falha
A FMEA e uma variante incluindo anlise de criticidade (FMECA) so atividades iterativas que intencionam analisar os efeitos e criticidade de modos de falha em um sistema. A aplicao dessas anlises ao software algumas vezes chamada de SFMEA e SFMECA onde o S se refere a Software. Nas sees seguintes, somente a FMEA usada, mas a informao aplicvel aos outros trs mtodos tambm. Os testadores devem ser capazes de contribuir com a criao do documento da FMEA. Isso inclui o entendimento da proposta e aplicao desses documentos, assim como a capacidade de aplicar seu conhecimento para auxiliar na determinao de fatores de risco.
3.10.1

reas de Aplicao
Onde a criticidade do software ou sistema sob considerao deve ser analisada, para reduzir o risco de falha (por exemplo, sistemas de segurana crtica tais como sistema de controle de voo) Onde requisitos obrigatrios ou reguladores so aplicveis (veja tambm a seo 1.3.2 Sistemas de Segurana Crtica) Para remover defeitos em estgios iniciais Para definir consideraes especiais de teste, restries operacionais, decises de modelagem para sistemas de segurana crtica
A FMEA deveria ser aplicada:
Verso 2007br
Pgina 49 de 124
02 Fev 2010
Certified Tester
3.10.2
Fases de Implementao
A FMEA deveria ser programada assim que informaes preliminares estejam disponveis em um alto nvel, e estendida para nveis mais baixos assim que mais detalhes tornam-se disponveis. A FMEA pode ser aplicada em qualquer nvel de decomposio de sistema ou software dependendo da informao disponvel e dos requisitos do programa. Para cada funo, mdulo, ou componente crticos, iterativamente: Selecione a funo e determine seus possveis modos de falha, ou seja, como a funo pode falhar Defina as possveis causas para tais falhas, seus efeitos e mecanismos de modelagem para a reduo ou mitigao das falhas
3.10.3

Custos & Benefcios
A FMEA apresenta as seguintes vantagens: Falhas de sistema esperadas por falhas de software ou erros de uso podem ser reveladas Uso sistemtico pode contribuir para a toda a anlise de nvel de sistema Resultados podem ser usados para modelar decises e/ou justificativas Resultados podem ser usados para direcionar o teste para reas especficas (crticas) do software As seguintes consideraes devem ser feitas quando aplicando a FMEA: Sequncias de falhas so raramente consideradas A criao de tabelas FMEA pode consumir tempo Funes independentes podem ser difceis de definir Propagao de erro pode no ser facilmente identificada
3.11
3.11.1
Questes de Gerenciamento de Teste

Questes de Gerenciamento para Teste Exploratrio
Gerenciamento de teste baseado em seo (Session-Based Test Managemen SBTM) um conceito para gerenciar o teste exploratrio. Uma seo uma unidade bsica de trabalho de teste, ininterrupta, e direcionada em um objeto de teste especfico com um objetivo especfico (o grfico do teste). Ao final de cada seo, um relatrio, chamado comumente de planilha de seo produzido utilizando as atividades realizadas. O SBTM opera dentro de uma estrutura de processo documentado e produz registros que complementam a documentao de verificao. Uma seo de teste pode ser dividida em trs estgios: Setup da seo: instalao do ambiente de teste e melhoria do entendimento do produto Modelagem e execuo de teste: escanear o objeto de teste e procurar por problemas Investigao e reporte de defeitos: iniciar quando o teste encontra algo que aparenta ser uma falha A planilha de seo SBTM consiste do seguinte: Grfico de seo Nome(s) do testador(es) Data e hora iniciais Decomposio de tarefa (sees) Arquivos de dados Anotaes de teste Questes
Verso 2007br
Pgina 50 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus Defeito Ao final de cada seo o gerente de teste preside uma reunio de alinhamento com a equipe. Durante o questionamento o gerente revisa as planilhas de seo, melhora os grficos, recebe um retorno dos testadores e estima e planeja as prximas sees. A programao para uma seo de discusso abreviada por PROOF pelo seguinte: Passado (Past): O que aconteceu durante a seo? Resultados (Results): O que foi conseguindo durante a seo? Perspectiva (Outlook): O que ainda necessita ser feito? Obstculos (Obstacles): O que ficou no caminho de um bom teste? Percepes (Feelings): Como os testadores se sentem sobre tudo isso?
3.11.2
Questes de Gerenciamento para Sistemas de Sistemas
As seguintes questes so associadas com o gerenciamento de teste de sistemas de sistemas: O gerenciamento de teste mais complexo porque o teste de sistemas individuais que compem os sistemas de sistemas pode ser conduzido em diferentes localidades, e usando diferentes modelos de ciclo de vida de desenvolvimento. Por essas razes o plano mestre de teste para os sistemas de sistemas tipicamente implementam um modelo de ciclo de vida formal com nfase em questes de gerenciamento tais como marcos e barreiras de qualidade. H frequentemente um processo formalmente definido de Garantia de Qualidade que pode ser definido em um plano de qualidade apartado. Processos como gerenciamento de configurao, gerenciamento de mudana e gerenciamento de liberao devem ser definidos formalmente e a interface com o gerenciamento de teste combinado. Esses processos so essenciais para garantir que os entregveis de software esto controlados, mudanas so introduzidas de uma forma gerenciada e as linhas de base sendo testas esto definidas. A construo e o gerenciamento de ambientes de teste representativos, incluindo dados de teste, podem ser um desafio central, tanto tcnico e como organizacional. A estratgia do teste de integrao pode necessitar que simuladores sejam construdos. Ao passo que isso pode ser relativamente simples e de baixo custo para o teste de integrao nos primeiros nveis de teste, a construo de simuladores para o sistema completo pode ser complexa e custosa para os nveis mais altos de teste de integrao encontrados em sistemas de sistemas. Planejamento, estimativa e desenvolvimento de simuladores so frequentemente gerenciados por um projeto separado. As dependncias entre as diferentes partes ao testar os sistemas de sistemas geram restries adicionais no teste de sistema e de aceite. tambm requerido um direcionamento adicional no teste de integrao de sistema e nos documentos de base de teste que acompanham, por exemplo, especificaes de interface.
3.11.3
Questes de Gerenciamento para Sistemas de Segurana Crtica
As seguintes questes so associadas com o gerenciamento de teste de sistemas de segurana crtica: Normas especficas da indstria (domnio) normalmente se aplicam (por exemplo, indstria de transporte, rea mdica e militar). Essas normas podem ser aplicadas para a estruturao do processo de desenvolvimento e organizacional, ou para os produtos sendo desenvolvidos. Refira ao Captulo 6 para mais detalhes. Devido a questes de confiabilidade associadas aos sistemas de segurana crtica, aspectos formais tais como rastreabilidade de requisitos, nveis de cobertura de teste a serem alcanados, critrio de aceite a ser atingido e a documentao de teste requerida podem ser aplicados para demonstrar a aderncia.
Verso 2007br
Pgina 51 de 124
02 Fev 2010
Certified Tester
Para evidenciar a adequao da estrutura organizacional e o processo de desenvolvimento, auditorias e grficos organizacionais devem ser suficientes. Um ciclo de vida de desenvolvimento predefinido seguido, dependendo do padro aplicvel. Tais ciclos de vida so tipicamente sequenciais em essncia. Se um sistema for categorizado como crtico por uma empresa, os seguintes atributos nofuncionais devem ser correspondidos na estratgia e/ou plano de teste: o Confiabilidade o Disponibilidade o Manutenibilidade o Segurana fsica e segurana de operao Devido a esses atributos, tais sistemas so chamados algumas vezes de sistemas RAMS (Reliability, Availability, Maintainability, Safety and security).
3.11.4
Outras Questes de Gerenciamento de Teste
Falhar no planejamento de testes no-funcionais pode colocar o sucesso de uma aplicao em um considervel risco. Muitos tipos de testes no-funcionais so, no entanto, associados aos custos altos, os quais devem ser equilibrados com os riscos. Existem muitos tipos diferentes de testes no-funcionais, nem todos apropriados para uma determinada aplicao. Os seguintes fatores podem influenciar o planejamento e a execuo de testes no-funcionais: Requisitos dos stakeholders Ferramental necessrio Hardware requerido Fatores organizacionais Comunicaes Segurana de dados
3.11.4.1 Requisitos de stakeholders Requisitos no-funcionais so frequentemente pobremente especificados ou at inexistentes. No estgio de planejamento, os testadores devem ser capazes de obter nveis de expectativa dos stakeholders afetados e avaliar os riscos que eles representam. recomendvel obter mltiplos pontos de vista durante a captura de requisitos. Os requisitos devem ser deduzidos pelos stakeholders tais como clientes, usurios, funcionrios de operao e funcionrios de manuteno; de outra forma alguns requisitos podem provavelmente ser esquecidos. As seguintes necessidades essenciais precisam ser consideradas para melhorar a testabilidade de requisitos no-funcionais: Requisitos so lidos mais frequentemente do que so escritos. Investir esforo em especificar requisitos testveis apresenta uma relao quase sempre vantajosa de custo. Use uma linguagem simples, de forma consistente e concisa (isso , use a linguagem definida no dicionrio de dados do projeto). Em particular, cuidado deve ser tomado no uso de palavras como precisa (isso , obrigatrio), poderia (isso , desejvel) e deve (melhor se evitado ou usado como sinnimo de precisa). Os leitores dos requisitos tm uma grande diversidade de conhecimentos. Requisitos devem ser escritos clara e concisamente para evitar mltiplas interpretaes. Um formato padro deve ser usado para cada requisito. Especificar requisitos quantitativamente quando possvel. Decidir as mtricas apropriadas para expressar um atributo (por exemplo, desempenho medido em milissegundos) e especificar variao na qual os resultados podem ser avaliados como aceitos ou rejeitados. Para certos atributos no-funcionais (por exemplo, usabilidade) isso pode no ser fcil.
Verso 2007br
Pgina 52 de 124
02 Fev 2010
Certified Tester
3.11.4.2 Ferramental Necessrio Ferramentas ou simuladores comerciais so particularmente relevantes para testes de desempenho, eficincia e alguns testes de segurana. O planejamento de teste inclui estimativa de custos e escala temporal envolvida no ferramental. Onde ferramentas especializadas so usadas, o planejamento deve levar em considerao as curvas de aprendizagem para novas ferramentas ou o custo de contratao de especialistas externos na ferramenta. O desenvolvimento de um simulador complexo pode representar o desenvolvimento de um projeto por si s e deveria ser planejado como tal. Em particular, o planejamento para simuladores serem usados em aplicaes de segurana crtica deveria considerar o teste de aceite e possvel certificao do simulado por uma corporao independente. 3.11.4.3 Hardware Requerido Muitos testes no-funcionais necessitam de um ambiente de teste como o da produo para que possam fornecer medies realistas. Dependendo do tamanho e da complexidade do sistema sob teste, isso pode envolver um impacto significativo no planejamento e capital disponvel para os testes. O custo de execuo de testes no-funcionais pode ser to alto que somente uma quantidade limitada de tempo est disponvel para a execuo do teste. Por exemplo, verificar os requisitos de escalabilidade de um site de Internet bastante visitado pode necessitar um simulador de centenas de milhares de usurios virtuais. Isso pode ter uma influncia significativa nos custos de hardware e ferramental. Desde que esses custos so tipicamente minimizados por aluguis (por exemplo, um complemento) de licenas de ferramentas de desempenho, o tempo disponvel para tais testes limitado. A realizao de testes de usabilidade pode necessitar a configurao de laboratrios dedicados ou proceder com amplos questionrios. Esses testes so realizados comumente somente uma vez no ciclo de vida do desenvolvimento. Muitos outros tipos de testes no-funcionais (por exemplo, testes de segurana, teste de desempenho) necessitam de um ambiente prximo ao da produo para sua execuo. Desde que o custo de tais ambientes muito alto, usar o prprio ambiente de produo pode ser a nica possibilidade prtica. O ritmo de tais execues de teste deve ser planejado cuidadosamente e bastante provvel que esses testes sejam executados somente em horrios especficos (por exemplo, perodo noturno). Computadores e largura de banda de comunicao devem ser planejados para quando os testes relacionados a eficincia (por exemplo, desempenho, carga) sero realizados. As necessidades dependem primariamente do nmero de usurios virtuais a serem simulados e da quantidade de trfego de rede que eles provavelmente geram. Falhar em considerar isso pode resultar em tomar medidas no representativas de desempenho. 3.11.4.4 Fatores Organizacionais Testes no-funcionais podem envolver a medio do comportamento de diversos componentes em um sistema completo (por exemplo, servidores, bancos de dados, redes). Se esses componentes forem distribudos por vrias localidades e organizaes, o esforo requerido para planejar e coordenar os testes pode ser significativa. Por exemplo, certos componentes de software podem somente estar disponveis para teste de sistema em horrios, dias ou anos em particular, ou as organizaes podem somente oferecer suporte para testar por um nmero de dias limitado. Falhar em confirmar se os componentes de sistema e os funcionrios de outras organizaes esto disponveis na chamada para os propsitos de teste pode resultar em ruptura dos testes programados.
Verso 2007br
Pgina 53 de 124
02 Fev 2010
Certified Tester
3.11.4.5 Consideraes de Comunicao A capacidade de especificar e executar tipos particulares de testes no-funcionais (em particular testes de eficincia) pode depender da habilidade em modificar protocolos de comunicao especficos para propsitos de teste. Cuidado deve ser tomado no estgio de planejamento para assegurar que isso possvel (por exemplo, quais ferramentas proveem compatibilidade necessria). 3.11.4.6 Consideraes de Segurana de Dados Medidas especficas de segurana implementadas para um sistema devem ser levadas em considerao no estgio de planejamento de teste para garantir que todas as atividades de teste sejam possveis. Por exemplo, o uso de criptografia de dados pode tornar difcil a criao de dados de teste e a verificao de resultados. Polticas de proteo de dados e leis podem impedir a gerao de usurios virtuais na base de dados da produo. Tornar os dados de teste annimos pode se uma tarefa no trivial, a qual deve ser planejada como parte da implementao de teste.
Verso 2007br
Pgina 54 de 124
02 Fev 2010
Certified Tester
4. Tcnicas de Teste
Termos:
BS 7925-2, anlise de valor limite (BVA), teste de desvio, grafo de causa-efeito, mtodo de rvore de classificao, teste de condio, teste de determinao de condio, anlise de fluxo de controle, caminho D-D , anlise de fluxo de dados , teste de tabela de deciso , teste de deciso, tcnica baseada em defeito, taxonomia de defeito, anlise dinmica, suposio de erro, partio de equivalncia, teste exploratrio, tcnica baseada em experincia, LCSAJ, vazamento de memria, teste de condies mltiplas, teste pareado, teste de caminho, teste baseado em requisitos, ataques de software, tcnica baseada em especificao, anlise esttica, cobertura de comando, teste de transio de estado, tcnica baseada em estrutura, painel de teste, teste de caso de uso, wild pointer.
4.1 Introduo
As tcnicas de modelagem de teste consideradas neste Captulo incluem as seguintes categorias: Baseado em especificao (ou baseada em comportamento ou caixa-preta) Baseado em estrutura (ou caixa-branca) Baseado em defeitos Baseado em experincia Essas tcnicas so complementares e podem ser usadas como apropriado para qualquer atividade dada de teste, independentemente do nvel de teste que esteja sendo aplicado. Ao passo que qualquer dessas tcnicas pode ser empregada por analistas de teste e analistas tcnicos de teste, para os propsitos deste syllabus, a seguinte diviso feita com base nos erros mais comuns de uso: Baseado em especificao Baseado em estrutura Baseado em experincia Baseado em defeitos Test Analysts e Technical Test Analysts Technical Test Analysts Test Analysts e Technical Test Analysts Test Analysts e Technical Test Analysts
Em complemento a essas reas, este captulo tambm inclui uma discusso sobre outras tcnicas, tais como ataques, anlise esttica e anlise dinmica. Essas tcnicas so normalmente realizadas pelos analistas tcnicos de teste. Note que tcnicas baseadas em especificao podem tambm ser funcional ou no-funcional. Tcnicas no-funcionais so discutidas no prximo Captulo.
4.2 Baseado em Especificao

Tcnicas baseadas em especificao so uma forma de derivar e selecionar condies e casos de teste baseados na anlise da documentao da base de teste para um componente ou sistema sem referncia sua estrutura interna. Caractersticas comuns de tcnicas baseadas em especificao: Modelos, sejam formais ou informais, so usados para a especificao do problema a ser resolvido, do software ou de seus componentes. Casos de teste podem ser derivados sistematicamente desses modelos. Algumas tcnicas tambm fornecem critrio de cobertura, os quais podem ser usados para medio da tarefa de modelagem de teste. O preenchimento completo do critrio de cobertura no significa
Verso 2007br
Pgina 55 de 124
02 Fev 2010
Certified Tester
que o conjunto inteiro de testes est completo, mas sim que o modelo j no sugere quaisquer testes teis baseados naquela tcnica. Testes baseados em especificao so comumente testes baseados em requisitos. Desde que a especificao de requisitos deve especificar como o sistema se comporta, particularmente na rea de funcionalidade, derivar testes dos requisitos frequentemente parte do teste de comportamento do sistema. As tcnicas discutidas anteriormente nessa subseo podem ser aplicadas diretamente especificao de requisitos, criando um modelo para o comportamento do sistema a partir de texto ou grficos da prpria especificao de requisitos, e ento os testes prosseguem como descritos anteriormente. No Advanced Level Syllabus, as seguintes tcnicas de modelagem de teste baseadas em especificao so consideradas: Nome Tcnica Critrio de Cobertura Partio de equivalncia Veja a seo 4.3.1 do ISTQB Foundation Syllabus para uma descrio. Anlise de valor limite (BVA Boundary Value Analysis) Veja a seo 4.3.2 do ISTQB Foundation Syllabus para uma descrio. Veja que BVA pode ser aplicado usando tanto 2 ou 3 valores. A deciso que se aplica mais provvel de ser baseada em risco. Teste de tabela de deciso e grafos de causa-efeito Veja a seo 4.3.3 do ISTQB Foundation Syllabus para uma descrio de Teste de tabela de deciso. Com o teste de tabela de deciso toda combinao de condies, relacionamentos e restries so testadas. Alm disso, para as tabelas de deciso, uma tcnica grfica usando uma notao lgica chamada grafos de causaefeito pode ser usada tambm. Observe que subsequente ao teste de cada combinao de condies, tambm possvel colapsar as tabelas. Usando tabelas de deciso completas ou colapsadas mais provvel ser baseado em risco. [Copeland03] Teste de transio de estado Veja a seo 4.3.4 do ISTQB Foundation Syllabus para uma descrio. Nmero de parties cobertas / nmero total de parties. Nmero de valores limites distintos cobertos / nmero total de valores limites.
Nmero de combinaes de condies cobertas / nmero mximo de combinaes de condies.
Para transies simples, a mtrica de cobertura a porcentagem de todas as transies vlidas exercitadas durante o teste. Isso conhecido como cobertura 0switch. Para n transies, a medida de cobertura a porcentagem de todas as sequncias vlidas de n transies exercitadas durante o teste. Isso conhecido como cobertura (n-1)-switch. Mtodo de classificao por rvore, vetores ortogonais e tabelas de todos os pares Fatores ou variveis de interesse e as opes ou Depende da tcnica aplicada, por valores que podem ser tomados na identificao, exemplo, por pares distinta da e singletons, pares, trios, ou tambm classificao por rvore. combinaes de ordem mais alta dessas opes e valores so identificadas. [Copeland03]
Verso 2007br
Pgina 56 de 124
02 Fev 2010
Certified Tester
Nome
Tcnica
Critrio de Cobertura
Mtodo de rvore de classificao utiliza uma notao grfica para mostrar as condies de teste (classes) e as combinaes tratadas pelos casos de teste. [Grochtmann94] Teste de caso de uso Veja a seo 4.3.5 do ISTQB Foundation Nenhum critrio formal se aplica. Syllabus para uma descrio. Algumas vezes as tcnicas so combinadas para criar testes. Por exemplo, as condies identificadas em uma tabela de deciso podem ser submetidas partio de equivalncia para descobrir mltiplas formas nas quais uma condio pode ser satisfeita. Os testes devem ento cobrir no somente toda combinao de condies, mas tambm, para aquelas condies que foram particionadas, testes adicionais devem ser gerados para descobrir parties de equivalncia.
4.3 Baseado em Estrutura

Uma tcnica de modelagem de teste baseada em estrutura, tambm conhecida como tcnicas de teste de caixa-branca ou baseada em cdigo, tal que o cdigo, o dado, a arquitetura ou fluxo do sistema usado como base para modelagem de teste, com testes derivados sistematicamente da estrutura. A tcnica determina os elementos da estrutura a serem considerados. A tcnica tambm prov critrio de cobertura, o qual sinaliza quando a derivao do teste pode ser concluda. Esses critrios no significam que todo o conjunto de testes est completo, mas que a estrutura considerada no prope mais nenhum teste baseado naquela tcnica. Cada critrio deve ser medido e associado a um objetivo definido por cada projeto ou empresa. Caractersticas comuns de tcnicas baseadas em estrutura: Informao sobre como o software construdo usada para derivar casos de teste, por exemplo, cdigo e modelagem. A extenso da cobertura do software pode ser mensurada para os casos de teste existentes, e outros casos de teste podem ser derivados sistematicamente para aumentar a cobertura. No Advanced Level Syllabus, a seguinte estrutura de tcnicas de modelagem de teste considerada: Nome Tcnica Critrio de Cobertura Nmero de comandos executados / nmero total de comandos Nmero de sadas de decises executadas / nmero total de sadas de decises Nmero de desvios executados nmero total de desvios. /
Teste de comando Os comandos executveis (no comentados, sem espaos em branco) so identificados. Teste de deciso Os comandos de deciso, tais como comandos if/else, switch/case, for e while, so identificados. Teste de desvio Os desvios, tais como comandos if/else, switch/case, for e while, so identificados. Veja que o teste de deciso e desvio so os mesmos para 100% de cobertura, mas podem ser diferentes para nveis inferiores de cobertura. Teste de condio Classificaes de verdadeiro/falso e case so identificados.
Nmero de valores de operandos booleanos / nmero total de valores de operandos booleanos
Verso 2007br
Pgina 57 de 124
02 Fev 2010
Certified Tester
Nome
Tcnica
Critrio de Cobertura Nmero de combinaes executadas de valores de operandos booleanos / nmero total de combinaes de valores de operadores booleanos Nmero de valores de operandos booleanos demonstrados a afetar independentemente a deciso / nmero total de operandos booleanos. Nmero de LCSAJs executados nmero total de LCSAJs. /
Teste de condio mltipla Todas as possveis combinaes de condies verdadeiro/falso so identificadas.
Teste de determinao de condio As possveis combinaes de condies verdadeiro/falso que afetam as decises (desvios) so identificadas. LCSAJ (teste de lao) As condies possveis que controlam uma iterao de um lao so identificadas. O teste de sequncia de cdigo linear e salto (LCSAJ - Linear Code Sequence And Jump) usado para testar uma seo especfica do cdigo (uma sequncia linear de cdigo executvel) que inicia no comeo de um fluxo de controle em particular e termina no salto para outro fluxo de controle ou um salto ao final do programa. Esses fragmentos de cdigo so tambm conhecidos como caminhos D-D (para caminho deciso a deciso). Essa tcnica usada para definir casos de teste especficos e dados de teste associados necessrios para exercitar o fluxo de controle selecionado. Modelar esses testes requer aceso a um modelo do cdigo fonte que define os saltos do fluxo de controle. LCSAJ pode ser usado como base para medio de cobertura de cdigo. Teste de caminho Uma nica sequncia de comandos (caminhos) identificada.
Nmero de caminhos exercitados / nmero total de caminhos.
Um uso comum para o critrio de cobertura estrutural a medida da completude ou no completude de um conjunto de testes modelados usando tcnicas baseadas na especificao e/ou na experincia. Ferramentas de teste chamadas de ferramentas de cobertura de cdigo so usadas para capturar a cobertura estrutural atingida por esses testes. Se forem identificadas lacunas importantes na cobertura estrutural (ou na cobertura exigida por normas aplicveis no alcanadas), ento testes so adicionados para tratar dessas lacunas usando tcnicas estruturais ou outras. Cobertura de anlise Teste dinmico usando tcnicas baseadas em estrutura ou outras pode ser conduzido para determinar se uma cobertura especfica de cdigo foi atingida ou no. Isso usado para fornecer evidncia no caso de sistemas crticos onde uma cobertura especfica deve ser alcanada (veja tambm a seo 1.3.2 Sistemas de Segurana Crtica). Os resultados podem indicar que algumas sees do cdigo no foram exercitadas, e ento conduzir definio de casos de teste adicionais para exercitar essas sees.
Verso 2007br
Pgina 58 de 124
02 Fev 2010
Certified Tester

4.4.1 Tcnicas Baseadas em Defeito
Uma tcnica de modelagem de teste baseada em defeito tal que o tipo do defeito procurado usado como base para a modelagem do teste, com testes derivados sistematicamente com o que conhecido sobre o defeito. A tcnica tambm fornece critrio de cobertura que pode ser usado para determinar quando a derivao de teste pode ser concluda. De forma prtica, o critrio de cobertura para tcnicas baseadas em defeito tende a ser menos sistemtica que para tcnicas baseadas em comportamento ou estrutura, na qual as regras gerais para a cobertura so dadas e a deciso especfica sobre o que constitui o limite de cobertura til arbitrado durante a modelagem de teste ou a execuo de teste. O critrio de cobertura no significa que o conjunto completo de testes esteja completo, mas sim que os defeitos sendo considerados no indicam mais nenhum teste til baseado na tcnica. No Advanced Level Syllabus, a seguinte tcnica de modelagem de teste baseado em defeito discutida: Nome Tcnica Critrio de Cobertura Taxonomias (categorias & listas de defeitos em potencial) O testador usa amostras de taxonomia a partir de listas, selecionando um problema em potencial para anlise. Taxonomias podem listar a causa raiz, defeito e falha. As taxonomias de defeitos listam os defeitos mais comuns no software sob teste. Essa lista usada para modelar casos de teste. Dados e tipos de defeitos apropriados.
4.4.2 Tcnicas Baseadas em Experincia

Existem outras tcnicas que consideram o histrico do defeito, mas no tm necessariamente um critrio de cobertura sistemtico. Essas so categorizadas como tcnicas de teste baseadas em experincia. Testes baseados em experincia utilizam as competncias e intuio dos testadores, juntamente com uso de experincia em aplicaes ou tecnologias similares. Esses testes so efetivos em encontrar defeitos, porm no so to apropriados como outras tcnicas para alcanar nveis de cobertura especficos de teste ou para produzir procedimentos reutilizveis de teste. Usando abordagens dinmicas e heursticas, os testadores tendem a usar testes baseados em experincia, e o teste mais reativo a eventos do que uma abordagem pr-planejada. Alm disso, a execuo e avaliao so tarefas concorrentes. Algumas abordagens estruturadas para testes baseados em experincia no so completamente dinmicas; por exemplo, os testes no so completamente criados ao mesmo momento em que so executados os testes. Veja que apesar de que algumas ideias sobre cobertura esto presentes na tabela a seguir, tcnicas baseadas em experincia no tm critrio de cobertura formal. Neste syllabus, so discutidas as seguintes tcnicas de modelagem de teste baseado na experincia:
Verso 2007br
Pgina 59 de 124
02 Fev 2010
Certified Tester
Nome
Tcnica
Critrio de Cobertura Quando uma taxonomia usada, faltas de dados e tipos de defeitos apropriados. Sem uma taxonomia, a cobertura limitada pela experincia da equipe disponvel. Cada item de uma lista de checagem tenha sido coberto.
Suposio de erro O testador usa experincia para supor os erros potenciais que podem ser feitos e determina os mtodos para cobrir os defeitos resultantes. A suposio de erro til durante a anlise de risco para identificar modos de falha em potencial. Baseado em lista de checagem O testador experiente usa uma lista de alto nvel com itens a serem anotados, verificados, ou relembrados, ou um conjunto de regras ou critrios mediante os quais o produto deve ser verificado. Essas listas de checagem so construdas baseadas em um conjunto de padres, experincia e outras consideraes. Uma lista de verificao de padro de interface de usurio aplicada como base para o teste de uma aplicao um exemplo de teste baseado em lista de checagem. Exploratrio O testador aprende simultaneamente sobre o produto e seus defeitos, planeja o trabalho de teste a ser feito, modela e executa os testes, e reporta os resultados. Bons testes exploratrios so planejados, interativos e criativos. O testador ajusta dinamicamente os objetivos de teste durante a execuo e prepara somente uma documentao superficial. [Veenendaal02]
Grficos podem ser criados para especificar tarefas, objetivos e entregveis, e uma seo de teste exploratrio planejada para identificar o que atingir, onde colocar o foco, o que est dentro e fora do escopo, e quais recursos devem ser combinados. Em adio, um conjunto de heursticas sobre defeitos e qualidade deve ser considerado. As diferentes interfaces da aplicao sendo testada. As interfaces principais so as interface de usurio, sistema operacional, kernel, APIs e sistema de arquivo.
Ataques O testador faz uma avaliao direcionada e com foco na qualidade do sistema na tentativa de forar a ocorrncia de falhas especficas. O princpio de ataques de software, como descrito em [Whittaker03], baseado nas interaes do software sob teste com seu ambiente operacional. Isso inclui a interface do usurio, sistema operacional com seu kernel, as APIs e os sistemas de arquivo. Essas interaes so baseadas em trocas precisas de dados. Qualquer falta de alinhamento em uma (ou mais) interao pode ser a causa da falha.
Tcnicas baseadas em defeitos e experincia aplicam conhecimento de defeitos e outras experincias para aumentar a deteco de defeitos. Elas variam desde testes rpidos, nos quais o testador no tem atividades formalmente pr-planejadas para realizar, at sees pr-planejadas com sees pr-definidas. Elas so quase sempre teis, e so de valor particularmente nas seguintes circunstncias: Nenhuma especificao est disponvel H uma documentao escassa do sistema sob teste Tempo insuficiente dedicado para modelagem e criao de procedimentos de teste Testadores tm experincia no domnio e/ou na tecnologia
Verso 2007br
Pgina 60 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus Procura por diversidade do teste redigido. Anlise de falhas operacionais Tcnicas baseadas em defeito e experincia tambm so teis quando usadas em conjunto com tcnicas baseadas em comportamento e estrutura, na medida em que preenchem as lacunas na cobertura do teste que resulta da fraqueza sistemtica nessas tcnicas.
4.5 Anlise Esttica

A anlise esttica concentra-se no teste sem realmente executar o software sob teste e pode ser relacionada ao cdigo ou arquitetura do sistema.
4.5.1 Anlise Esttica do Cdigo

A anlise esttica um tipo de teste ou exame que pode ser realizado sem executar o cdigo. So vrias as tcnicas de anlise esttica e elas so discutidas nesta seo. 4.5.1.1 Anlise de Fluxo de Controle Anlise de fluxo de controle fornece informao sobre pontos de deciso lgica nos sistemas de software e a complexidade de sua estrutura. A anlise de fluxo de controle descrita no ISTQB Foundation Level Syllabus e em [Beizer95]. 4.5.1.2 Anlise de Fluxo de Dados Anlise de fluxo de dados uma tcnica de teste estruturada que testa os caminhos entre onde a varivel estabelecida at onde ela subsequentemente usada. Esses caminhos so denominados de pares definio-uso (pares du) ou estabelecimento-uso. Nesse mtodo, os conjuntos de teste so gerados para alcanar 100% de cobertura (quando possvel) para cada um desses pares. Essa tcnica, apesar de denominada anlise de fluxo de dados, tambm considera o fluxo de controle do software sob teste j que ele segue o estabelecimento e o uso de cada varivel, e pode ter que atravessar o fluxo de controle do software. Veja tambm [Beizer95]. 4.5.1.3 Conformidade com Padres de Codificao Durante a anlise esttica, a conformidade aos padres de codificao tambm podem ser avaliadas. Os padres de codificao cobrem tanto aspectos arquiteturais quanto o uso (ou proibio do uso) de algumas estruturas de programao. A conformidade com os padres de codificao permite que o software seja mais passvel de manuteno e teste. Requisitos especficos da linguagem podem tambm ser verificados usando teste esttico. 4.5.1.4 Gerao de Mtricas de Cdigo Mtricas de cdigo podem ser geradas durante a anlise esttica, a qual contribuir para um mais alto nvel de capacidade de manuteno ou confiabilidade do cdigo. Exemplos de tais mtricas so: Complexidade ciclomtica Tamanho Frequncia de comentrios Nmero de nveis aninhados Nmero de chamadas de funes
Verso 2007br
Pgina 61 de 124
02 Fev 2010
Certified Tester
4.5.2 Anlise Esttica da Arquitetura

4.5.2.1 Anlise Esttica de um Web Site A arquitetura de um web site tambm pode ser avaliada usando ferramentas de anlise esttica. Aqui o objetivo verificar se a estrutura em rvore do site bem balanceada ou se h um desbalano que conduzir a: Maior dificuldade nas tarefas de teste Aumento na carga de trabalho para manuteno Dificuldade na navegao do usurio Algumas ferramentas de teste especficas que incluem uma web spider engine tambm podem fornecer, atravs de anlise esttica, informao sobre o tamanho das pginas, sobre o tempo necessrio para o download, e quando a pgina est presente ou no (por exemplo, um erro http 404). Isso fornece informao til ao desenvolvedor, ao webmaster e ao testador. 4.5.2.2 Grafos de Chamadas Grafos de chamadas podem ser usados para inmeros propsitos: Modelar testes que chamam um mdulo especfico Estabelecer o nmero de localizaes dentro do software em que o mdulo chamado Fornecer uma sugesto para a ordem de integrao (integrao por pares ou vizinhana [Jorgensen02]) Avaliar a estrutura do cdigo total e sua arquitetura. Informao sobre os mdulos chamados tambm pode ser obtida durante a anlise dinmica. A informao obtida se refere ao nmero de vezes que um mdulo foi chamado durante a execuo. Com a unio da informao obtida pelos grafos de chamada durante a anlise esttica e a informao obtida durante a anlise dinmica, o testador pode manter o foco em mdulos que so chamados frequentemente e/ou repetidamente. Se tais mdulos so tambm complexos (veja 1.3.2.2 Sistemas de Segurana Crtica e Complexidade) eles so os primeiros candidatos para um teste detalhado e extensivo.
4.6 Anlise Dinmica

O princpio da anlise dinmica analisar uma aplicao enquanto ela est em execuo. Isso frequentemente requer algum tipo de instrumentao, inserida no cdigo tanto manual quanto automaticamente.
4.6.1 Viso Geral

Defeitos que no so imediatamente reprodutveis tm uma consequncia significativa no esforo de teste e na capacidade de liberao ou uso produtvel do software. Tais defeitos podem ser causados por vazamento de memria, uso incorreto de ponteiros e outras construes corrompidas (por exemplo, da pilha do sistema) [Kaner02]. Devido natureza desses defeitos, os quais podem incluir piora gradual do desempenho do sistema ou at queda de sistemas, as estratgias de teste devem considerar os riscos associados a tais defeitos e, quando apropriado, realizar uma anlise dinmica para reduzi-los (comumente pela utilizao de ferramentas). A anlise dinmica realizada enquanto o software est sendo executado. Isso pode ser aplicado para: Prevenir a ocorrncia de falhas pela deteco de wild pointers e perda de memria do sistema Analisar falhas de sistema que no so facilmente reprodutveis Avaliar o comportamento da rede de interconexo
Verso 2007br
Pgina 62 de 124
02 Fev 2010
Certified Tester
Melhorar o desempenho do sistema provendo informao do comportamento do sistema em tempo de execuo. A anlise dinmica deve ser realizada em qualquer nvel de teste, mas particularmente til em teste de componente e integrao. Habilidades tcnicas e de sistema so requeridas para especificar os objetivos do teste da anlise dinmica e, em particular, para analisar os resultados.
4.6.2 Detectando Vazamentos de Memria

Um vazamento de memria ocorre quando uma memria (RAM) disponvel para um programa alocada por aquele programa, mas, subsequentemente, no liberada devido a erros de programao. O programa ento perde a capacidade de acessar esse pedao de memria e pode, eventualmente, acabar com a memria utilizvel. Vazamentos de memria causam problemas que se desenvolvem durante o passar do tempo e podem no ser sempre imediatamente bvios. Esse pode ser o caso se, por exemplo, o software tenha sido recentemente instalado e o sistema reiniciado, o que frequentemente ocorre durante o teste. Por essas razes, os efeitos negativos dos vazamentos de memria podem frequentemente ser notados primeiro quando o programa est em produo. Os sintomas de um vazamento de memria representam uma piora constante no tempo de resposta do sistema, a qual pode finalmente resultar em uma falha do sistema. Enquanto que tais falhas podem ser resolvidas atravs da reinicializao (re-booting) do sistema, isso pode no ser sempre prtico ou at possvel. Ferramentas identificam reas no cdigo onde os vazamentos de memria ocorrem para que elas possam ser corrigidas. Simples monitores de memria tambm podem ser usados para obter uma impresso geral de como a memria disponvel est reduzindo ao longo do tempo, apesar de que uma anlise de acompanhamento ainda pode ser necessria se esse for o caso. H outras formas de vazamentos que deveriam ser consideradas. Exemplos incluem a manipulao de arquivos, semforos e reservatrios de conexo para recursos.
4.6.3 Detectando Wild Pointers

Wild pointers em um programa so ponteiros que so de alguma forma inutilizveis. Por exemplo, eles podem ter perdido o objeto ou funo para o qual eles deveriam estar apontando ou eles no apontam para a rea de memria intencionada (por exemplo, alm do limites alocados de um array). Quando um programa usa wild pointers, vrias consequncias podem ocorrer: 1. O programa pode executar como esperado. Esse pode ser o caso quando o wild pointer acessa memria que no atualmente usada pelo programa e visto como livre. 2. O programa pode quebrar. Nesse caso o wild pointer pode ter apontado a uma parte da memria usada a qual crtica execuo do programa (por exemplo, o sistema operacional). 3. O programa no funciona corretamente visto que objetos requeridos pelo programa no podem ser acessados. Sob essas condies o programa pode continuar seu funcionamento, porm uma mensagem de erro pode ser emitida. 4. O dado pode estar corrompido pelo ponteiro e valores incorretos sero subsequentemente usados. Note que qualquer mudana realizada no uso de memria pelo programa (por exemplo, uma nova build seguida da mudana do software) pode disparar qualquer uma das quatro consequncias listadas acima. Isso particularmente crtico onde o programa inicialmente executa como esperado apesar do uso de wild pointers, e ento quebra inesperadamente (talvez at em produo) seguindo uma mudana do software. importante notar que tais falhas so sintomas de erros encobertos (tal como o wild pointer), mas no o erro propriamente dito. (Refira a [Kaner02], Lesson 74).
Verso 2007br
Pgina 63 de 124
02 Fev 2010
Certified Tester
Ferramentas podem identificar wild pointers quando so usados pelo programa, sem restrio quanto suas consequncias na execuo do programa.
4.6.4 Anlise de Desempenho

A anlise dinmica pode ser conduzida para analisar o desempenho do programa. Ferramentas auxiliam a identificar gargalos no desempenho e a gerar uma grande variao de mtricas de desempenho as quais podem ser usadas pelo desenvolvedor para sintonizar o sistema. Isso tambm referenciado como perfil de desempenho.
Verso 2007br
Pgina 64 de 124
02 Fev 2010
Certified Tester
5. Teste de Caractersticas de Software

Termos
Teste de acessibilidade, teste de acurcia, teste de eficincia, avaliao heurstica, teste de interoperabilidade, teste de mantenabilidade, teste de aceite operacional (OAT - Operational Acceptance Test), perfil operacional, teste de portabilidade, teste de recuperabilidade, modelo de crescimento de confiabilidade, teste de confiabilidade, teste de segurana de acesso, teste de adequao, Inventrio de Medio de Usabilidade de Software (SUMI Software Usability Measurement Inventory), teste de usabilidade
5.1 Introduo
Ao passo que o Captulo anterior descreveu tcnicas especficas disponveis ao testador, este Captulo considera a aplicao de tais tcnicas na avaliao dos principais atributos usados para descrever a qualidade das aplicaes de software ou sistemas. Neste syllabus os atributos de qualidade que podem ser avaliados para Test Analyst e Technical Test Analyst so considerados em sees separadas. A descrio de atributos de qualidade fornecida na ISO 9126 usada como guia para descrever os atributos. A compreenso dos vrios atributos de qualidade um objetivo bsico de aprendizado para os trs mdulos. Dependendo do atributo de qualidade especfico coberto, um entendimento mais profundo desenvolvido tanto para o mdulo de Test Analysts quando para o de Technical Test Analysts, assim os riscos tpicos podem ser reconhecidos, estratgias apropriadas de teste desenvolvidas e casos de teste especificados.
5.2 Atributos de Qualidade para Teste de Domnio

O teste funcional direcionado para o qu o produto faz. A base de teste para o teste funcional usualmente uma documentao de requisitos ou especificao, conhecimentos especficos de domnio ou necessidade subentendida. Testes funcionais variam de acordo com o nvel ou fase de teste nos quais eles so conduzidos. Por exemplo, um teste funcional conduzido durante o teste de integrao testar a funcionalidade da interface entre os mdulos que implementam uma nica funo definida. No nvel de teste de sistema, os testes funcionais incluem o teste da funcionalidade da aplicao como um todo. Para sistemas de sistemas, o teste funcional ter foco primariamente no teste end to end atravs dos sistemas integrados. Uma grande variedade de tcnicas de teste aplicada durante o teste funcional (veja seo 4). O teste funcional pode ser realizado por um testador dedicado, um especialista em domnio, ou um desenvolvedor (comumente no nvel de componente). Os seguintes atributos de qualidade so considerados: Acurcia Adequao Interoperabilidade Segurana funcional Usabilidade Acessibilidade
Verso 2007br
Pgina 65 de 124
02 Fev 2010
Certified Tester
5.2.1 Teste de Acurcia

Acurcia funcional envolve o teste da aderncia da aplicao a requisitos especificados ou subentendidos e podem inclusive incluir acurcia computacional. O teste de acurcia faz aplicao de muitas das tcnicas de teste explicadas no Captulo 4.
5.2.2 Teste de Adequao

O teste de adequao envolve avaliao e validao da convenincia de um conjunto e funes para suas tarefas especficas intencionadas. O teste pode ser baseado nos casos de uso ou procedimentos.
5.2.3 Teste de Interoperabilidade

O teste de interoperabilidade testa quando uma dada aplicao pode funcionar corretamente para todos os ambientes alvo intencionados (hardware, software, middleware, sistema operacional, etc.). Especificar testes para interoperabilidade requer que a combinao dos ambientes alvo intencionados seja identificada, configurada, e disponveis equipe de teste. Esses ambientes so ento testados usando uma seleo de casos de testes funcionais os quais exercitam os vrios componentes presentes no ambiente. A interoperabilidade relata como os diferentes sistemas de software interagem uns com os outros. Um software com boas caractersticas de interoperabilidade pode ser facilmente integrado com vrios outros sistemas sem necessitar de grandes mudanas. A quantidade de mudanas e o esforo requerido para realiz-las podem ser usados para medir a interoperabilidade. O teste para a interoperabilidade do software pode, por exemplo, manter o foco nas seguintes caractersticas de modelagem: O uso do software de padres de comunicao largamente utilizados na indstria, tal como XML. A capacidade do software em automaticamente detectar as necessidades de comunicao com sistema que ele interage e mudar de acordo.
O teste de interoperabilidade pode ser particularmente significativo para: Empresas desenvolvendo software e ferramentas como Sistemas de Prateleira (COTS) Desenvolvimento de sistemas de sistemas
Essa modalidade de teste primariamente realizada no teste de integrao de sistema.
5.2.4 Teste de Segurana Funcional

O teste de segurana funcional (teste de invaso) direcionado capacidade do software em prevenir acesso no autorizado, tanto acidental ou deliberado, a funes e dados. Os direitos de usurio, acesso e privilgios so includos nesse teste. Essa informao deve ser avaliada nas especificaes do sistema. O teste de segurana tambm inclui diversos aspectos que so mais relevantes a Technical Test Analysts e so discutidos na seo 5.3 abaixo.
5.2.5 Teste de Usabilidade

importante compreender o motivo pelos quais usurios podem ter dificuldade na utilizao de um sistema de software proposto. Para isso, primeiramente necessrio frisar que o termo usurio pode aplicar a uma larga variao de diferentes tipos de pessoas, desde especialistas de TI a crianas ou pessoas com incapacidades.
Verso 2007br
Pgina 66 de 124
02 Fev 2010
Certified Tester
Algumas instituies nacionais (por exemplo, o British Royal National Institute for the Blind), recomendam que pginas web sejam acessveis para incapacitados, cegos, viso parcial, mobilidade prejudicada, surdos e usurios com inaptido cognitiva. Verificar que tais aplicaes e web sites so utilizveis pelos usurios listados acima, pode tambm melhorar a usabilidade para qualquer outro. O teste de usabilidade mede a adequao do software aos seus usurios, e direcionado medio dos seguintes fatores com os quais usurios especficos podem atingir objetivos especficos em ambientes ou contextos de uso: Efetividade: a capacidade do produto de software em permitir que usurios atinjam objetivos particulares com preciso e perfeio em um contexto de uso especificado. Eficincia: a capacidade do produto de software em permitir que usurios despendam quantidades apropriadas de recursos em relao efetividade alcanada em um contexto de uso especificado. Satisfao: a capacidade do produto de software em satisfazer usurios em um contexto de uso especificado. Atributos que podem ser medidos so: Inteligibilidade: atributos do software que afetam o esforo requerido dos usurios em reconhecer o conceito lgico e sua aplicabilidade Capacidade de aprendizado: atributos do software que afetam o esforo requerido dos usurios em aprender a aplicao Operabilidade: atributos do software que afetam o esforo requerido pelo usurio para conduzir tarefas de forma efetiva e eficiente Atratividade: a capacidade do software ser apreciado pelo usurio A avaliao da usabilidade tem dois propsitos: Remover defeitos de usabilidade (algumas vezes referido como uma avaliao formativa) Testar em comparao a requisitos de usabilidade (algumas vezes referido como avaliao somativa) As competncias dos testadores devem incluir especializao ou conhecimento nas seguintes reas: Sociologia Psicologia Conformidade com normas nacionais (por exemplo, American Disabilities Act) Ergonomia A realizao da validao da implementao corrente deveria ser feita sob condies to prximas quanto possvel daquelas nas quais o sistema ser usado. Isso pode envolver a composio do laboratrio de usabilidade com cmeras de vdeo, escritrios simulados, painis de reviso, usurios, etc., para que a equipe de desenvolvimento possa observar o efeito do sistema vigente em pessoas reais. Muitos testes de usabilidade podem ser executados como parte de outros testes, por exemplo, durante o teste funcional de sistema. Para alcanar uma abordagem consistente para detectar e reportar faltas de usabilidade em todos os estgios do ciclo de vida, orientaes de usabilidade podem ser teis. 5.2.5.1 Especificao de Teste de Usabilidade As principais tcnicas para teste de usabilidade so: Inspeo, avaliao ou reviso Execuo de verificao e validao da implementao real Execuo de pesquisas e questionrios
Inspeo, avaliao ou reviso
Verso 2007br
Pgina 67 de 124
02 Fev 2010
Certified Tester
Inspeo ou reviso das especificaes e modelagens da perspectiva de usabilidade, a qual aumenta o nvel de envolvimento do usurio, pode ser apropriada em relao ao custo por encontrar problemas antecipadamente. Avaliao Heurstica (inspeo sistemtica do modelo da interface do usurio para usabilidade) pode ser usada para encontrar problemas de usabilidade no modelo de tal forma que eles podem ser tratados como parte de um processo de modelagem iterativo. Isso envolve ter um pequeno conjunto de avaliadores examinando e julgando sua conformidade com princpios reconhecidos de usabilidade (a heurstica). Validao da implementao real Para realizar a validao da implementao real, os testes especificados para o teste funcional de sistema podem ser desenvolvidos como cenrios de teste de usabilidade. Esses cenrios de teste medem atributos especficos de usabilidade, tais como a velocidade de aprendizado ou operabilidade, ao invs de resultados funcionais. Cenrios de teste para usabilidade podem ser desenvolvidos especificamente para teste de sintaxe e semntica. Sintaxe: a estrutura ou gramtica da interface (por exemplo, o que pode ser entrado em um campo de entrada) Semntica: significado e propsito (por exemplo, mensagens de sistema e sada fornecidas ao usurio razoveis e significativas) Tcnicas usadas para desenvolver esses cenrios de teste podem incluir: Mtodos de caixa-preta como descrito, por exemplo, em BS-7925-2 Casos de uso, tanto em texto puro ou definidos com UML (Unified Modeling Language) Cenrios de teste para teste de usabilidade incluem instrues de usurio, distribuio de tempo para entrevistas pr e ps teste para determinadas instrues e recebimento de feedback e um protocolo de acordo para execuo de sees. Esse protocolo inclui uma descrio de como o teste deve ser conduzido, ritmo, anotaes e registro de sees, e os mtodos de entrevista e levantamento a serem utilizados. Pesquisas e questionrios Pesquisas e questionrios podem ser aplicados para reunir observaes do comportamento do usurio com o sistema em um laboratrio de teste de usabilidade. Pesquisas disponveis publicamente e padronizados tal como o SUMI (Inventrio de Medio de Usabilidade de Software Software Usability Measurement Inventory) e WAMMI (Inventrio de Anlise e Medio de Website Website Analysis and MeasureMent Inventory) permitem comparao com um banco de dados de medies prvias de usabilidade. Alm disso, desde que SUMI fornece medies concretas de usabilidade, ele prov uma boa oportunidade de us-las como um critrio de concluso/aceite.
5.2.6 Teste de Acessibilidade

importante considerar a acessibilidade do software para requisitos particulares ou restries em seu uso. Isso inclui pessoas que apresentam incapacidades. Devem ser consideradas as normas relevantes, tais como Web Content Accessibility Guidelines, e a legislao, tal como Disability Discrimination Acts (UK, Austrlia) e Section 508 (US).
5.3 Atributos de Qualidade para o Teste Tcnico

Atributos de qualidade para Technical Test Analysts so direcionados para como o produto trabalha, e no para aspectos funcionais como o qu ele faz. Esses testes podem ser realizados em qualquer nvel de teste, mas tem relevncia particular para:
Verso 2007br
Pgina 68 de 124
02 Fev 2010
Certified Tester
Teste de Componente (especialmente para sistemas de tempo real e sistemas embarcados) Benchmarking de desempenho Uso de recurso Teste de Sistema e Teste de Aceite Operacional (OAT) Inclui qualquer atributo de qualidade e subatributos mencionados a seguir, de acordo com os riscos e recursos disponveis. Testes orientados tecnicamente nesse nvel so destinados ao teste de um sistema especfico, isso , combinaes de hardware e software, incluindo servidores, clientes, banco de dados, redes de interconexo e outros recursos Frequentemente, os testes continuam a ser executados depois do software ter entrado em produo, frequentemente por uma equipe ou empresa separada. Medies de atributos de qualidade coletados em testes de pr-produo podem formar uma base para Acordos de Nvel de Servio (SLA) entre o fornecedor e o operador do sistema de software. Os seguintes atributos de qualidade so considerados: Segurana tcnica Confiabilidade Eficincia Mantenabilidade Portabilidade
5.3.1 Teste Tcnico de Segurana

Testes de segurana diferem de outras formas de teste de domnio ou tcnico em duas reas significativas: 1. Tcnicas padro para selecionar dados de entrada podem perder importantes objetivos de segurana. 2. Os sintomas de falta de segurana so muito diferentes daqueles encontrados em outros tipos de teste Existem muitas vulnerabilidades de segurana nas quais o software no s funciona como projetado, mas tambm realiza aes extras que no foram intencionadas. Esses efeitos colaterais representam uma grande ameaa para a segurana de software. Por exemplo, um tocador de mdia que corretamente toca udio, porm o faz atravs da escrita de arquivos de sada para armazenamento temporrio no criptografado apresenta um efeito colateral que pode de ser explorado por piratas de software. A principal preocupao em relao segurana impedir a informao de uso no intencionado por pessoas no autorizadas. O teste de segurana busca o compromisso da poltica de segurana do sistema atravs da avaliao da vulnerabilidade do sistema a ameaas, tais como: Cpia no autorizada de aplicaes ou dados (por exemplo, pirataria) Controle de acesso no autorizado (por exemplo, capacidade de realizar tarefas para os quais o usurio no tem direitos) Overflow de buffer (transposio de buffer), o qual pode ser causado pela entrada de strings extremamente longas em um campo de entrada da interface do usurio. Uma vez que causado o overflow do buffer, pode existir uma oportunidade de executar instrues de cdigo malicioso. Negao de servio, o qual impede o usurio de interagir com uma aplicao (por exemplo, atravs da sobrecarga de um servidor web com requisitos de estorvo) Escuta de transferncia de dados atravs de redes de interconexo para que obtenha informaes sensveis (por exemplo, em transaes de carto de crdito) Quebra de cdigos criptografados usados para proteger dados sensveis
Verso 2007br
Pgina 69 de 124
02 Fev 2010
Certified Tester
Bombas lgicas (algumas vezes chamados de Ovos de Pscoa nos EUA), as quais podem ser cdigos maliciosos inseridos no cdigo e o qual ativado somente sob certas condies (por exemplo, em uma data especfica). Quando bombas lgicas so ativadas, elas podem realizar atos maliciosos tal como apagar arquivos ou formatar discos. Preocupaes particulares de segurana podem ser agrupadas como a seguir: Relacionado interface de usurio o Acesso no autorizado o Entradas maliciosas Relacionado ao sistema de arquivo o Acesso a dado sensvel armazenado em arquivos ou repositrios Relacionado ao sistema operacional o Armazenamento de informao sensvel tal como senhas em formato no criptografado na memria. Quebrando o sistema atravs de entrada maliciosa pode exportar tais informaes Relacionado ao software externo o Interaes que podem ocorrer entre componentes externos que o sistema utiliza. Essas interaes podem ser em nvel de sistema (por exemplo, pacotes incorretos ou mensagens passadas), ou em nvel de componente de software (por exemplo, falha de um componente de software no qual o software confia). Deve ser observado que melhorias que so feitas na segurana do sistema podem afetar seu desempenho. Aps fazer melhorias na segurana aconselhvel considerar a repetio dos testes de desempenho. 5.3.1.1 Especificao de Teste de Segurana A seguinte abordagem pode ser usada para desenvolver testes de segurana: Realizar recuperao de informao Um perfil ou mapa de rede do sistema construdo usando ferramentas largamente disponveis. Essa informao pode incluir nomes de funcionrios, endereos fsicos, detalhes internos da rede de interconexo, nmeros de IP, identidade do software ou hardware usado e verso do sistema operacional. Realizar uma varredura por vulnerabilidade O sistema varrido usando ferramentas largamente disponveis. Tais ferramentas no so usadas diretamente para comprometer os sistemas, mas para identificar vulnerabilidade que so, ou que podem resultar em, uma brecha na poltica de segurana. Vulnerabilidades especficas tambm podem ser identificadas usando listas de checagem tais como as fornecidas em www.testingstandards.co.uk. Desenvolver planos de ataque (ou seja, um plano de aes de teste com a inteno de comprometer alguma poltica de segurana do sistema em particular) usando a informao recolhida. Vrias entradas atravs de vrias interfaces (por exemplo, interface de usurio, sistema de arquivo) necessitam ser especificadas nos planos de ataque para detectar as faltas mais severas de segurana. Os vrios ataques descritos em [Whittaker04] so uma fonte valiosa de tcnicas desenvolvidas especificamente para teste de segurana. Para mais informaes sobre ataques referencie a seo 4.4.
5.3.2 Teste de Confiabilidade

Um objetivo do teste de confiabilidade monitorar a medio estatstica da maturidade do software no tempo e compar-la com o objetivo de confiabilidade desejado. As medies podem ter o formato de Mdia de Tempo Entre Falhas (MTBF Mean Time Between Failures), Mdia de Tempo de Conserto (MTTR Mean Time to Repair) ou outra forma de falha intensivamente medida (por exemplo, o nmero de falhas por semana de uma severidade em particular). O desenvolvimento dos
Verso 2007br
Pgina 70 de 124
02 Fev 2010
Certified Tester
valores monitorados pelo tempo pode ser expresso como um Modelo de Crescimento de Confiabilidade. O teste de confiabilidade pode tomar a forma de um conjunto repetido de testes predeterminados, testes aleatrios selecionados de um reservatrio ou casos de teste gerados de um modelo estatstico. Como resultado, esses testes podem tomar um tempo significativo (da ordem de dias). Anlise das medidas de maturidade do software pelo tempo pode ser usada como critrio de sada (por exemplo, para a liberao para produo). Medies especficas como MTBF e MTTR podem ser estabelecidas como Acordos de Nvel de Servio e monitoradas em produo. Engenharia e Teste de Confiabilidade de Software (SRET Software Reliability Engineering and Testing ) uma abordagem padro para o teste de confiabilidade. 5.3.2.1 Testes de Robustez Enquanto o teste funcional pode avaliar a tolerncia do software s faltas em termos de manipulao de valores de entrada no esperados (conhecidos como testes negativos), testes orientados tecnicamente avaliam a tolerncia de um sistema s faltas que ocorrem externamente aplicao sob teste. Tais faltas so tipicamente reportadas pelo sistema operacional (por exemplo, disco cheio, processo ou servio no disponveis, arquivo no encontrado, memria no disponvel). Testes de tolerncia a faltas em nvel de sistema podem ser apoiados por ferramentas especficas. 5.3.2.2 Teste de Recuperabilidade Outras formas de teste de confiabilidade avaliam a capacidade do sistema de software em recuperar de falhas de hardware e software de uma forma pr-determinada a qual subsequentemente permite reiterar operaes normais. Os testes de recuperabilidade incluem testes de Failover e Backup & Restore. Testes de failover so realizados onde as consequncias da falha do software so to altas que medidas especficas de hardware e/ou software so implementadas para garantir a operao do sistema mesmo na ocorrncia de uma falha. Testes de failover podem ser aplicados, por exemplo, onde o risco de perdas financeiras extremo ou onde existem questes de segurana crtica. Onde falhas podem resultar de eventos catastrficos essa forma de teste de recuperabilidade pode tambm ser chamada de teste de recuperao de desastre. Medidas tpicas tomadas em relao ao hardware podem incluir o balanceamento de carga pelos vrios processadores, aglomerados de servidores, processadores ou discos de forma que um deles imediatamente assume o controle na falha e outro (por exemplo, RAID: Redundant Array of Inexpensive Disks). Uma medida tpica tomada em relao ao software poderia ser a implementao de mais de uma instncia independente do sistema de software (por exemplo, um sistema de controle de voo de avies) conhecida como sistemas heterogneos de redundncia. Sistemas redundantes tipicamente so uma combinao medidas de software e hardware e podem ser chamados de sistemas duplex, triplex ou quadruplex, dependendo do nmero de instncias independentes (2, 3, ou 4, respectivamente). O aspecto heterogneo do software alcanado quando os mesmos requisitos de software so fornecidos a duas (ou mais) equipes independentes e no conectadas de desenvolvimento, com o objetivo de ter os mesmos servios fornecidos por software diferentes. Isso protege os sistemas de redundncia heterognea na medida em que uma entrada defeituosa similar menos propensa a apresentar o mesmo resultado. Essas medidas tomadas para melhorar a recuperabilidade do sistema podem influenciar diretamente na sua confiabilidade tambm e pode ainda ser considerada na realizao dos testes de confiabilidade. O teste de failover projetado para testar explicitamente tais sistemas atravs da simulao dos modos de falha e executando-os em um ambiente controlado. Depois da falha o mecanismo de failover testado para garantir que o dado no est perdido ou corrompido e que quaisquer nveis de servio combinado esto mantidos (por exemplo, disponibilidade de funo, tempos de resposta). Para mais informaes sobre o teste de failover, veja www.testingstandards.co.uk.
Verso 2007br
Pgina 71 de 124
02 Fev 2010
Certified Tester
Testes de Backup e Restore tm o foco em medidas procedurais estabelecidas para minimizar os efeitos de uma falha. Tais testes avaliam os procedimentos (normalmente documentados em um manual) para tomar diferentes formas de backup e para a recuperao de tal dado no caso que uma perda ou corrupo de dados. Os casos de teste so modelados para garantir que caminhos crticos do procedimento sejam cobertos. Revises tcnicas podem ser realizadas para fazer uma execuo prtica nesses cenrios e validar os manuais mediante o procedimento real de instalao. Testes de Aceite Operacional (OAT Operational Acceptance Test) exercitam os cenrios em um ambiente de produo ou semelhante a ele para validar seu uso real. Medidas para testes de Backup e Restore podem incluir o seguinte: Tempo tomado para realizar diferentes tipos de backup (por exemplo, completo, incremental) Tempo tomado para recuperao do dado Nveis de garantia do backup do dado (por exemplo, recuperao de todo dado no mais antigos que 24 horas, recuperao de dados de uma transao especfica no mais antigos do que uma hora)
5.3.2.3 Especificao de Teste de Confiabilidade Os testes de confiabilidade so em sua maioria baseados em padres de uso (algumas vezes referenciados como Perfis Operacionais) e podem ser realizados formalmente ou de acordo com o risco. O dado de teste pode ser gerado usando mtodos randmicos ou pseudorandmicos. A escolha da curva de crescimento de confiabilidade deveria ser justificada e ferramentas podem ser usadas para analisar um conjunto de dados de falhas para determinar a curva de crescimento de confiabilidade que melhor se ajusta ao dado correntemente disponvel. Testes de confiabilidade podem procurar especificamente por vazamentos de memria. A especificao de tais testes requer que aes especficas e intensivas quanto memria sejam executadas repetidamente para garantir que a memria reservada est sendo corretamente liberada.
5.3.3 Teste de Eficincia

O atributo de qualidade de eficincia avaliado atravs da conduo de testes direcionados no comportamento temporal e dos recursos. O teste de eficincia relacionado ao comportamento temporal coberto a seguir, sob os aspectos de teste de desempenho, carga, estresse e escalabilidade. 5.3.3.1 Teste de Desempenho O teste de desempenho em geral pode ser categorizado em diferentes tipos de teste de acordo com os requisitos no-funcionais em foco. Os tipos de teste incluem teste de desempenho, carga, estresse e escalabilidade. Teste especfico de desempenho tem o foco na capacidade de um componente ou sistema em responder ao usurio ou s entradas do sistema dentro de um tempo especificado e das condies especificadas (veja tambm carga e estresse abaixo). Medies de desempenho variam de acordo com os objetivos do teste. Para componentes de software individuais o desempenho pode ser medido de acordo com os ciclos de CPU, enquanto que para sistemas baseados no cliente o desempenho pode ser medida de acordo com o tempo tomado para a resposta a uma requisio em particular do usurio. Para sistemas cujas arquiteturas consistem de vrios componentes (por exemplo, clientes, servidores, banco de dados) as medidas de desempenho so tomadas entre componentes individuais e com isso gargalos de desempenho podem ser identificados. 5.3.3.2 Teste de Carga O teste de carga tem o foco na capacidade do sistema em tratar de nveis crescentes de cargas realistas e previstas que so resultantes de requisies de transaes geradas por vrios usurios
Verso 2007br
Pgina 72 de 124
02 Fev 2010
Certified Tester
em paralelo. O tempo mdio de resposta aos usurios sob cenrios diferentes de uso tpico (perfis operacionais) pode ser medido e analisado. Veja tambm [Splaine01] Existem dois subtipos de teste de carga, teste de multiusurio (com nmeros realsticos de usurios) e de volume (com um grande nmero de usurios). Testes de carga visam tanto os tempos de resposta quanto sada de rede. 5.3.3.3 Teste de Estresse O teste de estresse tem o foco na capacidade do sistema em tratar de picos de carga em um mximo de capacidade, ou alm. O desempenho do sistema deve degradar lentamente e de forma previsvel sem falhar com o crescimento do nvel de estresse. Em particular, a integridade funcional do sistema deve ser testada enquanto o sistema est sob estresse para encontrar possveis faltas no processamento funcional ou inconsistncia de dados. Um possvel objetivo de teste de estresse descobrir os limites nos quais um sistema efetivamente falha para que o elo mais fraco da corrente seja determinado. O teste de estresse permite que componentes adicionais sejam anexados ao sistema de forma oportuna (por exemplo, memria, capacidade de CPU, armazenamento de banco de dados). Em um teste de picos, combinaes de condies que podem resultar em uma carga extrema e repentina sendo aplicada ao sistema so simuladas. Testes de ressaltos aplicam vrios desses picos ao sistema com perodos de pouco uso entre os picos. Esses testes determinaro quo bem o sistema trata das mudanas de carga e quando ele capaz de reivindicar e liberar recursos conforme necessrio. Veja tambm [Splaine01]. 5.3.3.4 Teste de Escalabilidade O teste de escalabilidade tem o foco na capacidade do sistema em corresponder a requisitos futuros de eficincia, os quais podem estar alm daqueles atualmente requeridos. O objetivo dos testes julgar a capacidade do sistema em crescer (ou seja, com mais usurios, maior quantidade de dados armazenados) sem exceder os limites combinados ou falhar. Uma vez que esses limites so conhecidos, valores iniciais podem ser ajustados e monitorados em produo para fornecer um aviso de problemas impeditivos. 5.3.3.5 Teste de Utilizao de Recursos Os testes de eficincia relacionados utilizao de recurso avaliam o uso dos recursos do sistema (por exemplo, espao de memria, capacidade do disco e largura de banda da rede). Esses so comparados tanto em cargas normais como para situaes de estresse, tais como altos nveis de transao e volumes de dados. Por exemplo, para um sistema de tempo real embarcado, o uso de memria (algumas vezes referenciados como memory footprints, ou o uso de memria principal) apresenta um papel significativo no teste de desempenho. 5.3.3.6 Especificao de Teste de Eficincia A especificao dos testes para os tipos de teste de eficincia tais como desempenho, carga e estresse so baseados na definio de perfis operacionais. Eles representam formas distintas de comportamento do usurio na interao com a aplicao. Pode haver vrios perfis operacionais para uma dada aplicao. Os vrios usurios por perfil operacional podem ser obtidos pela utilizao de ferramentas de monitoramento (onde a aplicao real ou comparvel j est disponvel) ou pela previso de uso. Tais previses podem ser baseadas em algoritmos ou fornecidas pela empresa do negcio, e so especialmente importantes para especificar o perfil operacional para o teste de escalabilidade.
Verso 2007br
Pgina 73 de 124
02 Fev 2010
Certified Tester
Perfis operacionais formam a base para os casos de teste e so tipicamente gerados usando ferramentas de teste. Nesse caso, o termo usurio virtual comumente usado para representar um usurio simulado dentro do perfil operacional.
5.3.4 Teste de Mantenabilidade

Os testes de mantenabilidade so relacionados geralmente facilidade com a qual o software pode ser analisado, alterado e testado. Tcnicas apropriadas para teste de mantenabilidade incluem anlise esttica e listas de checagem. 5.3.4.1 Teste Dinmico de Mantenabilidade O teste dinmico de mantenabilidade tem o foco nos procedimentos documentados desenvolvidos para manuteno de uma aplicao particular (por exemplo, para realizar atualizaes de software). Selees de cenrios de manuteno so usadas como casos de teste para garantir que os nveis requeridos de servio sejam atingveis com os procedimentos documentados. Essa forma de teste particularmente relevante onde a infraestrutura interna complexa, e os procedimentos apoiados podem envolver mltiplos departamentos/empresas. Essa forma de teste pode acontecer como parte do Teste de Aceite Operacional (OAT). [www.testingstandards.co.uk] 5.3.4.2 Capacidade de Anlise (manuteno corretiva) Essa forma de teste de mantenabilidade tem o foco na medio do tempo tomado para diagnosticar e corrigir problemas identificados dentro de um sistema. Uma simples medida pode ser o tempo mdio tomado para diagnosticar e corrigir uma falta identificada. 5.3.4.3 Capacidade de Mudana, Estabilidade e Testabilidade (manuteno adaptativa) A mantenabilidade de um sistema tambm pode ser mensurada em termos do esforo requerido para realizar mudanas quele sistema (por exemplo, mudanas de cdigo). Ao passo que o esforo necessrio dependente de vrios fatores tais como a metodologia de modelagem de software (por exemplo, orientao a objetos), padres de cdigo, etc., essa forma de teste de mantenabilidade tambm pode ser realizada por anlise ou reviso. A testabilidade relacionada especificamente ao esforo requerido para testar as alteraes feitas. A estabilidade relacionada especificamente resposta do sistema mudana. Os sistemas com baixa estabilidade exibem um grande nmero de problemas que derrubam o sistema (tambm conhecidos como efeito oscilatrio) toda vez que uma alterao realizada. [ISO9126] [www.testingstandards.co.uk]
5.3.5 Teste de Portabilidade

Os testes de portabilidade so relacionados geralmente facilidade com que cada software pode ser transferido para o ambiente intencionado, tanto de um novo como de um ambiente existente. Testes de portabilidade incluem testes para capacidade de instalao, coexistncia/compatibilidade, capacidade de adaptao e capacidade de substituio. 5.3.5.1 Teste de Instalabilidade O teste de instalabilidade conduzido no software usado para instalar outro software no seu ambiente alvo. Isso pode incluir, por exemplo, o software desenvolvido para instalar o sistema operacional em um processador, ou um assistente de instalao usado para instalar um produto em um PC do cliente. Objetivos comuns ao teste de instalabilidade incluem: Validao de que o software pode ser instalado com sucesso seguindo as instrues em um manual de instalao (incluindo a execuo de qualquer script de instalao), ou atravs da utilizao de um instalador. Isso inclui exercitar opes de instalao para diferentes configuraes de hardware/software e para vrios graus de instalao (por exemplo, completa ou parcial)
Verso 2007br
Pgina 74 de 124
02 Fev 2010
Certified Tester
Testar quando falhas que ocorreram durante a instalao (por exemplo, falha para carregar DLLs em particular) so tratadas corretamente pelo software de instalao sem deixar o sistema em um estado indefinido (por exemplo, com o software parcialmente instalado ou com configuraes incorretas do sistema) Testar quando uma instalao/desinstalao parcial pode ser completada Testar quando um instalador pode identificar com sucesso uma plataforma de hardware ou configuraes de sistema operacional invlidas Medir quando o processo de instalao pode ser completado dentro de um nmero especificado de minutos ou em um nmero menor de passos do que especificado Validao de que o software pode ser atualizado com diminuio de recursos (downgraded) ou desinstalado O teste de funcionalidade comumente conduzido aps o teste de instalao para detectar quaisquer faltas que possam ter sido introduzidas pela instalao (por exemplo, configuraes incorretas, funo indisponveis). O teste de usabilidade comumente conduzido em paralelo ao teste de instalabilidade (por exemplo, para validar que os usurios esto providos com instrues compreensveis e mensagens de feedback/erro durante a instalao). 5.3.5.2 Coexistncia Os sistemas computacionais que no so relacionados uns aos outros so ditos compatveis quando eles conseguem executar no mesmo ambiente (por exemplo, no mesmo hardware) sem afetar o comportamento entre eles (por exemplo, conflitos de recurso). Testes de compatibilidade podem ser realizados, por exemplo, onde um software novo ou atualizado recebido nos ambientes (por exemplo, servidores) que j contm aplicaes instaladas. Problemas de compatibilidade podem ser originados quando a aplicao testada em um ambiente no qual ela a nica aplicao instalada (quando questes de incompatibilidade no so detectveis) e ento implantada em um outro ambiente no qual outras aplicaes tambm executam (como o de produo). Objetivos comuns ao teste de compatibilidade incluem: Avaliao de possveis impactos adversos em funcionalidades quando as aplicaes so carregadas no mesmo ambiente (por exemplo, uso conflitante de recursos quando um servidor executa mltiplas aplicaes). Avaliao do impacto a qualquer aplicao resultante da implantao de correes e atualizaes no sistema operacional. O teste de compatibilidade normalmente realizado quando os testes de sistema e aceite de usurio tenham sido completados com sucesso. 5.3.5.3 Teste de Capacidade de Adaptao O teste de capacidade de adaptao testa quando uma determinada aplicao pode funcionar corretamente em todos os ambientes alvo intencionados (hardware, software, middleware, sistema operacional, etc.). Especificar testes para a capacidade de adaptao requer que combinaes dos ambientes alvo intencionados sejam identificados, configurados e disponveis equipe de teste. Esses ambientes so ento testados usando uma seleo de casos de teste funcional os quais exercitam os vrios componentes presentes no ambiente. A capacidade de adaptao pode ser relacionada habilidade do software em ser levado a vrios ambientes especificados atravs da realizao de procedimentos predefinidos. Os testes podem avaliar esse procedimento. Os testes de capacidade de adaptao podem ser efetuados em conjunto com os testes de instalabilidade e so tipicamente seguidos por testes funcionais para detectar quaisquer faltas que possam ter sido introduzidas na adaptao do software a diferentes ambientes.
Verso 2007br
Pgina 75 de 124
02 Fev 2010
Certified Tester
5.3.5.4 Teste de Capacidade de Substituio A capacidade de substituio tem foco na habilidade dos componentes de software dentro de um sistema em ser trocado por outros. Isso pode se particularmente relevante para sistemas que usam software de prateleira (COTS) para componentes especficos de sistema. Os testes de capacidade de substituio podem ser realizados em paralelo aos testes de integrao funcional onde mais de um componente alternativo est disponvel para integrao no sistema completo. A capacidade de substituio pode ser avaliada por reviso tcnica ou inspeo, na qual a nfase colocada em uma definio clara de interfaces para possveis componentes de substituio.
Verso 2007br
Pgina 76 de 124
02 Fev 2010
Certified Tester
6. Revises
Termos
Auditoria, IEEE 1028, reviso informal, inspeo, lder de inspeo, reviso gerenciada, moderador, reviso, revisor, reviso tcnica, acompanhamento/walkthrough.
6.1 Introduo
Um processo de reviso de sucesso necessita de planejamento, participao e acompanhamento. Provedores de treinamento necessitaro se assegurar que os gerentes de teste entendem suas responsabilidades com as atividades de planejamento e acompanhamento. Os testadores devem ser participantes ativos no processo de reviso, fornecendo suas vises nicas. Eles devem ser formalmente treinados em revises para melhor entendimento de seus respectivos papis em qualquer processo de reviso tcnica. Todos os participantes de revises devem entender os benefcios de uma reviso tcnica bem conduzida. Quando feita de forma apropriada, as inspees so os maiores e os mais eficientes fatores para a qualidade geral em termos de custo. Uma norma internacional sobre revises a IEEE 1028.
6.2 Os Princpios das Revises

Uma reviso um tipo de teste esttico. As revises frequentemente apresentam como principal objetivo a deteco de defeitos. Os revisores encontram defeitos atravs de exame direto dos documentos. Os tipos fundamentais de revises so descritos na seo 3.2 do Foundation Level Syllabus (verso 2007br) e so listadas abaixo na seo 6.3. Todos os tipos de reviso so mais bem executados assim que os documentos fonte relevantes (documentos que descrevem os requisitos do projeto) e padres (aos quais o projeto deve aderir) esto disponveis. Se algum dos documentos ou padres est faltando, ento as faltas e inconsistncias pelos documentos podem no ser descobertas, somente aquelas em um documento podem ser encontradas. Os revisores devem receber os documentos a serem revisados em tempo hbil para permitir que eles se tornem familiares com o contedo dos documentos. Todos os tipos de documentos podem ser sujeitos reviso, por exemplo, cdigo fonte, especificao de requisitos, conceitos, planos de teste, documentos de teste, etc. O teste dinmico normalmente sucede uma reviso de cdigo fonte; ele destinado a encontrar quaisquer defeitos que no podem ser encontrados por um exame esttico. Uma reviso pode conduzir para trs possveis resultados: O documento pode ser usado inalterado ou com mudanas menores O documento pode ser mudado, mas uma reviso adicional no ser necessria O documento deve ser extensivamente alterado e uma reviso adicional necessria Os papis e responsabilidades dos envolvidos em uma reviso formal tpica so cobertos no Syllabus Foundation, ou seja, gerente, moderador ou lder, autor, revisores e secretrio. Outros que podem ser envolvidos em revises incluem tomadores de deciso ou stakeholders e representantes do cliente ou usurio. Um papel opcional algumas vezes usado em inspees o leitor, o qual destinado a parafrasear sees do produto de trabalho no encontro de reviso. Em complemento aos papis de reviso, revisores individuais podem ser designados a um papel direcionado a defeito para verificar tipos particulares de defeito.
Verso 2007br
Pgina 77 de 124
02 Fev 2010
Certified Tester
Mais do que um tipo de reviso pode ser aplicado em um mesmo produto. Por exemplo, uma equipe pode realizar uma reviso tcnica para decidir quais funcionalidades implementar em uma prxima iterao. Uma inspeo pode ser realizada nas especificaes para as funcionalidades includas.
6.3 Tipos de Reviso

O Syllabus Foundation introduziu os seguintes tipos de reviso: Reviso informal Acompanhamento ou walkthrough Reviso tcnica Inspeo Hbridos desses tipos de reviso podem ser vistos na prtica, tais como uma reviso tcnica usando um conjunto de regras.
6.3.1 Reviso Gerencial e Auditoria

Alm dos tipos mencionados no Syllabus Foundation, a IEEE 1028 tambm descreve os seguintes tipos de reviso: Reviso gerencial Auditoria As caractersticas chave de uma reviso gerencial so: Objetivos principais: monitorar progresso, verificar status e tomar decises a respeito aes futuras Conduzidas por ou para gerentes com responsabilidade direta sobre o projeto ou sistema Conduzidas por ou para um stakeholder ou tomador de deciso, por exemplo, um gerente alto nvel ou diretor Verifica consistncia com e desvios dos planos, ou adequao de procedimentos gerenciamento Inclui verificao de riscos do projeto Sada inclui itens e aes de ao a serem resolvidos esperado que os participantes se preparem, e decises sejam documentadas Note que os gerentes de teste devem participar e podem incitar revises gerenciais de progresso teste. de
de de
de
Auditorias so extremamente formais e so realizadas comumente para demonstrar a conformidade com algum conjunto de expectativas, como uma norma aplicvel ou uma obrigao contratual. Como tais, auditorias so menos efetivas para revelar defeitos. As caractersticas chave de uma auditoria so: Objetivo principal: fornecer avaliao independente de conformidade com processos, regras, padres, etc. O auditor que est conduzindo responsvel pela auditoria e atua como moderador Auditores juntam evidncias de aderncia atravs de entrevistas, verificao de indcios e exame de documentos Sadas incluem observaes, recomendaes, aes corretivas e verificaes de passa/falha
6.3.2 Revises de Produtos de Trabalho Especficos

Revises podem ser descritas em termos de produtos de trabalho ou atividades sujeitas a reviso, tais como: Reviso contratual
Verso 2007br
Pgina 78 de 124
02 Fev 2010
Certified Tester
Reviso de requisitos Reviso de modelagem o Reviso de modelagem preliminar o Reviso de modelagem crtica Reviso de aceite / reviso de qualificao Reviso de prontido operacional Uma reviso contratual pode ser associada com um marco de contrato, e poderia ser comumente uma reviso gerencial para um sistema de segurana crtica ou relacionado segurana. Ela poderia envolver gerentes, clientes e equipe tcnicas. Uma reviso de requisitos pode ser um acompanhamento, reviso tcnica ou inspeo, e pode considerar requisitos de segurana e dependabilidade assim como requisitos funcionais e nofuncionais. Uma reviso de requisitos pode incluir critrio de aceite e condies de teste. Revises de modelagem so tipicamente revises tcnicas ou inspees, e envolvem equipe tcnica e clientes ou stakeholders. A Reviso de Modelagem Preliminar apresenta uma abordagem inicial para algumas modelagens e testes tcnicos; a Reviso de Modelagem Crtica cobre todas as solues de modelagem propostas, incluindo os casos de teste e procedimentos. Revises de aceite obtm a aprovao da gerncia para um sistema. Isso referenciado como uma reviso de qualificao, e normalmente uma reviso gerencial ou uma auditoria.
6.3.3 Execuo de uma Reviso Formal

O Syllabus Foundation descreve seis fases de uma reviso formal: planejamento, kick-off, preparao individual, encontro de reviso, retrabalho e acompanhamento. O produto de trabalho a ser revisado deve ser apropriado para a qualificao ou para a reviso, ou seja, um Plano de Teste para um gerente de teste, requisitos de negcio ou modelagem de teste para um analista de teste, ou especificao funcional, casos de teste, ou scripts de teste para analistas tcnicos de teste.
6.4 Introduo s Revises

Para que as revises sejam introduzidas com sucesso em uma organizao, os seguintes passos devem acontecer (no necessariamente nessa ordem): Assegurar suporte da gerncia Instruir os gerentes sobre questes de custos, benefcios e implementao Selecionar e documentar os procedimentos de reviso, formulrios e infraestrutura (por exemplo, banco de dados de mtricas de reviso) Treinar a equipe em tcnicas e procedimentos de reviso Obter suporte das pessoas que participaro da reviso e das que tero seu trabalho revisado Executar revises piloto Demonstrar o benefcio de revises atravs da economia nos custos Aplicar revises nos documentos mais importantes, por exemplo, requisitos, contratos, planos, etc.
Mtricas como reduo ou preveno de custos para correo de defeitos e/ou suas consequncias podem ser usadas para avaliar o sucesso da introduo de revises. A economia tambm pode ser medida em tempo que foram resguardados por encontrar e corrigir defeitos precocemente. Os processos de reviso devem ser continuamente monitorados e melhorados no decorrer do tempo. Gerentes devem estar conscientes que o aprendizado de uma nova tcnica de reviso um
Verso 2007br
Pgina 79 de 124
02 Fev 2010
Certified Tester
investimento os benefcios no so instantneos, entretanto crescero significativamente com o tempo.
6.5 Fatores de Sucesso para Revises

So vrios os fatores que contribuem para o sucesso de revises. As revises no so necessariamente difceis de serem realizadas, mas elas podem falhar de vrias formas se fatores como os listados abaixo no forem considerados. Fatores Tcnicos Garanta que o processo definido para o tipo de reviso seja seguido corretamente, particularmente para tipos mais formais de reviso tais como inspees Registre os custos das revises (incluindo o tempo gasto) e os benefcios alcanados Revise os rascunhos iniciais ou documentos parciais para identificar padres de defeito antes que eles sejam inseridos em todo o documento Garanta que os documentos (completos ou parciais) estejam prontos para reviso antes de iniciar um processo de reviso (ou seja, aplique o critrio de entrada) Use listas de verificao especficas da organizao para defeitos comuns Use mais de um tipo de reviso, dependendo dos objetivos, tais como organizao de documento, melhoria tcnica, transferncia de informao ou gerenciamento de progresso Revise ou inspecione documentos com os quais decises importantes sero tomadas, por exemplo, inspecione a proposta, contrato ou requisitos de alto nvel antes de uma reviso gerencial autorizar despesas maiores no projeto Amostre um subconjunto limitado de um documento para anlise (no organizao de documento) Incentive a procura pelos defeitos mais importantes: foco no contedo no no formato Melhore continuamente o processo de reviso
Fatores Organizacionais Garanta que os gerentes permitam que tempo adequado seja gasto nas atividades de reviso, mesmo sob presses de prazo Lembre que tempo e oramento gastos no so proporcionais aos erros encontrados Reserve tempo adequado para retrabalho dos defeitos identificados pelos revisores Nunca use as mtricas de revises para estimativa de desempenho individual Garanta que as pessoas certas estejam envolvidas nos diferentes tipos de reviso Fornea treinamentos em revises, particularmente para tipos de reviso mais formais Apoie um frum de lderes de reviso par compartilhar experincia e ideias Garanta que todos participem em revises e que todos tenham seus prprios documentos revisados Aplique as tcnicas de reviso mais intensas nos documentos mais importantes Garanta uma equipe de reviso bem balanceada com pessoas com diferentes habilidades e experincia Apoie aes de melhoria do processo para corresponder a problemas sistemticos Reconhea as melhorias atingidas atravs do processo de reviso
Fatores Pessoais Instrua os stakeholders a esperar os defeitos que sero encontrados e a permitir tempo para retrabalho e nova reviso Garanta que a reviso uma experincia positiva para o autor
Verso 2007br
Pgina 80 de 124
02 Fev 2010
Certified Tester
Acolha a identificao de defeitos em uma atmosfera sem acusaes Garanta que os comentrios sejam construtivos, teis e objetivos, no subjetivos No realize uma reviso se o autor no concorda ou no deseja Encoraje a todos a pensar profundamente sobre os aspectos mais importantes dos documentos sendo revisados Para mais sobre revises e inspees veja [Gilb93] e [Weigers02].
Verso 2007br
Pgina 81 de 124
02 Fev 2010
Certified Tester
7. Gerenciamento de Incidente
Termos
IEEE 829, IEEE 1044, IEEE 1044.1, anomalia, comit de controle de configurao, defeito, erro, falha, incidente, registro de incidente, prioridade, anlise de causa raiz, severidade
7.1 Introduo
Gerentes de teste e testadores devem estar familiares com processos de gerenciamento de defeito. Os gerentes de teste tm foco no processo, incluindo mtodos para reconhecer, rastrear e remover defeitos. Os testadores esto preocupados primariamente em registrar precisamente as questes encontradas em suas reas de teste. Para cada passo do ciclo de vida de desenvolvimento de software, analistas de teste e analistas tcnicos de teste tero orientaes diferentes. Os analistas de teste avaliaro o comportamento em termos de negcio e necessidade do usurio, por exemplo, se o usurio saberia o que fazer quando encontrasse determinada mensagem ou comportamento. O analista tcnico de teste avaliaria o comportamento do software propriamente dito e faria novas investigaes tcnicas sobre o problema, por exemplo, testando a mesma falha em plataformas diferentes ou com configuraes diferentes de memria.
7.2 Quando um Defeito Pode Ser Detectado?

Um incidente uma ocorrncia inesperada que necessita maiores investigaes. Um incidente o reconhecimento de uma falha causada por um defeito. Um incidente pode ou no resultar na gerao de um relatrio de defeito. Um defeito um problema real que foi determinado e que necessita de resoluo atravs de mudana do item de trabalho. Um defeito pode ser detectado atravs de teste esttico. Uma falha somente pode ser detectada atravs de teste dinmico. Cada fase do ciclo de vida do software deve fornecer um mtodo para detectar e eliminar falhas em potencial. Por exemplo, durante a fase de desenvolvimento, revises de cdigo e modelagem devem ser usadas para detectar defeitos. Durante o teste dinmico, casos de teste so usados para detectar falhas. Quanto mais cedo um defeito detectado e corrigido, menor o custo de qualidade para o sistema como um todo. Deve ser lembrado que defeitos podem existir no testware assim como no objeto sob teste.
7.3 Ciclo de Vida do Defeito

Todos os defeitos tm um ciclo de vida, apesar de que alguns podem omitir alguns estgios. O ciclo de vida do defeito (como descrito em IEEE 1044-1993) composto por quatro passos, mais bem descritos a seguir: Passo 1: Reconhecimento Passo 2: Investigao Passo 3: Ao Passo 4: Disposio Dentro de cada passo existem trs atividades de captura de informao: Registro Classificao Identificao de impacto
Verso 2007br
Pgina 82 de 124
02 Fev 2010
Certified Tester
7.3.1 Passo 1: Reconhecimento

O passo de Reconhecimento acontece quando um defeito em potencial (incidente) descoberto. Isso pode ocorrer em qualquer fase do Ciclo de Vida do Software. Na descoberta, os itens de dados so identificados e os defeitos so registrados. Isso inclui informaes tais como sobre o ambiente no qual o defeito foi observado, o criador, informaes de descrio, a hora e o fornecedor (se aplicvel). O reconhecimento classificado pela identificao de certos atributos dos defeitos em potencial, incluindo atividade de projeto, fase de projeto, causa suspeita, repetibilidade, sintomas e status do produto como resultado da anomalia. Com essa informao, o impacto medido pela relao de severidade, impacto no planejamento do projeto e impacto no custo do projeto.
7.3.2 Passo 2: Investigao

Aps o Reconhecimento, cada defeito em potencial investigado. Esse passo primariamente usado para encontrar qualquer questo relacionada e propostas de solues, as quais podem incluir nenhuma ao (por exemplo, se o defeito em potencial no mais considerado um defeito real). Dados adicionais so registrados nesse passo assim como uma reavaliao da classificao e informao de impacto fornecidas no passo anterior.
7.3.3 Passo 3: Ao
Baseado nos resultados da Investigao iniciado o passo da Ao. Aes incluem aquelas requeridas para resolver o defeito assim como quaisquer aes indicadas para reviso/melhoria de processos e polticas para preveno de futuros defeitos similares. Teste de regresso e reteste, assim como teste de progresso devem ser realizados para cada mudana. Dados adicionais so registrados nesse passo, assim como uma reavaliao da classificao e informao de impacto fornecidas no passo anterior.
7.3.4 Passo 4: Disposio

A anomalia passa ento ao passo de Disposio, no qual qualquer item de dado adicional registrado e uma classificao de disposio estabelecida como fechada, deferida, unida ou referenciada a outro projeto.
7.4 Campos de Defeito

A IEEE 1044-1993 especifica um conjunto de campos obrigatrios que so estabelecidos vrias vezes em um ciclo de vida de defeito. Um grande conjunto de campos opcionais tambm definido. De acordo com a IEEE 1044.1, quando implementando a IEEE 1044-1993, aceitvel a criao de um mapeamento ente os termos da IEEE para campos de defeitos e os nomes associados usados por uma empresa individualmente. Isso permite conformidade com a IEEE 1044-1993 sem ter que aderir justamente com convenes de nomenclatura. A conformidade com a IEEE permite comparao de informao de defeito atravs de vrias empresas e organizaes. A menos de quando a conformidade com a IEEE o objetivo, os campos fornecidos por um defeito so intencionados a fornecer informao suficiente para que possam ser tomadas aes a respeito do defeito. Um relatrio de defeito dessa forma : Completo Conciso Preciso Objetivo Alm de resolver o defeito especfico, a informao tambm deve ser fornecida para uma classificao precisa, anlise de risco e melhoria de processo.
Verso 2007br
Pgina 83 de 124
02 Fev 2010
Certified Tester
7.5 Mtricas & Gerenciamento de Incidente

A informao de defeito deve incluir informao suficiente para auxiliar na monitorao do progresso do teste, anlise de densidade de defeito, mtricas de defeitos encontrados vs. corrigidos e mtricas de convergncia (abertos vs. fechados). Alm disso, a informao de defeito necessita apoiar iniciativas de melhoria de processo atravs de rastreamento da fase de reteno de informao, anlise de causa raiz e identificao de tendncias de defeitos para serem usadas como entradas para ajustes de mitigao de riscos estratgicos.
7.6 Comunicao de Incidentes

O gerenciamento de incidente inclui comunicao efetiva de tal forma que seja livre de acusaes e que apoie o agrupamento e a interpretao de informao objetiva. A preciso de relatrios de incidente, classificao apropriada e demonstrada objetividade so imperativas para manter relaes profissionais entre as pessoas que esto relatando defeitos e as pessoas que esto resolvendo os defeitos. Os testadores podem ser consultados em relao importncia relativa de um defeito, e devem fornecer a informao objetiva disponvel. Encontros de triagem de defeitos devem ser conduzidos para auxiliar uma priorizao apropriada. Uma ferramenta de rastreamento de defeito no deve ser usada como uma substituta para boa comunicao, e nem os encontros de triagem devem ser usados como substitutos utilizao de uma boa ferramenta de rastreamento de defeito. Tanto a comunicao quanto o suporte de uma ferramenta adequada so necessrias para um processo efetivo de defeito.
Verso 2007br
Pgina 84 de 124
02 Fev 2010
Certified Tester
8. Normas & Processo de Melhoria de Teste

Termos
Modelo de Maturidade e Capacidade (CMM Capability Maturity Model), Integrao do Modelo de Maturidade e Capacidade (CMMI Capability Maturity Model Integration), Modelo de Maturidade de Teste (TMM Test Maturity Model), Integrao do Modelo de Maturidade de Teste (TMMi Test Maturity Model integration), Melhoria de Processo de Teste (TPI Test Process Improvement).
8.1 Introduo
O apoio para estabelecer e melhorar os processos de teste vem de vrias fontes. Essa seo primeiramente considera normas como uma fonte til (algumas vezes obrigatria) de informao para diversos tpicos relacionados a teste. Conhecendo quais normas esto disponveis e onde elas devem ser aplicadas considerado um objetivo de aprendizado para gerentes de teste e testadores. Provedores de treinamento devem enfatizar as normas especficas que so particularmente relevantes para o mdulo sendo considerado. Uma vez estabelecido, o processo de teste deve se submeter melhoria contnua. Na seo 8.3 questes genricas de melhoria so primeiramente cobertas, seguidas por uma introduo a alguns modelos especficos que podem ser usados na melhoria de processo de teste. Ao passo que para Test Manager necessrio entender todo o material dessa seo, tambm importante que Test Analysts e Technical Test Analysts, como papis importantes na implementao de melhorias, estejam atentos aos modelos de melhoria disponveis.
8.2 Considerao sobre Normas

Neste, e no Foundation Level Syllabus, algumas normas so mencionadas. Existem normas para diversos tpicos relacionados a software, tais como: Ciclos de vida de desenvolvimento de software Teste e metodologia de software Gerenciamento de configurao de software Manuteno de software Garantia de qualidade Gerenciamento de projeto Requisitos Linguagens de software Interfaces de software Gerenciamento de defeito No o propsito deste syllabus listar ou recomendar normas especficas. Os testadores devem estar atentos em como as normas so criadas, e como elas devem ser usadas dentro do ambiente do usurio. As normas podem vir de diferentes fontes: Objetivos internacionais, ou estarem inseridas em objetivos internacionais Nacionais, tais como aplicaes nacionais de normas internacionais De domnio especfico, tais como quando normas internacionais ou nacionais so adaptadas a domnios particulares, ou desenvolvidas em domnios especficos
Verso 2007br
Pgina 85 de 124
02 Fev 2010
Certified Tester
Algumas consideraes so aplicveis quando usando normas. Essas so descritas a seguir nessa seo.
8.2.1 Aspectos Gerais das Normas

8.2.1.1 Fontes de Normas Normas so criadas por grupos de profissionais e refletem um conhecimento coletivo. H duas maiores fontes de normas internacionais: IEEE e ISO. Normas nacionais e de domnio especfico so tambm importantes e disponveis. Testadores devem estar atentos a normas que se aplicam ao seu ambiente ou contexto, sejam normas formais (internacionais, nacionais, ou de domnio especfico) ou normas internas e prticas recomendadas. Como normas evoluem e mudam necessrio especificar a verso (data de publicao) da norma para garantir que a conformidade seja obtida. Quando uma referencia a uma norma especificada sem data ou verso, ento a ltima verso considerada como sendo referenciada. 8.2.1.2 Utilidade de Normas Normas podem ser usadas como um instrumento para promover uma garantia de qualidade construtiva, tal que mantm foco em minimizar os defeitos introduzidos ao invs de encontr-los atravs de teste (garantia de qualidade analtica). Nem todas as normas so aplicveis a todos os projetos; a informao especificada em uma norma pode ser til para um projeto, ou pode estorv-lo. Seguindo uma norma somente com a finalidade de seguir a norma no ajudar o testador a encontrar mais defeitos no produto de trabalho [Kaner02]. No entanto, normas podem prover a mesma estrutura de referncia, e prover uma base na qual definir solues de teste. 8.2.1.3 Coerncia & Conflitos Algumas normas podem ser deficientes em coerncia com outras normas, ou at fornecer definies conflitantes. deixado a cargo dos usurios das normas determinarem a utilidade das diferentes normas em seu ambiente e contexto.
8.2.2 Normas Internacionais

8.2.2.1 ISO ISO [www.iso.org] significa International Standards Organization (recentemente alterado para International Organization for Standardization) e formado por membros representando, para seu pas, o corpo nacional representativo da padronizao. Esse corpo internacional fomenta diversas normas teis para testadores de software, tais como: ISO 9126:1998, que atualmente separada na seguinte norma e relatrios tcnicos (technical reports - TR): o ISO/IEC 9126-1:2001 Engenharia de software Qualidade de produto -- Parte 1: Modelo de qualidade o ISO/IEC TR 9126-2:2003 Engenharia de software Qualidade de produto -- Parte 2: Mtricas externas o ISO/IEC TR 9126-3:2003 Engenharia de software Qualidade de Produto -- Parte 3: Mtricas internas o ISO/IEC TR 9126-4:2004 Engenharia de software Qualidade de produto -- Parte 4: Qualidade no uso de mtricas ISO 12207:1995/Amd 2:2004 Sistemas e Engenharia de software Processos de Ciclo de Vida de Software
Verso 2007br
Pgina 86 de 124
02 Fev 2010
Certified Tester
1
ISO/IEC 15504 -2:2003 Tecnologia da informao Avaliao de processo -- Parte 2: Realizando uma avaliao Essa lista no exaustiva; outras normas ISO podem ser aplicveis ao contexto e ambiente de um testador. 8.2.2.2 IEEE IEEE [www.ieee.org] o Institute of Electrical and Electronics Engineer, uma organizao profissional com sede nos EUA. Existem representantes nacionais disponveis em mais de uma centena de pases. Essa organizao fomenta diversas normas teis para testadores de software, tais como: IEEE 610:1991 Norma IEEE de dicionrio de computao. Uma compilao da norma IEEE de glossrio de computao IEEE 829:1998 Norma IEEE de documentao de teste de software IEEE 1028:1997 Norma IEEE de reviso de software IEEE 1044:1995 Guia IEEE para classificao de anomalias de software Essa lista no exaustiva; outras normas IEEE podem ser aplicveis ao contexto e ambiente de um testador.
8.2.3 Normas Nacionais

Muitos pases tm suas normas especficas. Algumas dessas normas so aplicveis e/ou teis para o teste de software. Um exemplo seria a norma britnica BS-7925-2:1998 Teste de software. Teste de componente de software a qual fornece informao relacionada a vrias tcnicas de teste descritas neste syllabus, incluindo: Partio de Equivalncia Anlise de Valor Limite Teste de Transio de Estado Grafo de Causa-Efeito Teste de Comando Teste de Desvio/Deciso Teste de Condio Teste Randmico A BS-7925-2 tambm fornece uma descrio do processo de Teste de Componente.
8.2.4 Normas de Domnio Especfico

As normas tambm esto presentes em diferentes domnios tcnicos. Alguns mercados adaptam outras normas para seus domnios tcnicos especficos. Nesse mbito, tambm h aspectos de interesse para o teste de software, qualidade de software e desenvolvimento de software. 8.2.4.1 Sistemas de Aviao RTCA DO-178B/ED 12B Consideraes de Software em Sistemas Areos e Certificao de Equipamento aplicvel ao software usado em aeronaves civis. Essa norma tambm se aplica ao software usado para criar (ou verificar) tais software usados em aeronaves. Para software de aviao, a United States Federal Aviation Administration (FAA) e o internacional Joint Aviation Authorities (JAA) prescrevem certos critrios de cobertura estrutural baseado na criticidade do software sendo testado:
Nvel de Criticidade
1
Impacto Potencial da Falha
Cobertura Estrutural Requerida
A ISO 15504 tambm conhecida como SPICE, e derivada do projeto SPICE.
Verso 2007br
Pgina 87 de 124
02 Fev 2010
Certified Tester
Nvel de Criticidade A Catastrfico B Perigoso / Superiorsevero
Impacto Potencial da Falha Impede um voo contnuo e pouso seguro
Cobertura Estrutural Requerida Determinao de Condio, Deciso de Comando
Grande reduo nas margens de segurana ou capacidades funcionais A tripulao no pode fiar-se na realizao de suas tarefas com Deciso e Comando preciso ou completamente Danos srios ou fatais a um pequeno nmero de passageiros Significativa reduo nas margens de segurana Significativo aumento na carga de trabalho da tripulao Desconforto aos passageiros possivelmente incluindo danos Comando
C Superior
D Inferior
Pequena reduo nas margens de segurana da aeronave nas capacidades funcionais Nenhuma Pequeno aumento na carga de trabalho da tripulao Algum inconveniente aos passageiros Nenhum impacto nas capacidades da aeronave Nenhum aumento na carga de trabalho da tripulao Nenhuma
E Sem efeito
O nvel apropriado de cobertura estrutural deve ser atingido dependendo do nvel de criticidade do software que ser certificado para uso em aviao civil. 8.2.4.2 Indstria Espacial Algumas indstrias adaptam outras normas para seus domnios especficos. Esse o caso da indstria especial com a ECSS (European Cooperation on Space Standardization) [www.ecss.org]. Dependendo da criticidade do software, a ECSS recomenda mtodos e tcnicas que so consistentes com os Syllabi ISTQB nos Nveis Foundation e Advanced incluindo: SFMECA - Software Failure Modes, Effects and Criticality Analysis Modos de Falhas de Software, Efeitos e Anlise de Criticidade SFTA - Software Fault Tree Analysis Anlise de rvore de Falta de Software HSIA - Hardware Software Interaction Analysis Anlise de Interao Hardware Software SCCFA - Software Common Cause Failure Analysis Anlise de Causas Comuns de Falha de Software
8.2.4.3 Gabinete de Alimentao & Drogas Para sistemas mdicos sujeitos ao Title 21 CFR Part 820, o gabinete Americano de Alimentos e Drogas (United States Food and Drug Administration FDA) recomenda certas tcnicas de teste estruturais e funcionais. O FDA tambm recomenda estratgias de teste e princpios que esto consistentes com os Syllabi ISTQB nos Nveis Foundation e Advanced.
8.2.5 Outras Normas

As diversas normas disponveis nas diferentes indstrias so bastante vastas. Algumas so adaptaes a domnios e mercados especficos, algumas so aplicveis em tarefas especficas ou fornecem explanao de como aplicar uma norma. O testador deve estar atento s diferentes normas (incluindo normas internas, melhores prticas, etc.) que so aplicveis dentro de seu domnio, mercado ou contexto. Algumas vezes as normas aplicveis so especficas, com aplicabilidade hierrquica a contratos especficos. O gerente de teste deve estar atento s normas as quais ele deve estar conforme, e assegurar-se que a conformidade adequada mantida.
Verso 2007br
Pgina 88 de 124
02 Fev 2010
Certified Tester
8.3 Processo de Melhoria de Teste

Na medida em que o teste usado para melhoria de software, os processos de qualidade de software so selecionados e usados para melhorar o processo de desenvolvimento de software (e os entregveis de software resultantes). Melhoria de processo tambm pode ser aplicada aos processos de teste. Diferentes formas e mtodos esto disponveis para melhorar o teste de software e os sistemas que contm software. Esses mtodos visam a melhoria de processo (e, portanto, dos entregveis) atravs do fornecimento de diretrizes e reas de melhoria. O teste frequentemente responde por uma grande parte do custo total de projeto. No entanto, somente uma ateno limitada dada ao processo de teste nos vrios modelos de melhoria de processo de software, tal como CMMI (veja detalhes a seguir). Modelos de melhoria de teste como o Modelo de Maturidade de Teste (TMM Test Maturity Model), Processo Sistemtico de Teste e Avaliao (STEP Systematic Test and Evaluation Process), Processos Crticos de Teste (CTP Critical Testing Processes) e Melhoria de Processo de Teste (TPI Test Process Improvement) foram desenvolvidos para cobrir esse aspecto. O TPI e TMM fornecem um grau de mtricas transversais organizao as quais podem ser usadas para comparaes de benchmark. H diversos modelos de melhoria disponveis no mercado atualmente. Alm daqueles cobertos nessa seo, podem ser tambm considerados o modelo de Maturidade de Organizao de Teste (TOM Test Organization Maturity), Modelo de Melhoria de Teste (TIM Test Improvement Model) e Graduao de Qualidade de Software (SQR Software Quality Rank). Existe tambm um grande nmero de modelos regionais que so usados atualmente. Profissionais de teste devem pesquisar todos os modelos disponveis para determinar o que melhor se ajusta a sua situao. Os modelos presentes nessa seo no so intencionados a serem uma recomendao de uso, mas so mostrados aqui para fornecer uma viso representativa de como os modelos funcionam e o que includo neles.
8.3.1 Introduo Melhoria de Processo

Melhorias de processo so relevantes aos processos de desenvolvimento de software assim como para os processos de teste. Aprender com os erros de alguns torna possvel melhorar o processo que as organizaes esto usando para desenvolver e testar software. O ciclo de melhoria de Deming: Planejar, Realizar, Verificar, Agir (Plan, Do, Check, Act) tem sido usado por vrias dcadas, e ainda relevante quando os testadores necessitam melhorar o processo em uso atualmente. Uma premissa para a melhoria do processo a crena de que a qualidade do sistema fortemente influenciada pela qualidade do processo usado para desenvolver o software. A qualidade melhorada na indstria de software reduz a necessidade por recursos para manter o software e ento fornece mais tempo para criao de mais e melhores solues no futuro. Os modelos de processo fornecem uma posio para iniciar a melhoria, atravs da medida da maturidade dos processos da organizao dentro do modelo. O modelo tambm fornece uma estrutura para melhoria dos processos da organizao baseados nas sadas de uma avaliao. Uma Avaliao de Processo conduz a Determinao da Capacidade do Processo, a qual motiva uma Melhoria de Processo. Isso pode invocar uma posterior Avaliao de Processo para medir o efeito da melhoria.
8.3.2 Tipos de Melhoria de Processo

Existem dois tipos de modelos: modelos de referncia de processo e modelos de referncia de contedo.
Verso 2007br
Pgina 89 de 124
02 Fev 2010
Certified Tester
1. O modelo de referncia de processo usado como uma estrutura quando uma avaliao realizada, para estimar a capacidade da organizao em relao ao modelo, e para avaliar a organizao dentro da estrutura. 2. O modelo de referncia de contedo usado para melhorar o processo uma vez que a avaliao realizada. Alguns modelos podem apresentar ambas as partes ao passo que outros tero somente uma.
8.4 Melhoria do Processo de Teste

A indstria de TI comeou a trabalhar com modelos de melhoria de processo de teste na medida em que busca alcanar um nvel mais alto de maturidade e profissionalismo. Modelos padres da indstria esto auxiliando a desenvolver mtricas e medidas transversais organizao, as quais podem ser usadas para comparao. Os modelos estagiados, tais como TMMi e CMMI, fornecem padres para comparao entre as diferentes empresas e organizaes. Os modelos contnuos permitem a uma organizao corresponder s suas questes de mais alta prioridade com maior liberdade para a implementao. Fora da necessidade da melhoria de processo na indstria de teste, diversos padres foram criados. Esses incluem STEP, TMMi, TPI e CTP. Eles so discutidos a seguir nesta seo. Esses quatro modelos de avaliao de processo permitem a uma organizao determinar onde ela se encaixa em termos de seus processos de teste atuais. Uma vez que uma avaliao realizada, TMMi ou TPI fornecem um guia prescritivo para a melhorar o processo de teste. Ao contrrio, STEP e CTP fornecem organizao meios para determinar aonde vir o maior retorno de investimento na melhoria de processo e deixa a organizao selecionar o guia apropriado. Uma vez que foi consentido que os processos de teste devam ser revisados e melhorados, os passos do processo a serem adotados para essa atividade deveriam ser os seguintes: Iniciar Medir Priorizar e Planejar Definir e Redefinir Operar Validar 2 Evoluir Iniciar Nessa atividade a confirmao dos stakeholders, os objetivos, metas, escopo e cobertura das melhorias do processo so acertados de comum acordo. A escolha do modelo de processo no qual as melhorias sero identificadas tambm feita durante esta atividade. O modelo poderia ser selecionado por aqueles publicados ou definidos individualmente. Antes do incio das atividades de melhoria de processo, critrios de sucesso devem ser definidos e o mtodo pelo qual eles sero mensurados durante a atividade de melhoria deve ser implementado. Medir A abordagem que foi consentida para a avaliao utilizada culminando em uma lista de possveis melhorias de processo. Priorizar & Planejar A lista de possveis melhorias de processo colocada em ordem de prioridade. A ordenao poderia ser baseada no retorno de investimento, riscos, alinhamento com a estratgia da organizao, benefcios mensurveis quantitativa ou qualitativamente.
2
Nota da verso brasileira: as iniciais marcadas formam a palavra IMPROVE que significa melhorar, aperfeioar.
Verso 2007br
Pgina 90 de 124
02 Fev 2010
Certified Tester
Tendo estabelecida a ordem de prioridade, o planejamento para a entrega das melhorias deveria ento ser desenvolvido e implantado. Definir & Redefinir Baseado nos requisitos de melhoria de processo identificados, quando novos processos so necessrios eles so definidos, e quando processos existentes necessitam de atualizao eles so redefinidos e aprontados para a implantao. Operar Uma vez desenvolvidas, as melhorias de processo so implantadas. Isso poderia incluir quaisquer treinamentos ou tutoriais requeridos, conduo do processo e enfim a completa implantao delas. Validar Tendo as melhorias de processo completamente implantadas, importante que quaisquer benefcios que foram combinados antes de realizar a(s) melhoria(s) sejam validados, por exemplo, a realizao do benefcio. importante tambm que qualquer critrio de sucesso da atividade de melhoria de processo seja satisfeito. Evoluir Dependendo do modelo de processo usado, neste estgio do processo que a monitorao para o prximo nvel de maturidade inicia e uma deciso tomada para iniciar o aperfeioamento do processo novamente, ou para parar a atividade nesse ponto. O uso de modelos de avaliao um mtodo comum o qual garante uma abordagem padronizada para a melhoria do processo de teste usando prticas testadas e confiveis. A melhoria do processo de teste pode, no entanto, ser alcanada sem modelos, utilizando, por exemplo, abordagens analticas e encontros de retrospectiva.
8.5 Melhoria do Processo de Teste com TMM

O Modelo de Maturidade de Testes (Testing Maturity Model) composto de cinco nveis e intencionado a complementar o CMM. Cada um dos nveis contm reas de processo definidas que devem ser completamente preenchidas antes que a organizao possa avanar para o prximo nvel (ou seja, uma representao estagiada). O TMM fornece tanto um modelo de referncia de processo como um modelo de referncia de contedo. Os nveis do TMM so: Nvel 1: Incio O nvel inicial representa um estado no qual no h processo de teste formalmente documentado ou estruturado. Os testes so desenvolvidos tipicamente de forma ad hoc aps a codificao, e o teste visto como depurao. O propsito do teste entendido como uma prova de que o software funciona. Nvel 2: Definio O segundo nvel pode ser alcanado pelo ajuste de uma poltica e metas de teste, introduzindo um processo de planejamento de teste, e implementando tcnicas e mtodos bsicos de teste. Nvel 3: Integrao O terceiro nvel conquistado quando o processo de teste integrado junto ao ciclo de vida de desenvolvimento de software, e documentado em normas, procedimentos e mtodos formais. Deve haver uma funo de teste de software distinta que pode ser controlada e monitorada. Nvel 4: Gerenciamento & Medio
Verso 2007br
Pgina 91 de 124
02 Fev 2010
Certified Tester
O quarto nvel alcanado quando o processo de teste capaz de ser efetivamente medido, gerenciado e adaptado a projetos especficos. Nvel 5: Otimizao O nvel final representa o estado de maturidade do processo de teste, no qual os dados do processo de teste podem ser usados para auxiliar na preveno de defeitos e o foco est na otimizao do processo estabelecido. Para alcanar um nvel particular algumas metas e submetas pr-definidas de maturidade devem ser concludas. Essas metas so definidas em termos de atividades, tarefas e responsabilidades e avaliadas de acordo com vises especficas para gerente, desenvolvedor/testador e cliente/usurio. Para maiores informaes em TMM, veja [Burnstein03]. A Fundao TMMi [veja www.tmmifoundation.org para detalhes] definiu o sucessor do TMM: TMMi. O TMMi um modelo detalhado para a melhoria do processo de teste baseado na estrutura do TMM como desenvolvida pelo Instituto de Tecnologia de Illinois, e em experincias prticas do uso de TMM e colocado como sendo complementar ao CMMI. A estrutura do TMMi largamente baseada na estrutura do CMMI (por exemplo, reas de processos, metas genricas, prticas genricas, metas especficas, prticas especficas).
8.6 Melhoria do Processo de Teste com TPI

O TPI (Test Process Improvement) usa uma representao continua ao invs da representao estagiada do TMM. O plano de otimizao do processo de teste delineado em [Koomen99] envolve um conjunto de reas chave que so ajustadas dentro de quatro alicerces de Ciclo de vida, Organizao, Infraestrutura e ferramentas e Tcnicas. As reas chaves podem ser avaliadas em um nvel entre A a D, A sendo mais baixo. tambm possvel para reas chave muito imaturas no receberem o nvel inicial A. Algumas reas chave apenas recebem A ou B (tais como Estimativa e Planejamento) enquanto que outras (tais como Mtricas) podem receber A, B, C ou D. O nvel alcanado por uma dada rea chave determinado para avaliar os pontos de verificao definidos no modelo TPI. Se, por exemplo, todos os pontos de verificao para o relatrio de uma rea chave so respondidos positivamente no nvel A e B, ento o nvel B atingido para essa rea chave. O modelo TPI define dependncias entre as vrias reas chave e nveis. Essas dependncias asseguram que o processo de teste desenvolvido equilibradamente. No possvel, por exemplo, atingir um nvel A na rea chave mtrica sem alcanar tambm o nvel A na rea chave reporte (ou seja, qual a utilidade de tomar medidas se elas no so reportadas). O uso de dependncias opcional no modelo TPI. O TPI primariamente um modelo de referncia de processo. Uma Matriz de Maturidade de Teste fornecida para mapear os nveis (A, B, C, ou D) para cada rea chave para um nvel geral de maturidade de processo de teste. Esses nveis gerais so: Controlado Eficiente Otimizado Durante uma avaliao TPI, mtricas quantitativas e entrevistas qualitativas so usadas para estabelecer o nvel de maturidade do processo de teste.
Verso 2007br
Pgina 92 de 124
02 Fev 2010
Certified Tester
8.7 Melhoria do Processo de Teste com CTP

Como descrito em [Black02], a premissa bsica do modelo de avaliao de Processo Crtico de Teste (CTP Critical Testing Processes) tal que determinados processos de teste so crticos. Esses processos crticos, se bem conduzidos, apoiaro equipes de teste de sucesso. De modo oposto, se essas atividades forem mal conduzidas, at mesmo testadores e gerentes de teste individualmente talentosos dificilmente tero sucesso. O modelo identifica doze processos crticos de teste. O CTP primariamente um modelo de referncia de contedo. O modelo de processos crticos de teste uma abordagem sensvel ao contexto a qual permite ajustes do modelo incluindo: Identificao para desafios especficos Reconhecimento de atributos para bons processos Seleo da ordenao e importncia da implementao de melhorias de processos O modelo de processos crticos de teste adaptvel dentro do contexto de todos os modelos de ciclo de vida de desenvolvimento de software. As melhorias de processo usando CTP iniciam dentro de uma avaliao do processo de teste existente. A avaliao identifica quais processos so fortes e quais so fracos, e fornece recomendaes priorizadas para melhoria baseadas nas necessidades da organizao. Enquanto que as avaliaes variam dependendo do contexto especfico no qual elas so executadas, as seguintes mtricas quantitativas so comumente examinadas durante uma avaliao CTP: Porcentagem de deteco de defeito Retorno do investimento no teste Cobertura de requisitos e cobertura de riscos Custos sobre a liberao de teste Razo de rejeio de reporte de defeito Os seguintes fatores qualitativos so comumente avaliados durante a avaliao CTP: Papel e efetividade da equipe de teste Utilidade do plano de teste Habilidades da equipe de teste em teste, conhecimento no domnio e tecnologia Utilidade do relatrio de defeito Utilidade do relatrio de resultado de teste Utilidade e equilbrio do gerenciamento de mudana Uma vez que a avaliao tenha identificado reas frgeis, planos para melhoria so colocados em prtica. Planos genricos de melhoria so fornecidos pelo modelo para cada processo crtico de teste, mas esperado que a equipe de avaliao os ajuste profundamente.
8.8 Melhoria do Processo de Teste com STEP

O STEP (Systematic Test and Evaluation Process), assim como o CTP e ao contrrio do TMMi e TPI, no requer que melhorias aconteam em uma ordem especfica. As premissas bsicas da metodologia incluem: Uma estratgia de teste baseada em requisitos Incio do teste no comeo do ciclo de vida de desenvolvimento do software Os testes so usados como requisitos e modelos de uso A modelagem do testware conduz a modelagem do software Os defeitos so detectados precocemente ou prevenidos de modo geral Os defeitos so sistematicamente analisados Os testadores e desenvolvedores trabalham em conjunto
Verso 2007br
Pgina 93 de 124
02 Fev 2010
Certified Tester
STEP um modelo primariamente de referncia de contedo. A metodologia STEP baseada na premissa de que o teste uma atividade do ciclo de vida que inicia durante a formulao de requisitos e continua at a retirada do sistema. A metodologia STEP enfatiza o teste enquanto codifica utilizando uma estratgia de teste baseada em requisitos para assegurar que a criao o mais cedo possvel de casos de teste valida a especificao de requisitos anteriormente modelagem e codificao. A metodologia identifica e direciona o foco na melhoria de trs principais fases de teste: Planejamento Aquisio Medio Durante uma avaliao STEP, mtricas quantitativas e entrevistas qualitativas so usadas. Mtricas quantitativas incluem: Status do teste ao longo do tempo Cobertura de requisitos de teste ou risco Tendncias de defeito incluindo deteco, severidade e aglomerao Densidade de defeito Efetividade de remoo de defeito Porcentagem de deteco de defeito Fases de introduo, deteco e remoo de defeitos Custo do teste em termos de tempo, esforo e dinheiro Fatores quantitativos incluem: Utilizao do processo de teste definido Satisfao do cliente Em alguns casos o modelo de avaliao STEP mesclado com o modelo de maturidade TPI.
8.9 Integrao do Modelo de Maturidade e Capacidade, CMMI

O CMMI pode ser implementado atravs de duas abordagens ou representaes: a estagiada ou a contnua. Na representao estagiada existem cinco nveis de maturidade, cada nvel construdo sobre as reas de processo estabelecidas nos nveis anteriores. Na representao contnua, permitido organizao concentrar seus esforos de melhoria nas suas prprias reas primrias de interesse sem considerar nveis precedentes. A representao estagiada primariamente includa no CMMI para assegurar atributos comuns com CMM, enquanto que a representao contnua usualmente considerada mais flexvel. Dentro do CMMI as reas de processo de Validao e Verificao referenciam tanto processos de teste estticos quanto dinmicos.
Verso 2007br
Pgina 94 de 124
02 Fev 2010
Certified Tester
9. Ferramentas de Teste e Automatizao

Termos
Ferramenta de depurao, ferramenta de anlise dinmica, emulador, ferramenta de injeo de faltas, ferramentas de teste de hyperlink, teste orientado a palavra-chave, ferramenta de teste de desempenho, simulador, analisador esttico, ferramenta de execuo de teste, ferramenta de gerenciamento de teste, orculo de teste
9.1 Introduo
Esta seo expande o Foundation Level Syllabus por cobrir vrios conceitos gerais e discutir algumas ferramentas especificas em maior detalhe. Ainda que alguns conceitos cobertos sejam mais relevantes a Test Manager, Test Analysts, ou Technical Test Analysts, um conhecimento bsico dos conhecimentos necessrio para todos os profissionais de teste. Esse conhecimento bsico pode ser aprofundado quando apropriado. As ferramentas disponveis para o teste podem ser agrupadas de diferentes formas, incluindo um agrupamento de acordo com o usurio intencionado, tais como gerentes de teste, analistas de teste, ou analistas tcnicos de teste. Esse agrupamento particular, o qual reflete os mdulos deste syllabus, usado nas prximas sees deste captulo. Em geral, as ferramentas discutidas nessas sees so primariamente relevantes a um mdulo especifico, no entanto certas ferramentas (por exemplo, ferramentas de gerenciamento de teste) podem ter uma relevncia mais abrangente. Quando esse for o caso, exemplos de aplicao de ferramentas em um contexto especfico sero dados pelo Provedor de Treinamento.
9.2 Conceitos de Ferramentas de Teste

As ferramentas de teste podem melhorar bastante a eficincia e preciso do esforo de teste, mas somente se as ferramentas apropriadas forem implementadas da forma apropriada. Ferramentas de teste devem ser gerenciadas assim como outros aspectos de uma organizao de teste bem conduzida. A automatizao de teste frequentemente tomada como um sinnimo de execuo de teste, mas muito do trabalho manual apresenta diferentes formas de automatizao de teste, significando que boa parte das reas dentro do teste poderia ser automatizada em algum grau caso as ferramentas corretas estejam presentes. Qualquer verso de ferramenta, script, ou seo de teste deveria estar, como qualquer base de teste, sob gerenciamento de configurao e relacionado a uma verso particular do software no qual est sendo usado. Qualquer ferramenta de teste uma parte importante do testware e deveria ser gerenciada da seguinte forma: Criando uma arquitetura anterior criao da ferramenta de teste Assegurando um gerenciamento de configurao adequado de script & verses de ferramenta, caminhos, etc., incluindo informao de verso Criando e mantendo bibliotecas (reuso de conceitos similares nos casos de teste), documentando a implementao da ferramenta de teste (por exemplo, processo de como a ferramenta utilizada na organizao) Planejando para o futuro atravs da estruturao de casos de teste para prximos desenvolvimentos, por exemplo, tornando-os expansveis e passveis de manuteno
Verso 2007br
Pgina 95 de 124
02 Fev 2010
Certified Tester
9.2.1 Custo-benefcio e Riscos de Ferramentas de Teste e Automatizao

Uma anlise de custo-benefcio sempre deveria ser realizada e deveria mostrar um retorno de investimento significativo e positivo. As principais caractersticas de uma anlise de custo-benefcio deveriam incluir os seguintes itens de custo, atravs da comparao do custo real tanto para teste manual (sem o uso de ferramentas) quanto para teste com uso de ferramenta (em termos de custos em horas, custos diretos, custos recorrentes e no recorrentes): Custos iniciais o Aquisio de conhecimento (curva de aprendizado da ferramenta) o Avaliao (comparaes de ferramentas) quando apropriado o Integrao com outras ferramentas o Consideraes iniciais de custos para compra, adaptao ou desenvolvimento da ferramenta Custos recorrentes o Custo de propriedade da ferramenta (manuteno, taxas de licena, taxas de suporte, nveis de manuteno de conhecimento) o Portabilidade o Disponibilidade e dependncias (caso esteja faltando) o Estimativa de custo contnuo o Melhoria de qualidade, para garantir o uso das ferramentas selecionadas Casos de negcios baseados somente em projetos piloto de automatizao frequentemente no incluem custos importantes, tais como custos de manuteno, atualizao e expanso dos scripts de teste quando o sistema muda. A durabilidade de um casos de teste relativa a quanto tempo ele se manter vlido sem retrabalho. O tempo necessrio para implementar a primeira verso de scripts de teste automatizados frequentemente bem superior ao tempo de execut-los manualmente, mas permitir a criao de novos scripts similares de teste automatizados mais rapidamente e assim facilmente expandir o nmero de bons casos de teste ao longo do tempo. Alm disso, uma cobertura de teste significativa e melhorias na eficincia de teste sero vistas no uso futuro da automatizao aps o perodo de implementao. O caso de negcio para a implementao de ferramenta deve ser baseado em um caso de negcio de longo prazo. Em um nvel especfico cada caso de teste deve ser considerado se tem caracterstica para automatizao. Muitos projetos de automatizao so baseados na implementao de casos de testes prontos e disponveis sem reviso do real benefcio da automatizao para cada caso particular. Muito provavelmente, qualquer conjunto de casos de teste (uma sute) pode conter testes manuais, semiautomatizados e totalmente automatizados. Alm dos tpicos cobertos no Foundation Level Syllabus, os seguintes aspectos deveriam ser considerados: Benefcios adicionais: O tempo de execuo de testes automatizados so mais previsveis Teste de regresso e validao de defeito so mais rpidos e seguros durante o projeto quando os casos de teste so automatizados O uso de ferramentas automatizadas pode aumentar o status e o crescimento tcnico do testador ou da equipe de teste Automatizao pode ser usada em desenvolvimento paralelo, iterativo e incremental, para fornecer melhores testes de regresso em cada build Cobertura de determinados tipos de teste que no podem ser cobertos manualmente (por exemplo, desempenho e confiabilidade) Riscos adicionais: Testes manuais incompletos ou incorretos so automatizados como esto
Verso 2007br
Pgina 96 de 124
02 Fev 2010
Certified Tester
O testware difcil de manter, requerendo mltiplas mudanas quando o software sob teste sofre alteraes Perda do envolvimento direto do testador na execuo pode reduzir a deteco de defeitos na medida em que somente os testes automatizados e j escritos so realizados
9.2.2 Estratgias de Ferramenta de Teste

Ferramentas de teste normalmente tm o propsito de serem usadas para mais do que um projeto em particular. Dependendo do investimento e do tamanho do projeto, poderia no haver um retorno adequado do investimento dentro de um projeto, mas poderia vir a ter o retorno em verses subsequentes do software. Por exemplo, visto que a fase de manuteno frequentemente intensiva em relao ao teste (para cada correo uma grande sute de regresso deve ser executada), pode ser benfico, em termos de custo, automatizar o sistema para que dessa forma a extenso da fase de manuteno do sistema possa torn-la econmica. Como outro exemplo, fcil os humanos cometerem erros enquanto executam testes manuais (tais como erros de digitao), e com isso o custo-benefcio de automatizar a entrada de dados e a comparao da sada dos dados com um orculo (por exemplo, comparao do resultado de teste com o resultado esperado) em uma sute de teste vantajoso. Para empresas que usam e so dependentes de vrias ferramentas de teste (para diferentes fases e propsitos) uma estratgia de longo prazo em relao s ferramentas de teste aconselhvel para amparar decises sobre diferentes verses e suporte de ferramentas. Para empresas maiores com um domnio intensivo de ferramentas, aconselhvel fornecer guias gerais para aquisio de ferramentas, estratgias, paradigmas ou linguagens de script a serem usados.
9.2.3 Integrao & Troca de Informao entre Ferramentas

Comumente, h mais do que uma ferramenta de teste sendo usada dentro do processo (e desenvolvimento) de teste. Vamos tomar um exemplo de uma empresa usando ferramentas de anlise esttica, de gerenciamento e reporte de teste, de gerenciamento de configurao, de gerenciamento de incidente e de execuo de teste, umas com as outras em uma forma benfica. Por exemplo, poderia ser benfico se todo o status de execuo de teste fosse reportado diretamente ao sistema de gerenciamento de teste para fornecer atualizaes imediatas do progresso, e rastreabilidade direta dos requisitos para um caso de teste particular. mais trabalhoso e mais passvel de erro armazenar os scripts de teste tanto em um banco de dados de gerenciamento de teste e em um sistema de gerenciamento de configurao. Se um testador deseja iniciar um relato de incidente durante a execuo do caso de teste, os sistemas de rastreamento de defeito e gerenciamento de teste devem ser integrados. Enquanto que ferramentas de anlise esttica podem estar separadas de outras ferramentas, seria mais do que conveniente se as ferramentas pudessem reportar incidentes, avisos e retorno diretamente ao sistema de gerenciamento de incidentes. A compra de um conjunto de ferramentas de teste do mesmo fornecedor no implica automaticamente que as ferramentas trabalharo em conjunto dessa maneira, apesar de que seria um requisito razovel. Todos esses aspectos deveriam ser analisados, desde o custo de automatizar a troca de informao, comparado com o risco de adulterao ou perda de informao, com o trabalho integralmente manual, assumindo que a organizao tem o tempo que acarretar esse trabalho. Novos conceitos como ambientes de desenvolvimento integrados tal como o Eclipse tm a inteno de facilitar a integrao e uso de diferentes ferramentas no mesmo ambiente atravs da oferta de uma interface comum para as ferramentas de desenvolvimento e teste. Um fornecedor de ferramenta pode se tornar aderido ao Eclipse atravs da criao de um plug-in para a plataforma Eclipse, fazendo com que ela tenha a mesma aparncia que qualquer outra ferramenta. Isso cria uma boa vantagem para o usurio. Observe: isso no significa automaticamente, mesmo que a interface de
Verso 2007br
Pgina 97 de 124
02 Fev 2010
Certified Tester
usurio seja similar, que as ferramentas automaticamente fornecem integrao e troca de informao entre elas.
9.2.4 Linguagens de Automatizao: Scripts, Linguagem de Script

Scripts e linguagens de script so algumas vezes usados para melhor implementar e expandir as condies e casos de teste. Por exemplo, no teste de uma aplicao web, um script pode ser usado para negligenciar a interface de usurio para uma API (Application Programming Interface) mais adequada ao teste propriamente. Outro exemplo poderia ser o caso no qual o teste de interface de usurio automatizada para permitir todas as possveis combinaes de entradas que seriam impraticveis com o teste manual. A capacidade das linguagens de script varia enormemente. Note que as linguagens de scripting podem variar desde linguagens de programao normal, at notaes padro bastante especficas, por exemplo, sinalizao para protocolos como TTCN-3.
9.2.5 O Conceito de Orculos de Teste

Os orculos de teste so geralmente usados para determinar os resultados esperados. Dessa forma, eles executam a mesma funo que um software sob teste e so raramente disponveis. Eles podem ser usados, no entanto, em situaes nas quais um sistema antigo est sendo trocado por um novo sistema com a mesma funcionalidade, e dessa forma o sistema antigo pode ser usado como um orculo. Orculos podem tambm ser usados quando desempenho um fator importante para o sistema entregue. Um orculo de baixo desempenho poderia ser construdo ou usado para gerar resultados esperados para os testes funcionais de um software de alto desempenho a ser entregue.
9.2.6 Implantao de Ferramenta de Teste

Toda ferramenta de automatizao um software por si s e pode ter dependncias de hardware ou software. Uma ferramenta deveria ser documentada e testada indiferentemente se ela comprada, adaptada ou criada na prpria empresa. Algumas ferramentas so mais integradas com o ambiente, e outras ferramentas trabalham melhor como ferramentas isoladas. Quando um sistema sob teste executa em hardware e/ou sistema operacional proprietrios, software embarcado, ou usa configuraes fora de padro, pode ser necessrio criar (desenvolver) uma ferramenta ou adaptar uma ferramenta para ajustar ao ambiente especfico. sempre aconselhvel fazer uma anlise de custo-benefcio que inclua a implementao inicial assim como uma manuteno de longo prazo. Durante a implantao da ferramenta de automatizao no prudente automatizar os casos de teste manuais como esto, mas redefinir os casos de teste para melhor uso da automatizao. Isso inclui formatar os casos de teste, considerar o reuso de padres, expandir a entrada atravs do uso de variveis ao invs de uso de valores fixos, e utilizar os benefcios da ferramenta de teste, a qual tem funcionalidades para repetir e mudar a ordem com melhores anlises e facilidades de reporte. Para muitas ferramentas de automatizao, conhecimentos de programao so necessrios para criar programas (scripts) e sutes de teste eficientes e efetivos. comum que grandes sutes de teste sejam difceis de manter e gerenciar se no forem modeladas com cuidado. Treinamento apropriado nas ferramentas de teste, programao e tcnicas de modelagem valoroso e garante que os benefcios completos das ferramentas sejam obtidos. Mesmo quando os casos de teste manuais foram automatizados, importante que sejam periodicamente executados manualmente para preservar o conhecimento de como o teste funciona e para verificar a operao correta.
Verso 2007br
Pgina 98 de 124
02 Fev 2010
Certified Tester
Quando a ferramenta entra em uso e o nmero de scripts de teste cresce, pode haver a necessidade de acrescentar funcionalidades que podem ser fornecidas por outras ferramentas. Isso no sempre possvel a partir do momento que as ferramentas nem sempre tm interfaces abertas e algumas vezes usam linguagens proprietrias no padronizadas. prudente usar ferramentas que tenham plugins para plataformas ou APIs (Application Programming Interface) abertas. Isso garantir aos scripts de teste sejam a prova de tempo como testware. Para cada tipo de ferramenta, a despeito da fase na qual usada, considera as caractersticas listadas a seguir. Essas caractersticas podem ser usadas tanto para avaliaes de ferramenta como ao construir uma ferramenta. Em cada uma dessas reas, uma ferramenta pode ser forte ou fraca. Uma lista como essa pode ser til quando comparando as caractersticas de ferramentas similares. Anlise (entendimento do conceito, entrada, informao fornecida manual ou automaticamente) Modelagem (gerada manual ou automaticamente) Seleo (selecionada manual ou automaticamente de acordo com um critrio, por exemplo, cobertura) Execuo (manual, automtica, dirigida, reincio, etc.) Avaliao (por exemplo, orculo de teste) e apresentao. Essas so frequentemente referenciadas como funes de registro ou reporte (manual, automtico, por exemplo, comparativo, com um formulrio, padro, gerada por um critrio)
9.2.7 Uso de Ferramentas de Teste de Cdigo Aberto

Ferramentas usadas para testar sistemas de segurana crtica devem ser certificados a estarem adequados aos propsitos intencionados em relao s normas correspondentes. No recomendvel o uso de ferramentas de cdigo-livre em sistemas de segurana crtica, a menos que eles tenham obtido um nvel apropriado de certificao. A qualidade do software de cdigo-livre dependente de sua exposio, histrico e uso do software em questo, e no deve ser tomado como mais (ou menos) preciso que qualquer outra ferramenta comercial disponvel. Uma avaliao da qualidade deveria sempre ser realizada para qualquer ferramenta de teste para atestar a preciso da ferramenta. Para alguns tipos de ferramentas mais fcil confundir um resultado positivo de avaliao com uma execuo errnea da ferramenta (por exemplo, execues foram descartadas e no foi reportado esse descarte). Consideraes cuidadosas devem ser realizadas para as taxas de licena. H tambm a expectativa de que modificaes no cdigo realizadas para melhoria da ferramenta sejam compartilhadas.
9.2.8 Desenvolvendo sua Prpria Ferramenta de Teste

Diversas ferramentas de teste so desenvolvidas para as necessidades de um testador individual ou modeladas para acelerar seu prprio trabalho. Outra motivao para ferramentas de teste de desenvolvimento prprio a falta de adequao de ferramentas comercias ou o uso de hardware ou ambiente de teste proprietrios. Essas ferramentas frequentemente so eficientes para realizar a tarefa que se prope, mas tambm frequentemente muito dependentes da pessoa que criou a ferramenta. Essas ferramentas deveriam ser documentadas de forma que pudessem ser mantidas por terceiros. tambm importante revisar o propsito, inteno, benefcios e a possibilidade de otimizao de tamanho antes de ser distribuda pela empresa. Geralmente essas ferramentas recebem novos requisitos e so expandidas para um uso futuro alm do uso inicial, o qual pode no ser benfico.
Verso 2007br
Pgina 99 de 124
02 Fev 2010
Certified Tester
9.2.9 Classificao de Ferramenta de Teste

Adicionalmente a ferramentas separadas em quais atividades elas apoiam (o qual o conceito usado no Foundation Level), existem outros esquemas de classificao de ferramentas, incluindo: Ferramentas agrupadas pelo nvel de teste que realizado (componente, integrao, sistema, aceite) Ferramentas agrupadas pelas faltas que elas processam e suportam Ferramentas baseadas na abordagem ou tcnica de teste (veja discusso a seguir) Ferramentas para o teste de diferentes propsitos, por exemplo, medio, controlador, registro, comparaes Ferramentas especficas para determinados domnios, por exemplo, simulao e sinalizao de trfego, redes de interconexo, protocolos, transaes, telas de televiso, sistemas inteligentes Ferramentas para apoio de diferentes reas de teste, por exemplo, entrada de dados, ambiente, configurao, ou outra rea conceitual Ferramentas baseadas na forma que a ferramenta aplicada: software de prateleira, framework (para adaptao), adaptao por plugin (ou seja, Eclipse), conjunto de teste padronizado ou certificado, desenvolvimento prprio da ferramenta
E finalmente, ferramentas podem ser agrupadas de acordo com seu usurio real, tais como gerentes de teste, analistas de teste e analistas tcnicos de teste. Esse agrupamento, o qual reflete os mdulos deste syllabus, usado nas sees seguintes deste captulo. O Foundation Level Syllabus inclui um captulo em considerao a ferramentas. As sees a seguir apresentam aspectos adicionais sobre essas ferramentas.
9.3 Categorias de Ferramentas de Teste

Esta seo apresenta os seguintes objetivos: Fornecer informaes adicionais sobre as categorias de ferramenta j introduzidas no ISTQB Foundation Level Syllabus captulo 6, tais como Ferramentas de Gerenciamento de Teste, Ferramentas de Execuo de Teste e Ferramentas de Desempenho de Teste Introduzir novas categorias de ferramentas Por gentileza, referencie o captulo 6 do ISTQB Foundation Level Syllabus para informaes gerais a respeito das categorias de ferramentas no includas nesta seo.
9.3.1 Ferramentas de Gerenciamento de Teste

Para informaes gerais a respeito de ferramentas de gerenciamento de teste, por gentileza referencie a seo 6.1.2 do ISTQB Foundation Level Syllabus. Ferramentas de gerenciamento de teste deveriam ter a capacidade de rastrear as seguintes informaes: Rastreabilidade de artefatos de teste Captura de dados de ambiente de teste em ambientes complicados Dados considerando a execuo das sutes de teste correntes em diferentes ambientes de teste na mesma seo de teste atravs de localizaes mltiplas (organizaes de teste) Mtricas, tais como: o Condies de teste o Casos de teste o Tempo para execuo (por exemplo, um caso, sute, ou sute de regresso de teste) e outras medidas temporais importantes, incluindo mdias que podem contribuir para decises gerenciais
Verso 2007br
Pgina 100 de 124
02 Fev 2010
Certified Tester
o Nmeros de casos, artefatos e ambientes de teste o Taxas de passa/falha o Nmero de casos de teste pendentes (e a razo de sua no execuo) o Tendncias o Requisitos o Relacionamentos e rastreabilidade entre artefatos de teste Conceitos apoiados pelas ferramentas de gerenciamento de teste, tais como: o Organizador de artefatos de teste, repositrio e controlador de casos de teste o Condies e ambientes de teste o Sutes de regresso, sesses de teste o Registro e informao de tratamento de falhas o Reincio do ambiente (e reinicializaes) o Mtricas de teste relacionadas aos artefatos de teste (documentao de teste) para documentar o progresso do teste As ferramentas de gerenciamento de teste so usadas por gerentes de teste, analistas de teste e analistas tcnicos de teste.
9.3.2 Ferramentas de Execuo de Teste

Para informaes gerais a respeito de ferramentas de execuo de teste, por gentileza referencie a seo 6.1.5 do ISTQB Foundation Level Syllabus. Ferramentas de execuo de teste so mais usadas por analistas de teste e analistas tcnicos de teste em todos os nveis do teste, para executar os testes e verificar suas as sadas. O objetivo de usar uma ferramenta de execuo de teste tipicamente para: Reduzir custos (esforo ou tempo), Executar mais testes, Tornar os testes mais repetveis.
As ferramentas de execuo de teste so frequentemente usadas para automatizar testes de regresso. As ferramentas de execuo de teste trabalham executando um conjunto de instrues escritas em uma linguagem de programao, comumente chamadas de linguagem de script. As instrues ferramenta esto em um nvel bastante detalhado o qual especifica os botes individuais a serem pressionados, toques de teclas e movimentos do mouse. Isso torna o detalhamento dos scripts muito susceptveis a mudanas do software sob teste (Software Under Test SUT), particularmente a mudanas na interface grfica do usurio (Graphical User Interface GUI). O ponto inicial de um script pode ser a gravao (realizada com captura e reexecuo) ou um script construdo ou editado usando scripts, modelos ou palavras chave existentes. Um script um programa e trabalha exatamente como qualquer software. A captura (ou gravao) pode ser usada para registrar o rastro de uma auditoria para um teste no sistemtico. A maior parte de ferramentas de execuo incluem um comparador, a capacidade de comparar o resultado real com o resultado esperado. A tendncia no teste (assim como em programao) passar de instrues detalhas de baixo nvel para linguagens de mais alto nvel, onde so utilizadas bibliotecas, macros e subprogramas. Uma srie de instrues nomeada com uma s denominao em teste so chamadas orientadas a palavra-chave ou orientadas a palavras de ao. A principal vantagem separar as instrues dos dados. Esse o mesmo conceito de quando usando modelos quando est sendo feito um script para minimizar o esforo do usurio. As razes principais pelas quais algumas ferramentas de teste falham so devidas baixa capacidade em programao e ao entendimento de que uma ferramenta de teste simplesmente resolve parte dos problemas da automatizao da execuo de teste. importante notar que
Verso 2007br
Pgina 101 de 124
02 Fev 2010
Certified Tester
qualquer automatizao da execuo de teste necessita de gerenciamento, esforo, habilidade e ateno, por exemplo, a arquitetura de teste e o gerenciamento de configurao. Isso tambm significa que os scripts de teste tambm podem conter defeitos. O uso de uma arquitetura de testware pode oferecer independncia de um fornecedor de ferramenta em particular. Quando uma ferramenta procurada, h a tendncia de pensar que os padres da ferramenta devem ser seguidos, por exemplo, para a estrutura e conveno de nomes para os scripts. Entretanto, a automatizao do ajuste do teste pode formar uma interface entre sua melhor forma de organizar os testes com as necessidades da ferramenta em encontr-los para execut-los.
9.3.3 Ferramentas de Depurao & Investigao

A busca de defeitos pode aplicar ferramentas para limitar a rea na qual as faltas ocorrem. Isso pode ser necessrio em um sistema no qual no evidente qual falta causa a falha exibida. Ferramentas de busca de defeitos incluem os rastros e os ambientes simulados usados para interagir com o software ou extrair informao do sistema para restringir a localizao da falta. Os programadores reproduzem as faltas e investigam o estado dos programas usando ferramentas de depurao e rastreamento. Depuradores e rastreadores viabilizam aos programadores: Executar os programas linha a linha Parar o programa em qualquer comando do cdigo Fixar e examinar as variveis do programa.
Deve ser esclarecido que a depurao (e ferramentas de depurao) relacionada ao teste, mas no so de teste (ou ferramentas de teste). Ferramentas de depurao e rastreamento podem ser usadas para propsitos de procura de defeitos por testadores para melhor localizar a origem da falta e para auxiliar a determinar onde enviar um reporte de defeito. Ferramentas de depurao, rastreamento e busca de defeitos so principalmente usadas por analistas tcnicos de teste.
9.3.4 Ferramentas de Semeadura de Faltas & Injeo de Faltas

Semeadura de faltas e injeo de faltas so duas tcnicas diferentes que podem ser usadas no teste. Semeadura de falta utiliza uma ferramenta similar a um compilador para criar um s ou limitados tipos de faltas de cdigo de uma forma sistemtica. Essas ferramentas so tambm usadas frequentemente em associao com a tcnica de teste de mutao e so algumas vezes chamadas de ferramentas de teste de mutao. Injeo de faltas destinada a mudar as interfaces reais para componentes de teste (quando o cdigo fonte no est disponvel), mas que podem ser deliberadamente (re)injetar uma falta particular para verificar se (1) o software pode lidar com ela (tolerncia a falta) ou (2) para avaliar se um teste na sute de teste encontra a falta inserida deliberadamente. Ferramenta de semeadura de falta e injeo de falta so principalmente usadas em nvel de cdigo por analistas tcnicos de teste, mas tambm possvel pra um analista de teste manipular dados em um banco de dados ou injetar faltas nos fluxos de dados para testar o comportamento do sistema.
9.3.5 Ferramentas de Simulao & Emulao

Simuladores so usados para apoiar testes nos quais o cdigo ou outros sistemas no esto disponveis, so caros ou de uso impraticvel (por exemplo, teste de software para conter um colapso nuclear). Alguns simuladores e ferramentas de ambiente preparado de teste podem tambm suportar ou imitar o comportamento da falta, e assim estados de erro ou cenrios de erro podem ser averiguados. O risco principal do uso dessas ferramentas que os defeitos relacionados aos recursos, tais como questes temporais, podem no ser encontrados, o que muito importante para alguns tipos importantes de sistemas.
Verso 2007br
Pgina 102 de 124
02 Fev 2010
Certified Tester
Emuladores formam uma categoria particular de simuladores, e consistem de software escrito para imitar o hardware. A vantagem de usar emuladores que testes mais elaborados podem ser viabilizados. Uma vantagem particular com emuladores que rastreamento, depurao e causas dependentes de tempo podem ser recriadas, e que poderiam ser impossveis em um sistema real. Emuladores so custosos para serem criados, mas a vantagem da anlise quando o sistema pode ser executado de forma lenta incalculvel pra alguns sistemas paralelos, dependentes de tempo e complexos. Analistas de teste e analistas tcnicos de teste, dependendo do tipo de emulao requerida, usam essas ferramentas.
9.3.6 Ferramentas de Anlise Esttica e Dinmica

Para informaes gerais a respeito de ferramentas de teste esttico e anlise dinmica, por gentileza referencie a seo 6.1.6 do ISTQB Foundation Level Syllabus Ferramenta para desempenho e monitorao. 9.3.6.1 Ferramentas de Anlise Esttica Ferramentas de anlise esttica podem ser usadas a qualquer momento no ciclo de vida do software e tambm em todos os nveis/fases do desenvolvimento de software, dependendo das medidas fornecidas pela ferramenta. Ferramentas de anlise esttica relatam o que encontraram em termos de avisos (warnings). Os avisos que no so confirmados so chamados de falsos positivos. Positivos reais so faltas reais que poderiam conduzir a falhas durante a execuo. Pode ser difcil e demorado para discernir os falsos e verdadeiros positivos na medida em que isso requer uma procura apropriada por defeitos. Ferramentas de anlise esttica mais modernas podem usar informaes sobre a ligao dinmica durante a compilao, e so, portanto, mais poderosos em encontrar faltas reais com menos falsos positivos. Analistas tcnicos de teste usam essas ferramentas. 9.3.6.2 Ferramentas de Anlise Dinmica Ferramentas de anlise dinmica fornecem informaes de tempo de execuo sobre o estado do software sendo executado. Essas ferramentas so mais comumente usadas para identificar ponteiros no inicializados, verificar aritmtica de ponteiros, monitorar alocao, uso de desalocao de memria para marcar vazamentos de memria e evidenciar outros erros difceis de encontrar estaticamente. Ferramentas de memria deveriam ser reutilizadas em diversos nveis em sistemas complexos grandes, a partir do momento que problemas de memria so criados dinamicamente. Observe que diferentes ferramentas de teste comercial deveriam ser implementadas diferentemente, e ento mirariam e reportariam diferentes tipos de problemas de memria ou recurso (pilha, rvore heap). A concluso que duas ferramentas diferentes de memria poderiam identificar problemas diferentes. Ferramentas de memria so particularmente teis para algumas linguagens de programao (C, C++) nas quais o gerenciamento de memria deixado para o programador. Analistas tcnicos de teste usam essas ferramentas.
9.3.7 Automatizao de Teste Orientado a Palavra-chave

Palavras-chave (algumas vezes referenciadas como palavras de ao) so majoritariamente (mas no exclusivamente) usadas para representar interaes de negcio de alto nvel com o sistema (por exemplo, cancelar ordem). Cada palavra-chave tipicamente usada para representar diversas interaes detalhadas com o sistema sob teste. Sequncias de palavras-chave (incluindo dados de teste relevantes) so usadas para especificar casos de teste [Buwalda01]. Na automatizao de teste uma palavra-chave implementada como um ou mais scripts de teste executveis. Ferramentas leem casos de teste escritos com as palavras-chave e chamam os scripts de teste apropriados os quais as implementam. Os scripts so implementados de forma fortemente
Verso 2007br
Pgina 103 de 124
02 Fev 2010
Certified Tester
modular para permitir mapeamento fcil para especificar palavras-chave. Habilidades de programao so necessrias para implementar esses scripts modulares. As principais vantagens de automatizao de teste orientado a palavra-chave so: Palavras-chave podem ser definidas por especialistas de domnio, as quais so relacionadas a uma aplicao ou domnio de negcio em particular. Isso pode tornar a tarefa de especificao de caso de teste mais eficiente. Pessoas com conhecimento primrio no domnio podem se beneficiar com a execuo automtica de casos de teste (uma vez que as palavras-chave tenham sido implementadas como scripts). Casos de teste escritos usando palavras-chave usados para facilitar a manuteno porque eles so menos passveis de necessitar modificao se os detalhes do software sob teste muda. As especificaes de caso de teste so independentes de suas implementaes. As palavras-chave podem ser implementadas usando diversas linguagens de script e ferramentas.
Automatizao de teste baseado em palavra-chave usada frequentemente por especialistas de domnio e analistas de teste.
9.3.8 Ferramentas de Teste de Desempenho

Para informaes gerais a respeito de ferramentas de teste de desempenho, por gentileza referencie a seo 6.1.6 do ISTQB Foundation Level Syllabus Ferramentas para desempenho e monitorao. Ferramentas de teste de desempenho tm duas principais facilidades: Gerao de carga Medida e anlise da resposta do sistema em determinada carga
Gerao de carga realizada para implementar um perfil operacional pr-definido (veja seo 5.3.3) como um script. O script pode ser inicialmente capturado para um s usurio (possivelmente usando uma ferramenta de captura/execuo) e ento implementado para um perfil operacional especificado usando a ferramenta de teste de desempenho. Essa implementao deve levar em conta a variao de dado por transao (ou conjuntos de transaes). Ferramentas de desempenho geram carga atravs da simulao de um grande nmero de usurios mltiplos (usurios virtuais) com volumes especficos de dados de entrada. Em comparao com ferramentas de captura/execuo, vrios scripts de teste de desempenho reproduzem a interao do usurio com o sistema em um nvel de protocolo de comunicao e no atravs da simulao da interveno do usurio via interface grfica. Um nmero limitado de ferramentas de gerao de carga pode gerar carga atravs da conduo da aplicao usando sua interface de usurio. Uma grande variao de medies tomada pela ferramenta de teste de desempenho para permitir anlise durante ou aps a execuo do teste. Mtricas tpicas tomadas e reportes fornecidos incluem: Nmero de usurios simulados Nmero e tipo de transaes geradas pelos usurios simulados Tempos de resposta para transaes em particular requisitadas por usurios Relatrios baseados em registro de teste e grafos de carga com tempos de resposta.
Fatores significativos a serem considerados na implementao de ferramentas de teste de desempenho incluem:
Verso 2007br
Pgina 104 de 124
02 Fev 2010
Certified Tester
O hardware e a largura de banda da rede necessrios para gerar a carga A compatibilidade da ferramenta com protocolos de comunicao usados pelo sistema sob teste A flexibilidade da ferramenta para permitir perfis operacionais diferentes serem facilmente implementados As facilidades requeridas de monitorao, anlise e reporte
Ferramentas de teste de desempenho so tipicamente adquiridas devido ao esforo necessrio para desenvolv-las. Pode ser, no entanto, apropriado desenvolver uma ferramenta de desempenho especfica se restries tcnicas impedem que o produto seja usado, ou se o perfil de carga e as funcionalidades a serem fornecidas so relativamente simples. Ferramentas de teste de desempenho so usadas tipicamente por analistas tcnicos de teste. Nota: defeitos relativos a desempenho frequentemente tm um profundo impacto no SUT. Quando requisitos de desempenho so imperativos, interessante que sejam realizados testes de desempenho dos componentes crticos (via controladores e simuladores) ao invs de esperar pelos testes de sistema.
9.3.9 Ferramentas Web

Ferramentas de teste de hyperlink so usadas para varrer e verificar que nenhum hyperlink esteja quebrado ou faltante esteja presentes em um web site. Algumas ferramentas tambm fornecem informaes adicionais tais como grafos da arquitetura (arborescncia do site), a velocidade e o tamanho de download (por URL), acertos e volumes. Essas ferramentas podem ser teis tambm para monitorar adequao aos acordos de nvel de servio (Service Level Agreements SLA). Analistas de teste e analistas tcnicos de teste usam essas ferramentas.
Verso 2007br
Pgina 105 de 124
02 Fev 2010
Certified Tester
10. Competncias de Pessoas Composio de Equipe

Termos
Independncia do teste.
10.1
Introduo
Todos os profissionais de teste devem estar atentos para as competncias pessoais necessrias para realizar bem suas tarefas especficas. Esse captulo mantm foco inicialmente naquelas capacidades individuais e d prosseguimento com diversas questes especficas aos gerentes de teste, tais como dinmica de equipe, organizao, motivao e comunicao.
10.2
Competncias Individuais
Uma habilidade individual para o teste de software pode ser obtida atravs de experincia ou treinamento em diferentes reas de trabalho. Os seguintes itens podem contribuir para a base de conhecimento do testador: Uso de sistemas de software Conhecimento do domnio ou negcio Atividades em vrias fases do processo de desenvolvimento de software, incluindo anlise, desenvolvimento e suporte tcnico Atividades em teste de software Os usurios de sistemas de software conhecem bem o lado de usurio do sistema e tm um bom conhecimento de como o sistema operado, onde as falhas podem apresentar maiores impactos, e o que deveria ser esperado como reao do sistema. Usurios com conhecimento de domnios sabem quais reas so mais importantes para o negcio e como essas reas afetam na capacidade de atingir seus requisitos de negcio. Esse conhecimento pode ser usado para ajudar a priorizar as atividades de teste, criar dados realsticos e casos de teste, e verificar ou fornecer casos de uso. Conhecimento do processo de desenvolvimento de software (anlise de requisitos, modelagem e codificao) fornece discernimento sobre como os defeitos foram introduzidos, onde eles podem ser detectados e como prevenir sua introduo. Experincia em suporte tcnico fornece conhecimento de experincia de usurio, expectativas e requisitos de usabilidade. Experincia em desenvolvimento de software importante para uso de ferramentas especializadas de teste de automao que necessitam de conhecimento em programao e modelagem. Habilidades especficas em teste de software incluem a capacidade de analisar uma especificao, participar de anlises de risco, modelar casos de teste e a presteza para executar testes e armazenar os resultados. Especificamente para gerentes de teste o conhecimento, habilidade e experincia em gerenciamento de projeto so importantes a partir do momento que o gerenciamento de teste como executar um projeto, por exemplo, fazer planejamento, rastrear o progresso e relatar aos stakeholders. Habilidade interpessoal, tal como dar e receber crticas, influenciar e negociar so todas importantes na atividade do teste. Um testador tecnicamente competente pode falhar em suas atividades a menos que ele possua e use as habilidades interpessoais necessrias. Alm de trabalhar efetivamente com outros, um profissional de teste de sucesso deve ser bem organizado, atento ao detalhe e possuir fortes habilidades em comunicao verbal e escrita.
Verso 2007br
Pgina 106 de 124
02 Fev 2010
Certified Tester
10.3
Dinmica da Equipe de Teste
A seleo da equipe uma das funes mais importantes para a atividade de gerenciamento na organizao. H muitos itens a serem considerados alm das habilidades especficas individuais necessrias para o trabalho. Na seleo de um indivduo para compor a equipe, a dinmica da equipe deve ser considerada. Essa pessoa complementar as habilidades e tipos de personalidades j existentes na equipe de teste? importante considerar as vantagens de ter uma variedade de personalidades na equipe de teste, assim como uma mistura de competncias tcnicas. Uma equipe forte de teste capaz de lidar com vrios projetos de complexidade variada enquanto trata com sucesso as interaes interpessoais com os outros membros da equipe de projeto. Novos membros da equipe devem ser rapidamente assimilados na equipe e ser fornecida adequada superviso. A cada pessoa deve ser dado um papel definido na equipe. Isso pode ser baseado em um processo de avaliao individual. O objetivo fazer com que cada um tenha sucesso ao mesmo tempo em que um indivduo contribui com o sucesso geral da equipe. Isso largamente correspondido quando os tipos de personalidade so combinados aos papis da equipe e com base nas habilidades inatas dos envolvidos assim como incrementando seus portflios de habilidades. Um ponto importante a considerar que uma pessoa perfeita raramente estar disponvel, mas uma equipe forte pode ser construda atravs do equilbrio de foras e fraquezas dos indivduos. Treinamento interno equipe necessrio para manter e consolidar o conhecimento da equipe e aumentar a flexibilidade.
10.4
Ajustando o Teste em uma Organizao
Organizaes variam enormemente em como o teste se ajusta a sua estrutura organizacional. Enquanto que a qualidade responsabilidade de todos atravs do ciclo de vida de desenvolvimento do software, uma equipe de teste independente pode contribuir bastante para a qualidade do produto. A independncia da funo de teste varia bastante na prtica, como pode ser observado na lista a seguir, organizada desde o menos at o mais independente: Sem testadores independentes o Nesse caso no h independncia e o desenvolvedor testa seu prprio cdigo o O desenvolvedor, caso reserve tempo para realizar o teste, determinar se o cdigo funciona como intencionado, o que pode ou no corresponder aos requisitos reais o O desenvolvedor pode corrigir quaisquer defeitos rapidamente. O teste realizado por um desenvolvedor diferente que aquele que escreveu o cdigo o H pouca independncia entre o desenvolvedor e o testador o Um desenvolvedor testando o cdigo de outro desenvolvedor pode ser relutante em relatar defeitos o A mente do desenvolvedor em relao ao teste direcionada a casos de teste positivos O teste feito por um testador (ou equipe de teste) fazendo parte de uma equipe de desenvolvimento o O testador (ou equipe de teste) reportar ao gerente de projeto o A mente do testador direcionada mais em verificar a aderncia aos requisitos o Visto que o testador um membro da equipe de desenvolvimento, ele pode ter responsabilidades de desenvolvimento alm do teste Testadores da organizao de negcio, usurios da comunidade e outras organizaes tcnicas que no sejam de desenvolvimento o Reporte independente aos stakeholders o A qualidade o foco principal desta equipe o Desenvolvimento de competncias e treinamentos so direcionados ao teste Especialistas externos de teste realizam teste em alvos especficos de teste
Verso 2007br
Pgina 107 de 124
02 Fev 2010
Certified Tester
Os alvos de teste poderiam ser usabilidade, segurana ou desempenho A qualidade deve ser o foco desses indivduos, mas pode ser dependente da estrutura de reporte O teste feito por uma organizao externa empresa o A mxima independncia atingida o Transferncia de conhecimento pode no ser suficiente o Requisitos claros e estrutura de comunicao bem definida so necessrias o A qualidade da organizao externa deve ser auditada regularmente H vrios graus de independncia entre o desenvolvimento e organizaes de teste. importante entender que h a possibilidade de troca na qual mais independncia resulta em maior isolao e menor transferncia de conhecimento. Um nvel menor de independncia pode aumentar o conhecimento, mas tambm pode introduzir objetivos conflitantes. O nvel de independncia tambm ser determinado pelo modelo de desenvolvimento de software em uso, por exemplo, dentro de um desenvolvimento gil os testadores fazem parte da equipe de desenvolvimento. o o Qualquer uma das opes acima pode ser misturada em uma organizao. Pode haver teste realizado dentro da organizao de desenvolvimento assim como por uma equipe independente de teste e pode haver uma certificao final por uma organizao externa. importante entender as responsabilidades e expectativas para cada fase de teste e ajustar os requisitos para maximizar a qualidade do produto final enquanto se mantm dentro de limites de planejamento e oramento. Terceirizao uma das formas de usar uma organizao externa. O grupo terceirizado pode ser uma outra empresa que fornece servios de teste, a qual se mantm em sua localidade, externa sua, tanto no mesmo como em outro pas (algumas vezes referenciado como off-shore). A terceirizao traz desafios, particularmente quando externo ao seu pas. Alguns itens devem ser considerados incluindo: Diferenas culturais Superviso dos recursos terceirizados Transferncia de informao e de comunicao Proteo da propriedade intelectual Conjunto de habilidades, desenvolvimento de habilidades e treinamento Rotao de empregados Estimativa precisa de custo Qualidade
10.5

Motivao
H muitas maneiras de motivar um indivduo em uma posio de teste, incluindo: Reconhecimento do trabalho cumprido Aprovao da gerncia Respeito dentro da equipe de projeto e entre pares Recompensa adequada pelo trabalho realizado (incluindo salrio, aumento de mritos e bnus) H influncias de projeto que podem fazer com que essas ferramentas motivacionais sejam difceis de aplicar. Por exemplo, um testador pode trabalhar muito em um projeto que tem um prazo impossvel. O testador pode fazer tudo o que estiver em seu alcance para direcionar o foco de qualidade da equipe, colocar horas extras e esforo, e ainda o produto pode ser entregue antes do que deveria, devido a influncias externas. O resultado pode ser um produto de baixa qualidade mesmo com os melhores esforos do testador. Isso facilmente pode ser um desmotivador se a contribuio do testador no entendida ou medida, indiferentemente de quando o produto final tem sucesso.
Verso 2007br
Pgina 108 de 124
02 Fev 2010
Certified Tester
A equipe de teste deve assegurar que as mtricas apropriadas estejam sendo rastreadas para demonstrar um que bom trabalho foi realizado para cumprir o teste, mitigar os riscos e armazenar precisamente os resultados. A menos que esses dados sejam reunidos e divulgados, comum que a equipe se torne desmotivada quando eles no recebem o reconhecimento de que realizaram um bom trabalho. O reconhecimento no somente determinado em medidas impalpveis de respeito e aprovao, mas aparente em oportunidades de promoes, aumento de salrio e carreiras profissionais. Se o grupo de teste no respeitado, essas oportunidades podem no estar disponveis. O reconhecimento e respeito so adquiridos quando claro que o testador contribui para o valor incremental do projeto. Em um projeto individual, mais rapidamente alcanado com o envolvimento do testador desde a concepo do projeto e mantendo esse envolvimento atravs do ciclo de vida. Com o decorrer do tempo, os testadores conseguiro o reconhecimento e respeito atravs de sua contribuio ao desenvolvimento positivo do projeto, mas essa contribuio deve tambm ser quantificada em termos de custos de reduo de qualidade e mitigao de risco.
10.6
Comunicao
A comunicao na equipe de teste ocorre primariamente em trs nveis: Documentao de produtos de teste: estratgia de teste, plano de teste, casos de teste, relatrios de resumo de teste, relatrios de defeito, etc. Retorno dos documentos revisados: requisitos, especificaes funcionais, casos de uso, documentao de teste de componente, etc. Reunio e disseminao de informao: interao com desenvolvedores, outros membros da equipe de teste, gerncia, etc. Toda comunicao deve ser profissional, objetiva e efetiva para que seja construdo e mantido respeito para a equipe de teste. Diplomacia e objetividade so necessrias quando estiver fornecendo um retorno, particularmente um retorno construtivo, sobre os produtos de trabalhos de outros. Toda comunicao deve ser direcionada a alcanar os objetivos do teste e em melhorar a qualidade do produto e do processo usado para produzir os sistemas de software. Os testadores se comunicam para um grupo vasto de pessoas, incluindo usurios, membros da equipe de projeto, gerncia, grupos externos de teste e clientes. A comunicao deve ser efetiva para o pblico alvo. Por exemplo, um relatrio de defeito desenvolvido para a equipe de desenvolvimento pode ser detalhado em demasia para um resumo gerncia executiva.
Verso 2007br
Pgina 109 de 124
02 Fev 2010
Certified Tester
11. Referncias
11.1
11.1.1
Normas
Por Captulo
Esta seo lista as normas mencionadas neste syllabus.
Os seguintes Captulos referenciam as seguintes normas Captulo 2 BS-7925-2, IEEE 829, DO-178B/ED-12B. Captulo 3 IEEE829 D0-178B/ED-12B. Captulo 4 BS 7925-2. Captulo 5 ISO 9126. Captulo 06 IEEE 1028. Captulo 7 IEEE 829, IEEE 1044, IEEE 1044.1.
11.1.2

Alfabtico
As seguintes normas so mencionadas nos respectivos Captulos [BS-7925-2] BS 7925-2 (1998) Teste de Componente de Software Captulo 02 e 04 [IEEE 829] IEEE Std 829 (1998/2005) Norma IEEE de Documentao de Teste de Software (atualmente sob reviso) Captulo 02 e 03 [IEEE 1028] IEEE Std 1028 (1997) Norma IEEE de Revises de Software Captulo 06 [IEEE 1044] IEEE Std 1044 (1993) Norma IEEE de Classificao de Anomalias de Software Captulo 07 [ISO 9126] ISO/IEC 9126-1:2001, Engenharia de Software Qualidade de Produto de Software Captulo 05 [ISTQB] Glossrio ISTQB de termos usados em Teste de Software, Verso 2.0, 2007 [RTCA DO-178B/ED-12B]: Consideraes de Software em Sistemas de Aviao e Certificao de Equipamento, RTCA/EUROCAE ED12B.1992. Captulo 02 e 03
Verso 2007br
Pgina 110 de 124
02 Fev 2010
Certified Tester
11.2
Livros
[Beizer95] Beizer Boris, Black-box testing, John Wiley & Sons, 1995, ISBN 0-471-12094-4 [Black02]: Rex Black, Managing the Testing Process (2nd edition), John Wiley & Sons: New York, 2002, ISBN 0-471-22398-0 [Black03]: Rex Black, Critical Testing Processes, Addison-Wesley, 2003, ISBN 0-201-74868-1 [Black07]: Rex Black, Pragmatic Software Testing, John Wiley and Sons, 2007, ISBN 978-0-470-12790-2 [Burnstein03]: Ilene Burnstein, Practical Software Testing, Springer, 2003, ISBN 0-387-95131-8 [Buwalda01]: Hans Buwalda, Integrated Test Design and Automation Addison-Wesley Longman, 2001, ISBN 0-201-73725-6 [Copeland03]: Lee Copeland, A Practitioner's Guide to Software Test Design, Artech House, 2003, ISBN 1-58053-791-X [Craig02]: Craig, Rick David; Jaskiel, Stefan P., Systematic Software Testing, Artech House, 2002, ISBN 1-580-53508-9 [Gerrard02]: Paul Gerrard, Neil Thompson, Risk-based e-business testing, Artech House, 2002, ISBN 1-580-53314-0 [Gilb93]: Gilb Tom, Graham Dorothy, Software inspection, Addison-Wesley, 1993, ISBN 0-201-63181-4 [Graham07]: Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black Foundations of Software Testing, Thomson Learning, 2007, ISBN 978-1-84480-355-2 [Grochmann94]: M. Grochmann (1994), Test case design using Classification Trees, in: conference proceeedings STAR 1994 [Jorgensen02]: Paul C.Jorgensen, Software Testing, a Craftsmans Approach second edition, CRC press, 2002, ISBN 0-8493-0809-7 [Kaner02]: Cem Kaner, James Bach, Bret Pettichord; Lessons Learned in Software Testing; Wiley, 2002, ISBN: 0-471-08112-4 [Koomen99]: Tim Koomen, Martin Pol, Test Process Improvement, Addison-Wesley, 1999, ISBN 0-201-59624-5. [Myers79]: Glenford J.Myers, The Art of Software Testing, John Wiley & Sons, 1979, ISBN 0-471-46912-2 [Pol02]: Martin Pol, Ruud Teunissen, Erik van Veenendaal, Software Testing: A Guide to the Tmap Approach, Addison-Wesley, 2002, ISBN 0-201-74571-2 [Splaine01]: Steven Splaine, Stefan P.,Jaskiel, The Web-Testing Handbook, STQE Publishing, 2001, ISBN 0-970-43630-0 [Stamatis95]: D.H. Stamatis, Failure Mode and Effect Analysis, ASQC Quality Press, 1995, ISBN 0-873-89300 [vanVeenendaal02]: van Veenendaal Erik, The Testing Practitioner, UTN Publsihing, 2002, ISBN 90-72194-65-9 [Whittaker03]: James Whittaker, How to Break Software, Addison-Wesley, 2003, ISBN 0-201-79619-8 [Whittaker04]: James Whittaker and Herbert Thompson, How to Break Software Security, Peason / Addison-Wesley, 2004, ISBN 0-321-19433-0
Verso 2007br
Pgina 111 de 124
02 Fev 2010
Certified Tester
11.3
Outras referncias
As seguintes referncias apresentam informao disponvel na Internet. Apesar de que essas referncias foram verificadas na publicao deste Advanced Level Syllabus, o ISTQB/BSTQB no pode se responsabilizar que essas referncias ainda estejam disponveis. Captulo 05 - www.testingstandards.co.uk Captulo 06 - Taxonomia de Bug: www.testingeducation.org/a/bsct2.pdf - Exemplo de Taxonomia de Bug baseado no trabalho de Boris Beizer: inet.uni2.dk/~vinter/bugtaxst.doc - Boa reviso de vrias taxonomias: testingeducation.org/a/bugtax.pdf - Teste Baseado em Risco Heurstico por James BachJames Bach, Interview on What IsTesting.com. www.whatistesting.com/interviews/jbach.htm - www.satisfice.com/articles/et-article.pdf - De Exploratory & Risk-Based Testing (2004) www.testingeducation.org" - Explorando o Teste Exploratrio, Cem Kaner e Andy Tikam , 2003 - Pettichord, Bret, An Exploratory Testing Workshop Report, www.testingcraft.com/exploratorypettichord Captulo 09 - www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview06.pdf - TMMi www.tmmifoundation.org/
Verso 2007br
Pgina 112 de 124
02 Fev 2010
Certified Tester
12. Apndice A Syllabus background

Objetivos na Qualificao em Certificao Avanada
Para obter reconhecimento o teste como uma especializao profissional e essencial da engenharia de software. Para prover uma estrutura padro para o desenvolvimento da carreira dos testadores. Para possibilitar que testadores profissionalmente qualificados sejam reconhecidos por empresrios, clientes e colegas, e para promover um perfil de testador. Para promover boas e consistentes prticas de teste inseridas nas disciplinas de engenharia de software. Para identificar os tpicos do teste que so relevantes e de valor para o mercado. Para permitir que fornecedores de software contratem testadores certificados e, por meio disso, ganhem em vantagens comerciais sob seus competidores por propagar suas prpria poltica de recrutamento de testadores. Para fornecer uma oportunidade para os testadores e aqueles interessados no teste, a adquirir uma qualificao internacionalmente reconhecida no tema.
Requisitos bsicos para esta qualificao

Os critrios de entrada para fazer o exame para Certificao em Teste Advanced Level do ISTQB so: Ter um certificado de Nvel Fundamental, emitido por um Conselho de Exames reconhecido pelo ISTQB ou por um Conselho Membro. Ter um nmero apropriado de anos de experincia em teste de software ou desenvolvimento, como determinado pelo Conselho de Exame ou Conselho Membro que esteja concedendo a certificao. Subscrever ao Cdigo de tica deste Syllabus. tambm recomendvel que os candidatos participem de um curso que tenha sido credenciado pelo Conselho Membro do ISTQB. Um treinamento no requerido para obteno de qualquer exame ISTQB. Um certificado existente de Practitioner ou de nvel Avanado em Teste de Software (provenientes de um Conselho de Exames reconhecido pelo ISTQB ou por um Conselho Membro) anterior ao lanamento deste Certificado Internacional ser considerado equivalente ao Certificado Internacional. O Certificado Avanado no expira e no necessrio renovao. A data em que ele foi concedido mostrada no Certificado. Internamente em cada pas participante, aspectos locais so controlados pelo Conselho Membro reconhecido pelo ISTQB. Obrigaes dos Conselhos Membros so especificadas pelo ISTQB, mas so implementadas dentro de cada pas. As obrigaes dos Conselhos Membros incluem credenciamento de provedores de treinamento e organizao de exames, diretamente ou indiretamente atravs de um ou mais Conselhos de Exames Contratados. O Conselho Membro do Brasil, o BSTQB, cuidar de todas as obrigaes devidas dentro do pas.
Verso 2007br
Pgina 113 de 124
02 Fev 2010
Certified Tester
13. Apndice B Aviso aos Leitores

13.1 Comisses de Exame
Este Advanced Level Syllabus requer conhecimento do contedo da Certificao em Teste Foundation Level Syllabus do ISTQB, verso 2005 (traduo BSTQB, verso 2007br), com o nvel de conhecimento especificado no Foundation Level Syllabus. Comisses de exame reconhecidas pelo ISTQB podem gerar questes baseados em qualquer tpico mencionado nesse syllabus. recomendvel que as questes geradas sejam especificadas com diferentes valores em relao aos objetivos de aprendizado dos seus tpicos respectivos. Por exemplo: uma questo pertencente ao nvel de conhecimento K1 pode receber pontuao menor que uma correspondente ao nvel de conhecimento K3, ao passo que uma questo no nvel de conhecimento K4 poderia receber pontuaes ainda maiores.
13.2
Candidatos & Provedores de Treinamento
Para obter a certificao em Nvel Avanado, os candidatos devem ter a Certificao em Nvel Fundamental e satisfazer a avaliao da Comisso de Exame relativa experincia prtica do candidato para ser considerado qualificado para o Nvel Avanado. Procure pela Comisso de Exame para conhecer seu critrio para experincia prtica. O ISTQB sugere um mnimo de 5 anos de experincia prtica em engenharia de software como um pr-requisito para obter o Nvel Avanado, ou 3 anos de experincia prtica para o caso de o candidato ter bacharelado ou grau equivalente em Cincia ou Engenharia da Computao, ou em cursos relacionados a serem avaliados pela Comisso de Exame. Atingir o nvel adequado de proficincia para alcanar um status de proficiente em Nvel Avanado em Teste de Software requer mais do que somente conhecer o contedo deste syllabus. Os candidatos e provedores de treinamento so encorajados a despender, em leitura e pesquisa, mais tempo do que o indicado neste syllabus. Este syllabus fornece uma lista de referncias, livros e padres que os candidatos e provedores de treinamento poderiam ler para entender os tpicos especficos em maiores detalhes.
Verso 2007br
Pgina 114 de 124
02 Fev 2010
Certified Tester
14. Apndice C Aviso aos Provedores de Treinamento

14.1 Modularidade
Este syllabus apresenta contedo para trs mdulos, denominados: Advanced Level Test Manager Advanced Level Test Analyst Advanced Level Technical Test Analyst Passando em todos os mdulos o candidate obtm a certificao Full Advanced Level Testing Professional.
14.2
14.2.1
Ritmo de Treinamento
Treinamento por Mdulo
O tempo necessrio recomendando para o ensino dos 3 diferentes perfis colocado a seguir: Advanced Level Test Manager 5 dias Advanced Level Test Analyst 5 dias Advanced Level Technical Test Analyst 5 dias Essa durao baseada no nmero de Captulos por mdulo e os objetivos de aprendizagem especficos para cada Captulo. A durao mnima especfica lista para cada Captulo, para cada perfil. Provedores de treinamento podem utilizar mais tempo do que o indicado, e candidatos podem gastar mais tempo em leitura e pesquisa. Uma ementa de treinamento no necessita seguir a mesma ordem que este syllabus. Os treinamentos no precisam ser em dias consecutivos. Provedores de treinamento podem decidir por organizar seus cursos diferentemente, tal como em 3+2 dias para Test Management, ou 2 dias em comum seguidos de 3 dias para cada perfil de Test Analysts e Technical Test Analysts.
14.2.2
Partes em Comum
Provedores de treinamento podem escolher tpicos em comum para serem ensinados em conjunto, reduzindo o tempo total e evitando repeties. Os provedores de treinamento devem tambm ficar atentos para o fato de que algumas vezes o mesmo tpico pode ser visto de diferentes ngulos dependendo do mdulo.
14.2.3
Fontes
O syllabus contm referncias para padres estabelecidos, os quais devem ser usados na preparao de material de treinamento. Cada padro usado deve ser usado na verso referenciada na verso atual deste syllabus. Outras publicaes, modelos, ou padres no referenciados neste syllabus tambm podem ser usados e referenciados, mas no sero avaliados.
14.3
Exerccios Prticos
Atividades prticas (exerccios curtos) devem ser includas para todos os aspectos nos quais os candidatos devem aplicar seu conhecimento (Objetivo de Aprendizagem K3 ou maior). Os textos e
Verso 2007br
Pgina 115 de 124
02 Fev 2010
Certified Tester
exerccios devem ser baseados nos Objetivos de Aprendizagem e na descrio dos tpicos no contedo do syllabus.
Verso 2007br
Pgina 116 de 124
02 Fev 2010
Certified Tester
15. Apndice D Recomendaes

Na medida em que as seguintes recomendaes se aplicam aos vrios Captulos deste syllabus, eles foram compilados e agrupados em um apndice. Os itens listados a seguir so passveis de avaliao. Esta lista fornece diversas recomendaes teis para enfrentar desafios de teste, baseados na lista dos sete princpios bsicos de teste introduzidos no Nvel Fundamental. A lista apresentada neste apndice no tem a inteno de ser completa, mas sim de oferecer um conjunto de lies aprendidas, as quais deveriam ser consideradas. Provedores de treinamento escolhero os pontos desta lista que sejam de maior relevncia para o mdulo sendo discutido.
15.1
Recomendaes para Industrializao
Ao implementar testes na indstria, um profissional pode encarar diversos desafios. Testadores em nvel avanado devem ser capazes de utilizar as diferentes recomendaes descritas neste syllabus com o foco no contexto de sua organizao, equipes, tarefas e componentes de software. A lista a seguir apresenta algumas reas que comprovadamente impactam de forma negativa no desempenho dos esforos de teste. Note que a lista no tem a inteno de ser completa. Gerar planos de teste com inclinao ao teste funcional Defeitos no so limitados a aspectos funcionais, ou a um s usurio. A interao de mltiplos usurios pode ter impacto no software sob teste. Testes de configurao no suficientes Se mltiplos tipos de processadores, sistemas operacionais, mquinas virtuais, navegadores e vrios perifricos podem ser combinados em vrias possveis configuraes, limitar o teste a um pequeno conjunto dessas configuraes pode deixar uma grande quantidade de defeitos em potencial no descobertos. Deixar os testes de estresse e carga para o ltimo minuto O resultado de testes de estresse e carga podem necessitar grandes mudanas no software (inclusive incluindo a arquitetura bsica). A partir do momento que isso pode requerer recursos considerveis para ser implementado, pode ser fortemente negativo ao projeto se esses testes forem realizados logo antes da entrada planejada para produo. No testar a documentao Usurios recebem o software e a documentao. Se a documentao no corresponder ao software, o usurio no ser capaz de utilizar a potencialidade completa do software, ou pode at descartar o software completamente. No testar os procedimentos de instalao Procedimentos de instalao, assim como procedimentos de backup e restore, so realizados em nmero pequeno de vezes. Esses procedimentos so, no entanto, mais crticos que o software; se o software no pode ser instalado, ele no ser usado de qualquer forma. Insistir em completar inteiramente uma tarefa de teste antes de mudar para a prxima Mesmo que alguns modelos de ciclo de vida de desenvolvimento de software sugerem uma execuo sequencial de tarefas, na prtica, vrias tarefas frequentemente podem ser realizadas (pelo menos parcialmente) concorrentemente. Falhar em identificar corretamente reas de risco Algumas reas podem ser identificadas como passveis de risco e com isso serem testadas mais completamente. No entanto, as reas deixadas com nenhum ou um mnimo de teste podem se mostrar mais passveis de risco do que originalmente estimadas. Ser muito especfico a respeito das entradas de teste e procedimentos Ao no dar aos testadores escopo suficiente para sua iniciativa prpria em termos de definio de entradas de teste e procedimentos, o testador pode no ser encorajado a
Verso 2007br
Pgina 117 de 124
02 Fev 2010
Certified Tester
examinar reas que podem parecer promissoras (em termos de possveis defeitos escondidos) No perceber e explorar uma singularidade irrelevante Observaes ou resultados podem ser visto como irrelevantes so frequentemente indicadores de defeitos que (como icebergs) esto espreitando por debaixo da superfcie. Verificar que o produto faz o que se espera que ele faa, e que no faz o que se espera que ele no faa Ao limitar somente ao que se espera do produto possvel que se perca alguns aspectos do software que ele no deveria fazer (funes adicionais e no desejadas, por exemplo) Suites de teste que so inteligveis somente pelos seus donos Os testadores podem ser alocados em outras reas de responsabilidade. Outros testadores devero ler e entender os testes previamente especificados. Falhar em fornecer especificaes de teste legveis e inteligveis pode ser um impacto negativo porque os objetivos de teste podem no ser entendidos ou o teste pode ser completamente removido. Testar somente a interface visvel ao usurio As interfaces do software no so limitadas s interfaces dos usurios. Comunicaes entre processos, execues batch e outras interrupes podem tambm interagir com o software, e podem gerar defeitos. Reporte de bugs e gerenciamento d configurao ruins Reporte e gerenciamento de incidente, assim como um gerenciamento de configurao, so extremamente importantes para garantir o sucesso do projeto inteiro (o qual inclui desenvolvimento, assim como teste). Um testador de sucesso pode ser considerado como aquele que consegue ter os defeitos corrigidos, ao invs daquele que encontra muitos defeitos, mas falha ao report-los bem o suficiente para serem corrigidos. Adicionar somente testes de regresso A evoluo das suites de teste no limitada pela verificao que nenhum defeito de regresso ocorreu. O cdigo ir evoluir com o tempo e testes adicionais sero necessrios para cobrirem essas novas funcionalidades, assim como para procurar por regresses em outras reas do software. Falhar em tomar notas para o prximo esforo de teste As tarefas de teste no terminam quando o software fornecido ao usurio ou distribudo ao mercado. Uma nova verso ou release do software possivelmente seja produzida, ento o conhecimento deveria ser armazenado e transferido aos testadores responsveis pelo prximo esforo de teste. Esforar em automatizar todos os testes A automatizao pode ser vista como uma boa ideia, mas automatizao por si s um projeto de desenvolvimento. Nem todos os testes devem ser automatizados: alguns testes so mais rpidos de serem feitos manualmente do que automatizados. Esperar que todos os testes manuais sejam reexecutados Ao reexecutar testes manuais, frequentemente irreal esperar que todos os testes sejam reexecutados. A extenso da ateno dos testadores oscilar e os testadores tendero a ter foco em reas particulares do software, tanto conscientemente ou no. Usar uma ferramenta de automatizao GUI para reduzir o custo da criao de teste Uma ferramenta GRUI de captura/replay representa um investimento inicial importante e deveria somente ser usada para apoiar uma estratgia definida, com os custos associados bem compreendidos e avaliados. Esperar que testes de regresso encontrem um grande proporo de novos bugs Testes de regresso geralmente no encontram uma grande proporo de defeitos, principalmente porque so testes que j foram executados (por exemplo, para um verso anterior do mesmo software) e defeitos devem ter sido detectados naquelas execues anteriores. Isso no significa que os testes de regresso devem ser completamente eliminados, somente que a eficincia (capacidade de detector novos defeitos) dos testes de regresso menor que para outros testes.
Verso 2007br
Pgina 118 de 124
02 Fev 2010
Certified Tester
Adotar a cobertura de cdigo com tal devoo que somente nmeros podem inspirar Cobertura de cdigo e mtricas podem ser vistas como de muito interesse por um ponto de visto de gerenciamento, baseado nos nmeros e grficos fornecidos, mas nmeros no podem refletir a eficincia ou a pertinncia do teste. Um exemplo:100% um bom objetivo para cobertura de cdigo, mas ser um objetivo realstico, ou um objetivo adequado (isso , em cobertura de instruo, condio, ou MCDC (Modified Condition/Decision Coverage))? Remover testes de uma suite de testes de regresso somente porque eles no adicional cobertura Em uma sute de teste de regresso, alguns testes podem (e devem) ser removidos e alguns outros acrescentados. O motivo para remover no deve ser fundamentado somente em quanto o teste adiciona em cobertura, visto que um caso de teste pertinente (pelo tipo de defeito que ele verifica) pode no ter impacto na cobertura. Exemplo: cobertura de cdigo no nico tipo de cobertura; os testes podem ser criados com outras motivaes (tais como valores especficos e sequncia de eventos) alm de uma simples cobertura. Usar cobertura como um objetivo de desempenho para os testadores A cobertura uma medida de integridade, no de desempenho ou eficincia pessoal. Outras mtricas podem ser definidas para avaliar a eficincia de um testador no contexto de sua organizao e projeto. O uso de tais mtricas deve ser cuidadosamente planejado para evitar efeitos indesejados (disfunes). Abandonar a cobertura completamente Diferentes tipos de cobertura esto disponveis (por exemplo, comandos de cdigo, condies, mdulos, funes, etc.) e a carga de trabalho para obter as mtricas adequadas pode ser significativa. No entanto, isso no motivo para abandonar mtricas de cobertura completamente, visto que elas podem ser muito teis para a tarefa de teste. Muitos desses pontos colocados so tratados dentro do contexto de sees especficas deste syllabus. Ao introduzir mtricas e prticas de teste em sua organizao, pode ser til considerar no somente a lista dos pontos acima, mas tambm devem ser consideradas fontes adicionais de informao, tais como: Os syllabi ISTQB (Foundation e Advanced) Livros inclusos na lista de referncia deste syllabus Modelos de referncia tais como os cobertos na seo 8.3.
Verso 2007br
Pgina 119 de 124
02 Fev 2010
Certified Tester
16. ndice
acessibilidade, 65 acompanhamento, 77 acurcia, 65 adequao, 65 ajustando o teste em uma organizao, 107 anlise de causa raiz, 82 anlise de fluxo de controle, 55 anlise de fluxo de dados, 55 anlise de pontos de teste, 36 anlise de risco, 36, 46 anlise de valor limite, 55, 56 anlise dinmica, 55, 62 cobertura, 58 desempenho, 64 vazamentos de memria, 63 viso geral, 62 wild pointers, 63 anlise esttica, 55, 61 arquitetura, 62 cdigo, 61 controle de fluxo, 61 fluxo de dados, 61 grafo de chamadas, 62 padres de codificao, 61 web site, 62 anomalia, 82 apndice A, 113 apndice B, 114 apndice C, 115 apndice D, 117 arrays ortogonais, 56 rvore de classificao, 55 aspecto heterogneo do software, 71 aspectos bsicos de teste de software, 22 ataques, 60, 70 ataques de software, 55 atividades de encerramento de teste, 34 atividades de teste, 23 atributos de qualidade para teste de domnio, 65 atributos de qualidade para teste tcnico, 68 auditoria, 77 avaliao, 67 avaliao do critrio de sada e relatrio, 33 BVA, 55, 56 caminho D-D, 55, 58 capacidade de anlise, 74 capacidade de mudana, 74 caso de teste, 28 cenrios, 57 ciclo de vida do software, 22 CMMI, 94 cobertura de comando, 55 Cdigo de tica, 27 coexistncia, 75 comit de controle de configurao, 82 competncias individuais, 106 composio de equipe, 106 comunicao, 109 condio de teste, 28 confiabilidade, 65 consideraes de comunicao, 54 consideraes de segurana dos dados, 54 consideraes sobre normas, 85 controle de teste, 28, 36 critrio de sada, 28 CTP, 89, 90, 93 defeito, 82 ao, 83 campos, 83 ciclo de vida, 82 deteco, 82 disposio, 83 gerenciamento, 84 investigao, 83 mtricas, 84 reconhecimento, 83 desuso, 25 determinao de condio, 55 diagramas de estado e tabelas, 56 dinmica da equipe de teste, 107 documentao de gerenciamento de teste, 36 documentao de plano de teste, 39 eficincia, 65 encerramento de teste, 28 entrada & sada, 23 entregveis, 23 erro, 82 especificao de teste de confiabilidade, 72 especificao de teste de eficincia, 73 especificao de teste de segurana, 70 espectativas, 11 estabilidade, 74 estimativa de teste, 36, 39 estratgia de teste, 36, 37 tica, 22, 27 execuo de teste, 28, 32
Verso 2007br
Pgina 120 de 124
02 Fev 2010
Certified Tester
exploratrio, 60 failover, 71 falha, 82 falso negativo, 32 falso positivo, 32, 103 fatores organizacionais, 53 FDA, 88 ferramenta analisador esttico, 95 anlise dinmica, 95 depurao, 95 desempenho, 95 emulador, 95 execuo de teste, 95 gerenciamento de teste, 95 injeo de faltas, 95 orculo de teste, 95 simulador, 95 teste de hyperlink, 95 ferramental necessrio, 53 ferramentas de teste, 23 anlise, 103 anlise dinmica, 103 anlise esttica, 103 captura-replay, 100 classificao, 100 conceitos, 95 custo-benefcio, 96 depurao, 102 desempenho, 104 desenvolvendo sua prpria ferramenta de teste, 99 estratgias, 97 ferramentas de execuo de teste, 101 ferramentas web, 105 gerenciamento de teste, 100 implantao, 98 injeo de faltas, 102 integrao & troca de informao, 97 investigao, 102 orculos de teste, 98 palavras-chave, 104 riscos, 96 scripts, linguagem de script, 98 semeadura de faltas, 102 simulao & emulao, 103 ferramentas de teste e automatizao, 95 FMEA, 36 aplicao, 49 custos & benefcios, 50 descrio, 49 fases, 50 gerenciamento de incidente, 82
gerenciamento de risco, 36, 45 gerenciamento de risco no ciclo de vida, 48 gerenciamento de teste, 36 gerenciamento de teste baseado em seo, 36 grafo de causa-efeito, 55 grafos de causa efeito, 56 harware requerido, 53 heurstica, 65, 68 HSIA, 88 identificao de risco, 36 identificao do risco, 45 implementao & execuo de teste, 31 implementao de teste, 28, 31 incidente, 82 independncia do teste, 106 indstria espacial, 88 inspeo, 67, 77 instalabilidade, 74 Integrao do Modelo de Maturidade e Capacidade, 94 integrao por pares, 62 integrao por vizinhana, 62 interoperabilidade, 65 introduo melhoria de processo, 89 ISO ISO 9126, 31, 46 largura-primeiro, 48 LCSAJ, 55, 58 Levantamentos, 68 lder de inspeo, 77 lista de checagem, 60 mantenabilidade, 65 manuteno adaptativa, 74 manuteno corretiva, 74 MCDC, 58 medio, 22 Melhoria de Processo de Teste, 85 melhoria do processo de teste com CTP, 93 melhoria do processo de teste com STEP, 93 melhoria do processo de teste com TMM, 91 melhoria do processo de teste com TPI, 92 melhoria no processo de teste, 90 mtrica, 22 mtricas, 23, 31, 35 CTP, 93 defeitos, 84 desempenho, 64 externas (ISO 9126), 86 internas (ISO 9126), 86 qualidade, 86
Verso 2007br
Pgina 121 de 124
02 Fev 2010
Certified Tester
STEP, 94 TPI, 92 mtricas & medies, 26 mitigao de risco, 36 mitigao do risco, 47 modelagem & anlise de teste, 29 modelagem de teste, 28 modelo de ciclo de vida cascata, 22, 23 espiral, 23 evolucionrio, 22, 23 iterativo, 22 metodologias geis, 22, 23 modelo V, 22, 23 modelo W, 22, 23 RAD, 22, 23 Rapid Application Development, 22 modelo de crescimento de confiabilidadel, 65 Modelo de Maturidade de Teste, 85 Modelo de Maturidade e Capacidade, 85 modelos, 39 modelos de processo de teste, 28 moderador, 77 monitorao & controle do progresso do teste, 41 monitorao de teste, 36 motivao, 108 MTBF, 70 MTTR, 70 nvel de planejamento de teste, 36 nvel de risco, 36 nvel de teste, 36 normas aspectos gerais, 86 BS 7925, 28, 55 BS-7925-2, 33, 68, 87 CMM, 85 CMMI, 85 coerncia, 86 DO-178B, 31, 47, 87 domnio especfico, 87 ECSS, 88 ED-12B, 47, 87 fontes, 86 IEC 61508, 47 IEEE, 87 IEEE 1028, 77, 87 IEEE 1044, 82, 83, 87 IEEE 610, 87 IEEE 829, 28, 30, 37, 82, 87 ISO, 86 ISO 12207, 86
ISO 15504, 87 ISO 9126, 31, 46 nacionais, 87 TMM, 85 TMMi, 85 TPI, 85 UML, 68 utilidade, 86 normas & processo de melhoria de teste, 85 normas internacionais, 86 OAT, 69 objetivos technical test analyst, 11 test analyst, 11 test management, 11 objetivos da qualificao, 113 objetivos de aprendizagem technical test analyst, 18 test analyst, 16 test manager, 13 operational acceptance test, 69 orculo de teste, 98 outras quests de gerenciamento de teste, 52 painel de teste, 55 partio de equivalncia, 55, 56 perfil operacional, 65 planejamento & controle de teste, 29 planejamento da programao de teste, 41 planejamento de teste, 28 plano de nvel de teste, 39 plano de teste, 36 plano mestre de teste, 36, 38 poltica de defeitos, 84 poltica de teste, 36 princpios das revises, 77 prioridade, 82 procedimento de teste, 28 processo de melhoria de teste, 89 processos de teste, 28 profundidade-primeiro, 48 programao de teste, 36 questionrios, 68 questes de gerenciamento de teste, 50 sistemas de segurana crtica, 51 sistemas de sistemas, 51 teste exploratrio, 50 rastreabilidade, 23, 25 recuperabilidade, 65 registro de incidente, 82 registro de teste, 28 relatrio, 23 relatrio de resumo de teste, 28
Verso 2007br
Pgina 122 de 124
02 Fev 2010
Certified Tester
requisitos de entrada, 113 requisitos dos stakeholder, 52 reviso, 67, 77 reviso gerenciada, 77 reviso informal, 77 reviso tcnica, 77 revises, 77 auditorias, 78 fatores de sucesso, 80 introduo s revises, 79 princpios, 77 produtos de trabalho especficos, 78 revises formais, 79 tipos, 78 revisor, 77 risco de produto, 36 risco de projeto, 36 SBTM, 50 SCCFA, 88 script de teste, 28 segurana de acesso, 65 severidade, 82 SFMEA, 49 SFMECA, 88 SFTA, 88 sistemas complexos, 26 sistemas de aviao, 87 sistemas de segurana crtica, 22, 25 complexidade, 26 conformidade com regulamentao, 25 sistemas de sistemas, 22, 24, 26, 45 caractersticas do ciclo de vida, 25 gerenciamento & teste, 24 sistemas especficos, 24 SQR, 89 SRET, 71 STEP, 89, 90, 93 SUMI, 68 suposio de erro, 55, 60 tabela de deciso, 55, 56 tabela de todos os pares, 56 taxonomia de defeito, 55 taxonomias, 59 tcnica baseada em defeito, 55, 59 tcnica baseada em especificao, 55 tcnica baseada em estrutura, 55 tcnica baseada em experincia, 55, 59 tcnicas, 23 tcnicas de caixa-preta, 55 tcnicas de teste, 55 testabilidade, 74 teste baseado em defeito, 59 teste baseado em especificao, 55
teste baseado em experincia, 59 teste baseado em requisitos, 55 teste baseado em risco, 36, 44 teste de aceite operacional, 65 teste de acessibilidade, 68 teste de acurcia, 66 teste de adequao, 66 teste de caminho, 55, 58 teste de capacidade de adaptao, 75 teste de capacidade de substituio, 75 teste de caractersticas de software, 65 teste de carga, 72 teste de caso de uso, 55 teste de comando, 57 teste de condio, 55, 57 teste de condio mltipla, 58 teste de condies mltiplas, 55 teste de deciso, 55, 57 teste de desempenho, 72 teste de desvio, 55, 57 teste de determinao de condio, 58 teste de eficincia, 72 teste de escalabilidade, 73 teste de especificao de usabilidade, 67 teste de estresse, 73 teste de integrao de hardware-software, 23 teste de integrao de produto cliente, 23 teste de integrao de sistema, 23 teste de interoperabilidade, 66 teste de mantenabilidade, 74 teste de portabilidade, 65, 74 teste de recuperabilidade, 71 teste de robustez, 71 teste de segurana funcional, 66 teste de sistema, 69 teste de transio de estado, 55 teste de usabilidade, 66 teste de utilizao de recursos, 73 teste dinmico de mantenabilidade, 74 teste distribudo, outsourced & insourced, 43 teste exploratrio, 55 teste orientado a palavra-chave, 95 teste pareado, 55 teste tcnico de segurana, 69 testes baseados na estrutura, 57 TIM, 89 tipo de risco, 36 tipos de melhoria de processo, 89 TMM, 89 TMMI, 90 TOM, 89
Verso 2007br
Pgina 123 de 124
02 Fev 2010
Certified Tester
TPI, 89, 90, 92 usabilidade, 65 validao, 68 valor de negcio do teste, 42
vazamento de memria, 55 WAMMI, 68 wide band delphy, 36 wild pointer, 55
Verso 2007br
Pgina 124 de 124
02 Fev 2010

Ctal Syllabus 2007br

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ctal Syllabus 2007br

Enviado por

Direitos autorais:

Formatos disponíveis

Brazilian Software Testing Qualifications Board

Certificao em Teste Advanced Level Syllabus

Comisso Internacional para Qualificao de Teste de Software

Verso ISEB v1.1 ISTQB 1.2 E V2007 V2007br V2007br

0. Introduo a Este Syllabus

Objetivo deste documento

O Certified Tester Advanced Level em testes de software

Como este syllabus est organizado

0.2.1 Advanced Level Test Manager

0.2.2 Advanced Level Test Analyst

0.2.3 Advanced Level Technical Test Analyst

0.3 Objetivos de Aprendizagem / Nveis de Conhecimento

0.4 Objetivos de Aprendizagem para Test Manager

(Incluindo reviso ao Foundation Level Syllabus do ISTQB)

1.3 Sistemas Especficos

1.4 Mtricas & Medies

Captulo 2: Processos de Teste [120 minutos] 2.3 Planejamento e Controle de Teste

2.5 Implementao e Execuo de Teste

2.6 Avaliao de Critrio de Sada e Reporte

2.7 Atividades de Encerramento de Teste

Captulo 3: Gerenciamento de Teste [1120 minutos] 3.2 Documentao de Gerenciamento de Teste

3.3 Documentao de Plano de Teste

3.4 Estimativa de Teste

3.5 Programando o Planejamento de Teste

3.6 Monitoramento & Controle do Progresso de Teste

3.7 Valor de Negcio do Teste

3.8 Teste Distribudo, Outsourced & Insourced

3.9 Teste Baseado em Riscos 3.9.1 Introduo ao Teste Baseado em Riscos

3.9.2 Gerenciamento de Risco

3.9.3 Gerenciamento de Risco em um Ciclo de Vida

6.4 Introduo s Revises

6.5 Fatores de Sucesso para Revises

Captulo 7: Gerenciamento de Incidente [80 minutos]

9.3 Categorias de Ferramenta de Teste

10.3 Dinmica da Equipe de Teste

10.4 Adequando o Teste a uma Empresa

10.5 Motivao 10.6 Comunicao

0.5 Objetivos de Aprendizagem para Test Analyst

(Incluindo reviso ao Foundation Level Syllabus do ISTQB)

Captulo 2: Processos de Teste [180 minutos] 2.4 Anlise e Modelagem de Teste

2.5 Implementao e Execuo de Teste

2.6 Avaliao de Critrio de Sada e Reporte

Captulo 3: Gerenciamento de Teste [120 minutos] 3.9.2 Teste Baseado em Riscos

Captulo 4: Tcnicas de Teste [1080 minutos] 4.2 Baseado em Especificao

4.4 Baseado em Defeito e Experincia

5.3 Atributos de Qualidade para Teste Tcnico

Captulo 6: Revises [180 minutos]

Captulo 7: Gerenciamento de Incidente [120 minutos]

9.3 Categorias de Ferramenta de Teste

0.6 Objetivos de Aprendizagem para Technical Test Analyst

(Incluindo reviso ao Foundation Level Syllabus do ISTQB)

2.5 Implementao e Execuo de Teste

2.6 Avaliao de Critrio de Sada e Reporte

Captulo 3: Gerenciamento de Teste [120 minutos] 3.9.2 Teste Baseado em Riscos

Captulo 4: Tcnicas de Teste [930 minutos] 4.2 Baseado em Especificao

4.3 Baseado em Estrutura

4.4 Baseado em Defeito e Experincia

4.5 Anlise Esttica

4.6 Anlise Dinmica

5.3 Atributos de Qualidade para Teste Tcnico

Captulo 6: Revises [180 minutos]

Captulo 7: Gerenciamento de Incidente [120 minutos]

9.3 Categorias de Ferramenta de Teste

9.3.7 Automatizao de Teste Dirigido a Palavra-chave