Что такое интуитивное или ad hoc тестирование

Что такое исследовательское тестирование?

И чем оно отличается от тестирования по сценариям (сценарного тестирования)

Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.

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

Параллельное проектирование и выполнение тестов

Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Звучит это просто, но на практике все весьма туманно. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся. Даже в том случае, если тщательно определены все тестовые сценарии, то работа с большим количеством интересных деталей (например, как быстро печатать на клавиатуре, или какие виды поведения программы признать ошибочными) остаются на усмотрение тестировщика. Кроме того, даже в свободной форме поисковой сессии тест будет включать в себя ограничения состоящие в том, какую часть продукта тестировать или какую стратегию использовать. Хороший исследовательский тестирировщик будет записывать идеи тестов и использовать их в последующих циклах испытаний. Такие заметки иногда очень похожи на сценарии тестирования, даже если они таковыми не являются. Исследовательское тестирование иногда путают с «ad hoc» тестированием. Ad hoc тестирование обычно относится к процессу импровизации, поиска ошибки экспромтом. По определению, любой может заниматься ad hoc тестированием. Термин «исследовательское тестирование» (придумал Cem Kaner, в книге Testing Computer Software) обозначает вдумчивый подход к ad hoc тестированию. За последние десять лет, Джеймс Уиттакер, Сем Канер и я работали для выявления навыков и техник позволяющих эффективно использовать исследовательское тестирование. Например, полностью определены и сформулированы процессы исследовательского тестирования, см. General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program.

Баланс между исследовательским и сценарным тестированием

Если каждый следующий тест, который мы выполняем, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование.Мы начинаем заниматься поисками и исследованиями, когда мы не можем сказать, какие тесты должны быть выполнены, или когда мы еще не имели возможности эти тесты создать, то есть мысль об их написании даже не приходила нам в голову. Если мы идем по сценариям, и на свет выплывает новая информация, которая предлагает нам лучшую стратегию тестирования, мы можем перейти к поисковому режиму (как и в случае обнаружения новой ошибки, которая требует подробного рассмотрения). С другой стороны, мы больше следуем сценарному подходу, когда 1) неопределенность в том, как мы хотим проверить, мала 2) новые тесты относительно неважны, 3) необходимость обеспечения эффективности и надежности в выполнении этих тестов стоит усилий по работе с подобными тестами, 4)мы готовы платить за написание и поддержание тестов.

Результаты исследовательского тестирования не обязательно радикально отличаются от тех, которые мы получаем с помощью сценарного тестирования и оба этих подхода к тестированию являются полностью совместимыми. Такие компании, как Nortel и Microsoft обычно используют оба подхода в одном проекте. Тем не менее есть много важных различий между двумя подходами.

Зачем проводить исследовательское тестирование?

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

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

Источник

Интуитивное тестирование. Как найти хитрый баг?

«Ad hoc testing is a commonly used term for software testing performed without planning and documentation»

Плюсы интуитивного тестирования:

1. «Псевдохаотичность» тестирования

Я часто слышу от людей близких к разработке ПО, но далеких от тестирования фразы типа: «все тестеры — задроты». Вероятно, такое мнение образовалось из-за того, что нам, тестировщикам, приходится большую часть времени заниматься рутинной работой, например, составление и анализ сотен однотипных тест-кейсов и последующее прохождение их, в лучшем случае, перед каждым релизом, или проведение теста приемки каждый раз когда выходит новый билд. Для такой работы характерна четкая определенность процесса тестирования, т.е. взял кейс №1, воспроизвел процедуру, поставил отметку о прохождении, взял кейс №2, и т.д. Никакого творчества и само собой шаг влево-право = расстрел.
Таким образом эта рутина не может не угнетать здоровый и молодой мозг тестировщика, который, устраиваясь на работу, прочитал в интернетах что «тестеры – люди творческие», и тут на помощь приходит эксплоринг, а именно эд хок тестирование, хаотичность которого объясняется свободным поиском багов, хочу туда кликаю, хочу сюда, а хочу и с БД балуюсь, и на первый взгляд, вот оно творчество, но не все так просто. Думаю, что любой более-менее опытный тестировщик перед началом тестирования какой-нибудь функциональности в голове составляет план тестирования и все те же тест-кейсы №1-100500, которые в другом случае были бы написаны, и только после этого приступает к работе. Этим я объясняю приставку «псевдо». Таким образом, чередование интуитивного тестирования с прохождением тест-кейсов позволяет снимать напряжение с мозга.

2. Форсированное обучение новых сотрудников

Каждый тестировщик как минимум должен знать свой проект. С приходом нового тестировщика встает вопрос: «А как его научить знать проект?». В одних компаниях тестера сразу бросают в бой – дают пару сотен кейсов на выполнение. Действительно, зачем учить, если в процедурах все и так написано. Таким образом, компания приобретает «мартышку» на 3-5 месяцев, до тех пор, пока он не пройдет большую часть тестовых комплектов. После этого тестировщик достаточно хорошо знает проект, чтобы выполнять другие функции помимо воспроизведения шагов. Давайте представим, что этот же тестировщик вместо прохождение кейсов, неделю(40-50 часов) должен будет бессистемно искать баги, там где он захочет, параллельно читая спеки и диздоки об интересующих его объектах. Уже через неделю наш тестировщик будет знать 70% от того что узнал бы проходя кейсы 3-5 месяцев.

3. Основной плюс метода — возможность поиска «хитрых, коварных» багов, которые не только трудновоспроизводимы, но и неизвестно как их воспроизводить

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

Что делать если баг не воспроизвелся, но игроку мы доверяем? Можно попросить вспомнить все, что он делал последние 15 минут до падения. 80% что он не вспомнит. Тогда остается только эд хок. Под девизом: «воспроизвести любой ценой» мы открываем клиент и штурмуем мозг всевозможными алгоритмами поведения пользователя. Итого: через 2-100 часов баг воспроизведен, а у игрока горят уши пропорционально количеству потраченных часов. А баг оказался простым: стабильное падение клиента на компах где установлен скайп, во время получения сообщения в icq6.

Источник

Исследовательское тестирование: когда его стоит применять и как это делать

Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.

Что такое исследовательское тестирование

Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.

Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.

Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.

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

Когда можно применять исследовательское тестирование в чистом виде

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

Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.

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

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

Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.

Когда одним исследовательским тестированием не обойтись:

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

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

Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.

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

Развенчание мифов или как применять исследовательское тестирование

«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»

Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.

«Нельзя доверить выполнение тестирования первому встречному»

Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.

«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»

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

Выводы

Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.

Источник

Что такое ad-hoc тестирование?

В этой статье мы разберем, что такое ad-hoc тестирование и какие оно имеет преимущества и недостатки. Также рассмотрим best practices в этом виде тестирования.

Что из себя представляет ad-hoc тестирование?

«Ad hoc» переводится с английского как «случайный, непродуманный, спонтанный». Такое тестирование также называют «случайным тестированием» или «monkey testing» («обезьяньим тестированием»).

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

Главная цель ad-hoc тестирования — обнаружить баги при помощи случайных проверок. На каждом шаге тестирования тестировщик импровизирует. Таким образом удается выловить очень специфические и любопытные баги, которые легко пропустить, применяя другие методы.

Самый интересный аспект ad-hoc тестирования — отсутствие каких-либо методик продумывания тестов. Благодаря этому можно найти баги, которые обычно проскакивают незамеченными. Но, вместе с тем, воспроизвести это тестирование сложно, поскольку нет ни написанных тест-кейсов, ни документации.

Успех ad-hoc тестирования полностью зависит от креативности и настойчивости тестировщика, а порой и от чистой удачи.

Виды ad-hoc тестирования

1. Buddy Testing

Суть Buddy Testing в том, что как минимум два «компаньона» (в переводе с английского buddy — приятель, компаньон) одновременно пытаются выявить баги в одном и том же модуле.

Buddy Testing можно считать комбинацией системного и модульного тестирования. Оно проводится после юнит-тестирования модуля.

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

2. Monkey Testing

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

Основная задача тестировщика — проанализировать работу приложения совершенно рандомным образом. Это помогает удостовериться, что система способна выдержать любой сбой.

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

3. Парное тестирование

Парное тестирование похоже на Buddy Testing, но здесь над модулем работают два тестировщика, а не тестировщик и разработчик. Кроме того, Buddy Testing — комбинация модульного и системного тестирования, а парное тестирование — чисто модульное.

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

Работая в паре, тестировщики могут распределять роли: скажем, один проводит тесты, а другой делает записи.

Когда стоит проводить ad-hoc тестирование

Ad-hoc testing бывает полезным, когда у вас нет времени на длительный и всеобъемлющий процесс тестирования, требующий подготовки требований и тест-кейсов.

Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов. Но его также можно проводить и в процессе разработки, и после его завершения.

Стоит отметить и пару сценариев, при которых ad-hoc тестирование не рекомендуется:

Преимущества ad-hoc тестирования

Основное преимущество ad-hoc тестирования — возможность выявить баги, которые остались бы незамеченными при других проверках. А поскольку для такого тестирования не нужно ничего планировать и структурировать, оно экономит много времени.

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

Такое тестирование могут проводить и сами разработчики ПО.

Недостатки ad-hoc тестирования

Основной недостаток ad-hoc тестирования состоит в том, что сам процесс тестирования не документируется, поскольку идет не по конкретному набору тест-кейсов. В результате воспроизвести замеченную ошибку сложнее. Для этого тестировщику приходится вспоминать, какие шаги привели его к нужной точке.

Кроме того, если у тестировщика нет предварительных знаний о функционале тестируемого приложения, ad-hoc тестирование будет бесполезным, оно не выявит никаких ошибок.

Также ad-hoc тестирование не гарантирует, что все ошибки будут найдены. Успех этого тестирования вообще очень зависит от знаний и навыков тестировщика.

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

Best Practices в ad-hoc тестировании

Если тесты проводятся неправильно, время тратится впустую. Поэтому для успешного проведения ad-hoc тестирования важно знать, как оптимизировать процесс.

Следующие best practices гарантируют, что время на тестирование будет потрачено с умом, а шансы на успех будут максимальными.

Ознакомьтесь со спецификацией

QA-специалист, проводящий ad-hoc тестирование, должен хорошо знать тестируемое приложение и его основные функции. Только благодаря этому он сможет «угадывать», где скрываются ошибки и баги.

Определите наиболее «подозрительные» части приложения

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

Функции, к которым имеет доступ конечный пользователь, должны быть в приоритете

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

Сформулируйте план тестирования в свободной форме

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

Используйте подходящие инструменты

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

Итоги

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

Источник

QA evolution

Интуитивное тестирование (ad-hoc testing)

ad-hoc testing — в ид тестирования, который выполняется без подготовки к тестам, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Он не требует никакой документации, планирования, процессов которых следует придерживаться в выполнении. Также на данный вид тестирования не пишутся тест-кейсы, что в свою очередь может вызвать определенные затруднения в попытках воспроизвести дефект в системе. Такой вид зачастую может дать сходу больше результата чем тестирование по заранее определенным сценариям. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основного функционала и выполняет нестандартные проверки, точнее некоторые из его проверок будут нестандартными.

ad-hoc testing

Часто интуитивное тестирование путают с исследовательским. Если говорить об ad-hoc testing и исследовательском тестировании. Ad-hoc testing — это более интуитивное и беспорядочное тестирование, когда тестировщик просто идет и проверяет, что ему хочется. У него нет определенной цели, структуры тестов в голове, какой-то системы. В свою очередь исследовательское тестирование более структурированное. Обычно тестировщик знает, что ему нужно проверить, у него в голове есть цель и какая-то система проведения тестов. Хоть тесты в этом случае не обязательно должны быть оформлены в виде тест кейсов.

Чаще всего такое тестирование выполняется когда мало времени на точное и последовательное тестирование. При этом тестировщик полагается на свое общее представление о приложении и здравый смысл

Тестирование ad-hoc имеет смысл только в случае если тестировщик владеет общей информацией о продукте. Если человек совсем не будет знать продукт, то потратит время на его изучение, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначению и основным функциям и возможностям. А дальше уже можно приступать к ad-hoc testing.

Виды интуитивного тестирования:

Различия между buddy testing и pair testing:

Основные преимущества ad-hoc testing:

Что можно использовать при таком виде тестирования, какие навыки будут полезными?

Поскольку нет никакой применимой документации, все что остается использовать тестировщику — здравый смысл, логику и накопленный опыт. Стоит отметить что любое, даже не очень знакомое вам приложение должно быть интуитивно понятным. Действуйте больше с точки зрения пользователя, чем тестировщика.

Источник