SIMULADO CTFL AT 2022

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

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

Os desenvolvedores devem usar ferramentas de teste de unidade para apoiar o processo de teste .

Os representantes comerciais devem fornecer uma lista de pendências de estórias de usuários e suas estimativas para a equipe.

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

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 tradicionais de desenvolvimento de software, como o Cascata (Waterfall).

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

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

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

1-i, 2-iii, 3-ii

1-i, 2-ii, 3-iii

1-iii, 2-i, 3-ii

1-iii, 2-ii, 3-i

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

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

O testador aconselha que os critérios de aceitação de desempenho devem padronizar no máximo 1 segundo para armazenamento de dados.

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

Como testador participando de uma reunião retrospectiva, devo trazer tópicos relacionados apenas ao teste. Todos os outros tópicos serão abordados por diferentes participantes.

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

Como testador participando 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 participar de uma reunião retrospectiva se tiver algum feedback e contribuição relacionada às atividades conduzidas pela equipe durante o sprint.

Deveria haver mais ênfase nos testes de unidade no futuro, para melhorar a qualidade geral.

O processo de criaçã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. O treinamento de design de teste é necessário para este recurso.

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

A integração contínua ajuda a criar software alterado regularmente, incluindo teste e implantação, de maneira automatizada.

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

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 compilações seja feito manualmente, pois isso gera resultados mais confiáveis do que scripts automatizados.

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

Ajude a dividir as estórias do usuário em tarefas menores e mais detalhadas

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

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

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

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

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

Um artefato escrito em colaboração por desenvolvedores, testadores e representantes de negócios para capturar 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 teste automatizados que são usados 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.

II apenas

I e II

II e III

III apenas

Pode haver um risco de perder a independência dos testes para as organizações que apresentam o método ágil.

Testadores independentes encontrarão mais defeitos que 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 6 do software da iteração indicam que o sistema funciona corretamente e que aumentou a produtividade.

A equipe ágil tem rastreado com êxito as estimativas, com variação limitada exibida nos gráficos de burn down para todas as iterações até o momento.

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

Gráficos de burn down

Logs de automação

O painel 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 alteração 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 inclua-os no conjunto de testes de regressão automatizado.

Aumente a quantidade de automação de teste em todo o 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

i e iii

ii e iii

ii e iv

ii e v

Automatizar testes e mantê-los

Para orientar e treinar outros membros da equipe

Produzir e atualizar gráficos de burn down

Participar de atividades de análise de código

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

Um gráfico mostrando o progresso de cada estória de usuário e quando é provável que seja concluída

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

Um gráfico mostrando os defeitos que foram corrigidos e quando é provável que os defeitos restantes sejam corrigidos

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

O ciclo TDD é usado continuamente até o lançamento do produto de software

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 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 de unidade 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 consultar o quadrante de teste correspondente, para que o restante da equipe entenda melhor o objetivo do teste.

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

A equipe deve escolher uma série de testes esperados para 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 nível de unidade, voltado para tecnologia & Q2 nível de sistema, voltado para negócios

Q2 nível de sistema, voltado para negócios & Q3 nível de aceitação do usuário ou sistema, voltado para negócios

Q3 nível de sistema ou de aceitação do usuário, voltado para o negócio & Q4 nível de aceitação de operação ou sistema, voltado para tecnologia

Q2 nível do sistema, voltado para negócios & Q4 nível de aceitação operacional do sistema, voltado para tecnologia

O testador deve notificar a equipe que está planejando trabalhar horas extras nos próximos 2 sprints para atualizar a estrutura e os scripts de automação de teste existentes para dar suporte ao novo tipo de navegador, a fim de não atrapalhar 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 de sprint adicionando tarefas para modificar a estrutura e os scripts para dar suporte ao novo tipo de navegador.

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

O testador interrompe o que está fazendo, cria testes específicos para testes de compatibilidade do novo tipo de navegador e comunica à 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 coincidem, 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 manter uma conversa 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 é o proprietário do sistema no final, as estimativas dos clientes devem ser consideradas corretas quando houver um conflito.

As sessões de planejamento de pôquer devem continuar até que todos os pontos da estória estimados correspondam exatamente aos clientes, desenvolvedores e testadores.

i, ii, iii, iv

ii, iv, v

i, ii, v

Todas as opções acima

Todos os casos de teste foram executados

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

A cobertura de teste obtida é 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á concluída

i, ii, iv

i, iii, iv

ii, iv, v

ii, iii, 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 – Enviar item.

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

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

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

O cenário ii É o melhor caminho, pois: Nesse caso, os testadores já têm conhecimento da estória do usuário, o que os ajudará a apresentar condições e ideias de teste. A equipe está usando sessões de teste exploratório com time-box. A equipe deve documentar as condições do teste, dados e informações do usuário e registrar os resultados do teste. Os problemas são registrados em uma ferramenta de rastreamento de defeitos, como qualquer outra técnica de teste.

O cenário iii NÃO é o melhor caminho porque: Isso pode estar descrevendo o teste de aceitação do sistema, mas não o teste exploratório.

Cenário iv NÃO É o melhor caminho, porque: É necessária documentação para testes exploratórios, e os testadores devem registrar ideias e resultados dos testes. Os resultados dos testes são usados para orientar futuros testes exploratórios.

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

Uma ferramenta ALM fornece resposta rápida sobre a qualidade da compilaçã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 nos testes

O teste exploratório abrange aprendizado simultâneo, design 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 alcançados quando o teste exploratório é combinado com outras estratégias de teste.

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