Fundamentos de Teste de Softwares

1. Testes de Software

2.  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

3.  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

4. Motivação
A arte do teste de software (MYERS, 1979)

5. Motivação

6.  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

7.  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

8.  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)

9. Processo de Testes
TI Exames

10. Processo de Testes x Dev

11.  1 - Caso de Uso
 N - Cenários
 1 - Caso de Testes
 N - Cenários de Teste
 1 UC -> 1 TC
Cenário Tradicional

12.  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

13.  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

14.  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

15.  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

16.  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