Перевод статьи «Test smart: how to explore a product like Sherlock?».
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 17.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Помните шляпу Шерлока? Легендарный детектив Шерлок Холмс — персонаж, созданный Артуром Конан Дойлом — больше всего запомнился тем, как раскрывал загадочные дела в лондонском тумане, попыхивая трубкой и… нося свою знаменитую шляпу. Со временем она стала стереотипным головным убором детективов, расследующих самые сложные дела.
В работе нам постоянно приходится примерять разные «шляпы». Продакт-оунеры, разработчики, дизайнеры и QA-инженеры легко переключаются между ролями, когда появляются новые задачи и вызовы. Но именно тестировщики чаще всего надевают воображаемую шляпу детектива. И, честно говоря, если вы хороший QA, она вам абсолютно точно подойдет.
Я начинала карьеру в тестировании как manual-тестировщик — или, точнее сказать, как human QA Engineer. Спустя несколько лет я также освоила основы автоматизации на Gherkin, помогала разработчикам выбирать тесты для автоматизации и регулярно следила за состоянием автотестов в CI/CD-пайплайнах. Однако основной мой фокус оставался на техниках human-driven тестирования и развитии общей стратегии тестирования в команде — как для ручных, так и для автоматизированных проверок на разных уровнях продукта.
Сейчас я каждый раз удивляюсь, когда слышу из сообщества, что manual-тестировщики якобы больше не нужны. Я не воспринимаю такие заявления как личное оскорбление. Но всё же возникает вопрос: действительно ли мы готовы доверить инструментам оценку юзабилити, UX и доступности, поиск edge-кейсов и UI-глитчей, а также исследование продукта так, как это делает человек?
Эксперты индустрии подчёркивают, что human-driven техники тестирования остаются важной частью разработки продукта. Однако я вижу, что некоторые известные компании слишком полагаются на автоматизацию и игнорируют исследовательские подходы. На мой взгляд, это может негативно сказаться на качестве продукта. В одной из недавних статей я уже писала о рисках чрезмерной зависимости от автоматизации. А после нескольких обсуждений на LinkedIn решила подробнее рассказать об одной из самых интересных техник ручного тестирования — исследовательском тестировании.
Ручное тестирование всё ещё живо?
Для начала стоит задать простой вопрос: нужно ли сегодня ручное тестирование? И если да — почему? Прежде чем скептики начнут бросаться в автора помидорами, уточню: да, техники тестирования, основанные на работе человека (human-driven), по-прежнему важны. Без навыков исследовательского тестирования QA-специалисты легко могли бы стать ненужными — их место заняли бы инструменты и искусственный интеллект. Но пока этого не произошло.
К такому выводу я пришла после выступления Сью Аткинс «В защиту ручного тестирования» на TestBustersNight, которое организовал Рудольф Грётц. Сью подчеркнула, что мы всё ещё не готовы полностью передать все виды тестирования инструментам на базе ИИ. Её доклад также вызвал интересную дискуссию: а корректно ли вообще называть работу тестировщика «ручным тестированием»? Возможно, более точным был бы термин «тестирование человеком» — вариант, который ранее предложил Джулиан Харти.
Не поймите меня неправильно: я выступаю за сбалансированный подход к тестированию. Тестировщик в гибкой команде должен уметь применять методы тестирования, основанные на человеческом анализе, автоматизировать отдельные проверки или работать над автоматизацией вместе с разработчиками. Однако у инструментов и машин есть свои ограничения — им не хватает креативности, эмпатии и интуиции.
Автоматизированные тесты вряд ли обнаружат пограничные случаи, о которых разработчики или дизайнеры просто не подумали — так называемые «нештатные» сценарии. Они также не способны глубоко оценить пользовательский опыт и качество интерфейса с точки зрения характеристик качества продукта (см. ISO 25010: Системная и программная инженерия). В этих областях гораздо лучше проявляет себя тестировщик-человек. Поэтому существующие инструменты всё ещё не могут исследовать продукт на том же уровне, что и люди.
«Автоматизированный тест не скажет вам, что система работает медленно, если вы заранее не указали ему это проверять. Он не сообщит, что окно оставляет постоянную тень, что каждая вторая запись в базе данных повреждена или что ложные значения возвращаются как истинные — если не знает, где искать и на что обращать внимание. Конечно, вы можете заметить проблему, когда будете разбирать огромные массивы данных, которые он собрал. А значит, мы снова возвращаемся к исследовательскому тестированию».
Итак, давайте теперь подробнее поговорим об исследовательском тестировании — и о детективной шляпе.
Коротко об исследовательском тестировании
Исследовательское тестирование во многом строится на человеческой креативности и любопытстве. В отличие от сценарных проверок, здесь нет заранее подготовленного тестового сценария — тестировщик изучает продукт и ищет проблемы прямо в процессе работы. Такой подход позволяет заметить поведение системы, которое могут пропустить формализованные тесты, например сквозные проверки. Именно так часто обнаруживаются пограничные случаи, проблемы пользовательского опыта и различные интерфейсные сбои.
Как отмечает Джеймс Линдсей:
«Исследовательскому тестированию не нужен заранее подготовленный сценарий. Тестировщик сам решает, какие действия выполнять в каждый момент времени. Выбор того, на что обратить внимание, определяется не готовым планом, а возможностями и обстоятельствами. В процессе работы тестировщик постоянно принимает решения: что попробовать дальше, какими средствами проверить результат и как интерпретировать происходящее. Если что-то выглядит подозрительно, это исследуется глубже — проверяются слабые места, пробуются разные комбинации действий. Иногда именно такие эксперименты раскрывают систему с неожиданной стороны. Исследовательское тестирование прежде всего сосредоточено на рисках».
Исследовательское тестирование более спонтанное и менее формализованное, чем сценарное, однако это не означает отсутствие дисциплины. Чтобы проводить его эффективно, необходима определённая структура. Обычно такие проверки выполняются с конкретной целью (например, «проверить новую функциональность») и проходят в формате ограниченных по времени сессий. Тестировщики могут использовать специальную карточку задачи (charter), в которой фиксируют наблюдения и результаты.
Чтобы исследовательское тестирование действительно давало результат, его нужно проводить регулярно. Мартин Фаулер отмечает, что если в команде вообще нет такого тестирования, это плохой знак: «Даже самые лучшие автоматизированные тесты по своей сути являются сценарными — а этого недостаточно». По моему опыту, стоит выделять время для сессий исследовательского тестирования хотя бы раз в неделю.
Проводить такие проверки могут QA-инженеры, разработчики, владельцы продукта и дизайнеры — как индивидуально, так и вместе. В гибких командах каждый участник может внести вклад в качество продукта: исследовать систему, находить проблемы и делиться своими наблюдениями с командой.
Исследовательское тестирование можно проводить и в парах — по аналогии с парным программированием. Как пишут Мария Гуцук и Сивамурти Бозе, при парном исследовательском тестировании участники выполняют две роли. Один человек выступает в роли «водителя», другой — «навигатора»:
«Водитель — это человек, который непосредственно работает с приложением. Он выполняет действия, наблюдает за системой и задаёт вопросы по ходу тестирования. Навигатор в это время выступает наблюдателем: он предлагает, что проверить дальше, и записывает шаги или найденные проблемы. Участники могут периодически меняться ролями».
По моему опыту, ещё больший эффект дают командные сессии исследовательского тестирования — так называемые bug bash. Чтобы находить дефекты как можно раньше, команда может проводить такие проверки сразу после того, как разработчики реализовали новую функциональность в своей среде.
Ниже приведён пример карточки задания для условной командной сессии исследовательского тестирования.
«Привет! Сегодня наша цель — посмотреть на продукт глазами пользователя и проверить пользовательские сценарии на портале Amazing Portal. Используйте свои навыки и интуицию, чтобы найти как можно больше визуальных или функциональных проблем. Если вы обнаружите баг или несоответствие в пользовательском опыте, зафиксируйте его в карточке тестирования. Ниже приведены лишь общие ориентиры — сценарии вам придётся придумывать по ходу работы.
Задание 1
В качестве пользователя просмотрите товары на портале Amazing Portal.
Задание 2
В качестве пользователя оформите заказ на товары A, B, C и D.
Задание 3
Как пользователь, обновите данные в своём профиле.
Задание 4
В качестве клиента исследуйте другие разделы портала Amazing Portal.
После завершения сессии все найденные проблемы стоит задокументировать и обсудить в команде. Иногда результаты такой проверки могут привести к полной переработке функции. Это может быть болезненно для команды, но в итоге выигрывают все: разработчикам и дизайнерам приходится меньше переделывать на поздних этапах, а пользователи получают более качественный продукт.
Я уверена, что никакие инструменты на базе ИИ не смогут заменить человеческую креативность, эмпатию и интуицию в тестировании. Именно поэтому подходы, основанные на работе человека — такие как исследовательское тестирование — по-прежнему остаются востребованными. Их должны активно использовать все участники команды: разработчики, дизайнеры, владельцы продукта и QA-инженеры (если вашей команде повезло иметь такого специалиста 😉).
Если применять исследовательское тестирование на самых ранних этапах разработки, оно помогает выявлять возможные пограничные случаи и проблемы продукта — как видимые пользователю на уровне интерфейса, так и скрытые дефекты на уровне API и серверной логики. Это может значительно повлиять на качество продукта, снизить затраты на переделки в долгосрочной перспективе и помочь команде сдвинуть стратегию тестирования влево.
Так что продолжайте исследовать продукт и не забывайте с гордостью носить свою «шляпу Шерлока».