Александр Молодцов

Старший специалист по тестированию в ГК Юзтех

Всем добрый день!

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

Ну что ж, давайте продолжать, ведь мне ещё есть чем с вами поделиться :)

Сценарий 3. Лейтенант Коломбо — мужская шляпа федора

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

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

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

Что же я предлагаю? Я предлагаю найти отдельный функционал, отдельный элемент интерфейса, один какой-то модуль и задуматься – скорее всего там есть баг. Есть он там или нет – это вопрос риторический. У нас стоит цель – найти интересный баг и не пропустить его в прод. Нам нужно. И мы начинаем копать вокруг этого функционала / интерфейса / функционального модуля.

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

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

Сценарий 4. Эркюль Пуаро — котелок

Эркюль Пуаро — бельгиец по происхождению. Но из-за ранения переехал на лечение в Англию, где впоследствии остался жить и вести свою частную практику. Он является персонажем высокомерным, который не стесняется говорить: «Я самый гениальный человек на планете». Но на самом деле под маской этого высокомерного человека он скрывает свою основную слабость – он не может повлиять на ситуацию и вынужден только собирать информацию, которая идёт гораздо быстрее него.

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

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

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

Данный сценарий немного отступает от канонов построения исследовательского сценария, так как я предлагаю вам поставить мысленный эксперимент.

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

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

Мой пример – интеграция сторонней системы поддержки пользователей в форме чата в мобильном приложении. Какие проблемы могли возникнуть там?

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

2. В интерфейсе приложения был реализован счётчик входящих сообщений в главном меню. Сообщения приходили, но сам счётчик не обновлялся

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

Сценарий 5. Джессика Флетчер — женская шляпа

Сам персонаж не очень популярен на территории России. Она — писатель по профессии. Детектив-любитель.

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

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

Как же это применить в работе тестировщика. Если вам команда говорит: «Да нет, не надо проверять, там всё хорошо, там всё работает в этой части интерфейса» – знайте, что там совершено преступление, там кого-то убили. Да, тестировщик часто проводит смоуки, регрессы, но я предлагаю вам не полениться и просто так пройтись по функционалу тестируемого продукта, в котором вы на сто процентов уверены. На самом деле, когда вы проводите скриптовое тестирование, то вы уже идёте по приложению с замыленным глазом – вы проходите очень много раз один и тот же сценарий, одни и те же проверки в своём чек-листе и можете чего-то не заметить. Вы тестируете строго по ТЗ.

Причин возникновения проблем может быть несколько. Самая частая – это какая-то ошибка при сборке билда или накатки обновления на стенд. Мало ли, может у нас собралась не та ветка в билде. Конечно, Джессика сразу натолкнётся на данную проблему. Или тестирование с применением автотестов не выявит сдвиг изображений в интерфейсе программы.

Любой стабильный функционал ПО рано или поздно может отказать. Главное – это вовремя провести диагностику.

Система чатов в большинстве приложений не вызывает никаких сомнений в простоте их реализации. В мобильном приложении на iOS 13 появились четыре новых пиктограммы: Шотландии, Англии и ещё двух. И при отправке их в чат у всех получателей сообщения вылетало приложение. Краш на ровном месте. Казалось бы, проверка чата довольно простая: сообщение ушло – сообщение пришло, и в этих пиктограммах ничего подозрительного не было. Но смайлы допустили краш.

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

Сценарий 6. Комиссар Рекс — полицейская фуражка

Комиссар Рекс является главным персонажем шоу Рекс. Он – напарник детективов. Рекс – собака-полицейский.

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

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

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

Инструменты быстрых заметок сэкономят очень много времени во время проведения самого исследовательского тестирования. В роли любого из детективов мы делаем краткие текстовые заготовки багов, а уже дальнейшей локализацией занимается наш главный детектив – Шерлок Холмс с его дедуктивным методом. Не зря же мы его выделили в самом начале? (Блокнот).

Также можно использовать в своей работе различные плагины и расширения для проверки веб-страниц. Находя мелкие улики – баги с низким приоритетом, можно найти интересные закономерности, которые могут привести к более серьёзным проблемам работы системы. (Яндекс Спеллер, Майнер). Валидаторы страниц – тоже один из очень эффективных инструментов, которые могут помочь тестировщикам в не очень понятных ситуациях. 

Предлагаю вам надрессировать вашего комиссара Рекса интересными программными решениями и поставить в качестве вспомогательного  компаньона к основным исследовательским сценариям. 

Заключение

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

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

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

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

И в конце статьи я хочу, чтобы каждый задал себе вопрос: А я применяю исследовательское тестирование в своей работе?