QA Engineer, o que faz? com Demis Meneghetti – O Trabalho do QA no Time de Desenvolvimento #89

1
00:00:00,000 –> 00:00:12,200
Fala pessoal, bem vindos ao TPA, Gabriel Rubens aqui e hoje com mais um episódio sobre profissões

2
00:00:12,200 –> 00:00:17,720
e o papel de hoje vai ser o do QA e quem vai falar pra gente sobre esse papel vai ser o

3
00:00:17,720 –> 00:00:24,080
Demis Meneghetti que já tem mais ou 13 anos de experiência já na área, conhece o modelo

4
00:00:24,080 –> 00:00:29,200
de fábrica de software, conhece o modelo de testes ágeis e vem evoluindo na carreira

5
00:00:29,200 –> 00:00:34,360
e tem muita coisa pra compartilhar hoje aqui com a gente nesse episódio, tudo bem Demis?

6
00:00:34,360 –> 00:00:38,640
Tudo bem Gabriel e você cara? Graças a Deus tudo certo por aqui.

7
00:00:38,640 –> 00:00:44,200
Tá tudo ótimo, então bora lá. Acho que antes da gente passar pro trabalho do QA né,

8
00:00:44,200 –> 00:00:52,000
começar pedindo pra você falar um pouco sobre quem é você, como chegou até aí como QA specialist.

9
00:00:52,000 –> 00:01:00,200
Bom eu sou o Demis Meneghetti que você já me apresentou, eu acho até que pra ser um

10
00:01:00,200 –> 00:01:07,720
pouco mais inclusivo aqui né, eu sou careca, sou de barba, uso barba, minha barba é branquinha aqui

11
00:01:07,720 –> 00:01:17,800
pra quem tiver ouvindo e não tiver vendo a imagem, sou gordinho né, peso uns 96 kg aqui e tenho 1,80

12
00:01:17,800 –> 00:01:25,000
kg que atrás de mim tem uma estantezinha com alguns livros, umas passas com documentos e eu

13
00:01:25,000 –> 00:01:33,240
tô na área de QA, já há 13 anos trabalhando nessa área, anterior a isso eu sempre trabalhei em

14
00:01:33,240 –> 00:01:40,520
escritora de advocacia, voltado mais a serviços administrativos né, e nos últimos tempos nesse

15
00:01:40,520 –> 00:01:50,040
período de advocacia eu cuidava da parte de suporte ao usuário, suporte de TI mesmo né, dentro do

16
00:01:50,040 –> 00:01:56,240
escritório atendendo os advogados da empresa né, dando todo suporte na parte operacional ali de

17
00:01:56,240 –> 00:02:06,280
computadores né. E aí nesse, no momento que eu saí de férias lá, eu tinha uma pessoa conhecida na

18
00:02:06,280 –> 00:02:12,960
internet que me recomendou para uma entrevista, eu fui sem conhecimento nenhum, me apresentei,

19
00:02:12,960 –> 00:02:17,760
falei o que eu gostava, o que eu não gostava e recebi minha primeira oportunidade ali mesmo sem

20
00:02:17,760 –> 00:02:26,280
experiência lá em 2009, para trabalhar no Banco Santander e startar a carreira totalmente do zero

21
00:02:26,280 –> 00:02:33,880
né, então fui treinado, fui formado como QA, daí pra frente fui sempre estudando coisas novas e

22
00:02:33,880 –> 00:02:41,840
mais para chegar até aqui hoje. Caramba, bastante tempo mesmo já dentro da mesma área hein, que legal.

23
00:02:41,840 –> 00:02:45,600
Então é que bom porque tu vai ter muita experiência aí para contar para gente né,

24
00:02:45,600 –> 00:02:53,320
qual que é o papel do QA. Então cara, eu queria também saber como que é a estrutura do time que

25
00:02:53,320 –> 00:03:00,680
você trabalha hoje sabe, tipo quantos developers, quantos QA’s, sei lá, gestor, scrum master,

26
00:03:00,680 –> 00:03:04,640
qual que é a organização do trabalho mesmo, porque eu acho que vai ficar mais fácil as pessoas

27
00:03:04,640 –> 00:03:09,360
visualizarem daqui para frente tudo que a gente falar, de qual que é o contexto que tu está inserido.

28
00:03:09,360 –> 00:03:16,280
Bacana, bom eu estou inserido dentro de um time ágil né, então o meu time tem cinco desenvolvedores,

29
00:03:16,280 –> 00:03:24,160
tem um Product Owner né, o Product Manager e o Tech Lead né, então nós somos cinco, seis,

30
00:03:24,160 –> 00:03:33,200
oito pessoas dentro do time, trabalhando no produto e eu como QA faço parte do Dev Team,

31
00:03:33,200 –> 00:03:39,280
inserido no time e também fico ali fazendo a ponte entre as informações que chegam através

32
00:03:39,280 –> 00:03:47,600
do nosso Product Manager para a equipe, criando artefatos para a equipe poder produzir um novo

33
00:03:47,600 –> 00:03:55,240
produto para a software. Tá bom, então sabendo agora como que é o ambiente que tu está, eu queria saber

34
00:03:55,240 –> 00:04:04,160
como que é o teu trabalho, tu falou de duas coisas aí né, tu falou do suporte ali com o Product Manager

35
00:04:04,160 –> 00:04:09,560
ou com o Product Owner e depois o trabalho com a equipe né, eu queria saber qual que é esse suporte e

36
00:04:09,560 –> 00:04:14,680
como que é na prática o que tem que fazer sabe, ele passa uma demanda para ti, tu controla junto

37
00:04:14,680 –> 00:04:20,800
com essa pessoa de produto, como que é? Bacana, no decorrer do nosso papo aqui a gente vai falar da

38
00:04:20,800 –> 00:04:29,680
evolução do papel do QA né, porque nos dias atuais o QA é um cara ali mais próximo do usuário, com uma

39
00:04:29,680 –> 00:04:37,360
visão mais profunda ali daquele produto que está sendo validado, desenvolvido, testado e colocado

40
00:04:37,360 –> 00:04:43,880
em produção para o usuário testar, então o QA é um grande conhecedor assim como o Fio do produto né,

41
00:04:43,880 –> 00:04:51,120
porque as vezes o QA sabe muito mais do produto do que o próprio Fio, porque o Fio entende muito da regra

42
00:04:51,120 –> 00:04:56,840
de negócio para aquela aplicação, mas o QA é o cara que testa, é o cara que usa, é o cara que valida,

43
00:04:56,840 –> 00:05:03,720
que está o tempo inteiro ali transacionando as operações daquela aplicação, então no contexto atual

44
00:05:03,720 –> 00:05:11,760
hoje o papel do QA vem pensando numa esteira de desenvolvimento né, então o QA ele está de ponta

45
00:05:11,760 –> 00:05:20,440
dentro dessa esteira né, então pensa que o Product Manager ele vem com um pedido né, eu como QA faço

46
00:05:20,440 –> 00:05:26,160
uma espécie de uma entrevista para esse Product Manager perguntando para que serve, quem é o usuário,

47
00:05:26,160 –> 00:05:33,880
quantas pessoas vão acessar simultaneamente, se o serviço vai ficar 24 por 7, se ele desliga e desliga,

48
00:05:33,880 –> 00:05:43,280
se vai ter login para acesso, se a gente vai ter log de acesso das transações, faço uma bateria de perguntas ali

49
00:05:43,280 –> 00:05:51,840
e através dessas perguntas eu faço com que o PO traga uma demanda ali muito mais rica de informações

50
00:05:51,840 –> 00:05:57,920
para que o time seja, para que o projeto, para que aquela demanda seja desenvolvida pelo time.

51
00:05:57,920 –> 00:06:08,160
E aí esse é o primeiro momento né, pensando ali só no na parte do time né, de quando esse conteúdo

52
00:06:08,160 –> 00:06:16,440
chega para o time trabalhar, e aí em cima disso daí eu começo a questionar o PO sobre critérios de aceite né,

53
00:06:16,440 –> 00:06:25,000
o que para ele ele considera uma aplicação ok depois de desenvolvida né, então de repente estamos falando

54
00:06:25,000 –> 00:06:33,560
de uma aplicação que faz uma transferência bancária, e aí é o site do Banco X, você está com um fundinho roxo,

55
00:06:33,560 –> 00:06:38,400
vamos falar que a gente está no aplicativo do Nubank e você precisa fazer uma transferência,

56
00:06:38,400 –> 00:06:43,480
quais transferências, quais tipos de transferência? Existe transferência de conta para conta,

57
00:06:43,480 –> 00:06:50,200
existe TED de uma conta para outra, agora a gente tem o PIX, a gente pode fazer DOC, a gente pode ter uma infinita,

58
00:06:50,200 –> 00:06:56,960
infinitas não, mas nós temos diversas modalidades de transferências, e aí o PO vai me dizer,

59
00:06:56,960 –> 00:07:04,000
olha para eu considerar que esse modelo de transferência aí, que essa transação de transferência está ok,

60
00:07:04,000 –> 00:07:10,720
a aplicação precisa fazer pelo menos transferências entre contas nesse primeiro momento né,

61
00:07:10,720 –> 00:07:17,720
pensando no modelo startup aí, onde o aplicativo do Nubank antes era só uma conta, e ele foi evoluindo com o tempo,

62
00:07:17,720 –> 00:07:24,600
qualquer software hoje em dia, a grande maioria dos softwares trabalhando em um contexto ágil acontece dessa mesma forma,

63
00:07:24,600 –> 00:07:31,120
então são adicionadas novas funcionalidades naquela aplicação, e aí uma vez que ele me deu um critério de aceite,

64
00:07:31,120 –> 00:07:39,440
de que olha, preciso pelo menos fazer uma transferência entre contas, eu como que a vou pensar em cenários

65
00:07:39,440 –> 00:07:44,800
para essa transferência, então por exemplo, o Demis vai fazer uma transferência para o Gabriel,

66
00:07:44,800 –> 00:07:49,320
ele consegue fazer uma transferência de mil reais se ele tiver só cem na conta?

67
00:07:49,320 –> 00:07:59,560
Não deveria, mas e se o Demis tivesse pré-aprovado um crédito de limite por exemplo, ele conseguiria? Conseguiria.

68
00:07:59,560 –> 00:08:05,480
O saldo dele ficaria negativo, e aí eu tenho que pensar num monte de cenários que eu vou criar ali,

69
00:08:05,480 –> 00:08:12,320
eu posso utilizar, hoje é muito famoso aí o BDD, que todo mundo fala BDD, que é o Behavior Driven Development,

70
00:08:12,320 –> 00:08:19,800
que é desenvolvimento guiado por comportamento, então eu vou simular diversos comportamentinhos ali que o usuário vai fazer,

71
00:08:19,800 –> 00:08:26,160
então dado que eu tenho uma conta com saldo negativo, e eu tente fazer uma transferência para o Gabriel,

72
00:08:26,160 –> 00:08:32,400
aí o resultado esperado é tipo, não poderei fazer a transferência dado que eu não tenho um saldo,

73
00:08:32,400 –> 00:08:40,360
dado que eu tenho um saldo de mil reais, um outro cenário, e queira transferir cem reais para o Gabriel,

74
00:08:40,360 –> 00:08:48,400
então eu deveria ter o saldo reajustado para novecentos, e o saldo do Gabriel incrementado em cem.

75
00:08:48,400 –> 00:08:54,200
Então eu vou criando diversos cenários, e aí quando o time desenvolvimento pega aquilo, ele fala,

76
00:08:54,200 –> 00:08:59,440
opa, olha aqui tem esse cenário que faz isso, tem outro cenário que transfere cem dinheiro,

77
00:08:59,440 –> 00:09:06,040
tem um cenário que transfere e devita, tem um cenário que ele transfere e o dinheiro sai do limite da conta,

78
00:09:06,040 –> 00:09:15,080
e aí o desenvolvedor fala, pô, então eu tenho que criar uma variável para o saldo, uma variável para o limite,

79
00:09:15,080 –> 00:09:24,080
uma flag de repente para tem limite ou não tem limite, e aí ele vai, em cima disso daí, ele vai construindo a codificação dele.

80
00:09:24,080 –> 00:09:32,520
E depois, essa é a primeira parte do processo, do QA, e aí depois a gente tem diversas outras,

81
00:09:32,520 –> 00:09:42,000
então eu falei só o inicial, eu continuo aqui, você acha que eu devo falar aqui direto ou você tem perguntas aí em cima desse início do desenvolvimento?

82
00:09:42,000 –> 00:09:47,000
Não, continua, continua, vamos lá. Então vamos só sumarizar e aí deixa eu ver se eu entendi certo.

83
00:09:47,000 –> 00:09:55,400
Então, na primeira parte o teu papel é suportar o Product Owner, ou a pessoa de produto, para que ela consiga,

84
00:09:55,400 –> 00:10:03,400
para que você ajude essa pessoa a criar todos os casos, a traduzir tudo aquilo em caso de testes, certo?

85
00:10:03,400 –> 00:10:10,000
Para pensar qual é o cenário ideal e qual poderia ser o cenário de falha, e aí tu já ajuda essa pessoa até a pensar,

86
00:10:10,000 –> 00:10:17,400
quando é erro, o que acontece, quais são os erros, e isso vai também servir de instrumento para a equipe,

87
00:10:17,400 –> 00:10:23,600
tu faz essas duas conexões de sai do produto, a gente tem uma conversa, isso vira alguma coisa, um artefato,

88
00:10:23,600 –> 00:10:29,600
você pode dizer qual é o nome, mas tu até comentou aí do desenvolvimento guiado por comportamento?

89
00:10:29,600 –> 00:10:40,600
Um artefato pode ser qualquer coisa, pode ser um BDD, o BDD é só um método, muitas pessoas confundem,

90
00:10:40,600 –> 00:10:46,600
falam, automatiza em BDD, não existe isso, BDD é um método, que é um desenvolvimento guiado por comportamento,

91
00:10:46,600 –> 00:10:55,600
o BDD, como que eu escrevo meus cenários? Eu escrevo utilizando uma linguagem que se chama Gertrude, que é uma linguagem que em português é dado quando então,

92
00:10:55,600 –> 00:11:05,600
que é o pré-requisito, ação e resultado esperado, ou se não, given when then, em inglês, quando a gente escreve,

93
00:11:05,600 –> 00:11:15,600
então dado que o Demis tenha zero na conta dele, quando ele fizer uma transferência de 100 reais, então não será permitido a transferência,

94
00:11:15,600 –> 00:11:23,600
então eu vou criar vários cenarizinhos desse tipo, que serão os meus casos de teste, isso se eu utilizar o método BDD, eu posso não utilizar,

95
00:11:23,600 –> 00:11:32,600
eu posso simplesmente criar uma, eu falo muito aqui para os alunos do meu treinamento aqui, que a gente tem que pensar no modelo ágil,

96
00:11:32,600 –> 00:11:39,600
o modelo ágil fala assim, olha, se eu tiver um papel de pão eu consigo fazer, uma caneta e um papel de pão eu saio fazendo,

97
00:11:39,600 –> 00:11:48,600
então eu não posso me prender a uma ferramenta, eu não posso me prender a um framework de desenvolvimento, eu tenho que simplesmente descrever

98
00:11:48,600 –> 00:11:57,600
de forma que o meu time vai entender, então eu posso abrir uma panela de Excel e falar, para as transações validadas com saldo igual a zero,

99
00:11:57,600 –> 00:12:12,600
não deverá fazer a transferência, o saldo deve ser retirado do saldo inicial e incrementado na segunda conta, então eu posso fazer de várias formas isso,

100
00:12:12,600 –> 00:12:22,600
isso daí é uma coisa que o QA, como conhecedor dessas ferramentas e técnicas, ele leva para o time e junto com o time discute,

101
00:12:22,600 –> 00:12:31,600
cara, time, o que vocês acham melhor a gente utilizar, vamos utilizar dessa forma, vamos utilizar daquela, o que para vocês é mais fácil,

102
00:12:31,600 –> 00:12:41,600
e aí o time discute, se o time falar assim, me traz uma planilha de Excel, ok, o importante é o time ter isso organizado de forma que vai ficar

103
00:12:41,600 –> 00:12:53,600
entendível para todos, e aí pode ser VDD, pode ser planilha, pode ser caso de teste usando ferramentas como o TestRay ou XRay no Jira,

104
00:12:53,600 –> 00:13:05,600
tem um monte de, o Bugzilla que é uma ferramenta da Firefox, da Mozilla, tem diversas ferramentas que a gente pode fazer essa gestão escrita

105
00:13:05,600 –> 00:13:14,600
desses cenários. Sim, legal, então, entendi essa primeira parte, e aí você estava falando, antes da minha, da minha,

106
00:13:14,600 –> 00:13:21,600
da minha sumarização, sobre como que é para a equipe, então passa essa primeira parte, tu entrega algum artefato para eles,

107
00:13:21,600 –> 00:13:28,600
que você falou das várias formas que podem ser, e aí eu trabalho com a equipe, tá, antes da gente passar para o teu trabalho depois,

108
00:13:28,600 –> 00:13:37,600
de alguma coisa você entrega, mas qual que é o teu trabalho durante o desenvolvimento do software? Certo, uma vez que a gente fez esses

109
00:13:37,600 –> 00:13:45,600
critérios, a gente vai juntar isso numa planning, ou num refinement, e a gente vai discutir esses artefatos junto com o time,

110
00:13:45,600 –> 00:13:54,600
junto com a demanda, junto com o POA, a gente já vai chegar nessa reunião com muito mais informação, porque eu como QA,

111
00:13:54,600 –> 00:14:00,600
já fui lá na frente, extraí tudo que eu podia do Product Owner, e na hora que eu chego nessa reunião, eu chego com muito material

112
00:14:00,600 –> 00:14:07,600
para discussão, e aí a gente passa a discutir, e não quer dizer que tudo que eu preparei lá na frente está certo, eu posso chegar na reunião

113
00:14:07,600 –> 00:14:15,600
e terem outras questões que eu não me atentei, ou que eu não tinha informação, e a gente ali dentro do refinement de trabalho,

114
00:14:15,600 –> 00:14:21,600
aqui, se você for algo de simples resolver, a gente já alinha ali, e segue à frente, senão a gente volta para trás com o POA,

115
00:14:21,600 –> 00:14:27,600
e o POA vai buscar essa informação na área de negócio, no cliente dele, para que a gente passe a desenvolver.

116
00:14:27,600 –> 00:14:35,600
Uma vez que isso está feito, que a gente sentou, olha, está isso mesmo, os cenários são esses, vamos desenvolver, qual que é o problema que eu passo?

117
00:14:35,600 –> 00:14:45,600
O desenvolvedor começa a codificar, e aí eu como QA, o meu desejo ali de implementar, de melhorar a qualidade do processo,

118
00:14:45,600 –> 00:14:52,600
a gente tem uma outra técnica que chama TDD, que é Test Driven Develop, que é desenvolvimento guiado por teste.

119
00:14:52,600 –> 00:15:00,600
Então eu posso como QA, sentar junto com o meu dev ali, e falar, olha, você vai começar a codificar, que tal a gente começar pelos testes?

120
00:15:00,600 –> 00:15:07,600
E aí eu começo ali junto com ele, fazendo já os testes unitários para aqueles métodos que ele vai criar para a minha aplicação.

121
00:15:07,600 –> 00:15:15,600
E eu posso fazer isso com todos os devs, a gente pode fazer isso em formato de per-programming, a gente pode fazer isso

122
00:15:15,600 –> 00:15:21,600
simplesmente com esse artefato que eu entreguei para ele, que tinha os testes, e dali daqueles testes ele vai extrair, olha,

123
00:15:21,600 –> 00:15:27,600
desses 50 testes que você me escreveu, 15 aqui eu consigo fazer teste unitário.

124
00:15:27,600 –> 00:15:34,600
Então você não precisa considerar esses 15 aqui para os demais testes, porque quando a gente fala de teste, a gente tem uma pirâmide de teste.

125
00:15:34,600 –> 00:15:43,600
Para quem não conhece a área de qualidade, a pirâmide de teste basicamente é uma pirâmide, mesmo imaginem uma pirâmide,

126
00:15:43,600 –> 00:15:49,600
e ela é separada por camadas. Então a camada inferior, que vai ser a camada mais larga, a base da pirâmide,

127
00:15:49,600 –> 00:15:55,600
ela é composta de testes unitários, que a maioria dos testes vão estar naquela camada.

128
00:15:55,600 –> 00:16:00,600
Depois a gente vem para testes de componente, depois a gente vem para testes de integração,

129
00:16:00,600 –> 00:16:06,600
testes de sistema, e por último a gente vai ter o teste de interface, que é o teste visual,

130
00:16:06,600 –> 00:16:10,600
quando eu tenho um app na minha mão no celular, quando eu tenho uma página web que eu vou testar.

131
00:16:10,600 –> 00:16:19,600
Então eu tenho, lá no começo eu criei esses 50 casos de teste, e eu vou ter que distribuir esses 50 casos de teste,

132
00:16:19,600 –> 00:16:25,600
olhando para essa pirâmide. Ah, nesse caso de teste aqui eu consigo cobrir ele na camada de teste unitário?

133
00:16:25,600 –> 00:16:31,600
Consigo? Não consigo? Em qual camada acima eu consigo? E eu vou diluindo essa lista dentro dessa pirâmide.

134
00:16:31,600 –> 00:16:40,600
Por que a gente olha para a pirâmide? Porque quanto mais baixo nessas camadas da pirâmide,

135
00:16:40,600 –> 00:16:48,600
mais rápido vai ser construir, mais fácil vai ser a manutenção desse teste, e mais rápido vai ser a execução.

136
00:16:48,600 –> 00:16:53,600
E quando a gente está em um time ágil, é muito importante a gente ter um feedback rápido

137
00:16:53,600 –> 00:17:01,600
daquela aplicação, se ela funciona ou não funciona. Então é nesse momento que o QA senta ali com o time

138
00:17:01,600 –> 00:17:07,599
e começa a desenvolver a primeira camada de baixo, inferior, da pirâmide de teste.

139
00:17:07,599 –> 00:17:11,599
E aí depois a gente continua trabalhando e diluindo nas demais camadas.

140
00:17:11,599 –> 00:17:19,599
E tu consegue, sei que é uma pergunta talvez difícil de trazer na prática, mas se tu tiver algum exemplo

141
00:17:19,599 –> 00:17:27,599
de qual tipo de teste você deixaria para a parte de teste de unidade, como você falou, é o teste muito mais rápido

142
00:17:27,599 –> 00:17:32,600
que o desenvolvedor vai fazer ali, ele já vai ter um feedback se o que ele está fazendo está quebrando ou não o código

143
00:17:32,600 –> 00:17:37,600
ou a regra de negócio. E o que tu colocaria nas próximas camadas também?

144
00:17:37,600 –> 00:17:42,600
Bom, basicamente, eu colocaria nas camadas inferiores tudo o que fosse possível.

145
00:17:42,600 –> 00:17:50,600
Então imagina que eu estou preenchendo um campo de login e senha, e aí eu coloco só o meu email no campo de login

146
00:17:50,600 –> 00:17:57,600
e não coloco a senha e clico no botão logar. Isso daí tem que me dar uma mensagem de erro, falando

147
00:17:57,600 –> 00:18:04,600
opa, email ou senha inválidos, ou o campo não pode ficar em branco. Eu consigo validar isso no teste unitário?

148
00:18:04,600 –> 00:18:10,600
Consigo. Então eu posso ter no teste unitário do código front, do back-end e posso ter no teste unitário

149
00:18:10,600 –> 00:18:17,600
do front-end. Eu consigo ter teste unitário nessas duas camadas e eu posso validar isso também de forma manual

150
00:18:17,600 –> 00:18:24,600
utilizando, eu posso validar de forma automatizada através da interface. Mais uma vez que eu sei que esse teste

151
00:18:24,600 –> 00:18:32,600
está coberto na camada unitária, eu não preciso me preocupar em fazer esse teste ali na camada de teste de regressão

152
00:18:32,600 –> 00:18:40,600
que a gente chama. É aquela bateria de teste que é executada toda vez que é feita uma alteração em qualquer parte

153
00:18:40,600 –> 00:18:46,600
do código para garantir que tudo que estava funcionando antes continua funcionando mesmo após aquela alteração.

154
00:18:49,600 –> 00:18:59,600
Entendi. E qual camada que tu atua mais na prática? Porque se eu entendi bem o teste de unidade você vai dar suporte

155
00:18:59,600 –> 00:19:07,600
no TDD, no teste de unidade ali ao desenvolvedor. E qual camada normalmente no teu contexto já para de ser o dev

156
00:19:07,600 –> 00:19:11,600
e passa a ser o QA mesmo a fazer o teste?

157
00:19:11,600 –> 00:19:17,600
A partir da camada de sistema. A partir da camada de sistema, pensando em microserviços eu vou ter uma API.

158
00:19:17,600 –> 00:19:23,600
Bom, para quem não sabe o que é uma API, pense em você como cliente de um restaurante. Você chega num restaurante

159
00:19:23,600 –> 00:19:30,600
e você é atendido por um garçom. O garçom vai te perguntar o que você quer, você vai informar o que você quer,

160
00:19:30,600 –> 00:19:37,600
ele vai até a cozinha, pede para a cozinha e traz o seu pedido. Então o garçom representa uma API.

161
00:19:37,600 –> 00:19:45,600
E o que é uma API? É uma Application Program Interface, que é uma interface de programa de uma aplicação.

162
00:19:45,600 –> 00:19:51,600
Então imagina quando você entra no Google, você vê a tela do Google ali e aquela lá, aquilo ali é o seu front-end,

163
00:19:51,600 –> 00:19:59,600
a sua tela. E quando você preenche a sua pesquisa lá e clica no botão pesquisar, aquela interface vai ter por trás dela

164
00:19:59,600 –> 00:20:06,600
uma API, que seria o nosso garçom, que vai lá no servidor do Google, pega as informações e entrega aqui para a gente.

165
00:20:06,600 –> 00:20:14,600
Então isso é uma API. E aí o QA, no papel do QA, eu consigo já, a partir do momento que essa API é disponibilizada pelo time,

166
00:20:14,600 –> 00:20:22,600
eu consigo interagir com essa API através de ferramentas que a mais comum de todas é o Postman, que a gente faz de forma manual,

167
00:20:22,600 –> 00:20:30,600
posso até automatizar testes dentro do Postman e eu posso usar outros plugins, até para o VS Code.

168
00:20:30,600 –> 00:20:36,600
O VS Code é como se fosse o Word dos desenvolvedores, onde o desenvolvedor escreve os códigos dele.

169
00:20:36,600 –> 00:20:43,600
E aí tem alguns plugins que você instala no VS Code que você pode fazer a mesma transação, assim como no Postman,

170
00:20:43,600 –> 00:20:54,600
que é a ferramenta que a gente utiliza, que tem uma interface, e eu falo, olha, API, eu quero que você me traga todos os ouvintes do podcast,

171
00:20:54,600 –> 00:21:03,600
tudo para o Aldo, e ele vai me trazer toda a lista de ouvintes. E aí você pode ter inúmeras transações nessa API.

172
00:21:03,600 –> 00:21:10,600
E daí para frente eu consigo eu com o QA testar. Eu posso fazer isso de forma manual, usando o Postman,

173
00:21:10,600 –> 00:21:15,600
posso fazer isso de forma automatizada, e aí vai depender da linguagem de programação utilizada,

174
00:21:15,600 –> 00:21:20,600
eu vou ter um framework específico para cada uma dessas linguagens.

175
00:21:20,600 –> 00:21:26,600
E aí depois da camada de API, eu vou ter a outra camada, que é a camada da interface, que eu vou testar também,

176
00:21:26,600 –> 00:21:32,600
com o framework específico para cada linguagem de programação, mas aí eu já vou estar testando um front-end,

177
00:21:32,600 –> 00:21:41,600
uma tela, onde eu posso interagir e ver comportamentos visuales.

178
00:21:41,600 –> 00:21:49,600
Deixa eu te perguntar uma coisa, porque mais ou menos dois anos atrás, pandemia, comecei no meio, tempo sobrando em casa,

179
00:21:49,600 –> 00:21:54,600
comecei a programar de novo e estava fazendo um sistema para controlar ações.

180
00:21:54,600 –> 00:22:02,600
Não tinha nenhum sistema que não fosse tão caro que dava para controlações de diferentes regiões, eu comecei a programar aquilo.

181
00:22:02,600 –> 00:22:07,600
Fui pegando as APIs, juntando tudo e fui fazendo o que eu queria.

182
00:22:07,600 –> 00:22:14,600
Quando eu comecei a fazer os testes, os de unidades eram simples, dava para fazer, mas quando eu ia para outra camada,

183
00:22:14,600 –> 00:22:20,600
eu ficava na dúvida de se eu fazia da API, ali dos controllers, ou se eu ia para a tela principal,

184
00:22:20,600 –> 00:22:26,600
que era muito mais caro, tempo de fazer ele, quebra muito mais fácil que toda hora que eu mudo o layout,

185
00:22:26,600 –> 00:22:35,600
mas depois de um tempo testando, eu, não sou programador faz um tempo, então estava ali aprendendo, brincando com as coisas,

186
00:22:35,600 –> 00:22:42,600
mas eu acabei decidindo ficar só com o layout, porque o da API não cobria muita coisa.

187
00:22:42,600 –> 00:22:48,600
Fiquei, se eu tiver que fazer os dois, eu vou gastar muito tempo, então eu vou priorizar uma aqui, eu vou priorizar unidade,

188
00:22:48,600 –> 00:22:54,600
e o da tela mesmo, que era simular o uso do usuário final.

189
00:22:54,600 –> 00:23:03,600
O que eu fiz, normalmente, o que eu vou encontrar no mercado, ou foi minha, vamos dizer, minha amadorice,

190
00:23:03,600 –> 00:23:09,600
a falta de conhecimento, que me levou a fazer isso? O que você vê normalmente no seu dia a dia?

191
00:23:09,600 –> 00:23:13,600
Você vai testar mais a coisa na prática, lá no final, ou mais na API?

192
00:23:13,600 –> 00:23:19,600
O que você vai ver no mercado mais é testando, nem vai ter muito, pouca gente faz testes unitários,

193
00:23:19,600 –> 00:23:23,600
então o que você vai ver mais é a pessoa testando lá no final.

194
00:23:23,600 –> 00:23:28,600
E aí, qual é o problema disso? Uma vez que você tem uma aplicação muito grande,

195
00:23:28,600 –> 00:23:34,600
a quantidade de testes que você tem no front-end, por ele executar muito mais lento,

196
00:23:34,600 –> 00:23:39,600
o seu feedback vai demorar muito mais, e você, de repente, o que vai acontecer?

197
00:23:39,600 –> 00:23:44,600
Quando a gente está testando uma tela, pode acontecer de ela demorar para carregar,

198
00:23:44,600 –> 00:23:50,600
e aí o teste falha, o time-out, tem inúmeros que a gente chama de flick test,

199
00:23:50,600 –> 00:23:57,600
que são os testes que falham, mas não foi porque a aplicação está com problema,

200
00:23:57,600 –> 00:24:00,600
e sim a automação ali precisa ser ajustada.

201
00:24:00,600 –> 00:24:04,600
E isso já aconteceu comigo, eu trabalhava na Senova, que hoje em dia é a Via Parejo,

202
00:24:04,600 –> 00:24:11,600
e a gente testava todos os sites da Casbahia, Ponto Frio, Extra, até o site da Nike,

203
00:24:11,600 –> 00:24:18,600
era tudo na plataforma da Via Parejo, e aí os testes demoravam quatro horas para executar,

204
00:24:18,600 –> 00:24:26,600
e aí se falhava um teste, como você faz? Você vai confiar, e aí você vai lá e executa só aquele teste,

205
00:24:26,600 –> 00:24:30,600
como que fica? Só que quatro horas é muito tempo,

206
00:24:30,600 –> 00:24:35,600
porque no tempo que eu trabalhava na última empresa anterior aqui em Portugal,

207
00:24:35,600 –> 00:24:40,600
o nosso feedback era de menos de dez minutos, então é uma coisa bem diferente,

208
00:24:40,600 –> 00:24:46,600
e mesmo assim já aconteceu vários casos do time de desenvolvimento ter tanta confiança,

209
00:24:46,600 –> 00:24:54,600
entre aspas, de que aquilo estava ok, de desligar a automação, a validação da automação de teste,

210
00:24:54,600 –> 00:24:58,600
e colocar aquilo em produção, porque era um problema muito urgente, ou coisa do tipo,

211
00:24:58,600 –> 00:25:04,600
e depois remediar aquilo se fosse necessário. Então o que você vai ver de mais comum

212
00:25:04,600 –> 00:25:10,600
é uma bateria de teste muito grande na última camada, que é a camada da interface,

213
00:25:10,600 –> 00:25:15,600
o que é um erro bastante grave e que custa muito dinheiro. E tempo.

214
00:25:15,600 –> 00:25:21,600
É, dez minutos não é… é lento, né? Porque o que tu falou também,

215
00:25:21,600 –> 00:25:27,600
esses testes eu rodava quando eu ia fazer o request, quando eu mandava para o Git, rodava ele,

216
00:25:27,600 –> 00:25:32,600
porque eu comecei com… na minha máquina, né? Eu estava numa plataforma na Cloud, na…

217
00:25:32,600 –> 00:25:35,600
na Blu, eu esqueci o nome dela, mas enfim, e ele era lento, eu falei,

218
00:25:35,600 –> 00:25:39,600
não dá para ficar programando e parando, né? No começo era, sei lá, dois minutos?

219
00:25:39,600 –> 00:25:41,600
Mas dois minutos é muito lento.

220
00:25:41,600 –> 00:25:44,600
Dez minutos é o tempo da pipeline, né?

221
00:25:44,600 –> 00:25:45,600
Sim, da pipeline inteira, eu sei.

222
00:25:45,600 –> 00:25:50,600
É, correr dez minutos vai correr todos os testes e cai na produção.

223
00:25:50,600 –> 00:25:53,600
Normalmente os testes de um etário correm em segundos, né?

224
00:25:53,600 –> 00:25:54,600
Segundos, sim.

225
00:25:54,600 –> 00:26:00,600
Segundos, é… eu acho que ele gerava em torno de 12 segundos a bateria de teste.

226
00:26:00,600 –> 00:26:01,600
Ah, todos eles?

227
00:26:01,600 –> 00:26:07,600
Os testes unitários, né? Aí, conforme você vai subindo, mais lento vai ficando.

228
00:26:07,600 –> 00:26:13,600
Mas não… mas não chega a ficar mais de três minutos, assim, a partir de testes.

229
00:26:13,600 –> 00:26:14,600
Só um teste, né?

230
00:26:14,600 –> 00:26:15,600
Entendi.

231
00:26:15,600 –> 00:26:16,600
Rodando e executando.

232
00:26:16,600 –> 00:26:20,600
Entendi, então é muito da minha pequena experiência fazendo eles também,

233
00:26:20,600 –> 00:26:24,600
é que qualquer modificaçãozinha, às vezes, no JavaScript, aí quebrava.

234
00:26:24,600 –> 00:26:28,600
Mas o que tu falou, né? Vai, vai.

235
00:26:28,600 –> 00:26:32,600
Não, é que aparentemente quando a gente fala assim, o que você está falando?

236
00:26:32,600 –> 00:26:35,600
Você fez uma aplicação e você foi testar.

237
00:26:35,600 –> 00:26:40,600
Você fez o teste unitário, bacana, volta rapidinho, e eu vou testar a minha interface.

238
00:26:40,600 –> 00:26:42,600
É meio que parece óbvio, né? Tipo, não.

239
00:26:42,600 –> 00:26:44,600
O que eu vou entregar para o usuário é uma interface.

240
00:26:44,600 –> 00:26:48,600
Eu vou testar a interface, a interface está ok quando para frente está em produção, beleza.

241
00:26:48,600 –> 00:26:55,600
Só que quando você está com uma aplicação pequena, ok, isso funciona, que é uma beleza, vai embora.

242
00:26:55,600 –> 00:26:58,600
Mas imagina que sua aplicação vai crescendo, como a gente se referiu aqui,

243
00:26:58,600 –> 00:27:00,600
ao aplicativo do Nubank.

244
00:27:00,600 –> 00:27:05,600
Antes era só um mano conta, depois começou a fazer transferência só entre contas Nubank.

245
00:27:05,600 –> 00:27:09,600
Depois começou a fazer transferência entre outros bancos, depois veio cartão de crédito,

246
00:27:09,600 –> 00:27:13,600
depois veio o TEDPIX, veio todas as outras ações.

247
00:27:13,600 –> 00:27:17,600
Então imagina você validar tudo isso de forma na interface.

248
00:27:17,600 –> 00:27:25,600
Vai começar a sobrecarregar ali de tempo, essa sua pipeline de teste, de correr para colocar aquela aplicação em produção,

249
00:27:25,600 –> 00:27:27,600
vai começar a ficar muito demorado.

250
00:27:27,600 –> 00:27:31,600
E aí o que vai acontecer? Vamos falar, aonde está demorando mais aqui?

251
00:27:31,600 –> 00:27:35,600
Ah, é nos testes. Então precisamos tirar os testes da pipeline.

252
00:27:35,600 –> 00:27:37,600
Já vi muito isso acontecer.

253
00:27:37,600 –> 00:27:39,600
Então o que a gente precisa fazer para tirar os testes?

254
00:27:39,600 –> 00:27:44,600
Uma vez que você tirou o teste, qual a sua garantia que tudo ali vai funcionar em produção com o usuário?

255
00:27:44,600 –> 00:27:50,600
Entendeu? Então é muito comum a gente ter esse cenário que você fez aí na sua aplicação.

256
00:27:50,600 –> 00:27:52,600
Isso em produção, em grandes empresas.

257
00:27:52,600 –> 00:28:00,600
E o que há, o trabalho do que há quando ele chega em um time que já, que não tem o processo definido, não tem nada disso,

258
00:28:00,600 –> 00:28:04,600
é justamente pegar tudo que está automatizado ali na interface e falar,

259
00:28:04,600 –> 00:28:07,600
pessoal, espera aí, a gente não consegue trazer isso aqui para o unitário?

260
00:28:07,600 –> 00:28:10,600
Olha, então eu vi esse cenário aqui, só que a gente consegue cobrir no unitário.

261
00:28:10,600 –> 00:28:15,600
Vocês conseguem criar isso aqui no unitário, na camada de teste?

262
00:28:15,600 –> 00:28:17,600
Claro, conseguimos, Tim, qual.

263
00:28:17,600 –> 00:28:22,600
Aí isso aqui, a gente não consegue testar em um componente, isso aqui a gente não consegue testar via API?

264
00:28:22,600 –> 00:28:24,600
Ah, conseguimos. E aí você vai divulgando isso.

265
00:28:24,600 –> 00:28:30,600
E uma coisa que tem sido muito comum é o famoso teste exploratório.

266
00:28:30,600 –> 00:28:32,600
E o que é o teste exploratório?

267
00:28:32,600 –> 00:28:38,600
Depois que você está com a aplicação lá em produção, depois de ter rodado todos os testes lá,

268
00:28:38,600 –> 00:28:44,600
imagina que a gente tem todas as camadas de testes cobertas para automação,

269
00:28:44,600 –> 00:28:49,600
por fim colocou em produção, eu vou lá como usuário e começo a navegar na aplicação.

270
00:28:49,600 –> 00:28:56,600
Vou em busca de erros que possam acontecer, que já aconteceram no passado,

271
00:28:56,600 –> 00:28:59,600
ou que já aconteceram na minha experiência com o QA.

272
00:28:59,600 –> 00:29:04,600
Por exemplo, eu estive testando uma aplicação nova aqui e eu já tive experiência de aplicações,

273
00:29:04,600 –> 00:29:10,600
por exemplo, que eu fui me logar e a aplicação me permitia me logar mesmo que a senha estivesse errada.

274
00:29:10,600 –> 00:29:15,600
Então eu vou tentar simular aquilo lá de forma exploratória, só um exemplo.

275
00:29:15,600 –> 00:29:20,600
Ou senão eu clicava na tecla voltar e não fazia nada.

276
00:29:20,600 –> 00:29:25,600
Então o teste exploratório vai muito baseado na experiência profissional que está testando.

277
00:29:25,600 –> 00:29:30,600
Ele vai se recordar de tudo que ele já testou, problemas que ele encontrou,

278
00:29:30,600 –> 00:29:32,600
e ele vai tentar simular nessa nova aplicação.

279
00:29:32,600 –> 00:29:36,600
Então uma vez que eu tenha todos os testes construídos de forma bonitinha,

280
00:29:36,600 –> 00:29:40,600
um processo legal, eu posso ainda incrementar fazendo um teste exploratório.

281
00:29:40,600 –> 00:29:45,600
Tanto eu quanto o PO e a equipe pode fazer esse trabalho.

282
00:29:45,600 –> 00:29:46,600
Legal, legal.

283
00:29:46,600 –> 00:29:50,600
Só dar um passo atrás e falar um pouco mais da minha experiência também,

284
00:29:50,600 –> 00:29:54,600
que de fato foi muito difícil, às vezes eu desligava o teste,

285
00:29:54,600 –> 00:29:59,600
porque demorava dois minutos, mas para uma aplicação pequena dois minutos era muito tempo

286
00:29:59,600 –> 00:30:03,600
e às vezes eu estava fazendo as horas vagas e eu ficava,

287
00:30:03,600 –> 00:30:08,600
poxa, eu quero acabar uma coisinha aqui, eu vou mudar a tela inteira e depois eu vou rodar ele de uma vez.

288
00:30:08,600 –> 00:30:12,600
Só que era muito difícil mesmo.

289
00:30:12,600 –> 00:30:16,600
Quando eu consertava ele, ok, mas dependendo do tipo de mudança.

290
00:30:16,600 –> 00:30:22,600
Então acho que começa a fazer sentido o que tu falou de tentar cobrir primeiro as camadas de baixo

291
00:30:22,600 –> 00:30:27,600
e lá em cima ficar o que é essencial, porque é muito mais demorado e caro

292
00:30:27,600 –> 00:30:29,600
e de manutenção mais lenta.

293
00:30:29,600 –> 00:30:37,600
Sim, essa tarefa, Gabriel, é uma tarefa que nenhum desenvolvedor gosta de fazer, a parte dos testes.

294
00:30:37,600 –> 00:30:43,600
E uma vez que você começa a aplicar o TDD, por exemplo, que é começar a criar o teste primeiro,

295
00:30:43,600 –> 00:30:47,600
aí você faz esse teste, ele vai criar o teste, você vai rodar, ele vai falhar,

296
00:30:47,600 –> 00:30:52,600
porque não existe código para ele validar, aí você implementa o código, você vai executar o teste,

297
00:30:52,600 –> 00:30:57,600
o teste vai passar, aí você vai refatorar o seu teste, depois você refatora o código principal

298
00:30:57,600 –> 00:31:04,600
e você vai fazendo. É um trabalho assim que, por exemplo, de três a seis meses vai ser um saco para o desenvolvedor fazer.

299
00:31:04,600 –> 00:31:10,600
Mas uma vez que ele começa a executar aquilo, ele começa a enxergar tanto o valor naquilo lá,

300
00:31:10,600 –> 00:31:19,600
que ele fala, puta, eu sempre tive uma visão errada, uma visão assim, eu sempre compliquei esse trabalho aqui

301
00:31:19,600 –> 00:31:26,600
por não ter o conhecimento, por não ter tido o apoio de um QA que estava do lado ali criando cenários, ajudando,

302
00:31:26,600 –> 00:31:32,600
porque muitas vezes um teste unitário, ele pode virar três ou quatro, não apenas um Ctrl C, Ctrl V,

303
00:31:32,600 –> 00:31:38,600
mudando ali variáveis daquele teste, as informações que eu vou estar processando.

304
00:31:38,600 –> 00:31:47,600
Então, às vezes o que acontece é o QA ter muito mais a visão de usuário e o desenvolvedor ser um cara muito de código mesmo.

305
00:31:47,600 –> 00:31:54,600
E aí o conjunto desses dois caras trocando informações ali, isso é bom tanto para o QA quanto para o Dev.

306
00:31:54,600 –> 00:32:02,600
O QA, da mesma forma que ele está ali passando esse conhecimento para o Dev, ele começa a absorver conhecimento técnico.

307
00:32:02,600 –> 00:32:06,600
Até mesmo tem muitos QAs hoje que não automatizam, que não sabem programação.

308
00:32:06,600 –> 00:32:13,600
E nessa troca de experiência, o QA também começa a ter uma visão ali de lógica, da linguagem, sintaxe,

309
00:32:13,600 –> 00:32:19,600
que estava sendo usada, e isso vai ajudar o QA também na hora da programação dos testes automatizados.

310
00:32:19,600 –> 00:32:24,600
Não, total, total. Eu tinha na minha experiência pequena novamente.

311
00:32:24,600 –> 00:32:29,600
Claro que quando eu era programador mesmo eu tive a experiência como QA, mas falando nessa recente individual,

312
00:32:29,600 –> 00:32:35,600
toda vez que eu desliguei o teste depois era muito pior para o pequeno ganho que tinha de fazer alguma coisinha,

313
00:32:35,600 –> 00:32:39,600
depois tinha que pagar em duplo para corrigir tudo.

314
00:32:39,600 –> 00:32:47,600
Sim. Eu queria saber agora onde que entram esses testes dentro do desenvolvimento.

315
00:32:47,600 –> 00:32:53,600
Eu acho que hoje é muito comum, pelo menos todas as empresas que eu passei até agora nos últimos anos,

316
00:32:53,600 –> 00:32:55,600
a gente trabalhar com sprints.

317
00:32:55,600 –> 00:33:00,600
Independente de trabalhar com scrum, Kanban, de não ter nenhum dos dois, mas quase sempre o trabalho é dividido ali

318
00:33:00,600 –> 00:33:03,600
em algum período, de duas semanas, um mês.

319
00:33:03,600 –> 00:33:11,600
E no final desse período a gente tem uma entrega, a gente combina com a pessoa de produto, a equipe faz um acordo ali e tem uma entrega.

320
00:33:11,600 –> 00:33:21,600
E onde entra o trabalho do QA? A gente entrega as coisas e a gente testa na próxima sprint, a gente testa junto,

321
00:33:21,600 –> 00:33:26,600
o que você vê no mercado, na sua experiência, o que você acha que é o correto?

322
00:33:26,600 –> 00:33:32,600
Eu não acho que existe um certo ou errado, existe a melhoria contínua.

323
00:33:32,600 –> 00:33:37,600
Pode ser que hoje o time tenha um QA que não saiba programar, por exemplo,

324
00:33:37,600 –> 00:33:41,600
foi o exemplo que a gente acabou de dar anteriormente aqui nessa troca de experiência,

325
00:33:41,600 –> 00:33:46,600
mas ele vai evoluir junto com o time, assim como deve vai evoluir o mindset de entender o usuário,

326
00:33:46,600 –> 00:33:53,600
o QA tem que evoluir o nível de conhecimento dele de programação, começar a automatizar aos poucos.

327
00:33:53,600 –> 00:34:00,600
Eu enxergo o QA como uma figura que está em evolução desde quando eu comecei,

328
00:34:00,600 –> 00:34:04,600
não desde quando eu comecei, mas desde quando o teste foi criado lá atrás,

329
00:34:04,600 –> 00:34:14,600
em 1900, se alguma coisa eu esqueci agora a data, mas já fazem 40 e pouquinhos anos que tem essa modalidade.

330
00:34:14,600 –> 00:34:23,600
Então ele vem evoluindo e eu acredito que em um futuro bem médio prazo, o QA vai deixar de ser uma figura QA só,

331
00:34:23,600 –> 00:34:30,600
ele vai ser um desenvolvedor focado em negócio e focado em teste.

332
00:34:30,600 –> 00:34:42,600
E respondendo a sua pergunta especificamente, o QA vai, dependendo do cenário de onde ele estiver,

333
00:34:42,600 –> 00:34:47,600
pode ser que ele não automatize, então ele tem que estar inserido junto com o time,

334
00:34:47,600 –> 00:34:54,600
e ir falando, ó pessoal, precisamos automatizar, vamos automatizar, sentar junto, e automatizar todas as camadas possíveis junto com o time.

335
00:34:54,600 –> 00:34:58,600
O teste não é responsabilidade do QA, o teste é responsabilidade da equipe.

336
00:34:58,600 –> 00:35:09,600
O QA é o evangelizador da qualidade e dos frameworks, das ferramentas que podem ajudar a equipe a entregar a melhor qualidade.

337
00:35:09,600 –> 00:35:13,600
Então ele pode estar ali junto com o time e desenvolver isso.

338
00:35:13,600 –> 00:35:20,600
Uma vez que ele saiba automatizar e que ele tenha conseguido trabalhar com o time durante todas aquelas duas semanas de desenvolvimento,

339
00:35:20,600 –> 00:35:29,600
teve tempo para automatizar esses testes no final da sprint antes de colocar isso em produção, ótimo.

340
00:35:29,600 –> 00:35:36,600
É um cenário que eu não conquistei ainda, chegar de eu ter tempo para fazer tudo isso.

341
00:35:36,600 –> 00:35:39,600
O que normalmente eu faço e que funciona?

342
00:35:39,600 –> 00:35:50,600
Eu testo aquela nova feature, aquela nova demanda, testo manualmente, ali dentro da sprint, e a gente coloca em produção.

343
00:35:50,600 –> 00:35:55,600
No começo da próxima sprint, enquanto os desenvolvedores estão…

344
00:35:55,600 –> 00:36:02,600
A gente está na parte de planning, a gente está na parte do desenvolvedor colocar a mão nos primeiros códigos,

345
00:36:02,600 –> 00:36:05,600
eu estou trabalhando na automação da sprint anterior.

346
00:36:05,600 –> 00:36:10,600
Então quando eu chegar no final dessa sprint atual, a minha sprint anterior vai estar automatizada.

347
00:36:10,600 –> 00:36:15,600
E eu estou sempre com esse débito da sprint anterior na questão da automação.

348
00:36:15,600 –> 00:36:22,600
Mas isso vai de maturidade de time, Gabriel, vai muito de conhecimento, do que há, do quanto técnico ele é.

349
00:36:22,600 –> 00:36:27,600
A gente tem muita variação de profissionais de qualidade dentro dos times.

350
00:36:27,600 –> 00:36:30,600
E aí podem ter vários formatos diferentes.

351
00:36:30,600 –> 00:36:36,600
Mas eu acredito que no futuro, 15 anos aí para frente, a gente vai ter esse cara…

352
00:36:36,600 –> 00:36:41,600
A gente até tem os títulos hoje no LinkedIn, a gente vê muito software engineer no teste.

353
00:36:41,600 –> 00:36:46,600
Então não é mais um QA, é um engenheiro de software focado em teste.

354
00:36:46,600 –> 00:36:52,600
E ele vai utilizar todo aquele conhecimento base do QA para trabalhar dentro dessa equipe.

355
00:36:52,600 –> 00:36:57,600
Entendi. Se eu entendi direito, tu quer dizer que é difícil,

356
00:36:57,600 –> 00:37:01,600
mas tu quer aproximar mais de quando a coisa foi…

357
00:37:01,600 –> 00:37:08,600
Acabou o desenvolvimento e o teste é feito para, de algum momento, tudo isso acabar dentro do próprio sprint.

358
00:37:08,600 –> 00:37:09,600
Certo?

359
00:37:09,600 –> 00:37:12,600
O ideal é que tudo isso aconteça dentro da sprint.

360
00:37:12,600 –> 00:37:18,600
Mas é difícil, porque, tipo, primeiro os desenvolvedores começam, depois vocês vão testar.

361
00:37:18,600 –> 00:37:22,600
Então está sempre tentando correr atrás, mas com a ideia de se aproximar mais.

362
00:37:22,600 –> 00:37:28,600
Isso. É difícil porque depende da equipe ali, da empresa.

363
00:37:28,600 –> 00:37:34,600
A gente, por exemplo, eu já trabalhei em time, que demandas chegavam no meio da sprint.

364
00:37:34,600 –> 00:37:40,600
E aí tudo saía do trilho, porque você chega uma demanda no meio da sprint, você tem que descobrir ela,

365
00:37:40,600 –> 00:37:46,600
você tem que criar todos os artefatos que o time desenvolver e tem que entregar dentro da sprint.

366
00:37:46,600 –> 00:37:50,600
Então fica surreal esse trabalho, acaba se tornando insano.

367
00:37:50,600 –> 00:38:00,600
O que a gente fez para solucionar esse problema no time, quando a gente tinha essas demandas que chegavam top down?

368
00:38:00,600 –> 00:38:06,600
A gente mudou de sprint. Saiu do sprint, começou a trabalhar com o Kanban, chegava uma demanda nova,

369
00:38:06,600 –> 00:38:12,600
a gente parava e estava fazendo, priorizava a demanda nova e iniciava o processo daquela demanda nova.

370
00:38:12,600 –> 00:38:18,600
Então ela ia até o final, muitas vezes a gente colocava em produção e depois criava task de automação,

371
00:38:18,600 –> 00:38:24,600
ou se fosse algo que dava para automatizar, mas sim, porque se automatizava e entregava já automatizado.

372
00:38:24,600 –> 00:38:30,600
Mas vai muito da maturidade não só do time, vai maturidade da empresa, da cultura da empresa.

373
00:38:30,600 –> 00:38:40,600
Então você aí como ajaio coach, você está muito inserido nessa parte organizacional onde o QA não atua,

374
00:38:40,600 –> 00:38:50,600
no contexto de time. Então você trabalha nessa parte e entende bem essa questão das demandas chegarem

375
00:38:50,600 –> 00:38:52,600
durante o time estar trabalhando e bem complicado.

376
00:38:57,600 –> 00:39:03,600
Agora queria passar para outra e aí eu vou primeiro contar um caos aqui e depois eu vou pedir a tua opinião,

377
00:39:03,600 –> 00:39:13,600
que é sobre o que QA é medido. Tem aquela frase que é diga-me como me mede, que eu direi como me comportarei.

378
00:39:13,600 –> 00:39:14,600
Exato.

379
00:39:14,600 –> 00:39:23,600
Eu tenho um caos parecido com o DevOps também, mas trabalhei numa equipe que a gente tinha todos os testers,

380
00:39:23,600 –> 00:39:30,600
isso foi no começo de carreira ainda, todos os testers, eu não sabia muita coisa, então hoje eu consigo entender

381
00:39:30,600 –> 00:39:35,600
isso melhor, mas todos os testers ficavam numa equipe só separada, então você tinha os times de desenvolvimento

382
00:39:35,600 –> 00:39:43,600
que eram separados pela parte do produto, pela entrega de valor, isso era até bem legalzinho, só que os testers

383
00:39:43,600 –> 00:39:52,600
ficavam separados. E a minha pergunta agora vai ser sobre como o QA é medido, porque esses QAs eram medidos

384
00:39:52,600 –> 00:40:03,600
por quantidade de bugs que eles pegavam. Então isso eu acho que tu desenha o cenário, desenha a forma de trabalhar

385
00:40:03,600 –> 00:40:09,600
e essa forma de trabalhar vai acabar ditando se as pessoas vão estar mais próximas ou não, se elas têm metas

386
00:40:09,600 –> 00:40:16,600
em conjunto ou não. E com essa meta o que acontecia é que existia uma rixa muito grande e acontecia situações

387
00:40:16,600 –> 00:40:23,600
que eu acabei descobrindo depois de os QAs segurar um pouco de bug para achar tudo em determinado momento,

388
00:40:23,600 –> 00:40:30,600
porque aí ia bater a métrica deles, e se eles não achassem nada o chefe deles chamava atenção, de como assim não

389
00:40:30,600 –> 00:40:37,600
foi pegando nenhum bug, vocês não estão trabalhando direito, tudo isso era manual. E tudo isso para te falar

390
00:40:37,600 –> 00:40:45,600
do caos que isso gerava e perguntar qual seria a forma mais correta de um QA ser avaliado dentro de uma equipe,

391
00:40:45,600 –> 00:40:54,600
como que seria, talvez essa forma era correta, se tu me disser isso eu também, mas o que tu acha que seria o cenário ideal?

392
00:40:54,600 –> 00:41:04,600
Bom, eu trabalho desde essa época que você falou, a gente era conhecido como fábrica de teste, fábrica de software.

393
00:41:04,600 –> 00:41:10,600
A fábrica de software era o time dev construindo que mandava para uma outra fábrica diferente, uma fábrica,

394
00:41:10,600 –> 00:41:16,600
basicamente uma empresa, a gente tem a empresa A construindo software, a empresa B testando software.

395
00:41:16,600 –> 00:41:25,600
E eu trabalhei nesse formato, é um formato horrível, onde você não tem comunicação, a comunicação é zero entre QA e dev,

396
00:41:25,600 –> 00:41:33,600
e existe a rixa, existe a rixa não, existem os borburinhos das rixas antigas que haviam entre dev e QA,

397
00:41:33,600 –> 00:41:39,600
muito por conta disso, porque o QA reportava, mas ele não conhecia o dev, ele não sabia nada, reportava,

398
00:41:39,600 –> 00:41:43,600
e ele disse, não, para mim não funciona, o requisito diz isso e não está aqui no requisito,

399
00:41:43,600 –> 00:41:51,600
só que esse requisito às vezes tinha mudado e não era atualizado, a gente tinha inúmeros artefatos, documentos,

400
00:41:51,600 –> 00:41:59,600
quando eu falo artefatos eu falo de documentos, no passado, que isso vai ficar aí por terra, com a chegada da agilidade e tudo,

401
00:41:59,600 –> 00:42:06,600
e a gente foi formatando isso. A gente antigamente media muito essa questão de número de bugs,

402
00:42:06,600 –> 00:42:16,600
e eu já vi como testador, eu já vi criando 400 mil cenários da mesma coisa, validar caracteres especial,

403
00:42:16,600 –> 00:42:23,600
aí o cara punha asterisco e colocava barra, todos dois são caracteres, eu não preciso de dois testes, eu preciso de um.

404
00:42:23,600 –> 00:42:25,600
Precisa de dois bugs reportados.

405
00:42:25,600 –> 00:42:35,600
É, e aí fica reportando essa ideia de gestão, que antigamente as fábricas de teste venhavam por bug encontrado,

406
00:42:35,600 –> 00:42:40,600
então não era questão de como reportar o trabalho do que há, era uma forma de ganhar dinheiro,

407
00:42:40,600 –> 00:42:47,600
então as fábricas de teste ganhavam por bug, por número de casos de testes utilizados,

408
00:42:47,600 –> 00:42:56,600
então olha, minha equipe criou 5 mil casos de teste, não é um negócio assim, tipo, apenas para fazer dinheiro,

409
00:42:56,600 –> 00:43:00,600
não estava muito focado em qualidade de comunicação e etc.

410
00:43:00,600 –> 00:43:11,600
Hoje, quais são as métricas que eu tenho utilizado? As mesmas de um time ágil, então throughput, second time, lead time,

411
00:43:11,600 –> 00:43:19,600
eu tenho utilizado essas mesmas métricas para medir o time, pensando, tenho trabalhado sempre pensando assim,

412
00:43:19,600 –> 00:43:25,600
teste, qualidade, tem que estar presente, então faz parte do trabalho, não é algo à parte,

413
00:43:25,600 –> 00:43:32,600
então uma demanda não sai, quando a gente fala definition of run, definition of read,

414
00:43:32,600 –> 00:43:41,600
ela não sai para entrega se ela não cumprir uma lista de critérios,

415
00:43:41,600 –> 00:43:51,600
um dos critérios é ter os testes automatizados, ter a documentação daquela funcionalidade na ferramenta,

416
00:43:51,600 –> 00:44:01,600
seja lá o Confliss, ou qualquer outra ferramenta, então eu não tenho utilizado nenhuma métrica nesse sentido para validar teste,

417
00:44:01,600 –> 00:44:09,600
o que eu tenho utilizado é implementar ferramentas, por exemplo, existem ferramentas para você metrificar a qualidade do código,

418
00:44:09,600 –> 00:44:17,600
como por exemplo o SonarQube, a gente consegue utilizar o SonarQube para ver lá se o nosso código tem qualidade ou não,

419
00:44:17,600 –> 00:44:24,600
a gente tem testes de mutação, que é uma ferramenta que se chama StrikeMutator, você executa ela,

420
00:44:24,600 –> 00:44:31,600
e ela vai validar todos os testes unitários e ver se toda a mutação que ela fez no código fonte,

421
00:44:31,600 –> 00:44:39,600
se os testes unitários cumpriram, e ela vai te dar lá o percentil de que o teste está bacana ou não,

422
00:44:39,600 –> 00:44:45,600
e ela vai te dar até os testes que estão faltando, que aí torna muito mais fácil a vida do desenvolvedor,

423
00:44:45,600 –> 00:44:50,600
que chega lá e fala assim, preciso fazer um teste para contê-lo isso daqui, e valido ali aumenta minha cobertura,

424
00:44:50,600 –> 00:44:57,600
então pensando nesse cenário que a aplicação só sai com teste, eu não me preocupo com métrica de teste,

425
00:44:57,600 –> 00:45:04,600
eu me preocupo com métrica de qualidade, então o que a gente pode fazer é tipo, depois que está em produção,

426
00:45:04,600 –> 00:45:11,600
bugs que foram encontrados, se um bug que foi encontrado já foi encontrado anteriormente, isso é um problema para mim,

427
00:45:11,600 –> 00:45:17,600
porque se a gente já encontrou esse bug, por que ele apareceu de novo e não tem um teste que valide aquilo,

428
00:45:17,600 –> 00:45:22,600
para que ele não acontecesse de novo? Bug sempre vai existir, ele sempre vai acontecer,

429
00:45:22,600 –> 00:45:28,600
a gente trabalha para minimizar esse risco, então uma vez que tem uma recorrência de um bug em produção,

430
00:45:28,600 –> 00:45:37,600
isso é um problema grave, porque a gente corrigiu a aplicação e não criou testes suficientes para uma próxima vez aquilo não acontecer.

431
00:45:37,600 –> 00:45:42,600
Mas esse é um problema grave para a equipe, deixa de ser uma coisa de fábrica.

432
00:45:42,600 –> 00:45:45,600
Para o produto em si.

433
00:45:45,600 –> 00:45:53,600
Legal, então deixa eu tentar ver se eu capturei bem aqui resumindo, aí tu me corrigi qualquer coisa.

434
00:45:53,600 –> 00:46:01,600
Então ao invés de ter uma métrica própria que é a quantidade de bugs em cada release, que é o cenário que eu te falei lá,

435
00:46:01,600 –> 00:46:08,600
eu estava lembrando aqui, eu acho que era o Scrum Master, e aí eu tive que brigar para mudar, porque era dentro da própria empresa,

436
00:46:08,600 –> 00:46:15,600
era como se fosse aqui, separado dentro da própria empresa, e era esse modelo de fábrica de software, e depois mudou,

437
00:46:15,600 –> 00:46:22,600
até quando mudou a inimizidade, a falta de amizade entre eles.

438
00:46:22,600 –> 00:46:23,600
Inimizade.

439
00:46:23,600 –> 00:46:28,600
Inimizade, isso, entre eles durou, porque já a gente tinha a rixa, mas enfim.

440
00:46:28,600 –> 00:46:34,600
Mas o que eu queria dizer aqui então é que, ao invés de ter uma métrica própria, como esse cenário cálido que eu falei,

441
00:46:34,600 –> 00:46:42,600
tu vai pensar no through push, que é a vazão que a equipe dá, então quantas tasks a história a gente está entregando,

442
00:46:42,600 –> 00:46:50,600
lead time, cycle time, tipo de desenvolvimento, a produção, quanto tempo demora em dias, e de quando o cliente pediu,

443
00:46:50,600 –> 00:46:51,600
quanto tempo foi na produção.

444
00:46:51,600 –> 00:46:59,600
E aí então o teu time trabalha baseado nisso, e também se houver bugs, também é um problema, que é uma métrica negativa em produção, com frequência.

445
00:46:59,600 –> 00:47:00,600
Produção.

446
00:47:00,600 –> 00:47:09,600
Isso, e isso quer dizer que é ruim para a equipe inteira. Talvez tu pode ser a pessoa mais responsável para estar puxando para isso,

447
00:47:09,600 –> 00:47:15,600
mas é o problema da equipe não, da equipe de QA’s versus desenvolvedor, está todo mundo junto.

448
00:47:15,600 –> 00:47:16,600
Exato.

449
00:47:16,600 –> 00:47:25,600
Quando a gente trata bug como um problema dentro do desenvolvimento, a gente vai ter essa rixa de deve que a,

450
00:47:25,600 –> 00:47:33,600
o Demis reportou um bug meu, não podia ter conversado comigo, isso já aconteceu muito, quando eu comecei no passado que era,

451
00:47:33,600 –> 00:47:42,600
ainda hoje existe isso, muitos líderes querendo métrica de bug em desenvolvimento, cara, está em desenvolvimento,

452
00:47:42,600 –> 00:47:49,600
achar bug faz parte do trabalho, eu não posso metrificar o Gabriel, o desenvolvedor, por ter criado cinco bugs,

453
00:47:49,600 –> 00:47:57,600
sendo que ele estava desenvolvendo aquilo, o trabalho ali é justamente desenvolver, testar e entregar algo sem bugs,

454
00:47:57,600 –> 00:48:03,600
mas enquanto está desenvolvendo, está desenvolvendo, eu não posso ficar criando bug, tem muito líder que pede isso,

455
00:48:03,600 –> 00:48:08,600
quero saber quando os bugs foram produzidos por desenvolvedor, cara, para quê?

456
00:48:08,600 –> 00:48:14,600
Para chicotir o cara, para demitir? É essa a forma que você vai tratar seus funcionários? Não faz sentido isso.

457
00:48:14,600 –> 00:48:21,600
Então para mim, bug é bug em produção, em fase de desenvolvimento não é um bug, é uma falha que precisa ser corrigida,

458
00:48:21,600 –> 00:48:28,600
bug é depois que passou por todo mundo ali, passou pelos testes e foi para a produção, o usuário pegou, isso para mim é um bug.

459
00:48:28,600 –> 00:48:40,600
Então uma forma que melhora muito a comunicação é a gente eliminar isso, não a comunicação, mas o convívio entre dev e qa,

460
00:48:40,600 –> 00:48:46,600
é eliminar essa questão bug, olha Gabriel, encontrei um bug, temos uma falha que precisa ser corrigida,

461
00:48:46,600 –> 00:48:52,600
e aí põe para o time, pode ser na dele, pode ser durante o dia, alivia a slack, encontrei uma falha nisso aqui,

462
00:48:52,600 –> 00:48:59,600
precisamos corrigir, e beleza, não interessa quem produziu, interessa que a equipe vai ganhando músculo no decorrer do tempo.

463
00:48:59,600 –> 00:49:08,600
E aí eu vou olhando para as métricas lá, ágeis e falando, olha, antigamente a gente demorava 3 semanas para desenvolver

464
00:49:08,600 –> 00:49:14,600
um pedacinho de software do tamanho X, e hoje a gente demora uma semana,

465
00:49:14,600 –> 00:49:23,600
então pô, a gente evoluiu e a gente continua implementando a qualidade, fazemos testes automatizados, fazemos testes inúmeros,

466
00:49:23,600 –> 00:49:31,600
sei lá, depende do tipo do que você está desenvolvendo, a gente faz os testes apropriados para aquela aplicação do jeito que tinha que ser,

467
00:49:31,600 –> 00:49:37,600
e entrega isso no menor prazo, para mim é essa a métrica que conta pensando que a gente está trabalhando em um time,

468
00:49:37,600 –> 00:49:41,600
e esse time vai amadurecendo junto, vai ganhando músculo junto.

469
00:49:41,600 –> 00:49:50,600
Sim, eu até pensando em métrica, eu até gosto dessa métrica de quantas falhas e retrabalho teve assim dentro da equipe,

470
00:49:50,600 –> 00:49:59,600
mas eu acho que o mais importante da métrica é o como que tu vai usar ela, porque é um número, um número, agora o que aconteceu,

471
00:49:59,600 –> 00:50:07,600
como que a gente minimiza, tá, esse desenvolvedor aqui está criando mais, como equipe a gente monta um plano para que essa pessoa

472
00:50:07,600 –> 00:50:14,600
aprenda mais sobre esse módulo, sobre essa parte do código, ou é o código talvez, como que a gente vai refatorar,

473
00:50:14,600 –> 00:50:20,600
a gente tem que criar aqui alguma tarefa para colocar no backlog para a gente corrigir isso e a gente evitar falha.

474
00:50:20,600 –> 00:50:31,600
Então eu até gosto dessa métrica quando não está nesse modelo de Keyways versus desenvolvedores, versus manager,

475
00:50:31,600 –> 00:50:39,600
que quer procurar alguém para culpar pelos atrasos, o problema, então acho que é tudo como a gente usa, mas depende muito.

476
00:50:39,600 –> 00:50:48,600
Exato, eu acho que é mais o formato do uso, quando os alunos aqui nos treinamentos perguntam, eu falo, mas para que você quer a métrica?

477
00:50:48,600 –> 00:50:54,600
Ah, meu líder pediu, mas para que ele vai usar? Ah, não sei, então você perguntou para o seu líder para que ele quer a métrica,

478
00:50:54,600 –> 00:51:02,600
de repente você pode estar entregando a métrica e não vai ajudar em nada, é para chicotear o dev, é para melhorar o processo, então existem outras formas,

479
00:51:02,600 –> 00:51:12,600
eu acho que ficar medindo o bug não é uma forma legal, eu posso simplesmente, eu como QA, identificar que o desenvolvedor João é relaxado,

480
00:51:12,600 –> 00:51:21,600
por exemplo, e por isso que o teste dele, que o código dele tem mais bugs, e aí, cara, eu posso chegar e falar, po, mas você está pisando na bola aqui,

481
00:51:21,600 –> 00:51:30,600
a gente está tentando seguir esse processo aqui, você está dando atenção zero aqui para esse templatezinho com as coisas que a gente está fazendo,

482
00:51:30,600 –> 00:51:39,600
sabe se eu compro o implementamento e segui isso aqui, porque a gente está trabalhando para melhorar esse produto e você não está procurando com isso,

483
00:51:39,600 –> 00:51:46,600
não quero chegar para a gente chegar numa retrospectiva e ter que expor você na frente do time, ou você está precisando de ajuda,

484
00:51:46,600 –> 00:51:54,600
às vezes em muitos casos o cara está com problema em casa, sei lá, o cara está, sei lá, teve filho e não dorme direito há meses, sabe,

485
00:51:54,600 –> 00:52:03,600
e aí você fala, po, a partir do momento que eu entendo o problema do cara, eu começo a olhar diferente, falou, João, eu sei que você está cansado aí,

486
00:52:03,600 –> 00:52:08,600
o que eu posso fazer para te ajudar? E aí você senta do lado do cara e ajuda, simples assim, entendeu?

487
00:52:08,600 –> 00:52:19,600
Então, eu não gosto dessa métrica durante o desenvolvimento, eu utilizo basicamente quando eu estou controlando isso, eu utilizo a métrica de bug,

488
00:52:19,600 –> 00:52:27,600
um bug novo em produção tem que ser corrigido e tem que ter sido criado um teste para que ele não volte a aparecer lá,

489
00:52:27,600 –> 00:52:37,600
um teste automatizado que garanta que ele não apareça mais, e aí se um teste volta a aparecer, foi porque a gente falhou realmente em não criar

490
00:52:37,600 –> 00:52:39,600
alguma coisa que invalidasse o bug.

491
00:52:40,600 –> 00:52:51,600
Tá bom. A gente falou um pouco agora dessa fábrica de software, né, e fábrica de testes, e a gente falou de como isso é uma coisa no geral do passado

492
00:52:51,600 –> 00:53:00,600
e foi evoluindo, e eu queria entrar agora nessa parte de carreira, eu queria saber o que, no ponto de vista do que é um QA hoje,

493
00:53:00,600 –> 00:53:10,600
ainda trazendo muita experiência como professor, de o que é um QA hoje e quais são as habilidades necessárias para alguém que quer virar um QA,

494
00:53:10,600 –> 00:53:18,600
ou não trabalha com tecnologia e quer migrar de carreira, ou talvez até um desenvolvedor que acha que no desenvolvimento de software, sabe,

495
00:53:18,600 –> 00:53:24,600
engenharia mesmo não é a parte dessa pessoa, talvez ir para a QA, eu conheço uma pessoa que é assim e pode trazer essa experiência,

496
00:53:24,600 –> 00:53:29,600
então, o que é que essas pessoas, né, falei duas pessoas diferentes que são habilidades diferentes, uma que está fora, outra que está dentro,

497
00:53:29,600 –> 00:53:33,600
o que é que essas pessoas, na tua opinião, deveriam começar estudando?

498
00:53:34,600 –> 00:53:45,600
Bom, eu acho que a pessoa, antes de migrar de carreira, ou iniciar essa carreira, ela tem que ter em mente que trabalhar com TI é um mundo que você não para de estudar nunca,

499
00:53:45,600 –> 00:53:50,600
então você vai estar sempre evoluindo junto com a tecnologia e vai ter que estar sempre aprendendo.

500
00:53:50,600 –> 00:54:03,600
Um outro ponto, que quando a gente estava no modelo fábrica de teste, a gente simplesmente testava manualmente, a gente escrevia em excess, em planilhas, etc, e executava aquilo manualmente.

501
00:54:03,600 –> 00:54:13,600
O QA evoluiu no decorrer desse tempo e hoje o QA também programa, não o código fonte, mas ele programa um script que execute testes para aquilo.

502
00:54:13,600 –> 00:54:21,600
Então, vai trabalhar com o QA, quer trabalhar com o QA, bacana, mas você vai ter que aprender lógica de programação, vai ter que gostar de lógica de programação,

503
00:54:21,600 –> 00:54:26,600
vai ter que gostar de programar o mínimo necessário para você criar seu script.

504
00:54:26,600 –> 00:54:29,600
E eu acho que é importante ele saber isso.

505
00:54:29,600 –> 00:54:47,600
Agora, pensando em um caminho para ele se tornar, eu acho que ele precisa, apesar do profissional, do modelo de trabalho ter evoluído, tudo que era ensinado lá atrás sobre a base de conhecimento do teste de software,

506
00:54:47,600 –> 00:54:55,600
eu lendo hoje o mesmo livro que eu ganhei lá em 2009, eu tenho uma visão completamente diferente do mesmo livro.

507
00:54:55,600 –> 00:55:02,600
Então, lá atrás ele dizia o formato de trabalhar, que é basicamente o que a gente está falando aqui hoje.

508
00:55:02,600 –> 00:55:15,600
Porém, como a gente tinha esses modelos de fábrica de software, fábrica de teste, parece que aquele conteúdo foi deturpado para entrar no modelo de ganhar dinheiro.

509
00:55:15,600 –> 00:55:30,600
Então, quando eu olho hoje a literatura que eu li lá em 2009, eu falo assim, cara, já era, já estava aqui que era para a gente ser comunicativo, que era para a gente interagir, que era para a gente conversar e tirar o máximo de coisas.

510
00:55:30,600 –> 00:55:40,600
Só que a gente foi trabalhando separado. E isso daí, essa base de conhecimento é importante para qualquer pessoa.

511
00:55:40,600 –> 00:55:54,600
Eu tenho um treinamento aqui, tenho um treinamento que eu recomendo que é da TI Exames, que é o Tester Foundation, é só dar TI Exames lá, teste de software no Google, vai ser o primeiro link que aparecer.

512
00:55:54,600 –> 00:56:07,600
É um treinamento muito barato, 120 reais, são os meus gramas. E eu acho que pode ser o primeiro investimento de alguma pessoa que quer começar, comprar esse curso que é baratinho,

513
00:56:07,600 –> 00:56:13,600
assiste às videoaulas, vê se encaixa ali com aquele modelo que ele está ensinando e depois busca evolução.

514
00:56:13,600 –> 00:56:22,600
E aí tem treinamento nosso, tem treinamento meu aqui, a gente está na mentoria, tem treinamento de outros profissionais especialistas no mercado também aí na área.

515
00:56:22,600 –> 00:56:36,600
E eu acho que os principais pontos são esses, Gabriel. Ah, e pensando em perfil, é curiosidade, né meu? É uma pessoa curiosa, uma pessoa investigativa, que tem aquele instinto de investigar as coisas,

516
00:56:36,600 –> 00:56:51,600
de aprender, que esteja sempre querendo buscar aprendizado ou buscando novas formas de fazer aquela mesma coisa. Eu acho que quando a pessoa tem isso, ela tem um plus ali no dia a dia dela depois que ela estiver executando o trabalho.

517
00:56:51,600 –> 00:57:12,600
E dentro desse curso que você falou, do teu e eu, do T.I. Exames, tu tem algumas coisas básicas do fundamento. Tu comentou aí sobre a parte de engenharia de software, porque é muito importante a gente saber um pouquinho de programação para poder criar os scripts.

518
00:57:12,600 –> 00:57:30,600
Mas além disso, tem mais alguma coisa que tu acha que o pessoal deveria olhar ou considerar, além de ser curioso, ter na cabeça que essa pessoa vai precisar entender um pouquinho de programação também, mas tem mais alguma coisa que te chama atenção que as pessoas deveriam levar em consideração também?

519
00:57:30,600 –> 00:57:48,600
Eu acho que tem bastante coisa. Eu acho que o fato da pessoa ser resiliente, o fato da pessoa ser comunicativa, todas essas questões ajudam muito se você tiver. É óbvio que eu acredito que qualquer pessoa é capaz de fazer uma determinada atividade.

520
00:57:48,600 –> 00:58:17,600
Ela só tem que estar aberta ou aberta ao novo e a querer aprender, a querer se automoldar para evoluir. Então, eu não acredito que existam barreiras, mas existem sim maiores possibilidades para aqueles que têm esses perfis de comunicação, para um cara que é mais flexível, um cara que é negociador, que isso vai ajudar muito na carreira dele.

521
00:58:17,600 –> 00:58:34,600
Uma vez que ele é isso, tem esse perfil pessoal desse formato, ele estuda a base de conhecimento e teste de software, ele tem em mente que ele vai precisar programar e automatizar tudo, eu acho que isso são os primeiros passos para ele começar a evoluir.

522
00:58:34,600 –> 00:58:48,600
E depois, você vai ter que andar sempre com uma caixa de ferramenta vazia e no decorrer da sua trajetória você fala, preciso aprender um pouco mais disso para solucionar esse problema. E aí você vai e coloca aquela ferramenta dentro da sua caixa e vai evoluindo.

523
00:58:48,600 –> 00:59:09,600
Então, por exemplo, eu quando trabalhava junto na mesma empresa, eu busquei conhecimento e agilidade para melhorar o meu trabalho como testador. Então, o trabalho que eu fazia na comunidade ágil, de busca de conhecimento e que eu aplicava dentro do meu time, isso me ajudou demais a mudar bastante coisa dentro do meu time.

524
00:59:09,600 –> 00:59:28,600
Então, eu sempre falo aqui quando eu faço entrevista, que me pedem um caso bacana, eu falo esse caso de, poxa, eu trabalhei junto com um time, a gente saiu do modelo escuro, foi para a Camban, isso não é um trabalho de um tester, por exemplo, é um trabalho de quem está envolvido ali com o processo como um todo.

525
00:59:28,600 –> 00:59:44,600
Então, eu vejo muita gente migrando de carreira para ganhar dinheiro, então tipo, vou fazer automação, o mercado pede automação, só que o mercado não sabe o que quer, não sabe o que é qualidade, não sabe o que o profissional de QA é capaz ou pode fazer.

526
00:59:44,600 –> 01:00:00,600
Então, o mercado fala assim, eu preciso que tenha um feedback rápido, o que é que me dá feedback rápido? Automação. E aí, tipo, contrata QA automação, para ser QA tem que ter automação, mas QA não é automação, QA não é teste, QA é quality assurance, é garantia de qualidade.

527
01:00:00,600 –> 01:00:15,600
E você não garante qualidade com teste, você garante qualidade mudando o processo, mudando forma de entregar esse produto, fazendo várias outras coisas além do teste. O teste é apenas uma das atividades dentro do processo de qualidade.

528
01:00:15,600 –> 01:00:42,600
Então, eu acredito que, eu tenho bastante gente, tenho uma aluna de RH que está trabalhando com QA, e meu, amando, tenho um aluno que era escrivão em escritório de advocacia, está trabalhando com QA já, e a gente faz mentoria aqui nos treinamentos, e eles trazem um problema, e eu falo, cara, quando eu passei por esse problema, eu busquei isso, isso e aquilo, quando eu passei por esse outro problema, eu busquei isso, isso e aquilo.

529
01:00:42,600 –> 01:00:53,600
Então, a gente, quando entra nessa nova atividade, a gente tem que pensar que a gente está aqui ou com uma caixa de ferramenta vazia, ou com uma mochila vazia nas costas, e no decorrer, a gente busca aquilo que é necessário para resolver um problema.

530
01:00:53,600 –> 01:01:02,600
Então, pensando aí, falando mais um item do perfil, fora a questão de comunicação e tal, é o solucionador de problemas.

531
01:01:02,600 –> 01:01:17,600
Então, você vai encontrar muitos problemas dentro do processo de desenvolvimento, então, você vai ter que não ficar só contando, olha, tem problema aqui, e sim falando assim, olha, nós temos esse problema, e eu encontrei essa solução.

532
01:01:17,600 –> 01:01:22,600
Vocês veem outro modelo, outra solução que a gente possa para resolver esse problema?

533
01:01:22,600 –> 01:01:34,600
Um problema, por exemplo, que eu posso dar de exemplo aqui, que é muito comum, para que há? Ambiente de teste não é igual ao ambiente de produção, não é uma réplica de produção.

534
01:01:34,600 –> 01:01:45,600
E aí, por exemplo, o ambiente de teste não funciona como deveria. Como que eu posso solucionar isso? A gente já trabalhou numa empresa que, tipo, isso é um problema comum para todos os times.

535
01:01:45,600 –> 01:01:53,600
E aí, toda retrospectiva, ah, porque atrasou, porque não sei o que, ah, porque o ambiente era ruim, porque o ambiente demorou para a fase funcionar.

536
01:01:53,600 –> 01:02:05,600
Tá, a gente tem que parar de reclamar disso, a gente está há dois anos reclamando com a mesma coisa. O que a gente pode fazer para sanar esse problema, para esquecer que esse ambiente existe?

537
01:02:05,600 –> 01:02:11,600
A gente pode criar um ambiente só nosso? A gente pode testar isso localmente? O que a gente pode fazer?

538
01:02:11,600 –> 01:02:18,600
E aí a gente deixou, por exemplo, de usar o ambiente de teste e passou a usar o ambiente local. E solucionamos o problema.

539
01:02:18,600 –> 01:02:23,600
Então, a gente tem que estar sempre com esse pensamento de solucionar problemas.

540
01:02:23,600 –> 01:02:35,600
Eu acho que isso vai ajudar muito a pessoa de Ikea a conseguir implementar toda a mudança em todas as fases ali do processo, ou melhorias aonde for possível.

541
01:02:35,600 –> 01:02:52,600
Então, tu falou agora toda a parte do que era o Kiway lá atrás quando tu começou, falou o que seria o Kiway hoje, o Kiway moderno, no dia de hoje, o que ele tem que saber.

542
01:02:52,600 –> 01:03:00,600
E tu também ensina sobre isso, né? Então, queria que tu, antes da gente fechar, falasse do teu curso também, onde o pessoal acha ele.

543
01:03:00,600 –> 01:03:13,600
Bom, eu tenho desenvolvido treinamentos e eventos na área de qualidade desde 2017 e dá para encontrar tudo em bileb.com.br, né?

544
01:03:13,600 –> 01:03:24,600
B de havia em inglês, B de laboratório, bileb.com.br. E também deixei o link aqui do meu link, que tem todos os links de todas as minhas coisas, que eu deixei aqui.

545
01:03:24,600 –> 01:03:27,600
O Gabriel vai estar aqui embaixo na descrição do vídeo.

546
01:03:27,600 –> 01:03:34,600
Perfeito, vai estar tudo aqui na descrição do vídeo, podcast, independente de onde vocês estiverem ouvindo, vocês vão achar.

547
01:03:34,600 –> 01:03:44,600
E Demis, antes de fechar, se quer deixar alguma palavra final, deixar além do B-Labs também algum link teu, link de site?

548
01:03:44,600 –> 01:03:56,600
Sim, eu já deixei o meu link aqui, já tem meu link, tem meu Instagram, eu compartilho sempre conteúdo de qualidade, falando sobre qualidade de software, teste no meu Instagram.

549
01:03:56,600 –> 01:03:59,600
E também no LinkedIn, sempre compartilho conteúdo lá.

550
01:03:59,600 –> 01:04:10,600
E os links que estão na descrição aqui podem me adicionar na rede social, podem mandar perguntas, eu sempre respondo, às vezes no LinkedIn demoro um pouco para responder, bastante pergunta.

551
01:04:10,600 –> 01:04:21,600
Mas sempre no prazo, uma semana assim, eu respondo. Até meu WhatsApp é público, está lá também, pode me mandar um WhatsApp, eu demoro um pouquinho para responder, mas sempre respondo.

552
01:04:21,600 –> 01:04:34,600
Às vezes respondo com áudio, mas respondo para facilitar o trabalho, mas podem contar comigo se estiver em transição, quiser tirar uma dúvida, eu faço esse trabalho de forma gratuita,

553
01:04:34,600 –> 01:04:49,600
ajudo as pessoas a entenderem melhor, não estou nesse modelo de treinamento para ganhar dinheiro, eu quero mesmo ajudar as pessoas e que elas tenham sucesso, se elas quiserem ter o sucesso, eu ajudo com o treinamento.

554
01:04:49,600 –> 01:04:59,600
Se elas entenderem que a qualidade não é para elas, respeito e seguem a vida, estamos juntos, quem precisar de uma força pode contar comigo.

555
01:04:59,600 –> 01:05:14,600
Legal, cara, muito obrigado pelo compartilhamento da tua experiência, obrigado por responder esse monte de perguntas e até a próxima, faz tempo que a gente não se vê, desde que a gente trabalhou juntos, de lá para cá.

556
01:05:14,600 –> 01:05:17,600
Faz um ano já.

557
01:05:17,600 –> 01:05:19,600
Caramba, faz um ano.

558
01:05:19,600 –> 01:05:27,600
Bom, obrigado pelo convite, valeu pelo compartilhamento, a gente poderia ficar horas aqui falando.

559
01:05:27,600 –> 01:05:37,600
Valeu, e mais uma vez, se precisar de mim, só contem comigo e quem tiver ouvindo, se quiser contar.

560
01:05:37,600 –> 01:05:49,600
Então é isso, até a próxima, DMS, valeu.