Escolar Documentos
Profissional Documentos
Cultura Documentos
Syllabus Ctal 2007br
Syllabus Ctal 2007br
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
Advanced Level Syllabus
Histrico de Revises
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
International Software Testing Qualifications Board
Pgina 3 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 4 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 5 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 6 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 7 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 8 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 9 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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
International Software Testing Qualifications Board
Pgina 10 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 11 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Conduzir atividades tcnicas de teste Fornecer as evidncias necessrias para apoiar avaliaes Implementar as ferramentas e tcnicas necessrias para atingir metas definidas
Verso 2007br
International Software Testing Qualifications Board
Pgina 12 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
(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.
(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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 13 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
(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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 14 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
(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.
(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.
Captulo 8: Normas & Processo de Melhoria de Teste [120 minutos] 8.4 Melhoria nos Processos de Teste
Verso 2007br
International Software Testing Qualifications Board
Pgina 15 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
(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.
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 16 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
(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.
(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.
(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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 17 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 18 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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]
(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.
(K2) Listar as atividades de uma abordagem baseada em riscos para o planejamento e execuo tcnica de teste
(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
Verso 2007br
International Software Testing Qualifications Board
Pgina 19 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 20 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
(K3) Especificar casos de teste para tipos no-funcionais de teste de manuteno e portabilidade.
(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.
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
International Software Testing Qualifications Board
Pgina 21 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 22 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 23 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.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
International Software Testing Qualifications Board
Pgina 24 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 25 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 26 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 27 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 28 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 29 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 30 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 31 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 32 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 33 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 34 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 35 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 36 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 37 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 38 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 39 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 40 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 41 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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)
Verso 2007br
International Software Testing Qualifications Board
Pgina 42 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 43 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 44 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 45 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 46 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 47 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 48 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 49 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
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
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
International Software Testing Qualifications Board
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
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
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
International Software Testing Qualifications Board
Pgina 51 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
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
International Software Testing Qualifications Board
Pgina 52 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 53 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 54 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 55 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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
International Software Testing Qualifications Board
Pgina 56 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 57 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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 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.
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
International Software Testing Qualifications Board
Pgina 58 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 59 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 61 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 62 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 63 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Ferramentas podem identificar wild pointers quando so usados pelo programa, sem restrio quanto suas consequncias na execuo do programa.
Verso 2007br
International Software Testing Qualifications Board
Pgina 64 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 65 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
O teste de interoperabilidade pode ser particularmente significativo para: Empresas desenvolvendo software e ferramentas como Sistemas de Prateleira (COTS) Desenvolvimento de sistemas de sistemas
Verso 2007br
International Software Testing Qualifications Board
Pgina 66 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 67 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 68 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 69 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 70 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 71 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 72 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 73 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 74 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 75 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 76 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 77 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 78 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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
International Software Testing Qualifications Board
Pgina 79 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 80 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
Pgina 81 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 82 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 83 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 84 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 85 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Algumas consideraes so aplicveis quando usando normas. Essas so descritas a seguir nessa seo.
Verso 2007br
International Software Testing Qualifications Board
Pgina 86 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Nvel de Criticidade
1
Verso 2007br
International Software Testing Qualifications Board
Pgina 87 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 88 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 89 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Nota da verso brasileira: as iniciais marcadas formam a palavra IMPROVE que significa melhorar, aperfeioar.
Verso 2007br
International Software Testing Qualifications Board
Pgina 90 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 91 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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).
Verso 2007br
International Software Testing Qualifications Board
Pgina 92 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 93 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 94 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
Pgina 95 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
Pgina 96 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
Verso 2007br
International Software Testing Qualifications Board
Pgina 97 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
usurio seja similar, que as ferramentas automaticamente fornecem integrao e troca de informao entre elas.
Verso 2007br
International Software Testing Qualifications Board
Pgina 98 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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)
Verso 2007br
International Software Testing Qualifications Board
Pgina 99 de 124
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
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.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
10.3
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
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
11. Referncias
11.1
11.1.1
Normas
Por Captulo
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
exerccios devem ser baseados nos Objetivos de Aprendizagem e na descrio dos tpicos no contedo do syllabus.
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
15.1
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
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
International Software Testing Qualifications Board
02 Fev 2010
Certified Tester
Advanced Level Syllabus
Verso 2007br
International Software Testing Qualifications Board
02 Fev 2010