QA & QC: ЦЕНА ЭКОНОМИИ | LONGREAD
1. Скепсис в компаниях.
В малых компаниях, командах и стартапах у различных CEO, разработчиков, менеджеров и прочих специалистов небезосновательно появился скепсис в необходимости QA/QC тестировщика из-за следующих причин:
- пользователи сами находят все баги;
- разработчик сам проверяет свою работу;
- напряжение из-за плохого менеджмента;
- CEO тратит лишние деньги на QA/QC тестера.
2. Начнем с базы.
QA (Quality Assurance, «обеспечение / гарантия качества») - звучит гордо, но не совсем правильно отражает его реальность, иначе многие проекты были бы очень качественными. Обеспечивать или гарантировать качество тестировщик не может, так как он не имеет контроля или управления над кодом, он лишь повышает вероятность успеха.
важно: QA (процессы) и QC (поиск багов) часто смешивают и путают, поэтому мы поставим равно между ними и будет просто «тестировщик».
Более того, сам тестировщик - это первый пользователь продукта, который невольно подливает масло в огонь репортами: менеджмент дополнительно давит на разработчика.
Ответственность тестировщика:
«Уведомлять команду, если задуманная реализация не соответствует фактической». - © MagicH
2.1. Зона ответственности.
Когда какая-то функция, механика или запрос воспроизводится некорректно, то задача тестировщика - уведомить разработчика, который исправит это до релиза.
ПРИМЕР: «Баг-репорт №1 [IT & High | Магич] - механика подбора предметов не работает после перехода на вторую локацию».
2.2. Пользователи сами находят все баги.
После релиза пользователи отправляют жалобы на (те же или новые) баги, недочеты и ошибки обвиняя разработчиков. После чего начинается дополнительный этап «фиксов», который бьет по финансам и времени. Учитывая тот факт, что разработчики и тестировщики обычно знают о 85-95% найденных багов.
2.3. Разработчик сам проверяет свою работу.
Когда разработчик пишет свой код он проверяет соответственно так, как задумывал ее. После проходит код ревью лида, который подтверждает или отправляет на переработку.
2.4. Напряжение из-за плохого менеджмента.
Когда в проекте тестировщики уведомляют о новых репортах, то в первую очередь на этом акцентируется менеджмент, который дополнительно давит на отдел разработки, что повышает градус между специалистами по формуле:
Тестировщик & Менеджер <-> Разработчик.
2.5. CEO тратит лишние деньги на тестировщика.
Совокупность причин наблюдаемым CEO подталкивает его к тому, что тестировщик и вовсе не нужен.
А зачем? Баги найдут пользователи, разработчики друг друга подстраховывают, менеджменту приоритеты ведь виднее…
После CEO наблюдает следующую картину в виде множества багов:
Первый продукт с багами - случайность;
Второй продукт с багами - совпадение;
Третий продукт с багами - закономерность.
А страдают абсолютно все.
3. Причины закономерности.
Почему вне зависимости наличия тестировщика итоговый продукт все равно выходит некачественный? Все из-за следующих причин:
- отсутствии тестировщика;
- неправильного пайплайна;
- строгого регламента по дате релиза.
3.1. Отсутствие тестировщика.
Тестировщик это специалист, который проводит первый обкат продукта или его частей, где его отсутствие очень сильно понижает шансы на качественный продукт, так как разработчики проверяют свои фичи по той логике, по которой ее программировали. Тестировщик будет тыкать приложение, сайт, программу или игру так, как оно изначально не задумывалось. Поэтому в релизном проекте, в котором не было специалиста, тестировщиками становятся сами пользователи, что сильно понижает рейтинг продукта на выпущенной площадке.
3.2. Неправильный пайплайн.
Из-за финансовых ограничений или нежелании выделять дополнительных средств тестировщиков подключают в пред-релизное состояние проекта, который и так находится в состоянии кранча. После специалист находит огромное количество багов, что сильно понижает «боевой» дух разработчиков и добавляет работы всей команде. А после это приводит либо к сдвижению сроков, либо бессонным ночам специалистов, либо низкому рейтингу продукта из-за договоров с инвесторами, площадками и т.п.
3.3. Строгий регламент по дате релиза.
К сожалению, формальности это один из самых уязвимых частей любого проекта, ведь огромное количество даже крутых проектов были в обязательствах выпускать продукт в формуле «как есть – потом допилим», а после находились в очень долгой турбулентности.
3.4. На моей личной практике я попадал в разные ситуации.
С нуля - достаточно комфортно для всех, по мере разработки находятся дефекты, которые исправляются под корень. Предлагаю свои предложения или решения по логике (как пользователь), а проект выходит более качественным и оптимизированным.
Пред-релиз - ты моментально попадаешь в дедлайн и тебе как специалисту необходимо искать баланс между подходом, сроками, скоростью, приоритетами и сложностью. После аккуратно представить это все на контрольном созвоне с учетом человеческого фактора, потому что багов будет очень много, а разработчики не роботы.
4. Цена экономии.
Наличие разработчиков, дизайнеров, художников не дает менеджменту полной картины происходящего, так как PM работает со статусами «готово», «в процессе», «не начато». Тестировщик же независимый информатор для PM о состоянии проекта из-за нового статуса «баг».
Чем раньше будет подключен QA/QC тестировщик, тем больше будет сэкономлено после релиза, так как платить придется не только разработчику, но и всей команде из-за объемного рефакторинга (оптимизация кода).
IT - с MVP / TRL* с 4 по 9 и тех. поддержку;
GameDev - альфа, демо, бета, пред релиз и пост релиз.
*TRL - Technology Readiness Level - уровень готовности технологии
Иначе цена экономии будет ощутима для любой команды, особенно для CEO и инвесторов, ведь они будут платить не только деньгами, временем и нервами, но и своей репутацией.
Подключить тестировщика поздно - ошибка
Не подключать тестировщика - фатальная ошибка.
Спасибо, что прочитали!
Данная тема возникла в моей голове достаточно давно, но благодаря различным дискуссиям и банальному общению с приятными людьми из разных сфер захотелось прям написать. Если вы CEO, HR или человек, который интересуется QA/QC тестированием в GameDev вы можете ко мне обратиться, подскажу с удовольствием!
Возможные longread темы:
- Как стать тестировщиком [GameDev];
- Искусство подачи репортов;
- Знания тестировщика [GameDev];
- Мысли как пользователь;
- Предложи в комментариях!