Na nossa série Papo de Desenvolvedor, continuamos a apresentar a nossa equipe para vocês. Hoje, queremos compartilhar uma entrevista com o nosso departamento de Controle de Qualidade (QA). Sentamos para conversar com Kieren e Lionel (que já experienciaram o conteúdo da nossa nova expansão A Queda de Oriath dúzias de vezes) e perguntamos a eles sobre seus trabalhos no QA.

Olá! Obrigado pela entrevista! Por favor, se apresentem e nos digam um pouco da sua história com os jogos.

Kieren: Oi, meu nome é Kieren. Eu sou apaixonado por jogos e como eles funcionam desde criança. Eu cresci passando horas em lan houses (jogando CS 1.5, WC3, D2), depois jogando em grupos com amigos e depois administrando e ajudando vários servidores de jogos para pequenas comunidades - tudo que depois me levou ao meu cargo na GGG, onde eu comecei como Suporte e depois fui transferido para QA.

Lionel: Olá, eu sou o Lionel. Eu gosto de e-sports, basicamente a maior manifestação de pura habilidade em competições. Super Smash Bros Melee é o melhor jogo de todos. Recentemente, houve alguns speedrunners testando o Path of Exile e foi muito interessante ler a perspectiva deles. Eu não assisti tantos campeonatos nas últimas semanas, e foi bom ouvir pequenos detalhes que os tornam profissionais em Diablo II e sobre o amor deles por jogos, já que isso bate com os aspectos da minha relação com jogos e o que faz eu gostar deles mais ainda.

Você poderia nos dizer sobre o seu cargo atual na Grinding Gear Games e como é um dia comum de trabalho para você?

Kieren: O que eu mais gosto no QA é que você vê algo novo todos os dias. A primeira coisa que fazemos assim que chegamos é descobrir se algum patch é a prioridade principal. Se sim, o QA checa uma lista de conferências para cada funcionalidade, testa tudo de novo em um servidor local com o patch e informa aos outros caso haja algum problema e correções sejam necessárias antes do patch ser lançado.

Se não estivermos focando em um patch, então nós passamos por uma lista de tickets solucionados de bugs que foram trabalhados ou sistemas adicionados por outros membros da equipe - bem interessante já que podemos ver ou falar com eles sobre o que estiveram fazendo. Essas questões são conferidas no nosso servidor de testes principal e são reabertas ou fechadas dependendo se encontramos problemas ou se tivemos sugestões.

Também ficamos de olho em relatos de bugs e informações de crashes. Nós tentamos reproduzi-los e enviamos tickets com todas informações e passos de reprodução (e gifs/vídeos) para alguém que possa corrigir - se já não houver um ticket. Os mesmos passos são realizados se encontrarmos quaisquer outros bugs enquanto fazendo testes, e alguns de nós temos planilhas para acompanhar o progresso de grandes projetos/testes que envolvem muitos tickets.

Lionel: O que ele disse, exceto que a primeira coisa que fazemos é pegar uma Blue V na geladeira.

Kieren: A Coca de Baunilha é a que está lá agora, você tem que ser rápido antes que elas desapareçam pelo dia.

Por favor, nos digam sobre o QA na GGG. Quantas pessoas estão na sua equipe de QA?

Kieren: Atualmente, somos 9 pessoas na equipe. Nos damos muito bem e aprendemos uns com os outros. Já que estamos conferindo o trabalho de outras pessoas na companhia, nos manter informados e ajudar uns aos outros é muito importante.

Vocês testam manualmente ou usam softwares/ferramentas/bots específicos?

Lionel: Não há bots, mas temos ferramentas que podem ser uma mistura de scripts ahk criados pelo QA ou códigos implementados pelos programadores. Rian mencionou a adição de alguns durante sua entrevista e nos economizou centenas de horas de tarefas tediosas. O melhor é chamado de /dad, mas vou deixar a comunidade adivinhar o que ele faz. Testar jogando acontece, mas para a maioria das nossas tarefas isso não é a abordagem mais relevante/eficiente, e vista como um luxo que só pode acontecer quando as coisas estão acontecendo suavemente. O que geralmente não é a atmosfera nas semanas antes de um grande patch.

Kieren: Como Lionel disse, temos muitas ferramentas e scripts que fizemos, e também códigos que alguns dos nossos programadores criaram. Eles ajudam muito e certamente são essenciais para o que fazemos: para quando mudanças são feitas nas listas de itens, mods ou monstros; códigos para testar novas mecânicas de ligas; e para checar os personagens em diferentes estágios do jogo.

Uma grande coisa que aconteceu enquanto eu estive aqui foi poder colar linhas de comando dentro do cliente, e elas serem executadas em sequência - o que é ótimo para poder reproduzir bugs, informar os passos para outra pessoa olhar mais a fundo e depois testar o mesmo caso novamente para ver se foi corrigido. Por exemplo, você pode ter uma situação onde você cria um personagem com únicos e passivas específicas, precisa teleportar para uma certa área, teleportar para um monstro e depois usar habilidades específicas. Isso poderia se tornar 40 linhas de comandos, mas em vez de ir colando um de cada vez, podemos colar tudo de uma vez e ter um cenário pronto.

Você poderia descrever o processo de testes, por favor? Quantas vezes você testa o mesmo conteúdo? Você o testa durante todos os estágios de desenvolvimento ou apenas na versão final?

Lionel: Vamos usar uma luta de chefe como exemplo. Geralmente começamos com um protótipo incompleto. Coisas como modelos, animações, efeitos de magias e áudio estão em vários estados, mas podemos ver as habilidades em termos de comportamento geral e podemos pensar em cenários onde elas quebrariam. Frequentemente, há uma discussão contínua entre os programadores, designers e uma pequena parte do QA para determinar como as habilidades evoluem da ideia original que está em um documento, e como a implementação será um pouco diferente.

A quantidade de tempo que testamos o mesmo conteúdo depende de quanto quebrado ele está, e quão rapidamente os problemas são solucionados, assim como quanto tempo temos disponível. Um dos futuros chefes usa uma habilidade de raio, e para deixá-la pronta foi preciso dezenas de tickets já que sempre que um problema era solucionado, outro aparecia. Por outro lado, a tecnologia de criação de monstros das fendas funcionou desde o começo (menos os monstros ficando invisíveis na borda, o que foi algo que não tinha como arrumarmos), e mesmo tentando diversas maneiras para quebrá-la, aquele sistema sempre esteve certo. Eu espero não estar esquecendo nenhuma correção pequena, mas se eu estiver, tenho certeza de que a comunidade graciosamente nos lembrará.

Diferentes pessoas estão envolvidas em diferentes estágios, então dependendo para quem você perguntar, você receberá uma resposta diferente. É sempre interessante ouvir a perspectiva de outra pessoa em um ângulo diferente, já que isso pode trazer luz a um detalhe que não está certo.

Kieren: Também temos listas que devemos checar para cobrir tudo: microtransações, monstros, únicos e missões, apesar de tickets para sistemas que exigem mais trabalho geralmente serem divididos. Por exemplo, olharíamos as habilidades de monstros em tickets separados, o áudio em outro, depois é conferido quando estiver em uma área, e então é conferido novamente antes de ser implementado no servidor público. No último passo, os sistemas são frequentemente checados por várias pessoas do QA. São muitas conferências, mas devido à natureza do jogo e das mecânicas por trás de tudo, as mudanças feitas podem afetar situações específicas assim como podem afetar coisas que não são obviamente relacionadas.

Vocês podem influenciar o desenvolvimento do Path of Exile? Vocês já tiveram conflitos com designers ou programadores em relação ao balanceamento ou mecânicas?

Kieren: Ah sim, falamos para eles deixarem o jogo o mais fácil possível para tod- brincadeirinha... Discussões acontecem entre o QA e outros membros quando eles estão atrás de feedback ou ideias. Se houver algum conflito, eles tendem a considerar justamente entre todos envolvidos. E também há sempre sugestões sendo adicionadas por nós aos tickets, que são considerados e às vezes implementados, ou às vezes não.

Vocês jogam Path of Exile no tempo livre? Como vocês se mantêm interessados depois de jogar Path of Exile o dia inteiro no trabalho?

Lionel: Jogar Path of Exile o dia todo no trabalho é uma ideia errada. Pouco do nosso tempo no dia é usado para jogar o jogo igual aos jogadores. Eu piorei muito como jogador depois que comecei a trabalhar como QA. Meu principal interesse no jogo eram as corridas e, infelizmente, esse aspecto do jogo foi considerado não lucrativo o suficiente para receber qualquer atenção.

Apesar de eu não ter aquele desejo de jogar o jogo como eu tinha antes, eu estou ansioso pela expansão A Queda de Oriath e espero que mais consideração venha para o aspecto competitivo do jogo.

Kieren: Sim! Fazer parte e ver a criação de novos conteúdos tendem a tornar a experiência mais prazerosa (enquanto lembrando-se que você não está em um ambiente de testes). Embora você também fica ansioso pelo que está por vir, e sempre tem algo prestes a chegar.

Onde vocês geralmente encontram bugs? Vocês monitoram o fórum ou o Reddit, ou encontram os bugs sozinhos?

Lionel: Os bugs que encontramos no reddit ou no fórum são apenas a ponta do iceberg, não que eu queira diminuir a importância, quantidade ou aspectos de quebra de jogo deles. Eu estou do lado recebedor de conteúdos quebrados, então eu posso entender a frustração que os jogadores sentem, porém ler constantemente que a “GGG não tem QA” pode ser desencorajador. O Path of Exile é um jogo muito complexo com partes que interagem entre si em maneiras inesperadas, e é muito difícil pensar em todas interações possíveis.

Para uma expansão, geralmente temos metade do departamento presente no dia do lançamento, monitorando a seção de relatos de bugs, reddit e o chat global para rapidamente entender os bugs e enviar para os programadores. Kieren falou sobre esse processo na parte de “como é um dia comum”, mas o dia de lançamento pode ser mais frenético.

Kieren: Bem, encontramos e resolvemos bugs todos os dias com coisas que ainda estão sendo trabalhadas. Em questões de bugs no servidor público, depois de vasculhar todas as mensagens, repassamos tickets de quaisquer problemas que conseguimos reproduzir. Ter uma boa quantidade de detalhes sobre como podemos checar o problema nos ajuda muito, logo podemos atualizar rapidamente o tópico de Problemas Conhecidos fixado no fórum inglês de Relatar Bugs. Seguido disso, somos ocasionalmente pedidos para ajudar em reproduzir falhas comuns que são reportadas para nós, ou apenas para notar problemas ocasionais que acontecem enquanto jogando ou conferindo algo não relacionado.

Vocês poderiam nos dizer quais as qualificações necessárias para se tornar um testador QA na GGG?

Kieren: Gostar do jogo, um bom conhecimento dele e um bom olho para detalhes, e a capacidade de conseguir olhar para as coisas com diferentes perspectivas também ajuda na hora de dar feedback. Morar na mesma cidade é provavelmente uma necessidade, caso precise ir para o escritório.

Vocês lembram de bugs engraçados?

Lionel: Não. Bugs só são engraçados até eles arruinarem a experiência de jogo de alguém.

Kieren: Ah, muitos. Teve uma vez que os efeitos da investida com escudo persistiram quando você era empurrado no meio da investida:



Me lembro de outro quando o jogo não estava parecendo direito no meu computador (arma de teste elemental não relacionada):



A árvore de passivas ficou ótima:



E se você mexesse a roda do mouse um pouco, seu computador parecia estar morrendo:



Felizmente, esse bug foi corrigido antes de ir ao ar.