1
00:00:00,040 --> 00:00:03,680
Olá, vamos direto ao que 
interessa, testes de software. 

2
00:00:04,040 --> 00:00:05,680
Oi. 
Bora lá, a gente tem aqui um 

3
00:00:05,680 --> 00:00:10,280
material sobre engenharia de 
software Moderna e a ideia ir um

4
00:00:10,280 --> 00:00:13,320
pouco além, né? 
Do básico de testes unitários de

5
00:00:13,320 --> 00:00:15,800
integração. 
Isso queremos entender melhor 

6
00:00:15,800 --> 00:00:19,440
essas diferenças, caixa preta, 
caixa branca, como escolher 

7
00:00:19,440 --> 00:00:22,960
dados de testes, sabe? 
E também testes de aceitação. 

8
00:00:23,200 --> 00:00:25,280
Requisitos não funcionais, 
exato. 

9
00:00:25,720 --> 00:00:27,880
É fundamental conhecer essas 
categorias, né? 

10
00:00:27,880 --> 00:00:31,440
Para garantir que o software não
só funcione, mas que seja bom, 

11
00:00:31,440 --> 00:00:33,920
que seja robusto, adequado para 
o que ele se propõe. 

12
00:00:33,960 --> 00:00:38,200
Perfeito, então, começando pela 
base, caixa preta versus caixa 

13
00:00:38,200 --> 00:00:40,040
branca, qual que é a diferença 
chave? 

14
00:00:40,040 --> 00:00:43,720
Aí pensa assim, ó, teste caixa 
preta, que a gente chama também 

15
00:00:43,720 --> 00:00:46,160
de funcional. 
É como se você olhasse o 

16
00:00:46,160 --> 00:00:49,200
software só por fora. 
Você sabe o que ele deveria 

17
00:00:49,200 --> 00:00:53,800
fazer, o que entra, o que sai. 
Mas não faz ideia de como ele 

18
00:00:53,800 --> 00:00:57,280
faz aquilo por dentro, o código 
é uma caixa preta mesmo. 

19
00:00:57,520 --> 00:01:00,600
Entendi já o caixa branca ou 
estrutural? 

20
00:01:00,720 --> 00:01:05,000
Aí sim, você precisa olhar 
dentro do código. 

21
00:01:05,560 --> 00:01:10,000
A ideia é entender a lógica, 
garantir que os caminhos ali 

22
00:01:10,000 --> 00:01:14,480
dentro, as condições, os ifes e 
elses sejam testados. 

23
00:01:14,480 --> 00:01:18,400
Tá, e onde que entram os testes 
de unidade nisso tudo? 

24
00:01:18,400 --> 00:01:21,400
Porque muita gente usa, né? 
Faz tdd? 

25
00:01:21,400 --> 00:01:26,040
Ah, boa pergunta. 
É aí que fica interessante o 

26
00:01:26,040 --> 00:01:29,280
teste de unidade. 
Ele pode ser as 2 coisas. 

27
00:01:29,400 --> 00:01:33,080
Sério, como assim? 
É se você escreve um teste 

28
00:01:33,080 --> 00:01:37,200
focado só na interface pública 
de uma classe, tipo o que ela 

29
00:01:37,200 --> 00:01:42,280
promete fazer sem ligar para 
como ela faz isso é caixa preta,

30
00:01:42,280 --> 00:01:44,840
certo? 
Agora, se você escreve o teste 

31
00:01:44,840 --> 00:01:47,400
pensando em cobertura de código.
Sabe? 

32
00:01:47,480 --> 00:01:50,840
Para garantir que todos os ifes 
sejam executados, que todos os 

33
00:01:50,840 --> 00:01:54,640
caminhos sejam testados. 
Aí já tem uma pegada forte de 

34
00:01:54,640 --> 00:01:58,160
caixa branca. 
O Kant back até fala uma coisa 

35
00:01:58,160 --> 00:02:02,360
curiosa sobre tdd. 
Ele diz que parece caixa preta 

36
00:02:02,360 --> 00:02:05,800
no começo porque você escreve o 
teste antes do código existir, 

37
00:02:05,800 --> 00:02:08,759
né? 
Mas a inspiração para o próximo 

38
00:02:08,759 --> 00:02:11,720
teste que você vai escrever 
muitas vezes vem de olhar para o

39
00:02:11,720 --> 00:02:15,880
código que você acabou de fazer.
E essa análise do código já é 

40
00:02:15,880 --> 00:02:19,000
uma característica da caixa 
branca, é meio que um ciclo. 

41
00:02:19,240 --> 00:02:22,880
Que interessante essa dualidade.
OK, entendi. 

42
00:02:23,280 --> 00:02:28,360
Agora, pensando na caixa preta, 
testar tudo, todas as entradas 

43
00:02:28,360 --> 00:02:30,560
possíveis, não dá, né? 
É inviável. 

44
00:02:30,800 --> 00:02:34,360
Nossa, totalmente inviável teste
exaustivo. 

45
00:02:34,640 --> 00:02:38,720
Imagina testar um compilador com
todo o programa que existe ou 

46
00:02:38,720 --> 00:02:40,760
uma função que recebe 2 
inteiros? 

47
00:02:41,200 --> 00:02:44,360
São infinitas combinações. 
É impossível? 

48
00:02:44,440 --> 00:02:46,600
Por isso que a gente usa 
técnicas para selecionar os 

49
00:02:46,600 --> 00:02:50,680
dados, uma delas é a partição 
por classes de equivalência. 

50
00:02:50,760 --> 00:02:55,120
Partição, como funciona isso? 
A ideia é simples, até você 

51
00:02:55,120 --> 00:02:59,120
divide todas as possíveis 
entradas em grupos, em classes, 

52
00:02:59,520 --> 00:03:03,000
dentro de cada classe, você 
espera que o sistema se comporte

53
00:03:03,000 --> 00:03:06,840
de maneira parecida, ou seja, se
um valor daquele grupo der 

54
00:03:06,840 --> 00:03:09,000
problema. 
Provavelmente os outros também 

55
00:03:09,000 --> 00:03:12,240
dariam Ah. 
Tipo agrupar por similaridade de

56
00:03:12,240 --> 00:03:15,200
comportamento esperado. 
Exato, aí você testa só um valor

57
00:03:15,200 --> 00:03:18,240
de cada classe, é mais 
inteligente e mais eficiente. 

58
00:03:18,240 --> 00:03:20,600
Como no exemplo clássico do 
imposto de healand, né? 

59
00:03:20,600 --> 00:03:23,000
Testar um salário de cada faixa 
perfeito. 

60
00:03:23,000 --> 00:03:25,480
Esse é um ótimo exemplo. 
E para complementar isso, tem 

61
00:03:25,480 --> 00:03:29,640
outra técnica muito boa. 
A análise de valor limite. 

62
00:03:29,640 --> 00:03:33,280
Valor limite, isso é testar nas 
bordas das classes. 

63
00:03:33,280 --> 00:03:38,480
Exatamente, a experiência mostra
que muitos bugs, mas muitos 

64
00:03:38,480 --> 00:03:42,120
mesmo acontecem justamente nos 
limites dessas faixas nas 

65
00:03:42,120 --> 00:03:45,320
Fronteiras. 
Ah, tipo no maior que ou maior 

66
00:03:45,320 --> 00:03:46,520
ou igual a. 
Isso. 

67
00:03:46,880 --> 00:03:50,240
Então, se a faixa de isenção vai
até 1903 e 98 e a próxima começa

68
00:03:50,240 --> 00:03:52,760
em 1903 e 99, você vai testar 
esses valores exatos e também os

69
00:03:52,760 --> 00:03:58,200
valores bem próximos, tipo 1903 
e 98 e 1903 e 99, e talvez os 

70
00:03:58,360 --> 00:04:00,640
limites da faixa seguinte, 
também, tipo 2826 e 65 e 2826 e 

71
00:04:00,640 --> 00:04:11,480
66. 
Entendi foca onde a chance de 

72
00:04:11,480 --> 00:04:13,920
erro é maior e teste aleatório 
funciona. 

73
00:04:13,920 --> 00:04:16,760
Pegar valores ao acaso, Monte de
valores de uma. 

74
00:04:16,880 --> 00:04:20,760
Fácil e nenhum de uma classe 
crítica ou de um limite 

75
00:04:20,760 --> 00:04:23,200
importante. 
É menos sistemático. 

76
00:04:23,200 --> 00:04:27,240
Menos eficiente, né? 
Isso, as partições e os valores 

77
00:04:27,240 --> 00:04:31,000
limite costumam dar um resultado
melhor para chabugs funcionais, 

78
00:04:31,200 --> 00:04:33,320
ok? 
Essas técnicas ajudam a 

79
00:04:33,320 --> 00:04:35,960
verificar se o sistema faz o que
deveria, né? 

80
00:04:36,240 --> 00:04:39,320
A parte funcional. 
Mas e para garantir que ele 

81
00:04:39,320 --> 00:04:41,480
atende mesmo a necessidade do 
cliente? 

82
00:04:41,760 --> 00:04:43,960
Aí entra outra categoria 
importante. 

83
00:04:44,360 --> 00:04:48,760
Os testes de aceitação. 
Aceitação pelo nome, imagino que

84
00:04:48,760 --> 00:04:51,560
seja o cliente que faz. 
Exatamente. 

85
00:04:51,800 --> 00:04:56,200
O ponto chave é esse, são testes
realizados pelo cliente ou por 

86
00:04:56,200 --> 00:04:59,760
representantes dele, muitas 
vezes usando dados reais do dia 

87
00:04:59,760 --> 00:05:03,720
a dia da empresa. 
E o objetivo é determinar se o 

88
00:05:03,720 --> 00:05:07,120
cliente aceita o sistema, se ele
tá pronto para ir para a 

89
00:05:07,120 --> 00:05:10,600
produção, se resolve o problema 
que ele precisava resolver. 

90
00:05:11,080 --> 00:05:13,320
Aqui a gente fala mais de 
validação. 

91
00:05:13,840 --> 00:05:18,800
Construímos a coisa certa do que
só de verificação, construímos a

92
00:05:18,800 --> 00:05:21,400
coisa corretamente segundo a 
especificação. 

93
00:05:21,680 --> 00:05:26,040
Entendi a diferença, validação 
versus verificação e tem aquelas

94
00:05:26,040 --> 00:05:29,440
fases alfa e beta, não é? 
Sim, geralmente tem. 

95
00:05:29,800 --> 00:05:33,240
O teste alfa costuma ser feito 
primeiro num ambiente mais 

96
00:05:33,240 --> 00:05:37,200
controlado, talvez na máquina do
desenvolvedor ou num servidor de

97
00:05:37,200 --> 00:05:40,320
testes com um grupo pequeno de 
usuários mais próximos. 

98
00:05:40,480 --> 00:05:42,880
Para pegar os problemas mais 
óbvios, primeiro. 

99
00:05:42,880 --> 00:05:45,720
Isso. 
Se passar pelo alfa, aí vai para

100
00:05:45,720 --> 00:05:48,960
o teste beta. 
Esse já é num ambiente real do 

101
00:05:48,960 --> 00:05:52,640
cliente, com mais usuários para 
ver como o sistema se comporta 

102
00:05:52,640 --> 00:05:55,200
na vida real. 
Sabe pegar aqueles problemas que

103
00:05:55,200 --> 00:05:58,480
só aparecem no uso de verdade? 
Em métodos ágeis. 

104
00:05:58,480 --> 00:06:01,600
Isso está bem ligado ao Dan, né?
A história só está pronta quando

105
00:06:01,600 --> 00:06:04,640
passa na aceitação. 
Perfeitamente é um critério de 

106
00:06:04,640 --> 00:06:07,280
aceite fundamental. 
Muito bom. 

107
00:06:07,600 --> 00:06:11,160
Bom, além de testar o que o 
sistema faz, a gente precisa 

108
00:06:11,160 --> 00:06:15,560
garantir como ele faz, né? 
Performance, usabilidade. 

109
00:06:15,800 --> 00:06:20,680
Exato, chegamos nos testes de 
requisitos não funcionais, eles 

110
00:06:20,680 --> 00:06:22,880
olham para esses atributos de 
qualidade? 

111
00:06:23,120 --> 00:06:25,600
Tipo. 
Por exemplo, testes de 

112
00:06:25,600 --> 00:06:29,040
desempenho, como o sistema se 
comporta quando tem muita gente 

113
00:06:29,040 --> 00:06:32,360
usando ao mesmo tempo? 
A simular carga de uma Black 

114
00:06:32,360 --> 00:06:34,360
Friday num e Commerce, por 
exemplo. 

115
00:06:34,360 --> 00:06:36,480
Exatamente. 
Ele vai aguentar? 

116
00:06:36,480 --> 00:06:39,520
Vai ficar lento? 
Outro tipo são os testes de 

117
00:06:39,520 --> 00:06:42,800
usabilidade. 
A interface é fácil de usar, as 

118
00:06:42,800 --> 00:06:45,760
pessoas conseguem fazer o que 
precisam sem se perder. 

119
00:06:46,160 --> 00:06:50,120
Isso muitas vezes é feito 
observando usuários reais 

120
00:06:50,120 --> 00:06:53,280
tentando usar o sistema. 
Observando mesmo, né? 

121
00:06:53,360 --> 00:06:56,280
Vendo aonde a pessoa trava, 
aonde clica errado. 

122
00:06:56,280 --> 00:07:00,720
Isso e tem também os testes de 
falhas, às vezes chamados de 

123
00:07:00,720 --> 00:07:03,200
testes de robustez ou 
resiliência. 

124
00:07:03,840 --> 00:07:07,560
O que acontece se um serviço que
o sistema depende cair, se a 

125
00:07:07,560 --> 00:07:10,520
rede ficar instável, o sistema 
se recupera. 

126
00:07:10,840 --> 00:07:14,000
Ele lida bem com erros. 
Nossa, esses parecem bem 

127
00:07:14,000 --> 00:07:17,040
críticos também. 
E são porque um sistema pode 

128
00:07:17,040 --> 00:07:21,360
fazer tudo certo funcionalmente,
mas se ele for lento demais ou 

129
00:07:21,360 --> 00:07:25,560
muito difícil de usar ou viver 
caindo, ele não entrega valor de

130
00:07:25,560 --> 00:07:28,280
verdade. 
Pode até prejudicar o negócio, 

131
00:07:28,280 --> 00:07:31,040
né? 
Com certeza, então, testar esses

132
00:07:31,040 --> 00:07:34,880
atributos não funcionais. 
Velocidade, usabilidade, 

133
00:07:34,880 --> 00:07:39,600
robustez, segurança é essencial 
para garantir a qualidade total 

134
00:07:39,600 --> 00:07:42,640
da experiência e a 
confiabilidade do software lá na

135
00:07:42,640 --> 00:07:45,320
ponta, complementa. 
Tudo que a gente falou antes. 

136
00:07:45,480 --> 00:07:49,680
Faz todo sentido uma visão bem 
completa da qualidade. 

137
00:07:50,000 --> 00:07:51,920
Cobrimos bastante coisa hoje, 
Hein? 

138
00:07:52,240 --> 00:07:55,600
Das técnicas de caixa preta e 
branca, seleção de dados. 

139
00:07:55,920 --> 00:08:00,040
Até aceitação e não funcionais. 
Foi uma boa passada geral sim. 

140
00:08:00,120 --> 00:08:03,000
Ótimo, agradecemos a quem 
acompanhou essa análise com a 

141
00:08:03,000 --> 00:08:06,400
gente. 
Valeu até a próxima exploração.