Certificação de Testador CTFL 4.0 - PDF

Certified Tester Foundation Level Syllabus CTFL versão 4.0 International Software Testing Qualifications Board Versão traduzida, adaptada e disponibilizada na Língua Portuguesa pelo WGT BSTQB - Grupo de Traduções do BSTQB Certified Tester Foundation Level Syllabus Direitos autorais Aviso de direitos autorais © International Software Testing Qualifications Board (doravante denominado ISTQB®). ISTQB® é uma marca registrada do International Software Testing Qualifications Board. Copyright© 2023 os autores do syllabus Foundation Level v4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (presidente), Adam Roman, Lucjan Stapp, Stephanie Ulrich (vice-presidente), Eshraka Zakaria. Copyright© 2019 os autores da atualização 2019 Klaus Olsen (presidente), Meile Posthuma e Stephanie Ulrich. Copyright© 2018 os autores da atualização de 2018 Klaus Olsen (presidente), Tauhida Parveen (vice- presidente), Rex Black (gerente de projeto), Debra Friedenberg, Matthias Hamburg, Judy McKay, Meile Posthuma, Hans Schaefer, Radoslaw Smilgin, Mike Smith, Steve Toms, Stephanie Ulrich, Marie Walsh e Eshraka Zakaria. Copyright© 2011 os autores da atualização 2011 Thomas Müller (presidente), Debra Friedenberg e o ISTQB WG Foundation Level. Copyright © 2010 os autores da atualização de 2010 Thomas Müller (presidente), Armin Beer, Martin Klonk e Rahul Verma. Copyright© 2007 os autores da atualização 2007 Thomas Müller (presidente), Dorothy Graham, Debra Friedenberg e Erik van Veenendaal. Copyright© 2005 os autores Thomas Müller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson e Erik van Veenendaal. Todos os direitos reservados. Os autores transferem os direitos autorais para o ISTQB ®. Os autores (como atuais detentores dos direitos autorais) e o ISTQB ® (como futuro detentor dos direitos autorais) concordaram com as seguintes condições de uso: Extratos deste documento, para uso não comercial, podem ser copiados se a fonte for citada. Qualquer Provedor de Treinamento Credenciado pode usar este syllabus como base para um curso de treinamento se os autores e o ISTQB ® forem reconhecidos como a fonte e os proprietários dos direitos autorais do syllabus desde que qualquer anúncio de tal curso de treinamento possa mencionar o syllabus somente após o credenciamento oficial dos materiais de treinamento ter sido recebido de um Conselho Membro reconhecido pelo ISTQB®. Qualquer indivíduo ou grupo de indivíduos pode usar este syllabus como base para artigos e livros, se os autores e o ISTQB® forem reconhecidos como a fonte e os proprietários dos direitos autorais do syllabus. Qualquer outro uso deste syllabus é proibido sem antes obter a aprovação por escrito do ISTQB®. Qualquer Conselho Membro reconhecido pelo ISTQB ® pode traduzir este documento desde que reproduza o Aviso de Direitos Autorais acima mencionado na versão traduzida do syllabus. V. 4.0 Página 2 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Histórico da Revisão Versão Data Observações CTFL v4.0 21/04/2023 Versão de lançamento CTFL v3.1.1 01/07/2021 Atualização de direitos autorais e logotipo CTFL v3.1 11/11/2019 Versão de manutenção de pequenas atualizações ISTQB 2018 27/04/2018 Versão candidata de lançamento ISTQB 2011 01/04/2011 Versão de manutenção ISTQB 2010 30/03/2010 Versão de manutenção ISTQB 2007 01/05/2007 Versão de manutenção ISTQB 2005 01/07/2005 Versão candidata de lançamento ASQF V2.2 07/2003 ASQF Syllabus Foundation Level versão v2.2 “Lehrplan Grundlagen des Software-testens“ ISEB V2.0 25/02/1999 ISEB Software Testing Foundation Syllabus v2.0 Histórico da versão de tradução do BSTQB Versão Data Observações 1 29/02/2024 Correção de erros gramaticais. 2 28/06/2024 Adequação visual V. 4.0 Página 3 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Índice Direitos autorais................................................................................................................................................ 2 Histórico da Revisão.......................................................................................................................................... 3 Índice................................................................................................................................................................... 4 Agradecimentos................................................................................................................................................. 7 0 Introdução................................................................................................................................................... 9 0.1 Objetivo deste syllabus.....................................................................................................................................9 0.2 O Certified Tester Foundation Level em Teste de Software........................................................................9 0.3 Carreira para Testadores..................................................................................................................................9 0.4 Resultados de Negócio................................................................................................................................... 10 0.5 Objetivos de Aprendizagem e Nível Cognitivo de Conhecimento............................................................ 10 0.6 Exame de certificação Foundation Level..................................................................................................... 11 0.7 Credenciamento.............................................................................................................................................. 11 0.8 Manuseio de Normas..................................................................................................................................... 11 0.9 Mantendo-se atualizado................................................................................................................................ 11 0.10 Nível de detalhe.............................................................................................................................................. 11 0.11 Como este syllabus está organizado............................................................................................................ 12 1 Fundamentos de Teste (180 min)........................................................................................................... 13 1.1 O que é teste?.................................................................................................................................................. 14 1.1.1 Objetivos do teste....................................................................................................................................... 14 1.1.2 Teste e depuração...................................................................................................................................... 15 1.2 Por que os testes são necessários?.............................................................................................................. 15 1.2.1 Contribuições para o sucesso dos testes................................................................................................ 15 1.2.2 Testes e Garantia da Qualidade (QA)....................................................................................................... 16 1.2.3 Erros, Defeitos, Falhas e Causas-raiz....................................................................................................... 16 1.3 Princípios de Teste.......................................................................................................................................... 17 1.4 Atividades de teste, Testware e Papéis no teste........................................................................................ 18 1.4.1 Atividades e Tarefas de Teste................................................................................................................... 18 1.4.2 Processo de Teste no Contexto................................................................................................................ 19 1.4.3 Testware....................................................................................................................................................... 20 1.4.4 Rastreabilidade entre a Base de Teste e o Testware............................................................................. 20 1.4.5 Papéis no Teste........................................................................................................................................... 21 1.5 Habilidades essenciais e boas práticas em testes...................................................................................... 21 1.5.1 Habilidades genéricas necessárias para testes...................................................................................... 22 1.5.2 Abordagem de equipe completa.............................................................................................................. 22 1.5.3 Independência dos testes......................................................................................................................... 23 2 Testes ao longo do Ciclo de Vida de Desenvolvimento de Software (130 min).............................. 24 2.1 Testes no contexto de um Ciclo de Vida de Desenvolvimento de Software........................................... 25 2.1.1 Impacto do Ciclo de Vida de Desenvolvimento de Software nos Testes............................................ 25 V. 4.0 Página 4 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 2.1.2 Ciclo de Vida de Desenvolvimento de Software e boas práticas de Teste......................................... 25 2.1.3 Teste como um motivador para o desenvolvimento de software....................................................... 26 2.1.4 DevOps e Testes......................................................................................................................................... 26 2.1.5 Abordagem Shift-Left................................................................................................................................. 27 2.1.6 Retrospectivas e melhoria de processos................................................................................................. 28 2.2 Níveis de Teste e Tipos de Teste................................................................................................................... 28 2.2.1 Níveis de Teste............................................................................................................................................ 29 2.2.2 Tipos de Teste............................................................................................................................................. 30 2.2.3 Testes de Confirmação e Teste de Regressão........................................................................................ 31 2.3 Teste de Manutenção..................................................................................................................................... 31 3 Teste Estático (80 min)............................................................................................................................. 33 3.1 Noções básicas de Teste Estático................................................................................................................. 34 3.1.1 Produtos de trabalho examináveis por testes estáticos....................................................................... 34 3.1.2 Valor do teste estático............................................................................................................................... 34 3.1.3 Diferenças entre testes estáticos e testes dinâmicos............................................................................ 35 3.2 Processo de feedback e revisão.................................................................................................................... 36 3.2.1 Benefícios do feedback antecipado e frequente dos stakeholders.................................................... 36 3.2.2 Atividades do processo de revisão........................................................................................................... 36 3.2.3 Funções e responsabilidades nas revisões............................................................................................. 37 3.2.4 Tipos de revisão.......................................................................................................................................... 37 3.2.5 Fatores de sucesso para revisões............................................................................................................. 38 4 Análise e Modelagem de Teste (390 min)............................................................................................. 39 4.1 Visão geral das técnicas de teste.................................................................................................................. 40 4.2 Técnicas de Teste Caixa-Preta....................................................................................................................... 40 4.2.1 Particionamento de Equivalência (EP)..................................................................................................... 40 4.2.2 Análise de Valor de Limite (BVA)............................................................................................................... 41 4.2.3 Teste de Tabela de Decisão....................................................................................................................... 42 4.2.4 Teste de Transição de Estado................................................................................................................... 43 4.3 Técnicas de Teste Caixa-Branca.................................................................................................................... 44 4.3.1 Teste de Instrução e Cobertura de Instrução......................................................................................... 44 4.3.2 Teste de Ramificação e Cobertura de Ramificação................................................................................ 44 4.3.3 O valor do Teste Caixa-Branca.................................................................................................................. 45 4.4 Técnicas de Teste Baseadas na Experiência............................................................................................... 45 4.4.1 Suposição de Erro....................................................................................................................................... 46 4.4.2 Testes Exploratórios................................................................................................................................... 46 4.4.3 Testes baseados em Lista de Verificação................................................................................................ 47 4.5 Abordagens de Teste Baseadas na Colaboração....................................................................................... 47 4.5.1 Escrita colaborativa de histórias de usuários......................................................................................... 47 4.5.2 Critérios de Aceite....................................................................................................................................... 48 4.5.3 Desenvolvimento Orientado por Teste de Aceite (ATDD)..................................................................... 48 V. 4.0 Página 5 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 5 Gerenciamento das Atividades de Teste (335 min)............................................................................. 50 5.1 Planejamento de Teste.................................................................................................................................. 51 5.1.1 Objetivo e conteúdo de um plano de teste............................................................................................. 51 5.1.2 Contribuição do Testador para o planejamento de iteração e liberação........................................... 51 5.1.3 Critérios de Entrada e Critérios de Saída................................................................................................ 52 5.1.4 Técnicas de estimativa............................................................................................................................... 52 5.1.5 Priorização de casos de teste.................................................................................................................... 53 5.1.6 Pirâmide de Teste....................................................................................................................................... 54 5.1.7 Quadrantes de Teste.................................................................................................................................. 55 5.2 Gerenciamento de Risco................................................................................................................................ 55 5.2.1 Definição de Risco e Atributos do Risco.................................................................................................. 56 5.2.2 Riscos do projeto e riscos do produto..................................................................................................... 56 5.2.3 Análise de Risco do Produto..................................................................................................................... 57 5.2.4 Controle de Risco do Produto................................................................................................................... 57 5.3 Monitoramento, Controle e Conclusão do Teste....................................................................................... 58 5.3.1 Métricas usadas em testes........................................................................................................................ 58 5.3.2 Relatórios de Teste: objetivo, conteúdo e público-alvo......................................................................... 59 5.3.3 Comunicação do status dos testes........................................................................................................... 59 5.4 Gerenciamento de Configuração (CM)......................................................................................................... 60 5.5 Gerenciamento de Defeitos.......................................................................................................................... 60 6 Ferramentas de Teste (20 min)............................................................................................................... 62 6.1 Suporte de Ferramentas para Testes........................................................................................................... 63 6.2 Benefícios e Riscos da Automação de Teste............................................................................................... 63 Referências....................................................................................................................................................... 65 Apêndice A: Objetivos de Aprendizagem e Nível Cognitivo...................................................................... 68 Apêndice B: Matriz de rastreabilidade entre resultados de negócio x objetivos de aprendizagem.. 69 Apêndice C: Notas de versão......................................................................................................................... 76 V. 4.0 Página 6 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Agradecimentos Este documento foi formalmente lançado pela General Assembly do ISTQB® em 21 de abril de 2023. Foi produzido por uma equipe dos grupos de trabalho conjuntos do ISTQB Foundation Level e Agile: Laura Albert, Renzo Cerquozzi (vice chair), Wim Decoutere, Klaudia Dussa-Zieger, Chintaka Indikadahena, Arnika Hryszko, Martin Klonk, Kenji Onishi, Michaël Pilaeten (co-chair), Meile Posthuma, Gandhinee Rajkomar, Stuart Reid, Eric Riou du Cosquer (co-chair), Jean-François Riverin, Adam Roman, Lucjan Stapp, Stephanie Ulrich (vice chair), Eshraka Zakaria. A equipe agradece a Stuart Reid, Patricia McQuaid and Leanne Howard pela revisão técnica e aos Conselhos Membros por suas sugestões e contribuições. As seguintes pessoas participaram da revisão, dos comentários e da votação deste syllabus: Adam Roman, Adam Scierski, Ágota Horváth, Ainsley Rood, Ale Rebon Portillo, Alessandro Collino, Alexander Alexandrov, Amanda Logue, Ana Ochoa, André Baumann, André Verschelling, Andreas Spillner, Anna Miazek, Armin Born, Arnd Pehl, Arne Becher, Attila Gyúri, Attila Kovács, Beata Karpinska, Benjamin Timmermans, Blair Mo, Carsten Weise, Chinthaka Indikadahena, Chris Van Bael, Ciaran O'Leary, Claude Zhang, Cristina Sobrero, Dandan Zheng, Dani Almog, Daniel Säther, Daniel van der Zwan, Danilo Magli, Darvay Tamás Béla, Dawn Haynes, Dena Pauletti, Dénes Medzihradszky, Doris Dötzer, Dot Graham, Edward Weller, Erhardt Wunderlich, Eric Riou Du Cosquer, Florian Fieber, Fran O'Hara, François Vaillancourt, Frans Dijkman, Gabriele Haller, Gary Mogyorodi, Georg Sehl, Géza Bujdosó, Giancarlo Tomasig, Giorgio Pisani, Gustavo Márquez Sosa, Helmut Pichler, Hongbao Zhai, Horst Pohlmann, Ignacio Trejos, Ilia Kulakov, Ine Lutterman, Ingvar Nordström, Iosif Itkin, Jamie Mitchell, Jan Giesen, Jean-Francois Riverin, Joanna Kazun, Joanne Tremblay, Joëlle Genois, Johan Klintin, John Kurowski, Jörn Münzel, Judy McKay, Jürgen Beniermann, Karol Frühauf, Katalin Balla, Kevin Kooh, Klaudia Dussa-Zieger, Klaus Erlenbach, Klaus Olsen, Krisztián Miskó, Laura Albert, Liang Ren, Lijuan Wang, Lloyd Roden, Lucjan Stapp, Mahmoud Khalaili, Marek Majernik, Maria Clara Choucair, Mark Rutz, Markus Niehammer, Martin Klonk, Márton Siska, Matthew Gregg, Matthias Hamburg, Mattijs Kemmink, Maud Schlich, May Abu-Sbeit, Meile Posthuma, Mette Bruhn-Pedersen, Michal Tal, Michel Boies, Mike Smith, Miroslav Renda, Mohsen Ekssir, Monika Stocklein Olsen, Murian Song, Nicola De Rosa, Nikita Kalyani, Nishan Portoyan, Nitzan Goldenberg, Ole Chr. Hansen, Patricia McQuaid, Patricia Osorio, Paul Weymouth, Pawel Kwasik, Peter Zimmerer, Petr Neugebauer, Piet de Roo, Radoslaw Smilgin, Ralf Bongard, Ralf Reissing, Randall Rice, Rik Marselis, Rogier Ammerlaan, Sabine Gschwandtner, Sabine Uhde, Salinda Wickramasinghe, Salvatore Reale, Sammy Kolluru, Samuel Ouko, Stephanie Ulrich, Stuart Reid, Surabhi Bellani, Szilard Szell, Tamás Gergely, Tamás Horváth, Tatiana Sergeeva, Tauhida Parveen, Thaer Mustafa, Thomas Eisbrenner, Thomas Harms, Thomas Heller, Tobias Letzkus, Tomas Rosenqvist, Werner Lieblang, Yaron Tsubery, Zhenlei Zuo and Zsolt Hargitai. ISTQB Working Group Foundation Level (Edition 2018): Klaus Olsen (chair), Tauhida Parveen (vice chair), Rex Black (project manager), Eshraka Zakaria, Debra Friedenberg, Ebbe Munk, Hans Schaefer, Judy McKay, Marie Walsh, Meile Posthuma, Mike Smith, Radoslaw Smilgin, Stephanie Ulrich, Steve Toms, Corne Kruger, Dani Almog, Eric Riou du Cosquer, Igal Levi, Johan Klintin, Kenji Onishi, Rashed Karim, Stevan Zivanovic, Sunny Kwon, Thomas Müller, Vipul Kocher, Yaron Tsubery e a todos os Conselhos Membros por suas sugestões. V. 4.0 Página 7 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus ISTQB Working Group Foundation Level (Edition 2011): Thomas Müller (presidente), Debra Friedenberg. A equipe A equipe principal agradece à equipe de revisão (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riou du Cosquier, Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) e a todos os Conselhos Membros pelas sugestões para a versão atual do syllabus. ISTQB Working Group Foundation Level (Edition 2010): Thomas Müller (presidente), Rahul Verma, Martin Klonk e Armin Beer. A equipe principal agradece à equipe de revisão (Rex Black, Mette Bruhn- Pederson, Debra Friedenberg, Klaus Olsen, Judy McKay, Tuula Pääkkönen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van Veenendaal) e a todos os Conselhos Membros por suas sugestões. ISTQB Working Group Foundation Level (Edition 2007): Thomas Müller (presidente), Dorothy Graham, Debra Friedenberg e Erik van Veenendaal. A equipe principal agradece à equipe de revisão (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders Pettersson e Wonil Kwon) e a todos os Conselhos Membros por suas sugestões. ISTQB Working Group Foundation Level (Edition 2005): Thomas Müller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson e Erik van Veenendaal. A equipe principal agradece à equipe de revisão e a todos os Conselhos Membros pelas sugestões. O BSTQB agradece aos voluntário do GT Traduções pelo empenho e esforço na tradução e revisão deste material: Eduardo Medeiros, George Fialkovitz, Irene Nagase, Osmar Higashi, Rogério Athaide, Stênio Viveiros. V. 4.0 Página 8 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 0 Introdução 0.1 Objetivo deste syllabus Esse syllabus forma a base para a International Software Testing Qualification no Foundation Level. O ISTQB® fornece esse syllabus da seguinte forma: Aos conselhos membros, para traduzir para seu idioma local e credenciar os provedores de treinamento. Os conselhos membros podem adaptar o syllabus às suas necessidades específicas de idioma e modificar as referências para adaptá-las às suas publicações locais. Aos órgãos de certificação, para que elaborem questões de exame em seu idioma local, adaptadas aos objetivos de aprendizagem deste programa. Aos provedores de treinamento, para produzir material didático e determinar métodos de ensino adequados. Para candidatos à certificação, para se preparar para o exame de certificação (como parte de um curso de treinamento ou de forma independente). Para a comunidade internacional de Engenharia de Software e Sistemas, para promover a profissão de Teste de Software e Sistemas, e como base para livros e artigos. 0.2 O Certified Tester Foundation Level em Teste de Software A certificação Foundation Level é destinada a qualquer pessoa envolvida em testes de software. Isso inclui pessoas em funções como Testadores, Analistas de Teste, Engenheiros de Teste, Consultores de Teste, Gerentes de Teste, Desenvolvedores de Software e membros da equipe de desenvolvimento. Essa certificação de nível fundamental também é apropriada para qualquer pessoa que queira ter uma compreensão básica dos testes de software, como Gerentes de Projeto, Gerentes de Qualidade, Product Owner, Gerentes de Desenvolvimento de Software, Analistas de Negócios, Diretores de TI e Consultores de Gestão. Os detentores do Certificado Foundation Level poderão obter certificações de nível superior em teste de software. 0.3 Carreira para Testadores O esquema do ISTQB® oferece suporte para profissionais de teste em todos os estágios de suas carreiras, oferecendo amplitude e profundidade de conhecimento. As pessoas que obtiveram a certificação ISTQB® Foundation Level também podem se interessar pelos níveis Core Advanced (Analista de Testes, Analista de Testes Técnicos e Gerente de Testes) e, posteriormente, pelo Expert Level (Gerenciamento de Testes ou Melhoria do Processo de Testes). Qualquer pessoa que queira desenvolver habilidades em práticas de teste em um ambiente ágil pode considerar as certificações Agile Technical Tester ou Agile Test Leadership at Scale. O fluxo do Specialist oferece um mergulho profundo em áreas que têm abordagens e atividades de teste específicas (p. ex., em automação de testes, testes de AI, testes baseados em modelos, testes de aplicativos móveis), que estão relacionadas a áreas de teste específicas (p. ex., testes de performance, testes de usabilidade, testes de aceite, testes de segurança) ou que agrupam o conhecimento de testes para determinados V. 4.0 Página 9 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus domínios (p. ex., automotivo ou de jogos). Acesse www.istqb.org para obter as informações mais recentes sobre o Esquema de Certificação em Teste do ISTQB ®. 0.4 Resultados de Negócio Esta seção lista os 14 Resultados de Negócio esperados de uma pessoa que tenha obtido a certificação Foundation Level. Um Testador certificado no Foundation Level pode... FL-BO1 Compreender o que é um teste e por que ele é benéfico; FL-BO2 Compreender os conceitos fundamentais de teste de software; FL-BO3 Identificar a abordagem e as atividades de teste a serem implementadas dependendo do contexto do teste; FL-BO4 Avaliar e melhorar a qualidade da documentação; FL-BO5 Aumentar a eficácia e a eficiência dos testes; FL-BO6 Alinhar o processo de teste com o ciclo de vida de desenvolvimento de software; FL-BO7 Compreender os princípios de gerenciamento de testes; FL-BO8 Escreva e comunique relatórios de defeitos claros e compreensíveis; FL-BO9 Compreender os fatores que influenciam as prioridades e os esforços relacionados aos testes; FL-BO10 Trabalhar como parte de uma equipe multifuncional; FL-BO11 Conhecer os riscos e benefícios relacionados à automação de testes; FL-BO12 Identificar as habilidades essenciais necessárias para a realização de testes; FL-BO13 Compreender o impacto do risco nos testes; FL-BO14 Relatar com eficácia o progresso e a qualidade do teste. 0.5 Objetivos de Aprendizagem e Nível Cognitivo de Conhecimento Os objetivos de aprendizagem examináveis (LO) apoiam os resultados de negócio e são usados para criar o exame Certified Tester Foundation Level. Em geral, todo o conteúdo dos capítulos de 1 a 6 deste syllabus pode ser examinado em um nível K1. Ou seja, o candidato pode ser solicitado a reconhecer, lembrar ou recordar uma palavra-chave ou um conceito mencionado em qualquer um dos seis capítulos. Os níveis específicos dos objetivos de aprendizagem são mostrados no início de cada capítulo e classificados da seguinte forma: K1: Lembrar K2: Compreender K3: Aplicar Mais detalhes e exemplos de objetivos de aprendizagem são fornecidos no Apêndice A. Todos os termos listados como palavras-chave logo abaixo dos títulos dos capítulos devem ser lembrados (K1), mesmo que não sejam explicitamente mencionados nos Objetivos de aprendizagem. V. 4.0 Página 10 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 0.6 Exame de certificação Foundation Level O exame de certificação Foundation Level baseia-se neste syllabus. As respostas às questões do exame podem exigir o uso de material baseado em mais de uma seção deste syllabus. Todas as seções do syllabus são passíveis de exame, exceto a Introdução e os Apêndices. Normas e livros são incluídos como referências (Capítulo 7), mas seu conteúdo não é passível de exame, além do que está resumido no próprio syllabus a partir dessas normas e livros. Consulte o documento Foundation Level Examination Structures and Rules. 0.7 Credenciamento Um Conselho Membro do ISTQB® pode credenciar provedores de treinamento cujo material do curso siga este syllabus. Os provedores de treinamento devem obter as diretrizes de credenciamento do Conselho Membro (BSTQB®) ou do órgão que realiza o credenciamento. Um curso credenciado é reconhecido como estando em conformidade com este syllabus e pode ter um exame ISTQB ® como parte do curso. As diretrizes de credenciamento para este syllabus seguem as diretrizes gerais de credenciamento publicadas pelo Processes Management and Compliance Working Group. 0.8 Manuseio de Normas Há normas referenciadas no Foundation Syllabus (p. ex., normas IEEE ou ISO). Essas referências fornecem uma estrutura (como nas referências à ISO25010 com relação às características de qualidade) ou fornecem uma fonte de informações adicionais, se o leitor desejar. Os documentos de normas não se destinam a exame. Consulte o capítulo 7 para obter mais informações sobre normas. 0.9 Mantendo-se atualizado O setor de software muda rapidamente. Para lidar com essas mudanças e fornecer aos stakeholders acesso a informações relevantes e atuais, os grupos de trabalho do ISTQB criaram links no site www.istqb.org, que se referem à documentação de apoio e às mudanças nos padrões. Essas informações não são passíveis de exame no syllabus Foundation Level. 0.10 Nível de detalhe O nível de detalhamento desse syllabus permite a realização de cursos e exames consistentes internacionalmente. Para atingir esse objetivo, o syllabus consiste em: Objetivos gerais de instrução que descrevem a intenção do Foundation Level; Uma lista de termos (palavras-chave) que os alunos devem ser capazes de lembrar; Objetivos de aprendizagem (LO) para cada área de conhecimento, descrevendo os resultados cognitivos de aprendizagem a serem alcançados; Uma descrição dos principais conceitos, incluindo referências a fontes reconhecidas. V. 4.0 Página 11 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus O conteúdo do syllabus não é uma descrição de toda a área de conhecimento de testes de software; ele reflete o nível de detalhes a ser abordado nos cursos de treinamento de nível fundamental. Ele se concentra em conceitos e técnicas de teste que podem ser aplicados a todos os projetos de software, independentemente do SDLC empregado. 0.11 Como este syllabus está organizado Há seis capítulos com conteúdo passível de exame. O título de nível superior de cada capítulo especifica o tempo de estudo para o capítulo. O tempo não é fornecido em subcapítulos. Para cursos de treinamento credenciados, o syllabus exige um mínimo de 1135 minutos (18 horas e 55 minutos) de instrução, distribuídos nos seis capítulos da seguinte forma: Capítulo 1: Fundamentos dos Testes (180 minutos) O aluno aprende os princípios básicos relacionados a testes, os motivos pelos quais os testes são necessários e quais são os objetivos do teste; O aluno compreende o processo de teste, as principais atividades de teste e o testware; O aluno compreende as habilidades essenciais para a realização de testes. Capítulo 2: Testes ao longo do ciclo de vida de desenvolvimento de software (130 minutos) O aluno aprende como os testes são incorporados a diferentes abordagens de desenvolvimento. O aluno aprende os conceitos de abordagens de teste primeiro, bem como de DevOps. O aluno aprende sobre os diferentes níveis de teste, tipos de teste e testes de manutenção. Capítulo 3: Teste Estático (80 minutos) O aluno aprende sobre os fundamentos dos testes estáticos, o processo de feedback e revisão. Capítulo 4: Análise e Projeto de Teste (390 minutos) O aluno aprende a aplicar técnicas de teste caixa-preta, caixa-branca e baseadas na experiência para derivar casos de teste de vários produtos de trabalho de software. O aluno aprende sobre a abordagem de teste baseada na colaboração. Capítulo 5: Gerenciando as atividades de teste (335 minutos) O aluno aprende a planejar testes em geral e a estimar o esforço de teste. O aluno aprende como os riscos podem influenciar o escopo dos testes. O aluno aprende a monitorar e controlar as atividades de teste. O aluno aprende como o gerenciamento de configuração dá suporte aos testes. O aluno aprende a relatar defeitos de forma clara e compreensível. Capítulo 6: Ferramentas de Teste (20 minutos) O aluno aprende a classificar as ferramentas e a entender os riscos e os benefícios da automação de testes. V. 4.0 Página 12 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 1 Fundamentos de Teste (180 min) Palavras-chave cobertura, depuração, defeito, erro, falha, qualidade, garantia de qualidade, causa raiz, análise de teste, base de teste, caso de teste, conclusão do teste, condição de teste, controle de teste, dados de teste, projeto de teste, execução de teste, implementação de teste, monitoramento de teste, objeto de teste, objetivo de teste, planejamento de teste, procedimento de teste, resultado de teste, teste, testware, validação, verificação Objetivos de aprendizagem 1.1 O que é teste? FL-1.1.1 (K1) Identificar objetivos típicos de teste FL-1.1.2 (K2) Diferenciar teste de depuração 1.2 Por que os testes são necessários? FL-1.2.1 (K2) Exemplificar por que os testes são necessários FL-1.2.2 (K1) Relembrar a relação entre testes e garantia de qualidade FL-1.2.3 (K2) Distinguir entre causa raiz, erro, defeito e falha 1.3 Princípios de teste FL-1.3.1 (K2) Explicar os sete princípios de teste 1.4 Atividades de teste, Testware e Papéis de teste FL-1.4.1 (K2) Resumir as diferentes atividades e tarefas de teste FL-1.4.2 (K2) Explicar o impacto do contexto no processo de teste FL-1.4.3 (K2) Diferenciar testware que dá suporte às atividades de teste FL-1.4.4 (K2) Explicar o valor de manter a rastreabilidade FL-1.4.5 (K2) Comparar os diferentes papéis no teste 1.5 Habilidades essenciais e boas práticas em testes FL-1.5.1 (K2) Dar exemplos das habilidades genéricas necessárias para testar FL-1.5.2 (K1) Relembrar as vantagens da abordagem de equipe completa FL-1.5.3 (K2) Distinguir os benefícios e as desvantagens da independência dos testes V. 4.0 Página 13 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 1.1 O que é teste? Os sistemas de software são parte integrante de nossa vida cotidiana. A maioria das pessoas já teve experiência com software que não funcionou como esperado. Um software que não funciona corretamente pode causar muitos problemas, inclusive perda de dinheiro, tempo ou reputação comercial e, em casos extremos, até mesmo lesões ou morte. O teste de software avalia a qualidade do software e ajuda a reduzir o risco de falha do software em operação. O teste de software é um conjunto de atividades para descobrir defeitos e avaliar a qualidade dos artefatos de software. Esses artefatos, quando estão sendo testados, são conhecidos como objetos de teste. Uma equívoco comum sobre testes é que eles consistem apenas na execução de testes (ou seja, executar o software e verificar os resultados dos testes). Entretanto, o teste de software também inclui outras atividades e deve estar alinhado com o ciclo de vida de desenvolvimento de software - SDLC (ver capítulo 2). Outro equívoco comum sobre os testes é que eles se concentram inteiramente na verificação do objeto de teste. Embora o teste envolva verificação, ou seja, verificar se o sistema atende aos requisitos especificados, ele também envolve validação, o que significa checar se o sistema atende às necessidades dos usuários e de outros stakeholders em seu ambiente operacional. Os testes podem ser dinâmicos ou estáticos. O teste dinâmico envolve a execução do software, enquanto o teste estático não. O teste estático inclui revisões (ver capítulo 3) e análise estática. Os testes dinâmicos usam diferentes tipos de técnicas de teste e abordagens de teste para derivar casos de teste (ver capítulo 4). O teste não é apenas uma atividade técnica. Ele também precisa ser adequadamente planejado, gerenciado, estimado, monitorado e controlado (ver capítulo 5). Os Testadores usam ferramentas (ver capítulo 6), mas é importante lembrar que o teste é, em grande parte, uma atividade intelectual, exigindo que os Testadores tenham conhecimento especializado, usem habilidades analíticas e apliquem o pensamento crítico e o pensamento sistêmico (Myers 2011, Roman 2018). A norma ISO/IEC/IEEE 29119-1 fornece mais informações sobre os conceitos de teste de software. 1.1.1 Objetivos do teste Os objetivos típicos do teste são: Avaliar produtos de trabalho, como requisitos, histórias de usuários, projetos e código; Detectar falhas e defeitos; Garantir a cobertura necessária de um objeto de teste; Reduzindo o nível de risco de qualidade de software inadequado; Verificar se os requisitos especificados foram atendidos; Verificar se um objeto de teste está em conformidade com os requisitos contratuais, legais e normativos; Fornecer informações aos stakeholders para que eles possam tomar decisões informadas; Criar confiança na qualidade do objeto de teste; V. 4.0 Página 14 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Validar se o objeto de teste está completo e funciona conforme o esperado pelos stakeholders. Os objetivos dos testes podem variar, dependendo do contexto, o que inclui o produto de trabalho que está sendo testado, o nível de teste, os riscos, o ciclo de vida de desenvolvimento de software (SDLC) que está sendo seguido e os fatores relacionados ao contexto do negócio, por exemplo, estrutura corporativa, considerações competitivas ou tempo de comercialização. 1.1.2 Teste e depuração O teste e a depuração são atividades distintas. O teste pode desencadear falhas causadas por defeitos no software (teste dinâmico) ou pode encontrar defeitos diretamente no objeto de teste (teste estático). Quando o teste dinâmico (ver capítulo 4) aciona uma falha, a depuração se preocupa em encontrar as causas dessa falha (defeitos), analisar essas causas e eliminá-las. O processo típico de depuração nesse caso envolve: Reproduzir uma falha Diagnosticar (encontrar a causa principal) Corrigir a causa O teste de confirmação subsequente verifica se as correções resolveram o problema. De preferência, o teste de confirmação é feito pela mesma pessoa que realizou o teste inicial. Os testes de regressão subsequentes também podem ser realizados para verificar se as correções estão causando falhas em outras partes do objeto de teste (ver seção 2.2.3 para obter mais informações sobre testes de confirmação e testes de regressão). Quando o teste estático identifica um defeito, a depuração se preocupa em removê-lo. Não há necessidade de reprodução ou diagnóstico, pois o teste estático encontra defeitos diretamente e não pode causar falhas (ver capítulo 3). 1.2 Por que os testes são necessários? Os testes, como uma forma de controle de qualidade, ajudam a atingir os objetivos acordados dentro do escopo, do tempo, da qualidade e das restrições orçamentárias estabelecidas. A contribuição dos testes para o sucesso não deve se restringir às atividades da equipe de testes. Qualquer stakeholder pode usar suas habilidades de teste para trazer o projeto mais próximo do sucesso. O teste de componentes, sistemas e documentação associada ajuda a identificar defeitos no software, 1.2.1 Contribuições para o sucesso dos testes O teste oferece um meio econômico de detectar defeitos. Esses defeitos podem então serem removidos (por depuração: uma atividade que não é de teste), de modo que o teste contribui indiretamente para objetos de teste de maior qualidade. O teste fornece um meio de avaliar diretamente a qualidade de um objeto de teste em vários estágios do SDLC. Essas medidas são usadas como parte de uma atividade maior de gerenciamento de V. 4.0 Página 15 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus projetos, contribuindo para as decisões de passar para o próximo estágio do SDLC, como a decisão de liberação. Os testes oferecem aos usuários uma representação indireta no projeto de desenvolvimento. Os Testadores garantem que seu entendimento das necessidades dos usuários seja considerado em todo o ciclo de vida do desenvolvimento. A alternativa é envolver um conjunto representativo de usuários como parte do projeto de desenvolvimento, o que geralmente não é possível devido aos altos custos e à falta de disponibilidade de usuários adequados. Os testes também podem ser necessários para atender a requisitos contratuais ou legais, ou para cumprir normas regulatórias. 1.2.2 Testes e Garantia da Qualidade (QA) Embora as pessoas geralmente usem os termos "teste" e "garantia da qualidade" (QA) de forma intercambiável, teste e QA não são a mesma coisa. O teste é uma forma de controle de qualidade (QC). O QC é uma abordagem corretiva e orientada para o produto que se concentra nas atividades que apoiam a obtenção de níveis adequados de qualidade. Os testes são uma das principais formas de controle de qualidade, enquanto outras incluem métodos formais (verificação de modelos e prova de exatidão), simulação e prototipagem. A QA é uma abordagem preventiva e orientada para o processo que se concentra na implementação e no aprimoramento dos processos. Ela funciona com base no fato de que, se um bom processo for seguido corretamente, ele gerará um bom produto. A QA se aplica aos processos de desenvolvimento e teste e é responsabilidade de todos em um projeto. Os resultados dos testes são usados por QA e QC. No QC, eles são usados para corrigir defeitos, enquanto no QA eles fornecem feedback sobre a performance dos processos de desenvolvimento e teste. 1.2.3 Erros, Defeitos, Falhas e Causas-raiz Os seres humanos cometem erros (equívocos), que produzem defeitos (falta, bugs) que, por sua vez, podem resultar em falhas. Os seres humanos cometem erros por vários motivos, como pressão de tempo, complexidade dos produtos de trabalho, processos, infraestrutura ou interações, ou simplesmente porque estão cansados ou não têm treinamento adequado. Os defeitos podem ser encontrados na documentação, como uma especificação de requisitos ou um script de teste, no código-fonte ou em um artefato de suporte, como um arquivo de compilação. Os defeitos em artefatos produzidos no início do SDLC, se não forem detectados, geralmente levam a artefatos defeituosos mais tarde no ciclo de vida. Se um defeito no código for executado, o sistema poderá deixar de fazer o que deveria fazer ou fazer algo que não deveria, causando uma falha. Alguns defeitos sempre resultarão em falha se forem executados, enquanto outros só resultarão em falhas em circunstâncias específicas, e alguns podem nunca resultar em falha. V. 4.0 Página 16 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Os erros e defeitos não são a única causa de falhas. As falhas também podem ser causadas por condições ambientais, como quando a radiação ou o campo eletromagnético causam defeitos no firmware. Uma causa-raiz é um motivo fundamental para a ocorrência de um problema (p. ex., uma situação que leva a um erro). As causas-raiz são identificadas por meio da análise de causa-raiz, que normalmente é realizada quando ocorre uma falha ou quando um defeito é identificado. Acredita- se que outras falhas ou defeitos semelhantes possam ser evitados ou que sua frequência possa ser reduzida com a abordagem da causa-raiz, como, por exemplo, sua remoção. 1.3 Princípios de Teste Ao longo dos anos, foram sugeridos vários princípios de teste que oferecem diretrizes gerais aplicáveis a todos os testes. Este syllabus descreve sete desses princípios. 1) O teste mostra a presença, não a ausência de defeitos. Os testes podem mostrar que os defeitos estão presentes no objeto de teste, mas não podem provar que não há defeitos (Buxton 1970). Os testes reduzem a probabilidade de defeitos não serem descobertos no objeto de teste, mas, mesmo que nenhum defeito seja encontrado, os testes não podem provar a corretude do objeto de teste. 2) Testes exaustivos são impossíveis. Testar tudo não é viável, exceto em casos triviais (Manna 1978). Em vez de tentar testar exaustivamente, as técnicas de teste (ver capítulo 4), a priorização de casos de teste (ver seção 5.1.5) e os testes baseados em riscos (ver seção 5.2) devem ser usados para concentrar os esforços de teste. 3) Testes antecipados economizam tempo e dinheiro. Os defeitos que são removidos no início do processo não causarão defeitos subsequentes nos produtos de trabalho derivados. O custo da qualidade será reduzido, pois menos falhas ocorrerão posteriormente no SDLC (Boehm, 1981). Para encontrar defeitos logo no início, os testes estáticos (ver capítulo 3) e os testes dinâmicos (ver capítulo 4) devem ser iniciados o mais cedo possível. 4) Os defeitos se agrupam. Um pequeno número de componentes do sistema geralmente contém a maioria dos defeitos descobertos ou é responsável pela maioria das falhas operacionais (Enders 1975). Esse fenômeno é uma ilustração do Princípio de Pareto. Os agrupamentos de defeitos previstos e os agrupamentos de defeitos reais observados durante o teste ou em operação são uma entrada importante para o teste baseado em risco (ver seção 5.2). 5) Os testes se degradam. Se os mesmos testes forem repetidos muitas vezes, eles se tornarão cada vez mais ineficazes na detecção de novos defeitos (Beizer 1990). Para superar esse efeito, talvez seja necessário modificar os testes e os dados de teste existentes, e talvez seja necessário escrever novos testes. Entretanto, em alguns casos, a repetição dos mesmos testes pode ter um resultado benéfico, por exemplo, em testes de regressão automatizados (ver seção 2.2.3). 6) Os testes dependem do contexto. Não existe uma única abordagem universalmente aplicável aos testes. Os testes são feitos de forma diferente em contextos diferentes (Kaner 2011). V. 4.0 Página 17 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 7) Falácia da ausência de defeitos. É uma falácia (ou seja, uma concepção errônea) esperar que a verificação do software garanta o sucesso de um sistema. Testar exaustivamente todos os requisitos especificados e corrigir todos os defeitos encontrados ainda pode produzir um sistema que não atenda às necessidades e expectativas dos usuários, que não ajude a atingir os objetivos de negócio do cliente e que seja inferior a outros sistemas concorrentes. Além da verificação, a validação também deve ser realizada (Boehm, 1981). 1.4 Atividades de teste, Testware e Papéis no teste O teste depende do contexto, mas, em um nível elevado, há conjuntos comuns de atividades de teste sem os quais é menos provável que o teste atinja seus objetivos. Esses conjuntos de atividades de teste formam um processo de teste. O processo de teste pode ser adaptado a uma determinada situação com base em vários fatores. Quais atividades de teste estão incluídas nesse processo de teste, como são implementadas e quando ocorrem normalmente são decididas como parte do planejamento do teste para a situação específica (ver seção 5.1). As seções a seguir descrevem os aspectos gerais desse processo de teste em termos de atividades e tarefas de teste, o impacto do contexto, o material de teste, a rastreabilidade entre a base e o material de teste e as funções de teste. A norma ISO/IEC/IEEE 29119-2 fornece mais informações sobre os processos de teste. 1.4.1 Atividades e Tarefas de Teste Um processo de teste geralmente consiste nos principais grupos de atividades descritos abaixo. Embora muitas dessas atividades possam parecer seguir uma sequência lógica, elas geralmente são implementadas de forma iterativa ou paralela. Essas atividades de teste geralmente precisam ser adaptadas ao sistema e ao projeto. O Planejamento do Teste consiste em definir os objetivos do teste e, em seguida, selecionar uma abordagem que melhor atinja os objetivos dentro das restrições impostas pelo contexto geral. O planejamento de testes é explicado com mais detalhes na seção 5.1. O Monitoramento e Controle de Teste. O monitoramento de teste envolve a verificação contínua de todas as atividades de teste e a comparação do progresso real com o plano. O controle do teste envolve a tomada das ações necessárias para atingir os objetivos do teste. O monitoramento e o controle dos testes são explicados com mais detalhes na seção 5.3. A Análise de Teste inclui a análise da base de teste para identificar os recursos testáveis e definir e priorizar as condições de teste associadas, juntamente com os riscos e níveis de risco relacionados (ver seção 5.2). A base de teste e os objetos de teste também são avaliados para identificar defeitos que possam conter e para avaliar sua testabilidade. A análise do teste geralmente é apoiada pelo uso de técnicas de teste (ver capítulo 4). A análise de teste responde à pergunta "o que testar?" em termos de critérios de cobertura mensuráveis. O Modelagem de Teste inclui a elaboração das condições de teste em casos de teste e outros materiais (p. ex., cartas de teste). Essa atividade geralmente envolve a identificação de itens de cobertura, que servem como guia para especificar as entradas do caso de teste. As técnicas de teste V. 4.0 Página 18 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus (ver capítulo 4) podem ser usadas para apoiar essa atividade. A modelagem de teste também inclui a definição dos requisitos de dados de teste, o projeto do ambiente de teste e a identificação de qualquer outra infraestrutura e ferramenta necessária. A modelagem de teste responde à pergunta "como testar?". A Implementação do Teste inclui a criação ou a aquisição do material de teste necessário para a execução (p. ex., dados de teste). Os casos de teste podem ser organizados em procedimentos de teste e geralmente são reunidos em conjuntos de testes. São criados scripts de teste manuais e automatizados. Os procedimentos de teste são priorizados e organizados em um cronograma de execução de teste para uma execução eficiente do teste (ver seção 5.1.5). O ambiente de teste é criado e verificado quanto à configuração correta. A Execução do Teste inclui a execução dos testes de acordo com o cronograma de execução (“rodar” o teste). A execução do teste pode ser manual ou automatizada. A execução de testes pode assumir várias formas, inclusive testes contínuos ou sessões de testes em pares. Os resultados reais dos testes são comparados com os resultados esperados. Os resultados do teste são registrados. As anomalias são analisadas para identificar suas causas prováveis. Essa análise nos permite relatar as anomalias com base nas falhas observadas (ver seção 5.5). As atividades de Conclusão de Teste geralmente ocorrem nos marcos do projeto (p. ex., lançamento, fim da iteração, conclusão do nível de teste) para quaisquer defeitos não resolvidos, solicitações de alteração ou itens do backlog do produto criados. Qualquer material de teste que possa ser útil no futuro é identificado e arquivado ou entregue às equipes apropriadas. O ambiente de teste é encerrado em um estado acordado. As atividades de teste são analisadas para identificar as lições aprendidas e as melhorias para iterações, versões ou projetos futuros (ver seção 2.1.6). Um relatório de conclusão do teste é criado e comunicado aos stakeholders. 1.4.2 Processo de Teste no Contexto Os testes não são realizados de forma isolada. As atividades de teste são parte integrante dos processos de desenvolvimento executados em uma organização. Os testes são financiados pelos stakeholders e seu objetivo final é ajudar a atender às necessidades de negócio deles. Portanto, a forma como o teste é realizado dependerá de vários fatores contextuais, incluindo: Stakeholders (necessidades, expectativas, requisitos, disposição para cooperar etc.). Membros da equipe (habilidades, conhecimento, nível de experiência, disponibilidade, necessidades de treinamento etc.). Domínio do negócio (criticidade do objeto de teste, riscos identificados, necessidades do mercado, normas legais específicas etc.). Fatores técnicos (tipo de software, arquitetura do produto, tecnologia usada etc.). Restrições do projeto (escopo, tempo, orçamento, recursos etc.). Fatores organizacionais (estrutura organizacional, políticas existentes, práticas utilizadas etc.). Ciclo de vida do desenvolvimento de software (práticas de engenharia, métodos de desenvolvimento etc.). Ferramentas (disponibilidade, usabilidade, conformidade etc.). V. 4.0 Página 19 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Esses fatores terão um impacto em muitas questões relacionadas a testes, incluindo: estratégia de teste, técnicas de teste usadas, grau de automação de teste, nível de cobertura necessária, nível de detalhe da documentação de teste, relatórios etc. 1.4.3 Testware O testware é criado como produto de trabalho de saída das atividades de teste descritas na seção 1.4.1. Há uma variação significativa na forma como as diferentes organizações produzem, moldam, nomeiam, organizam e gerenciam seus produtos de trabalho. O gerenciamento adequado da configuração (ver seção 5.4) garante a consistência e a integridade dos produtos de trabalho. A lista de produtos de trabalho a seguir não é completa: Os produtos de trabalho do planejamento de testes incluem: plano de testes, cronograma de testes, registro de riscos e critérios de entrada e saída (ver seção 5.1). O registro de riscos é uma lista de riscos juntamente com a probabilidade de risco, o impacto do risco e informações sobre a mitigação do risco (ver seção 5.2). O cronograma de testes, o registro de riscos e os critérios de entrada e saída geralmente fazem parte do plano de testes. Os produtos de trabalho do monitoramento e controle de testes incluem: relatórios de progresso de testes (ver seção 5.3.2), documentação de diretrizes de controle (ver seção 5.3) e informações sobre riscos (ver seção 5.2). Os produtos de trabalho da análise de teste incluem: Condições de teste (priorizadas) (p. ex., critérios de aceite, ver seção 4.5.2) e relatórios de defeitos referentes a defeitos na base de teste (se não forem corrigidos diretamente). Os produtos de trabalho da modelagem de teste incluem: Casos de teste (priorizados), cartas de teste, itens de cobertura, requisitos de dados de teste e requisitos de ambiente de teste. Os produtos de trabalho da implementação de teste incluem: procedimentos de teste, scripts de teste automatizados, conjuntos de teste, dados de teste, cronograma de execução de teste e elementos do ambiente de teste. Exemplos de elementos do ambiente de teste incluem: stubs, drivers, simuladores e virtualizações de serviço. Os produtos de trabalho da execução de testes incluem: registros de testes e relatórios de defeitos (ver seção 5.5). Os produtos de trabalho da conclusão do teste incluem: relatório de conclusão do teste (ver seção 5.3.2), itens de ação para melhoria de projetos ou iterações subsequentes, lições aprendidas documentadas e solicitações de alteração (p. ex., como itens do backlog do produto). 1.4.4 Rastreabilidade entre a Base de Teste e o Testware Para implementar o monitoramento e o controle eficazes dos testes, é importante estabelecer e manter a rastreabilidade em todo o processo de teste entre os elementos da base de teste, o testware associado a esses elementos (p. ex., condições de teste, riscos, casos de teste), os resultados dos testes e os defeitos detectados. A rastreabilidade precisa dá suporte à avaliação da cobertura, portanto, é muito útil que os critérios de cobertura mensuráveis sejam definidos na base do teste. Os critérios de cobertura podem V. 4.0 Página 20 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus funcionar como indicadores-chave de performance para conduzir as atividades que mostram até que ponto os objetivos do teste foram alcançados (ver seção 1.1.1). Por exemplo: A rastreabilidade dos casos de teste aos requisitos pode verificar se os requisitos são cobertos pelos casos de teste. A rastreabilidade dos resultados dos testes aos riscos pode ser usada para avaliar o nível de risco residual em um objeto de teste. Além de avaliar a cobertura, uma boa rastreabilidade permite determinar o impacto das mudanças, facilita as auditorias de teste e ajuda a atender os critérios de governança de TI. A boa rastreabilidade também torna o progresso do teste e os relatórios de conclusão mais compreensíveis, incluindo o status dos elementos da base de teste. Isso também pode ajudar a comunicar os aspectos técnicos dos testes aos stakeholders de uma maneira compreensível. A rastreabilidade fornece informações para avaliar a qualidade do produto, a capacidade do processo e o progresso do projeto em relação aos objetivos de negócio. 1.4.5 Papéis no Teste Neste syllabus, são abordadas duas funções principais nos testes: um papel de gerenciamento de testes e um papel de testador. As atividades e tarefas atribuídas a esses dois papéis dependem de fatores como o contexto do projeto e do produto, as habilidades das pessoas que ocupam esses papéis e a organização. O papel de gerenciamento de teste assume a responsabilidade geral pelo processo de teste, pela equipe de teste e pela liderança das atividades de teste. Ela concentra-se principalmente nas atividades de planejamento, monitoramento e controle, e conclusão de testes. A maneira pela qual o papel de gerenciamento de testes é realizado varia de acordo com o contexto. Por exemplo, no desenvolvimento ágil de software, algumas das tarefas de gerenciamento de testes podem ser realizadas pela equipe ágil. As tarefas que abrangem várias equipes ou toda a organização podem ser executadas por gerentes de teste fora da equipe de desenvolvimento. O papel de testador assume a responsabilidade geral pelo aspecto de engenharia (técnico) do teste. Ela concentra-se principalmente nas atividades de análise, modelagem, implementação e execução de teste. Pessoas diferentes podem assumir esses papéis em momentos diferentes. Por exemplo, o papel de gerenciamento de testes pode ser desempenhada por um Líder de Equipe, por um Gerente de Teste, por um Gerente de Desenvolvimento etc. Também é possível que uma pessoa assume o papel de testador e gerenciamento de teste ao mesmo tempo. 1.5 Habilidades essenciais e boas práticas em testes Habilidade é a capacidade de fazer algo bem-feito que vem do conhecimento, da prática e da aptidão de uma pessoa. Os bons Testadores devem ter algumas habilidades essenciais para fazer bem o seu trabalho. Os bons Testadores devem ser participantes eficazes de uma equipe e devem ser capaz de realizar testes em diferentes níveis de independência de teste. V. 4.0 Página 21 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 1.5.1 Habilidades genéricas necessárias para testes Embora sejam genéricas, as habilidades a seguir são particularmente relevantes para os Testadores: Conhecimento sobre testes (para aumentar a eficácia dos testes, por exemplo, usando técnicas de teste) Meticulosidade, cuidado, curiosidade, atenção aos detalhes, ser metódico (para identificar defeitos, especialmente aqueles que são difíceis de encontrar) Boas habilidades de comunicação, ser um bom ouvinte, e trabalhar em equipe (para interagir efetivamente com todos os stakeholders, transmitir informações a outras pessoas, ser compreendido, e relatar e discutir defeitos) Pensamento analítico, pensamento crítico, criatividade (para aumentar a eficácia dos testes) Conhecimento técnico (para aumentar a eficiência dos testes, por exemplo, usando ferramentas de teste adequadas) Conhecimento do domínio (para poder entender e se comunicar com usuários finais/representantes de negócio) Os Testadores geralmente são os portadores de más notícias. É uma característica humana comum culpar o portador pelas más notícias. Isso torna as habilidades de comunicação cruciais para os Testadores. A comunicação dos resultados dos testes pode ser percebida como uma crítica ao produto e ao seu autor. O viés de confirmação pode dificultar o aceite de informações que discordem das crenças atuais. Algumas pessoas podem ver o teste como uma atividade destrutiva, embora ele contribua muito para o sucesso do projeto e a qualidade do produto. Para tentar melhorar essa visão, as informações sobre defeitos e falhas devem ser comunicadas de forma construtiva. 1.5.2 Abordagem de equipe completa Uma das habilidades importantes para um Testador é a capacidade de trabalhar de forma eficaz em um contexto de equipe e de contribuir positivamente para as metas da equipe. A abordagem de equipe completa - uma prática proveniente da Extreme Programming (ver seção 2.1) - baseia-se nessa habilidade. Na abordagem de equipe completa, qualquer membro da equipe com o conhecimento e as habilidades necessárias pode executar qualquer tarefa, e todos são responsáveis pela qualidade. Os membros da equipe compartilham o mesmo espaço de trabalho (físico ou virtual), pois a co- localização facilita a comunicação e a interação. A abordagem de equipe completa melhora a dinâmica da equipe, aprimora a comunicação e a colaboração dentro da equipe e cria sinergia ao permitir que os vários conjuntos de habilidades da equipe sejam aproveitados para o benefício do projeto. Os Testadores trabalham em estreita colaboração com outros membros da equipe para garantir que os níveis de qualidade desejados sejam alcançados. Isso inclui colaborar com representantes do negócio para ajudá-los a criar testes de aceite adequados e trabalhar com desenvolvedores para chegar a um acordo sobre a estratégia de teste e decidir sobre abordagens de automação de teste. Assim, os Testadores podem transferir conhecimento sobre testes para outros membros da equipe e influenciar o desenvolvimento do produto. V. 4.0 Página 22 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Dependendo do contexto, a abordagem de equipe completa nem sempre pode ser adequada. Por exemplo, em algumas situações, como as críticas para a segurança, pode ser necessário um alto nível de independência dos testes. 1.5.3 Independência dos testes Um certo grau de independência torna o Testador mais eficaz na localização de defeitos devido às diferenças entre os vieses cognitivos do autor e do Testador (cf. Salman 1995). No entanto, a independência não substitui a familiaridade, por exemplo, os desenvolvedores podem encontrar com eficiência muitos defeitos em seu próprio código. Os produtos de trabalho podem ser testados por seu autor (sem independência), pelos colegas do autor da mesma equipe (alguma independência), por Testadores de fora da equipe do autor, mas dentro da organização (alta independência) ou por Testadores de fora da organização (independência muito alta). Na maioria dos projetos, geralmente é melhor realizar testes com vários níveis de independência (p. ex., desenvolvedores realizando testes de componentes e de integração de componentes, equipe de testes realizando testes de sistemas e de integração de sistemas e representantes do negócio realizando testes de aceite). O principal benefício da independência dos testes é que os Testadores independentes provavelmente reconhecerão diferentes tipos de falhas e defeitos em comparação com os desenvolvedores, devido às suas diferentes formações, perspectivas técnicas e preconceitos. Além disso, um Testador independente pode verificar, contestar ou refutar as suposições feitas pelos stakeholders durante a especificação e a implementação do sistema. Entretanto, há também algumas desvantagens. Os Testadores independentes podem ficar isolados da equipe de desenvolvimento, o que pode levar à falta de colaboração, a problemas de comunicação ou a uma relação adversa com a equipe de desenvolvimento. Os desenvolvedores podem perder o senso de responsabilidade pela qualidade. Os Testadores independentes podem ser vistos como um gargalo ou ser responsabilizados por atrasos no lançamento. V. 4.0 Página 23 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 2 Testes ao longo do Ciclo de Vida de Desenvolvimento de Software (130 min) Palavras-chave teste de aceite, teste caixa-preta, teste de integração de componentes, teste de componentes, teste de confirmação, teste funcional, teste de integração, teste de manutenção, teste não funcional, teste de regressão, shift-left, teste de integração de sistemas, teste de sistemas, nível de teste, objeto de teste, tipo de teste, teste caixa-branca Objetivos de aprendizagem 2.1 Testes no contexto de um Ciclo de Vida de Desenvolvimento de Software FL-2.1.1 (K2) Explicar o impacto do ciclo de vida de desenvolvimento de software escolhido nos testes. FL-2.1.2 (K1) Relembrar as boas práticas de teste que se aplicam a todos os ciclos de vida de desenvolvimento de software. FL-2.1.3 (K1) Relembrar os exemplos de abordagens de desenvolvimento que priorizam o teste. FL-2.1.4 (K2) Resumir como o DevOps pode ter um impacto nos testes. FL-2.1.5 (K2) Explicar a abordagem shift-left. FL-2.1.6 (K2) Explicar como as retrospectivas podem ser usadas como um mecanismo de melhoria de processos. 2.2 Níveis de Teste e Tipos de Teste FL-2.2.1 (K2) Distinguir os diferentes níveis de teste. FL-2.2.2 (K2) Distinguir os diferentes tipos de teste. FL-2.2.3 (K2) Distinguir o teste de confirmação do teste de regressão. 2.3 Teste de Manutenção FL-2.3.1 (K2) Resumir os testes de manutenção e seus acionadores. V. 4.0 Página 24 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 2.1 Testes no contexto de um Ciclo de Vida de Desenvolvimento de Software Um modelo de ciclo de vida de desenvolvimento de software (SDLC) é uma representação abstrata e de alto nível do processo de desenvolvimento de software. Um modelo SDLC define como as diferentes fases de desenvolvimento e os tipos de atividades realizadas nesse processo se relacionam entre si, tanto lógica quanto cronologicamente. Exemplos de modelos de SDLC incluem: modelos de desenvolvimento sequencial (p. ex., modelo em cascata, modelo em V), modelos de desenvolvimento iterativo (p. ex., modelo em espiral, prototipagem) e modelos de desenvolvimento incremental (p. ex., Processo Unificado). Algumas atividades nos processos de desenvolvimento de software também podem ser descritas por métodos de desenvolvimento de software mais detalhados e práticas ágeis. Os exemplos incluem: desenvolvimento orientado por testes de aceite (ATDD), desenvolvimento orientado pelo comportamento (BDD), domain-driven design (DDD), extreme programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum e desenvolvimento orientado por teste (TDD). 2.1.1 Impacto do Ciclo de Vida de Desenvolvimento de Software nos Testes Para ser bem-sucedido, o teste deve ser adaptado ao SDLC. A escolha do SDLC tem impacto sobre: O escopo e cronograma das atividades de teste (p. ex., níveis de teste e tipos de teste); O nível de detalhamento da documentação de teste; A escolha das técnicas de teste e da abordagem de teste; A extensão da automação de testes; O papel e responsabilidades de um Testador; Nos modelos de desenvolvimento sequencial, nas fases iniciais, os Testadores normalmente participam das revisões de requisitos, da análise de testes e do projeto de testes. O código executável geralmente é criado nas fases posteriores, portanto, os testes dinâmicos não podem ser realizados no início do SDLC. Em alguns modelos de desenvolvimento iterativos e incrementais, supõe-se que cada iteração entregue um protótipo funcional ou um incremento de produto. Isso implica que, em cada iteração, os testes estáticos e dinâmicos podem ser realizados em todos os níveis de teste. A entrega frequente de incrementos exige feedback rápido e testes de regressão extensivos. O Desenvolvimento Ágil de Software pressupõe que podem ocorrer mudanças ao longo do projeto. Portanto, a documentação leve do produto de trabalho e a ampla automação de testes para facilitar os testes de regressão são favorecidas em projetos Ágeis. Além disso, a maior parte dos testes manuais tende a ser feita usando técnicas de teste baseadas na experiência (ver seção 4.4) que não exigem análise e projeto de teste prévio extensivo. 2.1.2 Ciclo de Vida de Desenvolvimento de Software e boas práticas de Teste As boas práticas de teste, independentemente do modelo de SDLC escolhido, incluem: V. 4.0 Página 25 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Para cada atividade de desenvolvimento de software, há uma atividade de teste correspondente, de modo que todas as atividades de desenvolvimento estejam sujeitas ao controle de qualidade; Diferentes níveis de teste (ver seção 2.2.1) têm objetivos de teste específicos e diferentes, o que permite que os testes sejam adequadamente abrangentes, evitando redundância; A análise e a modelagem do teste para um determinado nível de teste começam durante a fase de desenvolvimento correspondente do SDLC, para que o teste possa aderir ao princípio do teste antecipado (ver seção 1.3); Os Testadores estão envolvidos na revisão dos produtos de trabalho assim que os rascunhos dessa documentação estiverem disponíveis, de modo que esse teste antecipado e a detecção de defeitos possam apoiar a estratégia shift-left (ver seção 2.1.5). 2.1.3 Teste como um motivador para o desenvolvimento de software O TDD, ATDD e BDD são abordagens de desenvolvimento semelhantes, em que os testes são definidos como um meio de direcionar o desenvolvimento. Cada uma dessas abordagens implementa o princípio do teste antecipado (ver seção 1.3) e segue uma abordagem shift-left (ver seção 2.1.5), pois os testes são definidos antes de o código ser escrito. Elas dão suporte a um modelo de desenvolvimento iterativo. Essas abordagens são caracterizadas da seguinte forma: Desenvolvimento Orientado por Testes (TDD): Direciona a codificação por meio de casos de teste (em vez de um projeto de software extenso) (Beck 2003); Os testes são escritos primeiro, depois o código é escrito para satisfazer os testes e, em seguida, os testes e o código são refatorados; Desenvolvimento Orientado por Teste de Aceite (ATDD) (ver seção 4.5.3): Deriva testes de critérios de aceite como parte do processo de desenho do sistema (Gärtner 2011); Os testes são escritos antes que a parte do aplicativo relacionada seja desenvolvida para atender aos testes. Desenvolvimento Orientado pelo Comportamento (BDD): Expressa o comportamento desejado de um aplicativo com casos de teste escritos em uma forma simples de linguagem natural, que é fácil de entender pelos stakeholders - geralmente usando o formato Dado/Quando/Então. (Chelimsky 2010); Os casos de teste são então traduzidos automaticamente em testes executáveis. Para todas as abordagens acima, os testes podem persistir como testes automatizados para garantir a qualidade do código em futuras adaptações/refatoração. 2.1.4 DevOps e Testes DevOps é uma abordagem organizacional que visa a criar sinergia, fazendo com que o desenvolvimento (incluindo os testes) e as operações trabalhem juntos para atingir um conjunto de objetivos comuns. O DevOps exige uma mudança cultural em uma organização para preencher as V. 4.0 Página 26 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus lacunas entre o desenvolvimento (incluindo testes) e as operações, tratando suas funções com o mesmo valor. O DevOps promove a autonomia da equipe, feedback rápido, cadeias de ferramentas integradas e práticas técnicas como Integração Contínua (CI Continuous Integration) e Entrega Contínua (CD Continuous Delivery). Isso permite que as equipes criem, testem e liberem códigos de alta qualidade mais rapidamente por meio de um pipeline de entrega de DevOps (Kim 2016). Do ponto de vista dos testes, alguns dos benefícios do DevOps são: Feedback rápido sobre a qualidade do código e se as alterações afetam negativamente o código existente; O CI promove uma abordagem shift-left nos testes (ver seção 2.1.5), incentivando os desenvolvedores a enviar códigos de alta qualidade acompanhados de testes de componentes e análise estática; Promove processos automatizados, como CI/CD, que facilitam o estabelecimento de ambientes de teste estáveis; Aumenta a visão das características de qualidade não funcionais (p. ex., performance, confiabilidade); A automação por meio de um pipeline de entrega reduz a necessidade de testes manuais repetitivos; O risco na regressão é minimizado devido à escala e ao alcance dos testes de regressão automatizados; O DevOps tem seus riscos e desafios, que incluem: O pipeline de entrega de DevOps deve ser definido e estabelecido; As ferramentas de CI/CD devem ser introduzidas e mantidas; A automação de testes requer recursos adicionais e pode ser difícil de estabelecer e manter. Embora o DevOps venha com um alto nível de testes automatizados, os testes manuais - especialmente da perspectiva do usuário - ainda serão necessários. 2.1.5 Abordagem Shift-Left O princípio do teste antecipado (ver seção 1.3) às vezes é chamado de shift-left porque é uma abordagem em que o teste é realizado mais cedo no SDLC. Normalmente, o shift-left sugere que os testes devem ser feitos mais cedo (p. ex., não esperar que o código seja implementado ou que os componentes sejam integrados), mas isso não significa que os testes posteriores no SDLC devam ser negligenciados. Existem algumas boas práticas que ilustram como obter um "shift-left" nos testes, que incluem: Revisão da especificação sob a perspectiva de testes. Essas atividades de revisão das especificações geralmente encontram possíveis defeitos, como ambiguidades, incompletude e inconsistências; Escrever casos de teste antes de o código ser escrito e fazer com que o código seja executado em um conjunto de testes durante a sua implementação; Usar a CI e, melhor ainda, a CD, pois ela vem com feedback rápido e testes de componentes automatizados para acompanhar o código-fonte quando ele é enviado ao repositório de código; V. 4.0 Página 27 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus Concluir a análise estática do código-fonte antes do teste dinâmico ou como parte de um processo automatizado; Realizar testes não funcionais começando no nível de teste do componente, sempre que possível. Essa é uma forma de shift-left, pois esses tipos de testes não funcionais tendem a ser realizados mais tarde no SDLC, quando um sistema completo e um ambiente de teste representativo estão disponíveis. Uma abordagem shift-left pode resultar em treinamento, esforço e/ou custos adicionais no início do processo, mas espera-se que economize esforços e/ou custos no final do processo. Para a abordagem shift-left, é importante que os stakeholders sejam convencidos a aceitarem esse conceito. 2.1.6 Retrospectivas e melhoria de processos As retrospectivas (também conhecidas como "reuniões pós-projeto" e retrospectivas de projeto) geralmente são realizadas no final de um projeto ou de uma iteração, em um marco de lançamento, ou podem ser realizadas quando necessário. O momento e a organização das retrospectivas dependem do modelo específico de SDLC que está sendo seguido. Nessas reuniões, os participantes (não apenas os Testadores, mas também, por exemplo, Desenvolvedores, Arquitetos, Product Owner, Analistas de Negócios) discutem: O que foi bem-sucedido e deve ser mantido? O que não foi bem-sucedido e poderia ser melhorado? Como incorporar as melhorias e manter os sucessos no futuro? Os resultados devem ser registrados e normalmente fazem parte do relatório de conclusão do teste (ver seção 5.3.2). As retrospectivas são essenciais para a implementações bem-sucedidas da melhoria contínua e é importante que todas as melhorias recomendadas sejam acompanhadas. Os típicos benefícios dos testes incluem: Aumento da eficácia/eficiência do teste (p. ex., implementando sugestões de aprimoramento do processo); Aumento da qualidade do material de teste (p. ex., por meio da revisão conjunta dos processos de teste); Vínculo e aprendizado da equipe (p. ex., como resultado da oportunidade de levantar questões e propor pontos de melhoria); Melhoria da qualidade da base de teste (p. ex., como as deficiências na extensão e na qualidade dos requisitos podem ser abordadas e resolvidas); Melhor cooperação entre desenvolvimento e testes (p. ex., como a colaboração é revisada e otimizada regularmente); 2.2 Níveis de Teste e Tipos de Teste Os níveis de teste são grupos de atividades de teste que são organizadas e gerenciadas em conjunto. Cada nível de teste é uma instância do processo de teste, realizado em relação ao software em um V. 4.0 Página 28 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus determinado estágio de desenvolvimento, desde componentes individuais até sistemas completos ou, quando aplicável, sistemas de sistemas. Os níveis de teste estão relacionados a outras atividades dentro do SDLC. Nos modelos sequenciais do SDLC, os níveis de teste são geralmente definidos de forma que os critérios de saída de um nível façam parte dos critérios de entrada do próximo nível. Em alguns modelos iterativos, isso pode não se aplicar. As atividades de desenvolvimento podem se estender por vários níveis de teste. Os níveis de teste podem se sobrepor no tempo. Os tipos de teste são grupos de atividades de teste relacionadas a características de qualidade específicas e a maioria dessas atividades de teste pode ser realizada em todos os níveis de teste. 2.2.1 Níveis de Teste Neste syllabus, são descritos os cinco níveis de teste a seguir: O Teste de Componente (também conhecido como Teste de Unidade) concentra-se em testar componentes isoladamente. Geralmente, requer suporte específico, como estruturas de teste ou frameworks de teste de unidade. Normalmente, os testes de componentes são realizados por desenvolvedores em seus ambientes de desenvolvimento. O Teste de Integração de Componentes (também conhecido como Teste de Integração de Unidades) concentra-se no teste das interfaces e interações entre os componentes. O teste de integração de componentes depende muito das abordagens da estratégia de integração, como bottom-up, top-down ou big-bang. O Teste de Sistema concentra-se no comportamento geral e nos recursos de todo um sistema ou produto, geralmente incluindo o teste funcional de tarefas de ponta a ponta e o teste não funcional de características de qualidade. Para algumas características de qualidade não funcionais, é preferível testá-las em um sistema completo em um ambiente de teste representativo (p. ex., usabilidade). Também é possível usar simulações de subsistemas. O teste do sistema pode ser realizado por uma equipe de teste independente e está relacionado às especificações do sistema. O Teste de Integração de Sistema concentra-se no teste das interfaces do sistema e de outros sistemas e serviços externos. O teste de integração do sistema requer ambientes de teste adequados, de preferência semelhantes ao ambiente operacional. O Teste de Aceite concentra-se na validação e na demonstração da disposição para a implantação, o que significa que o sistema atende às necessidades (requisitos) de negócio do usuário. Preferencialmente, o teste de aceite deve ser realizado pelos usuários previstos. As principais formas de teste de aceite são: Teste de Aceite do Usuário (UAT), Teste de Aceite Operacional, Teste de Aceite Contratual e Normativo, Teste Alfa e Teste Beta. Os níveis de teste são diferenciados pela seguinte lista incompleta de atributos, para evitar a sobreposição de atividades de teste: Objeto de teste; Objetivos do teste; Base de teste; Defeitos e falhas; Abordagem e responsabilidades. V. 4.0 Página 29 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 2.2.2 Tipos de Teste Existem muitos tipos de testes que podem ser aplicados em projetos. Neste programa, são abordados os quatro tipos de teste a seguir: O Teste Funcional avalia as funções que um componente ou sistema deve executar. As funções são "o que" o objeto de teste deve fazer. O principal objetivo do teste funcional é verificar a integridade funcional, a correção funcional e a adequação funcional. O Teste Não Funcional avalia atributos que não sejam características funcionais de um componente ou sistema. O teste não funcional é o teste de "quão bem o sistema se comporta". O principal objetivo do teste não funcional é verificar as características não funcionais da qualidade do software. A norma ISO/IEC 25010 fornece a seguinte classificação das características não funcionais de qualidade do software: Eficiência de Performance; Compatibilidade; Usabilidade; Confiabilidade; Segurança; Capacidade de manutenção; Portabilidade. Às vezes, é apropriado que os testes não funcionais comecem no início do ciclo de vida (p. ex., como parte de revisões e testes de componentes ou testes de sistema). Muitos testes não funcionais são derivados de testes funcionais, pois usam os mesmos testes funcionais, mas verificam se, ao executar a função, uma restrição não funcional é atendida (p. ex., verificar se uma função é executada dentro de um tempo especificado ou se uma função pode ser portada para uma nova plataforma). A descoberta tardia de defeitos não funcionais pode representar uma séria ameaça ao sucesso de um projeto. Às vezes, os testes não funcionais precisam de um ambiente de teste muito específico, como um laboratório de usabilidade para testes de usabilidade. O Teste Caixa-Preta (ver seção 4.2) é baseado em especificações e deriva testes da documentação externa ao objeto de teste. O principal objetivo do teste caixa-preta é verificar o comportamento do sistema em relação às suas especificações. O Teste Caixa-Branca (ver seção 4.3) é baseado na estrutura e deriva testes da implementação ou da estrutura interna do sistema (p. ex., código, arquitetura, fluxos de trabalho e fluxos de dados). O principal objetivo do teste caixa-branca é cobrir a estrutura subjacente pelos testes até o nível aceitável. Todos os quatro tipos de teste mencionados acima podem ser aplicados a todos os níveis de teste, embora o foco seja diferente em cada nível. Diferentes técnicas de teste podem ser usadas para derivar condições de teste e casos de teste para todos os tipos de teste mencionados. V. 4.0 Página 30 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Brazilian Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 2.2.3 Testes de Confirmação e Teste de Regressão Normalmente, as alterações são feitas em um componente ou sistema para aprimorá-lo, adicionando um novo recurso, ou para corrigi-lo, removendo um defeito. Os testes também devem incluir testes de confirmação e testes de regressão. O Teste de Confirmação confirma que um defeito original foi corrigido com sucesso. Dependendo do risco, é possível testar a versão corrigida do software de várias maneiras, inclusive: executando todos os casos de teste que falharam anteriormente devido ao defeito, ou, também, adicionar novos testes para cobrir quaisquer alterações necessárias para corrigir o defeito No entanto, quando há pouco tempo ou dinheiro para corrigir defeitos, o teste de confirmação pode se restringir a simplesmente executar as etapas que devem reproduzir a falha causada pelo defeito e verificar se a falha não ocorre. Os Teste de Regressão confirmam que nenhuma consequência adversa foi causada por uma alteração, inclusive uma correção que já tenha sido confirmada após o teste. Essas consequências adversas podem afetar o mesmo componente em que a alteração foi feita, outros componentes do mesmo sistema ou até mesmo outros sistemas conectados. O teste de regressão pode não se restringir ao objeto de teste em si, mas também pode estar relacionado ao ambiente. É aconselhável realizar primeiro uma análise de impacto para otimizar a extensão do teste de regressão. A análise de impacto mostra quais partes do software podem ser afetadas. Os conjuntos de testes de regressão são executados muitas vezes e, em geral, o número de casos de teste de regressão aumentará a cada iteração ou versão, portanto, os testes de regressão são fortes candidatos à automação. A automação desses testes deve começar no início do projeto. Quando a CI é usada, como no DevOps (ver seção 2.1.4), é uma boa prática incluir também testes de regressão automatizados. Dependendo da situação, isso pode incluir testes de regressão em diferentes níveis. Testes de confirmação e/ou testes de regressão para o objeto de teste são necessários em todos os níveis de teste se os defeitos forem corrigidos e/ou se forem feitas alterações nesses níveis de teste. 2.3 Teste de Manutenção Há diferentes categorias de manutenção, que podem ser corretivas, adaptáveis a mudanças no ambiente ou melhorar a performance ou a capacidade de manutenção (ver ISO/IEC 14764 para mais detalhes), portanto, a manutenção pode envolver versõ

Certificação de Testador CTFL 4.0 - PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue