Тимофеева

1. Немного о нашей студии и проектах.
2. Существовавшие процессы.
3. Предпосылки для изменений.
4. Основные изменения, и зачем они нужны.
5. Выводы.
Что будет в презентации

О студии и проектах

Alawar Stargaze
15 лет;
более 60 игр;
casual игры в жанрах HOG и TM;
4 midcore проекта в жанрах Action Adventure, Survival, Quest Adventure (Goliath, Beholder, Distrust, Beholder 2);
игры для ПК, мобильных устройств и консолей.

Casual, 2012 год
Snark Busters 3
Twisted Lands 3

Midcore, 2016-2018 годы
Beholder
Beholder 2

Существовавшие процессы

Организация передачи проектов в QA
Porting team
Development team
QA team
Casual 1
Casual N
Casual 2
Casual 1
Тестирование итерациями
«Непрерывное» тестирование

1. Общее понимание важности тестирования.
2. Качественное оформление отчетов о тестировании.
3. Тестирование проектов от старта до релиза.
4. Высокое качество проектов.
5. В тестировании во многом помогали:
- интуиция;
- простота проектов;
- возможность тестировать всем всё.
Другие входные данные

Предпосылки для изменений

1. Переход от разработки casual проектов к midcore. 2015 год.
2. Создание оригинальных проектов.
3. Усложнение геймплея.
4. Более сложные и глубокие сюжеты.
5. Привлечение новой аудитории.
6. Формирование комьюнити игроков.
7. На базе Alawar Stargaze сформирован слот Warm Lamp Games.
Изменение стратегии компании

Casual
Midcore
Есть опыт?
Да
Нет
Инструменты разработки
Известные
Новые
Игровые механики
Понятные
Новые
Геймплейные апдейты
Не делаем
DLC и фидбек пользователей
Бета-тесты
Не нужны
Планируются
Комьюнити + поддержка
Не касается команды
Часть работы над проектом
Состав команды QA
3 человека
3 человека

Изменение процессов,
и зачем они нужны

1. Этап подключения QA. Casual
Обсуждение
Реализация
QA
Задание
Идея

1. Этап подключения QA. Midcore
Обсуждение
Реализация
QA
Задание
Идея
QA

чем раньше тестировщик подключается к проекту, тем больше он знает о нем;
тестировать можно начинать до того, как появится реализация;
для получения фидбека;
обычно стоимость исправления бага тем больше, чем дольше баг живет в проекте.
Зачем это нужно?

2. Ежедневная планерка. Casual
Художники и аниматоры
ГД
Программисты
Руководитель проекта

2. Ежедневная планерка. Midcore
QA
Художники и аниматоры
ГД
Программисты
Руководитель проекта

- уточнение задач и их важности;
- все члены команды в курсе задач каждого;
- выявляются недопонимания;
- складывается общая картина состояния проекта;
- неотложные вопросы находят решение.
Зачем это нужно?

3. Документация в работе QA. Casual
Команда разработки
Отчет о тестировании
QA
“Живой” проект
ГД документация
Внешняя документация

3. Документация в работе QA. Midcore
Команда разработки
Отчет о тестировании
QA
“Живой” проект
Внутренняя документация
ТЗ после реализации
Внешняя документация

Основная документация. Casual
Требования от издателей
Требования к платформам
Документация по проектам
Windows
MacOS
Android
iOS
XBOX
PS
Внешние документы
Win. phone
ГД документы

Основная документация. Midcore
Требования от издателей
Требования к платформам
Документация по проектам
Windows
MacOS
Linux
Android
iOS
XBOX
PS
Nintendo
Чек-листы
Схемы, карты
Регламенты
Особенности
Внешние документы
Внутренние документы
Тест планы
Ссылки

- покрытие проекта тестами (в зависимости от жанра, платформы, издателя, локализации, особенностей самого проекта);
- анализ рисков;
- оценка затрат времени на тестирование;
- сокращение времени тестирования;
- регрессионное тестирования;
- введение новых QA специалистов на проект;
- ротация QA специалистов;
- накопление знаний и опыта в отделе QA;
- разделение задач между тестировщиками.
Что дает ведение документации?

Тот, кто:
- понимает, как сделать удобно для всех;
- умеет декомпозировать;
- пишет последовательно;
- умеет выделять важное;
- не пишет ненужного;
- любит работать с документацией.
Кто должен составлять документацию?

- весь отдел QA;
- команда разработки (GD, программисты);
- локализаторы;
- специалисты поддержки пользователей.
Кто пользуется документацией?
Все специалисты QA, которые работают с проектом.
Кто ее обновляет?

4. Жизненный цикл задачи. Casual
Open, Unassign
Команда разработки
QA
Verification, QA assign
Сlosed

4. Жизненный цикл задачи. Midcore
Open, Unassign
Verification, QA lead assign
Команда разработки
QA
Verification, QA assign
Сlosed
Resolved
Комментарии, номер ревизии
Обновление документации
Номер ревизии

Зачем так сложно?
1. Комментарий разработчика позволяет понять:
- в какой версии сделано изменение;
- как именно изменилась механика/сюжет и пр.;
- какие могут возникнуть проблемы.
2. QA lead распределяет задачи по:
- приоритету;
- знанию проекта;
- сложности.
3. Перевод в статус Resolved позволяет QA lead’у:
- быть в курсе изменений;
- убедиться, что все необходимые изменения внесены в документацию.
Теперь вся информация доступна для любого члена команды!

5. Планирование тестирования. Casual
Стратегия тестирования
Оценка трудозатрат
Прогнозирование сроков
Тестируем всё, что есть
Тестируют все
Всё время до релиза

5. Планирование тестирования. Midcore
Стратегия тестирования
Оценка трудозатрат
Прогнозирование сроков
Контроль выполнения задач
Оценка рисков
Что и как будет тестироваться
Кто и когда будет тестировать
Сколько нужно времени
Сколько нужно времени, если что-то случится
Гибкая корректировка планов в зависимости от ситуации

Выводы

Изменение процессов позволило:
1. Сохранять качество проектов, несмотря на:
- рост их сложности;
- небольшое увеличение штата при большом увеличении количества версий.
2. Давать четкое представление о состоянии проекта и рисках.
3. Сохранять и использовать полученный опыт.
4. Обучать новых сотрудников в короткие сроки.
5. Быть частью команды разработки и влиять на качество проектов с ранних этапов.

А что сейчас?

Организация передачи проектов в QA
Porting team
Development team
QA team
Casual 1
Casual N
Casual 2
Casual 1
Тестирование итерациями
«Непрерывное» тестирование
2012 г.

Организация передачи проектов в QA
Porting team
Warm Lamp Games
QA team
Midcore 1
Midcore N
Midcore 2
Midcore 1
Тестирование итерациями
«Непрерывное» тестирование
Blindfold
Midcore 2
2019 г.