Testes de Software

Testar completude e corretude dos requisitos

Uma vez que os Requisitos levantados, elicitados, especificados como definir se ele foram desenvolvidos

Conceito de “Feito”: se passar por esses testes então foi feito o que foi pedido

Está seguindo funcionalidade (Requisitos Funcionais) e restrições (Requisitos não funcionais)

Se penso em como testar antes de desenvolver, já posso encontrar possíveis problemas futuros

Motivação

Encontrar Erros no Software

Defeitos (Bugs) causam prejuízos de todos os gêneros

Perdas Financeiras

Desenvolvedor: Retrabalho com correção

Clientes: Paradas, problemas de operação

Perda de Produtividade

Documentações paralelas (cliente)

Retrabalho

Perda de Qualidade

Multas, ações legais,...

Inclusive mortes ou danos físicos (Controle aéreo, por exemplo)

Motivação

Motivação

A arte do teste de software (MYERS, 1979)

Motivação

Erro trata-se de uma ação humana

Defeito Introdução do erro no sistema (Bug)

Falha Aquilo que é observado como divergente do esperado (Execução de uma

função defeituosa)

Definições – Erro, Defeito e Falha

TI Exames

Pressão dos Stakeholders

Prazos de atendimentos de demandas inadequado

Tecnologia inadequada

Arquiteto de Software, Analistas Seniors, Utilização de soluções de “Parceiros”, Hypeness, recusa/impossibilidade de aquisição de licenças

Pouca compreensão da necessidade do cliente

Falta de capacitação da equipe

Origem de Erros, Defeitos e Falhas

Pode existir um Software livre de defeitos? Não! Não existem profissionais infalíveis, pois os cenários possíveis são infinitos Confiabilidade = menor número de defeitos

# defeitos/linha # falhas/tempo

Aumentar o tempo e recursos de testes em documentos e software aumentam o custo

Sem Erros, Sem Defeitos, Sem Falhas

“Testes de programas pode ser usado para mostrar a presença de defeitos,

mas nunca para mostrar sua ausência.”(Dijsktra)

Processo de Testes

TI Exames

Processo de Testes x Dev

1 - Caso de Uso

N - Cenários

1 - Caso de Testes

N - Cenários de Teste

1 UC -> 1 TC

Cenário Tradicional

1 - User Story

N - Cenários (BDD, TDD, ATDD)

Given [Contexto]

When [Ações]

Then [Resultados esperados]

Máximo de automação

Toda a equipe é responsável

Cenário Ágil

Técnica Caixa-Preta:

Deriva condições e casos de teste de documentações formais

Funcionais e não-funcionais do software

Não considera aspectos internos (código)

Técnica Caixa-Branca:

Considera aspectos internos do software (código)

Foco nas estruturas dos códigos (cobertura)

Deriva condições e casos de testes de forma sistêmica.

Classificação de Teste

Teste Unitário Nível máximo de granularidade Pequenos trechos de códigos Acesso ao código fonte: Código testando Código

Teste de Integração Testa a integração entre os diversos componentes Funcionais, não-funcionais, desempenho, estruturais

Teste de Sistema Validação do comportamento do sistema Equipe e ambiente de teste independente Testes baseados em documentação, modelos, riscos, negócios, etc Registro de defeitos efetivo

Teste de Aceite Testes Alfa e Beta, validações realizadas por clientes Executado por usuários, fora da empresa (Ambiente de Pré-produção)

Níveis de Teste

ISO/IEC 9126-1 (2003)

Características de Qualidade do Produto de Software

ISO 12207 (2008)

Processos de Ciclo de Vida de Software

IEEE 829 (2008)

Documentação de Teste de Software e Sistema.

Normas relacionadas a Testes

ISTQB (istqb.org) CTFL, CTAL, CTEL

IBQTS (ibqts.com.br) ATC: Fundamental, Avançado, Especialista

ALATS (alats.org.br) CBTS

ScrumAlliance CSM, CSD ou CSPO

Scrum.org PSMI, PSMII, PSPO

Certificações em Teste