CTFL-AT - Simulado

1 - III , 2 - IV, 3 - II, 4 - I

1 - III 2 - II, 3 - I, 4 - IV

1 - IV, 2 - II, 3 - I, 4 - III

1 - II, 2 - III, 3 - IV, 4 – I

Um software funcionando permite que o cliente forneça feedback rápido à equipe de desenvolvimento.

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

Representantes de negócios devem fornecer um backlog de estorias de usuários e suas estimativas para a equipe.

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

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

Tarefas de automação de teste agora são de responsabilidade da equipe de desenvolvimento em vez 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 em projetos de desenvolvimento de software como o waterfall.

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

É fácil determinar o desenvolvedor que apresenta a maioria dos defeitos ao integrar o código.

Há tempo suficiente para concluir todos os recursos programados para a iteração especificada.

1-I, 2-III, 3-II

1-I, 2-II, 3-III

1-II, 2-I, 3-III

1-III, 2-II, 3-I

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

O testador informa que a usabilidade é mais importante que o desempenho.

O testador informa que os critérios de aceitação de desempenho devem ter um padrão máximo de 1 segundo para armazenamento de dados.

O testador informa que a estória do usuário precisa de critérios de aceitação para ser testável.

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

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

Como um testador participando de uma reunião retrospectiva, eu devo fornecer feedback e comentários sobre todas as atividades conduzidas pela equipe durante o sprint.

Como testador, eu só devo participar de uma reunião retrospectiva se eu tiver algum feedback e comentários relacionados às atividades conduzidas pela equipe durante o sprint.

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

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

O testador XYZ está tendo dificuldades para encontrar defeitos. O treinamento é necessário para este recurso.

Os conjuntos de testes de regressão automatizados 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 modificado regularmente, incluindo testes e implantação, de forma automatizada.

A integração contínua permite que novas construções sejam disponibilizadas frequentemente para testadores e interessados.

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

A integração contínua garante que o teste de unidade seja feito manualmente, pois isso gera resultados mais confiáveis do que os scripts automatizados.

Produzir uma lista de testes de aceitação para estórias de usuários.

Ajudar a detalhar as estórias do usuário em tarefas menores e mais detalhadas.

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

Apoiar o esclarecimento das estórias do usuário e garantir que elas sejam testáveis.

Um artefato que o testador deve revisar e assinar antes do teste pode começar.

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

Um artefato documentado por representantes de empresas para ajudar desenvolvedores e testadores compreender os requisitos do sistema.

Um artefato escrito colaborativamente por desenvolvedores, testadores e representantes de negócios para captura de requisitos.

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 usados para verificar a implementação dos requisitos.

Os testadores realizam testes exploratórios para encontrar rapidamente defeitos importantes.

Os testadores colaboram com os desenvolvedores para entender melhor o que precisa ser testado.

II apenas

Ie II

II e III

III apenas

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

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

Testes independentes podem ser introduzidos no final de um sprint.

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

Nenhum defeito de gravidade 1 ou 2 foi detectado durante o teste 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 do software da iteração 6 indicam que o sistema funciona corretamente e que melhorou a produtividade.

A equipe ágil tem acompanhado com sucesso as estimativas, com variância limitada nos gráficos de burndown de todas as iterações até o momento.

Todos os cards de estória no escopo de cada iteração, até a iteração atual, foram marcados como "Concluídos", mas com alguma dívida técnica incorrida.

Gráficos Burndown.

Logs de automação.

O quadro de tarefas ágil mostrando a estória do usuário e o progresso da tarefa.

Ferramentas de rastreamento de defeitos.

Revise e atualize todos os testes manuais e automatizados afetados por essa mudança para atender aos novos critérios de aceitação.

Escreva novos testes manuais e automatizados para o recurso e adicione-os ao conjunto de testes de regressão.

Automatize todos os casos de teste da iteração anterior e adicione-os ao conjunto de testes de regressão automatizada.

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

I e IV

I e V

III e IV

II e V

I e III

II e V

IV e V

II e III

Automatizar testes e mantê-los.

Orientar e treinar outros membros da equipe.

Produzir e atualizar gráficos burndown.

Participar de atividades de análise de código.

I e III

II e III

II e IV

II e V

Um gráfico mostrando quais membros da equipe estão trabalhando mais e provavelmente estarão sob estresse.

Um gráfico mostrando o progresso de cada estória do usuário e quando elas provavelmente serão concluídas.

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

Um gráfico mostrando os defeitos que foram corrigidos e quando os defeitos remanescentes provavelmente serão corrigidos.

TDD é uma abordagem de “teste primeiro” para desenvolver testes automatizados reutilizáveis.

O ciclo TDD é usado continuamente até que o produto de software seja liberado.

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

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

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

Dependendo do tamanho d backlog os testes diminuem.

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

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

Ao comunicar ideias de teste, o testador pode se referir ao quadrante de teste correspondente, para que o restante da equipe possa entender melhor a finalidade do teste

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

A equipe deve escolher uma série 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 tenham sido executados.

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

Q1 que é o nível da unidade, voltado para tecnologia. Q2 é o nível do sistema, voltado para negócios, e confirma o comportamento do produto.

Q2 é o nível do sistema, voltado para negócios, e confirma o comportamento do produto. Q3 que é o nível de aceite do sistema ou do usuário, voltado para o negócio.

Q3 que é o nível de aceite do sistema ou do usuário, voltado para o negócio. Q4 que é o nível de aceite operacional ou do sistema, orientado para tecnologia, e contém testes que criticam o produto.

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

O testador notificará a equipe sobre o problema. Uma análise de risco é feita e a equipe decide que o teste de regressão deve ser executado no novo tipo de navegador, além dos outros navegadores suportados. O testador atualizará o plano da 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 tenha sido encontrado em outros navegadores suportados. O testador continua com o plano de sprint existente e não faz alterações na estrutura de automação de teste ou scripts.

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

Como as estimativas de tamanho do cliente e do desenvolvedor correspondem, a equipe pode ter certeza de que essa estimativa é boa e deve passar para a próxima estória do usuário.

A equipe deve conversar para entender por que os testadores acharam que essa estória de usuário era significativamente mais trabalhosa. Outra rodada da sessão de planning poker deve ocorrer após essa discussão.

Como o cliente possui o sistema no final, as estimativas dos clientes devem ser consideradas corretas quando há um conflito.

As sessões de planning poker devem continuar até que todos os pontos da estória estimados sejam uma correspondência exata entre clientes, desenvolvedores e testadores.

I, II, III e IV

II, IV e V

I, II e V

Todos os itens.

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 / sprint está terminada.

I, II e IV

I, III e IV

II, IV e V

II, III e IV

Teste de Transição de Estado: Teste os seguintes estados - navegando, conectado, selecionando, comprando, confirmando e saindo.

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

Análise de Valores Limite: Teste as seguintes entradas - 0,5,6,10,11, max

Teste de Caso de Uso: Ator = cliente; Pré-requisitos = o cliente efetua login, seleciona e compra itens; Pós Condições = itens são enviados.

Cenário I NÃO é a melhor maneira porque: Em testes exploratórios, o projeto de teste e a execução de testes acontecem ao mesmo tempo, mas são guiados por um documento documentado que inclui agentes, condições de teste, dados de teste, etc. e guiará o próximo teste.

Cenário II É a melhor maneira porque: Neste caso, os testadores já têm conhecimento da estória do usuário, o que os ajudará a criar condições e idéias de teste. A equipe está usando sessões de teste exploratórias com timebox. Espera-se que a equipe documente condições de teste, dados e
informações do usuário e para registrar os resultados do teste. Os problemas são registrados em uma ferramenta de rastreamento de defeitos como qualquer outra técnica de teste.

Cenário III NÃO é a melhor maneira porque: Isso pode estar escrevendo o teste de aceitação do sistema, mas não o teste exploratório.

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

Uma ferramenta ALM permite que as equipes criem uma base de conhecimento sobre ferramentas e técnicas para atividades de desenvolvimento e teste.

Uma ferramenta ALM fornece uma resposta rápida sobre a qualidade de construção e detalhes sobre alterações de código.

Uma ferramenta ALM fornece visibilidade do estado atual do aplicativo, especialmente com equipes distribuídas.

Uma ferramenta ALM gera e carrega grandes volumes e combinações de dados para usar no teste.

O teste exploratório abrange aprendizado simultâneo, projeto de teste e execução.

O teste exploratório elimina a necessidade de os testadores prepararem ideias de teste antes da execução do teste.

Os melhores resultados são obtidos quando o teste exploratório é combinado com outras técnicas de teste.

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