Latest / Entre Chaves / Snippet #33 Os limites reais da IA nos testes

Transcript

Snippet #33 Os limites reais da IA nos testes · Entre Chaves

• 0:00
  Olá pessoal, bem vindos a mais um snipet aqui no enter de
• 0:02
  chaves me chamo Victor kassemildo e hoje a gente vai
• 0:05
  falar sobre um tema que afeta praticamente todos os QAS que
• 0:07
  trabalham com automação. Muito já se foi dito dos
• 0:10
  benefícios da automação dentro de uma release ou de uma sprint.
• 0:13
  Também pouco se fala sobre os custos do setup dessa automação.
• 0:16
  É muito comum ver um QA gastando muito mais tempo preparando o
• 0:20
  terreno para essa automação do que de fato testando.
• 0:22
  E esse terreno inclui page, object, fifty, mox e até mesmo
• 0:26
  institutação de pastas. A gente gasta um bom tempo
• 0:29
  pensando em como fazer isso e de fato fazendo.
• 0:31
  E esse é justamente o problema que iremos resolver neste
• 0:33
  episódio do snippet. Utilizando o conceito de
• 0:36
  perpergraming com inteligência artificial.
• 0:38
  O conceito de perpergraming vem do Extreme e pergraming, que é
• 0:42
  basicamente uma ideia simples, 2 desenvolvedores, um coda,
• 0:46
  enquanto o outro revisa em tempo real com OEA.
• 0:48
  Esse conceito se transforma em algo mais próximo de um co
• 0:51
  pilot, porém com um parceiro 24 horas disponível.
• 0:54
  Mas tem um ponto que precisa ser esclarecido desde o início, é
• 0:57
  você quem? No comando como um copart, a IA
• 1:00
  nunca deve decidir estratégia de testes ou mesmo o que testar.
• 1:04
  Dito isso, vamos então as 3 formas práticas de usaria no dia
• 1:07
  a dia. A primeira, e que eu juro será
• 1:09
  mais importante, é, usaria a para o trabalho mecânico da
• 1:12
  automação, o trabalho repetitivo.
• 1:14
  Ou seja, de criação de page objetivos, fictores e até mesmo
• 1:17
  o ox antes da ya, a gente criava Peugeot e ficture linha por
• 1:21
  linha. A gente IA até o código fonte ou
• 1:23
  HTML, lia cada um dos ADSE, transcrevia tudo aquilo
• 1:27
  manualmente para o nosso código. Hoje com OIAO processo é muito
• 1:30
  mais simples e direto. Com o simples prompt eu peço AIA
• 1:33
  para que ela gere um page objetiv e fixo e com o padrão de
• 1:36
  projeto que eu utilizo passando apenas no HTMLE da página, ou
• 1:40
  mesmo uma descrição breve do que eu preciso.
• 1:42
  Essa estrutura levaria cerca de. De 20 a 30 minutos para que eu
• 1:45
  construísse a mão linha por vinho.
• 1:47
  A aya gera isso em cerca de 5 minutos e eu gastando mais 5
• 1:52
  minutos para revisão, eu economeio cerca de 10 a 20.
• 1:55
  Se a gente multiplicar isso por sprint ou por páginas, a gente
• 1:59
  consegue ver um ganho significativo de tempo durante
• 2:01
  todo o processo. Isso é basicamente uma delegação
• 2:04
  inteligente de trabalho mecânico e repetitivo.
• 2:07
  Porém, nunca se esqueça de revisar todo o código antes.
• 2:10
  Aya sempre vale Rai em algum caso.
• 2:12
  E é você que é responsável por descobrir esses erros.
• 2:14
  A segunda prática é usar IA como revisora de cenários antes de
• 2:18
  concluir uma suíte de testes. É muito comum a gente criar uma
• 2:21
  suíte de testes e esquecer cenários de bordas e de cases ou
• 2:24
  algo que ninguém conseguiria se lembrar do primeiro momento.
• 2:27
  É como eu tenho um colega senior fazendo perguntas o tempo todo
• 2:30
  até que o trabalho esteja concluído.
• 2:31
  O que eu faço na prática por informações da minha user
• 2:34
  stories e da suíte de testes que eu estou trabalhando?
• 2:37
  Peço aí a para que ela revise todo esse trabalho e.
• 2:40
  Identifique alguma falha de cenário perdido ou não.
• 2:44
  Normalmente eu não utilizo tudo que AIA me sugere, mas ela me
• 2:48
  ajuda a listar cenários na qual eu não pensaria a primeiro
• 2:52
  momento, como por exemplo, eu falei da ações de campus,
• 2:54
  concorrência ou rescondition, melhorando significativamente a
• 2:58
  minha cobertura de testes. A terceira prática é usada e a
• 3:01
  para acelerar o The Bug dos testes.
• 3:03
  Antes do fluxo era manual. O teste quebra, a gente pega o
• 3:07
  log do erro, leva até o Google. Ou ou algum fórum e torce para
• 3:12
  que alguém já o tenha resolvido? Hoje o fluxo é mais simples,
• 3:14
  depois que o teste quebra, a gente pega o log do erro, monta
• 3:17
  um prompt e vai guiando AIA até chegar na solução.
• 3:20
  Na maioria das vezes a gente consegue identificar Oo erro em
• 3:24
  cerca de alguns minutos, principalmente se for um erro
• 3:27
  simples, como um seletor errado ou um elemento que não existe
• 3:31
  mais. Um ciclo que antes demorava
• 3:32
  cerca de 30 minutos de the buggy, hoje com IA leva no
• 3:36
  máximo 5 a 10 minutos, mas antes de utilizar IA em tudo.
• 3:39
  Eu preciso te dar 3 alertas que aprende na prática.
• 3:42
  O primeiro e mais perigoso é confiar cegamente no código que
• 3:45
  aí a gera. O código parece lindo o teste
• 3:47
  espaço código compila. Tudo o ideal, porém, não testa
• 3:51
  nada que realmente agregue valor a sua suíte de de testes.
• 3:54
  A sessão está no lugar errado, o seletor às vezes busca o
• 3:57
  elemento que sequer existe, às vezes o teste está validando um
• 4:00
  setup ao invés de um comportamento real.
• 4:02
  E se você não ler do código, você nunca vai perceber esse
• 4:05
  erro, é você que vai julgar se está correto ou não.
• 4:07
  O segundo alerta é a alucinação, bem conhecida por quem usa AIA
• 4:10
  no dia a dia. É muito comum AIA utilizar o
• 4:13
  método de uma biblioteca que sequer existe.
• 4:15
  Ou, às vezes, de uma ferramenta que você não está utilizando.
• 4:18
  Por isso, é muito necessário que você entenda a ferramenta que
• 4:22
  você está utilizando. Leia a documentação oficial e
• 4:24
  esteja sempre atento às novas atualizações.
• 4:28
  Esse erro pode passar despercebido e custar aulas e
• 4:30
  horas de The Bug. A regra aqui é simples.
• 4:33
  Consulte sempre a documentação oficial da ferramenta ou
• 4:36
  biblioteca que você está utilizando.
• 4:38
  Se houver dúvidas no método que a IA gerou, leia novamente a
• 4:42
  documentação antes de concluir o trabalho.
• 4:44
  O último alerta, e não menos importante, é a dependência da
• 4:47
  IA. Utilizar IA como muleta pode ser
• 4:50
  prático e rápido. No início funciona bem, você
• 4:52
  ganha produtividade e ganha eficiência todo o caminho
• 4:55
  perfeitamente bem até o momento que a IA erra.
• 4:58
  Então, quando isso acontecer, se você não tiver um repertório
• 5:00
  técnico, do que a IA está gerando?
• 5:03
  Esse erro vai passar despercebido e, assim como no
• 5:05
  segundo alerta, vai te custar horas e horas de The Bug
• 5:08
  novamente. Então nunca esqueça, a IA é quem
• 5:11
  faz o trabalho mecânico e repetitivo.
• 5:13
  Você é o responsável por pensar e tomar as decisões.
• 5:16
  A IA amplifica o que você já sabe, ela não vai construir uma
• 5:19
  base técnica onde não existe. Espero que esse snip tenha sido
• 5:22
  útil. Um abraço e até o próximo.