Recentemente, tive a chance de conversar com Alexei Nelyubov, diretor de QA da Datcroft Games. Agora, os caras estão trabalhando no MMO móvel Action Pixel Wars, o projeto está em fase de lançamento suave. O departamento de testes acompanhou o jogo em todas as etapas de seu desenvolvimento, e eu decidi que um bom artigo sobre o hub sairia da história de Alexey.
A seguir, fala direta.
Pixel Wars tem uma história longa e difícil. Guiados por objetivos de negócios, começamos a montar os primeiros protótipos do jogo em 2016. No futuro, o conceito foi completamente redesenhado, levando em consideração as mudanças das realidades do mercado, e “Pixels” entrou no jogo virtual no final de 2018. Num futuro próximo, está prevista uma liberação comercial do projeto.

Quem está na equipe?
O líder do departamento distribui tarefas, está presente em todas as reuniões, cria planos de teste, define prioridades para tarefas e também atua como analista de teste.
Em seguida, há três funcionários experientes que vigiam a qualidade do jogo há mais de um ano. Um deles recentemente participou de autotestes - ele cria scripts para casos em uma ferramenta auto-escrita.
Recentemente, um jovem e promissor especialista se juntou à nossa equipe (primeiro ele veio até nós para cursos de treinamento e depois fez um estágio - e agora está na equipe), que já resolve muitos problemas interessantes, desde a verificação de mapas até a escrita de scripts automatizados simples. E logo estamos esperando por outro.

Temos uma grande frota de dispositivos de teste, desde telefones antigos e antigos até dispositivos ultramodernos com o mais recente sistema operacional e funcionalidade. Às vezes, é interessante detectar um bug em apenas um tablet, porque ele possui um disco rígido especial e, em seguida, tentar recriar as condições apropriadas no estúdio de desenvolvimento.
Quais tarefas os especialistas em controle de qualidade resolvem?
Como você sabe, em modelos iterativos, o teste começa com a conclusão da formação de especificações técnicas e design de alto nível. Por isso, trabalha conosco. Lemos as especificações técnicas antes de começarem a implementá-lo, examinamos os layouts de novas interfaces, verificamos as caixas cinzas dos cartões, observamos os cálculos matemáticos nos documentos dos designers de jogos.
No momento da implementação, não esperamos até que todas as edições sejam carregadas no mestre, mas estamos testando ativamente partes individuais da funcionalidade em ramificações separadas. Eles podem não ter gráficos bonitos, um cone rosa pode ser executado em vez de um personagem e barris cinzas permanecerão no mapa em vez de árvores e arbustos. Mas já podemos verificar a funcionalidade.
Existem casos frequentes de teste de pares com um desenvolvedor em seu computador - economiza bastante tempo de montagem. Se um programador geralmente procura apenas a funcionalidade que ele criou ou corrigiu, e apenas casos positivos, o testador pode encontrar imediatamente erros em casos negativos, além da experiência, saber o que exatamente esse programador neste módulo pode quebrar. A análise de influência também ajuda: por exemplo, sempre que um código de guilda governa, algo acontece com a funcionalidade dos amigos. Por que não verificar esse momento imediatamente?

Quando todas as partes individuais de código, gráficos, efeitos, sons e localização são mescladas no mestre, chega a hora de integrar e testar o sistema. Examinamos como os novos recursos funcionam uns com os outros e realizamos testes em massa com toda a equipe. Frequentemente, erros como "Estou desconfortável" ou "Não sinto interesse" aparecem aqui, que também são registrados e processados. Observamos não apenas as características funcionais, mas também o comportamento do jogo sob carga pesada, Internet "ruim" e em vários ambientes não ideais, como viajar de ônibus pela cidade ou porão do centro de negócios.
Como a versão é aceita?
E agora, todos os erros óbvios foram corrigidos, todas as coisas novas estão prontas para ver a luz. Posso fazer upload para o prod? Claro que não. Precisa da opinião de representantes de todos os departamentos e de alguns jogadores reais. Ao mesmo tempo, a regressão começa (o tempo dos grandes autotestes) e o teste de aceitação. Se tudo estiver claro com o primeiro (verificamos todas as funcionalidades do jogo, adicionamos casos desatualizados, adicionamos novos, verificamos também), então poucas pessoas falam sobre aceitação. Mas a coisa é útil. Enviamos a construção para o canal geral do projeto e pedimos a todos que joguem e avaliem o jogo "de sua torre sineira" por alguns dias. Pode acontecer que os designers de jogos não representem a característica do poço com riscos, embora tudo tenha sido feito de acordo com a descrição e os layouts, e o marketing seja necessário outra pele do personagem guerreiro para a ação na rede social.Quando todos os desejos são levados em conta, vamos ao produtor, a pessoa principal do projeto, ele dá a aprovação e, em seguida, inicia o processo de upload da versão para o prod. a ação leva meia hora para cerca de uma hora.
Quando tudo estiver pronto, não removemos imediatamente o prato do trabalho profissional. Primeiro, você precisa ter certeza de que as classificações são sorteadas, os pagamentos passam, os jogos são lançados e os novos recursos chegam aos jogadores.
Em seguida, o processo começa de novo.

Mais alguns fatos
Freqüentemente, para testar um jogo, ele não precisa ser lançado. Existe uma mecânica existente na qual alguns parâmetros foram alterados. Ótimo, faça o download do novo repositório, veja o arquivo xml correspondente e feche a tarefa. Às vezes, os erros não querem ser repetidos. Por exemplo, um dos parceiros tocou em nosso projeto no metrô, nesse momento o telefone tocou e a Internet da 3G mudou para o wifi sem acesso à rede global. Ao mesmo tempo, o dispositivo ficou sem espaço e a bateria superaqueceu. Mas não temos bugs irreproduzíveis, existem aqueles aos quais as mãos ainda não chegaram.
Obviamente, acontece que os erros aparecem no prod. E se os usuários encontraram um, provavelmente também o encontramos. Ele tem baixa prioridade ou reprodutibilidade, portanto a correção foi adiada por dois meses.
É raro, mas acontece para provar a um programador ou PM que um bug é um bug e precisa ser corrigido agora. Por exemplo, nas cartas, você pode entrar na zona segura do inimigo. Sim, você não pode atacar lá, mas esta é uma ótima maneira de restaurar a saúde e emboscar o inimigo. Ele provou - eles estão consertando. Não - procure argumentos mais convincentes. Argumentos no estilo de “legal” ou “não gosto” não são aceitos, são necessários exemplos concretos com consequências concretas.
Às vezes, tínhamos que testar desconexões, indo até a varanda do escritório, até que houvesse uma configuração "ruim" da Internet no roteador.
Para simular uma rede completa e testar o aplicativo nessas condições, o testador caminha especificamente por um shopping lotado com um telefone.
Muitos erros são detectados quando você faz uma desconexão e troca rapidamente de algo. Aqui a velocidade das fitas na tela é realmente importante. Por exemplo, eles encontraram um erro completamente óbvio: quando você troca rapidamente de classe e aparência de personagem, no final, seu arqueiro segura um escudo ou guerreiro com uma varinha mágica.
Obrigado pela atenção! Espero que você esteja interessado em aprender mais sobre o processo de teste de jogos.