diferença indesejável entre o observado e o esperado
Um software pode
conter defeitos,
mas mesmo assim
nunca falhar
Qualidade é o
quanto um sistema
atende os
requisitos
especificados
SETE PRINCÍPIOS DO
TESTE
Teste desmonstra a presença de defeitos
Um teste demonstra a presença de defeitos,
mas NÃO prova que eles não existem
Teste exaustivo é impossível
Teste antecipado
Agrupamento de defeitos
Um número pequeno de módulos contém
a maioria dos defeitos descobertos
Paradoxo do pesticida
Se os mesmos testes forem repetidos diversas vezes, num determinado
momento não encontrará mais erros, então é preciso exercitar
diferentes partes do siftware para encontrar outros defeitos
Teste depende do contexto
A ilusão da ausência de erros
Encontrar e corrigir defeitos não ajuda se o
software não atender às necessidades do usuário
TESTE ESTÁTICO
atividades de revisão, inspeção e análise estática do código
encontram defeitos
REVISÃO INFORMAL
não há padronização, o autor do documento pode fazer a análise do próprio trabalho
nada é documentado e não há coleta de métricas
outra pessoa pode revisar o documento: um líder técnico ou alguém da mesma especialidade do autor (revisão por pares)
REVISÃO FORMAL
REVISÃO TÉCNICA OU REVISÃO POR PARES
Liderada por um MODERADOR treinado que não é o autor
Avalia de forma técnica os artefatos específicos, pode ser feita
individualmente, em dupla ou pequenos grupos
Checklist e relatório da revisão são opcionais
ACOMPANHAMENTO - WALKTHROUGH
O principal propósito é a aprendizagem, treinar os envolvidos e obter
entendimento
Liderada pelo AUTOR do documento
Não tem uso de checklist
INSPEÇÃO
Liderada por um MODERADOR treinado que não é o autor
Processo Formal: Planejamento > KickOff > Preparação > Reunião de Revisão > Retrabalho > Acompanhamento
Utilização de checklist
Papéis e Responsabilidades
GERENTE: decide sobre a execução da revisão, aloca tempo no projeto, agenda e determina os objetivos da revisão
MODERADOR: pessoa que lidera, planeja e executa a revisão.
AUTOR: responsável pelo documento a ser inspecionado
REVISORES: pessoas com conhecimento técnico ou de negócio que revisam os documentos
REDATOR: registra os defeitos, problemas e indicadores da reunião
Complexidade Ciclomática =
número de decisões + 1
TESTE DINÂMICO
atividades de planejamento, execução e controle de teste
o teste é responsável por encontrar a falha, a
depuração é responsável por encontrar o defeito
que está causando a falha
encontram falhas
ETAPAS DO PROCESSO DE TESTE
1. PLANEJAMENTO E CONTROLE
Planejamento: onde é desenvolvido o PLANO DE TESTE
PLANO DE TESTE: define escopo, objetivo, recursos, abordagem, cronograma
Abordagem: técnicas, cobertura, testware, interagir com equipes envolvidas
Controle: medir e analisar o resultado das etapas
2. ANÁLISE E MODELAGEM
Momento de definir as CONDIÇÕES DO TESTE
CONDIÇÃO DE TESTE: item ou componente de um sistema que
pode ser verificado por um ou mais casos de teste
Condição de teste é O QUE será testado
3. IMPLEMENTAÇÃO E EXECUÇÃO
Transformação das condições de teste em CASOS DE TESTE
Implementação: criar os casos de teste, priorizar os casos de teste, escrever os procedimentos e scripts, etc
Definir COMO será testado
Execução: executar os casos de teste, registrar as saídas das execuções, checar os resultados, etc
4. AVALIAÇÃO DOS CRITÉRIOS DE SAÍDA E RELATÓRIOS
Ajudam a definir se os objetivos do teste foram atingidos e se já é
possível encerrar as atividades
Critérios de saída: condições acordadas pelos stakeholders que
definem quando o processo pode ser considerado completado
Condições de saída podem ser: cobertura de requisitos, restrição de
tempo/orçamento, todos os casos de teste executados/aprovados, etc
5. ATIVIDADES DE ENCERRAMENTO DE TESTE
Pega dados do projeto para medir desempenho, consolidar experiência,
realizar reuniões de lições aprendidas, armazenar testware
TESTWARE: toda a documentação gerada pelo processo de teste, plano de teste, condição de teste, etc. Esses
documentos são guardados caso futuramente seja necessário alterar algum requisito do projeto original
NÍVEIS DE TESTE
TESTE UNITÁRIO OU DE COMPONENTE
Testar os componentes de forma isolada, provar que cumprem a função para a qual foram projetados
Realizados por programadores, aspectos funcionais e não-funcionais devem ser considerados
TESTE DE INTEGRAÇÃO
Testar a integração das unidades que foram testadas separadamente, a fim de buscar erros de interações
Dois tipos: Teste de Integração de Componentes e Teste de Integração de Sistemas
Bottom-Up
cada módulo do nível inferior é testado individualmente, em seguida são
testados os módulos que chamam esse, e assim sucessivamente
é preciso implementação de DRIVERS
DRIVER: testar o E sem o B precisar estar pronto, então cria um DRIVER para o B (cria um dublê)
Top-Down
o nível superior é testado primeiro, depois todos os módulos
chamados por ele, e assim sucessivamente
é preciso implementação de STUBs
STUB: testar o C sem o G precisar estar pronto, então cria um STUB para o G (cria um dublê)
STUB é consumido e DRIVER consome
Big-Bang
testa cada módulo individualmente e depois integra
necessário DRIVER e STUB, o que leva a muito
mais codificação e problemas em potencial
TESTE DE SISTEMA
Provar que o sistema não funciona, testando os requisitos funcionais e não-funcionais
Conhecido como TESTE DE VALIDAÇÃO
São testes CAIXA-PRETA realizados pela equipe de teste em um ambiente controlado, o mais próximo possível de produção
TESTE DE ACEITE
Obter a homologação do cliente em relação ao software
UAT - Teste de Aceite do Usuário
Realizados em ambiente de homologação do cliente, responsabilidade dos usuários
OAT - Teste de Aceite Operacional
Aceitação do sistema por quem deve administrá-lo, confirmar se atende
às necessidades operacionais
Teste de aceite de contrato e regulamento
Aceitação dos critérios definidos no contrato, o pagamento pode depender desse teste
Alfa e Beta Teste
Aplicados quando o software será usado por muitos clientes
ALFA: conduzido pelo cliente no ambiente da empresa desenvolvedora
BETA: conduzido no ambiente do cliente, que não é controlado pelo desenvolvedor
TIPOS DE TESTE
Teste Funcional
observa apenas QUAL foi o resultado do teste e não COMO o mesmo foi obtido
Avalia as funções do sistema "O QUE O SISTEMA FAZ"
baseado nas técnicas CAIXA-PRETA
TÉCNICAS DE MODELAGEM DE TESTES
CAIXA-PRETA
Teste Baseado na Especificação
CAIXA-BRANCA
Teste Baseado na Estrutura
BASEADAS NA EXPERIÊNCIA
Teste Não-Funcional
Teste de Performance
mede o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo
Teste de Carga
submete o sistema à variação de carga de trabalho para analisar a capacidade de continuar funcionando
Testes de Estresse
entender o comportamento do sistema em condições limites (pouca memória, capacidade, concorrência por recursos)
Teste de Recuperação de Falhas
assegura que após uma falha os dados serão recuperados com sucesso
Teste de Instalação
assegura a eficiência dos diferentes procedimentos de instalação em diferentes configurações
Teste Estrutural
analisa a estrutura interna do componente
é o TESTE
CAIXA-BRANCA
é possível medir quanto de código foi testado (COBERTURA DE CÓDIGO)
Teste de Regressão (Confirmação)
retesta parte do software previamente testadas, para assegurar que elas funcionam
corretamente depois que foram feitas mudanças em outras partes da aplicação
TESTE DE MANUTENÇÃO
É uma fase do ciclo de vida do software
Após o software ser desenvolvido, alterações no ambiente podem alterar o funcionamento do software
É executado quando tiver versões corretivas, evolutivas, migração de sistema, da base de dados, etc