Este documento apresenta uma introdução ao teste de software, abordando os principais conceitos e atividades envolvidas no processo de teste de software, como planejamento, execução e avaliação dos resultados.

1. Introdução ao
Teste de Software
Uma abordagem prática

2. Licença Creative Commons

6. Mas antes disso...
• O quanto
é o seu software?

15. Análise de Teste de
Requisitos aceitação
Design do Teste de
sistema sistema
Design da Teste de
arquitetura integração
Design dos Teste de
módulos unidade
Codificação

16. Ativação: Análise dos riscos:
determina objetivos, avalia alternativas;
alternativas e restrições identifica e resolve riscos
Planejamento da
próxima iteração Desenvolvimento:
desenvolve; verifica

17. Alguns modelos do processo de
desenvolvimento de software
• RUP

18. Alguns modelos do processo de
desenvolvimento de software
• Ágil

20. O processo de Teste de Software
• Dependerá do processo de desenvolvimento
de software
• Comparação com irmãos siameses

21. As atividades de Teste de Software
Planejar
Controlar
Analisar
Modelar
Implementar
Executar
Avaliar critérios de saída e reportar resultados
Encerramento

22. O que testar/avaliar?
• Norma ISO/IEC 9126/1991 ou NBR 13596:
O que testar

23. A importância dependerá do software
sob teste (SUT)
Sistema embarcado
Web Site
no carro
Funcionalidade
Confiabilidade
Usabilidade
Eficiência
Manutenibilidade
Portabilidade

24. Verificação X Validação
• Verificação:
– estamos desenvolvendo o produto corretamente?
• Validação:
– estamos desenvolvendo o produto correto?

25. Teste Estático X Teste Dinâmico
• No teste estático:
– O código é examinado.
• No teste dinâmico:
– O código é testado.

26. Técnicas Estáticas
• Revisões:
– Revisão informal;
– Acompanhamento;
– Revisões técnicas;
– Inspeção.
• Análise estática:
– Objetivo encontrar defeitos no
código/modelagem;
– Geralmente utilizando uma ferramenta.

27. Teste de Caixa Branca e Caixa Preta
• Teste de Caixa Branca: teste baseado na
análise da estrutura interna de um
componente ou sistema.
• Teste de Caixa Preta: teste funcional ou não
funcional, sem referência à estrutura interna
do componente ou do sistema.
Como testar

29. Níveis de teste
• Unidade: teste realizado com os componentes
individuais de um software, na maioria das
vezes feito pelo desenvolvedor.
• Integrado: teste realizado com a finalidade de
expor defeitos nas interfaces e nas interações
entre componentes ou sistemas integrados.
Quando testar

30. Níveis de teste
• Sistema: testa um sistema integrado para
verificar se ele atende aos requisitos
especificados. Realizado pelos testadores.
• Aceitação: Teste formal relacionado às
necessidades dos usuários e aos requisitos e
processos de negócios. Realizado pelos
usuários/stakeholders para estabelecer a
confiança no sistema.
Quando testar

34. Planejamento do Teste de Software
• Definir o objetivo do teste;
• O que testar? Como testar? Quando testar?
• A estratégia que será adotada;
• A equipe de teste;
• O ambiente de teste;
• Análise de riscos.

36. IEEE 829
• É o padrão criado pelo IEEE para
documentação de Teste de Software;
• A melhor fonte para criarmos nossos próprios
documentos;
• Mais uma vez devemos avaliar quais
documentos e itens podem ser úteis para a
nossa realidade.

37. IEEE 829
• Apresenta 8 documentos:
– Especificação
• Plano de Teste;
• Especificação de Projeto de Teste;
• Especificação de Caso de Teste;
• Especificação de Procedimento de Teste.
– Relatório
• Log de Teste;
• Relatório de Incidente de Teste;
• Relatório de Sumário de Teste;
• Relatório de Encaminhamento de Item de Teste.

38. Relação dos documentos com o
processo de Teste de Software
Especificação de Documentação do
Projeto de Teste Plano de Teste Projeto &
Desenvolvimento
Especificação de Relatório de
Especificação de Documentação do
Procedimento de Encaminhamento
Caso de Teste Item
Teste de Item de Teste
Execução dos testes
Relatório de
Log de Teste
Incidente de Teste
Relatório de
Sumário de Teste

39. O Plano de Teste
• É o documento mais importante!
• Deve ser feito a partir da documentação do
projeto e do desenvolvimento do software;
• Todos os demais documentos serão baseados
nele.

40. Prática 1

42. de
Teste de Software.

44. Técnicas de modelagem de testes
• Baseadas em especificação
• Baseadas em estrutura
• Baseadas na experiência

45. Baseadas em especificação
• Partição de Equivalência
• Análise do Valor Limite
• Tabela de Decisão
• Teste de Transição de Estados
• Teste de Caso de Uso

46. Partição de Equivalência
• Aplicada em qualquer nível de teste
• É muitas vezes uma boa técnica para ser
aplicada primeiro
• Muitos testadores aplicam ela sem saber
(informalmente)
• O seu uso formal pode proporcionar melhores
resultados

47. Partição de Equivalência
• A idéia é divivir/particionar as entradas em
grupos que tenham um comportamento
similar, podendo ser tratados da mesma forma
• Se tiver tempo, você pode tentar mais de um
valor por partição, principalmente, se quiser
confirmar uma entrada típica do usuário

48. Partição de Equivalência
Exemplo bolo:
• Vamos imaginar que esse delicioso bolo ao
lado, tem 6 sabores: chocolate, nozes,
morango, maracujá, baunilha e limão.
• Quantos testes são necessários,
usando a técnica de partição de
equivalência?

49. ~ ^
Partição de Equivalência
Temos 6 sabores diferentes, e a técnica de
partição de equivalência, diz que precisamos
dividir as entradas, fazendo com que cada
divisão/partição , seja equivalente com um
comportamento do sistema.
Ou seja, precisamos dividir o bolo em
pedaços de diferentes sabores. Totalizando 6
pedaços (partições) de bolo, que equivalem
aos 6 sabores.

50. Análise do Valor Limite
• Complementar a técnica de partição de
equivalência;
• Limites são áreas onde os testes estão mais
propensos a indicar defeitos;
• Os valores limites de uma partição são seu
máximo e seu mínimo.

51. Análise do Valor Limite
Voltando ao bolo...
Agora vamos considerar que cada “camada” do bolo
tem 10cm. Desta maneira, o nosso bolo tem 60cm,
sendo composto de:
10cm de chocolate
10cm de morango
10cm de nozes
10cm de maracujá
10cm de baunilha
10cm de limão
Portanto, agora é a hora de fazer um teste mais
“guloso”...vamos lá

52. Análise do Valor Limite
No teste anterior...
Comemos 6 pedaços de bolo para verificar se o bolo
contém os seis sabores mesmo.
Agora...
Além de verificar se o bolo contém os seis sabores, vamos
verificar cada sabor tem exatamente 10 cm de altura.
O teste usando a técnica de análise do valor limite, irá
resultar em 24 entradas diferentes, ou seja, iremos
precisar comer 24 pedaços de bolo, nada ruim, neh...

53. Análise do Valor Limite
Entendo melhor
Usando a análise de valor limite são 14 pedaços de bolo, necessários
para o teste. O motivo para esse resultado é:
Valor limite máximo inválido (chocolate) = 11cm
Valor limite mínimo válido (nozes)
Valor limite máximo válido= 10cm
Valor limite mínimo válido= 1cm
Valor limite mínimo inválido= 0cm
Assim sendo iremos cortar os seguintes centímetros do bolo: 0, 1,
10, 11, 20, 21, 30, 31, 40, 41, 50, 51, 60 e 61. Logo, teremos 12
pedaços de bolo e mais 2 “pedaços” vazios, que são equivalentes
aos valores inferiores inválidos 0cm e 61cm.
Totalizando 14 pedaços. BOM APETITE!

54. Tabela de Decisão
• Focada nas regras de negócio
• É uma boa maneira de lidar com combinações
de valores de entrada
• As condições de entrada e ações são
declaradas de uma forma que possam ser
entendidas, como verdadeiras ou falsas
• Às vezes, é chamada de “causa e efeito”

55. Tabela de Decisão
• O grande ganho na utilização da tabela de
decisão, é que ela cria combinações de
condições que, geralmente, não foram
exercitadas durante os testes
• Pode ser aplicada a todas as situações quando
a execução do software depende de muitas
decisões lógicas

56. Tabela de Decisão
• O grande ganho na utilização da tabela de
decisão, é que ela cria combinações de
condições que, geralmente, não foram
exercitadas durante os testes
• Pode ser aplicada a todas as situações quando
a execução do software depende de muitas
decisões lógicas

57. Tabela de Decisão
Condições de
entrada
Ações/
Resultados
Regra

58. Tabela de Decisão
Condição Regra 1 Regra 2 Regra 3 Regra 4
Valor>100 V F V F
quant>100 V V F F
Ações
dar brinde X
dar desconto X
mensagem X
de erro

59. Teste de Transição de Estados
• É utilizado quando algum aspecto do sistema
pode ser descrito usando uma máquina de
estados
• Ou seja, o sistema pode ter um número
(finito) de estados diferentes, e as transições
de um estado para outro são determinadas
por regras de "máquina"

60. Teste de Transição de Estados
• Os testes podem ser construídos para cobrir
uma sequência típica de estados, cobrir todos
os estados, exercitar todas as transições,
exercitar uma seqüência específica de
transições ou testar transições inválidas

61. Teste de Transição de Estados
insere digita
cartão senha NOK NOK
NOK
OK OK
OK

62. Teste de Caso de Uso
• Ajuda a identificar casos de testes que
exercitam todo o sistema, transação por
transação, do início ao fim
• Baseada em casos de uso
• Um caso de uso é a descrição de um uso
particular do sistema feito por um ator
(usuário do sistema)

63. Teste de Caso de Uso
• Casos de uso muitas vezes são tratados como
cenários, e úteis para construir testes de
aceite com a participação do usuário final
• Eles podem ajudar a descobrir defeitos de
integração causados pela interação e
interferência de diferentes componentes, que
testes individuais de componentes podem não
ter detectado

64. Teste de Caso de Uso
• Casos de uso são definidos de acordo com o
autor, não com o sistema, descrevendo o que
o ator ver, mais do que as entradas e
resultados esperados do sistema
• Eles costumar usar uma linguagem e termos a
nível de negócio, ao invés de termos técnicos,
especialmente quando o ator é parte do
negócio

65. Teste de Caso de Uso
Ator Sistema
Criar
post
Publicar
post

66. Teste de Caso de Uso
Cenário – criar post (fluxo principal)
Pré-condição: A: ator
Usuário logado no sistema S: sistema
Cenário:
1. A: Seleciona opção de novo post;
2. S: Abre página de postagem;
3. A: Digita post;
4. A: Seleciona opção de salvar o post;
5. S: Salva o post;
6. S: Carrega a página com o post salvo.

67. Teste de Caso de Uso
Caso de teste – criar post
Pré-condição:
Usuário logado no sistema
Cenário:
1. Clicar no botão ‘novo post’;
2. Digitar texto;
3. Clicar no botão 'salvar como rascunho‘.
Resultado esperado:
Sistema salvar o post e apresentar a página com o post salvo.

68. Saiba mais: Técnicas de modelagem de teste (parte 2)
(QualidadeBR)

69. Baseadas na experiência
• Suposição de erro
• Teste exploratório

70. Especificação dos Casos de Testes
• Basicamente: pré-condições, ações, resultado
esperado e pós-condições;
• Organizado em suítes de testes = conjunto de
casos de testes;
• Deve ser de auto-explicativo;
• Defina padrões entre a equipe.
Saiba mais: Test Case Writing Best Practices
(SlideShare)

71. Prática 2

72. Implementação de Teste
• Criar o procedimento de execução dos testes,
priorizando-os;
• Criar massa de dados, caso necessário;
• Preparar o ambiente de teste;
• Escrever scripts para automatização dos
testes.

73. Preparando o ambiente de teste
• O ambiente de teste deve ser o mais próximo
possível do de produção;
• O procedimento de criação do ambiente de teste
deve ser documentado;
• O ambiente de teste deve
ser isolado dos demais;
• Caso seja preciso, envolver
o pessoal de infra o mais
cedo possível.

75. Prática 3

78. Nunca é demais lembrar...
• Documente toda execução dos testes;
• Tenha todos os casos de testes prontos e
atualizados;
• Use a sua experiência e conhecimento ao seu
favor;
• Testar não é só seguir um procedimento!
• Se algo estiver errado no caso de teste, avise!
• Atenção é a palavra chave!

79. Top Five: 5 métodos para encontrar
falhas
• Aprenda a quebrar as regras, de vez em
quando. Explore!
• Busque padrões!
• Toque onde dói mais!
• Escute os passos do bug se
aproximando!
• Dois é melhor do que um.
Trabalhe em par!

80. O custo dos defeitos

82. Reporte de falha
• Detalhe ao máximo!
– A caixa de mensagem não segue o padrão.
– Após não preencher os dados de critério do filtro
de mensagens, a mensagem de erro foi
apresentada num message box diferente do
padrão das demais mensagens de erro.
• Descreva o passo-a-passo, informe as
configurações do ambiente de teste,
prioridade, impacto, tipo, coloque provas do
incidente (ex. log, printscreen, etc).

83. A falha foi corrigida, e agora?
• Reteste;
• Teste de regressão.

84. Prática 4

85. Gerenciamento de incidentes
• Incidente = qualquer evento que requeira
investigação;
• O gerenciamento de incidentes é uma tarefa
em conjunto da equipe de desenvolvimento e
testes;
• Máquina de estados definida de acordo com
as necessidades da equipe;
• Uma ferramenta bug tracking pode ajudar.

86. Ferramentas Bug Tracking
• Bugzilla;
• Eventum;
• Jira;
• Mantis;
• Trac;
• Etc.
Saiba mais: Comparação de ferramentas bug tracking
(Wikipedia)

87. Avaliar critérios de saída e reportar
resultados
• Checar os registros de teste (logs) mediante o
critério de encerramento especificado;
• Avaliar se são necessários testes adicionais ou
se o critério de saída especificado deve ser
alterado;
• Elaborar um relatório de
teste resumido para os
interessados.

89. Prática 5

90. Quando os testes devem parar?
• O número de bugs achados que estão fechados é maior do que o número
de bugs que se esperava achar;
• Todos os testes foram executados;
• A porcentagem de cobertura da aplicação pelos testes já é o suficiente;
• Todas as funcionalidades funcionam corretamente;
• O sistema atende as métricas de confiabilidade, disponibilidade e
durabilidade definidas no Plano de Teste;
• O software tornou-se confiável;
• A estabilidade alcançada atingiu o
esperado;
• O número e severidade dos bugs caíram
a um nível satisfatório;
• O tempo médio entre defeitos
encontrados é muito alto.

92. Relatório de Resumo de Teste
• O objetivo é resumir os resultados da
atividades de teste executadas e prover
avaliações baseadas nesses resultados;
• Nele também é registrado o que foi testado e
em quanto tempo; as melhorias identificadas
e qualquer plano futuro de teste;
• É o documento final que apresenta, se o que
foi acordado no plano de teste, foi
realmente realizado ou não.

95. Prática 6

97. Carreira – Teste de Software

98. Carreira – Teste de Software
• Tester: responsável pela execução dos testes,
que em muitas vezes incluem as seguintes
atividades: testar configurações de hardware e
software, executar scripts simples de teste,
reproduzir e reportar bugs.
• Analista de Teste: responsável pela
modelagem e elaboração dos casos de teste e
pelos scripts de teste.

99. Carreira – Teste de Software
• Analista de Automação de Teste: tem como
objetivo principal, buscar a automatização de
testes, sempre que ela for possível e viável.
• Arquiteto de Teste: responsável pela
montagem da infra-estrutura de teste, monta
o ambiente de teste, escolhe as ferramentas
de teste e capacita a equipe para executar seu
trabalho nesse ambiente de teste.

100. Carreira – Teste de Software
• Líder de Teste: responsável pela condução dos
testes e pela equipe de Testes. Geralmente é
um profissional com alto grau de
conhecimento da área de Teste de Software.
• Gerente de Teste: tem como função
primordial a iniciação do projeto de teste a ser
realizado no produto a ser testado. Lida com
todas tarefas gerenciais.

101. Carreira – Teste de Software
• Os cargos e as tarefas dos cargos podem variar
(muito) de empresa para empresa;
• A área de Testes está a pleno vapor e os seus
profissionais são cada vez mais valorizados;
• É difícil encontrar profissionais qualificados.

102. Saiba mais: Guia Completo para Certificações em Teste de Software
(TestExpert - Fábio Martinho Campos)

103. Saiba muito mais!
• Grupos de discussão:
– Agile-Testing;
– BSTQB;
– Certificações - Qualidade e Teste de SW;
– DFTestes;
– GUTS;
– QAI-Brasil;
– etc.

104. Saiba muito mais!
• Sites e blogs:
– Diário da Qualidade;
– Ensaios de Qualidade;
– Falando em Teste e Qualidade de Software;
– One Stop Testing;
– QualidadeBR;
– Sem Bugs;
– StickyMinds;
– TESTAVO;
– TestExpert.
– zezologs;
– etc.

105. Saiba muito mais!
• Livros:
– Agile Testing;
– Análise de Riscos Em Projetos de Teste de Software;
– Base de Conhecimento em Teste de Software;
– Critical Testing Processes: Plan, Prepare, Perform, Perfect;
– Garantia da Qualidade de Software;
– How We Test Software at Microsoft;
– Lessons Learned in Software Testing;
– Pragmatic Software Testing: Becoming an Effective and
Efficient Test Professional;
– etc.

106. Saiba muito mais!
• Twitter;
• Troca de e-mails;
• Eventos;
• etc.

108. Obrigado!
• E-mail/gtalk: ffc.fabricio@gmail.com
• MSN: ffc_fabricio@hotmail.com
• Twitter: fabricioffc
• Blog: qualidadebr.wordpress.com
• Ensina aí!
– ensinaai@voicetechnology.com.br
– ensinar.wordpress.com

109. Fonte
• ISO/IEC 9126
– http://pt.wikipedia.org/wiki/ISO/IEC_9126
• Deception and Self-deception in Software Testing
– www.stickyminds.com/se/S15016.asp
• Testing Lessons - Top 5 Secrets to Bug Hunting Success!
– http://software-testing-zone.blogspot.com/2007/09/testing-lessons-
bug-hunting-success.html
• Aulas da professora Dra. Eliane Martins (UNICAMP)
– http://www.ic.unicamp.br/~eliane/Cursos/
• Comparison of issue tracking systems
– http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
• Black R. Advanced Software Testing Vol. 1. Rocky Nook, 2008.

110. Fonte
• BSTQB. Base de Conhecimento para Certificação em Teste - Foundation
Level Syllabus . 2007br.
• D. Grahan; V. Veenendaal; I. Evans; R. Black. Foundations of Software
Testing: ISTQB Certification. Cengage Learning Business Press, 2006.
• ISTQB – Glossário de Termos de Teste (Versão 1.3 – Português/Brasil).
• Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em
teste de software. São Paulo, Martins Fontes, 2007.