Думаю многие организации, руководители, менеджеры всегда ставят перед собой цель тестировать качественно и максимально быстро. И это действительно факт. Конкуренция на рынке постоянно растет, особенно если мы говорим с вами о ИТ сфере. Принцип того, что кто первый, того и тапки, что рынок настолько перенасыщен продуктами, и даже если взять мой любимый банковский сектор, то можно насчитать порядка сотен различных продуктов, но тем не менее действительно классных банковских продуктов будет от силы 10, и это те продукты, которые действительно не вызывают проблем у пользователей.<>
Для того, чтобы быть конкурентноспособным, нужно уметь быстро внедрять продукты на рынок. Скорость тестирования обычно достигается двумя способами:
- Автоматизация
- Отказ от формализации
И мы рассмотрим тему отказа от формализации, или, в данном случае, подход Experience-Based Testing.
Предыстория Experience-Based Testing
Изначально, понятие тестирования, основанного на опыте не было, первоначально существовало только Исследовательское тестирование (Exploratory testing), о котором впервые упоминает Сэм Канер еще в далеком 1987 году в книге «Testing computer software». Но постепенно, со временем появляются другие подходы к тестированию, основанные на опыте тестировщиков, которые в 2004 году международная организация IEEE в документе «IEEE: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society» объединяет в общий подход Experience-Based Testing.
Что же в себя включает Experience-Based Testing?
Стандартно (в том числе и в ISTQB), это 3 техники тестирования:
- Error Guessing (предугадывание ошибок)
- Checklist-based testing (тестирование на основе чек-листов)
- Exploratory testing (тестирование методом свободного поиска или исследовательское тестирование)
Немного расскажу о них.
Предугадывание ошибок
Достаточно сложная техника тестирования, которая требует хороших знаний тестируемого ПО. Суть техники заключается в возможности тестировщика выполнять тестирование только путем предугадывания дефектов, рисков или проблем в системе. То есть, вы уже 6-й год тестируете одну и ту же систему, помните еще те времена, когда система была старт-апом и вы не спали ночами, пытаясь ее внедрить, к вам бегут все аналитики, чтобы понять, как будет работать функционал. В таком случае эта техника тестирования для вас. Зачем писать тест-кейсы, тестировать весь функционал, если вы интуитивно знаете, где возникнут проблемы с системой.
Немного отступлюсь…
Года 4 назад у меня был такой знакомый, который тестировал систему 5 лет. Так вот на вопрос, почему он все еще сидит и тестирует ее, он отвечал, что ему нравится работать там, где он все знает. Но его тест-кейсы были просто черт голову сломит «великолепными». Каждый его тест состоял всегда из 3 шагов:
- Что то открыть
- Что то сделать
- Что то проверить
И все! Как сделать, как открыть, что вводить, где проверять, в общем приходилось садиться и изучать систему.
Но это лирика, вернемся к теме…
Тестирование на основе чек-листов.
Это достаточно часто распространенная практика, особенно для небольших организаций, в которой обычно не более 2-3 тестировщиков. Зачем писать достаточно большие и объемные тестовые сценарии, тратить на них уйму времени, когда можно просто описать основные проверки.
Визуально чек-лист выглядит вот так:
Исследовательское тестирование
Есть брать определение из ISTQB, то исследовательское тестирование характеризуется тем, что тестировщик одновременно изучает продукт и его дефекты, планирует работы по тестированию, проектирует и выполняет тесты и отчитывается о результатах. Тестировщик постоянно корректирует цели во время выполнения тестирования и готовит только высокоуровневую документацию. Именно такое определение дал Джеймс Уиттакер в книге «Exploratory Software Testing».
Итак, если мы более глубоко погрузимся в исследовательское тестирование, то мы поймем, что исследовательское тестирование невозможно спланировать. Тестировщик начинает тестировать систему и в зависимости от получаемых результатов планирует выполнение следующих тестов. При таком тестировании, в принципе, отваливается необходимость глубоко изучать документацию, проектировать детальные тестовые сценарии, готовить тестовые данные и другие виды активностей, связанных с подготовкой к тестированию по тестовым сценариям.
Если рассматривать тестировщика, как действительно специалиста, выполняющего сложную интеллектуальную работу, а не тупо шмякующего идя бездумно по шагам тест-кейса, что в последнее время встречается все чаще и чаще, то это действительно огромный труд и аналитическая работа, требующего определенного склада ума и желания узнать и познать все необъятное. Сейчас же специалисты по тестированию перестают думать, то ли не чувствуют ответственности, то ли хотят просто работать, как обезьянки и ни в чем не развивать себя. В общем картина удручает…
Лично я считаю, что работая по тест-кейсам и не прикладывая особо усилий на тестирования только «отупляет» тестировщика. Но при этом, всегда есть возможность даже при сценарном подходе к тестированию, отклоняться от тест-кейсов и проводить исследовательское тестирования.
Поэтому, исследовательское тестирование:
- Подчеркивает персональную свободу и ответственность тестировщика
- Показывает индивидуальность тестировщика
- Позволяет постоянно проектировать новые тест-кейсы по результатам работы
Очень подробно систематический подход к исследовательскому тестированию описывает Уиттакер, используя для этого подход с турами по различным объектам, таким, как «Тур по плохому району», «Музейный тур» и т.д.
Звучит смешно. Но это действительно так!
Методика исследовательского тестирования с помощью туров заключается в следующем. Ваше приложение, которое вы тестируете — это незнакомый город. Вы — турист. Ваша цель — выполнить конкретную задачу, которую вы себе ставите, тем самым исследуя ваш город (приложения).
Например, если вы берете методику «Музейный тур», то музей — это место, которое содержит большое количество различных старинных вещей, т.е. это старый код, который обычно часто остается нетронутым разработчиком. Тем не менее, он может содержать дефекты, которые тестировщик должен найти. Поэтому, задача тестировщика — определить те функции, которые уже очень долгое время не были подвержены изменениям и протестировать их. Ведь именно код разработчика, который был написан очень давно, может быть подвержен дефектам просто потому, что он уже давно забыт разработчиком и скорее всего на него уже никто не пишет даже unit тесты.
Очень подробно система туров Уиттакера рассматривается в этой статье Система туров исследовательского тестирования.
Таким образом, для того, чтобы проводить исследовательское тестирование достаточно иметь очень хорошее абстрактное мышление.
Но возникает вопрос. А действительно ли достаточно обладать большим опытом, чтобы проводить исследовательское тестирование?
Возьмем опытного тестировщика, который уже большое количество времени проводит тестирование различных систем. Чем руководствуется в таком случае тестировщик? Опытом, интуицией или техниками тест-дизайна? Очень часто я сталкивался с тестировщиками, которые очень хорошо знали систему. Они понимали, где и как может возникнуть проблема, дефект, что нужно тестировать, а на что можно просто не обращать внимания, потому что «там никогда не возникает проблем». Да, это опыт, это умение сократить тестирование за счет того, что тестировщик понимает, к чему может привести то или иное изменение кода, но тогда мы говорим уже не об исследовательском тестирования, а о Risk-Based Testing!
Что такое исследование?
Исследование — это систематическое расследование с целью установления фактов, т.е. это процесс изучения чего-либо.
Поэтому, говоря об опыте, мы очень часто подразумеваем именно знания чего-либо. Знание — это уже умение чего-либо, но исследование — это изучение. Говоря об исследовательском тестировании мы должны отбросить все наши знания тестирования, опыт работы с системой, техник тест-дизайна и смотреть на системы новым, абсолютно не «замыленым» взглядом.
Исследовательское тестирование — это в первую очередь умение мыслить, желание обращать внимание на различные аспекты системы, отбросив наши знания и опыт работы с данной системой. Ведь именно опыт зачастую не позволяет нам видеть казалось бы такие простые вещи, на которые обычный тестировщик сразу укажет при тестировании.
Каждый же хоть раз в жизни, работая с молодыми тестировщиками, сталкивался с ситуацией, когда к вам приходит сотрудник и спрашивает, а почему здесь, к примеру, нету возможности изменить какое-либо поле, хотя оно по интуиции напрашивается само собой (потому что в жизни могут быть ситуации, когда нужно это поле изменить). На самом деле это дефект, но мы настолько привыкли тестировать по документации и, к сожалению, в нашей стране не ценят тестировщиков, как высококлассных специалистов, действительно отвечающих за качество работы приложения (именно с точки зрения пользователя), что в ответ мы слышим от Заказчика только одну фразу:
— Раз так написали в ТЗ, значит так должно быть.
Заключение
Поэтому, говоря об исследовательском тестирования, нельзя говорить, что это тестирование без тест-кейсов.
Исследовательское тестирование — это целое направление в тестировании, требующее от тестировщика не столько знания и опыт работы в отрасли, с системой, как умение неординарно мыслить и находить дефекты не в соответствии с ТЗ, а в соответствии с логикой работы приложения.