Привет!
Сегодня я расскажу о создании отдела тестирования на примере небольшой компании, которая уже 3 года выпускает мобильные игры. Особенность в том, что компания не зависит от спонсоров и живёт за счёт денег, которые зарабатывает. И нам, как сотрудникам, важно делать то, что, на наш взгляд, будет нравиться пользователям. Есть возможность экспериментировать и работать на аудиторию, но, при этом, куда меньше времени на разработку продукта.
Необходимость в QA отделе появилась год назад и процесс тестирования мне необходимо было выстроить, не ломая при этом график релизов.
Тестирование в мобильном геймдеве: что такое и в чём проблема
QA в мобильной разработке выступает чем-то вроде секретной службы. Пока работает хорошо, никто не замечает, что тестирование проводится. Но стоит Акелле хотя бы раз промахнуться и комментарии к игре пестрят сообщениями разной степени разгневанности. В сущности, задача мобильного тестировщика — проследить за тем, чтобы в приложении был минимум заметных багов, а команды разработки чётко представляли себе смысл каждого релиза и работали на достижение результата.
Тестирование — фактор, который помогает улучшать продукт, но, при неграмотном использовании он будет ещё и нагрузочным элементом в системе, сильно задерживающим релиз. В нашей компании, на тестирование игры закладываются 2 рабочих дня: первый день — продукт тестируется и дорабатывается; второй день — игра проходит последние проверки и отправляется на маркет.
Процесс тестирования сталкивается со следующими проблемами:
- Нет автоматизации тестирования
- Разный подход к полному тестированию и тестирование фичи
- Зависимость от других отделов. Провал сроков от других сотрудников сказывается на загруженности. Недели перегруженные релизами чередуются с неделями, когда релизов нет вовсе
- Необходимость научиться находить недоработки геймдизайна или UI. Существуют ситуации, когда этап тестирования помогает отказаться от бесперспективной игры.
Процесс и результат. Как всё поменять, но ничего не сломать
До моего прихода в компанию тестирование осуществлялось внутри команд. Теперь это отдельный этап, на который нужно закладывать время. Какое-то время всё делалось по принципу “кто раньше сдал, того и тестят”. Переносить релизы не хотелось, ведь не было понимания важности каждого из них. Минусы такого формата в частых переработках в конце недели и недостатке занятости в начале неё.
Первым инструментом, который должен был сделать процесс равномерным, стал временной регламент, расписывающий даты тестирования. Сделано это было для того, чтобы загруженность стала равномерной. По плану, все релизы, которые не успели выйти перед выходными, должны были создать занятость на начало следующей недели. Ограничение работало, но иногда сбивался приоритет и случались ситуации, когда игры, которые могли подождать, выходили раньше более важных релизов.
Нужна была визуализация процесса и всех задач, которые поступают в тест. Мы завели канбан доску в Jira. Тем, кто не понимает что это такое, советую прочитать книгу Дэвида Андерса “Канбан. Альтернативный путь в Agile”.
Раз в неделю, по понедельникам, мы встречались с гемдизайнерами на коротком митинге, по результатам которого на неделю расставлялись планы и приоритеты. Проекты, приходящие помимо основного плана обсуждались отдельно и автоматически уходили на следующую неделю, либо попадали в тест только тогда, когда в моём графике появлялось “окно”.
Загруженность стала понятнее и прозрачнее, но, увы, не стала равномернее. Канбан показал не только проблемы тестирования, но и общие проблемы в общении как отделов, так и отдельных специалистов. Плюс, появился новый повод для беспокойства: стало забываться, насколько важно ещё и разговаривать с коллегами. Складывались ситуации, при которых каждый выполнял свою работу хорошо, но без оглядки на других. Как итог, один из проектов находящихся на поддержке и требующий срочного обновления из-за того, что кончался период аналитики, был просрочен на 3 дня. Само собой это денежные убытки и упущенная информация.
Один из главных уроков, вынесенных из той ситуации, я формулирую для себя как:
“Не требуй жёсткого выполнения гибких элементов процесса. Непонятно - спроси. Напомни, если нужно. Сначала польза и результат, а потом уже всё остальное”.
Помимо взаимодействия, нам осталось наладить распределение занятости. Решение оказалось проще, чем виделось изначально — мы добавили митинг на вечер среды. В итоге, в понедельник мы раскидываем приоритеты на неделю, а в среду обсуждаем график релизов на пятницу. Теперь уже в середине недели все с почти стопроцентной уверенностью знают что выйдет, что не выйдет и все могут уйти домой вовремя. Команды конкретнее ставят внутренние сроки сдачи работы.
Гораздо проще собрать один незапланированный митинг и потратить 15 минут, чем потратить 3 дня на попытки соблюсти процесс, который, в итоге, просто не все правильно интерпретировали. Результат получается только в случае, если все сотрудники отдают себе отчёт в том, что мало сделать свою работу хорошо. Всегда думайте для чего эта работа делается и помогайте остальным делать тоже самое.
В ближайших планах ввести обновлённую систему тестирования, основанную на “самостоятельном тестировании при факапе”. Смысл в том, что команды смогут релизнуть свою игру в обход отдела QA, если докажут необходимость этого. То есть будут чётко понимать, что релиз необходим, но, в силу просрочки, не попадает в основную сетку тестирования. Под свою, разумеется, ответственность. Есть гипотеза, что в таком случае мы сможем снизить нагрузку на отдел и повысить общую трудовую дисциплину, поскольку команды будут более трезво оценивать свои силы, поскольку делать дополнительную работу из-за собственной просрочки — не самый желанный кейс.
Финальное напутствие
Для создания результативного отдела нужно, помимо классического тестирования, заниматься ещё и тем, что с полным правом называется “контролем качества”. Следить, чтобы игры выходили не просто так, а с конкретной целью. Изучать потребности аудитории и бизнеса также не будет лишним в условиях современного, динамического рынка.
Отсутствие автоматизации даёт как ограничения, так и возможности. С одной стороны, нужно гораздо больше элементарных вещей проверять самостоятельно. Но, с другой, остаётся гораздо больше времени для изучения дополнительных сторон бизнеса. И есть масса инструментов, позволяющих эффективнее заниматься тестированием. Одни только “эвристики” или правильно составленные “чек-листы” заслуживают отдельной статьи. Но об этом нужно разговаривать отдельно.
При выстраивании отдела и его процессов важно и нужно помнить и понимать 2 вещи:
как выстроить рабочий процесс так, чтобы он не ущемлял интересы других сотрудников;
как правильно реагировать на нарушение процессов. Цель и результат — намного важнее, чем их строгое соблюдение.
Автор: Garvi
