Какие баги есть в игре. Всё сломалось: легендарные баги в видеоиграх. Кричащий герой Heavy Rain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День первый

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

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

Инструкция

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

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

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

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

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

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

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

Инструкция

Для просмотра ошибок системы откройте: «Пуск» - «Панель управления» - «Администрирование» - «Просмотр событий». У вас будет возможность просмотреть разделы: «Приложение», «Безопасность» и «Система», в которых будут записаны все сообщения об ошибках.

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

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

Как восстановить систему при наличии тех или иных ошибок? На практике самым надежным вариантом является переустановка Windows поверх уже установленной системы в варианте «Обновление». В этом случае у вас сохраняются все установленные программы и настройки, при этом обновленная система избавляется от большого количества накопившихся ошибок. Подобную переустановку не стоит делать слишком часто, но порой она становится самым быстрым способом восстановления нормальной работы компьютера.

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

Не забывайте время от времени дефрагментировать диск, на котором установлена операционная система. Высокая степень дефрагментации данных существенно замедляет работу компьютера. Для дефрагментации откройте: «Пуск» - «Все программы» - «Стандартные» - «Служебные» - «Дефрагментация диска».

Описав методику систематического поиска багов по Джеймсу Уиттакеру (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

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

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

Шаги

Выявление глюков

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

• Прочитайте краткий обзор игры. Если он достаточно подробный, то это может вам помочь.
• Спросите друга, который играет в эту же игру. Возможно, они или она знает ответ на ваш вопрос.
• Зайдите в интернет и проверьте форумы игры. Посмотрите, если кто-то еще сообщил об этом глюке. Или, сделайте поиск “Х глюк” в поисковой системе, если вы думаете, что это известный баг.

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

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

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

   Типичные зоны и действия глюков

   Существуют более-менее стандартные зоны, где могут возникнуть глюки. Если вы пытаетесь их найти, то посмотрите на подсказки ниже.

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

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

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

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

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

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

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

      • Большинство глюков появляются на территориях, которые не были предназначены для игры.

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

      • Если смерть в игре вам не страшна, то возможно, вы найдете несколько забавных глюков!

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

   Повторный поиск глюка

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

   • Wii никогда не получает обновления, так что, если вы ищите неменяющийся глюк, то играйте на Wii. Тем не менее, большинство выступов в играх Wii - это пейзажи, и вы не сможете на них взобраться.
   • Научитесь прыгать точнее. Приземление на нужную цель – это ценное умение. Повторяющиеся прыжки (в стиле зайца), иногда, могут привести вас к одному из глюков.
   • Если препятствие недоступно, то попробуйте подняться по выступу, вместо попыток взобраться по центру.
   • Попробуйте подвинуть другого персонажа или животного на какой-нибудь объект и, потом, пройдите через этого человека или зверя. Используйте персонажа или животного для того, чтобы взобраться на что-нибудь, и для других целей.
   • Большинство объектов – это пейзажи. Если вы попробуете спрыгнуть с крыши здания на другую сторону, то скорее всего, вы начнете через него падать.
   • Используйте специальные прыжки, когда пытаетесь прыгнуть дальше, чем обычно. Если вы пытаетесь осуществить прыжок с разбегом на какое-нибудь место, то, после каждого прыжка, позвольте ему перезарядиться и проверяйте – помогает ли вам это.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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