Home

Автор: Мэтью Бреттен (Matthew Bretten)

Оригинал статьи: http://bestofthetest.blogspot.ru/2016/08/games-testers-should-be-proud-of-their.html

Перевод: Ольга Алифанова

Несколько месяцев назад я собеседовал кандидата на должность тестировщика и спросил про его имеющийся опыт. Ответ кандидата прозвучал в духе "ну, это, конечно, ни о чем, но я участвовал в бета-тестировании видеоигр". Неделей позже я наткнулся на дискуссию в Slack-чате Ministry of Testing, где народ обсуждал, кто как попал в тестирование. Несколько человек упомянули, что считают очень полезным начинать с тестирования игр, но, по их мнению, тестировщиков игр зачастую презирают. Это побудило меня подключиться к обсуждению и поделиться своей историей, потому что я обожаю игры! На самом деле именно эта страсть определила мою карьеру после университета.

Пицца, кола и печеньки

Я никогда не забуду эту фразу. Тогда я только что окончил институт и рассылал резюме на все позиции программиста, которые только мог найти. Это была безумная неделя (такое со мной случается каждые два-три года): я назначил три собеседования, причем прямо перед свадьбой одного из моих братьев. Два из них были на позицию программиста, а одно – на тестировщика игр.

Первое собеседование я не прошел, на втором мне удалось поразить интервьюера и получить оффер на должность тестировщика игр, а вот третье… Ну, учитывая, что я хотел работать программистом, чтобы использовать весь спектр навыков, полученных в институте, я отправился на третье собеседование, радуясь офферу от игр, но все-таки мечтая стать разработчиком. Однако интервью прошло примерно так:

- Итак, из вашего резюме мы поняли, что вы интересуетесь работой в играх?

- Именно так, но я готов учиться и учиться на любой позиции программиста, которую смогу найти!

- Пицца, кола и печеньки.

- Эм, что, простите?

- Ну это то, что вы, геймеры, любите, не так ли?

- Эээ…

- Мы недавно наняли программиста из геймдев-компании, которая находится тут неподалеку, как там ее бишь?...

- Traveller's Tales?

- Да, именно она, но не сложилось. Отличный программист, но он не подходил нашей организации.

Нужно ли говорить, что это было самое странное, агрессивное и стрессовое собеседование, на котором я когда-либо присутствовал. Я искренне не понимаю, зачем они вообще решили потратить мое и свое время на подобное собеседование. Однако благодаря ему я внезапно почувствовал, что буду очень рад принять предложение о работе в играх, и перестал сомневаться! В итоге моя карьера тестировщика стартовала с выражения презрения к "геймерам".

Учиться тестировать

Итак, я вышел на работу, имея крайне смутные представления о тестировании (удивительное рядом – можно получить диплом программиста, ни разу не услышав выражения "юнит-тест"). Я всегда любил игры, и натыкался на приличное количество багов в них, поэтому неплохо представлял себе, как выглядит "хорошая" игра, и чем она отличается от "плохой". Я также играл в кучу различных игр на разных уровнях сложности, поэтому обладал солидным запасом знаний – и это не говоря уже о моей степени в области гейм-дизайна и программирования. Я понимал, чего люди хотят от игр, как игры делаются, и что в них может пойти не так. Ранее я никогда полноценно не работал, но был убежден, что справлюсь.

Я узнал очень много о том, как тестируются игры – особенно о различных вариациях "багов" и "проблем" в них. Баги не ограничивались очевидными вещами, которые люди могут легко распознать, вроде крашей, зависаний и замираний (да, между ними есть техническая разница), а также графических недостатков – в играх также есть проблемы, которые необязательно можно определить на глаз. Большая часть тестирования проводилась исследовательским методом, обычно с задачей сконцентрироваться на определенной области – например, тестировании коллизий или прохождении игры с целью убедиться, что ее вообще можно пройти.

Вот некоторые примеры проблем, поиском которых мы занимались:

• Графика. Наиболее очевидные, визуальные типы багов, влияющие на внешний вид и ощущения от игры.
• Функциональность. Проще говоря, баги, относящиеся к тому, что игра должна "делать". Это сильно зависит от контекста, так как все игры разные, но есть и типичные вещи вроде возможности рулить машиной в гоночной игре.
• Сложность. Довольно субъективная штука – нам нужно было определить, была ли "низкая" сложность равномерной и не начинала ли она внезапно увеличиваться на определенных уровнях.
• Звук. Соответствует ли озвучка анимации персонажей, достаточно качественный ли наш звук (к примеру, не попали ли в игру звуки начала и конца записи голосов).
• Юридические проблемы. Игры могут включать в себя материал, защищенный авторским правом, и это должно быть указано в титрах. В игру также могли случайно попасть вещи, похожие на реальные продукты.
• Здоровье. Мы много знали о светочувствительности и том, как определить баги, провоцирующие эпилептические приступы.
• Технология. Иногда мы искали баги определенных технологий – например, 3D, контроль движений, устройства обратной связи, дополненная реальность, шлемы виртуальной реальности. Все эти технологии страдают от специфичных для них багов и проблем.
• Соответствие. Мы убеждались, что игры соответствуют корпоративным стандартам. Несоответствующие игры не выпускались, поэтому убедиться, что стандарт соблюден, было очень важным.
• Локализация. Мы не переводили игры и физически не могли читать что угодно на всех возможных языках, но мы искали баги, связанные с мелкими различиями локализации. Невинное отсутствие языкового файла могло привести к невозможности играть или крашам. Ну и для того, чтобы увидеть, что текст не влезает в отведенную область, не надо знать немецкий.
• Мультиплеер/Производительность. Мы тестировали нагрузку, стресс, и потенциал для эксплойтов. Некоторые игры должны быть способны выдерживать большое количество игроков, а эксплойты могут помешать людям получать удовольствие от онлайн-игры.
• Совместимость. В некоторых случаях игры портировались на новое железо или разрабатывались с учетом более пожилых систем. Мы искали проблемы совместимости игр с их окружением.
• Транзакции. Мы проверяли, что платежи реальными деньгами могут быть совершены, и что эти системы нельзя обмануть.

Возможно, я что-то позабыл, но надеюсь, что теперь у вас есть представление о спектре проблем, поиском которых мы занимались!

Помимо изучения возможных проблем, я также многое узнал о техниках и стратегиях тестирования. К сожалению, компания, где я работал, сильно полагалась на тест-кейсы. Взгляды на это различались, и я обнаружил, что нахожу больше проблем, тестируя исследовательским методом, нежели когда выполняю скучные и однообразные кейсы. Мы также начали внедрять автоматизацию, чтобы проводить нагрузочные и стрессовые тесты в многопользовательских играх, а также ускорить регресс.

Вот два самых важных урока о тестировании, полученных мной на этой работе:

1. Я ненавидел тест-кейсы и считал их бессмысленными. Иногда они приносили какую-то пользу, давая пищу для новых идей или направляя меня на пути исследования продукта, но их было трудно писать и использовать, и в целом они были просто тратой времени. Большую часть багов я нашел, тестируя исследовательским методом.

2. Автоматизация продукта, который постоянно менялся, была тратой времени. К моменту, когда мы завершали создание автотестов, продукт уже успевал измениться, и тесты приходилось переписывать. Большая часть наших продуктов не требовала тестирования после релиза, поэтому нам было сложно определить ценность автотестов. Они помогали нам только при проведении крупномасштабных тестов производительности.

Я научился тому, что можно применять и в других областях

На моей первой работе я научился ряду вещей, о которых не думал сознательно – или же у меня не было подходящего словаря, чтобы успешно их описывать – но которые были очень важны для моего формирования как хорошего тестировщика. Когда я стал лучше понимать тестирование и расширил свой лексикон, я смог их определить:

• Управление отношениями с разработчиками. Я быстро понял, что дипломатический подход очень важен для сообщения разработчику о проблеме. Вот аналогия, которую я позже использовал на собеседованиях – представьте, что художник создал блестящую работу, а вы подходите к ней и говорите – "Гляди-ка, тут упущен кусочек!". Понятно, что это раздражает автора, поэтому сделайте все, что от вас зависит, чтобы смягчить этот удар.
• Цена автоматизации. В то время я не мог это внятно описать, но я узнало скрытых издержках автоматизации и о соблазне найти дополнительные способы использовать ее. Я уже понимал, что такое "приносить ценность", и как легко люди впадают в недопонимание, что автоматизация не может заменить все тестирование вообще.
• Понимание, когда остановиться. Я получил опыт, помогающий мне понять, когда и почему мне надо остановить тестирование. На моем первом месте работы мы всегда были ограничены по времени, и я быстро осознал необходимость баланса между потраченным временем и пользой от этого, а также необходимость фокусироваться на наиболее рисковых областях.
• Понимание, когда нужно повторить тесты. Я также начал формировать свой собственный подход к регрессионному тестированию, хотя в то время и не осознавал, как еще к нему можно подойти, кроме как перепройти тест-кейсы.
• Обоснование тестирования. Я накопил опыт и научился уверенно отстаивать свое тестирование и писать эффективные баг-репорты. Я не всегда мог внятно объяснить, о чем речь, но, как минимум, был достаточно мотивирован улучшать свои коммуникационные навыки!
• Желание понимать о продукте как можно больше как можно раньше. На моей первой работе у нас не было хорошей документации, на которую можно было бы опереться (а иногда не было никакой). При наличии документации дать обратную связь по продукту можно было намного быстрее и проще. На своих последующих позициях я старался подключиться к продукту как можно раньше, чтобы как можно быстрее разобраться в нем. Я знал, что документация – это довольно дорогостоящее занятие, и понимал, что ранний доступ к источникам информации жизненно важен для того, чтобы я смог приступить к тестированию.
• Креативное мышление. Я быстро выяснил, что лучшие баги – это те, про которые ты никогда бы и не подумал. Иногда чинить их – довольно дорогое удовольствие, и поэтому очень важно уметь находить их как можно раньше.
• Самоорганизация, скорость и ясность. Я гордился тем, что мой труд был не только высокоорганизованным, но еще и быстрым и эффективным. Я быстро понял необходимость шустро налаживать свои тесты и максимизировать доступное для тестирования время. Я пользовался своими собственными техниками, чтобы этого добиться, и писал внятные и ясные отчеты, которые до сих пор служат мне верой и правдой.
• Умение адаптироваться и желание учиться. Мой бэкграунд программиста помог мне быстро вникать в технические детали сложных продуктов, и это очень помогало. Повторюсь, высвобождение максимально возможного времени на тестирование позволяло мне давать быструю и четкую обратную связь. Затем я искал способы освоить новые навыки, которые помогут мне в тестировании.
• Понимание и поддержка конечного пользователя. Если вы работаете в играх, то вы, скорее всего, много играете сами и имеете представление о том, что именно делают ваши пользователи, чего они хотят, что им нравится. Поэтому размышлять, как пользователь, вам должно быть проще. Это очень ценно при поиске новых идей для тестов, отстаивании своего тестирования и обоснования багов. Этот опыт мотивирует меня пытаться понимать больше о психологии конечных пользователей.

Заключение

Я тестировал игры три года в двух разных компаниях, и я считаю это позитивным опытом. Нет, все не всегда было гладко – индустрия разработки игр все еще страдает от ряда специфических проблем. Я перешел в другую отрасль отчасти потому, что тестирование в играх рассматривают, как конечную стадию разработки, и потому, что мне хотелось строить свою карьеру дальше. Я остался профессиональным тестировщиком во многом благодаря опыту, полученному именно в играх. Если вы тестируете игры и думаете, что вы непрофессиональны, и вам нужно доказывать, что вы все-таки настоящий тестировщик – забудьте об этом! Вы уже профессионал!

Обсудить в форуме