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

В закладки

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

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

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

Было бы неверно предполагать, что глитчи и баги появились лишь в современных играх. Они с нами почти с самого зарождения игровой индустрии. Самыми ранними примерами можно считать баги аркадных игровых автоматов, называемые 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 - "заплатка"), после установки которого проблема решается автоматически.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День первый

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. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.

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

Советы эти очень простые и проверены многолетней практикой многими QA инженерами, с которыми я обсуждал как они ищут и находят баги:



Фокусируйтесь на поиске багов
Все время держите в голове мысль "так, где-то здесь баги и я должен их найти сейчас ". Баги там точно есть, и вы их обнаружите.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успехов вам в поисках:)

Описав методику систематического поиска багов по Джеймсу Уиттакеру (James A. Whittaker)

Методика туров

Приложение - незнакомый город.
Тестировщик - турист.

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

Как пользоваться методикой

Выбрать тур из списка ниже.
Изучить его цели.
Поставить таймер на 2 часа (час, полчаса).
Провести исследование системы строго по целям тура. Ни на что не отвлекаясь, только “миссия” тура.
При необходимости повторить.

В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты - https://dadata.ru .

Отправляемся в путь!

Туры по деловому центру, Tours of the Business District

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

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

Тур по деловому центру фокусирует внимание на главных частях вашего приложения и показывает сценарии их использования вашими клиентами.

Туры по историческим районам, Tours Through the Historical District

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

В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

• унаследованный код (legacy code);
• функции, созданные в предыдущих версиях;
• исправления багов.

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

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

Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

Туры по туристическим районам, Tours Through the Tourist District

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

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

Туры по отельным районам, Tours Through the Hotel District

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

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

Туры по захудалым районам, Tours Through the Seedy District

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