Fundamental como Game Tester
Tive a ótima oportunidade de realizar nas ultimas semanas o curso Certified Tester – Foundation Level Syllabus da ISTQB (International Software Testing Qualifications Board) e foi uma das mais gratificantes experiências que já tive como tester profissional. O que me intriga é ter visto a importâncias destas bases de Game Tester somente depois de anos atuando na área, e ver também o como o teste é subjulgado.
Não me entendam mal. Não é que eu não tivesse a maioria destas bases antes, mas antes elas eram intuitivas, subjetivas, não documentadas, e o pior de tudo, acadêmicamente não estudadas.
Eu fui atrás dos cursos de desenvolvimento em games no Brasil para saber se algum abordava o teste como disciplina. Não foi surpresa ver que nenhum tinha em sua grade pelo menos uma matéria sobre o tema. Acho difícil acreditar que somente eu me incomode com este furo no ensino do processo de desenvolvimento de um game.
Tudo bem que o teste em si não é exatamente parte do desenvolvimento, mas é um erro achar que ele vem somente depois, uma fase posterior, um detalhe no final, quase um obrigação processual a ser seguida. Entender como testar um software é tão importante como saber seu desenvolvimento, achar que vale a pena testar somente quando o jogo está com todas as partes reunidas ou mesmo pronto é pular etapas e gastar recursos sem necessidade. O teste tem que vir do início: avaliar o plano de desenvolvimento do game (me desculpe os Game Designers), ler os códigos de programação (me desculpe os programadores), observar todos os gráficos de forma crítica (me desculpa os artistas) – temos que quebrar os egos. Como testers, nossa função não é julgar mas certamente indicar os erros em todas as fases do desenvolvimento. Afinal quando que é mais fácil concertar estes erros? No começo, quando as partes ainda estão separadas, ou no final, quando tudo tem que ser reconstruindo de novo?
Tudo o que é desenvolvido pode e deve ser testado.
Se você trabalha na área de QA (Quality Assurance), não vá pensando que está isento de culpa pelo pouca atenção dada na área, é obrigação do tester educar sua empresa. Pois o maior erro é achar que todo desenvolvedor é um tester, ninguém tem a capacidade de avaliar com precisão o próprio trabalho.
Quanto mais testes forem feitos, em mais fases possíveis, maior será a chance de achar um erro. E quanto melhor soubermos como fazer isso profissionalmente, melhor será a qualidade de nossos games.
Para aqueles que estão procurando uma melhor especialização, aconselho ferverosamente o curso da ISTQB – como eu já disse: “uma das mais gratificantes experiências que já tive como tester profissional”.
cateogories: Q.A.
Mongeff
August 31, 2010 at 11:53
É complicado essa área, principalmente aqui no Brasil onde querem mais programadores. Nesta área você deve se destacar muito e ser chato (no bom sentido) e mostrar para todos o quanto ela é importante.
Gilliard Lopes
August 31, 2010 at 12:58
Interessante o post, Marcos. Acho que vai dar bastante combustível para uma discussão legal sobre o papel do QA.
Sinceramente, acho a tua visão muito bem intencionada mas um pouco romântica, e confesso que tinha uma idéia parecida com a sua sobre o QA antes de ter contato mais direto com isso em projetos maiores.
No Brasil, trabalhei numa empresa onde o QA tinha poder demais. Eram eles quem DECIDIAM se um build estava pronto pra ir pra rua ou não, o que deveria ser o papel do produtor e do lead GD do game. É assim que funciona na indústria internacional.
Se depender do QA, TODOS os bugs têm que ser corrigidos, e isso simplesmente não é cost-effective em nenhum projeto. Bugs que precisam de uma sequência de ações muito específica para acontecerem, que apenas 0,0001% dos jogadores vão sequer ter chance de encontrar; outros que não atrapalham a experiência em si e que poucos sequer vão notar; ou, principalmente, bugs que dependem de ação destrutiva do usuário para acontecer, são todos candidatos a serem conscientemente lançados no jogo (shipped) e não consertados. Entra nessa decisão também o risco que cada conserto pode acarretar em quebrar outras partes do jogo, etc. Enfim, é uma decisão importante que tem que caber ao produtor ou lead GD, pois são eles que conhecem as features, o público-alvo e têm reponsabilidade em assumir esse risco.
Já aqui na EA, encontrei outro problema que vai de encontro aos teus pontos: é perigoso testar cedo demais. No processo criativo de um game, é primordial que se experimente e faça bastante protótipos de features. Esse processo não é restrito apenas à pré-produção, mas continua (em escala menor) até bem próximo do Alpha. Durante essas fases, não há muito o que agregar em testes de usuário final, pois as features claramente não estão acabadas. O que vejo acontecer é o QA apontando erros que todo mundo já sabe que existem, justamente porque aquela parte do jogo ainda não está pronta. Uma das coisas que ajudei a fazer aqui foi introduzir o conceito de "open for testing", que é uma indicação dos desenvolvedores de que uma determinada feature está pronta para um passe de QA. Isso ajudou muito a reduzir redundância no trabalho do QA durante a produção e evitar stress desnecessário aos programadores.
Não me entenda mal; não estou dizendo que o QA não pode ter um papel fundamental durante a produção. Mas pelo menos aqui fora esse papel é muito mais de conhecer as features novas que estão sendo planejadas, elaborar os casos de teste e planos de pós-produção, e apontar potenciais violações de certificação das plataformas (que são o conjunto de padrões e normas repassados pela Sony, MS e Nintendo que todos os games têm que obedecer, sob o risco de serem rejeitados).
Além disso tudo, acho que os pontos colocados no post assumem um prefil de funcionário de QA muito diferente do que se encontra na realidade. São poucos os testers aqui na EA que demonstram uma capacidade para contribuir e fazer sugestões de GD, arte ou programação. Os poucos que demonstram isso são rapidamente promovidos para um desses departamentos (o que é muito interessante e frequente – o QA como porta de entrada para um emprego melhor na indústria). O perfil dos testers por aqui é muito mais parecido com o do USUÁRIO do game do que com o de um desenvolvedor, o que na minha opinião é adequado. Não queremos que o QA examine o game com os olhos de quem desenvolve, mas sim com os de quem JOGA. Mas, ao mesmo tempo, acho pouco proveitoso que esses perfis de usuário dêem muito pitaco no desenvolvimento. Para cada "solução sugerida" boa que encontro na descrição dos bugs, existem outras cinquenta que são absurdas e não fazem sentido. Como norma, aqui na EA o QA aponta o problema claramente, mas não sugere soluções.
Enfim, tem bastante lenha nessa fogueira já. Afirmo novamente que sou super simpático às tuas idéias, mas esbarrei na realidade durante 12 anos pra chegar às minhas conclusões. Se um QA é bom o suficiente para contribuir decisivamente com o game design, por que não promovê-lo a GD?
Marcos Melim
August 31, 2010 at 13:42
Concordo que minha visão é um pouco romântica, mas cabe a mim como profissional idealizar meu trabalho para ao menos tentar chegar perto do considero ideal.
Quanto a decisão de aprovar ou não um game ou uma feature estar na mão no QA acho errada. Cabe ao profissional de QA, sim, apontar todos os bugs que ele encontrar e priorizar estes bugs de acordo um com uma escala estudada junto com a equipe de desenvolvedores, mas nunca um QA deve ter o poder de decidir se isso vai afetar ou não o lançamento do jogo.
Ao meu ver, o QA é um dedo-duro, um X-9, que tem como profissão apontar o erro. Quanto a concertar ou não.. é uma decisão fora de seu poder. E quando me refiro a testar o mais cedo possível, quero apenas garantir que o produto seja visto com o máximo de detalho possível, mas um bom Tester tem que ter a consciência se o que ele está testando esta pronto ou não. Também sou contra mostrar erros em algo que não está completo. Não faz sentido.
Sou do tipo que acho que sempre vamos encontrar bugs. Não existe produto 100%. Por isso o QA deve ser capaz, junto com um desenvolvedor de avaliar os riscos de um bug e decidir se ele vai ser concertado ou não.
Acho que a forma de ver um QA pode ser mais romântica. Trabalho aqui no Brasil, mas respondo para a Disney no Canadá, as diretrizes de um QAS aqui e na matriz são as mesmas. Concordo que a maioria dos Testers tem uma visão mais gamer, e os que se destacam, costumam migrar para outras áreas; mas realmente acredito na carreira dentro da área de QA. Um QA romantizado sim, capaz de ter uma boa visão em programação, arte ou GD.
Pode parecer meio incrível demais, mas dentro do que acredito como o ideal de QA, ainda temos um bom caminho na educação da indústria. Temos que evoluir.
Gilliard Lopes
August 31, 2010 at 14:29
Legal, no fim acabamos concordando.
Testar, quanto mais cedo melhor, não tenho dúvida. E muitas vezes pagamos por encontrar defeitos tarde demais e não podermos consertá-los a tempo, pois uma mudança mais profunda era necessária. Mas contanto que se saiba quando uma feature está inacabada, e se teste de acordo, como você mesmo disse.
Faltou eu comentar que o QA aqui é super importante pra focus testing dos nossos protótipos, onde eles não apontam bugs mas avaliam a diversão das features novas. Esse é um dos processos em que eu mais levo fé e acho até que deveria ser mais utilizado.
Henrique Arrais
September 2, 2010 at 11:09
Gostei muito do post e ainda mais dos comentários.
Concordo com vcs sobre a importância do QA, seja ele feito por técnico ou gamers, para medir diferentes/avaliar diferentes aspectos.
E gostaria de adicionar uma crítica ao que ando encontrando no mercado. Dificilmente vejo GPs envolvidos em conhecer o game no papel de gamer e tester. Acredito que este profissional é o mais capacitado para encontrar bugs mesmo quando uma feature está inacabada.
Tive a oportunidade de trabalhar com um GP que tinha conhecimento em todas as áreas da produção, GD, Art, Programação e conhecendo o projeto como ninguém ele era capaz de prever erros em fase de produção.
Estudo visando ser esse tipo de profissional, trabalho como GD, mais não perco a oportunidade de estudar programação, Design gráfico, além de trabalhar competências de liderança e comunicação.
A questão é … Aonde estão estes profissionais? Ou eu que estou esperando muito de um GP?
abss
Gilliard Lopes
September 2, 2010 at 11:17
Assumindo que, por GP, você se refere a Gerentes de Projeto, posso dizer que aqui na EA todos os gerentes são treinados extensivamente para atingir essa capacitação que você sugere. Foi uma das mais gratas surpresas que encontrei aqui: as pessoas que controlam orçamentos e prazos pelo menos entendem minimamente do que se trata desenvolver games, e isso os ajuda imensamente a serem mais efetivos.