Um conjunto de valores de entrada, pré-condições de execução, resultados esperados e pós-condições de execução.

Uma abordagem ao teste na qual casos de teste são projetados baseados em objetivos de teste e condições de teste derivadas dos requisitos.

Um item ou evento de um componente ou sistema que poderia ser verificado por um ou mais casos de teste.

Uma condição ou capacidade necessária para um usuário resolver um problema ou atingir um objetivo que precisa ser encontrado ou possuído por um sistema ou componente do sistema para satisfazer um contrato, norma, especificação, ou outro documento imposto formalmente.

I e II.

I e III.

I, II e III.

II e III.

Especificação de modelagem de alto nível

Especificação de modelagem de baixo nível

Especificação de requisitos

Relatórios de defeitos a partir de versões anteriores

Um projeto piloto de uma ferramenta de automação pode ser considerado para que se possa aprender mais sobre a ferramenta e sobre como utilizá-la.

O monitoramento do uso e dos benefícios das ferramentas de automação permite uma avaliação tanto da sua eficácia quanto da sua eficiência.

Ferramentas de automação podem ser introduzidas quando não existe um processo definido para a execução dos testes. Neste caso, a introdução da ferramenta garante que as atividades sejam realizadas de forma padronizada e controlada, pois um dos objetivos das ferramentas de automação é definir um processo de trabalho.

O processo de teste pode sofrer adaptações ou melhorias após a inclusão de uma ferramenta de automação.

Estabelecer responsabilidades para as metas.

Determinar as metas de um projeto.

Criar métricas relativas às questões de risco de um projeto.

Desenvolvimento de perguntas sobre as metas.

Uma abordagem inteiramente bottom-up.

Primeiramente uma abordagem baseada na experiência, acrescida de uma abordagem baseada na métrica.

Uma abordagem simultânea baseada na experiência e baseada na métrica.

Primeiramente uma abordagem baseada na métrica, acrescida de uma abordagem baseada na experiência.

Critérios de suspensão/retorno.

Passos do procedimento.

Requisitos especiais de procedimento.

Funcionalidades a serem testadas.

Implementar a política de teste e ou estratégia de teste.

Determinar o escopo e riscos, e identificar os objetivos do teste.

Programar a implementação, execução e avaliação.

Avaliar a testabilidade dos requisitos e do sistema.

1,0; 20;0

0,0; 0,1; 20,0; 20,1

0,0; 0,9; 1,0; 15,0; 20,0; 20,1; 25,0

0,9; 1,0; 20,0; 20,1

Cronograma curto

Vários níveis de integração

Homogeneidade do processo

Desenvolvimento pequeno e equipes de teste

Encontrar novos bugs através da repetição dos mesmos testes.

Medir a qualidade do software em termos de defeitos encontrados.

Eliminar a possibilidade de que não há defeitos remanescentes não descobertos.

Encontrar, analisar, e remover as causas das falhas.

Todas as cinco estratégias de teste, I, II, III, IV, e V, são inerentemente estratégias preventivas.

Somente V é inerentemente reativa.

III, IV, V são inerentemente reativas.

Todas as cinco estratégias de teste, I, II, III, IV, e V, são inerentemente estratégias reativas.

Escrever um plano de teste

Escrever um relatório de resumo do teste

Escrever um relatório de incidentes

Escrever uma log de teste

Teste de Componente.

Teste de Performance.

Teste de Sistema.

Teste de Aceite.

Elaborar um relatório com base nas informações obtidas durante o teste.

Medir a performance dos componentes e dos sistemas.

Decidir o que pode ser automatizado, em que grau se dará a automatização e como os testes serão automatizados.

Preparar o gerenciamento de configuração do testware para facilitar a rastreabilidade.

Testadores independentes vêem outros e diferentes defeitos, e são imparciais.

O time de teste é visto como responsável pelos atrasos.

O time de teste é isolado do resto do time de projeto.

Testadores independentes podem verificar suposições que outras pessoas fizeram.

Bug clustering

Momento de envolvimento

Análise e modelagem

Planejamento, preparação e execução

-0,01; 0,00; 0,01; 25,00; 49,99; 50,00; 50,01; 75,00

0,00; 20,0; 60,00

0,00; 0,01; 50,00

0,00; 0,01; 50,00; 70,00

Custo estimado para encontrar o próximo defeito.

Taxas de descoberta/correção de defeitos.

Segurança subjetiva dos testadores no produto.

Status do caso de teste.

Planejamento e controle do teste.

Implementação e execução de teste.

Avaliação do critério de saída e relatório.

Atividades de encerramento de teste.

Defeitos em interfaces entre componentes ou interações com diferentes partes de um sistema.

Níveis de teste de integração não focam na identificação de defeitos.

Defeitos em módulos ou objetos que são testáveis separadamente.

Defeitos no sistema ou produto completo.

Todos são objetivos comuns de teste.

I, II, III e V são objetivos comuns de teste.

II e V são objetivos comuns de teste;

I, III, IV, e V são objetivos comuns de teste.

Prover uma forma de avaliar a confiança sobre o nível de qualidade do sistema.

Apoiar a gerência no entendimento da qualidade do sistema.

Prover informações sobre os aspectos mais importantes de qualidade do sistema que está sendo testado.

Corrigir defeitos encontrados e registrados em um relatório de bugs.

A motivação de encontrar mais defeitos, que foi considerada pela diretoria da empresa, não corresponde a um ganho real da equipe independente de testes quando comparada com uma equipe de testes como recurso do projeto.

Uma equipe de testes independente pode encontrar mais defeitos do que uma equipe de teste constituída por colaboradores internos do projeto, tendo em vista a imparcialidade inerente deste tipo de organização e a possibilidade de enxergar defeitos diferentes. No entanto, cuidados devem ser tomados como, por exemplo, atenção para que não haja um isolamento total entre a equipe de desenvolvimento e a equipe independente de testes.

A motivação da diretoria é coerente, pois uma equipe independente de testes sempre encontra mais defeitos, se comparada a um projeto com recursos internos de testes.

Nenhuma das demais opções está correta com relação ao cenário apresentado.

Teste executado em sequência invertida.

Um sinônimo para teste de confirmação.

Teste que executa casos de teste que falharam da última vez em que foram executados.

Teste de um programa testado anteriormente após sua modificação.

Os desenvolvedores, que podem não estar corrigindo apropriadamente os bugs no passo 1.

Os desenvolvedores, que podem não estar testando adequadamente no passo 2.

Os testadores, que podem estar confusos sobre o que testar no passo 4.

Gerenciamento de configuração, que pode não estar mantendo a integridade do produto no passo 3.

Diferentemente dos testes de confirmação, os testes de regressão não envolve repetição de testes, o que os torna um fraco candidato a automação.

Podem ser executados tanto em um projeto de uma aplicação totalmente nova quanto em uma manutenção.

Podem ser realizados nos níveis de testes de componente, integração e sistema, mas não podem ser realizados no nível de teste de aceitação.

Falhas não podem ser observadas através de testes de regressão, que somente permitem encontrar bugs.

I e II estão corretas.

I, II e III estão corretas.

II e III estão corretas.

I e III estão corretas.

0,2; 0,9; 29,5

12,3

10,0; 28,0

0,4; 0,5; 25,0; 25,1

Rastreabilidade dos resultados dos testes com os regulamentos

Data de entrega realizada através de deferimento da inexistência de defeitos

Baixa complexidade do sistema

Segurança do projeto utilizado para reduzir a necessidade de testes

Não é possível garantir que um software esteja totalmente isento de defeitos, mesmo se já estiver em uso por vários anos e nunca tiver apresentado qualquer falha.

Deve-se modelar casos de teste cobrindo todas as combinações possíveis de entradas e pré-condições visando reduzir nível de risco de qualidade.

O envolvimento das atividades de teste o mais cedo possível no contexto do ciclo de vida do software é fundamental para uma comunicação eficaz entre as equipes de desenvolvimento e de teste, mas não representa vantagens com relação ao custo para remoção de bugs.

Um software com uma taxa de bugs muito baixa garante a satisfação dos usuários.

Teste e desenvolvimento.

Custo e decisão.

Probabilidade e impacto.

Dinâmico e reativo.

Revisões informais nunca trazem benefícios para projetos de desenvolvimento de software. Todas as revisões devem ser formais.

Nas revisões do tipo Walkthough a responsabilidade do autor limita-se a esclarecer eventuais dúvidas sobre o item a ser revisado.

Em uma revisão por pares, colegas com conhecimentos técnicos específicos procuram defeitos no item a ser revisado. O gerente do projeto participa da revisão com o intuito de identificar riscos de projeto.

Uma inspeção é um tipo de revisão formal em que um moderador (que necessariamente não pode ser o autor) lidera o time de inspeção através de um processo definido.

Refinamentos da abordagem.

Responsabilidades.

Riscos e Contingências.

Necessidades ambientais.

Análise de fluxo de dados

Efeito da monitoração

Web Spider

Complexidade ciclomática

“Oh, desculpe-me, eu não deveria ter mencionado aqueles testes e seu status, pois não são dados apropriados de monitoramento do progresso do teste.”

“Dependendo da reação do cliente a alguns dos bugs que afetam aqueles testes, nós poderemos ter problemas contratuais com o aceite e pagamento final.”

“Todo software sempre deveria ser liberado complemente sem defeitos, e este software não atende esse padrão.”

“Isso não importa, realmente, já que o cliente ficará satisfeito se 80% dos testes passarem”

Todas as técnicas estáticas e dinâmicas possíveis.

Todas as técnicas baseadas na especificação possíveis.

Todas as técnicas baseadas na estrutura possíveis.

Todas as técnicas baseadas na experiência possíveis.

Prover os desenvolvedores com informação para isolar a falha.

Não pertence a um relatório de incidente.

Prover lideres de teste com informação para relatar progresso do teste.

Prover idéias para melhorar o processo de teste.