Teste de software

Qualidade e Teste de
Software
RODRIGO FONTE
ANALISTA DE SISTEMAS - CAPGEMINI

Agenda
 Quem sou?
 Atuação
 Desde os primórdios…
 Qualidade de software x Teste
 O que é teste?
 Por que teste é importante?
 Qual o impacto de não fazer teste?
 Técnicas de Teste
 Técnicas Ágeis
 Carreira de teste

Quem sou?
• 8 anos atuando com teste de software
Teste manual…
Teste de
performance…Automação de
teste…
Ferramentas…

Atuação
Demanda de
Teste
Entendimento
Criação de plano
de testes
Desenvolvimento de
scripts
Agendamento de
execução e revisão
Execução do teste
Geração de
laudo final
Performance Test

Desde os primórdios…
1848
Thomas Edson
Encontrado um inseto em uma
máquina
BUG
1947
Harvard Mark
Primeiro BUG de computador
1979
“The Art of Software Testing”
Glendford Myers
Qualidade de Software
1980
Modelos prescritivos de
desenvolvimento
E ferramentas de teste

Qualidade de software x Teste
 "Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com
o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos".
(BARTIÉ, 2002, p. 16)
 "Definir explicitamente o termo qualidade de software, quando o mesmo é dito";(PRESSMAN, 2005, p. 193)
 "Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de
software exiba alta qualidade"; (PRESSMAN, 2005, p. 193)
 "Realizar atividades de segurança da qualidade em cada projeto de software";(PRESSMAN, 2005, p. 193)
 "Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como conseqüência, a
qualidade no produto final"; (PRESSMAN, 2005, p. 193)
 Teste é uma das atividades dentro do processo de qualidade.

O que é teste ?
 É o processo de execução de um produto para determinar se
ele atingiu suas especificações e funcionou corretamente no
ambiente para o qual foi projetado.

O que é teste ?
Executar o teste?

O que é teste ?
 Planejamento e controle;
 Escolha das condições do teste;
 Modelagem de casos de teste;
 Checagem dos resultados;
 Avaliação de critério de execução;
 Geração de relatórios;

O que é teste ?
 Testes podem possuir objetivos diferentes:
 Encontrar defeitos;
 Ganhar confiança sobre o nível de qualidade;
 Prover informações para tomada de decisão;
 Previnir defeitos;

Por que teste é importante?
 “O ser humano está sujeito a cometer um erro (engano), que produz um defeito
(falha, bug), no código, em um software ou sistema ou em um documento.“
 Possíveis causas:
 Pressão de prazo;
 Códigos complexos;
 Complexidade na infraestrutura;
 Mudanças de tecnologia;

 Redução dos riscos de ocorrências em ambiente operacional;
 Contribui para a qualidade da aplicação;
 Defeitos corrigidos antes de implantar em produção;
 Atender a requisitos contratuais ou legais;

Fonte: http://blog.onedaytesting.com.br/teste-de-software

Fonte: The Standish Group - Chaos Report 2015

Qual o impacto de não fazer teste?
 31.1% dos projetos serão cancelados antes mesmo de serem completados;
 16.2% dos projetos de software são completos no tempo correto e com o valor
planejado gasto;
 9% quando falamos de empresas de grande porte;
 52,7% dos projetos irão custar 189% do valor original estimado;
 Os projetos entregues possuem 42% das funcionalidades originalmente
propostas;

Opinião dos executivos:

Fatores que mais impactam um projeto:

 Problemas no Mariner (1962)
 Custo: 18,5 milhões dólares
 Desastre: Mariner, um foguete com uma
sonda espacial para Vênus, foi desviado de
seu percurso de voo logo após o lançamento.
O controle da missão destruiu o foguete 293
segundos após a decolagem.
 Causa: Um programador, ao passar para o
computador uma fórmula que haviam lhe
entregado escrita manualmente, se esqueceu
de uma barra. Sem ela, o software tratava
variações normais de velocidade como se
fossem sérios problemas, causando falhas por
tentativas de correções que acabaram por
enviar o foguete fora do curso.
 Bug do Milênio (1999)
 Custo: $500 bilhões
 Desastre: O desastre de um homem é a fortuna de
outro, como demonstra o Bug do Milênio. Empresas
gastaram bilhões com programadores para corrigir
uma falha no software legado. Embora nenhum
falha significativa ocorreu, a preparação para o Bug
do Milênio teve um custo significativo e impacto no
tempo em todas as indústrias que usam a tecnologia
computacional.
 Causa: Para economizar espaço de armazenamento
de computador, softwares legados muitas vezes
armazenavam anos para datas com números de dois
dígitos, como 99 para 1999. Esses softwares também
interpretavam 00 para significar 1900, em vez de
2000, por isso, quando o ano de 2000 veio, bugs
apareceriam.

 Desatre no FBI (2005)
 Custo: $105 milhões jogados fora!
 Desastre: O FBI desistiu da revisão de um sistema após quatro anos de esforço. O
projeto Arquivo Virtual foi um maciço sistema de software integrado para agentes
compartilharem arquivos de casos e outras informações.
 Causa: Má gestão e uma tentativa de construir um projeto de longo prazo sobre
tecnologia ultrapassada, resultou em um sistema complexo e inutilizável.

Técnicas de teste
 Caixa Preta
 É uma forma de derivar e selecionar as condições e casos de testes baseados na análise
da documentação.
 Modelos, formais ou informais, são utilizados para especificação de um problema a ser
resolvido, o software ou seu componente.
 Os casos de testes podem ser derivados sistematicamente destes modelos.

Técnicas de teste
Caixa-Preta
Funcional
Não
Funcional
 Funcional
 Especificação de requisitos;
 Casos de uso;
 Especificação funcional;
 Podem não estar documentados.
 As funções representam “o que” o sistema faz.
 Testes funcionais são baseados em funções (descritas nos documentos ou
compreendidas pelos testadores)
 Teste funcional considera o comportamento externo do software (teste caixa-preta).

Técnicas de teste
Caixa-Preta
Funcional
Não
Funcional
 Não Funcional
 Como o sistema trabalha!
 Medir as características que podem ser quantificadas em uma escala variável como o
tempo de resposta;
 Avaliar:
 Capacidade;
 Robustez;
 Disponibilidade conforme as conexões simultâneas;
 Avaliar o comportamento do sistema em condições anormais.
 Evitar: indisponibilidade e insuficiência dos recursos;

Técnicas de teste
Caixa-Preta
Funcional
Não
Funcional
 Não Funcional
 Tipos:
 Teste de performance;
 Teste de carga;
 Teste de estresse;
 Teste de usabilidade;
 Teste de interoperabilidade;
 Teste de manutenibilidade;
 Teste de confiabilidade;
 Teste de portabilidade.

Técnicas de teste
Caixa-Preta
Funcional
Não
Funcional
 Não Funcional
 Benefícios:
 Verificar a qualidade do sistema desenvolvido;
 Testar a capacidade da infraestrutura contratada;
 Saber a quantidade de acessos simultâneos suportado;
 Identificar o ponto de exaustão da aplicação;

Técnicas de teste
Caixa-Preta
Funcional
Não
Funcional
 Não Funcional – Dados de pesquisa
 O carregamento ideal de páginas deve ser de 250 milissegundos ¼ de segundo ou UMA
PISCADA! (Harry Shum)
 Forest Research – Tempo que o usuário aguarda:
 Min 2 seg: aguardam
 Méd 3-5 seg: insatisfeito
 Máx 5> segundos: abandonam
 100 milissegundos a mais no tempo de carregamento de uma página resulta em uma perda de
1% nas vendas OU 1 segundo 10% de vendas perdidas.
Fonte: http://www.speedawarenessmonth.com/slow-websites-cost-the-us-ecommerce-market-504-billion-in-2011/#sthash.KYc3OVTu.dpuf

Técnicas de teste
 Automação
 Aplicação de estratégias e ferramentas com o objetivo de reduzir o
envolvimento humano em atividades manuais repetitivas.
 Testes regressivos com maior amplitude e profundidade.
 Baseado na interface gráfica
 Gravação/Execução (Capture/Playback)
 Dirigido a dados (Data-Driven)
 Dirigido à palavra-chave (Keyword-Driven)
 Baseado na lógica de negócio
 Baseado na linha de comando (Command Line Interface)
 Baseado em API (Application Programming Interface)
 Test Harness (criação de um pequeno programa)

Técnicas de teste
 Caixa Branca
 Técnicas baseadas na estrutura interna de um componente ou sistema.
 Informações sobre como o software é construído é utilizada para derivar os casos de
testes. Por exemplo, código e informações detalhadas de modelagem.
 A extensão da cobertura do software pode ser medida pelos casos de testes. Além
disto, os casos de testes podem ser derivados sistematicamente para aumentar a
cobertura.

Técnicas ágeis
 TDD – Test Driven Development
 Escreva um teste que falhe;
 Escreva um código que faça o teste passar;
 Melhore o código;
 Teste como especificação;

Técnicas ágeis
 BDD – Behavior Driven Development
 Dan North 2003;
 Foco principal o comportamento do software;
 Envolver partes interessadas no processo;
 Utilizar linguagem ubíqua para descrever o comportamento de uma aplicação;
 Os nomes dos métodos devem ser sentenças;
 Um nome mais expressivo auxilia melhor quando um teste falha;
 Padrão:
 Given <context inicial>
 When <quando ocorre um evento>
 Then <garantir quais são as saídas>
 Ferramentas

Carreira de teste
 Não exige habilidades técnicas?
 É uma carreira para que não quer programar?
 Basta ter uma visão crítica?
PÉSSIMA ESCOLHA!!!!

ESCOLHA CERTA!!!
Carreira de teste
 Teste de software faz parte do desenvolvimento?
 Não gosta de fazer trabalhos repetitivos?
 Considera que teste faz parte da equipe toda?

Carreira de teste
 Cargos tradicionais:
 Testador – Executa
 Analista – Modela e Executa
 Automatizador – Automatiza os testes
 QA – Junção dos 3 papéis
A carreira de testes ainda vale a pena?

Fonte
 Qualister - www.qualister.com.br
 BSTQB - www.bstqb.org.br
 Profissionais de TI - www.profissionaisti.com.br
 OWASP – Chaos Report 2015

Contato
 Rodrigo Fonte
 E-mail: rodrigo.fonte@hotmail.com
 Medium: @rfonte
 Linkedin: rodrigofonte

Teste de software

Mais conteúdo relacionado

Mais procurados

Semelhante a Teste de software

Mais de Allan Almeida de Araújo

Último

Teste de software