Исследовательское тестирование для чего
Исследовательское тестирование: пустая трата времени или мощный инструмент?
Одни считают, что исследовательское тестирование более продуктивное, чем привычное нам тестирование по сценариям. Другие — что это пустая трата времени и ресурсов. Так ли это на самом деле?
Исследовательское тестирование это:
Это метод ручного тестирования, который базируется на взаимодействии с приложением без детальной подготовки, основанное на знаниях и опыте тестировщика, из-за чего его квалификация может серьезно повлиять на результат.
Три вида тестирования, которые не стоит путать
По формальности документирования выделяют три вида тестирования:
Под ad-hoc тестированием понимают тестирование без использования спецификаций, планов и разработанных тест-кейсов — здесь преимущественно чистая импровизация. В таком виде тестирования полностью отсутствует предварительная подготовка, происходит наиболее достоверная имитация случайного пользователя.
Исследовательское тестирование — более формальная версия ad-hoc: тестирование, не требует написания тест-кейсов без необходимости, но подразумевает, что каждый последующий шаг(тест) выбирается на основании результата предыдущего шага(теста). А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование является классическим тестированием по предварительно написанным и задокументированным сценариям. Оно требует наибольшей степени формальности и детализации документирования, что затрачивает гораздо больше сил тестировщика и его времени, однако наиболее подходит для ведения отчетности, статистики и т.п.
Общие сведения
Исследовательское тестирование можно понимать как подход или саму идею, которой придерживается специалист в процессе. Исследовательское тестирование подразумевает под собой одновременное изучение проекта и его функционала, создание тест-кейсов в уме и их исполнение, не записывая и не создавая тестовую документацию без необходимости.
Такой вид тестирования может не предусматриваться в тест плане, а тест-кейсы выполняются и модифицируются динамически. Эффективность такого тестирования напрямую зависит от опыта тестировщика ранее имевшим дело с этим приложением, платформой, знанием мест скопления возможных багов и рисками которые относятся к конкретному продукту. Тестировщики могут успешно применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов, и даже как вариант дымового тестирования, избегая лишних затрат времени.
Рассмотрим преимущества и недостатки исследовательского тестирования
Преимущества исследовательского похода
Недостатки исследовательского подхода
В каких же случаях стоит применять исследовательское тестирование?
— В запасе имеется довольно много времени после регресса
Бывает, конечно, зачастую не так часто, вы успеваете в срок и остается некоторое количество времени, и чтобы убедиться, что вы внимательно прошлись по всем тест-кейсам, что ничего не упустили, применяют исследовательское тестирование.
— Одни и те же тест-кейсы на регрессе
Количество имеющихся тест-кейсов на проекте зачастую довольно велико. Еженедельные прохождения по одним и тем же тест-кейсам приводят к тому, что глаз замыливается, и вследствие этого баги пробираются на прод. Когда же мы идем не по шагам и в голове не держим, что нам осталось еще пройти пару сотен кейсов – это помогает взглянуть на проект с несколько другой стороны.
Функционал нашего приложения не очень большой, поэтому можно смело использовать исследовательское тестирование. Но стоит помнить и об обратной стороне — проект расширяется, количество коллег в команде растет и документация в скором времени просто будет необходима. Даже если сроки «горят», закладывайте время на составление документации.
Как было сказано выше, кейсов на проекте может быть очень большое количество и иногда, из-за горящих сроков, команда просто не успевает актуализировать тест-кейсы. Либо вы пришли на проект и там просто нет документации.
В каких же случаях не стоит применять одно только исследовательское тестирование?
Клиенту важно знать, что было проверено, ему необходим отчет о тестировании. В данном случае составляются чек-листы и тест-кейсы.
— На проекте есть автоматизация
Приложение покрывается автотестами, тут тест-кейсы просто необходимы.
Исследовательское тестирование: когда его стоит применять и как это делать
Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Что такое исследовательское тестирование
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Когда можно применять исследовательское тестирование в чистом виде
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Когда одним исследовательским тестированием не обойтись:
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Развенчание мифов или как применять исследовательское тестирование
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Выводы
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
Исследовательское тестирование: пустая трата времени или мощный инструмент?
Одни считают, что исследовательское тестирование более продуктивное, чем привычное нам тестирование по сценариям. Другие — что это пустая трата времени и ресурсов. Так ли это на самом деле?
Исследовательское тестирование это:
Это метод ручного тестирования, который базируется на взаимодействии с приложением без детальной подготовки, основанное на знаниях и опыте тестировщика, из-за чего его квалификация может серьезно повлиять на результат.
Три вида тестирования, которые не стоит путать
По формальности документирования выделяют три вида тестирования:
Под ad-hoc тестированием понимают тестирование без использования спецификаций, планов и разработанных тест-кейсов — здесь преимущественно чистая импровизация. В таком виде тестирования полностью отсутствует предварительная подготовка, происходит наиболее достоверная имитация случайного пользователя.
Исследовательское тестирование — более формальная версия ad-hoc: тестирование, не требует написания тест-кейсов без необходимости, но подразумевает, что каждый последующий шаг(тест) выбирается на основании результата предыдущего шага(теста). А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование является классическим тестированием по предварительно написанным и задокументированным сценариям. Оно требует наибольшей степени формальности и детализации документирования, что затрачивает гораздо больше сил тестировщика и его времени, однако наиболее подходит для ведения отчетности, статистики и т.п.
Общие сведения
Исследовательское тестирование можно понимать как подход или саму идею, которой придерживается специалист в процессе. Исследовательское тестирование подразумевает под собой одновременное изучение проекта и его функционала, создание тест-кейсов в уме и их исполнение, не записывая и не создавая тестовую документацию без необходимости.
Такой вид тестирования может не предусматриваться в тест плане, а тест-кейсы выполняются и модифицируются динамически. Эффективность такого тестирования напрямую зависит от опыта тестировщика ранее имевшим дело с этим приложением, платформой, знанием мест скопления возможных багов и рисками которые относятся к конкретному продукту. Тестировщики могут успешно применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов, и даже как вариант дымового тестирования, избегая лишних затрат времени.
Рассмотрим преимущества и недостатки исследовательского тестирования
Преимущества исследовательского похода
Недостатки исследовательского подхода
В каких же случаях стоит применять исследовательское тестирование?
— В запасе имеется довольно много времени после регресса
Бывает, конечно, зачастую не так часто, вы успеваете в срок и остается некоторое количество времени, и чтобы убедиться, что вы внимательно прошлись по всем тест-кейсам, что ничего не упустили, применяют исследовательское тестирование.
— Одни и те же тест-кейсы на регрессе
Количество имеющихся тест-кейсов на проекте зачастую довольно велико. При еженедельных прохождениях по одним и тем же тест-кейсам приводит к тому, что глаз замыливается и, в следствии чего, баги пробираются на прод. Когда же мы идем не по шагам и в голове не держим, что нам осталось еще пройти пару сотен кейсов – это помогает взглянуть на проект с несколько другой стороны.
Функционал нашего приложения не очень большой, поэтому можно смело использовать исследовательское тестирование.
Как было сказано выше, кейсов на проекте может быть очень большое количество и иногда, из-за горящих сроков, команда просто не успевает актуализировать тест-кейсы. Либо вы пришли на проект и там просто нет документации.
В каких же случаях не стоит применять одно только исследовательское тестирование?
Клиенту важно знать, что было проверено, ему необходим отчет о тестировании. В данном случае составляются чек-листы и тест-кейсы.
— На проекте есть автоматизация
Приложение покрывается автотестами, тут тест-кейсы просто необходимы.
Исследовательское тестирование для чего
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Сегодня поговорим с вами про исследовательское тестирование. Причём про такое исследование продукта, которое никто не назовёт обезьяньей работой.
Бытует мнение, что исследовательское тестирование – удел молодых специалистов, якобы думать там совсем не нужно, тыкай себе хаотично всё подряд – авось и баги найдутся. Ан нет. Исследовательское тестирование – это целая наука со своими методологиями и техниками.
Давайте обратимся к теории, что же такое исследовательское тестирование? Что значит “мы исследуем”? Исследовать – значит изучать, знакомиться, смотреть на продукт и на то, как он будет реагировать на ваши действия.
Исследовательское тестирование – это одновременное создание тестов, их прохождение и корректировка в зависимости от поведения вашего продукта.
У исследовательского тестирования есть определённые характеристики, и мы рассмотрим их в сравнении со скриптовым тестированием, то есть с тестированием по готовым тестам.
Первая характеристика – гибкость
При исследовательском подходе вы не готовите заранее никаких тестов, не придерживаетесь выбранного курса – вы изучаете функционал, как турист без карты, который увидел красивую полянку с цветочками и багами, пошёл к ней и задержался там на некоторое время.
Вы не должны тратить время на подготовку и продумывание маршрута. Вы тестируете продукт, опираясь лишь на определённые техники, инструменты и на свой предыдущий релевантный опыт.
А при скриптовом тестировании вы готовите тестовую документацию, кейсы, чек-листы, согласовываете их, актуализируете, поддерживаете, всегда придерживаетесь конкретного маршрута движения и тратите довольно много времени.
Вторая характеристика – параллельность
При параллельном планировании, создании и выполнении тестов вы одновременно проводите тестирование, знакомитесь со своим продуктом и определяете дальнейшие шаги, опираясь на поведение продукта.
А при скриптовом подходе всё идет поэтапно: сначала этап анализа, потом создание и выполнение тестов, затем предоставление отчётов по пройденным тестам.
Третья характеристика – возможность быстрого старта
Вы можете начать тестировать продукт сразу, как только получили такую задачу. Вы не тратите время на создание тестов, на их запись, как при скриптовом подходе, ничего не актуализируете, не тратите время на то, чтобы показать записанные тесты руководителю и получить согласование. Получили задачу – начали исследовательское тестирование. Всё просто.
Подведём небольшой итог: любой подход в тестировании имеет свои несомненные плюсы и минусы.
Формальные подходы могут обеспечить планируемость тестирования, прогнозируемость и хорошую детальную отчетность. Но, как правило, они грешат избытком бюрократии, разных видов отчётов и иной рутины.
Более гибкие подходы дают тестировщикам бОльшую свободу и возможность творить, быстро и гибко реагировать на какие-то изменения в продукте, но чреваты неопределённостью и отсутствием тестовых артефактов.
Сравнение разных подходов
Как же найти золотую середину? Возможно ли сделать тестирование и интересным, и творческим, и прогнозируемым одновременно? Измеримым, но не переполненным бюрократией и прочими бумажками? Можно! Session based testing – вот за счёт чего обезьяна эволюционировала в настоящего тестировщика!
Сессионное исследовательское тестирование или session based testing
Этот подход придумали братья Джеймс и Джон Бах в 2000 году. Смысл его очень простой и интуитивно понятный из названия – тестирование происходит сессиями, то есть определёнными промежутками времени.
В самом начале тестирования необходимо определить функциональные области продукта, то есть то, из каких частей состоит продукт. Это будет правильным для любого из подходов: исследовательского или скриптового.
Вы декомпозируете продукт, разбиваете его на части, рисуете, например, майнд-карту или сразу техникой действия расписываете параметры значения: что куда и зачем. Неважно, какую технику вы выберете, главное, чтобы у вас было чёткое понимание, что представляет собой ваш продукт. Хоть в табличку вы всё напишете, хоть стикеры на доску приклеите.
Для начала вам необходимо проверить, работает ли вообще основной функционал вашего продукта, то есть самый первый уровень декомпозиции. Проводите так называемый нулевой тест, самый типичный и, конечно же, позитивный.
Определяете тестовую сессию на продукт в целом. Это будет чартер или цель тестирования.
Далее договариваетесь внутри команды о продолжительности сессии: час, полтора-два – то есть о времени, в течение которого вы будете исследовательски тестировать продукт. Кстати, сам Бах рекомендует проводить одну тестовую сессию не более полутора часов.
Далее идете тестировать, и тут можно применить самые разные техники эвристики: чит-листы, тестовые туры, о которых мы расскажем в наших следующих статьях.
А по результатам сессии к вам приходит менеджер и спрашивает: «Продлевать будете?»
На самом деле по результатам сессии создаётся session report, то есть своего рода отчёт, представляющий собой тестовый артефакт.
В отчёт входит следующая информация:
Чартер – это цель вашего тестирования, функционал или какая-то функциональная часть, которую вы проверяли. Указываете, кто и когда тестировал, дату, время начала тестовой сессии.
Дальше идёт блок, где вы указываете общую продолжительность тестовой сессии, время, в течение которого готовились к тестированию, когда проводили тестирование, время, потраченное на заведение и изучение обнаруженных ошибок.
Также можете оставить в отчёте какие-то свои заметки, выписать появившиеся вопросы, и, конечно, все найденные ошибки!
Ошибки документируются, ссылки на баги к отчёту прилагаются. Всё прозрачно и красиво.
Смотрите, какая классная штука будет дальше: если нулевой тест прошёл и в целом продукт работает, вы начинаете повторять тестовые сессии, но идёте уже на уровень глубже. И с каждой такой тестовой сессией всё глубже и глубже погружаетесь в продукт.
Всё лучше его изучаете, исследуете, узнаёте какие-то особенности и нюансы.
Представьте себе ступеньки, и как вы спускаетесь по ним. Работает основной функционал продукта – отлично, значит спускаетесь на ступеньку ниже и проводите новую тестовую сессию. И так до тех пор, пока не доберётесь до самого дна – то есть до физически неделимого компонента системы.
Нашли какой-то кусочек, какую-то функциональную область с множеством багов, остановились на ней подробнее и изучили детальнее.
Как правило, после сессии происходит такое интересное событие как де-бриф, когда вся команда собирается и обсуждает “натестированное добро”.
Если это офис – команда идёт в переговорную комнату, если хоум-офис – ребята созваниваются по какой-нибудь “звонилке” с камерами и обсуждают, что тестировали, с какими проблемами столкнулись, какие баги нашли. И реальная, ощутимая польза таких де-брифов в том, что имеет место взгляд со стороны: свежий, интересный, нестандартный. Ваши коллеги могут подкинуть вам пару идей, дать советы, да и вообще вербальное обсуждение – очень хорошая и полезная практика. Пусть даже при помощи мобильной конференц-связи.
Подведём итог: что же даёт сессионный подход? Он даёт возможность планировать тестирование и избегать хаоса, ведь когда вы знаете продолжительность одной сессии, одного уровня продукта, то можете спланировать, сколько времени займёт тестирование всего продукта целиком.
Либо можете выбрать наиболее приоритетные уровни продукта, если время на тестирование у вас ограничено. Согласитесь, это совсем не обезьянья работа, а полноценное качественное тестирование продукта, да еще с тестовыми артефактами и обменом опытом на де-брифах.
Итак, плюсы сессионного подхода:
Несмотря на всю важность и пользу исследовательского подхода в тестировании продукта в целом и session based тестинга в частности, это далеко не панацея.
Когда же нужно проводить исследовательское тестирование, а когда всё же стоит отдать предпочтение более формальному подходу и скриптовому тестированию?
Исследовательское тестирование применимо в следующих случаях:
Когда исследовательское тестирование лучше заменить на скриптовое:
Иногда применяется комбинированный подход, когда критично важный функционал проверяется скриптовым тестированием с расписанными детально тест-кейсами, полируется исследовательским сессионным тестированием, а менее важный функционал покрывается чек-листами.
Научиться внедрять эти рекомендации на практике вы можете на курсе “Первый Онлайн ИНститут Тестировщиков” (ПОИНТ) от компании “Лаборатория Качества”.