Simulado CTFL-AT-Agile Tester BSTQB[v1.2br]- 40 questões.

1c, 2d, 3b, 4a

1c, 2b, 3a, 4d

1d, 2b, 3a, 4c

1b, 2c, 3d, 4a

O software de trabalho permite que o cliente forneça feedback rápido ao desenvolvedor.

Os desenvolvedores devem usar ferramentas de teste unitário para apoiar o processo de teste.

Os representantes comerciais devem fornecer um backlog de histórias de usuários e suas estimativas para a equipe.

A adoção de planos de mudança não agrega nenhum valor real a um projeto ágil.

As empresas não precisam mais recrutar e treinar especialistas em testes de software.

As tarefas de automação de testes são agora da responsabilidade da equipe de desenvolvimento, ao invés da equipe de testes.

As barreiras de papel são eliminadas e os membros da equipe contribuem para o sucesso do projeto com base em suas habilidades e perspectivas únicas.

Os custos do projeto são menores porque a necessidade de uma equipe de teste especializada é eliminada.

1 e 4

2 e 3

2 e 4

1 e 3

O número total de defeitos encontrados durante o projeto é muito maior do que nos projetos tradicionais de desenvolvimento de software, tais como a queda d'água.

Há menos retrabalho porque os clientes veem o produto regularmente.

É fácil determinar o desenvolvedor que introduz mais defeitos ao integrar o código.

Há tempo suficiente para completar todas as características programadas para a iteração em questão.

1a, 2c, 3b

1a, 2b, 3c

1b, 2c, 3b

1c, 2b, 3a

O testador avisa que a tela da história do usuário precisa ser uma única página para reduzir o esforço de automatização do teste.

O testador aconselha que a usabilidade é mais importante do que o desempenho.

O testador aconselha que o critério de aceite de desempenho deve ser o padrão máximo de 1 segundo para armazenamento de dados.

O testador aconselha que a história do usuário precisa de critérios de aceite para poder ser testada.

Como um testador participando de uma reunião retrospectiva, eu deveria trazer tópicos que estão relacionados apenas a testes. Todos os outros tópicos serão abordados por diferentes participantes.

Como um testador, participo de uma reunião retrospectiva como observador, assegurando que a reunião siga as regras retrospectivas e os valores ágeis.

Como testador, participo de uma reunião retrospectiva, devo fornecer feedback e sugestões sobre todas as atividades conduzidas pela equipe durante o sprint.

Como testador, só devo assistir e participar de uma reunião retrospectiva se eu tiver qualquer feedback e contribuição relacionados às atividades conduzidas pela equipe durante o sprint.

Deve haver mais ênfase em testes unitários no futuro, para melhorar a qualidade geral.

O processo de construção é manual e leva muito tempo. A pesquisa e a implementação de uma estrutura de construção automatizada devem ser feitas.

O Testador XYZ está lutando para encontrar defeitos. É necessário treinamento de projeto de teste para este recurso.

Os conjuntos de testes de regressão automatizada estão demorando muito para serem executados. Uma revisão dos testes, para eliminar testes redundantes ou desnecessários, é necessária.

A integração contínua ajuda a construir software alterado regularmente, incluindo testes e implantação, de forma automatizada.

A integração contínua permite que novas construções estejam disponíveis com frequência para os testadores e partes interessadas.

A integração contínua ajuda a identificar novos defeitos de integração antecipadamente e torna a análise desses defeitos mais fácil.

A integração contínua garante que os testes de builds sejam feitos manualmente, pois isso gera resultados mais confiáveis do que os scripts automatizados.

Produzir uma lista de testes de aceite para histórias de usuários.

Ajuda a decompor as histórias dos usuários em tarefas menores e mais detalhadas.

Estimar tarefas de teste geradas por novos recursos planejados para esta iteração.

Apoiar o esclarecimento das histórias de usuários e garantir que elas sejam testáveis.

Um artefato que o testador deve rever e assinar antes do início dos testes.

Um artefato usado para detalhar apenas os requisitos funcionais do sistema.

Um artefato documentado por representantes comerciais para ajudar os desenvolvedores e testadores a entender os requisitos do sistema.

Um artefato escrito colaborativamente por desenvolvedores, testadores e representantes comerciais para capturar as exigências.

Os testadores escrevem planos de teste detalhados para que todos os membros da equipe possam entender o que será testado durante cada iteração.

Os testadores estão fortemente envolvidos na criação de casos de testes automatizados que são então utilizados para verificar a implementação dos requisitos.

Os testadores decidem os critérios de entrada e saída para cada nível de teste.

Os testadores estão envolvidos no desenvolvimento para entender melhor o que precisa ser testado.

2

1, 2

2, 3

3

Pode haver o risco de perder a independência dos testes para organizações que introduzem o ágil.

Os testadores independentes encontrarão mais defeitos que desenvolvedores, independentemente do nível de teste.

Os testes independentes podem ser introduzidos ao final de um sprint.

A equipe de teste independente pode fazer parte de outra equipe.

Não foram detectados defeitos de gravidade 1 ou 2 durante os testes do sistema da iteração 6, o que permitiu que as equipes passassem para a iteração 7.

Os resultados de um teste beta do cliente na versão de software da iteração 6 indicam que o sistema funciona corretamente e que melhorou a produtividade.

A equipe ágil tem rastreado com sucesso as estimativas, com variações limitadas mostradas nos gráficos queimados para todas as iterações até o momento.

Todos os cartões de histórias no escopo de cada iteração, até a iteração atual, foram marcados como "Feito", mas com alguma dívida técnica sendo incorrida.

Gráficos queimados

Registros de automação

O ágil quadro de tarefas mostrando a história do usuário e o progresso das tarefas

Ferramentas de rastreamento de defeitos

Rever e atualizar todos os testes manuais e automatizados impactados por esta mudança para atender aos novos critérios de aceite.

Escrever novos testes manuais e automatizados para o recurso e adicioná-los ao conjunto de testes de regressão.

Automatizar todos os casos de teste da iteração anterior e adicioná-los à suíte de testes de regressão automatizada.

Aumentar a quantidade de automação de testes ao redor do sistema para incluir condições de teste mais detalhadas.

1, 4

1, 5

3, 5

2, 5

1, 3

2, 5

4, 5

2, 3

1, 3

2, 3

2, 4

2, 5

Automatizar os testes e mantê-los

Para orientar e treinar outros membros da equipe

Produzir e atualizar gráficos queimados

Participar das atividades de análise de código

Um gráfico mostrando quais membros da equipe estão trabalhando mais, e é provável que estejam sob estresse

Um gráfico mostrando o progresso de cada história de usuário, e quando é provável que elas sejam completadas

Um gráfico mostrando a quantidade de trabalho restante a ser feito, versus o tempo alocado para a iteração

Um gráfico mostrando os defeitos corrigidos, e quando os defeitos restantes são susceptíveis de serem corrigidos

TDD é uma abordagem de "teste primeiro" para desenvolver testes automatizados reutilizáveis

O ciclo TDD é utilizado continuamente até que o produto de software seja lançado

TDD ajuda a documentar o código para futuros esforços de manutenção

O resultado do TDD são classes de teste utilizadas pelo desenvolvedor para desenvolver casos de teste

A carga de trabalho de teste da equipe aumenta de sprint para sprint.

O tamanho do backlog e, portanto, o número de testes, diminui

O número de testes unitários automatizados é maior do que o número de testes automatizados para níveis de teste mais elevados.

O número de testes automatizados em vigor aumenta de sprint para sprint

Ao comunicar as ideias do teste, o testador pode se referir ao quadrante de teste correspondente, para que o resto da equipe entenda melhor o propósito do teste.

O testador pode usar os tipos de testes descritos nos quadrantes de teste como uma métrica de cobertura, quanto mais testes forem cobertos de cada quadrante, maior será a cobertura do teste.

A equipe deve escolher um número de testes esperados de cada quadrante, e o testador deve projetar e executar esses testes para garantir que todos os níveis e tipos de testes foram executados.

O testador pode usar os quadrantes de teste durante a análise de risco; os quadrantes de nível inferior representam menor risco para o cliente.

Q1: nível de unidade, sobre tecnologia; Q2: nível de sistema sobre negócios

Q2: nível do sistema, nível de aceite do sistema ou do usuário; Q3: nível de aceite do sistema ou do usuário, nível de
aceite do negócio

Q3: nível de aceite do sistema ou do usuário, sobre negócio; Q4: nível de aceite do sistema ou da operação, sobre
tecnologia

Q2: nível do sistema, sobre negócios; Q4: nível de aceite do sistema ou operação, sobre tecnologia

O testador deve notificar a equipe que está planejando trabalhar horas extras durante os próximos 2 sprints a fim de atualizar a estrutura de automação de testes e os scripts existentes para suportar o novo tipo de navegador de modo
a não perturbar o plano de sprint existente.

O testador notificará a equipe sobre a questão. Uma análise de risco é feita e a equipe decide que o teste de regressão deve ser realizado no novo tipo de navegador, além dos outros navegadores suportados. O testador atualizará o plano de sprint adicionando tarefas para modificar a estrutura e os scripts para suportar o novo tipo de navegador.

O testador faz algumas pesquisas e conclui que o risco é baixo de que quaisquer novos defeitos sejam introduzidos no novo tipo de navegador que ainda não tenham sido encontrados em outros navegadores suportados. O testador continua com o plano de sprint existente e não faz nenhuma alteração na estrutura ou nos scripts de automação de testes.

O testador interromperá o que está fazendo, projetará testes específicos para testar a compatibilidade do novo tipo de navegador e comunicará à equipe que qualquer outro trabalho de teste para o sprint terá que ser empurrado para
a próxima iteração.

Como as estimativas de tamanho do cliente e do desenvolvedor coincidem, a equipe pode estar confiante de que esta estimativa é boa e deve passar para a próxima história do usuário.

A equipe deve manter uma conversa para entender por que os testadores acharam que esta história de usuário foi significativamente mais trabalhosa. Outra rodada do planejamento da sessão de pôquer deve ocorrer após essa
discussão.

Como o cliente é o proprietário do sistema no final, as estimativas dos clientes devem ser consideradas corretas quando houver um conflito.

As sessões de planejamento do pôquer devem continuar até que todos os pontos estimados da história sejam uma correspondência exata entre clientes, desenvolvedores e testadores.

1, 2, 3, 4

2, 4, 5

1, 2, 5

Todos os itens acima

Todos os casos de teste foram executados

A probabilidade de falhas remanescentes foi reduzida a um nível que pode ser aceito pelo cliente

A cobertura de teste alcançada é considerada suficiente. O limite de cobertura é justificado pela complexidade da
funcionalidade incluída, sua implementação e os riscos envolvidos.

A iteração/impressão está terminada

1, 2, 4

1, 3, 4

2, 4, 5

2, 3, 4

Teste de transição de estado: Teste os seguintes estados - navegação, login, seleção, compra, confirmação e saída.

Tabelas de decisão: Testar as seguintes condições - Usuário logado; Pelo menos 1 item no carrinho; Compra
confirmada; Financiamento aprovado; com a ação resultante de - Enviar item.

Análise do valor limite: Testar as seguintes entradas - 0, 5, 6, 10, 11, máximo

Teste de caso de uso: Ator=cliente; Pré-requisitos=cliente faz login, seleciona e compra itens; Condições postais=
itens são enviados

Cenário 1 NÃO É o melhor caminho porque: Nos testes exploratórios, o projeto e a execução dos testes acontecem ao
mesmo tempo, mas são guiados por uma carta de teste documentada que inclui atores, condições de teste, dados de
teste etc. Os resultados dos testes também são documentados e orientarão o próximo teste.

O Cenário 2 é o melhor caminho porque: Neste caso, os testadores já têm conhecimento da história do usuário, o que
os ajudará a apresentar as condições e ideias do teste. A equipe está usando sessões programas de teste exploratório.
Espera-se que a equipe documente as condições do teste, dados e informações do usuário, e que registre os
resultados do teste. As questões são registradas em uma ferramenta de rastreamento de defeitos, como qualquer
outra técnica de teste.

O Cenário 3 NÃO É a melhor maneira porque: Isto poderia estar descrevendo testes de aceite do sistema, mas não
testes exploratórios.

O Cenário 4 NÃO É a melhor maneira porque: A documentação é necessária para testes exploratórios, e os testadores
devem registrar as ideias de teste e os resultados dos testes. Os resultados dos testes são usados para orientar futuros
testes exploratórios.

Permite às equipes construir uma base de conhecimento sobre ferramentas e técnicas para atividades de desenvolvimento e testes

Fornece uma resposta rápida sobre a qualidade de construção e detalhes sobre mudanças de código

Dá visibilidade ao estado atual da aplicação, especialmente com equipes distribuídas

Gera e carrega grandes volumes e combinações de dados a serem usados para testes

Os testes exploratórios englobam aprendizagem simultânea, projeto e execução de testes.

Os testes exploratórios eliminam a necessidade de os testadores prepararem ideias de teste antes da execução do teste.

Os melhores resultados são alcançados quando os testes exploratórios são combinados com outras estratégias de teste.

Os testadores exploratórios precisam ter uma compreensão sólida do sistema em teste.