Какая роль у отдела тестирования в процессе разработки игр
Перейти к содержимому

Какая роль у отдела тестирования в процессе разработки игр

  • автор:

Роль разработчиков и тестировщиков в обеспечении качества компьютерных игр

Если вы – геймер, вы точно слышали о «Cyberpunk 2077» от студии CD Project RED, если нет – то все равно вы должны были хоть что-то слышать об этой игре. По замыслу руководства CD Project RED эта игра должна была стать лучшей компьютерной игрой в истории, событием 2020 года в игровой индустрии, и, учитывая репутацию, которую студия уже успела получить благодаря своему «Ведьмаку», многие искренне верили в ее успех. Игра ждала своего появления аж 8 лет (первый анонс был еще в 2012 году), CD Project RED потратила миллионы долларов на разработку и маркетинг, в проект даже привлекли Киану Ривза, который исполнил одну из ключевых ролей, но что-то пошло не так…

Несмотря на ошеломительный успех первых дней (только на ПК заказали более 4,7 млн. копий), то, что случилось далее геймеры точно не ожидали. На ПК игра идет еще более-менее нормально, но на консолях (кроме новейших) ситуация просто ужасная. Полная заторможенность, огромное количество багов, плохая оптимизация, «разрывы экрана» и другие неожиданности привели к тому, что более 150 миллионов геймеров так и не смогли нормально поиграть в нее.

Многие огорчены и разочарованы, а студия, которая до этого считалась одной из лучших в индустрии терпит репутационные потери. Да, они пообещали в ближайшее время выпустить обновления и патчи, которые должны исправить ситуацию, но общее впечатление уже сложилось, и результат можно описать одним словом – ПРОВАЛ.

Так что же случилось и когда процесс пошел не так? Вот версия главного разработчика Марчина Ивински (Marcin Iwinski):

Главный тестировщик проекта, Стей МакСти выразила мнение, что в этом видео Марчин обвиняет их отдел в провале, поскольку «тестировщики не нашли баги» и руководство приняло поспешное решение выпустить игру.

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

Как разработчики могут обеспечить качество игры

  • Никто лучше разработчика не знает особенности конкретной части игры. Разработчики лучше всех остальных понимают все особенности и нюансы своей игры, и, хотя они конечно же стараются сразу сделать все хорошо, но все же всегда будут «узкие места», в которых могут появиться дефекты, и разработчик точно знает где они. Поэтому подсказать тестировщику на что именно, где и когда обратить особое внимание – хорошая практика для разработчика. На самом деле, тестирование игр – это очень сложный процесс, несмотря на кажущуюся увлекательность. В игре, тем более в такой, как «Cyberpunk 2077» очень много разных взаимодействий и сценариев поведения для игрока. В идеале все их нужно опробовать. В лучшем случае, разработчик помогает тестировщикам создавать сценарии тестирования, если есть такая возможность. Это позволит найти максимально много ошибок на максимально раннем сроке. А это означает, что можно быстро и дешево найти все баги.
  • Smoke test своих изменений. Да, тестирование – это работа тестировщиков, а не разработчиков. Но тут есть свои нюансы. Возьмем к примеру такой случай: программист отдает код, который невозможно компилировать, или для этого не хватает определенных файлов, в результате это приводит к остановке потока, простою и денежным потерям. Это только простейший случай, так как на сборку проекта и его компиляцию уйдет не так уж и много времени, но бывают и более сложные ситуации. Например, такая: гейм-дизайнер в одном из уровней меняет какой-то компонент, и не проверяет возможность его прохождения с таким изменением. Появляется потенциальное непроходимое место, тестировщики делают билд, добираются до этого проблемного места и обнаруживают, что его невозможно пройти. Таким образом потрачено время. Но этого можно легко избежать, если внедрить практику smoke test в работе разработчиков.
  • Помощь в процессе составления требований для тестировщиков. В идеале схема выглядит так: разработчики передают фичи на тест вместе с документами к ним, но так бывает далеко не всегда, и тестировщикам иногда нужно самим составить список требований. Хуже всего, когда им нужно сделать это на базе неактуальной документации, или, когда ее вообще нет (и так тоже бывает). Таким образом получается, что тестировщик не может полагаться на правильность требований, составленных на его проверках. Поэтому разработчик должен пересматривать тесты и проверять их валидность.

На выполнение этих рекомендаций не потребуется много времени (больше всего займет smoke test, но и это в конечном счете окупится), но их выполнение поможет команде значительно улучшить качество продукта.

Как тестировщики могут обеспечить качество игры

А сейчас давайте рассмотрим роль тестировщиков в обеспечении качества игр. На самом деле, тестировщики не повышают качество игры (сами по себе). Они ищут и находят те ошибки и проблемы, которые уже есть в игре, и исправить их, а значит и повысить качество продукта тестировщики не могут, это не входит в их обязанности. Тестирование – это оценка продукта, несмотря на бытующее среди некоторых разработчиков мнение «тестировщики все ломают», это далеко не так. Тестировщики не придумывают проблем, они уже там есть. Задача этих людей – правильно выявить их. В процессе тестирования могут возникнуть определенные проблемы, и здесь мы опишем наиболее типичные из них.

Проблемы тестирования

  1. Квалификация специалистов. Бытует мнение, что тестирование – самая неквалифицированная в ИТ работа, поэтому чтобы быстро закрыть этот вопрос, можно просто нанять побольше джуниоров, и они в кратчайший срок смогут прогнать все тесты. Но, на деле, все оказывается не так просто. Пять джуниоров без опыта не заменят одного высококлассного специалиста. Да, джуниоры тоже нужны в проекте, но без опытных тестировщиков никак не обойтись.
  2. Недостаток времени/тестировщиков. Нужно понимать, что игра — это сложный программный продукт с космическим количество пользовательских сценариев и вариантов взаимодействия. Даже при огромном штате тестировщиков, проверить все не удастся, но с другой стороны, если не уделить этому процессу достаточно внимания, продукт получится сырым и непривлекательным из-за множества ошибок, и сбоев. Поэтому лучший вариант – это разумный баланс между временем и количеством тестировщиков, которых нужно задействовать. В разработке игр за примерный ориентир можно предложить схему соотношения количества разработчиков к тестировщикам 4:1, хотя здесь все зависит от специфики проекта.
  3. Ранее/позднее тестирование. Вопрос тестирования с опозданием выглядит более-менее ясно – сроки горят (Cyberpunk 2077 – хороший пример), работы выполняются кое-как, в результате продукт выходит сырой. Но есть и другая сторона проблемы – ранее тестирование. Многие команды стремятся максимально сократить время на разработку продукта, и вводят тестировщиков в работу максимально быстро. Что плохого в баге, который найден максимально быстро? Если продукт уже на финишной прямой – отлично! Но если тестировщик находит баг еще в «драфт»-версии, это может негативно сказаться на работе разработчиков. Нет смысла фиксить баги в процессе работы над продуктом, когда все меняется по 10 раз в день. Это – лишнее время и никому не нужные усилия. Поэтому очень важно, чтобы тестировщики правильно понимали, на каком они этапе и свою роль на этом этапе.

Так что, как видите тестирование в играх – это не такой простой процесс, как кажется на первый взгляд. А еще, для нормального выполнения этой работы вам понадобится достаточное количество профессионалов.

Так кто же обеспечивает качество игры

Итак, несмотря на бытующее среди некоторых специалистов мнение, тестировщики не могут сами по себе обеспечить качество игры, да они и не должны этого делать. Разработка ПО и игр в частности – это командная работа и ее успех зависит в первую очередь от слаженной работы всех ее участников. Готовый качественный продукт – это результат общих стараний. Нет смысла обвинять других членов команды, если ваш продукт провалился – в такой ситуации проиграют все. И для того, чтобы команда работала слаженно, каждый ее член должен хорошо понимать, какова его роль и выполнять свою работу так, как нужно. Это относится и к разработчикам, и к тестировщикам.

Андрей Мельничук

Андрей Мельничук

Автор. Пишет о компьютерной технике, электронике и ИТ, делает аналитические обзоры.

Какая роль у отдела тестирования в процессе разработки игр

Тестирование игрового продукта

Как? Почему? Зачем?

В моей команде очень много крутых людей, которые знают не только своё дело, но и отлично работают на смежных поприщах. Так вот и вышло, что наш QA Андрей Кульбицкий попробовал себя в роли лектора для одного очень необычного детского класса киевской Инжиниринговой школы Brobots. Девятиклашки прослушали 40-минутную презентацию и после неё сразу приступили к практическому заданию — своему первому полноценному тестированию игры.

Целью было: рассказать ребятам о том, как делаются игры и про место тестирования в этом процессе. После лекции каждый получил свежеиспеченный билд игры Altar: the War of Gods и домашнее задание в “козы” простенького баг-треккера.

Я сама слушала лекцию Андрея взахлёб, потому очень уж захотелось поделиться основными постулатами, которые он положил в головы малышни — так уж всё было чётко, понятно и структурированно. Как демонстрационный материал, буду порой показывать части его презентации 😉 Итак, поехали!

Немного об объекте тестирования

Altar: the War of Gods — это онлайн коллекционная карточная игра в её классическом понимании. Есть главный герой, которого нужно защищать, а также его войско, которое под каждую новую битву можно собирать из разных существ. Игра находится на этапе вертикального среза, для широкой общественности — в стадии Альфа. Функционал не полон, в игре куча багов и прочих неожиданностей, так что тестить тут очень даже есть что 🙂

Этапы разработки игры

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

1.Этап: концептирование

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

На этом этапе каждый член команды уже чётко понимает, что будет делать, что от него требуется и сколько времени это будет занимать.

Некоторые компании быстро перепрыгивают этот этап, однако такой подход чреват дальнейшими трудностями на этапе продакшена, так что лучше подготовить подробный план работ заранее.

2. Этап: прототипирование

Целью этого этапа является сборка рабочего “пробника” гейпмплея игры и если он окажется не жизнеспособным, повторить этот процесс столько раз, сколько потребуется.

На этом этапе мы можем строить гепотезы и проводить соответствующие эксперименты и поверьте, это ни капельки не отличается от настоящего научного метода. Насколько удобен механизм контроля? Насколько понятен туториал? А игра вообще интересная? Зачастую, посредством экспериментов можно найти ответы на эти вопросы.

3. Этап: вертикальный срез

“Вертикальный срез — это красивый кусок торта, когда самого торта ещё как-бы и нет.” (с)

По факту, это доведенный до логичесткого завершения прототип, ведь он представляет нам все ключевые механики и геймплейные элементы, позволяет погрузится в атмосферу игры. Иногда даже может показаться, что перед вами уже завершенная игра, но это не так. Тут и принимается окончательное решение, стоит ли работать наверняка с этим проектом. Вертикальные срезы — очень важны для презентаций и будущих инвесторов, поскольку на этом этапе можно уже попробовать влюбить в игру определённую аудиторию 🙂

4. Этап: производство контента

Если на этапе вертикального среза мы видели одного героя, то теперь сможем увидеть 10. Если нам доступна была только одна боевая арена в преисподней, то теперь подраться можно будет и в раю, и в морской пучине и даже на кухне у средневековой хозяйки.

Кто отвечает за качество игр: разработчик или тестировщик

Всем привет! Меня зовут Александр Дончук, я руководитель отдела обеспечения качества студии 4A Games, известной по играм «Метро 2033», «Метро: Луч надежды», «Метро: Исход», ARKTIKA.1. Уже год я занимаюсь тестированием игр и более 3 лет преподаю курс для желающих стать тестировщиками игр в рамках школы Games Academy. С 2019 года мой курс можно прослушать и онлайн на платформе devtodev.

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

Почему я выбрал конкретно эту тему? Общаясь с людьми, я часто сталкивался с ошибочным мнением о том, что за качество игры отвечают тестировщики, а если кого-то оно не устраивает, значит, виноват в этом отдел контроля и обеспечения качества. Людям, не разрабатывающим игры (или другие приложения), такое мнение вполне простительно. Но когда я услышал подобные речи из уст опытных разработчиков, то во мне стал пробуждаться праведный гнев. И я недоумевал тем сильнее, чем опытнее был мой так глубоко заблуждающийся собеседник. Итогом моих размышлений стала идея: раз люди не осознают, как создается качество, моя задача — просветить их в этом по мере возможностей.

В статье я постараюсь кратко объяснить суть работы QA и дать определение качеству, расскажу о том, кто же в действительности его создает и как лучше взаимодействовать тестировщикам и разработчикам, чтобы это самое качество неустанно повышать.

Что такое качество

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

Итак, что же такое качество? Хорошо известная всем (я думаю) Международная организация по стандартизации (ISO) имеет целый специальный комитет, определяющий понятие и критерии качества программного обеспечения.

Международный стандарт ISO 8402:1994 гласит: качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Другими словами, это показатель того, насколько хорошо ваше ПО (в нашем случае игра) отвечает явным и неявным требованиям, предъявленным к нему.

Иллюстрации Каталины Маевской

Пойдем дальше. Международный совет по тестированию программного обеспечения (ISTQB), занимающийся экзаменацией и сертификацией тестировщиков, имеет свой глоссарий, в котором также определяется понятие качества. Согласно ему, качество — это степень, в которой ваше ПО обладает требуемой всеми участниками комбинацией свойств.

Одно из важнейших словосочетаний здесь — «всеми участниками». Естественно, конечная цель разработки — предоставить игроку продукт без ошибок. Но чтобы этого достичь, ваша игра должна соответствовать ожиданиям всех участников процесса: разработчиков, тестировщиков, менеджеров, издателей, маркетологов.

Отдельное внимание хочется уделить критериям качества по той же ISO, особенно одному из них. Итак, согласно ISO, существуют такие 6 критериев качества: функциональность, надежность, практичность, эффективность, мобильность, сопровождаемость.

Как вы уже могли догадаться, я хочу остановиться именно на последнем критерии из списка — на сопровождаемости. Если все остальные критерии в той или иной степени отражают ожидания конечного пользователя от игры, то сопровождаемость важна в первую очередь самим разработчикам.

Не изобретаем велосипед, идем к тем же стандартам ISO. ISO 9126 гласит, что сопровождаемость — это 4 основных фактора: удобство для анализа, изменяемость, стабильность, тестопригодность.

И тестопригодность — именно то, чем часто пренебрегают при планировании и разработке фич. Хотя это важнейший фактор, от которого напрямую зависит, насколько хорошо эта фича в итоге будет работать.

Что такое тестопригодность

Это приспособленность игры (или ее части) к обнаружению дефектов и их локализации. Всем известный шуточный закон Мерфи в тестировании работает на сто процентов: если что-то не протестировано, значит, оно сломано. Определение тестопригодности фичи на ранних этапах ее разработки — важнейшая задача QA, выполнение которой способно оградить вас от очень дорогих ошибок.

Смоделируем ситуацию: гейм-дизайнер придумал фичу, а вы в силу каких-то ее особенностей не понимаете, как нормально проверить ее. Например, вы придумываете систему нанесения урона противникам с большим количеством параметров: множество типов патронов, разные типы урона и брони. Дизайнер создает сложную систему, количество вариантов в которой сугубо комбинаторно будет очень большим. Такое проверить уже сложно. Следом добавляется еще какой-то влияющий на урон параметр: перк игрока, зависимость от окружающей среды (например, урон меняется в зависимости от того, где сейчас находится противник). Каждый новый параметр добавляет еще одну степень к количеству возможных вариантов. В такой момент важно спросить у этого разработчика: «А как, по-твоему, мы будем это проверять?» И если он не может дать вразумительного ответа, такую фичу делать нельзя. Она не будет работать сама и будет негативно влиять на качество работы других фич, которые могут с ней пересекаться.

Кто же в действительности отвечает за качество игры

Лично мое мнение (и я надеюсь, что все читатели этой статьи в итоге согласятся с ним): достичь желаемого качества игры возможно только благодаря слаженной работе всей команды. Не только тестировщики, не только разработчики, не только менеджмент — все должны эффективно взаимодействовать ради желаемого результата. Чтобы получить качественную игру по завершении работы над ней, нужно поддерживать ее качество и в процессе ее создания. Одно без другого невозможно.

Звучит достаточно банально: «Чтобы получить качественную игру, просто делайте ее хорошо». К сожалению, в современных движках еще не придумали кнопку «Сделать хорошо» (упущение, конечно, на мой взгляд). Поэтому я хотел бы поделиться набором конкретных советов. Они будут работать вне зависимости от жанра вашей игры, бюджетов, размеров команды и прочих факторов, которые, как многие по неопытности полагают, должны критично влиять на качество игры.

Что делать разработчикам, чтобы повысить качество игры

Первый блок советов касается процессов разработки и самих разработчиков.

1. Каждый разработчик хорошо (скорее всего, лучше всех) знает конкретную часть игры, которой непосредственно занимается. И зачастую он может довольно точно предсказать появление дефекта. Изменив параметры нанесения урона, разработчик может подсказать тестировщикам проверить пробиваемость материалов. Изменив настройки физической капсулы игрока, вполне возможно спрогнозировать застревания в местах, где раньше можно было пролезть. Или, наоборот, можно предсказать, что игрок пройдет туда, куда до этого проходить не должен был.

Это абсолютно здоровая и полезная практика, когда разработчик указывает тестировщику, где, что и как стоит проверить, предполагая, что там может возникнуть ошибка. Или же он может просто рассказать, как лучше протестировать тот или иной функционал. Игры — крайне сложные системы с огромным количеством взаимодействий и возможных пользовательских сценариев. Если разработчик может помочь создать эффективные сценарии тестировщикам, это однозначно стоит делать. Чем быстрее тестировщик найдет дефект, чем быстрее его исправят, тем меньше этот дефект нанесет вреда продукту. Чем дольше ошибка находится в игре, тем она дороже.

2. Code review. Мощнейшая практика для повышения качества вашей игры. Чем качественнее у вас код, тем качественнее в итоге будет ваш продукт. Причем относится это не только к программистам. Дизайнеры пишут скрипты, которые тоже с этой точки зрения можно считать кодом, проводя их review. Как говорится, всего несколько недель регрессии способны заменить часы code review.

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

4. Разработчики должны участвовать в составлении требований тестировщиками. Безусловно, в идеальной схеме разработчики должны отдавать на тестирование фичи уже с документацией и требованиями к ним. Однако зачастую тестировщикам приходится составлять список требований самостоятельно. И ладно еще, если это происходит на основе актуальной документации. Но если документация неактуальна или ее вообще нет, тестировщик никогда не может быть уверен, что требования, которые он составил на основе своих проверок, верны. А значит, задача разработчика — провести review тестов и указать, что данные проверок валидны и фича должна соответствовать им.

Этот набор не самых трудозатратных рекомендаций (пускай smoke test и code review все же потребуют времени, оно с лихвой компенсируется) позволяет разработчикам повысить качество продукта в любой команде и в любой ситуации.

Что делать тестировщикам, чтобы повысить качество игры

Теперь же перейдем к тестировщикам. Главный вопрос, на который хочется дать ответ в этой статье, — «А повышают ли тестировщики качество игр?». Внимание, сейчас будет спойлер: нет, не повышают.

Тестировщики находят ошибки, которые уже попали в ваш продукт. На момент тестирования игра уже обладает каким-то уровнем качества. Сами тестировщики его повысить не могут. У нас для этого нет ни компетенций, ни полномочий. Тестирование — информационный сервис. Тестировщики — люди, которые рассказывают другим заинтересованным людям правду о вашем продукте. Мы ни в коем случае его не ломаем, как можно часто услышать от тех же разработчиков, мол, «я отдал продукт в тестирование, сейчас тестировщики все сломают». Да не ломаем мы ничего! Оно уже сломано. Как однажды полушутя сказал Джеймс Бах, «максимум, что могут сломать тестировщики, — это ваши мечты о продукте». И это абсолютная правда. Мы не ломаем игры, мы рассказываем разработчикам, где они сломаны. Или не сломаны. Не менее важная часть процесса тестирования — убедиться, что все работает так, как задумывалось.

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

И что же получается? Тестировщик ни в чем не виноват? Это злые разработчики делают плохие игры?

Это не так. Существует целый ряд проблем, которые могут возникать в процессе тестирования и из-за которых будет страдать качество продукта. Хочу поделиться списком ошибок и их возможных решений, достаточно универсальных для большинства игровых продуктов и студий.

Первая проблема — недостаточная квалификация тестировщиков. Только джуны никогда не смогут добиться желаемого результата — ни в разработке, ни в тестировании. К сожалению, распространено мнение, что тестировщики — самые низкоквалифицированные сотрудники и можно нанять энное количество джунов к концу проекта, чтобы закрыть существующие вопросы тестирования. А не получится — нанять еще джунов. Как в анекдоте про 9 женщин, беременных 1 месяц, это не работает. Множество джунов никогда не заменит одного квалифицированного тестировщика. Естественно, как и в любой другой сфере, джунов надо больше. Задач, не требующих какой-то исключительной компетенции, у вас будет в итоге намного больше. Но квалифицированные QA — всегда основа и опора вашего отдела. Вы должны их нанимать, воспитывать и любить. Как и в любой другой сфере в разработке, вы не сможете обойтись исключительно некомпетентным составом.

Вторая проблема — недостаток тестировщиков. Да, в большинстве своем игры — крайне сложные системы с буквально неограниченным количеством возможных пользовательских сценариев и вариантов взаимодействия различных механик. Именно поэтому полностью покрыть вашу игру проверками даже теоретически невозможно. Не существует какой-то универсальной схемы, по которой можно вычислить необходимое количество тестировщиков для вашего проекта. На это будет влиять слишком много факторов: объем самой игры, количество механик, платформ, даже жанр и линейность игрового процесса. Однако одним из самых адекватных критериев, от которого можно плясать, я считаю количество разработчиков, чью работу вы будете тестировать. Считается, что здравое соотношение — 1 тестировщик на 4 разработчика. И это то количество, к которому имеет смысл стремиться, уже в дальнейшем делая поправки на специфику вашего конкретного продукта.

Третья проблема — несвоевременное тестирование. Причем это касается обеих возможных сторон несвоевременности. Если с проблемой слишком позднего запуска тестирования все довольно очевидно, то о проблеме слишком раннего тестирования я хотел бы поговорить отдельно.

Игры создаются не одномоментно. Наверняка процесс создания вашей игры разбит на этапы и отчетные периоды. Тестировщикам важно осознавать, на каком этапе вы сейчас находитесь, и указывать только релевантные для этого этапа дефекты. Казалось бы, что плохого в том, что вы заранее напишете о найденных багах? Если они касаются фичи в околофинальном состоянии — ничего. Однако, когда тестировщики начинают описывать дефекты низкой важности на этапе условного драфта, это очень вредно для всей разработки. Тестировщики тратят время на поиск, локализацию и занесение ненужных на данном этапе дефектов. В лучшем случае они просто будут висеть мертвым грузом у вас в баг-трекере, и вам придется регрессить их через какое-то время, когда проект выйдет на финальные этапы. В худшем случае неопытный разработчик возьмется их решать. Чинить миноры в драфте — худшее, что можно придумать. Это потеря времени на совершенно никому не нужную работу. Баги коллизии на ранних этапах игры никого не интересуют — там вся геометрия еще 15 раз переделается. Дергающиеся анимации в сценах, которые еще не утверждены и не анимированы на чистовую, чинить нельзя. Старайтесь максимально избегать таких багов, следить за текущим этапом и осознавать требования и ко всему продукту, и конкретно к тестируемой фиче.

В заключение

Так как тестирование — сервис про коммуникации, старайтесь как можно больше коммуницировать. Именно на общении между разработчиками и тестировщиками строится качество вашей игры. Запрашивайте тестирование, пишите отчеты, наращивайте документацию, утверждайте, спорьте, если это нужно. Это и есть наша работа.

Спасибо всем, кто дочитал.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Профессия тестировщик: разбираемся в QA, QC и testing

Чем занимаются тестировщики, как формируются отделы по контролю за качеством и какая специализация в тестировании пользуется сейчас наибольшим спросом.

Обложка поста Профессия тестировщик: разбираемся в QA, QC и testing

Анастасия Шарикова, преподавательница курса «Тестировщик» в Нетологии и QA Lead в Bookmate, рассказала, чем занимаются тестировщики, как формируются отделы по контролю за качеством, а также какая специализация в тестировании пользуется сейчас наибольшим спросом.

Совершенствовать качество продукта, каким бы он ни был — от мобильных игр до софта для запуска ракет в космос, — с каждым днём всё важнее для бизнеса. И главную роль в этом играют именно специалисты по обеспечению качества. Все они делятся по самым разным профессиональным уровням и направлениям, но цель у их одна — проверить и обеспечить стандарты выпускаемого продукта.

Человеку со стороны может показаться, что все «специалисты по тестированию» занимаются одинаковыми скучными задачами, но это не так. Разберёмся, чем на самом деле занимаются профессионалы-тестировщики и какое место занимают в команде.

Что такое QA, QC, тестирование и кто такой тестировщик

Тестирование охватывает весь цикл разработки и включает в себя планирование, проектирование, создание и выполнение тест-кейсов. Сейчас мы кратко поговорим о каждом из них.

Схематически отношения между QA, QC и тестированием можно представить так:

QA (англ. Quality Assurance) — обеспечение качества продукта — это, собственно, весь комплекс процессов, обеспечивающих качество, наиболее обширное понятие. QA интегрировано во все этапы разработки: от описания проекта до тестирования, релиза и даже пост-релизного обслуживания.

Специалисты QA создают и реализуют различные тактики для повышения качества на всех стадиях производства: подготовка и установка стандартов, анализ качества, выбор инструментов, предотвращение ошибок и постоянное усовершенствование процесса.

QC (англ. Quality Control) — контроль качества продукта — это часть комплекса QA, которая отвечает за анализ результатов тестирования, поиск ошибок и их устранение. QC ориентирован на проверку конкретного продукта, в него входят различные процессы, такие как анализ кода, технические обзоры, анализ дизайна, тестирование и прочее.

Тестирование — это уже непосредственно процесс проверки результатов работы на соответствие установленным требованиям. А тестировщик — это специалист, который занимается такой проверкой. Он тестирует компоненты продукта или весь продукт целиком на предмет ошибок или неточностей разработки. Тестирование — один из ключевых процессов в системе обеспечения качества.

Специализацию тестировщиков можно разделить по направлениям: тестирование безопасности, производительности, юзабилити; а также по методам написания тестов: ручное и автоматизированное тестирование.

Сейчас большинство компаний устроено таким образом, что тестировщиками в них работают в основном сотрудники на начальном этапе карьеры — то есть это junior-специалисты по тестированию. Они выполняют проверку софтов по готовым тест-кейсам. Специалисты более высокого уровня (тест-аналитики, автотестеры, менеджеры по тестированию) помогают им на других этапах разработки.

Карьера тестировщика: варианты развития

У тестировщика практически в любой компании есть три пути развития карьеры: вертикальный, горизонтальный и смежный.

Вертикальное развитие

Первый вариант — развиваться в сфере обеспечения качества по иерархии, то есть уходить в управление проектами или командой.

В каждом сегменте тестирования существуют свои грейды, которые определяют уровень специалиста: junior, middle и senior. Руководителем всех специалистов является test-lead или team-lead в зависимости от специфики компании. На некоторых проектах может быть также отдельный инженер по качеству, head of QA.

Из начинающего специалиста тестировщик может дорасти до любого из уровней, главное — постоянно держать себя в тонусе. Азы профессии освоить не трудно, а вот развиваться дальше и на каждом этапе приобретать новые знания уже гораздо сложнее. Конечно, всё зависит от человека, но, например, от junior до middle возможно дорасти в среднем за год.

Горизонтальное развитие

Второй вариант — развиваться как специалист и прокачивать hard skills, а в дальнейшим благодаря ним можно будет выбрать наиболее интересное направление. Тестировщик может стать автотестером или специалистом по тестированию юзабилити, безопасности, производительности. При этом есть профессионалы, которые могут совмещать оба варианта.

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

Спрос на автоматизированное тестирование

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

Ручное и автоматизированное тестирование: рассматриваем преимущества и недостатки подходов

Если оценить рынок вакансий, то именно автотестеры сейчас пользуются огромным спросом, да и и уровень заработной платы у них выше. Хотя с моей точки зрения, противопоставлять ручное и автоматизированное тестирование неправильно, поскольку и то и другое решает в итоге одну задачу.

Сегодня специалистов по автоматизированному тестированию ищет большинство компаний на рынке, причём как в команды по мобильной разработке, так и в тестирование бэкенда, фронтенда и других сфер. Даже начинающий специалист, имеющий базу, надолго без предложения работы не останется. Особенно, если он умеет ещё и развернуть всю инфраструктуру тестирования.

Переход в смежные сферы

Третий путь развития тестировщика — переквалификация в смежную специальность. Принято считать, что тестирование — это своего рода простая точка входа в IT и из него гораздо легче переходить в другие технические направления. Поэтому иногда специалисты по тестированию решают попробовать себя в других IT-профессиях. Так, например, тестировщик может стать продакт-менеджером, бизнес-аналитиком, разработчиком и даже дизайнером. На самом деле это не так просто, как кажется, — понадобятся дополнительные знания, желание развиваться, время на обучение и поиск работы.

Как тестировщику стать разработчиком — отвечают эксперты

Как стать тестировщиком

Вариантов, как освоить профессию тестировщика, сейчас достаточно много. Можно самостоятельно учиться по книгам, статьям и видеоурокам из интернета, устроиться на стажировку в компанию, где на практике покажут, что нужно делать, а также пойти в учебное заведение, которое готовит таких специалистов.

Как стать QA-инженером

Однако в вузах нет специальности «тестировщик». Если рассматривать государственное образование, то проведение тестов изучается только в рамках программирования. Минус в том, что практики при обучении в вузе всё равно не получить, если не работать параллельно на реальных проектах.

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

Другой вариант — устроиться в IT-компанию на стажировку, скорее всего, неоплачиваемую, чтобы учиться в процессе работы. Конечно, поначалу вам не доверят работу специалиста полностью, зато у вас будет возможность с самого начала общаться с профессионалами и учиться у них.

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

Ещё один важный и не совсем очевидный плюс курсов в том, что они дополнительно дисциплинируют и забросить учебу становится сложно: всегда есть четкое расписание занятий, домашние задания, пример других студентов. Это своеобразный волшебный пинок, которого обычно так не хватает при самостоятельном обучении.

Если говорить об обучении уже практикующего специалиста, например, ручного тестировщика, то здесь тоже немало вариантов: от специализированных курсов до самостоятельного изучения языков и инструментов, которые понадобятся в новом направлении. Как пример, если интересно тестирование веб-приложений, можно начать с изучения Selenium или Katalon Studio и Java.

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

Ещё один интересный вариант для тех, кто не знает, что именно ему понадобится, — попробуйте автоматизировать собственные рутинные процессы и разобраться, чего не хватает в знаниях.

Обеспечение качества сейчас — бурно развивающаяся перспективная сфера, особенно в России и СНГ, и это очень радует и вдохновляет постоянно развиваться в этом направлении.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *