1. Fundamentos
1.1. Principais Termos
1.1.1. Erro
1.1.1.1. Exemplo Humano que produz um resultado incorreto.
1.1.1.2. Também conhecido como engano.
1.1.2. Defeito
1.1.2.1. Defeito em um componente que leva o sistema a falha.
1.1.2.2. Também conhecido como bug
1.1.2.3. Manifestação dos erros inseridos no sistema.
1.1.3. Falha
1.1.3.1. Falha é a diferença entre o obtido e o esperado. (defeito encontrado).
1.2. Perfil do Profissional de Teste
1.2.1. Realista
1.2.2. Focado a evitar Problemas.
1.2.3. Analisador
1.2.4. Questionador da Criação
1.2.5. Medir a Qualidade do Produto (Software)
1.2.6. Detentor da visão de negócio
1.3. Conhecimentos, Habilidades e Atitudes
1.3.1. O analista de testes deve ter/adquirir os seguintes conhecimentos.
1.3.1.1. Aplicações e plataformas diversas
1.3.1.2. Metodologia de Desenvolvimento e Teste.
1.3.1.3. Técnicas e métodos de testes.
1.3.1.4. Análise combinatória.
1.3.1.5. Métricas e estimativas
1.3.1.6. Conhecimento em Programação.
1.3.2. O analista de! testes deve ter as seguintes habilidades.
1.3.2.1. Boa comunicação verbal e escrita
1.3.2.2. Facilidade de abstração e pensamento criativo
1.3.2.3. Análise critica para encontrar erros.
1.3.2.4. Ler e interpretar Especificações
1.3.3. Atitudes
1.3.3.1. Criatividade destrutiva
1.3.3.2. Acreditar que falhas existem
1.3.3.3. Encontrar falhas e problemas
1.3.3.4. Perseguir falhas e não pessoas
1.3.3.5. Agregar valor.
1.4. Responsabilidade
1.4.1. Fornecer subsídios para o planejamento dos testes.
1.4.2. Desenvolver casos, cenários e roteiros de testes.
1.4.3. Identificar, definir e gerar dados necessários para testes.
1.4.4. Executar testes
1.4.5. Reportar falhas
1.4.6. Efetuar testes de especificação.
1.5. Necessidades de Testes
1.5.1. Testamos para construir uma maior confiabilidade;
1.5.2. Quantos mais defeito menor a chance do sistema falhas.
1.5.3. Ajuda a manter a qualidade do produto, quanto defeitos são encontrados e resolvidos.
1.6. Quantos testes é suficiente ?
1.6.1. Não podemos testar tudo pois não temos tempo
1.6.2. Testes exaustivos são impraticáveis.
1.6.3. Os riscos de cada projeto irá fornecer quanto tempo será fornecido para testes e quantos profissionais deverá ser alocado para o projeto.
1.6.4. Restrições de tempo e orçamento são considerados
1.6.5. Executar primeiros os casos de testes com maiores riscos para o projeto
1.6.5.1. Para saber o risco de cadas cenário, coloque prioridades do momento da escrita do caso de testes.
1.7. O que é testes ?
1.7.1. Deve acontecer o mais breve possível no momento de desenvolvimento do software.
1.7.2. Teste de software é a etapa de controle de qualidade, serve para assegurar que o software está contemplando todas as funcionalidades esperadas e que estas estão funcionando corretamente
1.8. Principios
1.8.1. Teste demonstra a presença de defeitos.
1.8.2. Teste exaustivo é impraticável
1.8.3. Teste antecipado
1.8.3.1. O teste deve acontecer o mais breve possível no momento de desenvolvimento do produto
1.8.4. Agrupamentos de defeitos
1.8.4.1. Algumas funcionalidades do sistema, contém mais falhas que o outras.
1.8.5. Teste depende do contexto
1.8.5.1. Para cada projeto existi uma melhor forma de aplicar teste.
1.8.6. Ausência de erros.
1.8.6.1. Nenhum sistema é ausente de erros, se você não está encontrando erros é porque não está testando direito.
1.9. Processos
1.9.1. PC - Planejamento e Controle
1.9.1.1. Planejamento
1.9.1.1.1. Determina o que irá ser testado
1.9.1.1.2. Determina os objetivos de testes
1.9.1.1.3. Determina riscos
1.9.1.1.4. Determina recursos requeridos para cada fase.
1.9.1.1.5. Determina as atividades
1.9.1.1.6. Agenda as atividades
1.9.1.1.7. Especifica critérios de saída
1.9.1.2. Controle
1.9.1.2.1. Ajuda a alcançar o que foi planejado
1.9.1.2.2. Controlar o progresso do teste com o que foi planejado
1.9.1.2.3. Ocorre durante todo o processo.
1.9.1.2.4. Pode implantar ações corretivas
1.9.2. Analise
1.9.2.1. Revisa a base de teste como Documentação.
1.9.2.2. Avalia testabilidade.
1.9.3. Modelagem
1.9.3.1. Modela e prioriza condições de testes.
1.9.3.2. Modela o ambiente de teste
1.9.4. Implementação e Execução.
1.9.4.1. Execução
1.9.4.1.1. Onde é executado os casos de teste
1.9.4.1.2. Registra as evidência (saídas).
1.9.4.1.3. Verifica os resultados conforme Regras.
1.9.4.2. Implementação
1.9.4.2.1. Transforma condições de teste em casos de teste.
1.9.4.2.2. Desenvolve e prioriza os casos de testes.
1.9.4.2.3. Cria dados(massa) para os testes.
1.9.4.2.4. Escreve scripts de teste
1.9.4.2.5. Verifica se o ambiente está configurado conforme o planejado.
1.9.5. Avaliação de critérios, métricas e relatórios
1.9.5.1. Avaliação de Critéios
1.9.5.1.1. Se os critérios de saídas não foram alcançados mais testes devem ser aplicados, para isso devemos usar algumas métricas
1.9.5.2. Métricas
1.9.5.2.1. Mostra com números, onde está o maior ponto de atenção do projeto e se deve ser efetuado mais testes.
1.9.5.3. Relatórios
1.9.5.3.1. Coleta os resultados do teste para arquivamento.
2. Mapa mental criado por Anderson Caldeira
3. Ciclo de Vida do Software
3.1. Níveis de Testes
3.1.1. Teste Unitário
3.1.1.1. Conhecido como teste de Componente ou Modulo
3.1.1.2. Efetua testes de componentes individualmente
3.1.1.3. Normalmente é efetuado pela equipe de desenvolvedor
3.1.2. Teste de Integração
3.1.2.1. Valida se as unidades são integradas para formarem um conjunto de funcionalidades de software.
3.1.2.2. Normalmente é executado pelo Desenvolvedor
3.1.2.3. Níveis de teste de Integraçaõ
3.1.2.3.1. Teste de Sistema
3.1.2.3.2. Teste Integrado a componentes
3.1.3. Teste de Sistema
3.1.3.1. Visa provar que o software funciona de ponta a ponta
3.1.3.2. Podemos usar técnicas de testes baseadas em especificações (caixa-preta)
3.1.3.3. Pode usar técnicas baseadas na estrutura (caixa-branca).
3.1.3.4. Caracteristicas
3.1.3.4.1. Funcionais
3.1.3.4.2. Não Funcionais
3.1.3.4.3. Regras de Negócio
3.1.4. Teste de Aceite
3.1.4.1. Conhecido como o teste de aceitação do usuário.
3.1.4.2. É usado para testar a conformidade dos requisitos acordados com o usuário.
3.1.4.3. Não tem como objetivo encontrar erros
3.2. Modelo de Ciclo de Vida
3.2.1. Modelo V
3.2.1.1. Modelo de ciclo de vida do Software do Desenvolvimento e Testes
3.2.1.2. Mostra a relação dos níveis de testes com o desenvolvimento
3.2.1.3. Cada atividade de desenvolvimento tem uma atividade de testes.
3.2.1.4. O teste deve começar o quanto antes no momento de desenvolvimento, de preferência no momento dos requisitos.
3.3. Tipos de Testes
3.3.1. Funcional
3.3.1.1. Usado no teste de aceitação
3.3.1.2. Baseado em especificações
3.3.1.3. Teste de Caixa-Preta
3.3.2. Não Funcional
3.3.2.1. Usado para medir características do produto
3.3.2.1.1. Performance
3.3.2.1.2. Carga
3.3.2.1.3. Estresse
3.3.2.1.4. Recuperação de Falhas
3.3.2.1.5. Segurança
3.3.2.1.6. Instalaçao
3.3.2.1.7. Usabilidade
3.3.3. Mudanças
3.3.3.1. Reteste
3.3.3.1.1. Efetua o teste de um defeito após sua correção
3.3.3.1.2. Podemos chamar também de teste de confirmação.
3.3.3.2. Regressão
3.3.3.2.1. Teste efetuado para verificar se outras funcionalidades não foram afetadas após uma modificação no software.
3.4. Teste Estrutural
3.4.1. Normalmente efetuado pelos Desenvolvedores
3.4.2. Também conhecido como teste de caixa-branca.
4. Técnicas de Modelagem de Testes
4.1. Testes de caixa-preta
4.1.1. Fundamentos
4.1.1.1. Podemos se basear na documentação.
4.1.1.2. Também baseado na especificação.
4.1.1.3. Pode ser funcional e não funcional
4.1.2. Técnicas
4.1.2.1. Partição de Equivalência
4.1.2.1.1. As entradas do software são dividas em grupos que tenham um comportamento similar.
4.1.2.1.2. Reduz a quantidade de testes escolhendo somente valores para validar as partições.
4.1.2.2. Análise Valor Limíte
4.1.2.2.1. Testa os valores limites das partições
4.1.2.3. Tabela de Decisão
4.1.2.3.1. É considerado uma boa alternativa para capturar requisitos, que contém condições lógicas.
4.1.2.3.2. Cada coluna da tabela corresponde uma regra que define uma combinação de condições e ações que o sistema tem que realizar.
4.1.2.4. Transição de Estado
4.1.2.4.1. O testador tem que ser capaz de visualizar os estados do Software.
4.1.2.4.2. São transações que mudam o estado do software.
4.2. Caixa-Branca
4.2.1. Baseados na estrutura - Os testes de caixa-branca são conhecidos dessa forma pois são testes baseados na arquitetura interna do software ou seja baseada no código.
4.3. Testes Baseado na Experiencia.
4.3.1. São usados por pessoas que tem um devido conhecimento na aplicação, assim conseguem derivar casos de testes que não foram previstos durante a escrita dos roteiros.
4.3.1.1. Suposição de Erros
4.3.1.1.1. O testador deve acreditar que existem erros no sistema para efetuar esse tipo de testes,
4.3.1.1.2. Baseado na Experiencia.
4.3.1.2. Teste Exploratório
4.3.1.2.1. Técnica informal governada pelo tempo disponível (deve ser aplicada somente se houver tempo).
4.3.1.2.2. É mais utilizada quando não existem especificações disponíveis.