«В предыдущем посте я описал тест-кейсы, которые воплощают требования, и те, которые не воплощают. Этому я научился у Джеймса Линдси. Он пишет в книге «Почему исследованиям есть место в любой стратегии«:
Некоторые тесты предназначены для поиска рисков. Они делаются «на лету» и проводятся один раз. Некоторые предназначены для того, чтобы рассказать нам, где можно сэкономить. Они делаются один раз, а выполняются вечно. Вам нужны оба вида: они говорят вам о разных вещах.
Тесты, ориентированные на ценность, основаны на требованиях — на вещах, в ценности которых мы уверены, они предписаны (в смысле написаны ранее).
Тесты, ориентированные на риски, являются исследовательскими, они основаны на наших решениях в данный момент, мы ищем сюрпризы и решаем, как к ним относиться.
С годами я заметил одну вещь: исследовательских тестов проводится гораздо больше, чем мы считаем нужным. Это скрытая, но необходимая часть работы. Мы делаем это, но не целенаправленно.
Сегодня я хочу доказать, что стоит быть более внимательным к исследовательскому тестированию. Однако прежде чем перейти к делу, я хочу объяснить, что такое исследовательское тестирование, потому что до сих пор существует множество заблуждений.
Что такое исследовательское тестирование
Во время сессии исследовательского тестирования на NewCrafts 2024 Элизабет Загроба дала следующее определение:
«Исследовательское тестирование — это когда вы тестируете и одновременно думаете о том, что вы делаете, и имеет ли это значение».
Это постоянное размышление о том, что вы делаете, является ключевым компонентом исследовательского тестирования. Вы взаимодействуете с приложением, открываете для себя что-то новое и принимаете решения, что делать дальше, основываясь на этих открытиях.
Или, как резюмирует Маарет Пюхяярви в своей книге «Основы исследовательского тестирования«:
«Исследовательское тестирование — это подход к тестированию, в центре которого стоит обучение. Разработка тестов и их выполнение образуют неразрывную пару, где приложение и фича, которую мы тестируем — это наше внешнее воображение.
Некоторые люди, прочитав эти (или другие) определения, могут составить следующее представление об исследовательском тестировании: исследовательское тестирование — это кто-то копается в приложении, надеясь обнаружить ошибку. Хотя технически это и есть исследовательское тестирование, это не очень эффективная его форма.
В этой картине исследовательского тестирования отсутствуют две важные вещи:
- Исследовательское тестирование — это приобретаемый навык
- Исследовательское тестирование может быть настолько «техническим», насколько вы захотите
Это приобретенный навык
На протяжении десятилетий тестировщики собирали эвристики, которые помогали им направлять тестирование:
- Шпаргалка по эвристике Элизабет Хендриксон
- Элементы эвристической стратегии тестирования RST
- FEW HICCUPS Майкла Болтона
- Микроэвристика Алекса Шлейдебека
- Эвристика анализа, дизайна и выполнения тестов из «Записной книжки тест-дизайнера”
Наличие этих списков эвристик — отличное начало, но их применение зависит от двух скиллов: 1) замечать то, что нужно замечать, и 2) выбирать правильную эвристику для применения. Ни то, ни другое не может быть сделано идеально. Вы не можете заметить всё.
Но вы можете пытаться делать это (замечать и принимать решения) довольно хорошо или довольно плохо. И в этом заключается невидимая сила исследовательского тестирования. Невидимая, потому что все это находится в голове человека, проводящего исследовательское тестирование. Как и любой другой скилл, исследовательское тестирование можно практиковать и совершенствовать. Это не то, что у одних людей получается хорошо, а у других — нет.
Оно может быть настолько «техническим», насколько вы хотите
Прежде всего, мне очень не нравится, как слово «технический» использовалось и используется для определения границ, особенно в тестировании. Если вы работаете в сфере технологий, в какой бы роли вы ни выступали, вы — технический специалист. Точка.
Аналогично, исследовательское тестирование всегда носит технический характер. Вы исследуете и оцениваете технологический продукт, как же иначе? И исследование дает вам возможность выбора.
Исследовательское тестирование может быть проведено на любой части приложения, в любом месте стека. Если вы когда-нибудь смотрели на фичу или на юнит-тест и говорили себе: «Интересно, что сделает эта фича, если я дам ей вот эти параметры…», добавляли тест с этими параметрами и запускали его, вы проводили исследовательское тестирование.
Таким образом, вы можете включать или исключать из процесса один или несколько уровней стека, сколько хотите. Вы можете протестировать одну фичу, весь стек, только бэкенд, фронтенд с моком сервиса и т. д.
Кроме того, любой способ взаимодействия с любой частью приложения является допустимым способом проведения исследовательского тестирования. Сам код, API, CLI, графические интерфейсы, конфиги, базы данных и т. д.
Так как же исследовательское тестирование может быть не техническим?
Как исследовательское тестирование связано с обычным тестированием?
Исследовательское тестирование — это изучение и открытие. Обычные тесты (автоматизированные или нет) строятся на основе этого изучения. Именно поэтому в предыдущем посте этой серии я сказал: «Разница между тест-кейсом и требованием состоит в открытии». Мы открываем что-то новое в ходе исследовательского тестирования и разработки требований. Требования и обычные тесты (тест-кейсы) являются результатом этих открытий.
Как говорит Вуди Зуилл в одном из своих Agile Maxims:
«Именно в процессе выполнения работы мы обнаруживаем работу, которую должны сделать».
Создание и исследование того, что мы создали, является ключом к обнаружению того, что мы должны создать. Это исследование и есть исследовательское тестирование. И как только мы узнаем немного больше о том, что мы должны создать, хорошо бы зафиксировать то, что мы узнали. Обычные тесты, особенно если они автоматизированы и выполняются в конвейере — отличный способ сделать это.
Как пишет Джеймс Линдсей в статье «Почему исследованиям должно быть место в любой стратегии«:
«Нам нужны исследовательские тесты. Они великолепны. Они рассказывают нам о рисках — неожиданных, непредсказуемых — которые существуют в системе. Исследовательские тесты — это немедленные, сиюминутные тесты. Риск известен — и вам не придется тестировать его снова, пока вы не устраните его и не напишете тест, который покажет, что риск исчез.
И Маарет Пюхяярви говорит о том же. В современном исследовательском тестировании исследование и автоматизация идут рука об руку. И тест-кейсы, независимо от того, являются ли они исполняемыми (то есть автоматизированными) или нет, являются результатом исследовательского тестирования.
Осмысленное проведение исследовательского тестирования
К этому времени вы, возможно, уже поняли, что вопрос не в том, проводите вы или не проводите исследовательское тестирование. Вы уже проводите его, независимо от того, называете ли вы его таковым или нет. Вопрос в том, делаете ли вы это осмысленно.
Когда вы намерены делать это? Проводите ли вы исследовательское тестирование на протяжении всего процесса разработки: проектирования, создания, тестирования и мониторинга? А что вы делаете осмысленно? Что работает у вас во время исследовательского тестирования, а что нет? Что можно улучшить?
По моему опыту, команды, которые осмысленно и целенаправленно занимаются исследовательским тестированием, регулярно исследуют то, что они создают, и то, что они уже создали — обычно превосходят те команды, которые этого не делают.»
