Баги в браузерных играх. Что такое баг и как с ним бороться? Туры по отельным районам, Tours Through the Hotel District

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

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

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

Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 - B, 62 - С и 4 - D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.

Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:

  • Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.
  • Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.
  • Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.
  • Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.
Если у кого-то возникнут вопросы по содержанию поста, с удовольствием отвечу.

Спасибо за внимание!

Когда что-то пошло не так.

В закладки

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

Это не тот случай, конечно

«Экран-убийца» в старых аркадах

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

Взять к примеру Pac-Man. Если дойти до 255 уровня, то с игрой начинают происходить довольно жуткие вещи: половина экрана забивается цифрами и игровыми спрайтами, из-за чего играть становится проблематично (для обычных людей; профессионалов подобные трудности редко смущают). За то, где и в каком количестве появляются бонусы, отвечает особая процедура. Данные она берёт прямо из номера уровня, и когда значение выходит за пределы байта (то есть на 256 этапе), игра немного ломается.

В Donkey Kong «экран-убийца» тоже присутствует, но немного в другом виде. Если дойти до 22 уровня, то Марио погибнет всего через несколько секунд после начала игры. Происходит это из-за того же байтового предела.

Время, отводимое на уровень, рассчитывается по определённой формуле: 10x(*номер уровня*+4). Если игрок попадает на 22 уровень, то формула выводит число 260, однако игра воспринимает значения лишь до 256, а потому 260 превращается в 4. За четыре секунды герой успеет разве что пробежать пару шагов, после чего умрёт.

В Duck Hunt на NES с «экраном-убийцей» можно было столкнуться, дойдя до 100 уровня. Тогда утки начинали вылетать из кустов с огромной скоростью и в больших количествах. Разумеется, подстрелить их было невозможно, и игра заканчивалась.

Комбо в Street Fighter II

Возможность наносить противнику множественные удары появилась ещё до Street Fighter, но именно вторая часть серии популяризировала систему комбо и заставила остальных разработчиков обратить на неё внимание.

Как всё произошло: во время тестирования игры и отлова багов главный продюсер Street Fighter II Норитака Фунамицу заметил, что на бонусном уровне (где нужно было раскурочить автомобиль) персонаж может нанести несколько дополнительных ударов. Для того, чтобы сделать это, нужно было очень строго выдержать тайминг, что само по себе было сложно.

Ошибку решено было не убирать из тех соображений, что вряд ли кто-то решится её использовать. Игроки, однако не отступили и выучили комбинации. Уже в Super Street Fighter II, который вышел в 1993 году, игра стала учитывать и вознаграждать каждый удар в комбинации, официально закрепив систему комбо в жанре файтингов.

Однажды я занимался отловом багов на бонусном уровне (с машиной) и заметил кое-что необычное. Пересмотрев запись, мы с командой обнаружили, что, если рассчитать тайминг, можно нанести дополнительный удар. Я подумал, что применить эту особенность никак не удастся, потому что тайминг был слишком мал и уловить его было очень сложно. Было решено оставить всё как есть.

Самое интересное, что это и послужило основой всех будущих игр. Потом уже мы сделали тайминги более комфортными и создали систему комбо. В SFII мы думали, что при хорошей игре можно нанести где-то четыре удара. А потом нам удалось нанести восемь. Баг? Вероятно!

Норитака Фунамицу

Продюсер Street Fighter II

Ермак в Mortal Kombat

Ермак из Mortal Kombat обязан своим появлением слуху. Дело в том, что после релиза первой части многие игроки стали утверждать, будто замечали в игре баг, при котором цвет одежды Скорпиона меняется с жёлтого на красный, а в полоске жизней появляется надпись Ermac.

Ермак в фильме Mortal Kombat: Annihilation

Сразу же было сделано предположение, будто это секретный персонаж, которого можно как-то разблокировать. В игровых журналах того времени даже появлялись изображения героя, которые, впрочем оказались поддельными. Никакого Ермака в первой части MK, разумеется, не существовало. Секретного персонажа с этим именем разработчики ввели лишь в Ultimate Mortal Kombat 3. Вот так, из-за слухов о баге на свет появился герой файтинга.

Ultimate Mortal Kombat 3

«Потерянный покемон» из Pokémon Red & Blue

Во вселенной Pokémon множество культовых монстров. Но есть один особенный - MissingNO. В отличие от всех остальных, он - баг. Появляется покемон после выполнения трёх последовательных действий. Сначала игрок должен пройти внутриигровое обучение, затем использовать покемона со способностью к полёту, чтобы добраться до острова Синнабар. Там нужно взять водного покемона и плавать вниз-вверх рядом с восточным берегом острова. После этого в игре случится баг и MissingNO появится.

Правда, нужно быть осторожным. Nintendo ещё в 1999 году предупредила пользователей, что любой контакт с секретным покемоном может повредить игровые сейвы. Также побочным эффектом встречи является то, что количество предметов, расположенных в шестом слоте рюкзака героя, увеличится до 128. Также в игре могут встречаться различные графические артефакты. MissingNO можно даже поймать и использовать в сражении. В покедексе тот получает номер 000. Само покемона имя расшифровывается как Missing Number (Потерянный Номер).

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

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

Информация на сайте Nintendo

Баги Ultima Online

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

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

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

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

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

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

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

Раф Костер

Ведущий дизайнер Ultima Online

Жонглирование противниками в Devil May Cry

Изначально Devil May Cry задумывалась как очередная часть Resident Evil (четвёртая, если точнее). У руля проекта стоял Хидэки Камия, который планировал сделать из игры быстрый экшен в готических декорациях, с динамической камерой и главным героем - сверхчеловеком. В итоге, концепция эволюционировала настолько, что создатели поняли: в серию Resident Evil игра больше не вписывается. Сюжет переписали, название сменили, а герою дали имя Данте.

Devil May Cry

Интересная часть началась, когда Хидэки Камия сел тестировать игру Onimusha: Warlords (вышла в 2001 году на PS2). Оказалось, что в игре есть баг, из-за которого противниками можно буквально жонглировать, нанося удары. Из финальной версии его, конечно убрали, но геймдизайнеру настолько понравилась эта идея, что он перенёс её в DMC. Так из-за бага у игр про демона Данте появилась своя фишка.

Изначально Devil May Cry должен был стать новой игрой в серии Resident Evil. Но он настолько не вписывался в серию, что превратился в DMC, а мы потеряли целый год разработки. Я думал, что, может быть, я облажался, а Capcom хотят меня уволить. Это бы объяснило то, что мне не разрешили работать над DMC2.

Хидэки Камия

Геймдизайнер Devil May Cry, в интервью сайту 1UP

Onimusha: Warlords

Чума в World of Warcraft

В сентябре 2005 года мир World of Warcraft был усеян костями игроков. Виной всему была чума, сотнями выкашивавшая несчастных искателей приключений. Началось всё с рейда Зул’Гуруб, в котором игрокам предстояло сразиться с Хаккаром Свежевателем Душ. У босса в запасе был трюк: он высасывал из героев кровь, восстанавливая свои силы. Однако свою кровь можно было заразить: игрок получал урон, но Хаккар также заражался и, в конечном счёте, погибал.

Хаккар Свежеватель Душ

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

Люди старались не подходить к городам и писали остальным: «Не возвращайтесь в город, а то снова это подхватите. Держитесь дикой местности». Это был своего рода карантин, благодаря которому выживали игроки.

Шейн Дабири

На исправление ситуации ушёл почти целый месяц. В итоге, у питомцев просто убрали возможность переносить болезнь, и чума закончилась. Сами разработчики говорят, что не жалеют о происшествии.

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

Шейн Дабири

Один из руководителей Blizzard

Лицо Дрейка в Uncharted 2

Изображение с размытым лицом Натана Дрейка из Uncharted 2: Among Thieves впервые появилось на имиджбордах. «Дрейкфейс», как его назвали пользователи, быстро обрёл популярность, стал мемом и своеобразным символом консольного гейминга. Якобы железо на PS3 устаревшее, графика мыльная, вот и получается такое.

На самом же деле, «дрейкфейс» - результат бага, который, при желании, можно воспроизвести. Достаточно зайти в режим создания роликов в разделе «Коллективная игра», выбрать любую запись матча, сразу же навести камеру на стену и нажать паузу в момент первой смерти. Потом просто летим к месту гибели персонажа и видим «дрейкфейс». Из-за бага в момент смерти лицо персонажа прогружается неправильно, вот и получается такой эффект.

Кричащий герой Heavy Rain

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

В самом конце игры главный герой, Итан, находит своего пропавшего сына и встречается лицом к лицу с таинственным убийцей. И тут в игре что-то ломается, а на экране появляется надпись «ШОН» и предложение нажать X. Герой начинает выкрикивать имя сына, снова и снова. Перед ним стоит убийца - «ШООООН», в него выстрелили из пистолета - «ШООООН», финальный бой на заброшенной фабрике - ну вы поняли. К сожалению, не ясно, как повторить баг, так что остаётся лишь надеяться на удачу.

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

Термин "баг"

Естественно, начать следует с рассмотрения самого термина, его этимологии и значения. Что такое баг? Почему он называется именно так? История эта довольно интересна, потому что данный термин произошел от английского слова bug, которое переводится как "жук". Но означает-то он ошибку - каким же образом сочетаются между собой насекомое и проблемы в компьютерном коде? Прямой связи, естественно, нет - просто который появился в среде программистов уже довольно давно и прочно закрепился за ошибками, которым удавалось пробраться в код даже с учетом полной проверки. Таким образом, баги проползают в финальную версию кода и выявляются только после запуска самой программы. Касательно этого термина есть еще достаточно много полезной информации, но теперь вы по крайней мере знаете, что такое баг. Идем дальше!

Классификация

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

Исправление ошибок

Процесс разработки программ, в том числе и компьютерных игр, состоит не только из написания кода. Значение слова "баг" намекает на то, что данная ошибка умудрилась пробраться не через один слой защиты. Так что же позволяет отловить 99% всех багов? Ответ прост - это этап тестирования. Когда программный код написан, он отправляется на проверку специальным профессиональным тестировщикам, которые запускают его и проверяют на наличие ошибок. Роль тестировщика не менее важна, чем роль программиста, и если баг пройдет в релизную версию продукта, то вина одинаково будет лежать как на человеке, который совершил эту ошибку, так и на том, кто ее не заметил при проверке. К счастью, 99% багов фильтруются в процессе такой проверки. Но что же происходит, если какому-то из них все же удается ускользнуть?

Баги в релизах

99% - это очень много, но все же 1% также является существенным, особенно если речь идет об ошибках. И если они попадают в релизный продукт, который продается и попадает в руки к клиенту, то здесь уже компании-производителю приходится брать на себя ответственность. Чаще всего проблема решается очень оперативно - как только игроки выражают свое недовольство, специалисты тут же занимаются делом. И через некоторое время выходит патч (от английского patch - "заплатка"), после установки которого проблема решается автоматически.

Отчеты о багах

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

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

Как найти баги в играх?

Ответ мастера:

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

Чтобы найти баги в игре, начните с базового теста. Он отобразит работоспособность игрового движка. Его, в принципе, нужно производить на самых ранних стадиях разработки игры. Суть проверки – найти ошибки, которые приводят к «выбрасыванию из игры». Такого типа ошибки следует находить в первую очередь, потому что именно они отбивают всю охоту играть дальше.

Проверьте игру на нескольких компьютерах, которые имеют различные параметры. Важно, чтобы на всех ПК были разные видеокарты, например GeForce и Radeon. А еще нужно тестировать игру на разных видах операционных систем, чтобы приспособить ее к различным условиям.

Теперь протестируйте гейплей для обнаружения багов в игре. Если игра первый тест прошла и работоспособность движка вас устраивает, то можно внимательно изучить разработку принципов и баланса игры. Например, если ваша игра похожая на Dead Space, то обязательно оттестируйте все виды оружия и «фишки» разработчиков. Когда какие-то из них дублируют друг друга или вообще лишние, то их нужно пересмотреть или доработать. Особое внимание нужно уделить проходимости игры, чтобы ее можно было пройти даже на самых последних уровнях.

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

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

Вы уже освоили основные техники тест-дизайна? Отлично! Значит, Вы – квалифицированный тестировщик.

Как научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники?

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

Разумеется, техники надо знать. Но для осмысленного, а тем более творческого их применения требуется ещё кое-что:

Нужны дополнительные профессиональные навыки.

Этот тренинг нацелен на формирование у тестировщика специальных навыков:

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

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

Откуда берутся пропущенные баги, которые тестировщик “не заметил”? Почему не заметил? Техники не виноваты. В них ничего не говорится о том, как надо проверять результат. Просто не хватило наблюдательности.

Почему в продуктив попадают баги, для которых тестировщик “не придумал” подходящего теста? Техники не виноваты. Просто неверно выбрана модель или техника применялась не там и не так.

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

Но там не написано главного – как понять, что вы нашли баг? Как его узнать? Как понять, правильно или неправильно работает программа? Говоря “профессиональным” языком – тема оракулов не раскрыта.

Наконец, как понять, правильно или неправильно вы применяете ту или иную технику? Тема оценки полноты покрытия не раскрыта тоже.

На этом тренинге мы будем учиться:

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

Кроме того, мы освоим профессиональную работу с уже обнаруженными багами:

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

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

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

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

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

Программа тренинга

День первый

1. Подготовка инфраструктуры, знакомство – 30 минут

2. Тестирование учебной программы (упражнение и разбор), обсуждение на тему «Что важнее – техники или навыки?» – 60+15 минут

3. Тестирование новой программы, искусство задавания вопросов (упражнение и разбор) – 60 минут

4. Что делать, когда ты нашел баг? Глобализация и локализация (демонстрация и обсуждение) – 45 минут

5. Искусство описания багов (упражнение и разбор) – 60 минут

6. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? – 45 минут

7. Моделирование: умение смотреть на программу под разными углами (упражнение и разбор) – 45 минут

8. Тестирование юзабилити: поселите у себя в голове персонажей (упражнение) – 30 минут

День второй

1. Стратегия тестирования (обсуждение) – 45 минут

2. Сравнение двух программ: какая лучше? (упражнение и обсуждение) – 60 минут

3. HICCUPPSF: эвристики построения оракулов (демонстрация, упражнение и разбор) – 15+60 минут

4. Построение тестов для сложной функциональности (упражнение и разбор) – 60 минут

5. Тест-кейсы, чеклисты, тестирование методом свободного поиска – в каком соотношении смешивать? (обсуждение) – 30 минут

6. Тестирование методом свободного поиска (упражнение и разбор) – 60 минут

7. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? (обсуждение) – 30 минут

8. Автоматизация тестирования (демонстрация и обсуждение) – 45 минут

9. Завершение курса, подведение итогов – 30 минут

В этом тренинге по согласованию с Майклом Болтоном используется методика и упражнения из всемирно известного тренинга Rapid Software Testing. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.