O documento apresenta os fundamentos e práticas de testes de software. Aborda conceitos como erro, defeito e falha, níveis e técnicas de teste, além de discutir as perspectivas diferentes de desenvolvedores e testadores. O objetivo é auxiliar desenvolvedores a entender a importância dos testes e como aplicá-los de forma efetiva.

1. Testes de So)ware
para desenvolvedores de so)ware
Fundamentos e Prá/cas
Sergio Lima
Ruby Developer
Scrum team member
Junho de 2017

2. Testes de So)ware
Agenda
1. Minha experiência com testes
2. O Que é Teste de So)ware
3. Por que razão temos que testar?
4. Fundamentos
5. O que testes de so)ware podem
indicar…
6. O que pode ser testado?

3. Testes de So)ware
Agenda
7. Mindsets diferentes: Developer x Tester
8. AWvidades do Teste. Duas grandes
ramificações.
9. Níveis ou Fases do Teste.
10. Técnicas de Modelagem de Teste.

4. Minha experiência com testes

5. Minha experiência com testes

6. Minha experiência com testes
• Testes automaWzados em Ruby e em
Ruby On Rails.
• Curso “Fundamentos do Teste de
So)ware”.
• Preparação para o exame CTFL, CerWfied
Tester FoundaWon Level.

7. O Que é Teste de Software

8. O Que é Teste de Software
“Testar é analisar um programa com a
intenção de descobrir erros e defeitos.”
(Glenford Myers)

9. O Que é Teste de Software
“Teste é o processo que consiste em todas
as aWvidades do ciclo de vida, tanto
estáWcas quanto dinâmicas, voltadas para
o planejamento, preparação e avaliação de
… so)ware … a fim de determinar se elas
saWsfazem os requisitos especificados…”
(Glossário de termos do ISTQB, The
InternaWonal So)ware TesWng
QualificaWons Board.)

10. Por que razão temos que testar?

11. Por que razão temos que testar?
• Qual a origem da necessidade dos
testes?
• Onde nasce essa necessidade?
• Qual a origem?

12. Por que razão temos que testar?
• Erros?
• Como aparecem os erros?
• Podemos parar de produzir erros?

13. Por que razão temos que testar?
“O ser humano é incapaz de realizar
aWvidades sem erros.”

14. Por que razão temos que testar?
Principal causa das falhas:
• Processo de desenvolvimento imaturo.
• Pressão do tempo de entrega.
• Falhas na comunicação.
• Problemas em requisitos:
• Falta de definição ou não
documentados.

15. Fundamentos

16. Questão
Em relação a erro, defeito e falha, de
forma conceitual:
1. São a mesma coisa, portanto, sinônimos.
2. São diferentes conceitualmente.
3. Erro e defeito são a mesma coisa.
4. Erro e falha são a mesma coisa.
5. Defeito e falha são a mesma coisa.

17. Erro, Defeito, Falha
Erro (error):
Ação humana que produz um resultado incorreto.
Pode ocorrer em qualquer fase do
desenvolvimento do so)ware.
Defeito (fault):
Se executado, o erro pode causar uma falha.
É o famoso ‘bug’.
Falha (failure): É o defeito encontrado. Diferença
entre o esperado e o observado.
Pode ser causado pelo ambiente.

18. Erro, Defeito, Falha
Erro (error):
<|>
/
…produz um erro e cria um Defeito (fault):
… é possivel que cause uma Falha (failure):

19. Erro, Defeito, Falha

20. Erro, Defeito, Falha

21. Erro, Defeito, Falha
Como exemplo, filmes 2001 e 2010
2010:

22. Erro, Defeito, Falha
Como exemplo, filme Her

23. Erro, Defeito, Falha
Como exemplo, filme Her

24. Erro, Defeito, Falha
Como exemplo, filme Her

25. O que testes de so)ware podem
indicar…

26. O que testes de so)ware podem
indicar…
Sabendo a diferença entre Erro, Defeito e
Falha, o que testes de so)ware podem
indicar?

27. O que testes de so)ware podem
indicar…
"Testes podem indicar falhas no so)ware
mas não podem indicar a presença de
erros."

28. O que pode ser testado?

29. O que pode ser testado?
• Teste de so)ware não é aplicado apenas
para so)ware.
• Qualquer artefato de so)ware pode ser
testado.

30. O que pode ser testado?
Qualquer artefato de so)ware:
• Especificação:
• de Requisitos
• Funcional
• Técnica
• Código-fonte.
• Plano de teste, caso de teste, scripts de teste.
• Manual do usuário.
• Material de suporte.
• Outros.

31. O que pode ser testado?
• Importante: quanto mais cedo o erro for
detectado, melhor.

32. Mindsets diferentes: Developer x Tester

33. Mindsets diferentes: Developer x Tester
Developer
|
< | >
|
/
Ao realizar testes
procura o
funcionamento do
sistema
RESULTADO
defeitos

34. Mindsets diferentes: Developer x Tester
Tester
|
< | >
|
/
Ao realizar testes
procura defeitos
no sistema
RESULTADO
Menos defeitos

35. Mindsets diferentes: Developer x Tester
“Testar é analisar um programa com a
intenção de descobrir erros e defeitos.”
(Glenford Myers)
Teste é feito para provar que o so)ware
não funciona.
• Developer: construir e provar que o
so)ware funciona.
• Tester: realizar testes e provar que o
so)ware não funciona.

36. Mindsets diferentes: Developer x Tester
Proposta para um novo mindset para o
developer:
• construir o so)ware e provar que não
funciona.

37. AWvidades do Teste.
Duas grandes ramificações.

38. AWvidades do Teste.
Duas grandes ramificações.
Teste Está/co Teste Dinâmico
StaWc TesWng Dynamic TesWng
Revisão, inspeção,
análise em qualquer
documentação ou
código fonte.
Necessita que o
so)ware seja
executado. Mais
uWlizado por
empresas de
so)ware.

39. Níveis ou Fases do Teste.

40. Níveis ou Fases do Teste.
1) Unidades:
Aplicar
Testes unitários
2) Unidades
Integradas:
Aplicar
Testes de
Integração
3) Sistema
Integrado:
Aplicar
Testes de
Sistema
4) Sistema
pronto:
Aplicar
testes de
aceitação.

41. Níveis ou Fases do Teste.
Teste
Unitário
Teste de
integração
Teste de
Sistema
Teste de
Aceitação
Testar
componentes
ou unidades
de forma
isolada.
Testar a
integração
das unidades
que foram
testadas
isoladamente.
Provar que o
sistema não
funciona.
Testar
requisitos
funcionais e
não-
funcionais.
Teste de
aceitação ou
homologação.
Obter a
homologação
do cliente.
Especificações Técnicas e
Código Fonte
Requisitos de negócio, funcionais e
não-funcionais

42. Técnicas de Modelagem de Teste.

43. Técnicas de Modelagem de Teste.
Categorias das técnicas de modelagem de
teste:
• Teste de Caixa Preta
• Teste de Caixa Branca

44. Técnicas de Modelagem de Teste.
Categoria: Teste de Caixa Preta
• Não se considera o comportamento
interno do componente de so)ware a
ser testado.
• Dados de entrada são fornecidos, o
teste é executado e o resultado obWdo.

45. Técnicas de Modelagem de Teste.
Categoria: Teste de Caixa Branca
• Analisa a estrutura interna do
componente de so)ware a ser testado.

46. Técnicas de Modelagem de Teste.
• ParWção de Equivalência (equivalence
parWWoning)
• Análise do valor limite (boundary value
analysis)
• ObjeWvo: diminuir e escolher testes
mais representaWvos.

47. Técnicas de Modelagem de Teste.
• ParWção de Equivalência
Regra da LATAM:
viagem para criança, de 2 a 4 anos, acompanhada com
pessoa maior.
Par/ção inválida Par/ção inválida Par/ção válida
-3, -2, 0, 1 2, 3, 4 5, 6, 7, 8, …

48. Técnicas de Modelagem de Teste.
• Análise do valor limite
Baseada na experiência que mostra que os erros
acontecem mais nas fronteiras das parWções.
Par/ção inválida Par/ção inválida Par/ção válida
1 3 5
2 4
Valores válidos

49. Técnicas de Modelagem de Teste.
describe … do
describe … do
context ‘when invalid values’ do
context ‘and value is 1` do
it ‘returns false` do
expect(…).to be_falsy
end
context ‘and value is 5` do
it ‘returns false` do
expect(…).to be_falsy
end
end
...

50. Técnicas de Modelagem de Teste.
context ‘when valid values’ do
context ‘and value is 2` do
it ‘returns true` do
expect(…).to be_truthy
end
context ‘and value is 3` do
it ‘returns true` do
expect(…).to be_truthy
end
end
context ‘and value is 4` do
it ‘returns true` do
expect(…).to be_truthy
end
end
end

51. Técnicas de Modelagem de Teste.
• Casos de Teste:
• Definição de um conjunto de
entradas,
• condições de execução e
• resultados esperados.
• Finalidade è avaliar os requisitos
especificados do sistema.

52. Técnicas de Modelagem de Teste.
• Exemplo:
• tela de recuperação de senha da
guide invesWmentos
• hzps://
cliente.guideinvesWmentos.com.br/
recuperando-senha

53. Técnicas de Modelagem de Teste.
Entradas 1 2 3 4 5 6
E-mail válido N N N S S S
CPF válido N S S N S S
Dt. Nasc válida N S N S N S
Resultado esperado
Mensagem de
campo “inválido”
S S S S S N

54. Técnicas de Modelagem de Teste.
Entradas 1 2 3 4 5 6
E-mail válido N N N S S S
CPF válido N S S N S S
Dt. Nasc válida N S N S N S
Resultado esperado
Mensagem de
campo “inválido”
S S S S S N
Resultado obWdo OK OK OK NOK OK OK

55. Fundamentos e Prá/cas
Dúvidas,
comentários?
Testes de So)ware
para desenvolvedores de so)ware

56. Fundamentos e Prá/cas
Thanks!
Testes de So)ware
para desenvolvedores de so)ware

57. Fundamentos e Prá/cas
Bibliografia:
• Terminologia do teste padrão BS 7925-1.
• Glossário:
- InternaWonal So)ware TesWng QualificaWons Board (ISTQB®)
- hzp://www.istqb.org/
- GLOSSÁRIO PADRÃO DE TERMOS UTILIZADOS EM TESTE DE SOFTWARE
- Em português: BSTQB
Testes de So)ware
para desenvolvedores de so)ware