Home

Автор: Джефф Найман (Jeff Nyman)

Оригинал статьи: http://testerstories.com/2016/03/the-art-of-attention-to-detail-in-exploratory-testing/

Перевод: Ольга Алифанова

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

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

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

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

Тут стоит отметить, что именно в исследовательском тестировании подход "задеть лампу", как правило, наиболее эффективен (см. примечание в конце статьи). Недавно я убедился в этом, тестируя Star Wars: The Old Republic (сокращенно SWTOR) для Bioware Austin. Приведу пример.

Исследовательское тестирование: погружение в мир пользователя

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

Вообще я считаю, что исследовательское тестирование особенно результативно, если основано на "персонах" пользователей. Крайне рекомендую книгу Джеймса Уиттакера "Исследовательское тестирование: советы, туры, техники тест-дизайна", которая довольно подробно освещает этот вопрос. Мой пример основан на играх, но техники сработают для любого приложения.

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

Я болтался по одной помоечной планете под названием Коррибан (если вы играете в "расширенной вселенной" – теперь она называется Морабанд) и наткнулся на склеп Аюнты Полл. Осматриваясь, в одном из помещений склепа я взглянул на потолок и увидел дыру в крыше.

Через дырку была видна какая-то планета – может, луна – и я остановился, прикидывая, на какую точку поверхности выходит эта дырка. Я открыл карту, чтобы определить, где именно я нахожусь:

Сюрприз, карта сообщила мне, где я конкретно, но мне-то было интересно, где я по отношению к поверхности планеты! Поэтому мне пришлось переключиться в режим "мир", и вот что я увидел:

На картинке кругами отмечено мое местоположение относительно склепа, и относительно планеты в целом. Я заметил, что я стою примерно в районе буквы "а" в слове "Dark" надписи "Valley of the Dark Lords" (отнюдь не курорт, можете мне поверить). Я выбрался из склепа и отправился искать эту точку. Как видно на картинке, никакой дыры не наблюдается:

Я убедился, что стою в нужном месте, именно над предположительной дырой в склепе:

На картинке видно, что я стою точно над буквой "а" в слове "Dark", только снаружи, а не внутри склепа. Я нахожу нехватку дыры тревожным знаком (это была шутка про Дарта Вейдера, кто понял – тот молодец). Для вящей уверенности я переключился на вид сверху: дыра отсутствует.

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

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

А я мог ответить, что я и сделал, что когда я исследовал другие области мавзолея, я заметил заглушки на некоторых шахтах, ведущих наверх:

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

Проблемы вовлеченности и функциональность

Исследуя продукт, я также заметил вот что:

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

Ага, тут я твердо стою на ногах. Возможно, что-то не так с уровнями. Отойдем-ка от платформы и ступенек:

Мда, я снова левитирую. Ладно, отойдем подальше:

Теперь я снова стою на земле. Об этом надо сообщить, это слегка нелогично. Направимся к зеленому проходу:

Упс, я снова левитирую! Но я стою довольно далеко от ступенек – на самом деле так же далеко, как и на прошлом изображении (где я не стремился взлететь), просто в другом направлении.

Исследуя продукт, я обнаружил, что уровни в этом помещении поломаны. Кстати, в игре вы можете контролировать камеру, и такие вещи легко упустить, потому что обычно камера смотрит сверху и со спины – не так-то просто разглядеть, касаются ли ноги персонажа земли. Чтобы увидеть положение ног, нужно повернуть камеру.

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

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

Если вам интересно, как выглядит охота на датакроны – посмотрите на YouTube.

Итак, мое исследование привело меня к умозаключению, что расплывчатые жалобы на "чересчур высокую сложность джамп-паззлов", возможно, можно уточнить путем поиска вариаций в отображении персонажа по X и Y-осям.

Исследуйте модель

Отвлечемся от игр и потренируемся немного. Посмотрите на скриншот:

Что приходит вам в голову, когда вы изучаете эту статичную картинку? Вас что-нибудь тревожит? Как бы вы исследовали эту функциональность, если бы сайт был у вас под рукой?

Как правило, тестировщики сразу замечают, что поле количества представляет из себя или выпадающее меню, или спиннер - а может, и то, и другое одновременно (на самом деле так оно и есть – количество можно выбрать из дропдаун-списка, а можно увеличить и уменьшить при помощи кнопок). Это сразу же наводит на беспокойные мысли. Что, если я хочу заказать несколько сотен единиц? Да даже если не сотен – даже 50 штук уже глуповато смотрится в выпадающем списке.

Второй бросающийся в глаза момент – это кнопка "Добавить в корзину". Тестировщики сразу думают о том, что кнопка должна стать неактивной, если количество равно нулю. Наверное, в этом случае должно отображаться информационное сообщение. Возможно, кнопки вообще не должно там быть, если количество отсутствует. Поле "Количество" должно показывать 0 и не поддаваться редактированию, если товара нет в продаже.

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

Я также ожидаю, что при отсутствии товара в продаже появится какое-либо сообщение об этом. Как пользователь, я не обязан замечать, что в поле количества стоит ноль, или что кнопка "Добавить в корзину" испарилась.

Хм, а "Техническая спецификация" что, будет у ЛЮБОГО продукта? Это ящик с водой! Для него есть "техническая" спецификация? Нет, может, она и есть, но как исследователь я тут же начинаю размышлять, что это значит. Может, в ней указаны размеры бутылки или ящика? Или объем воды?

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

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

Изучайте пространство задачи

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

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

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

Всегда исследуйте!

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

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

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

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

Примечания:

Выражение "задеть лампу" – жаргон мультипликаторов студии Disney. Выражение родилось после одного эпизода из истории компании. Он связан со сценой в фильме "Кто подставил кролика Роджера", в которой Эдди Валиант пытается распилить наручники, которыми он прикован к Роджеру. В комнате, где он их пилит, с потолка свисает лампа, и Эдди постоянно задевает ее головой. В результате свет от лампы летает по комнате, как и тени героев.

Сцена на YouTube: https://www.youtube.com/watch?v=_EUPwsD64GI

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

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

Обсудить в форуме