Перевод книги «Game QA & Testing». Часть 5

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

Предыдущая часть здесь:

Давайте посмотрим определение из словаря! Ссылаясь на словарь Мерриам-Вебстер, баг может имеет множество определений:

1). а) насекомое или другое ползающее беспозвоночное (паук или многоножка)

б). одно из различных насекомых (постельный клоп или таракан), обычно считающееся неприятным

в) любой из отряда (Hemiptera и особенно его подотряд Heteroptera) насекомых с присасывающими ротовыми частями, утолщенными у основания передними крыльями, неполным метаморфозом и часто являющихся сельскохозяйственными вредителями — также называемые истинными насекомыми

2). неожиданный дефект, ошибка, недостаток или несовершенство (программы полны багов).

3). а) микроб или микроорганизм, в особенности если он вызывает болезнь

б) неуточненное или неспецифическое заболевание, причиной которого обычно считается насекомое

4) внезапный энтузиазм

5) энтузиаст

6) известная личность

7) сумасшедший человек

8) скрытое подслушивающее устройство

9) величина довольствия для учеников-жокеев

Определение № 2 здесь победитель. Так как видеоигры — это вид программного обеспечения, оно будет в самый раз. Давайте поближе взглянем на это определение:

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

Твоя главная задача как тестировщика это:

Дополнительные задачи это:

Если ты будешь держать эти директивы в голове, ты станешь выдающимся тестировщиком. Пришло время сделать первый шаг к «внутреннему кругу» тестирования. Давайте начнем, окинув взглядом различные уровни серьезности багов.

Эд Ротберг в игровом бизнесе с 1978, работал как продюсер, дизайнер, программист, исполнительный директор в различные времена своей карьеры. Он был одним из основателей Videa, которая была неожиданно присоединена к Bally Midway. Его карьера также включает двухгодичную работу по контракту в Apple Computer. Он работал в Atari (Atari Baseball, BattleZone, Star Wars, Blasteroids, S.T.U.N. Runner, Shuuz, Steel Talons, Guardians of the Hood), Bally Midway (Snake Pit), 3DO (Station Invasion, IMSA Racing [M2]), Silicon Entertainment (nascar Silicon Motor Speedway), THQ (MX Superfly, WWE CrushHour), и Mine Shaft Entertainment (High Heat Baseball 2002, Nokia Pro Series Golf, Blazing Angels: Squadrons of WWII).

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

Баги низкого приоритета (low bugs) едва имеют значение. По факту, часто команде разработки без разницы: починили их или нет. Примеры низкого уровня багов — маленькие графические глитчи, короткие нарушения звука тут и там, кое-какие небольшие ошибки в интерфейсе (включая опечатки, что лично нас очень расстраивает!) — все «ошибки», которые не влияют на погружение или то, как игра воспринимается в целом. Низкого уровня баги существуют в каждой игре, что вы играли, от низкобюджетных до ААА. Они временами игнорируются в пользу более серьезных багов — тех, что действительно имеют значение.

Баги среднего приоритета (medium bugs) следует устранять. Они проявляют себя чаще. Так что если визуальный баг встречается часто, а не редко — он должен быть проапгрейжен до среднего приоритета. В то же самое время, баг должен быть категоризирован как низкоприоритетный, если он случается где-то глубоко внутри интерфейса. Некоторые баги могут быть средними, если случаются на главном экране. Другой пример — это баг, который раздражает игрока — но не влияет на геймплей.

Баги высокого приоритета (high bugs) обязаны быть устранены. Игра, что продается с такими багами — плохая игра, или она была спешно отправлена в продажу. Баги высокого приоритета серьезно влияют на геймплей. Они заставляют все остановиться. Если ты не можешь открыть дверь, а эта дверь в конце уровня — ты поймал баг высокого приоритета. Если ты не можешь сменить оружие — и это высокий. Если фреймрейт падает с обычных 60 кадров в секунду до 20 — угадайте что? Это баг высокого приоритета.

Критические баги (critical) очень особенные. Критический баг требует немедленного внимания от разработчиков. Никто не идет домой, а если они уже дома — то лучше бежать назад. Критические баги распознаются как «небо рушится» — звонки в 2 часа ночи и другие признаки серьезного отношения! Но что такое в реальности критический баг? Критические баги — причина «катастроф», таких как неожиданное закрытие игры, зависания, потеря данных. Если вы когда-нибудь обнаруживали 50-часовое сохранение игры поврежденным — вы знаете, что мы имеем в виду. Критические баги должны быть устранены любой ценой — если издатель столкнется с критическим багом в процессе тестирования на соответствие (поговорим об этом позже в этой главе), игру отправят назад разработчику.

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

В фазе концепта дизайнер, продюсер или другой человек с «вИдением», возглавляющий проект, формирует идею об игре. Короткий концепт документ пишется, чтобы описать идею для остальных разработчиков. Концепт арт также часто поддерживает фокус на некоторых героях, внутреннем и наружном окружении, реквизите или конструкциях. Если концепт доказал свою успешность — концепт документ обычно вырастает в игровой дизайнерский документ (game design document, GDD).Создание этого документа происходит на стадии дизайна проекта.

Как только дан внутренний зеленый свет на производство, разработчики создают игровой прототип игры. Прототип очень грубо сделан и не является полноценной игрой, но он имеет образец геймплея. Если сделка с издателем еще не совершена, прототип показывают издателям или будущим инвесторам — процесс, который иногда обрекает начатый проект годами находиться в «забвении”. Важно, чтобы прототип содержал “золотую» игру — эта сверкающая геймплейная механика/закрученная история должны сделать игру финансово успешной.

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

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

Когда игра достигла золотого статуса, она готова отправиться в продажу. Заметьте — мы не говорим «готова”, но “может уже продаваться». Сегодня, когда консоли неотрывно соединены с интернетом — игры часто выпускаются «почти готовыми» и потом чинятся загружаемыми обновлениями (патчами). К сожалению, это не значит, что они становятся лучше (вспомним Test Drive Unlimited — которая была незавершенной, когда появилась в продаже и кое-как была доделана через примерно 6 месяцев после запуска?). Также золото можно рассматривать как время, когда игра полностью повзрослела.

Бета-тестирование, кроме того, что является важнейшей вехой — само делится на вида: закрытое и открытое. Закрытая бета используется, когда необходимо закрыть игру от публики, хотя все еще привлекает большое количество тестировщиков. Если закрытая бета успешна — разработчик может решить запланировать еще и проведение открытой беты.

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

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

Открытая бета (также известная как публичная или внешняя бета) часто используется для игр, которые имеют онлайн элементы. Некоторые жанры, такие как MMOG (или MMO) делаются с онлайн компонентами. Подключение и сетевые функции первостепенны для успеха MMO. В то время, как игра растет экспоненциально, производственные тестировщики и QA просто не могут протестировать всю игру — даже если у вас под рукой 1000 тестировщиков. Нужна внешняя помощь — и эти внешние тестировщики берутся на этапе открытой беты. Внешним тестировщикам не платят за их работу. Поиграть в раннюю версию игры бесплатно — выглядит достаточным вознаграждением. Открытая бета используется для стрессового тестирования серверов (проверка возможностей серверов с экстремально большим количеством игроков), балансировки геймплея, поиска высоко и низкоприоритетных багов, убеждения, что игра запускается корректно, когда тысячи игроков пытаются «мочить и убивать» в одно и то же время. Некоторые закрытые бета-версии пользуются большим спросом (такие как Age of Conan), в то время как для других проблемно найти достаточно игроков — с неблагоприятными последствиями к тому моменту, когда игра появится в магазинах.

James Lowe — контент-дизайнер и сценарист в Icarus Studios работал на постапокалиптической MMO Fallen Earth. Он закончил бакалавриат в университете Индианы и магистратуру по игровому арту и дизайну в институте Питтсбурга онлайн. Он живет в округе Триангл в Северной Каролине со своей женой Менди и дочкой Норой.

Как активный игрок в течение 30 лет и работающий в течение 20 лет в индустрии профессионал, Jerome Strach стал свидетелем значительного роста и технологических достижений. Он заработал первые деньги на разноске газет, чтобы купить его первый Atari 400 в 1980, а недавно уже гордился участием в финальном согласовании тестирования для Metal Gear Solid 4 и Grand Treft Auto IV. Работая на такие компании, как Atary, Digital Pictures, Pixar Animation Studios и Sony, Джероме смог изучить различные направления разработки игр — начиная от контроля качества и программирования до продюсирования, которое подразумевало работу рядом с невероятно талантливыми личностями. Веря, что жизнь — это продолжающийся процесс обучения, теперь он стремится глубже вникать в информационные технологии и сетевое администрирование, чтобы отточить свои навыки, поскольку индустрия все больше использует онлайн-соединение и включает в игры как социальные сети, так и случайное взаимодействие.

Если брать поверхностно — QA звучит как базовый процесс контроля качества, который проходят все продукты — хоть телевизоры, хоть зубные щетки. До того, как продукт поступит в продажу, важно, чтобы определенные маркеры качества были достигнуты, если не перевыполнены. QA обеспечивает это. В играх QA проводит двойной или тройной процесс прогона через «очень мелкую расческу”. Определенные части игры проверяются более, чем одним тестировщиком. Ротация не дает кому-то застрять на одном уровне, чтобы не оказалось, что его “глаз замылилися». QA также известен как последняя линия защиты игры.

Производственное тестирование далеко от последней линии. Термин «пехота» здесь больше подходит. Будучи тестировщиком на производстве, ты никогда не получишь стабильный код. Игра может вообще не запускаться. Производственное тестирование — это процесс создания такого билда игры, который достаточно стабилен для передачи в QA, а также убеждения в том, что в игру интересно играть. Следовательно, производственный тестировщик должен балансировать между двумя противоположными задачами ежедневно — техническими проблемами и проблемами геймплея одновременно. Баги, которые вы будете находить как производственный тестировщик — будут более сложными, чем баги, которые находит команда QA (если вы хорошо сделаете свою работу). Команды QA не должны сталкиваться с багами, которые следовало найти производственным тестировщикам — отчасти потому, что огромнейшие команды QA (которые могут достигать 900 тестировщиков) делают QA дорогим! Поломанный билд приводит к потере денег и счастливым тестировщикам, поигрывающим в пинг-понг.

Как вы уже изучили в Главе 1, тестирование начиналось с группы людей, которые хотели убедиться, что игра работает. С тех пор оно выросло в неотъемлемую часть цикла разработки игр. Если твоя игра тестировалась некачественно — продажи быстро упадут, а розница не будет рада. Дисциплины тестирования, рассматриваемые в этой части — области знаний внутри тестирования, в противоположность техникам тестирования (о которых поговорим в 6 главе).

Тестирование баланса гарантирует, что геймплей честен как с игроком, так с искусственным интеллектом в игре. Если один из них слишком силен — значит что-то не то. В однопользовательских играх, настройка баланса включает в себя проверку, что «легкий” уровень сложности не слишком легок, а “сложный” не слишком сложен. А “средний» уровень предлагает хороший, постепенный рост сложности. Мультиплеерные игры также требуют балансировки. Карты должны быть спроектированы нейтрально, оружие должно иметь одинаковую мощь (если нет — персонажи, владеющие им — точно должны), точки возрождения должны быть размещены честно. Правда в том, что без баланса — все матчи будут перекошены на одну из сторон. А без честных побед — нет радости от игры. Это настолько важно, что разработчики тратят месяцы на балансировку геймплея!

Тестирование баланса требует пристального внимания к деталям. В конце концов, восприятие игры (и ваши заметки) помогут разработчикам отполировать геймплей. Это интересная работа — она временами может развлекать, но очень серьезная, тем не менее.

Ниже несколько методических рекомендаций для балансировки игры во время процесса тестирования:

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

В Call of Duty 3, продюсеры давали задание много играть в Halo 2 дома. После того, как все поиграли, разработчики поменяли все параметры оружия в игре на уровень Halo 2. Геймплей стал аркадным, с несколькими попаданиями перед смертью. Как только вся команда возненавидела новые параметры, разработчики переработали их снова — в сторону параметров CoD 2. Не как в CoD 2, а ближе к Halo! В результате в игру стало проще играть, чем в CoD 2. Заслуга же Halo была в том, что теперь играть стало весело. Именно в этом и есть заслуга тестирования баланса. Если игроки описывают игру как «веселую» в интернете — вы хорошо сделали эту работу.

Исключительное для ПК, тестирование совместимости — это процесс, в котором игра тестируется на различных конфигурациях железа. Основная цель — убедиться, что игра полностью совместима с продающимися комплектующими и периферией. Тестировщики должны быть опытными в сборке ПК и поиске проблем, так как работа включает установку различных комплектующих и проверки того, как игра себя ведет на каждой из них. Тестирование совместимости технически намного сложнее, чем тестирование баланса. Установка GPU (graphics processing units, высокопроизводительных видеокарт) и модулей памяти (RAM) — не для слабаков. Даже фоновые приложения могут влиять на то, как игра работает. Знание о том, как выполнять тестирование совместимости в какой-то мере устаревшее умение. И большинство тестировщиков никогда этого не умели. Однако, если вы хотите продвижения своей карьеры, вам необходимо разобраться с тестированием совместимости до того, как двигаться дальше.

Soaking (замачивание) звучит как cooking (готовка) — в какой-то степени оно и есть. В игровой разработке поддисциплина «soaking» — та, в которой тестировщик на самом деле ничего не делает, только оставляет консоль или компьютер работать на определенное время. Для примера, тестировщик может оставить включенную на главном экране игру на три дня — а затем проверить, не вылетела ли она. «Soaking» необходимо потому, что временами утечки памяти или повторяющиеся ошибки могут нарушить стабильность игры при долговременной работе — и при этом незаметны при обычном тестировании. Такое тестирование обычно выполняет ведущий тестировщик.

Тестирование на соответствие (Compliance Testing) — один из видов тестирования, которые все, кажется, ненавидят. Но что же создало тестированию на соответствие такую плохую репутацию? До того, как игра поступит в продажу, она сначала должна пройти сертификацию. Этот процесс организуют сами производители железа (такие как Sony, Microsoft и Nintendo), которые должны быть абсолютно уверены, что игра следует всем методическим рекомендациям. До того, как ее разрешат отдать в продажу:

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

Другие общие требования соответствия:

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

Луиса однажды выбрали из огромной группы тестировщиков, чтобы обучить тестированию на соответствие. Это случилось во время затишья между двумя проектами. Каждому из тестировщиков были предоставлены старые сборки (предварительные версии) Gun, и мы целыми днями просматривали чеклисты соответствия, пытаясь разобраться с ними. В то время как некоторые вещи были по-настоящему простыми (вроде «игра должна встать на паузу при отключении геймпада”), другие мы называли “хардкором» (такие, как сетевой адаптер для PS2, который требовал драйвера на CD).

Тестирование локализации существует потому, что мы живем в мире глобальной экономики. «Локализация» включает в себя преобразование игры из одного региона в игру другого региона и обычно включает в себя перевод. Игра может быть сделана в Китае с помощью ирландских и австралийских разработчиков, а может быть сделана в Лос-Анджелесе, но экспортироваться на весь мир. Чаще встречается, когда игры сделаны в Японии и Корее, но выходят на Американском рынке. Например, Konami и Capcom — известные японские разработчики, а Gravity Interactive — бренд из Южной Кореи. Множество важнейших игр Nintendo в первую очередь делаются в Японии, а затем уже локализуются для Северной Америки. Как только игры экспортируются за границу, их необходимо переводить. Однако этот перевод временами полон ошибок. Это плохо для зарубежной игры, в особенности, если игра ставила себе задачу погрузить игрока в свое драматическое содержание.

Обычно игры локализуются для поставки в США, но Луису необходимо было заниматься тестированием локализации Call of Duty 2 для Китая и Японии. Его персонаж должен был умирать снова и снова, чтобы Луис смог проверить «цитаты при смерти» на экране на соответствие Японскому и Китайскому. Это было чистой пыткой — и он бы рад никогда больше этого не делать! Но все же, это работа, которую необходимо выполнять. И всегда есть кто-то, кто «наслаждается» этой задачей. В настоящее время в корейских MMO необходимо внимательно тестировать локализацию, тогда как японские игры теперь уже редко имеют такие проблемы.

«Веселое тестирование», которое показывают в рекламе на ТВ — это плейтесты, впервые упомянутые в Главе 2. В противоположность продуктовой разработке, такой как Microsoft Office, в игры должно быть «весело” играть. Просто “работает как положено” недостаточно. Геймдизайнеры должны задействовать то, что известно как “фан фактор”. В статье Gamasutra, названной “Тайны мудрецов: Левелдизайн», The Levellord из Ritual Entertainment объясняет:

Для того, чтобы превратить игру в веселую и интересную — надо немного больше, чем хорошие намерения и немного магической пыльцы. Это требует выдержанной, решительной и образцовой работы в команде. Кроме того, плейтесты — это не то, чем занимаешься, чтобы просто скоротать время и повеселиться. Лучшие плейтестеры могут разделять себя на 2 персоналии: игрок и профессионал.

1). Игрок: всегда готов увлечься.

2). Профессионал: всегда отслеживает игровые механики (такие как навигация, прицеливание, взаимодействие, окружение, физика, искусственный интеллект, цели).

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

Плейтесты включают в себя исследование всех возможных вещей и проверку того, что все они веселы. Это серьезная работа: достаточно одной неисправной игровой подсистемы, чтобы испортить весь игровой процесс. Сделаем пример из Call of Duty 3, игра в которой Луис работал как производственный тестировщик. Call of Duty 3 изменила серию CoD навсегда, представив транспорт. До CoD 3, весь транспорт на уровнях был просто декорацией — аксессуарами левел дизайна. С CoD3 джипы, мотоциклы и танки стали не только управляемыми, но и необходимыми стратегическими элементами.

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

Когда полировали мотоциклы, Луис решил, что сделал все, чтобы ими было весело пользоваться (Луис фанат гоночных игр, так что он считал, что отлично подходит для этой работы). Там было два различных мотоцикла для США и Японии. Изначально — оба немного медленные, да и управление посредственное. Чтобы мотоциклы были эффективны стратегически, в первую очередь они должны быть управляемыми — необходимо предоставить водителю некоторую степень свободы управления. Авария на мотоцикле в реальной жизни смертельна, но и в игре она может принести поражение и определенное унижение.

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

Юзабилити тестирование (тестирование удобства использования) — относительно недавний шаг в тестировании программного обеспечения. Что удивительно, учитывая его важность для удовольствия игрока. Microsoft большие фанаты юзабилити-тестирования — она научилась ему на собственном горьком опыте после того, как пользователи продолжали жаловаться на то, что машины на Windows намного сложнее использовать, чем Macintosh.

Юзабилити значит “легкой в использовании” — не “легкой” в смысле сложности. Но интуитивной: во взаимодействии с персонажами, использовании вещей, поиске пути или вождении транспорта. Когда определенный механизм в игре не имеет смысла (такой как невозможность двигаться и прицеливаться одновременно) — он также может быть записан как баг юзабилити. Возможно, игра задумана такой и в реальности ничего не сломано. Это неважно: механики геймплея должны иметь смысл и быть легки в использовании. Вы должны беспокоиться о прохождении игры, а не о схеме управления. Энергия, потраченная на отвлечения, снижает удовольствие, которое вы могли бы получить. Поскольку интерфейс игры отвечает за визуальный контроль и обратную связь, он изучается в процессе юзабилити-тестирования. Хотя это необычно для QA (которое обычно используется для поверхностного тестирования), все тестировщики в итоге сталкиваются с проблемами удобства использования (юзабилити). Вы даже можете столкнуться с ними сами — в играх, которые вы купили.

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

Как вы можете видеть, игровое тестирование намного более комплексное, чем может показать бездумная реклама на телевидении. Хотя тестирование игры — это навык, которому легко обучиться, понимание игровой индустрии и ее отношения к каждому типу тестирования — гораздо более сложная задача. Там где тестирование в QA издателя — это грубая сила (где ставка делается на количество участников), производственное тестирование может быть Джедайской техникой — с парой асов-тестировщиков, единственными, кто способен справиться с серьезными сетевыми проблемами. В следующей главе мы изучим, какие шаги должны быть сделаны до того, как вы начнете тестирование.