Syllabus 23.pdf

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, inclusi...

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 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 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 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). 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 V. 4.0 Página 17 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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 de teste (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 (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 V. 4.0 Página 18 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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 também são financiados pelos stakeholders e seu objetivo final é ajudar a atender às necessidades de negócio dos stakeholders. 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.). 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ário, nível de detalhe da documentação de teste, relatórios etc. V. 4.0 Página 19 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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 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. V. 4.0 Página 20 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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. 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) V. 4.0 Página 21 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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 toda a equipe 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 toda a equipe - uma prática proveniente da Programação Extrema (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 inteira 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. Dependendo do contexto, a abordagem de equipe inteira 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 V. 4.0 Página 22 de 77 21 de abril 2023 ©International Software Testing Qualifications Board Certified Tester Foundation Level Syllabus 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