Episode 89
QA Engineer, o que faz? com Demis Meneghetti - O Trabalho do QA no Time de Desenvolvimento #89
No episódio de hoje, O Demis Meneghetti vai nos contar sobre a evolução do trabalho do QA, e como a pessoa que assume esse papel pode ajudar o time.
Mais episódios
- 🎧 Lista de episódios por temas
- 🗺️ Morando e trabalhando na Europa
- 💻 Migração de Carreira
- 👩🏽 Mulheres em Tech
Demis Meneghetti
Casado, pai de 3, vivendo na Europa desde 2019 e com mais de 13 anos de experiência trabalhando com qualidade de software em projetos ágeis de sistemas bancários, varejo e sites de e-commerce.
Curso mencionado: https://tiexames.com.br/novosite2015/curso_Teste_Software_CTFL.php
Créditos
Lista de Episódios
- 🎒 Nômade Digital
- 👨🏽💻 Trabalho Remoto
- 🇪🇺 Europa
- 🇩🇪 Alemanha
- 🇵🇹 Portugal
- 🇬🇧 Reino Unido
- 🇪🇸 Espanha
- 🇳🇱 Holanda
- 🇺🇸 Estados Unidos
- 🇨🇦 Canadá
- 🇸🇪 Suécia
- 🎬 E muito mais: https://tudoproalto.com/lista
Por Gabriel Rubens ❤️
The post "QA Engineer, o que faz? com Demis Meneghetti - O Trabalho do QA no Time de Desenvolvimento #89" first appeared on https://tudoproalto.com
Transcript
Fala pessoal, bem vindos ao TPA, Gabriel Rubens aqui e hoje com mais um episódio sobre profissões
Speaker:e o papel de hoje vai ser o do QA e quem vai falar pra gente sobre esse papel vai ser o
Speaker:Demis Meneghetti que já tem mais ou 13 anos de experiência já na área, conhece o modelo
Speaker:de fábrica de software, conhece o modelo de testes ágeis e vem evoluindo na carreira
Speaker:e tem muita coisa pra compartilhar hoje aqui com a gente nesse episódio, tudo bem Demis?
Speaker:Tudo bem Gabriel e você cara? Graças a Deus tudo certo por aqui.
Speaker:Tá tudo ótimo, então bora lá. Acho que antes da gente passar pro trabalho do QA né,
Speaker:começar pedindo pra você falar um pouco sobre quem é você, como chegou até aí como QA specialist.
Speaker:Bom eu sou o Demis Meneghetti que você já me apresentou, eu acho até que pra ser um
Speaker:pouco mais inclusivo aqui né, eu sou careca, sou de barba, uso barba, minha barba é branquinha aqui
Speaker:pra quem tiver ouvindo e não tiver vendo a imagem, sou gordinho né, peso uns 96 kg aqui e tenho 1,80
Speaker:kg que atrás de mim tem uma estantezinha com alguns livros, umas passas com documentos e eu
Speaker:tô na área de QA, já há 13 anos trabalhando nessa área, anterior a isso eu sempre trabalhei em
Speaker:escritora de advocacia, voltado mais a serviços administrativos né, e nos últimos tempos nesse
Speaker:período de advocacia eu cuidava da parte de suporte ao usuário, suporte de TI mesmo né, dentro do
Speaker:escritório atendendo os advogados da empresa né, dando todo suporte na parte operacional ali de
Speaker:computadores né. E aí nesse, no momento que eu saí de férias lá, eu tinha uma pessoa conhecida na
Speaker:internet que me recomendou para uma entrevista, eu fui sem conhecimento nenhum, me apresentei,
Speaker:falei o que eu gostava, o que eu não gostava e recebi minha primeira oportunidade ali mesmo sem
Speaker:experiência lá em 2009, para trabalhar no Banco Santander e startar a carreira totalmente do zero
Speaker:né, então fui treinado, fui formado como QA, daí pra frente fui sempre estudando coisas novas e
Speaker:mais para chegar até aqui hoje. Caramba, bastante tempo mesmo já dentro da mesma área hein, que legal.
Speaker:Então é que bom porque tu vai ter muita experiência aí para contar para gente né,
Speaker:qual que é o papel do QA. Então cara, eu queria também saber como que é a estrutura do time que
Speaker:você trabalha hoje sabe, tipo quantos developers, quantos QA's, sei lá, gestor, scrum master,
Speaker:qual que é a organização do trabalho mesmo, porque eu acho que vai ficar mais fácil as pessoas
Speaker:visualizarem daqui para frente tudo que a gente falar, de qual que é o contexto que tu está inserido.
Speaker:Bacana, bom eu estou inserido dentro de um time ágil né, então o meu time tem cinco desenvolvedores,
Speaker:tem um Product Owner né, o Product Manager e o Tech Lead né, então nós somos cinco, seis,
Speaker:oito pessoas dentro do time, trabalhando no produto e eu como QA faço parte do Dev Team,
Speaker:inserido no time e também fico ali fazendo a ponte entre as informações que chegam através
Speaker:do nosso Product Manager para a equipe, criando artefatos para a equipe poder produzir um novo
Speaker:produto para a software. Tá bom, então sabendo agora como que é o ambiente que tu está, eu queria saber
Speaker:como que é o teu trabalho, tu falou de duas coisas aí né, tu falou do suporte ali com o Product Manager
Speaker:ou com o Product Owner e depois o trabalho com a equipe né, eu queria saber qual que é esse suporte e
Speaker:como que é na prática o que tem que fazer sabe, ele passa uma demanda para ti, tu controla junto
Speaker:com essa pessoa de produto, como que é? Bacana, no decorrer do nosso papo aqui a gente vai falar da
Speaker:evolução do papel do QA né, porque nos dias atuais o QA é um cara ali mais próximo do usuário, com uma
Speaker:visão mais profunda ali daquele produto que está sendo validado, desenvolvido, testado e colocado
Speaker:em produção para o usuário testar, então o QA é um grande conhecedor assim como o Fio do produto né,
Speaker:porque as vezes o QA sabe muito mais do produto do que o próprio Fio, porque o Fio entende muito da regra
Speaker:de negócio para aquela aplicação, mas o QA é o cara que testa, é o cara que usa, é o cara que valida,
Speaker:que está o tempo inteiro ali transacionando as operações daquela aplicação, então no contexto atual
Speaker:hoje o papel do QA vem pensando numa esteira de desenvolvimento né, então o QA ele está de ponta
Speaker:dentro dessa esteira né, então pensa que o Product Manager ele vem com um pedido né, eu como QA faço
Speaker:uma espécie de uma entrevista para esse Product Manager perguntando para que serve, quem é o usuário,
Speaker:quantas pessoas vão acessar simultaneamente, se o serviço vai ficar 24 por 7, se ele desliga e desliga,
Speaker:se vai ter login para acesso, se a gente vai ter log de acesso das transações, faço uma bateria de perguntas ali
Speaker:e através dessas perguntas eu faço com que o PO traga uma demanda ali muito mais rica de informações
Speaker:para que o time seja, para que o projeto, para que aquela demanda seja desenvolvida pelo time.
Speaker:E aí esse é o primeiro momento né, pensando ali só no na parte do time né, de quando esse conteúdo
Speaker:chega para o time trabalhar, e aí em cima disso daí eu começo a questionar o PO sobre critérios de aceite né,
Speaker:o que para ele ele considera uma aplicação ok depois de desenvolvida né, então de repente estamos falando
Speaker:de uma aplicação que faz uma transferência bancária, e aí é o site do Banco X, você está com um fundinho roxo,
Speaker:vamos falar que a gente está no aplicativo do Nubank e você precisa fazer uma transferência,
Speaker:quais transferências, quais tipos de transferência? Existe transferência de conta para conta,
Speaker:existe TED de uma conta para outra, agora a gente tem o PIX, a gente pode fazer DOC, a gente pode ter uma infinita,
Speaker:infinitas não, mas nós temos diversas modalidades de transferências, e aí o PO vai me dizer,
Speaker:olha para eu considerar que esse modelo de transferência aí, que essa transação de transferência está ok,
Speaker:a aplicação precisa fazer pelo menos transferências entre contas nesse primeiro momento né,
Speaker:pensando no modelo startup aí, onde o aplicativo do Nubank antes era só uma conta, e ele foi evoluindo com o tempo,
Speaker:qualquer software hoje em dia, a grande maioria dos softwares trabalhando em um contexto ágil acontece dessa mesma forma,
Speaker:então são adicionadas novas funcionalidades naquela aplicação, e aí uma vez que ele me deu um critério de aceite,
Speaker:de que olha, preciso pelo menos fazer uma transferência entre contas, eu como que a vou pensar em cenários
Speaker:para essa transferência, então por exemplo, o Demis vai fazer uma transferência para o Gabriel,
Speaker:ele consegue fazer uma transferência de mil reais se ele tiver só cem na conta?
Speaker:Não deveria, mas e se o Demis tivesse pré-aprovado um crédito de limite por exemplo, ele conseguiria? Conseguiria.
Speaker:O saldo dele ficaria negativo, e aí eu tenho que pensar num monte de cenários que eu vou criar ali,
Speaker:eu posso utilizar, hoje é muito famoso aí o BDD, que todo mundo fala BDD, que é o Behavior Driven Development,
Speaker:que é desenvolvimento guiado por comportamento, então eu vou simular diversos comportamentinhos ali que o usuário vai fazer,
Speaker:então dado que eu tenho uma conta com saldo negativo, e eu tente fazer uma transferência para o Gabriel,
Speaker:aí o resultado esperado é tipo, não poderei fazer a transferência dado que eu não tenho um saldo,
Speaker:dado que eu tenho um saldo de mil reais, um outro cenário, e queira transferir cem reais para o Gabriel,
Speaker:então eu deveria ter o saldo reajustado para novecentos, e o saldo do Gabriel incrementado em cem.
Speaker:Então eu vou criando diversos cenários, e aí quando o time desenvolvimento pega aquilo, ele fala,
Speaker:opa, olha aqui tem esse cenário que faz isso, tem outro cenário que transfere cem dinheiro,
Speaker:tem um cenário que transfere e devita, tem um cenário que ele transfere e o dinheiro sai do limite da conta,
Speaker:e aí o desenvolvedor fala, pô, então eu tenho que criar uma variável para o saldo, uma variável para o limite,
Speaker: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.
Speaker:E depois, essa é a primeira parte do processo, do QA, e aí depois a gente tem diversas outras,
Speaker: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?
Speaker:Não, continua, continua, vamos lá. Então vamos só sumarizar e aí deixa eu ver se eu entendi certo.
Speaker:Então, na primeira parte o teu papel é suportar o Product Owner, ou a pessoa de produto, para que ela consiga,
Speaker:para que você ajude essa pessoa a criar todos os casos, a traduzir tudo aquilo em caso de testes, certo?
Speaker: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,
Speaker:quando é erro, o que acontece, quais são os erros, e isso vai também servir de instrumento para a equipe,
Speaker:tu faz essas duas conexões de sai do produto, a gente tem uma conversa, isso vira alguma coisa, um artefato,
Speaker:você pode dizer qual é o nome, mas tu até comentou aí do desenvolvimento guiado por comportamento?
Speaker:Um artefato pode ser qualquer coisa, pode ser um BDD, o BDD é só um método, muitas pessoas confundem,
Speaker:falam, automatiza em BDD, não existe isso, BDD é um método, que é um desenvolvimento guiado por comportamento,
Speaker: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,
Speaker:que é o pré-requisito, ação e resultado esperado, ou se não, given when then, em inglês, quando a gente escreve,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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
Speaker: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,
Speaker: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
Speaker:desses cenários. Sim, legal, então, entendi essa primeira parte, e aí você estava falando, antes da minha, da minha,
Speaker:da minha sumarização, sobre como que é para a equipe, então passa essa primeira parte, tu entrega algum artefato para eles,
Speaker: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,
Speaker:de alguma coisa você entrega, mas qual que é o teu trabalho durante o desenvolvimento do software? Certo, uma vez que a gente fez esses
Speaker:critérios, a gente vai juntar isso numa planning, ou num refinement, e a gente vai discutir esses artefatos junto com o time,
Speaker: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,
Speaker: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
Speaker: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
Speaker: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,
Speaker: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,
Speaker:e o POA vai buscar essa informação na área de negócio, no cliente dele, para que a gente passe a desenvolver.
Speaker: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?
Speaker:O desenvolvedor começa a codificar, e aí eu como QA, o meu desejo ali de implementar, de melhorar a qualidade do processo,
Speaker:a gente tem uma outra técnica que chama TDD, que é Test Driven Develop, que é desenvolvimento guiado por teste.
Speaker: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?
Speaker: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.
Speaker:E eu posso fazer isso com todos os devs, a gente pode fazer isso em formato de per-programming, a gente pode fazer isso
Speaker:simplesmente com esse artefato que eu entreguei para ele, que tinha os testes, e dali daqueles testes ele vai extrair, olha,
Speaker:desses 50 testes que você me escreveu, 15 aqui eu consigo fazer teste unitário.
Speaker: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.
Speaker:Para quem não conhece a área de qualidade, a pirâmide de teste basicamente é uma pirâmide, mesmo imaginem uma pirâmide,
Speaker:e ela é separada por camadas. Então a camada inferior, que vai ser a camada mais larga, a base da pirâmide,
Speaker:ela é composta de testes unitários, que a maioria dos testes vão estar naquela camada.
Speaker:Depois a gente vem para testes de componente, depois a gente vem para testes de integração,
Speaker:testes de sistema, e por último a gente vai ter o teste de interface, que é o teste visual,
Speaker:quando eu tenho um app na minha mão no celular, quando eu tenho uma página web que eu vou testar.
Speaker: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,
Speaker:olhando para essa pirâmide. Ah, nesse caso de teste aqui eu consigo cobrir ele na camada de teste unitário?
Speaker:Consigo? Não consigo? Em qual camada acima eu consigo? E eu vou diluindo essa lista dentro dessa pirâmide.
Speaker:Por que a gente olha para a pirâmide? Porque quanto mais baixo nessas camadas da pirâmide,
Speaker: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.
Speaker:E quando a gente está em um time ágil, é muito importante a gente ter um feedback rápido
Speaker:daquela aplicação, se ela funciona ou não funciona. Então é nesse momento que o QA senta ali com o time
Speaker:e começa a desenvolver a primeira camada de baixo, inferior, da pirâmide de teste.
Speaker:E aí depois a gente continua trabalhando e diluindo nas demais camadas.
Speaker:E tu consegue, sei que é uma pergunta talvez difícil de trazer na prática, mas se tu tiver algum exemplo
Speaker:de qual tipo de teste você deixaria para a parte de teste de unidade, como você falou, é o teste muito mais rápido
Speaker: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
Speaker:ou a regra de negócio. E o que tu colocaria nas próximas camadas também?
Speaker:Bom, basicamente, eu colocaria nas camadas inferiores tudo o que fosse possível.
Speaker: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
Speaker:e não coloco a senha e clico no botão logar. Isso daí tem que me dar uma mensagem de erro, falando
Speaker:opa, email ou senha inválidos, ou o campo não pode ficar em branco. Eu consigo validar isso no teste unitário?
Speaker:Consigo. Então eu posso ter no teste unitário do código front, do back-end e posso ter no teste unitário
Speaker:do front-end. Eu consigo ter teste unitário nessas duas camadas e eu posso validar isso também de forma manual
Speaker:utilizando, eu posso validar de forma automatizada através da interface. Mais uma vez que eu sei que esse teste
Speaker:está coberto na camada unitária, eu não preciso me preocupar em fazer esse teste ali na camada de teste de regressão
Speaker:que a gente chama. É aquela bateria de teste que é executada toda vez que é feita uma alteração em qualquer parte
Speaker:do código para garantir que tudo que estava funcionando antes continua funcionando mesmo após aquela alteração.
Speaker:Entendi. E qual camada que tu atua mais na prática? Porque se eu entendi bem o teste de unidade você vai dar suporte
Speaker:no TDD, no teste de unidade ali ao desenvolvedor. E qual camada normalmente no teu contexto já para de ser o dev
Speaker:e passa a ser o QA mesmo a fazer o teste?
Speaker:A partir da camada de sistema. A partir da camada de sistema, pensando em microserviços eu vou ter uma API.
Speaker:Bom, para quem não sabe o que é uma API, pense em você como cliente de um restaurante. Você chega num restaurante
Speaker:e você é atendido por um garçom. O garçom vai te perguntar o que você quer, você vai informar o que você quer,
Speaker:ele vai até a cozinha, pede para a cozinha e traz o seu pedido. Então o garçom representa uma API.
Speaker:E o que é uma API? É uma Application Program Interface, que é uma interface de programa de uma aplicação.
Speaker:Então imagina quando você entra no Google, você vê a tela do Google ali e aquela lá, aquilo ali é o seu front-end,
Speaker: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
Speaker: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.
Speaker: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,
Speaker: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,
Speaker:posso até automatizar testes dentro do Postman e eu posso usar outros plugins, até para o VS Code.
Speaker:O VS Code é como se fosse o Word dos desenvolvedores, onde o desenvolvedor escreve os códigos dele.
Speaker:E aí tem alguns plugins que você instala no VS Code que você pode fazer a mesma transação, assim como no Postman,
Speaker: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,
Speaker: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.
Speaker:E daí para frente eu consigo eu com o QA testar. Eu posso fazer isso de forma manual, usando o Postman,
Speaker:posso fazer isso de forma automatizada, e aí vai depender da linguagem de programação utilizada,
Speaker:eu vou ter um framework específico para cada uma dessas linguagens.
Speaker:E aí depois da camada de API, eu vou ter a outra camada, que é a camada da interface, que eu vou testar também,
Speaker:com o framework específico para cada linguagem de programação, mas aí eu já vou estar testando um front-end,
Speaker:uma tela, onde eu posso interagir e ver comportamentos visuales.
Speaker:Deixa eu te perguntar uma coisa, porque mais ou menos dois anos atrás, pandemia, comecei no meio, tempo sobrando em casa,
Speaker:comecei a programar de novo e estava fazendo um sistema para controlar ações.
Speaker: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.
Speaker:Fui pegando as APIs, juntando tudo e fui fazendo o que eu queria.
Speaker:Quando eu comecei a fazer os testes, os de unidades eram simples, dava para fazer, mas quando eu ia para outra camada,
Speaker:eu ficava na dúvida de se eu fazia da API, ali dos controllers, ou se eu ia para a tela principal,
Speaker:que era muito mais caro, tempo de fazer ele, quebra muito mais fácil que toda hora que eu mudo o layout,
Speaker:mas depois de um tempo testando, eu, não sou programador faz um tempo, então estava ali aprendendo, brincando com as coisas,
Speaker:mas eu acabei decidindo ficar só com o layout, porque o da API não cobria muita coisa.
Speaker:Fiquei, se eu tiver que fazer os dois, eu vou gastar muito tempo, então eu vou priorizar uma aqui, eu vou priorizar unidade,
Speaker:e o da tela mesmo, que era simular o uso do usuário final.
Speaker:O que eu fiz, normalmente, o que eu vou encontrar no mercado, ou foi minha, vamos dizer, minha amadorice,
Speaker:a falta de conhecimento, que me levou a fazer isso? O que você vê normalmente no seu dia a dia?
Speaker:Você vai testar mais a coisa na prática, lá no final, ou mais na API?
Speaker:O que você vai ver no mercado mais é testando, nem vai ter muito, pouca gente faz testes unitários,
Speaker:então o que você vai ver mais é a pessoa testando lá no final.
Speaker:E aí, qual é o problema disso? Uma vez que você tem uma aplicação muito grande,
Speaker:a quantidade de testes que você tem no front-end, por ele executar muito mais lento,
Speaker:o seu feedback vai demorar muito mais, e você, de repente, o que vai acontecer?
Speaker:Quando a gente está testando uma tela, pode acontecer de ela demorar para carregar,
Speaker:e aí o teste falha, o time-out, tem inúmeros que a gente chama de flick test,
Speaker:que são os testes que falham, mas não foi porque a aplicação está com problema,
Speaker:e sim a automação ali precisa ser ajustada.
Speaker:E isso já aconteceu comigo, eu trabalhava na Senova, que hoje em dia é a Via Parejo,
Speaker:e a gente testava todos os sites da Casbahia, Ponto Frio, Extra, até o site da Nike,
Speaker:era tudo na plataforma da Via Parejo, e aí os testes demoravam quatro horas para executar,
Speaker:e aí se falhava um teste, como você faz? Você vai confiar, e aí você vai lá e executa só aquele teste,
Speaker:como que fica? Só que quatro horas é muito tempo,
Speaker:porque no tempo que eu trabalhava na última empresa anterior aqui em Portugal,
Speaker:o nosso feedback era de menos de dez minutos, então é uma coisa bem diferente,
Speaker:e mesmo assim já aconteceu vários casos do time de desenvolvimento ter tanta confiança,
Speaker:entre aspas, de que aquilo estava ok, de desligar a automação, a validação da automação de teste,
Speaker:e colocar aquilo em produção, porque era um problema muito urgente, ou coisa do tipo,
Speaker:e depois remediar aquilo se fosse necessário. Então o que você vai ver de mais comum
Speaker:é uma bateria de teste muito grande na última camada, que é a camada da interface,
Speaker:o que é um erro bastante grave e que custa muito dinheiro. E tempo.
Speaker:É, dez minutos não é... é lento, né? Porque o que tu falou também,
Speaker:esses testes eu rodava quando eu ia fazer o request, quando eu mandava para o Git, rodava ele,
Speaker:porque eu comecei com... na minha máquina, né? Eu estava numa plataforma na Cloud, na...
Speaker:na Blu, eu esqueci o nome dela, mas enfim, e ele era lento, eu falei,
Speaker:não dá para ficar programando e parando, né? No começo era, sei lá, dois minutos?
Speaker:Mas dois minutos é muito lento.
Speaker:Dez minutos é o tempo da pipeline, né?
Speaker:Sim, da pipeline inteira, eu sei.
Speaker:É, correr dez minutos vai correr todos os testes e cai na produção.
Speaker:Normalmente os testes de um etário correm em segundos, né?
Speaker:Segundos, sim.
Speaker:Segundos, é... eu acho que ele gerava em torno de 12 segundos a bateria de teste.
Speaker:Ah, todos eles?
Speaker:Os testes unitários, né? Aí, conforme você vai subindo, mais lento vai ficando.
Speaker:Mas não... mas não chega a ficar mais de três minutos, assim, a partir de testes.
Speaker:Só um teste, né?
Speaker:Entendi.
Speaker:Rodando e executando.
Speaker:Entendi, então é muito da minha pequena experiência fazendo eles também,
Speaker:é que qualquer modificaçãozinha, às vezes, no JavaScript, aí quebrava.
Speaker:Mas o que tu falou, né? Vai, vai.
Speaker:Não, é que aparentemente quando a gente fala assim, o que você está falando?
Speaker:Você fez uma aplicação e você foi testar.
Speaker:Você fez o teste unitário, bacana, volta rapidinho, e eu vou testar a minha interface.
Speaker:É meio que parece óbvio, né? Tipo, não.
Speaker:O que eu vou entregar para o usuário é uma interface.
Speaker:Eu vou testar a interface, a interface está ok quando para frente está em produção, beleza.
Speaker:Só que quando você está com uma aplicação pequena, ok, isso funciona, que é uma beleza, vai embora.
Speaker:Mas imagina que sua aplicação vai crescendo, como a gente se referiu aqui,
Speaker:ao aplicativo do Nubank.
Speaker:Antes era só um mano conta, depois começou a fazer transferência só entre contas Nubank.
Speaker:Depois começou a fazer transferência entre outros bancos, depois veio cartão de crédito,
Speaker:depois veio o TEDPIX, veio todas as outras ações.
Speaker:Então imagina você validar tudo isso de forma na interface.
Speaker:Vai começar a sobrecarregar ali de tempo, essa sua pipeline de teste, de correr para colocar aquela aplicação em produção,
Speaker:vai começar a ficar muito demorado.
Speaker:E aí o que vai acontecer? Vamos falar, aonde está demorando mais aqui?
Speaker:Ah, é nos testes. Então precisamos tirar os testes da pipeline.
Speaker:Já vi muito isso acontecer.
Speaker:Então o que a gente precisa fazer para tirar os testes?
Speaker:Uma vez que você tirou o teste, qual a sua garantia que tudo ali vai funcionar em produção com o usuário?
Speaker:Entendeu? Então é muito comum a gente ter esse cenário que você fez aí na sua aplicação.
Speaker:Isso em produção, em grandes empresas.
Speaker: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,
Speaker:é justamente pegar tudo que está automatizado ali na interface e falar,
Speaker:pessoal, espera aí, a gente não consegue trazer isso aqui para o unitário?
Speaker:Olha, então eu vi esse cenário aqui, só que a gente consegue cobrir no unitário.
Speaker:Vocês conseguem criar isso aqui no unitário, na camada de teste?
Speaker:Claro, conseguimos, Tim, qual.
Speaker:Aí isso aqui, a gente não consegue testar em um componente, isso aqui a gente não consegue testar via API?
Speaker:Ah, conseguimos. E aí você vai divulgando isso.
Speaker:E uma coisa que tem sido muito comum é o famoso teste exploratório.
Speaker:E o que é o teste exploratório?
Speaker:Depois que você está com a aplicação lá em produção, depois de ter rodado todos os testes lá,
Speaker:imagina que a gente tem todas as camadas de testes cobertas para automação,
Speaker:por fim colocou em produção, eu vou lá como usuário e começo a navegar na aplicação.
Speaker:Vou em busca de erros que possam acontecer, que já aconteceram no passado,
Speaker:ou que já aconteceram na minha experiência com o QA.
Speaker:Por exemplo, eu estive testando uma aplicação nova aqui e eu já tive experiência de aplicações,
Speaker:por exemplo, que eu fui me logar e a aplicação me permitia me logar mesmo que a senha estivesse errada.
Speaker:Então eu vou tentar simular aquilo lá de forma exploratória, só um exemplo.
Speaker:Ou senão eu clicava na tecla voltar e não fazia nada.
Speaker:Então o teste exploratório vai muito baseado na experiência profissional que está testando.
Speaker:Ele vai se recordar de tudo que ele já testou, problemas que ele encontrou,
Speaker:e ele vai tentar simular nessa nova aplicação.
Speaker:Então uma vez que eu tenha todos os testes construídos de forma bonitinha,
Speaker:um processo legal, eu posso ainda incrementar fazendo um teste exploratório.
Speaker:Tanto eu quanto o PO e a equipe pode fazer esse trabalho.
Speaker:Legal, legal.
Speaker:Só dar um passo atrás e falar um pouco mais da minha experiência também,
Speaker:que de fato foi muito difícil, às vezes eu desligava o teste,
Speaker:porque demorava dois minutos, mas para uma aplicação pequena dois minutos era muito tempo
Speaker:e às vezes eu estava fazendo as horas vagas e eu ficava,
Speaker:poxa, eu quero acabar uma coisinha aqui, eu vou mudar a tela inteira e depois eu vou rodar ele de uma vez.
Speaker:Só que era muito difícil mesmo.
Speaker:Quando eu consertava ele, ok, mas dependendo do tipo de mudança.
Speaker:Então acho que começa a fazer sentido o que tu falou de tentar cobrir primeiro as camadas de baixo
Speaker:e lá em cima ficar o que é essencial, porque é muito mais demorado e caro
Speaker:e de manutenção mais lenta.
Speaker:Sim, essa tarefa, Gabriel, é uma tarefa que nenhum desenvolvedor gosta de fazer, a parte dos testes.
Speaker:E uma vez que você começa a aplicar o TDD, por exemplo, que é começar a criar o teste primeiro,
Speaker:aí você faz esse teste, ele vai criar o teste, você vai rodar, ele vai falhar,
Speaker:porque não existe código para ele validar, aí você implementa o código, você vai executar o teste,
Speaker:o teste vai passar, aí você vai refatorar o seu teste, depois você refatora o código principal
Speaker:e você vai fazendo. É um trabalho assim que, por exemplo, de três a seis meses vai ser um saco para o desenvolvedor fazer.
Speaker:Mas uma vez que ele começa a executar aquilo, ele começa a enxergar tanto o valor naquilo lá,
Speaker:que ele fala, puta, eu sempre tive uma visão errada, uma visão assim, eu sempre compliquei esse trabalho aqui
Speaker: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,
Speaker:porque muitas vezes um teste unitário, ele pode virar três ou quatro, não apenas um Ctrl C, Ctrl V,
Speaker:mudando ali variáveis daquele teste, as informações que eu vou estar processando.
Speaker: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.
Speaker:E aí o conjunto desses dois caras trocando informações ali, isso é bom tanto para o QA quanto para o Dev.
Speaker:O QA, da mesma forma que ele está ali passando esse conhecimento para o Dev, ele começa a absorver conhecimento técnico.
Speaker:Até mesmo tem muitos QAs hoje que não automatizam, que não sabem programação.
Speaker:E nessa troca de experiência, o QA também começa a ter uma visão ali de lógica, da linguagem, sintaxe,
Speaker:que estava sendo usada, e isso vai ajudar o QA também na hora da programação dos testes automatizados.
Speaker:Não, total, total. Eu tinha na minha experiência pequena novamente.
Speaker:Claro que quando eu era programador mesmo eu tive a experiência como QA, mas falando nessa recente individual,
Speaker:toda vez que eu desliguei o teste depois era muito pior para o pequeno ganho que tinha de fazer alguma coisinha,
Speaker:depois tinha que pagar em duplo para corrigir tudo.
Speaker:Sim. Eu queria saber agora onde que entram esses testes dentro do desenvolvimento.
Speaker:Eu acho que hoje é muito comum, pelo menos todas as empresas que eu passei até agora nos últimos anos,
Speaker:a gente trabalhar com sprints.
Speaker:Independente de trabalhar com scrum, Kanban, de não ter nenhum dos dois, mas quase sempre o trabalho é dividido ali
Speaker:em algum período, de duas semanas, um mês.
Speaker: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.
Speaker:E onde entra o trabalho do QA? A gente entrega as coisas e a gente testa na próxima sprint, a gente testa junto,
Speaker:o que você vê no mercado, na sua experiência, o que você acha que é o correto?
Speaker:Eu não acho que existe um certo ou errado, existe a melhoria contínua.
Speaker:Pode ser que hoje o time tenha um QA que não saiba programar, por exemplo,
Speaker:foi o exemplo que a gente acabou de dar anteriormente aqui nessa troca de experiência,
Speaker:mas ele vai evoluir junto com o time, assim como deve vai evoluir o mindset de entender o usuário,
Speaker:o QA tem que evoluir o nível de conhecimento dele de programação, começar a automatizar aos poucos.
Speaker:Eu enxergo o QA como uma figura que está em evolução desde quando eu comecei,
Speaker:não desde quando eu comecei, mas desde quando o teste foi criado lá atrás,
Speaker:em 1900, se alguma coisa eu esqueci agora a data, mas já fazem 40 e pouquinhos anos que tem essa modalidade.
Speaker: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ó,
Speaker:ele vai ser um desenvolvedor focado em negócio e focado em teste.
Speaker:E respondendo a sua pergunta especificamente, o QA vai, dependendo do cenário de onde ele estiver,
Speaker:pode ser que ele não automatize, então ele tem que estar inserido junto com o time,
Speaker:e ir falando, ó pessoal, precisamos automatizar, vamos automatizar, sentar junto, e automatizar todas as camadas possíveis junto com o time.
Speaker:O teste não é responsabilidade do QA, o teste é responsabilidade da equipe.
Speaker:O QA é o evangelizador da qualidade e dos frameworks, das ferramentas que podem ajudar a equipe a entregar a melhor qualidade.
Speaker:Então ele pode estar ali junto com o time e desenvolver isso.
Speaker:Uma vez que ele saiba automatizar e que ele tenha conseguido trabalhar com o time durante todas aquelas duas semanas de desenvolvimento,
Speaker:teve tempo para automatizar esses testes no final da sprint antes de colocar isso em produção, ótimo.
Speaker:É um cenário que eu não conquistei ainda, chegar de eu ter tempo para fazer tudo isso.
Speaker:O que normalmente eu faço e que funciona?
Speaker:Eu testo aquela nova feature, aquela nova demanda, testo manualmente, ali dentro da sprint, e a gente coloca em produção.
Speaker:No começo da próxima sprint, enquanto os desenvolvedores estão...
Speaker:A gente está na parte de planning, a gente está na parte do desenvolvedor colocar a mão nos primeiros códigos,
Speaker:eu estou trabalhando na automação da sprint anterior.
Speaker:Então quando eu chegar no final dessa sprint atual, a minha sprint anterior vai estar automatizada.
Speaker:E eu estou sempre com esse débito da sprint anterior na questão da automação.
Speaker:Mas isso vai de maturidade de time, Gabriel, vai muito de conhecimento, do que há, do quanto técnico ele é.
Speaker:A gente tem muita variação de profissionais de qualidade dentro dos times.
Speaker:E aí podem ter vários formatos diferentes.
Speaker:Mas eu acredito que no futuro, 15 anos aí para frente, a gente vai ter esse cara...
Speaker:A gente até tem os títulos hoje no LinkedIn, a gente vê muito software engineer no teste.
Speaker:Então não é mais um QA, é um engenheiro de software focado em teste.
Speaker:E ele vai utilizar todo aquele conhecimento base do QA para trabalhar dentro dessa equipe.
Speaker:Entendi. Se eu entendi direito, tu quer dizer que é difícil,
Speaker:mas tu quer aproximar mais de quando a coisa foi...
Speaker:Acabou o desenvolvimento e o teste é feito para, de algum momento, tudo isso acabar dentro do próprio sprint.
Speaker:Certo?
Speaker:O ideal é que tudo isso aconteça dentro da sprint.
Speaker:Mas é difícil, porque, tipo, primeiro os desenvolvedores começam, depois vocês vão testar.
Speaker:Então está sempre tentando correr atrás, mas com a ideia de se aproximar mais.
Speaker:Isso. É difícil porque depende da equipe ali, da empresa.
Speaker:A gente, por exemplo, eu já trabalhei em time, que demandas chegavam no meio da sprint.
Speaker:E aí tudo saía do trilho, porque você chega uma demanda no meio da sprint, você tem que descobrir ela,
Speaker:você tem que criar todos os artefatos que o time desenvolver e tem que entregar dentro da sprint.
Speaker:Então fica surreal esse trabalho, acaba se tornando insano.
Speaker:O que a gente fez para solucionar esse problema no time, quando a gente tinha essas demandas que chegavam top down?
Speaker:A gente mudou de sprint. Saiu do sprint, começou a trabalhar com o Kanban, chegava uma demanda nova,
Speaker:a gente parava e estava fazendo, priorizava a demanda nova e iniciava o processo daquela demanda nova.
Speaker:Então ela ia até o final, muitas vezes a gente colocava em produção e depois criava task de automação,
Speaker:ou se fosse algo que dava para automatizar, mas sim, porque se automatizava e entregava já automatizado.
Speaker:Mas vai muito da maturidade não só do time, vai maturidade da empresa, da cultura da empresa.
Speaker:Então você aí como ajaio coach, você está muito inserido nessa parte organizacional onde o QA não atua,
Speaker:no contexto de time. Então você trabalha nessa parte e entende bem essa questão das demandas chegarem
Speaker:durante o time estar trabalhando e bem complicado.
Speaker:Agora queria passar para outra e aí eu vou primeiro contar um caos aqui e depois eu vou pedir a tua opinião,
Speaker:que é sobre o que QA é medido. Tem aquela frase que é diga-me como me mede, que eu direi como me comportarei.
Speaker:Exato.
Speaker:Eu tenho um caos parecido com o DevOps também, mas trabalhei numa equipe que a gente tinha todos os testers,
Speaker:isso foi no começo de carreira ainda, todos os testers, eu não sabia muita coisa, então hoje eu consigo entender
Speaker:isso melhor, mas todos os testers ficavam numa equipe só separada, então você tinha os times de desenvolvimento
Speaker:que eram separados pela parte do produto, pela entrega de valor, isso era até bem legalzinho, só que os testers
Speaker:ficavam separados. E a minha pergunta agora vai ser sobre como o QA é medido, porque esses QAs eram medidos
Speaker:por quantidade de bugs que eles pegavam. Então isso eu acho que tu desenha o cenário, desenha a forma de trabalhar
Speaker: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
Speaker:em conjunto ou não. E com essa meta o que acontecia é que existia uma rixa muito grande e acontecia situações
Speaker:que eu acabei descobrindo depois de os QAs segurar um pouco de bug para achar tudo em determinado momento,
Speaker: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
Speaker:foi pegando nenhum bug, vocês não estão trabalhando direito, tudo isso era manual. E tudo isso para te falar
Speaker:do caos que isso gerava e perguntar qual seria a forma mais correta de um QA ser avaliado dentro de uma equipe,
Speaker: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?
Speaker:Bom, eu trabalho desde essa época que você falou, a gente era conhecido como fábrica de teste, fábrica de software.
Speaker:A fábrica de software era o time dev construindo que mandava para uma outra fábrica diferente, uma fábrica,
Speaker:basicamente uma empresa, a gente tem a empresa A construindo software, a empresa B testando software.
Speaker:E eu trabalhei nesse formato, é um formato horrível, onde você não tem comunicação, a comunicação é zero entre QA e dev,
Speaker:e existe a rixa, existe a rixa não, existem os borburinhos das rixas antigas que haviam entre dev e QA,
Speaker:muito por conta disso, porque o QA reportava, mas ele não conhecia o dev, ele não sabia nada, reportava,
Speaker:e ele disse, não, para mim não funciona, o requisito diz isso e não está aqui no requisito,
Speaker:só que esse requisito às vezes tinha mudado e não era atualizado, a gente tinha inúmeros artefatos, documentos,
Speaker:quando eu falo artefatos eu falo de documentos, no passado, que isso vai ficar aí por terra, com a chegada da agilidade e tudo,
Speaker:e a gente foi formatando isso. A gente antigamente media muito essa questão de número de bugs,
Speaker:e eu já vi como testador, eu já vi criando 400 mil cenários da mesma coisa, validar caracteres especial,
Speaker:aí o cara punha asterisco e colocava barra, todos dois são caracteres, eu não preciso de dois testes, eu preciso de um.
Speaker:Precisa de dois bugs reportados.
Speaker:É, e aí fica reportando essa ideia de gestão, que antigamente as fábricas de teste venhavam por bug encontrado,
Speaker:então não era questão de como reportar o trabalho do que há, era uma forma de ganhar dinheiro,
Speaker:então as fábricas de teste ganhavam por bug, por número de casos de testes utilizados,
Speaker:então olha, minha equipe criou 5 mil casos de teste, não é um negócio assim, tipo, apenas para fazer dinheiro,
Speaker:não estava muito focado em qualidade de comunicação e etc.
Speaker:Hoje, quais são as métricas que eu tenho utilizado? As mesmas de um time ágil, então throughput, second time, lead time,
Speaker:eu tenho utilizado essas mesmas métricas para medir o time, pensando, tenho trabalhado sempre pensando assim,
Speaker:teste, qualidade, tem que estar presente, então faz parte do trabalho, não é algo à parte,
Speaker:então uma demanda não sai, quando a gente fala definition of run, definition of read,
Speaker:ela não sai para entrega se ela não cumprir uma lista de critérios,
Speaker:um dos critérios é ter os testes automatizados, ter a documentação daquela funcionalidade na ferramenta,
Speaker:seja lá o Confliss, ou qualquer outra ferramenta, então eu não tenho utilizado nenhuma métrica nesse sentido para validar teste,
Speaker:o que eu tenho utilizado é implementar ferramentas, por exemplo, existem ferramentas para você metrificar a qualidade do código,
Speaker:como por exemplo o SonarQube, a gente consegue utilizar o SonarQube para ver lá se o nosso código tem qualidade ou não,
Speaker:a gente tem testes de mutação, que é uma ferramenta que se chama StrikeMutator, você executa ela,
Speaker:e ela vai validar todos os testes unitários e ver se toda a mutação que ela fez no código fonte,
Speaker:se os testes unitários cumpriram, e ela vai te dar lá o percentil de que o teste está bacana ou não,
Speaker:e ela vai te dar até os testes que estão faltando, que aí torna muito mais fácil a vida do desenvolvedor,
Speaker:que chega lá e fala assim, preciso fazer um teste para contê-lo isso daqui, e valido ali aumenta minha cobertura,
Speaker:então pensando nesse cenário que a aplicação só sai com teste, eu não me preocupo com métrica de teste,
Speaker:eu me preocupo com métrica de qualidade, então o que a gente pode fazer é tipo, depois que está em produção,
Speaker:bugs que foram encontrados, se um bug que foi encontrado já foi encontrado anteriormente, isso é um problema para mim,
Speaker:porque se a gente já encontrou esse bug, por que ele apareceu de novo e não tem um teste que valide aquilo,
Speaker:para que ele não acontecesse de novo? Bug sempre vai existir, ele sempre vai acontecer,
Speaker:a gente trabalha para minimizar esse risco, então uma vez que tem uma recorrência de um bug em produção,
Speaker: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.
Speaker:Mas esse é um problema grave para a equipe, deixa de ser uma coisa de fábrica.
Speaker:Para o produto em si.
Speaker:Legal, então deixa eu tentar ver se eu capturei bem aqui resumindo, aí tu me corrigi qualquer coisa.
Speaker: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á,
Speaker: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,
Speaker:era como se fosse aqui, separado dentro da própria empresa, e era esse modelo de fábrica de software, e depois mudou,
Speaker:até quando mudou a inimizidade, a falta de amizade entre eles.
Speaker:Inimizade.
Speaker:Inimizade, isso, entre eles durou, porque já a gente tinha a rixa, mas enfim.
Speaker: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,
Speaker: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,
Speaker:lead time, cycle time, tipo de desenvolvimento, a produção, quanto tempo demora em dias, e de quando o cliente pediu,
Speaker:quanto tempo foi na produção.
Speaker: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.
Speaker:Produção.
Speaker: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,
Speaker:mas é o problema da equipe não, da equipe de QA's versus desenvolvedor, está todo mundo junto.
Speaker:Exato.
Speaker:Quando a gente trata bug como um problema dentro do desenvolvimento, a gente vai ter essa rixa de deve que a,
Speaker:o Demis reportou um bug meu, não podia ter conversado comigo, isso já aconteceu muito, quando eu comecei no passado que era,
Speaker:ainda hoje existe isso, muitos líderes querendo métrica de bug em desenvolvimento, cara, está em desenvolvimento,
Speaker:achar bug faz parte do trabalho, eu não posso metrificar o Gabriel, o desenvolvedor, por ter criado cinco bugs,
Speaker:sendo que ele estava desenvolvendo aquilo, o trabalho ali é justamente desenvolver, testar e entregar algo sem bugs,
Speaker:mas enquanto está desenvolvendo, está desenvolvendo, eu não posso ficar criando bug, tem muito líder que pede isso,
Speaker:quero saber quando os bugs foram produzidos por desenvolvedor, cara, para quê?
Speaker:Para chicotir o cara, para demitir? É essa a forma que você vai tratar seus funcionários? Não faz sentido isso.
Speaker:Então para mim, bug é bug em produção, em fase de desenvolvimento não é um bug, é uma falha que precisa ser corrigida,
Speaker: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.
Speaker: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,
Speaker:é eliminar essa questão bug, olha Gabriel, encontrei um bug, temos uma falha que precisa ser corrigida,
Speaker:e aí põe para o time, pode ser na dele, pode ser durante o dia, alivia a slack, encontrei uma falha nisso aqui,
Speaker:precisamos corrigir, e beleza, não interessa quem produziu, interessa que a equipe vai ganhando músculo no decorrer do tempo.
Speaker:E aí eu vou olhando para as métricas lá, ágeis e falando, olha, antigamente a gente demorava 3 semanas para desenvolver
Speaker:um pedacinho de software do tamanho X, e hoje a gente demora uma semana,
Speaker:então pô, a gente evoluiu e a gente continua implementando a qualidade, fazemos testes automatizados, fazemos testes inúmeros,
Speaker: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,
Speaker:e entrega isso no menor prazo, para mim é essa a métrica que conta pensando que a gente está trabalhando em um time,
Speaker:e esse time vai amadurecendo junto, vai ganhando músculo junto.
Speaker:Sim, eu até pensando em métrica, eu até gosto dessa métrica de quantas falhas e retrabalho teve assim dentro da equipe,
Speaker: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,
Speaker:como que a gente minimiza, tá, esse desenvolvedor aqui está criando mais, como equipe a gente monta um plano para que essa pessoa
Speaker:aprenda mais sobre esse módulo, sobre essa parte do código, ou é o código talvez, como que a gente vai refatorar,
Speaker:a gente tem que criar aqui alguma tarefa para colocar no backlog para a gente corrigir isso e a gente evitar falha.
Speaker:Então eu até gosto dessa métrica quando não está nesse modelo de Keyways versus desenvolvedores, versus manager,
Speaker:que quer procurar alguém para culpar pelos atrasos, o problema, então acho que é tudo como a gente usa, mas depende muito.
Speaker: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?
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker: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,
Speaker:à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,
Speaker: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í,
Speaker:o que eu posso fazer para te ajudar? E aí você senta do lado do cara e ajuda, simples assim, entendeu?
Speaker: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,
Speaker: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á,
Speaker: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
Speaker:alguma coisa que invalidasse o bug.
Speaker: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
Speaker: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,
Speaker: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,
Speaker:ou não trabalha com tecnologia e quer migrar de carreira, ou talvez até um desenvolvedor que acha que no desenvolvimento de software, sabe,
Speaker: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,
Speaker: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,
Speaker:o que é que essas pessoas, na tua opinião, deveriam começar estudando?
Speaker: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,
Speaker:então você vai estar sempre evoluindo junto com a tecnologia e vai ter que estar sempre aprendendo.
Speaker: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.
Speaker: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.
Speaker: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,
Speaker:vai ter que gostar de programar o mínimo necessário para você criar seu script.
Speaker:E eu acho que é importante ele saber isso.
Speaker: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,
Speaker:eu lendo hoje o mesmo livro que eu ganhei lá em 2009, eu tenho uma visão completamente diferente do mesmo livro.
Speaker:Então, lá atrás ele dizia o formato de trabalhar, que é basicamente o que a gente está falando aqui hoje.
Speaker: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.
Speaker: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.
Speaker:Só que a gente foi trabalhando separado. E isso daí, essa base de conhecimento é importante para qualquer pessoa.
Speaker: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.
Speaker:É 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,
Speaker:assiste às videoaulas, vê se encaixa ali com aquele modelo que ele está ensinando e depois busca evolução.
Speaker: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.
Speaker: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,
Speaker: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.
Speaker: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.
Speaker: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?
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker:Então, pensando aí, falando mais um item do perfil, fora a questão de comunicação e tal, é o solucionador de problemas.
Speaker: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.
Speaker:Vocês veem outro modelo, outra solução que a gente possa para resolver esse problema?
Speaker: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.
Speaker: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.
Speaker: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.
Speaker: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?
Speaker:A gente pode criar um ambiente só nosso? A gente pode testar isso localmente? O que a gente pode fazer?
Speaker:E aí a gente deixou, por exemplo, de usar o ambiente de teste e passou a usar o ambiente local. E solucionamos o problema.
Speaker:Então, a gente tem que estar sempre com esse pensamento de solucionar problemas.
Speaker: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.
Speaker: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.
Speaker: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.
Speaker:Bom, eu tenho desenvolvido treinamentos e eventos na área de qualidade desde 2017 e dá para encontrar tudo em bileb.com.br, né?
Speaker: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.
Speaker:O Gabriel vai estar aqui embaixo na descrição do vídeo.
Speaker:Perfeito, vai estar tudo aqui na descrição do vídeo, podcast, independente de onde vocês estiverem ouvindo, vocês vão achar.
Speaker: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?
Speaker: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.
Speaker:E também no LinkedIn, sempre compartilho conteúdo lá.
Speaker: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.
Speaker: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.
Speaker:À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,
Speaker: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.
Speaker: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.
Speaker: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á.
Speaker:Faz um ano já.
Speaker:Caramba, faz um ano.
Speaker:Bom, obrigado pelo convite, valeu pelo compartilhamento, a gente poderia ficar horas aqui falando.
Speaker:Valeu, e mais uma vez, se precisar de mim, só contem comigo e quem tiver ouvindo, se quiser contar.
