Questao 1:

� aplicado para gest�o e planejamento de projetos de sowftware, os projetos sao

divididos em ciclos mensais chamados de sprints que representa um time box
dentro do qual um conjunto de atividades deve ser executado

Product backlog: funcionalidades a serem implementadas em um projeto mantidas

nessa lista.

Sprint backlog: atividades que a equipe sera capaz de implementar durante o

sprint que se inicia, tarefas que sao transferidas do product backlog para o
sprint backlog.

Daily scrum: reuniao feita pela equipe a cada dia de uma sprint que tem como
objetivo disseminar o que foi feito no dia anterior, indentificar impedimentos
e priorizar o proximo dia de trabalho.

Questao 2:

Cascata: Se baseia em uma sequencia de atividades padronizadas em que uma saida

� entrada para outra ou seja elas devem ser executadas sequencialmente onde uma
tarefa so inicia quando a anterior for fimnalizada.

Agil:� feito em pequenas partes para que assim o cliente receba regularmente
um feedback do que est� sendo desenvolvido, isso possibilita um troca constante
entre cliente e a equipe se adequando as mudan�as que surgem durante o processo.

Questao 3:

Falta de cobertura dos testes: que se da pela prioriza��o errada, desenho errado
dos testes e pouco tempo para o desenvolvimento.

Qualidade pobre do software: por nao ter passado por todos os testes necessarios
e validacoes incompletas.

Aumento de custos para equipe: pois ao ser finalizado o software e produzido

ao se encontrar um bug o custo de tempo e dinheiro pra se corrigir � maior do
que quando ser dedectado logo de inicio.

Questao 4:
Defeat leakege:Se foram encontrados 100 bugs, mas 20 deles foram encontrados
na fase de entrega.

Questao 5:

Garantir a qualidade de um processo �gil.

Questao 6:

Nem sempre � possivel estimar a quantidade de testadores em rela��o aos

desenvolvedores em virtude de que existem fatores externos e mais desenvolve-
dores do que testadores.

Questao 7:

Casos de testes tem como objetivo verificar se todos os requisitos foram imple-
mentados e todas a entradas se estao validadas alem de suas saidas para que
por fim possa ser entregue as usuario final no qual sera analizado se corresponde
ao esperado, se satisfaz as necessidades do negocio e se nao afeta outros sistemas
verificando sua aceita��o diante do publico alvo.

Questao 8:

Quando o cliente pede de inicio um login com senha de tamanho 8 que foi validado e
depois
solicita pra mudar seu tamanho pra 10 � um conflito de requisitos no sistema pois
ao ser
atualizado a base de testes o requisito anterior falha porque o requisito foi
atualizado
assim ocorrendo um conflito entre os requisitos e gerando um bug, mas na verdade
foi so a
atualiza��o da base de testes.

Questao 9:

ATDD: criar os criterios de aceita��o antes do inicio do sprint

BDD: estrategia de definicao da documenta��o como descrevo os requisitos e
comportamento do
meu sistema na linguagem de negocios.
TDD: automatizar os testes no servidor antes da entegrar.

Questao 10:

Antecipar riscos de forma automatica, escrever menos documentacao, serve como um

caso de teste.

Quest�o 11:

Escrever todos os casos de testes de uma caracteristica em um unico modulo, no qual

se algum teste
falhar provavelmente sera um bug assim evitando problemas com bases de testes
desatualizados.

Questao 12:

Revisoes: tecnica e informal.

Analise estatica: Fuxo de controle e Fluxo de Dados.
Inspecoes: Checklist.
Caminhos percorridos: apresentacao passo a passo dos artefatos.

Questao 13:

Baseado em estruturas: sao testes de caixa branca que verificam se todos comandos
foram executados durante o teste.

Baseado em especifica�ao: sao testes que priorizam os casos principais do software

o que foi especificado pelo cliente.

Questao 14:

Se tem cobertura de codigo superior � 50% se nao o teste nao � tao efetivo.

Questao 15:

por nao ser tao viavel analisar todos os requisitos e perda de tempo ligado a
criacao de muitos casos de teste.

Questao 16:
Parti��o de Equival�ncia:Trata-se de uma t�cnica de testes que prop�e a separa��o
das poss�veis entradas em categorias diferentes.

An�lise de limite:� uma t�cnica de projeto de casos de teste que complementa o

particionamento de equival�ncia;
Em vez de selecionar qualquer elemento de uma classe de equival�ncia, a BVA leva �
sele��o de casos de teste nas �extremidades� da classe.

Tabelas de Decis�o:�A Tabela de decis�o � uma maneira de expressar, em forma de

tabela, qual o
conjunto de condi��es que � necess�rio ocorrer para que um determinado conjunto de
a��es deva ser executado.

Questao 17:

Por o teste agil estar relacionado mais com analise de risco do que com a
verifica�ao de todos os requisitos.

Questao 18:

Mais de 15 anos de experiencia.

Questao 19:

O grande diferencial dele nesse assunto nao � o que ele tem como conhecimento mais
sim o que ele aprendeu a partir de outras
pessoas que lhe passaram informacoes e experiencias vividas.

Questao 20:

Analisar as areas de risco do sistema, o que possivelmente pode acontecer seja

aplicacao desktop ou web.Entre as perdas
esta � nao renova�ao de contrato, insatisfa��o com o servico da institui��o,
atrasos na agenda, perda de dados e rescis�o de contrato.

Questao 21:

Distribuir meus testes em varias areas como exemplo seguran�a, ux, maturidade dai
posso analisar em qual area tive mais testes assim
controlando a quantidade de testes nao focando em uma area s�.

Questao 22:

Focar os testes so nos criterios da historia ou seja em uma area s� pois acarreta
muito fazamento de erros.

Questao 23:

Agrupamento de defeitos: Um pequeno n�mero de m�dulos vai ter a maioria dos

defeitos que voc� descobrir durante os testes,
isso possibilita que voc� se foque nesses m�dulos, mas sem esquecer dos outros

Parodoxo do pesticida: Pode ser que uma hora aqueles testes que voc� vem repetindo
n�o encontrem mais defeitos,
isso pode dizer que est� na hora de inovar nos testes.

Questao 24:
Ter um indentificador unico, separar os dados dos procedimentos, metadata onde irar
priorizar determinados dados e condicoes,
listagem de casos que sao validados ou que falham, especificar os casos para
determinado procedimento de entrada e saida de dados.

Questao 25:

Est� relacionado com o processo de testes, etapa do processo de desenvolvimento de

software de suma import�ncia para garantia e controle da qualidade.
Sua abrang�ncia vai desde testes unit�rios at� testes de aceita��o e tem por
objetivo definir documentos consistentes e adequados capazes de definir,
registrar e prover condi��es de an�lise dos resultados obtidos ao longo do
processo.
Falhas manifestadas durante o processo de teste de um sistema de software devem ser
registradas com informa��es suficientes para que este defeito possa ser
reproduzido,
analisado e corrigido de forma segura e definitiva. O defeito localizado deve ser
registrado, juntamente com suas evid�ncias e ind�cios, para compor uma base de
conhecimento compartilhada entre os membros da equipe.

Questao 26:

Metadados:
Os metadados s�o marcos ou pontos de refer�ncia que permitem circunscrever a
informa��o sob todas as formas,
pode se dizer resumos de informa��es de conte�do de uma fonte.

Casos de testes:
Condi��o particular a ser testada e � composto por valores de entrada, restri��es
para a sua execu��o e um resultado ou comportamento esperado.

Questao 27:

As assertivas surgiram com o intuito de ajudar o programador nos testes em tempo de

desenvolvimento evitando assim que o programador utilize outros meios
como captura de exce��es que podem nunca ocorrer.

Questao 28:

Por ser escrito um unico documento, apenas um unico documento para validacao no
metadado e os casos que estao descritos.