Escolar Documentos
Profissional Documentos
Cultura Documentos
Certified Tester
Foundation Level Syllabus
Verso 2011br
Traduo realizada pela TAG01 - Documentao do BSTQB baseada na verso 2011 do Certified Tester Foundation Level Syllabus do ISTQB.
Certified Tester
Foundation Level Syllabus
Copyright 2011, aos autores da atualizao 2011 (Thomas Muller (chair), Debra Friedenberg e o ISTQB WG Foundation Level) Copyright 2010, aos autores da atualizao 2010 (Thomas Muller (chair), Armin Beer, Martin Klonk e Rahul Verma) Copyright 2007, aos autores da atualizao 2007 (Thomas Muller (chair), Dorothy Graham, Debra Friedenberg e Erik van Veendendal) Copyright 2005, aos autores (Thomas Muller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson e Erik van Veendendal). Todos os direitos reservados. Os autores que esto transferindo o copyright para a Comisso Internacional para Qualificao de Teste de Software (aqui chamado de ISTQB). Os autores (como os atuais proprietrios copyright) e ISTQB (como os futuros proprietrios copyright) concordam com as seguintes condies de uso: 1) Qualquer treinamento individual ou por meio de companhia pode usar este syllabus como a base para treinamento se os autores e o ISTQB forem reconhecidos como a fonte original e proprietrios dos direitos sob o syllabus e, com a condio de que qualquer publicao tais como cursos e treinamentos, pode fazer meno ao syllabus somente aps obter autorizao oficial para utilizao do material de treinamento por uma comisso nacional reconhecida pela ISTQB. 2) Qualquer indivduo ou grupo de indivduos pode utilizar este syllabus como base para artigos, livros ou outros textos derivados se, os autores e o ISTQB forem reconhecidos como a fonte original e proprietrios dos direitos do syllabus; 3) Qualquer comisso nacional reconhecida pelo ISTQB poder traduzir este syllabus e licenci-lo (ou traduzir parcialmente) para outras partes.
Verso 2011br
Agosto 2011
Pgina 2 de 77
Certified Tester
Foundation Level Syllabus Histrico de Revises
Verso
BSTQB 2011br BSTQB 2007br ISTQB 2007 ISTQB 2005 ASQF V2.2 ISEB V2.0
Data
Agosto-2011 Agosto-2007 Maio-2007 Julho-2005 Julho-2003 Fevereiro-1999
Observao
Ver Apendice E Notas da Verso Traduo para portugus do Brasil Certified Tester Foundation Level Syllabus Maintenance Release see Apendix E Certified Tester Foundation Level Syllabus ASQF Syllabus Foundation Level Version 2.2 Lehrplan, Grundlagen des Softwaretestens ISEB Software Testing Foundation Syllabus V2.0 25 February 1999
Verso 2011br
Agosto 2011
Pgina 3 de 77
Certified Tester
Foundation Level Syllabus ndice
Agradecimentos .......................................................................................................................... 7 Introduo do Syllabus ............................................................................................................... 8
Objetivo deste documento ................................................................................................................... 8 CTFL (Certified Tester Foundation Level) ......................................................................................... 8 Objetivos de aprendizagem / nveis de conhecimento ........................................................................ 8 O Exame 8 Autorizao ......................................................................................................................................... 8 Nvel de Detalhe.................................................................................................................................. 9 Como este syllabus est organizado .................................................................................................... 9
1.
2.
2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4
3.
3.1 3.2 3.2.1 3.2.2 3.2.3
Certified Tester
Foundation Level Syllabus
3.2.4 Fatores de sucesso para as revises (K2) .......................................................................... 33 3.3 Anlise Esttica por Ferramentas (K2) ............................................................................. 34
4.
4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 4.4.1 4.4.2 4.4.3 4.5 4.6
5.
5.1 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.3 5.3.1 5.3.2 5.3.3 5.4 5.5 5.5.1 5.5.2 5.6
6.
6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.8 6.2 6.2.1 6.2.2 6.3
7.
Referncias ............................................................................................................. 65
Verso 2011br Agosto 2011 Pgina 5 de 77
Certified Tester
Foundation Level Syllabus
Apndice A Syllabus Background ......................................................................................... 66 Apndice B Objetivos de estudo/Nveis de Conhecimento ................................................... 68 Apndice C Regras aplicadas ao ISTQB Fundation Syllabus ............................................... 70 Apndice D Observao aos provedores de treinamentos. .................................................... 72 Appendix E Release Notes..................................................................................................... 73 Apncide F ndice Remissivo ................................................................................................ 75
Verso 2011br
Agosto 2011
Pgina 6 de 77
Certified Tester
Foundation Level Syllabus Agradecimentos
International Software Testing Qualifications Board Working Party Foundation Level: Thomas Muller (Diretor), Dorothy Graham, Debra Friedenberg e Erik van Veendendal. A comisso principal agradece a equipe de reviso (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Andrers Petterson e Wonil Knon) e todas as comisses nacionais para as sugestes deste syllabus. International Software Testing Qualifications Board Working Party Foundation Level: Thomas Muller (Diretor), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson e Erik van Veendendal. A comisso principal agradece a equipe de reviso e todas as comisses nacionais para as sugestes deste syllabus. Agradecimentos especiais para (ustria) Anastasios Kyriakopoulos, (Dinamarca) Klaus Olsen, Christine Rosenbeck-Larsen, (Alemanha) Matthias Daigl, Uwe Hehn, Tilo Linz, Horst Pohlmann, Ina Schieferdecker, Sabine Uhde, Stephanie Ulrich, (ndia) Vipul Kocher, (Israel) Shmuel Knishinsky, Ester Zabar, (Sucia) Anders Claesson, Mattias Nordin, Ingvar Nordstrm, Stefan Ohlsson, Kennet Osbjer, Ingela Skytte, Klaus Zeuge, (Sua) Armin Born, Sandra Harries, Silvio Moser, Reto Muller, Joerg Pietzsch, (Reino Unido) Aran Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen Moore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith, Richard Taylor, Neil Thompson, Pete Williams, (Estados Unidos) Dale Perry.
Verso 2011br
Agosto 2011
Pgina 7 de 77
Certified Tester
Foundation Level Syllabus Introduo do Syllabus Objetivo deste documento
Este syllabus forma a base de conhecimento para a Qualificao Internacional de Teste de Software no nvel Foundation. O International Software Testing Qualifications Board (ISTQB) disponibiliza o syllabus s comisses nacionais para que elas autorizem os fornecedores de treinamento e tambm derivem as questes do exame em suas lnguas locais. Os fornecedores de treinamento produziro o material de curso e determinaro os mtodos de ensino apropriados para certificao, e o syllabus ajudar os candidatos em sua preparao para o exame. Informaes histricas e conceituais do syllabus podem ser encontradas no apndice A.
Maiores detalhes e exemplos dos objetivos de estudo so dados no Apndice B. Todos os termos listados abaixo do tpico Termos devem ser relembrados (K1), mesmo que no forem explicitamente mencionados nos objetivos de estudo.
O Exame
O exame CTFL ser baseado neste syllabus. Respostas para as questes do exame podem requerer o uso do material baseado em mais de uma sesso do syllabus. Todas as sesses do syllabus podero ser contempladas no exame. O exame composto por questes de mltipla escolha. Exames podem ser efetuados como parte de um treinamento certificado ou no. Um treinamento realizado por uma entidade certificada pelo BSTQB no pr-requisito para a participao de um exame.
Autorizao
Provedores de treinamentos que utilizam o syllabus como referncia em seus cursos podem ser autorizados por uma comisso nacional (board) reconhecida pelo ISTQB. Os procedimentos de autorizao podem ser obtidos a partir de uma comisso (board) ou grupo que realiza a autorizao. Um curso autorizado reconhecido em conformidade com este syllabus, sendo permitida a realizao de um exame do ISTQB como parte do curso. Maiores detalhes para os fornecedores de treinamento so dados no Apndice D.
Verso 2011br Agosto 2011 Pgina 8 de 77
Certified Tester
Foundation Level Syllabus Nvel de Detalhe
O nvel de detalhe do syllabus permite que o treinamento e o exame sejam feitos internacionalmente e de forma consistente. Com foco em alcanar estes objetivos, o syllabus consiste de: Objetivos de instruo geral descrevendo as intenes do syllabus. Uma lista de informaes para o treinamento, incluindo uma descrio e referncias a fontes adicionais, se necessria. Objetivos de estudos para cada rea de conhecimento, descrevendo os resultados do conhecimento aprendido e das metas a serem atingidas. 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 coberto no treinamento para o nvel fundamental.
115 minutos
Mostra que o captulo 2 tem objetivos de estudos de K1 (assumido quando um nvel maior demonstrado) e K2 (mas no K3) e est dimensionado para levar 115 minutos para cobrir o estudo do captulo. Cada captulo composto de sees. Cada seo tambm tem os objetivos de aprendizagem e o tempo necessrio para estudo. Subsees que no tm um tempo determinado so includas no tempo da seo.
Verso 2011br
Agosto 2011
Pgina 9 de 77
Certified Tester
Foundation Level Syllabus
155 minutos
1.1
1.2
1.3 1.4
LO-1.3.1
LO-1.4.1
1.5
LO-1.5.1 LO-1.5.2
Verso 2011br
Agosto 2011
Pgina 10 de 77
Certified Tester
Foundation Level Syllabus 1.1 Porque necessrio testar? (K2)
Termos
Bug, defeito, erro, falha, dano, engano, qualidade, risco.
20 minutos
Verso 2011br
Agosto 2011
Pgina 11 de 77
Certified Tester
Foundation Level Syllabus
Projetos anteriores devem prover lies aprendidas. Atravs do entendimento da causa raiz dos defeitos encontrados em outros projetos, os processos podem ser aprimorados de modo a prevenir reincidncia de erros e, consequentemente, melhorar a qualidade dos sistemas futuros. Testes devem ser integrados como uma das atividades de garantia da qualidade (ex.: juntamente aos padres de desenvolvimento, treinamento e anlise de defeitos).
Verso 2011br
Agosto 2011
Pgina 12 de 77
Certified Tester
Foundation Level Syllabus 1.2 O que teste? (K2)
Termos
Depurao de cdigo, requisito, reviso, caso de teste, objetivo do teste.
30 minutos
Conceito
Uma viso comum do processo de teste de que ele consiste apenas da fase de execuo, como executar o programa. Esta, na verdade, uma parte do teste, mas no contempla todas as atividades do teste. Existem atividades de teste antes e depois da fase de execuo. Por exemplo: planejamento e controle, escolha das condies de teste, modelagem dos casos de teste, checagem dos resultados, avaliao do critrio de concluso, gerao de relatrios sobre o processo de teste e sobre sistema alvo e encerramento ou concluso (ex.: aps a finalizao de uma fase de teste). Teste tambm inclui reviso de documentos (incluindo o cdigo fonte) e anlise esttica. Testes dinmicos e estticos podem ser usados para atingir objetivos similares e proveem informaes para melhorar o sistema a ser testado e o prprio processo de teste. Testes podem possuir objetivos diferentes: Encontrar defeitos. Ganhar confiana sobre o nvel de qualidade Prover informaes para tomada de deciso. Prevenir defeitos.
O processo mental de projetar testes de forma antecipada no ciclo de vida (verificando a base de teste atravs da modelagem de teste) pode ajudar a prevenir defeitos que poderiam ser introduzidos no cdigo. A reviso de documentos (ex.: requisitos) tambm ajuda a prevenir defeitos que possam aparecem no cdigo. No processo de teste, diferentes pontos de vista levam a diferentes objetivos. Por exemplo, no teste feito em desenvolvimento (teste de componente, integrao e de sistemas), o principal objetivo pode ser causar o maior nmero de falhas possveis, de modo que os defeitos no software possam ser identificados e resolvidos. No teste de aceite o objetivo principal pode ser confirmar se o sistema est funcionando conforme o esperado, ou seja, prover a confiabilidade de que esteja de acordo com o requisito. Em alguns casos o principal objetivo do teste pode ser avaliar a qualidade do software (no com a inteno de encontrar defeitos), para prover informaes sobre os riscos da implantao do sistema em um determinado momento aos gestores. Os testes de manuteno podem ser usados para verificar se no foram inseridos erros durante o desenvolvimento de mudanas. Durante os testes operacionais, o principal objetivo pode ser avaliar caractersticas como confiabilidade e disponibilidade. Depurao de cdigo e teste so atividades diferentes. Testes podem demonstrar falhas que so causadas por defeitos. Depurao de cdigo a atividade de desenvolvimento que identifica a causa de um defeito, repara o cdigo e checa se os defeitos foram corrigidos corretamente. Depois feito um teste de confirmao por um testador para certificar se a falha foi eliminada. As responsabilidades de cada atividade so bem distintas: testadores testam e desenvolvedores depuram. O processo de teste e suas atividades so explicados na seo 1.4.
Verso 2011br
Agosto 2011
Pgina 13 de 77
Certified Tester
Foundation Level Syllabus 1.3 Os sete Princpios do Teste (K2)
Termos
Teste exaustivo
35 minutos
Princpios
Alguns princpios foram sugeridos ao longo dos ltimos 40 anos, oferecendo um guia geral para o processo de teste como um todo.
Verso 2011br
Agosto 2011
Pgina 14 de 77
Certified Tester
Foundation Level Syllabus 1.4 Fundamentos do Processo de Teste (K1)
Termos
Teste de confirmao, reteste, critrio de sada, incidente, teste de regresso, base de teste, condio de teste, cobertura de teste, dados de teste, execuo de teste, registro de teste, plano de teste, estratgia de teste, poltica de teste, sute de teste, relatrio consolidado de teste, testware.
35 minutos
Conceito
A parte mais visvel do teste a execuo. Mas para se obter eficcia e eficincia, os planos de teste precisam conter o tempo a ser gasto no planejamento dos testes, modelagem dos casos de testes e preparao da execuo e avaliao de resultados. O processo de teste bsico consiste das seguintes atividades: Planejamento e controle Anlise e modelagem Implementao e execuo Avaliao dos critrios de sada e relatrios Atividades de encerramento de teste
Apesar de serem apresentadas sequencialmente, as atividades durante o processo podem sobrepor-se ou acontecer de forma concorrente. Adaptando essas atividades principais dentro do contexto do sistema e do projeto quando necessrio.
Grau em que o software cumpre ou deve cumprir um conjunto e / ou caractersticas de sistema baseadas em software (por exemplo: a complexidade do software, avaliao de risco, o nvel de segurana, desempenho, confiabilidade ou custo) que so definidos para refletir a importncia do software para seus stakeholders. Verso 2011br Agosto 2011 Pgina 15 de 77
Certified Tester
Foundation Level Syllabus
Identificar e priorizar as condies ou requisitos de testes e dados de testes baseados na anlise dos itens de teste, na especificao, no comportamento e na estrutura. Projetar e priorizar os casos de testes de alto nvel. Identificar as necessidades de dados para teste suportando as condies e casos de teste Planejar a preparao do ambiente de teste e identificar a infraestrutura e ferramentas necessrias. Criar uma rastreabilidade bidirecional entre os requisitos e os casos de teste.
Certified Tester
Foundation Level Syllabus
As atividades de encerramento de teste so compostas pelas seguintes atividades principais: Checar quais entregveis planejados foram realmente entregues Fechar os relatrios de incidentes, ou levantar os registros de mudana que permaneceram abertos. Documentar o aceite do sistema. Finalizar e arquivar o testware, o ambiente de teste e infraestrutura de teste para o reuso. Entregar o testware para a manuteno da organizao. Analisar as lies aprendidas para se determinar as mudanas necessrias para futuros releases e projetos. Utilizar as informaes coletadas para melhorar a maturidade de teste
Verso 2011br
Agosto 2011
Pgina 17 de 77
Certified Tester
Foundation Level Syllabus 1.5 A Psicologia do Teste (K2)
Termos
Suposio de erro, Teste independente
25 minutos
Conceito
A forma de pensar utilizada enquanto se est testando e revisando diferente da utilizada enquanto se est analisando e desenvolvendo. Com a sua forma de pensar, os desenvolvedores esto aptos a testarem seus prprios cdigos, mas a separao desta responsabilidade para um testador tipicamente feita para ajudar a focalizar o esforo e prover benefcios adicionais, como uma viso independente, profissional e treinada de recursos de teste. Teste independente pode ser considerado em qualquer nvel de teste. Certo grau de independncia (evitando a influncia do autor) muitas vezes representa uma forma eficiente de encontrar defeitos e falhas. Independncia no significa simplesmente uma substituio, tendo em vista que os desenvolvedores podem encontrar defeitos no cdigo de maneira eficiente. Nveis de independncia podem ser definidos como: Teste elaborado por quem escreveu o software que ser testado (baixo nvel de independncia). Teste elaborado por outra(s) pessoa(s) (por exemplo, da equipe de desenvolvimento). Teste elaborado por pessoa(s) de um grupo organizacional diferente (ex.: equipe independente de teste). Teste elaborado por pessoa(s) de diferentes organizaes ou empresas (terceirizada ou certificada por um rgo externo).
Pessoas e projetos so direcionados por objetivos. Pessoas tendem a alinhar seus planos com os objetivos da gerncia e outros envolvidos (stakeholders) para, por exemplo, encontrar defeitos ou confirmar que o software funciona. Desta forma, importante ter objetivos claros do teste. Identificar falhas durante o teste pode ser considerado uma crtica contra o produto e o autor (responsvel pelo produto). Teste , nestes casos, visto como uma atividade destrutiva, apesar de ser construtiva para o gerenciamento do risco do produto. Procurar por falhas em um sistema requer curiosidade, pessimismo profissional, um olhar crtico, ateno ao detalhe, comunicao eficiente com os profissionais do desenvolvimento e experincia para encontrar erros. Se os erros, defeitos ou falhas so comunicados de uma forma construtiva, podem-se evitar constrangimentos entre as equipes de teste, analistas e desenvolvedores, tanto na reviso quanto no teste. O testador e o lder da equipe de teste precisam ter boa relao com as pessoas para comunicar informaes slidas sobre os defeitos, progresso e riscos de uma forma construtiva. A informao do defeito pode ajudar o autor do software ou documento a ampliar seus conhecimentos. Defeitos encontrados e resolvidos durante o teste trar ganho de tempo e dinheiro, alm de reduzir os riscos. Problemas de comunicao podem ocorrer, especialmente se os testadores forem vistos somente como mensageiros de ms notcias ao informar os defeitos. De qualquer forma, existem formas de melhorar a comunicao e o relacionamento entre os testadores e os demais: Comear com o esprito de colaborao, ao invs de disputa (conflitos), onde todos tm o mesmo objetivo para alcanar a melhor qualidade do sistema. Comunicar os erros encontrados nos produtos de uma forma neutra, dar foco no fato sem criticar a pessoa que o criou, por exemplo, escrevendo objetivamente o relatrio de incidentes. Tentar compreender como a pessoa se sente ao receber a notcia e interpretar sua reao. Confirmar que a outra pessoa compreendeu o que voc relatou e vice-versa.
Verso 2011br
Agosto 2011
Pgina 18 de 77
Certified Tester
Foundation Level Syllabus 1.6 Cdigo de tica
10 minutos
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.
Referncias
1.1.5 Black, 2001, Kaner, 2002 1.2 Beizer, 1990, Black, 2001, Myers, 1979 1.3 Beizer, 1990, Hetzel, 1998, Myers, 1979 1.4 Hetzel, 1998 1.4.5 Black, 2001, Craig, 2002 1.5 Black, 2001, Hetzel, 1998
Verso 2011br
Agosto 2011
Pgina 19 de 77
Certified Tester
Foundation Level Syllabus
115 minutos
2.1
LO-2.1.1
LO-2.1.2 LO-2.1.3
2.2
LO-2.2.1
2.3
2.4
Verso 2011br
Agosto 2011
Pgina 20 de 77
Certified Tester
Foundation Level Syllabus 2.1 Modelos de Desenvolvimento de Software (K2)
Termos
Software comercial de prateleira (COTS - Commercial Off the Shelf), modelo de desenvolvimento incremental, validao, verificao, Modelo V.
35 minutos
Conceito
No existe teste isolado; a atividade de teste est intimamente relacionada com as atividades de desenvolvimento do software. Modelos de ciclo de vida de desenvolvimento diferentes necessitam de abordagens diferentes para testar.
Na prtica, um Modelo V, pode ter mais, menos ou diferentes nveis de desenvolvimento e teste, dependendo do projeto e do produto. Por exemplo, pode haver teste de integrao de componentes aps o teste de um componente, e teste de integrao de sistemas aps o teste de sistemas. Produtos de trabalho de software (como cenrio de negcios ou casos de uso, especificao de requisitos, documentos de modelagem e cdigo) produzidos durante o desenvolvimento muitas vezes so a base do teste em um ou mais nvel de teste. Alguns exemplos de referncias para produtos de trabalho genricos: CMMI (Capability Maturity Model Integration) ou os Software life cycle processes IEEE/IEC 12207. Verificao e validao (e modelagem antecipada de teste) podem ser executadas durante a elaborao destes produtos de trabalho.
Certified Tester
Foundation Level Syllabus
A anlise e modelagem do teste para um dado nvel de teste devem comear durante a atividade de desenvolvimento correspondente. Testadores devem se envolver na reviso de documentos o mais cedo possvel utilizando as primeiras verses disponveis ao longo ciclo de desenvolvimento.
Nveis de teste podem ser combinados ou reorganizados dependendo da natureza do projeto ou arquitetura do sistema. Por exemplo, para a integrao de um pacote (COTS), em um sistema, o cliente pode fazer o teste de integrao em nvel de sistema (ex.: integrao da infraestrutura ou outros sistemas, implantao do sistema) e teste de aceite (funcional e/ou no funcional, teste de usurio e/ou operacional).
Verso 2011br
Agosto 2011
Pgina 22 de 77
Certified Tester
Foundation Level Syllabus 2.2 Nveis de Teste (K2)
Termos
Alfa Teste, Beta Teste, teste de componente (tambm conhecido como teste de unidade, mdulo ou teste de programa), controlador (driver), teste no campo, requisitos funcionais, integrao, teste de integrao, requisitos no funcionais, testes de robustez, simulador (stub), teste de sistema, nvel de teste, desenvolvimento dirigido teste, ambientes de teste, teste de aceite do usurio.
60 minutos
Conceito
Para cada nvel de teste, os seguintes aspectos podem ser identificados: seus objetivos genricos, os produtos de trabalho utilizados como referncia para derivar os casos de testes (ex.: base do teste), o objeto do teste (o que est sendo testado), defeitos e falhas tpicas a se encontrar, testes (harness) e ferramentas de suporte e abordagens e responsabilidades especficas.
Verso 2011br
Agosto 2011
Pgina 23 de 77
Certified Tester
Foundation Level Syllabus
podem envolver uma srie de sistemas. Problemas relacionados a mltiplas plataformas podem ser significativos. Quanto maior o escopo da integrao, maior a dificuldade de isolar as falhas para componentes ou sistemas especficos, fato que pode representar um aumento no risco. Estratgias sistemticas de integrao podem ser baseadas na arquitetura do sistema (top-down e bottom-up), funes, sequncias de processamento de transaes, entre outros aspectos do sistema ou componente. Visando reduzir o risco de encontrar defeitos tardiamente, a integrao deve, preferencialmente, ser incremental e no big bang. Teste de caractersticas no funcionais especficas (por exemplo, performance) pode ser includo nos testes de integrao. A cada estgio da integrao, os testadores concentram somente na integrao propriamente. Por exemplo, o mdulo A est sendo integrado com o mdulo B o foco a comunicao entre os mdulos, no suas funcionalidades. Tanto testes funcionais quanto estruturais podem ser utilizados. Idealmente, os testadores devem compreender a arquitetura e influenciar no planejamento da integrao. Se o teste de integrao for planejado antes que os componentes ou sistemas estejam prontos, eles podem ser preparados visando um teste mais eficiente.
Verso 2011br
Agosto 2011
Pgina 24 de 77
Certified Tester
Foundation Level Syllabus
O teste de aceite pode ser realizado em mais de um nico nvel de teste, por exemplo: Um pacote (COTS) de software ter um teste de aceite quando instalado ou integrado. Teste de aceite de usabilidade de um componente pode ser feito durante o teste de componente. Teste de aceite de uma nova funcionalidade pode vir antes do teste de sistema.
Verso 2011br
Agosto 2011
Pgina 25 de 77
Certified Tester
Foundation Level Syllabus 2.3 Tipos de Teste: o alvo do teste
Termos
Teste caixa-preta, cobertura de cdigo, teste funcional, teste de interoperabilidade, teste de carga, teste de manutenibilidade, teste de performance, teste de portabilidade, teste de regresso, teste de confiabilidade, teste de segurana, teste baseado em especificao, teste de estresse, teste estrutural, teste de usabilidade, teste caixa-branca.
40 minutos
Conceito
Um grupo de atividades de teste pode ser direcionado para verificar o sistema (ou uma parte do sistema) com base em um motivo ou alvo especfico. Cada tipo de teste tem foco em um objetivo particular, que pode ser o teste de uma funcionalidade, a ser realizada pelo software; uma caracterstica da qualidade no funcional, tal como a confiabilidade ou usabilidade, a estrutura ou arquitetura do software ou sistema; ou mudanas relacionadas, ex.: confirmar que os defeitos foram solucionados (teste de confirmao) e procurar por mudanas inesperadas (teste de regresso). Modelos do software podem ser elaborados e/ou usados no teste estrutural ou funcional. Por exemplo, para o teste funcional, um diagrama de fluxo de processo, um diagrama de transio de estados ou uma especificao do programa, e para teste estrutural um diagrama de controle de fluxo ou modelo de estrutura do menu.
Verso 2011br
Agosto 2011
Pgina 26 de 77
Certified Tester
Foundation Level Syllabus
2.3.3 Teste de estrutura/arquitetura do software (teste estrutural) (K2)
Teste estrutural (caixa-branca) pode ser feito em todos os nveis de testes. Recomenda-se utilizar as tcnicas estruturais aps as tcnicas baseadas em especificao, j que ela auxilia a medio da eficincia do teste atravs da avaliao da cobertura de um tipo de estrutura. Cobertura a extenso que uma estrutura foi exercitada por um conjunto de testes, expresso como uma porcentagem de itens cobertos. Se a cobertura no atinge 100%, ento mais testes devem ser construdos a fim de testar aqueles itens que no foram contemplados para, desta forma, aumentar a cobertura. Tcnicas de cobertura so discutidas no Captulo 4. Em todos os nveis de teste, mas especialmente no teste de componente e teste de integrao de componentes, ferramentas podem ser usadas para medir a cobertura do cdigo dos elementos assim como as declaraes ou decises. Teste estrutural deve ser baseado na arquitetura do sistema, como uma hierarquia de chamadas. Teste de estrutura tambm pode ser aplicado no sistema, integrao de sistema ou nvel de teste de aceite (por exemplo, para modelos de negcios ou estrutura de menu).
Verso 2011br
Agosto 2011
Pgina 27 de 77
Certified Tester
Foundation Level Syllabus 2.4 Teste de Manuteno
Termos
Anlise de impacto, teste de manuteno
15 minutos
Conceito
Uma vez desenvolvido, um sistema pode ficar ativo por anos ou at mesmo dcadas. Durante este tempo o sistema e seu ambiente podem ser corrigidos, modificados ou completados. Teste de manuteno realizado no mesmo sistema operacional e iniciado por modificaes, migraes ou retirada de software ou sistema. Alguns exemplos de modificaes incluem melhorias planejadas (ex.: baseadas em releases), mudanas corretivas e emergenciais, alm de mudanas de ambiente, como atualizao em sistema operacional ou banco de dados, e correes (patches) para expor e encontrar vulnerabilidades do sistema operacional. Teste de manuteno por migrao (ex.: de uma plataforma a outra) pode incluir testes operacionais do novo ambiente tanto quanto a mudana de software. Teste de manuteno para retirada de um sistema pode incluir o teste de migrao de dados, ou arquivamento se longos perodos de reteno de dados forem necessrios. Alm de testar o que foi alterado, o teste de manuteno inclui teste de regresso massivo para as partes do sistema que no foram testadas. O escopo do teste de manuteno est relacionado ao risco da mudana, o tamanho do sistema existente e o tamanho da mudana. Dependendo da mudana, o teste de manuteno pode ser feito em todos ou alguns nveis, e em todos ou alguns tipos de testes. A determinao de como um sistema pode ser afetado por mudanas chamado de anlise de impacto, e pode ser usado para ajudar a decidir quantos testes de regresso sero realizados. Teste de manuteno pode se tornar uma tarefa complicada se as especificaes estiverem desatualizadas ou incompletas.
Referncias
2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207 2.2 Hetzel, 1998 2.2.4 Copeland, 2004, Myers, 1979 2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004 2.3.2 Black, 2001, ISO 9126 2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998 2.3.4 Hetzel, 1998, IEEE 829 2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Verso 2011br
Agosto 2011
Pgina 28 de 77
Certified Tester
Foundation Level Syllabus
60 minutos
3.1
3.2
3.3
Verso 2011br
Agosto 2011
Pgina 29 de 77
Certified Tester
Foundation Level Syllabus 3.1 Reviso e o Processo de Teste (K2)
Termos
Teste dinmico, Teste esttico.
15 minutos
Contedo
Ao contrrio dos testes dinmicos, as tcnicas de teste esttico no pressupem a execuo do software que est sendo testado. Elas so manuais (reviso) ou automatizadas (anlise esttica). Reviso uma maneira de testar o produto de software (incluindo o cdigo) e pode ser realizada bem antes da execuo do teste dinmico. Defeitos detectados durante as revises o mais cedo possvel no ciclo de vida do software so muitas vezes mais barato do que aqueles detectados e removidos durante os testes (ex.: defeitos encontrados nos requisitos). Uma reviso pode ser feita inteiramente como uma atividade manual, mas h tambm ferramentas de suporte. A principal atividade manual examinar o produto de trabalho e fazer os comentrios sobre ele. Qualquer software pode ser revisado, incluindo a especificao de requisitos, diagramas, cdigo, plano de teste, especificao de teste, casos de teste, script de teste, manual do usurio ou pginas web. Os benefcios das revises incluem a deteco e correo antecipada de defeitos, ganho no desenvolvimento em termos de produtividade, reduo do tempo no desenvolvimento, reduo do custo e tempo de teste, menos defeitos e melhoria na comunicao. A reviso pode encontrar omisses, por exemplo, nos requisitos, que no so normalmente encontrados no teste dinmico. Revises, anlises estticas e testes dinmicos tm os mesmos objetivos identificar defeitos. Eles so complementares: as diferentes tcnicas podem encontrar diferentes tipos de defeitos eficazmente e eficientemente. Em contraste com o teste dinmico, revises encontram defeitos ao invs de falhas. Os defeitos mais facilmente encontrados durante revises do que em testes dinmicos so: desvios de padres, defeitos de requisitos, defeitos de modelagem, manutenibilidade insuficientemente e especificao incorreta de interfaces.
Verso 2011br
Agosto 2011
Pgina 30 de 77
Certified Tester
Foundation Level Syllabus 3.2 Processo de Reviso (K2)
Termos
Critrio de entrada, reviso formal, reviso informal, inspeo, mtricas, moderador, reviso em par, revisor, redator, reviso tcnica, acompanhamento (walkthrough).
25 minutos
Contedo
As revises variam de muito informais para muito formais (ex.: bem estruturadas e reguladas). A formalidade do processo de reviso relacionada a fatores como a maturidade do processo de desenvolvimento, requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria. O modo como uma reviso conduzida depende do seu objetivo (ex.: encontrar defeitos, obter compreenso, discusso ou decises por um consenso).
Verso 2011br
Agosto 2011
Pgina 31 de 77
Certified Tester
Foundation Level Syllabus
3.2.2 Papis e responsabilidades (K1)
Uma tpica reviso formal inclui as funes abaixo: Gerente: toma deciso durante a realizao da reviso, aloca tempo nos cronogramas de projeto e determina se o objetivo da reviso foi atingido. Moderador: a pessoa que lidera a reviso do documento ou conjunto de documentos, incluindo o planejamento da reviso, e o acompanhamento aps a reunio. Se necessrio, o moderador mediar entre os vrios pontos de vista e muitas vezes quem responder pelo sucesso da reviso. Autor: a pessoa que escreveu ou que possui a responsabilidade pelos documentos que sero revisados. Revisores: indivduos com conhecimento tcnico ou de negcio (tambm chamados inspetores), que, aps a preparao necessria, identificam e descrevem os defeitos encontrados no produto em reviso. Revisores podem ser escolhidos para representar diferentes funes e perspectivas no processo de reviso, e parte integrante de qualquer reunio de reviso. Redator: documenta todo o contedo da reunio, problemas e itens em aberto que foram identificados durante a reunio.
Olhando os documentos de diferentes perspectivas e usando check-lists, tornamos a reviso mais eficaz e eficiente. Por exemplo, um check-list baseado em perspectivas tais como a do usurio, desenvolvedor, testador, operador, ou um check-list tpico de problemas de requisitos pode ajudar a descobrir problemas no detectados anteriormente.
Acompanhamento: Reunio conduzida pelo autor. Cenrios, grupos de discusso, exerccios prticos. Sesses sem restrio de tempo. Opcionalmente h uma reunio preparatria dos revisores. Opcionalmente, relatrios de reviso e lista de defeitos encontrados so preparados. Opcionalmente h um redator. Na prtica pode variar de informal para muito formal. Principal propsito: aprendizagem, obteno de entendimento e encontrar defeitos.
Revises tcnicas: Documentado, processo de deteco de defeito definido que inclui colegas especialistas ou tcnicos com a participao opcional da gerncia. Pode ser feito por um colega sem a participao da gerncia.
Verso 2011br Agosto 2011 Pgina 32 de 77
Certified Tester
Foundation Level Syllabus
Idealmente so conduzidas por um moderador treinado (que no seja o autor). Reunio preparatria dos revisores. Opcionalmente usa check-lists. Elaborao de um relatrio de reviso, que inclui a lista de defeitos encontrados, se o produto de software corresponde s suas exigncias e, quando apropriado, recomendaes relacionadas com as descobertas. Na prtica, pode variar de informal para muito formal. Principais propsitos: discusso, tomada de decises, avaliar alternativas, encontrar defeitos, resolver problemas tcnicos e checar a conformidade da padronizao das especificaes.
Inspeo : Conduzida pelo moderador (que no seja o autor). Geralmente uma anlise por pares. Papis definidos. Utilizao de mtricas. Processo formal baseado em regras e utilizao de check-list. Entrada especificada e critrios de sada para a aceitao do produto de software. Reunio de preparao. Relatrio de inspeo, lista de defeitos encontrados; Processo de acompanhamento formal. Opcionalmente, ter aperfeioamento do processo e um leitor. Principal propsito: encontrar defeitos.
Acompanhamento, revises tcnicas e inspees podem ser executados dentro de um grupo de pessoas no mesmo nvel organizacional. Este tipo de reviso chamado de reviso por pares.
Verso 2011br
Agosto 2011
Pgina 33 de 77
Certified Tester
Foundation Level Syllabus 3.3 Anlise Esttica por Ferramentas (K2)
Termos
Compilador, complexidade, controle de fluxo, fluxo de dados, anlise esttica.
20 minutos
Conceito
O objetivo da anlise esttica encontrar defeitos no cdigo fonte do software e na modelagem. Anlise esttica feita sem a execuo do software examinado pela ferramenta; j o teste dinmico executa o software. Anlise esttica pode localizar defeitos que so dificilmente encontrados em testes. Como as revises, a anlise esttica encontra defeitos ao invs de falhas. Ferramentas de anlise esttica analisam o cdigo do programa (ex.: fluxo de controle e fluxo de dados), gerando, como sada, arquivos do tipo HTML e XML, por exemplo. Os benefcios da anlise esttica so: Deteco de defeitos antes da execuo do teste. Conhecimento antecipado sobre aspectos suspeitos no cdigo ou programa atravs de mtricas, por exemplo, na obteno de uma medida da alta complexidade. Identificao de defeitos dificilmente encontrados por testes dinmicos. Deteco de dependncias e inconsistncias em modelos de software, como links perdidos. Aprimoramento da manutenibilidade do cdigo e construo. Preveno de defeitos, se as lies forem aprendidas pelo desenvolvimento.
Defeitos mais comuns descobertos por ferramentas de anlise esttica incluem: Referncia a uma varivel com valor indefinido. Inconsistncias entre as interfaces dos mdulos e componentes. Variveis que nunca so usadas ou impropriamente declaradas. Cdigo morto. Falta de lgica ou lgica errada (loops infinitos). Construes excessivamente complicadas. Violao de padres de programao. Vulnerabilidade na segurana. Violao de sintaxe e de modelos.
Ferramentas de anlises estticas so tipicamente usadas por desenvolvedores (checando regras pr-definidas ou padres de programao) antes e durante o teste de componente e de integrao e por projetistas durante a modelagem do software. Ferramenta de anlise esttica pode produzir um grande nmero de mensagens de advertncias que precisam ser gerenciadas para permitir o uso mais efetivo da ferramenta. Compiladores podem oferecer algum suporte para a anlise esttica, incluindo o clculo de mtricas.
Referncias
3.2 IEEE 1028 3.2.2 Gilb, 1993, van Veenendaal, 2004 3.2.4 Gilb, 1993, IEEE 1028 3.3 Van Veenendaal, 2004
Verso 2011br
Agosto 2011
Pgina 34 de 77
Certified Tester
Foundation Level Syllabus
255 minutos
4.1
4.2
LO-4.2.1
LO-4.2.2
4.3
4.4
LO-4.4.1 LO-4.4.2
LO-4.4.3 LO-4.4.4
4.5
LO-4.5.1 LO-4.5.2
4.6
LO-4.6.1
Verso 2011br
Agosto 2011
Pgina 35 de 77
Certified Tester
Foundation Level Syllabus 4.1 Identificando as condies de testes e projetando os casos de testes (K3)
Termos
Especificao de caso de teste, modelagem de teste, cronograma de execuo do teste, especificao de procedimento de teste, script de teste e rastreabilidade.
15 minutos
Conceito
O processo pode ser realizado de diferentes maneiras, desde informalmente sem muitos dados ou documentao, at um processo muito formal (como o que ser descrito ainda nesta seo). O nvel de formalidade depende do contexto do teste, o que inclui a organizao, maturidade do processo de teste e desenvolvimento, restries de tempo e as pessoas envolvidas. Durante a anlise de teste, a documentao base de teste analisada de maneira a determinar o que testar (ex.: identificar as condies de teste). A condio do teste definida como um item ou evento que pode ser verificado por um ou mais casos de testes (ex.: uma funo, transao, caracterstica de qualidade ou elemento estrutural). Estabelecer a rastreabilidade das condies de testes de volta at as especificaes e requisitos permitem analisar o impacto quando os requisitos mudam e, a cobertura de requisitos a ser determinada por um conjunto de testes. Durante a modelagem do teste, o detalhamento da abordagem de teste ser implementado com base entre outras consideraes nos riscos identificados. (Ver mais informaes de anlise de riscos no Captulo 5) Durante a modelagem de teste, os casos de teste e os dados de teste so especificados e criados. Um caso de teste consiste de um conjunto de valores de entrada, pr-condies de execuo, resultados esperados e pscondies de execuo, desenvolvidos para cobrir certas condies de teste. O Standard for Software Test Documentation (IEEE 829-1998) descreve o contedo da especificao da modelagem de teste (contendo as condies de teste) e a especificao de caso de teste. Resultados esperados devem ser produzidos como parte da especificao de um caso de teste e inclui as sadas, mudana de dados e status, e qualquer outra consequncia do teste. Se o resultado esperado no for definido, um resultado plausvel, porm errado, pode ser interpretado como correto. O resultado esperado deve ser definido antes da execuo do teste. Durante a implementao do teste os casos de teste so desenvolvidos, implementados, priorizadas e organizadas na especificao de procedimento de teste (IEEE STD 829-1998). O procedimento de teste especifica a sequncia de aes para a uma execuo de teste. Se os testes so executados por uma ferramenta, a sequncia de aes especificada por um script automatizado (que um procedimento de teste automatizado). Os vrios e scripts de testes automatizados formam uma sequncia de execuo de teste que define a ordem em que os procedimentos, e/ou os scripts automatizados sero executados e quem os executar. A sequncia de execuo de teste considera alguns fatores como testes de regresso, priorizao, dependncias tcnicas e lgicas.
Verso 2011br
Agosto 2011
Pgina 36 de 77
Certified Tester
Foundation Level Syllabus 4.2 Categorias das tcnicas de modelagem de teste (K2)
Termos
Tcnicas caixa-preta, tcnicas baseadas em experincia, tcnicas de modelagem de teste, tcnicas caixabranca.
15 minutos
Conceito
O propsito da tcnica de modelagem de teste identificar as condies e os casos de testes. Classificar testes como caixa-preta ou caixa-branca uma diferenciao clssica. Tcnicas caixa- preta, (tambm chamadas de tcnicas baseadas em especificao) so uma forma de derivar e selecionar as condies e casos de testes baseados na anlise da documentao. Isto inclui testes funcionais e no funcionais, para um componente ou sistema sem levar em considerao a sua estrutura interna. Tcnicas de caixa branca (tambm chamadas de tcnicas estruturais ou baseadas em estrutura) so baseadas na estrutura interna de um componente ou sistema. Algumas tcnicas se encaixam claramente em uma nica categoria; outras tm elementos de mais de uma categoria. Este syllabus considera tcnicas baseadas em especificao ou tcnicas baseadas em experincia como tcnicas caixa-preta e tcnicas baseadas em estrutura como tcnicas caixa-branca. Caractersticas comuns das tcnicas baseadas em especificao: Modelos, formais ou informais, so utilizados para especificao de um problema a ser resolvido, o software ou seu componente. Os casos de testes podem ser derivados sistematicamente destes modelos.
Caractersticas comuns das tcnicas baseadas em estrutura: Informaes sobre como o software construdo utilizada para derivar os casos de testes. Por exemplo, cdigo e informaes detalhadas de modelagem. A extenso da cobertura do software pode ser medida pelos casos de testes. Alm disto, os casos de testes podem ser derivados sistematicamente para aumentar a cobertura.
Caractersticas comuns de tcnicas baseada em experincia: Conhecimento e experincia de pessoas so utilizados para derivar os casos de testes. Conhecimento de testadores, desenvolvedores, usurios, outros interessados (stakeholders) responsveis pelo software, seu uso e ambiente. Conhecimento sobre defeitos provveis e sua distribuio.
Verso 2011br
Agosto 2011
Pgina 37 de 77
Certified Tester
Foundation Level Syllabus 4.3 Tcnicas baseadas em especificao ou Caixa-Preta (K3) 120 minutos
Termos
Anlise de valores limites, teste de tabela de deciso, partio de equivalncia, teste de transio de estados, teste de caso de uso.
Certified Tester
Foundation Level Syllabus
4.3.4 Teste de transio de estados (K3)
Um sistema pode exibir respostas diferentes dependendo da sua condio atual ou de estado anterior. Neste caso, o comportamento do sistema pode ser representado como um diagrama de transio de estados. Permite ao testador visualizar o software em termos de estados, transies entre estados, as entradas ou eventos que disparam as mudanas de estado (transio) e as aes que podem resultar daquelas transies. Os estados do sistema, ou objetos em teste, so isolados, identificveis e finitos. Uma tabela de estado exibe a relao entre estados e entradas, e pode destacar possveis transies invlidas. Os testes podem ser construdos para cobrir uma sequncia tpica de status, cobrir todos os estados, exercitar todas as transies, exercitar uma sequncia especfica de transies ou testar transies invlidas. Teste de transio de status muito utilizada em softwares industriais embarcados e automaes tcnicas em geral. No entanto, a tcnica tambm adequada para modelar um objeto de negcio tendo estado especfico ou para testar fluxos de telas de dilogos (exemplo: aplicao de internet e cenrios de negcios).
Verso 2011br
Agosto 2011
Pgina 39 de 77
Certified Tester
Foundation Level Syllabus 4.4 Tcnicas baseadas em estrutura ou Caixa-Branca (K3)
Termos
Cobertura de cdigo, cobertura de deciso, cobertura de sentena, teste baseado em estrutura.
60 minutos
Conceito
Teste de estrutura ou caixa-branca baseado na estrutura do software ou sistema, como veremos nos exemplos que seguem abaixo: Nvel de Componente: a estrutura o prprio cdigo, ex.: comandos, decises e desvios. Nvel de Integrao: a estrutura pode ser uma rvore de chamadas (um diagrama em que um mdulo chama outros mdulos). Nvel de Sistema: A estrutura pode ser uma estrutura de menu, processos de negcios ou estruturas das pginas Web.
Nesta seo h basicamente duas tcnicas de cobertura de cdigo baseados em comandos e decises sero discutidas. Para teste de deciso, um diagrama de controle de fluxo pode ser utilizado para visualizar as alternativas de cada deciso.
Verso 2011br
Agosto 2011
Pgina 40 de 77
Certified Tester
Foundation Level Syllabus 4.5 Tcnicas baseadas na experincia (K2)
Termos
Teste exploratrio, ataque (de falha).
30 minutos
Conceito
Os testes baseados na experincia so testes derivados da intuio e conhecimento dos testadores atravs de sua experincia em aplicaes e tecnologia similares. Quando usado para aumentar a tcnica sistemtica, testes intuitivos podem ser teis para identificar testes especficos que no so facilmente identificados pelas tcnicas formais, especialmente quando aplicado aps ter estabelecido o processo mais formal. No entanto esta tcnica pode produzir amplas variedades e graus de eficincia, dependendo da experincia do testador. Possivelmente a tcnica mais amplamente aplicada a de supor (adivinhar) onde esto os erros. Uma abordagem estruturada da tcnica de deduo de erros enumerar uma lista de possveis erros e construir testes com objetivo de atacar/cobrir estes erros. Esta abordagem sistemtica chamada de ataque de falha. Estas listas de defeitos e falhas podem ser construdas com base na experincia, dados de defeitos/falhas disponveis e do conhecimento comum de como o software falha. Teste exploratrio ocorre simultaneamente modelagem, execuo e registro de teste, e baseia-se nos objetivos de teste, onde realizado em um tempo predefinido. uma abordagem muito usual, em locais onde a especificao rara ou inadequada e existe grande presso por conta de prazo, ou para aprimorar/complementar um teste mais formal. Pode servir como uma checagem do processo de teste, assegurando que os defeitos mais importantes sejam encontrados.
Verso 2011br
Agosto 2011
Pgina 41 de 77
Certified Tester
Foundation Level Syllabus 4.6 Escolhendo as tcnicas de teste (K2)
Termos
No h.
15 minutos
Conceito
A escolha de qual tcnica utilizar depender de uma srie de fatores, incluindo o tipo de sistema, padres, clientes, requisitos contratuais, nvel do risco, tipos de riscos, objetivos do teste, documentao disponvel, conhecimento dos testadores, tempo, dinheiro, ciclo de desenvolvimento, modelo de caso de uso e uma experincia prvia do tipo de defeitos encontrados. Algumas tcnicas so mais facilmente aplicadas em certas situaes e nveis de teste, j outras so aplicveis a todos os nveis. Ao criar casos de teste, os testadores geralmente usam uma combinao de tcnicas de teste, incluindo regras de processo e tcnicas de data-driven para garantir uma cobertura adequada do objeto em teste.
Referncias
4.1 Craig, 2002, Hetzel, 1998, IEEE 829 4.2 Beizer, 1990, Copeland, 2004 4.3.1 Copeland, 2004, Myers, 1979 4.3.2 Copeland, 2004, Myers, 1979 4.3.3 Beizer, 1990, Copeland, 2004 4.3.4 Beizer, 1990, Copeland, 2004 4.3.5 Copeland, 2004 4.4.3 Beizer, 1990, Copeland, 2004 4.5 Kaner, 2002 4.6 Beizer, 1990, Copeland, 2004
Verso 2011br
Agosto 2011
Pgina 42 de 77
Certified Tester
Foundation Level Syllabus
180 minutos
5.1
5.2
LO-5.2.1 LO-5.2.2
5.3
5.4 5.5
LO-5.4.1
Certified Tester
Foundation Level Syllabus
LO-5.5.4 LO-5.5.5 Reconhecer um risco de produto e de projeto tpico. (K1) Descrever, utilizando exemplos, como a anlise e gerenciamento de risco podem ser utilizados para planejar os testes. (K2) Reconhecer o contedo do relatrio de incidente do Standard for Software Test Documentation (IEEE 829). (K1) Preparar um relatrio de incidente cobrindo a observao de uma falha durante os testes. (K3)
5.6
LO-5.6.1 LO-5.6.2
Verso 2011br
Agosto 2011
Pgina 44 de 77
Certified Tester
Foundation Level Syllabus 5.1 Organizao do Teste (K2)
Termos
Testador, lder de teste, gerente de teste
30 minutos
Para projetos longos, complexos e crticos, normalmente melhor ter vrios nveis de teste, com algum ou todos os nveis efetuados por equipes independentes de teste. A equipe de desenvolvimento pode participar do teste, especialmente para os testes de baixo nvel, mas sua falta de objetividade muitas vezes limita a efetividade do teste. A equipe independente de teste deve ter a autoridade para requisitar e definir os processos de teste e suas regras, mas os testadores teriam que exercer estas funes somente sob um claro gerenciamento. Os benefcios da independncia da equipe de testes so: Testadores independentes conseguem enxergar outros defeitos e so imparciais. Um testador independente capaz de verificar concepes pessoais criadas durante a especificao e implementao de um sistema.
As desvantagens incluem: Isolamento da equipe de desenvolvimento (se for tratado com independncia total). Equipe pode se tornar um gargalo, considerando-se o ltimo ponto de controle. Os desenvolvedores podem perder o senso da responsabilidade pela qualidade.
A atividade do teste deve ser realizada por pessoas com uma funo especfica de teste, ou pode ser feita por algum em outra funo, assim como gerente de projeto, gerente de qualidade, desenvolvedores, especialistas no negcio, suporte de infraestrutura ou operaes em TI.
Certified Tester
Foundation Level Syllabus
Normalmente, o lder responsvel pelo planejamento, monitorao e controle d as atividades de testes e tarefas como as definidas na seo 1.4. As tarefas tpicas de um lder so: Coordenar a estratgia de teste e planejar com o gerente de projetos e outros envolvidos. Escrever ou revisar uma estratgia de teste para o projeto e uma poltica de teste para a empresa. Contribuir com perspectiva do teste para outras atividades, como o planejamento de integrao. Planejar os testes considerando o contexto e compreendendo os riscos, incluindo a escolha da abordagem do teste, estimativa de tempo, esforo, custo, aquisio de recursos, definio de nveis e ciclos de testes, definio de objetivos e planejamento da gesto de incidente. Iniciar a especificao, preparao, implementao e execuo dos testes e monitorar o controle da execuo. Adaptar o planejamento baseado nos resultados e progresso do teste (algumas vezes documentado em relatrio de andamento) e tomar aes necessrias para resolver problemas. Preparar o gerenciamento de configurao do testware para facilitar a rastreabilidade. Introduzir mtricas para medir o progresso do teste e avaliar a qualidade do teste e do produto. Decidir o que pode ser automatizado, em que grau e como. Escolher ferramenta de apoio e organizar treinamento para seus usurios (testadores). Decidir sobre a implementao do ambiente de teste. Montar um relatrio com base nas informaes obtidas durante o teste.
As tarefas tpicas de um testador podem incluir: Revisar e contribuir no planejamento dos testes. Analisar, revisar e avaliar os requisitos de usurios, especificaes e modelos para testabilidade. Criar especificao de teste. Configurar o ambiente de teste (muitas vezes com a coordenao do administrador de sistemas e redes). Preparar e adquirir dados para os testes. Implementar os testes em todos os nveis, execuo, registro, avaliao dos resultados e documentar os desvios dos resultados esperados. Utilizar ferramenta de administrao, gesto e monitorao de teste se necessrio. Automatizar testes (esta tarefa pode ser efetuada pelo desenvolvedor ou por um especialista em automao). Medir a performance dos componentes e sistemas (se aplicvel). Rever os testes desenvolvidos por outras pessoas.
As pessoas que trabalham na anlise, construo, tipos especficos de teste ou automao podem se especializar nestas funes. Dependendo do nvel do teste e do risco relacionado ao produto e o projeto, pessoas diferentes podem ocupar a funo do testador, mantendo algum grau de independncia. Tipicamente, testadores em nvel de componente e integrao so desenvolvedores, testadores em nvel de aceite podem ser os especialistas no negcio ou usurio final e testadores para o nvel de teste operacional podem ser os prprios operadores.
Verso 2011br
Agosto 2011
Pgina 46 de 77
Certified Tester
Foundation Level Syllabus 5.2 Organizao do Teste (K2)
Termos
Abordagem de teste, estratgia de teste
50 minutos
Certified Tester
Foundation Level Syllabus
Disponibilidade de cdigo a ser testado. Disponibilidade dos dados de teste.
Uma vez que a estimativa do esforo do teste efetuada, recursos podem ser alocados e um cronograma pode ser elaborado. O esforo do teste pode depender de inmeros fatores que incluem: Caractersticas do produto: a qualidade da especificao ou outra informao usada por projetos de teste, o tamanho do produto, a complexidade do problema, os requisitos para segurana e os requisitos para documentao. Caractersticas do processo de desenvolvimento: A estabilidade da organizao, ferramentas usadas, processos de teste, experincia das pessoas envolvidas e presso no prazo. As sadas do teste: o nmero de defeitos e a quantidade de retrabalho necessria.
Certified Tester
Foundation Level Syllabus
Compatvel com processos ou padres: como algumas especificadas por padres da indstria ou as vrias metodologias geis. Dinmica e heurstica: tais como os testes exploratrios onde a atividade de testar mais reativa do que pr-planejada e onde a execuo e avaliao so tarefas concorrentes. Baseada em conselhos: como os testes em que a cobertura dirigida por conselhos de especialistas em tecnologia ou negcio fora do time de teste. Regresso: como aqueles em que h o reuso do material de teste, automao extensiva dos testes funcionais de regresso, e um conjunto de testes padro.
Diferentes abordagens para montar uma estratgia podem ser utilizadas como, por exemplo, abordagem baseada em risco.
Verso 2011br
Agosto 2011
Pgina 49 de 77
Certified Tester
Foundation Level Syllabus 5.3 Controle e Monitorao do Progresso do Teste (K2)
Termos
Densidade do defeito, taxa de falha, controle do teste, monitorao do teste e relatrio de resumo do teste.
20 minutos
A essncia de um relatrio de teste tratada no Standard for Software Test Documentation (IEEE 829). As mtricas podem ser coletadas durante ou ao final do teste: A adequao dos objetivos do teste com o nvel do teste. A adequao da abordagem/estratgia do teste. A eficcia dos testes em respeito a seus objetivos.
Verso 2011br
Agosto 2011
Pgina 50 de 77
Certified Tester
Foundation Level Syllabus
Exemplos de controle de teste: Tomar decises baseadas em informaes adquiridas na monitorao dos testes. Priorizar novamente os testes quando riscos so identificados. Mudar o cronograma de acordo com disponibilidade do ambiente de teste. Definir um critrio de entrada para se iniciar o reteste de bugs resolvidos pelo desenvolvedor antes de aceit-lo em uma build.
Verso 2011br
Agosto 2011
Pgina 51 de 77
Certified Tester
Foundation Level Syllabus 5.4 Gerenciamento de Configurao (K2)
Termos
Gerenciamento de configurao, controle de verso.
10 minutos
Conceito
O propsito do gerenciamento de configurao estabelecer e manter a integridade dos produtos (componentes, dados e documentao) do software ou sistema durante todo o projeto ou ciclo de vida do produto. Para o teste, o gerenciamento de configurao pode garantir que: Todos os itens do software so identificados, controladas as mudanas, seus relacionamentos, facilitando manuteno e a rastreabilidade durante todo o processo de teste. Todos os documentos e itens do software so referenciados sem ambiguidade na documentao do teste.
Para o testador, o gerenciamento de configurao ajuda na identificao nica (e a reproduo) do item testado, documentos de testes, aos testes e aos scripts de execuo de testes. Durante o planejamento do teste a ferramenta e processos de gerenciamento de configurao devem ser escolhidos, documentados e implementados.
Verso 2011br
Agosto 2011
Pgina 52 de 77
Certified Tester
Foundation Level Syllabus 5.5 Riscos e Teste (K2)
Termos
Risco do produto, risco do projeto, risco, teste baseado em risco.
30 minutos
Conceito
Risco pode ser definido como uma chance de um evento indesejvel acontecer, causando um problema em potencial. O nvel do risco pode ser determinado pela possibilidade do evento acontecer e os danos que podem causar caso acontea.
Quando analisando, gerenciando e mitigando os riscos, o gerente de teste conduzido por um princpio de gerenciamento de projeto bem estabelecido. A definio de planos de teste contida no Standard for Software Test Documentation (IEEE 829-1998) requisita que os riscos e a contingncias devam ser declaradas.
Certified Tester
Foundation Level Syllabus
Risco usado para se decidir quando comear e onde dever se testar com mais frequncia; o teste utilizado para reduzir o risco da ocorrncia de um efeito indesejado, ou para reduzir seu impacto. Risco do produto um tipo especial de risco porque compromete o sucesso de um projeto. A atividade de controle de riscos fornece informaes sobre riscos residuais, por medir a eficincia da retirada de defeitos crticos e dos planos de contingncia. Um teste baseado nos riscos pode fornecer oportunidades proativas para reduzir os nveis do risco do produto quando abordado no estgio inicial do projeto. Envolve a identificao do risco e seu uso para orientar o planejamento, especificao, preparao e execuo do teste. Os riscos identificados podem ser utilizados para: Determinar a tcnica de teste a ser empregada. Determinar o nvel de detalhamento do teste. Priorizar o teste na tentativa de buscar erros crticos o mais cedo possvel. Determinar se alguma atividade (que no seja o teste) poderia ser efetuada para reduzir o risco (ex.: prover treinamento).
Teste baseado no risco auxilia os stakeholders a determinar os riscos e nveis de testes, com base no conhecimento coletivo e na viso do projeto. Para assegurar que a chance de um produto falhar seja minimizada, o gerenciamento de riscos dever prover disciplina para: Avaliar (e reavaliar periodicamente) o que poder dar errado (riscos). Determinar quais riscos so importantes para negoci-los. Implementar aes para negociar aqueles riscos.
Alm disto, o teste pode demonstrar a identificao de novos riscos, que riscos deveriam ser reduzidos e diminuir as incertezas sobre os riscos.
Verso 2011br
Agosto 2011
Pgina 54 de 77
Certified Tester
Foundation Level Syllabus 5.6 Gerenciamento de Incidente (K3)
Termos
Registro de Incidente, Gerncia de Incidente, Reporte de Incidente.
40 minutos
Conceito
Levando em considerao que um dos objetivos do teste encontrar defeitos, as discrepncias entre o resultado atual e o esperado precisam ser registradas como incidentes. Um incidente precisa ser investigado e pode se tornar um defeito. Aes apropriadas para dispor incidentes e defeitos devem ser disponveis. Incidente e defeito deve ser rastrevel desde a descoberta, classificao at correo e confirmao da resoluo. Para gerenciar os incidentes, a empresa deve estabelecer processos e regras para classific-los. Incidentes podem ser descobertos durante o desenvolvimento, o teste e a utilizao do software. Eles podem se revelar por problemas no cdigo, por funes do sistema, documentao de desenvolvimento, documentao de teste, manual de instalao ou manual do usurio. O Relatrio de Incidentes tem os seguintes objetivos: Prover aos desenvolvedores e outros envolvidos um retorno sobre o problema para permitir a identificao, isolamento e correo se necessrio. Prover aos lderes de teste um meio para se rastrear a qualidade do sistema em teste e o progresso do teste. Prover ideias para aprimorar o processo de testes. Data da emisso, autor, status e organizao. Resultados esperados e resultados atuais. Identificao do item de teste (item de configurao) e ambiente. Processo do ciclo de vida do sistema ou software em que o incidente foi descoberto. Descrio do incidente para permitir a reproduo e resoluo, incluindo logs, database dumbs, ou screenshots. Escopo e grau de impacto para os stakeholder. Severidade do impacto no sistema. Urgncia / Prioridade na correo. Estado (status) do incidente (aberto, rejeitado, duplicado, aguardando resoluo, aguardando reteste ou fechado). Concluso, recomendaes e aprovaes. Comentrios gerais, tais como outras reas que podem ser afetadas por uma mudana resultante de um incidente. Histrico de mudanas, como a sequncia de aes tomadas pela equipe envolvida no projeto com respeito ao isolamento do incidente, reparo e confirmao da resoluo. Referncias, incluindo a identificao da especificao do caso de teste que revelou o problema.
A estrutura de um relatrio de incidente pode ser encontrada no Standard for Software Test Documentation (IEEE Std. 829-1998).
Referncias:
5.1.1 Black, 2001, Hetzel, 1998 5.1.2 Black, 2001, Hetzel, 1998 5.2.5 Black, 2001, Craig, 2002, IEEE 829, Kaner 2002 5.3.3 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Verso 2011br Agosto 2011 Pgina 55 de 77
Certified Tester
Foundation Level Syllabus
5.4 Craig, 2002 5.5.2 Black, 2001 , IEEE 829 5.6 Black, 2001, IEEE 829
Verso 2011br
Agosto 2011
Pgina 56 de 77
Certified Tester
Foundation Level Syllabus
80 minutos
6.1
LO-6.1.1 LO-6.1.3
6.2
LO-6.2.1 LO-6.2.2
6.3
Verso 2011br
Agosto 2011
Pgina 57 de 77
Certified Tester
Foundation Level Syllabus 6.1 Tipos de Ferramentas de Teste (K2)
Termos
Ferramentas de gerenciamento de configurao, ferramenta de cobertura de cdigo, ferramenta de depurao, ferramenta de anlise dinmica, ferramenta de gesto de incidentes, ferramenta de teste de carga, ferramenta de modelagem, ferramenta de monitorao, ferramenta de teste de performance, efeito da monitorao, ferramentas de gerenciamento de requisitos, ferramenta de reviso, ferramentas de segurana, ferramentas de anlise esttica, ferramenta de teste de estresse, ferramenta de comparao de teste, ferramenta de preparao de dados, ferramenta de modelagem de teste, ambiente preparado de testes, ferramentas para execuo do teste, ferramentas para gerenciamento do teste, framework de teste de unidade.
45 minutos
O termo frameworks de teste tambm frequentemente utilizado na indstria, em pelo menos trs sentidos:
Para o objetivo deste syllabus, o termo frameworks de teste utilizado em seus dois primeiros significados, como descrito na Seo 6.1.6.
Certified Tester
Foundation Level Syllabus
Algumas ferramentas suportam claramente apenas uma atividade; outras podem suportar mais que uma, mas esto classificadas sob a atividade de que ela est mais associada. Ferramentas de um nico fornecedor, especialmente aquelas que foram planejadas para atuarem em conjunto, podem ser agrupadas em um nico pacote. Alguns tipos de ferramentas de teste so intrusivos, ou seja, eles prprios podem afetar o resultado do teste. Por exemplo, o resultado de uma aferio de tempo pode ser diferente dependendo de como a medio em diferentes ferramentas de performance, ou ento pode-se ter uma medida diferente na cobertura do cdigo dependendo da ferramenta que se utiliza. A consequncia de uma ferramenta intrusiva conhecida como efeito de monitorao. Algumas ferramentas oferecem suporte mais apropriado para desenvolvedores (durante teste de componente e integrao dos componentes). Estas so identificadas com um (D) na classificao que segue abaixo.
Certified Tester
Foundation Level Syllabus
cdigo seguro), alm de anlise de estrutura e dependncias. Podem ser teis tambm no planejamento ou anlise de risco devido ao fornecimento de mtricas para o cdigo (ex.: complexidade). Ferramentas de Modelagem (D) Ferramentas de modelagem validam o modelo do software (ex.: modelo fsico de dados, para um banco de dados relacional), enumerando inconsistncia e encontrando defeitos. Essas ferramentas podem geralmente ajudar na gerao de alguns casos de testes baseados no modelo.
Verso 2011br
Agosto 2011
Pgina 60 de 77
Certified Tester
Foundation Level Syllabus
6.1.7 Ferramenta de performance e monitorao (K1)
Ferramenta de Anlise dinmica (D) Estas ferramentas encontram defeitos que s so evidenciados quando o software est em execuo, assim como dependncia de tempo ou vazamento de memria. So normalmente utilizados em testes de componentes, testes de integrao dos componentes e teste de middleware. Ferramentas de Teste de Performance/Teste de Carga/Teste de Estresse Ferramenta de teste de performance monitoram e relatam como um sistema se comporta sob uma variedade de condies simuladas, em termos de nmero de usurios concorrentes, seu padro ramp-up, frequncia e porcentagem relativa de transaes. A simulao de carga conseguida atravs da criao de usurios virtuais que executam um conjunto selecionado de transaes, espalhados atravs de vrias mquinas de testes normalmente chamadas de geradores de carga. Ferramentas de monitorao Ferramentas de monitorao continuamente analisam, verificam e reportam a respeito do uso de recursos especficos do sistema, e fornecem avisos de possveis problemas do servio.
Verso 2011br
Agosto 2011
Pgina 61 de 77
Certified Tester
Foundation Level Syllabus 6.2 Uso Efetivo das Ferramentas: Riscos e Benefcios em potenciais (K2)
Termos
Teste orientado a dados, Teste orientado a palavras-chaves, linguagem de scripts.
20 minutos
Verso 2011br
Agosto 2011
Pgina 62 de 77
Certified Tester
Foundation Level Syllabus
Capturar testes pela gravao de aes manuais do usurio pode parecer atrativo, mas esta abordagem no tem uma escalabilidade. Um script de captura uma representao linear com dados e aes especficas como parte de cada script. Este tipo de script pode se tornar instvel a eventos inesperados. Uma abordagem orientada a dados separa os dados de entrada dos testes, normalmente em diversas planilhas contendo variaes destes dados, utilizando scripts mais genricos que possam ler estas planilhas na execuo de um mesmo teste fazendo com que os dados utilizados sejam diferentes. Os testadores que no tem familiaridade com a linguagem dos scripts podem entrar com os dados para estes scripts pr-definidos. Em uma abordagem orientada a palavras-chave, as planilhas contm palavras-chaves que descrevem aes a serem tomadas e os dados do teste. Testadores (mesmo que no tenham familiaridade com a linguagem de scripts) podem ento definir os testes utilizando estas palavras-chaves, que poder ser montada para o aplicativo que ser testado. Um tcnico especialista na linguagem do script ser necessrio para todos os casos (ainda que como testador ou como especialista em automao). Para qualquer tcnica de script utilizada, os resultados de cada teste precisam ser armazenados para futuras comparaes. Ferramentas de anlises estticas Ferramentas de anlises estticas aplicadas ao cdigo fonte podem forar a padronizao do cdigo. No entanto se aplicada a um cdigo existente (sistemas legado) pode gerar grande quantidade de mensagens. Mensagens de ateno no param o processo de compilao, mas devem ser tratados para que a manuteno do cdigo seja mais fcil no futuro. Uma implementao gradual com filtros iniciais para excluir algumas mensagens poder ser uma boa e eficiente alternativa. Ferramentas de gerenciamento de teste Ferramentas de gerenciamento de teste precisam fazer a interface com outras ferramentas ou planilhas para produzir as informaes no melhor formato possvel de modo a atender as necessidades da empresa. O relatrio precisa ser bem desenhado e monitorado para que traga o benefcio esperado.
Verso 2011br
Agosto 2011
Pgina 63 de 77
Certified Tester
Foundation Level Syllabus 6.3 Implementando uma Ferramenta na Organizao (K1)
Termos
No h
15 minutos
Conceito
Os princpios para introduzir uma ferramenta em uma organizao so: Avaliao da maturidade da organizao, pontos fracos e pontos fortes na identificao de oportunidades para um aperfeioamento do processo de teste com uso de uma ferramenta. Avaliao frente a requisitos claros e os critrios objetivos. Uma prova de conceito, utilizando a ferramenta durante a fase de avaliao para estabelecer se ela funciona adequadamente com o software sendo testado e dentro da infraestrutura atual ou para identificar mudanas necessrias infraestrutura para efetivamente utilizar a ferramenta. Avaliao do fornecedor (incluindo treinamento, suporte e aspectos comerciais) ou fornecedores de suporte ao servio em caso de ferramentas no comerciais. Identificao dos requisitos internos para acompanhamento (mentoring e coaching) no uso da ferramenta. Avaliao das necessidades de treinamento, considerando as habilidades de automao de teste da equipe. Estimativa de uma razo custo-benefcio baseado em um business case concreto.
Introduzir a ferramenta seleciona em uma organizao se inicia com um projeto piloto, que tem os seguintes objetivos: Aprender mais detalhes sobre a ferramenta. Ver como a ferramenta poder se adequar aos processos e prticas e como necessitariam mudar. Decidir as formas e padres de uso, gerenciamento, arquivamento e manuteno da ferramenta e artefatos de testes (ex.: decidir a conveno dos nomes de arquivos, criao de bibliotecas e decidir a modularidade dos grupos de teste). Estimar se os benefcios sero atingidos a um custo razovel. Implementar a ferramenta ao restante da organizao incrementalmente. Adaptar e aprimorar o processo para combinar com o uso da ferramenta. Providenciar treinamentos para novos usurios. Definir diretrizes de utilizao. Implementar um modo de aprender lies com o uso da ferramenta. Fornecer suporte ao time de teste para uma determinada ferramenta. Monitorar o uso e os benefcios da ferramenta.
Referncias
6.2.2 Buwalda, 2001, Fewster, 1999 6.3 Fewster, 1999
Verso 2011br
Agosto 2011
Pgina 64 de 77
Certified Tester
Foundation Level Syllabus
7. Referncias
Padres
ISTQB Glossrio de termos usados no Teste de Software Verso 2.1 [CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration and Product Improvement, Addison Wesley: Reading, MA - Ver seo 2.1 [IEEE 829-1998] IEEE Std 829 (1998) IEEE Standard for Software Test Documentation) - Ver sees 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6 [IEEE 1028] IEEE Std 1028 (2008) IEEE Standard for Software Reviews and Audits- Ver seo 3.2 [IEEE 12207] IEEE 12207/ISO/IEC 12207-1996, Software life cycle processes - Ver seo 2.1 [ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality - Ver seo 2.3
Livros
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand Reinhold: Boston - Ver sees 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6 [Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley & Sons: NewYork - Ver sees 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6 [Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley: Reading, MA - Ver seo 6.2 [Copeland, 2004] Copeland, L. (2004) A Practitioners Guide to Software Test Design, Artech House: Norwood, MA - Ver sees 2.2, 2.3, 4.2, 4.3, 4.4, 4.6 [Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech House: Norwood, MA - Ver sees 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4 [Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison Wesley: Reading, MA - Ver sees 6.2, 6.3 [Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley: Reading, MA - Ver sees 3.2.2, 3.2.4 [Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA - Ver sees 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3 [Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software Testing, John Wiley & Sons - Ver sees 1.1, 4.5, 5.2 [Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons - Ver sees 1.2, 1.3, 2.2, 4.3 [van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters 6, 8, 10), UTN Publishers: The Netherlands - Ver sees 3.2, 3.3
Verso 2011br
Agosto 2011
Pgina 65 de 77
Certified Tester
Foundation Level Syllabus
Verso 2011br
Agosto 2011
Pgina 66 de 77
Certified Tester
Foundation Level Syllabus
Requisitos bsicos para esta qualificao
O critrio de entrada para fazer o exame do ISTQB (Certificado dos Fundamentos em Teste de Software) que o candidato tenha um interesse em teste de software. No entanto, altamente recomendvel que o candidato tambm: Tenha um conhecimento mnimo seja em desenvolvimento de software ou teste de software, como seis meses de experincia como um testador em testes de sistema ou de aceite, ou como desenvolvedor de software. Fazer o curso que autorizado pelos padres do ISTQB (por uma comisso nacional reconhecida).
Verso 2011br
Agosto 2011
Pgina 67 de 77
Certified Tester
Foundation Level Syllabus
Verso 2011br
Agosto 2011
Pgina 68 de 77
Certified Tester
Foundation Level Syllabus
Nvel 4: Analisar (K4)
O candidato pode separar a informao relacionada a um procedimento ou tcnica em suas partes constituintes para melhor entendimento, e pode distinguir entre fatos e inferncias. A aplicao tpica uma anlise de documento, software ou situao de projeto e propor aes adequadas para resolver um problema ou tarefa. Palavras chave: Analisar, organizar, encontrar coerncia, integrar, esboar, estruturar, atribuir, desconstruir, diferenciar, discriminar, distinguir, focar, selecionar. Exemplo: Avaliar 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 a partir de resultados.
Referncias
(Para os nveis cognitivos dos objetivos de estudo) 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:
Verso 2011br
Agosto 2011
Pgina 69 de 77
Certified Tester
Foundation Level Syllabus
Regras gerais
SG1 SG2 SG3 SG4 SG5 O syllabus deve ser compreensvel e absorvvel por pessoas com 0 a 6 meses (ou mais) de experincia em teste. (6-MESES) O syllabus mais prtico do que terico. (PRTICO) O syllabus claro e objetivo (no tem ambiguidades) aos leitores interessados. (CLARO) O syllabus compreensvel a pessoas de diferentes pases e, de fcil traduo em diferentes linguagens. (TRADUZVEL) O syllabus original usa o ingls americano. (INGLS-AMERICANO)
Contedo Atual
SC1 O syllabus inclui conceitos recentes de testes e reflete as melhores prticas da atualidade em teste de software, quando estas forem adotadas de forma geral. O syllabus est sujeito reviso de trs a cinco anos (ATUALIZADO). O syllabus deve minimizar aspectos relacionados a tempo, assim como as condies atuais do mercado para permitir possua uma vida til de trs a cinco anos. (VIDA UTIL)
SC2
Objetivos de Estudos
LO1 Objetivos de estudos distinguem os itens a ser reconhecidos/relembrados (nvel cognitivo K1), itens que o candidato deve compreender conceitualmente (K2) e aqueles que os candidatos esto aptos a praticar/utilizar (K3). (NVEL DE CONHECIMENTO) LO2 A descrio do contedo consistente com os objetivos de estudo. (CONSISTNCIA) LO3 Para ilustrar os objetivos de aprendizado, questes simuladas de exame devero ser apresentadas para as sees principais do syllabus. (EXAME)
Estrutura geral
ST1 ST2 ST3 ST4 ST5 A estrutura do syllabus clara e permite o cruzamento de referncia e de uma parte a outra das questes dos exames e de outros documentos relevantes. (REFERNCIAS CRUZADAS). Sobreposio entre sees do syllabus minimizado. (SOBREPOSIO) Cada seo do syllabus tem a mesma estrutura. (ESTRUTURA CONSISTENTE) O syllabus contm verso, data de emisso e nmero de cada pgina. (VERSO) O syllabus contempla um guia que aponta a quantidade de tempo a ser gasta em cada seo (para refletir a importncia relativa de cada tpico). (TEMPO GASTO)
Referncias
SR1 Origens e referncias dos conceitos so dadas no syllabus para ajudar os instrutores a encontrar mais informaes sobre o tpico. (REFS)
Verso 2011br Agosto 2011 Pgina 70 de 77
Certified Tester
Foundation Level Syllabus
SR2 Quando no existir fontes claras ou identificveis, mas detalhes deveram ser fornecidos no syllabus. Por exemplo, definies esto no Glossrio, sendo assim apenas os termos sero listados no syllabus. (REFS SEM DETL)
Fontes e Informaes
Os termos utilizados no syllabus so definidos no Glossrio do ISTQB que usado em teste de software. Uma verso do glossrio disponibilizada pelo ISTQB. A traduo poder ser encontrada no site do BSTQB (www.bstqb.org.br) Uma lista de livros sobre teste de software recomendada para estudos em paralelo com este syllabus. A principal lista de livros parte da seo Referncias.
Verso 2011br
Agosto 2011
Pgina 71 de 77
Certified Tester
Foundation Level Syllabus
Verso 2011br
Agosto 2011
Pgina 72 de 77
Certified Tester
Foundation Level Syllabus
Release 2011
Mudanas feitas no release de manuteno 2011: 1) Primeira ocorrncia: ISTQB substitudo por ISTQB. 2) Introduo neste syllabus: Descrio dos nveis cognitivos de conhecimento removidos, pois isto estava redundante com o Apndice B. 3) Seo 1.6: Sendo que o intuito no era definir um Objetivo de Estudo para o Cdigo de tica, o nvel cognitivo para a seo foi removido. 4) Sees 2.2.1, 2.2.2, 2.2.3 e 2.2.4, 3.2.3: Correo de formatao em listas. 5) Seo 2.2.2. A palavra falha no estava correta de acordo com a descrio: ... isolar falhas em um componente especfico.... Portanto, foi substituda com a expresso defeito para a mesma sentena. 6) Seo 2.3: Formatao corrigida da lista de tpicos de objetivos de teste relacionados aos termos de teste na seo Tipos de Teste (K2).
Verso 2011br Agosto 2011 Pgina 73 de 77
Certified Tester
Foundation Level Syllabus
7) Seo 2.3.4: Descrio atualizada de debugging para ser consistente com a Verso 2.1 do Glossrio ISTQB. 8) Seo 3.2.1: Devido ao fato das atividades de uma reviso formal terem sido incorretamente formatadas, o processo de reviso tinha 12 atividades principais ao invs de 6, conforme previsto. Portanto, foi alterado de novo para seis, o que torna essa seo aderente ao Syllabus 2007 e o ISTQB Advanced Level Syllabus 2008. 9) Seo 4.2: Mudana de texto para clarificar como o teste caixa-preta e caixa-branca podem ser usados em conjunto com tcnicas baseadas na experincia. 10) Seo 4.3.5: caminho alternativo substitudo por cenrio alternativo. 11) Seo 4.4.2: Para clarear o termo teste de desvio no texto da Seo 4.4, uma sentena para clarificar o foco do teste de desvio foi alterado. 12) Seo 6.1: Tpico 6.1.1 Entendendo o Significado e Objetivo do Suporte a Ferramentas para Teste (K2) substitudo por 6.1.1. Suporte a Ferramentas para Teste (K2). 13) Seo 7 / Livros: A terceira edio de [Black, 2001] listada, substituindo a segunda edio. 14) Apndice D: Captulos requerendo exerccios foram substitudos pelos requisitos genricos informando que todos Objetivos de Estudo K3 e superiores requerem exerccios. Este um requisito especificado no Processo de Certificao ISTQB (Verso 1.26). 15) Apndice E: os objetivos de estudo alterados entre as verses 2007 e 2010 esto agora listados corretamente.
Verso 2011br
Agosto 2011
Pgina 74 de 77
Certified Tester
Foundation Level Syllabus
condio de teste, 18 controladores, 27 controle de verso, 64 critrio de sada, 18 D dados de teste, 18, 48, 72 dano, 14 data-driven, 76 deduo de erros, 52 defeito, 14, 32 depurao, 16, 27, 32 diagrama de fluxo de processo, 31 diagrama de transio de estados, 31 E efeito de monitorao, 71 encerramento de teste, 20 engano, 14 erros, 15 escopo da integrao, 28 especificao de riscos, 28 especificao de teste, 36 estimativa do esforo do teste, 60 estratgia de teste, 18, 57, 61 execuo de teste, 18, 19, 73, 76 F falha, 14 Ferramentas de Teste, 71 Ferramentas para gerenciamento do teste, 71 Ferramentas para testes estticos, 72 G garantia da qualidade, 15 gerenciamento de configurao, 64, 72
Agosto 2011 Pgina 75 de 77
Certified Tester
Foundation Level Syllabus
gerenciamento de incidentes, 72 gerenciamento de requisitos, 71 gerenciamento de riscos, 66 gerenciamento de teste, 71, 76 gerente de teste, 38, 56, 57, 65 I implementao, 19, 57 incidente, 18, 67 K Kick-off, 37 L lder de teste, 56, 57 linguagem de scripts, 75 M medio de cobertura, 73 mtricas, 62 modelagem, 25, 72 modelagem de teste, 45, 72 modelo de desenvolvimento incremental, 25 Modelo V, 25 Moderador, 38 monitorao, 74 monitorao do teste, 62 mudanas, 34 N nvel do risco, 15 O objetivo do teste, 16 P palavras-chave, 76 Partio de Equivalncia, 48 performance, 73, 75 Planejamento, 37 planejamento de integrao, 57 Planejamento de teste, 59 plano de teste, 18, 65 poltica de teste, 18 Preparao individual, 37 processo de reviso, 72 processo mental, 16 processos de negcios, 28 Q qualidade, 14 R rastreabilidade, 45 registro de teste, 18 regras de negcio, 28 relatrio consolidado de teste, 18 relatrio de incidentes, 67 relatrio do teste, 62 requisito, 16, 25, 28, 36 reteste, 18 Retrabalho, 37 Reunio de reviso, 37 reviso, 16 Revisores, 38 risco, 14, 28, 59, 60, 65, 66 S script de teste, 36, 45 segurana, 73 simuladores, 27 software de prateleira, 25 stakeholders, 20, 21, 29 sute de teste, 18 T tabela de deciso, 28, 48 testador, 56, 57, 58 teste automatizado, 45 teste de aceite, 29, 59 teste de carga, 32
Verso 2011br
Agosto 2011
Pgina 76 de 77
Certified Tester
Foundation Level Syllabus
Teste de Caso de Uso, 49 teste de componente, 27 teste de confiabilidade, 32 teste de confirmao, 18, 31, 32 teste de estresse, 32 teste de funcionalidade, 27 teste de integrao, 27, 29, 32, 51 teste de interoperabilidade, 32 teste de manuteno, 34 teste de manutenibilidade, 32 teste de performance, 32 teste de portabilidade, 32 teste de regresso, 18, 26, 32 teste de segurana, 31 teste de sistema, 28, 59 Teste de transio de estados, 49 teste de unidade, 73 teste de usabilidade, 32 teste dinmico, 36, 41 Teste e Cobertura de Deciso, 50 teste esttico, 36 teste estrutural, 27, 31, 32 Teste exaustivo, 17 teste exploratrio, 52 teste funcional, 31, 32 teste independente, 21 teste no funcional, 32 Teste Operacional de Aceite, 29 Teste orientado a dados, 75 Teste orientado a palavras-chaves, 75 testes de integrao, 28 testware, 18, 19, 20, 57 Tipos de reviso, 38 top-down, 28 V validao, 25 verificao, 25
Verso 2011br
Agosto 2011
Pgina 77 de 77