Что такое monkey testing
Разница между тестированием на обезьянах и специальным тестированием
Ключевая разница: Adhoc Тестирование выполняется без какого-либо планирования или подготовки. После того, как программа заработает, программист или тестер будут тестировать программное обеспечение, ис
Содержание:
Adhoc Тестирование выполняется без какого-либо планирования или подготовки. После того, как программа заработает, программист или тестер будут тестировать программное обеспечение, используя свои знания о программе. Он, как правило, проверяет основы системы, чтобы убедиться, что они работают и система не падает. Этот тип тестирования выполняется без использования тестового примера.
Тестирование на обезьянах похоже на Ad hoc Testing. Это также проводится случайным образом, без какого-либо планирования или подготовки. По этой причине многие программисты относят Monkey Testing к типу Adhoc Testing. Однако Monkey Testing отличается от Adhoc Testing одним существенным образом, Monkey Testing можно проводить без каких-либо знаний или информации о программном обеспечении.
Преимущество Monkey Testing и Adhoc Testing заключается в том, что оно тестирует программное обеспечение в реальной и случайной ситуации по сравнению со структурированным тестированием. Подобные ситуации также более реальны и могут произойти, когда продукт появится на публике. Однако недостатком Monkey Testing и Ad-hoc Testing является то, что, когда ошибка действительно возникает, невозможно воспроизвести ошибку, так как нет файлов тестовых примеров, на которые можно было бы сослаться. Вот почему Monkey Testing и Adhoc Testing почти всегда используются в сотрудничестве с традиционными и структурированными методами тестирования.
Сравнение между тестированием на обезьянах и специальным тестированием:
Обезьяна Тестирование
Специальное тестирование
Несколько тестов, чтобы убедиться, что система или приложение не аварийно завершают работу.
Тестер пытается «сломать» систему путем случайного опробования ее функциональных возможностей.
Никакого конкретного теста не проводится; это может включать в себя просто случайный щелчок или ввод текста, чтобы увидеть, не происходит ли сбой системы.
Основано на знаниях тестера. Тестер может проверить, что он считает необходимым.
«Обезьяна на пишущей машинке». Любой, кто не знает программного обеспечения или даже компьютеров.
Программист с детальным знанием программного обеспечения и системы.
Gremlins.js — monkey testing библиотека для веб приложений
Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.
Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.
Kate: What are they, Billy?
Billy Peltzer: They’re gremlins, Kate, just like Mr. Futterman said.
Предвидите ли вы все необычные пользовательские сценарии при разработке HTML5 приложений? Можете ли вы обнаружить и устранить возможные утечки памяти? Если нет, ваше приложение рано или поздно может дать сбой. Если случайные действия могут положить ваше приложений, лучше узнать о проблемах на стадии тестирования, вместо того, чтобы позволить пользователю обнаружить их самостоятельно.
Gremlins.js эмулирует случайные действия пользователя: гремлины кликают везде, куда могут добраться, вводят случайные данные в формы, или перемещают мышь над элементами, которые этого не ожидают. Их цель: вызвать JavaScript ошибку или заставить приложение выйти из строя. Если им это не удалось, поздравляю! Приложение достаточно пуленепробиваемо для того, чтобы показать его реальным пользователям.
Эта практика так же известна как Monkey testing или Fuzz testing, она широко распространенна в мире мобильной разработки (посмотрите на Android Monkey program). Сегодня, когда интерфейс (MV*, d3.js, Backbone.js, Angular.js, etc.) и бекенд (Node.js) разрабатывается полностью на JavaScript, эта технология становится применима и для веб приложений.
Базовое использование
Полчище гремлинов ( horde ) — это армия из специализированных гремлинов, готовых встряхнуть ваше приложение. Выпустите ( unleash ) их для начала стресс тестов:
Gremlins.js предоставляет несколько типов гремлинов: некоторые кликают во всевозможных местах, другие заполняют формы данными, кто то скролит окно браузера, и т.д.
Вы можете наблюдать за их поведением в окне браузера (они оставляют за собой следы) или отслеживать логи в консоли:
Кроме того, существуют безвредные могваи ( mogwais ). Могваи только наблюдают за активностью приложения и записывают дынне в лог. Для примера, «fps» могвай каждые 500ms показывает количеcтво кадров в секнду (FPS).
Иногда могваи сообщают, когда гремлинам все же удалось навредить приложению. К примеру, если fps опустится ниже отметки в 10, fps могвай выведет ошибку в лог:
После 10 ошибок специальный могвай Gizmo остановит тестирование и всех выпущенных гремлинов. В конце концов, после первых 10 ошибок, вы уже знаете, что вам нужно сделать, чтобы сделать ваше приложение более устойчивым.
Гремлины, как и могваи — это простые JavaScript функции. Если gremlins.js не предоставляет необходимых вам гремлинов, вы довольно просто можете реализовать их самостоятельно:
Загляните в папку с примерами, чтобы лучше понять как работает gremlins.js.
Вы можете сконфигурировать любой компонент в gremlins.js; расширяйте функциональность и адаптируйте ее для своих сценариев.
Установка
В браузере, файл gremlins.min.js может быть добавлен как сторонняя библиотека, после чего gremlins будет доступен в глобальном пространстве имен:
Есть возможность подключить gremlins.min.js как RequireJS модуль, не засоряя глобальное пространство имен:
Продвинутое использование
Настройка гремлинов и могваев для использования в тестах
Изначально все гремлины и могваи уже добавлены в полк ( horde ).
Вы так же можете выбирать и добавлять только необходимых вам гремлинов с помощью метода gremlin() у объекта horde :
Для того, чтобы добавить ваших собственных гремлинов к стандартным, воспользуйтесь методом allGremlins() :
Чтобы добавить могваев, используйте методы mogwai() и allMogwais() таким же образом.
На данный момент gremlins.js поставляет несколько гремлинов и могваев:
Конфигурация гремлинов
Все гремлины и могваи поставляемые в gremlins.js являются настраиваемыми функциями ( configurable functions ), то есть вы можете изменить логику работы их методов.
Для примера, гремлин clicker — это функция, возвращающая объект, который вы можете вызвать напрямую:
Гремлин clicker имеет следующие методы для кастомизации:
Каждый гремлин или могвай имеет собственные методы для настройки, советую изучить исходный код каждого из них.
Больше информации о конфигурируемых функциях ищите в статье о service closures.
Поддержка Random Seed
Если вы хотите, чтобы ваши атаки можно было повторить, вам необходимо инициализировать генератор случайных чисел. Gremlins.js использует Chance.js для генерации случайных данных, таким образом его можно инициализировать:
Выполнение кода до или после атак
Вы можете исполнять произвольный код до начала тестирования. Обычно бывает полезно:
Для очистки тестового окружения, объект horde так же предоставляет метод after() :
Оба метода поддерживают асинхронный вызов callback’a:
Стратегия
По умолчанию гремлины будут атаковать ваше приложение в произвольном порядке разделенные промежутком в 10ms. Эта стратегия атаки называется distribution. Изменить ее можно используя метод horde.strategy() :
Существует возможность использовать и другие стратегии. Стратегия — это просто callback ожидающий три параметра: массив гремлинов, объект (возвращенный в результате unleash() ) и финальный callback. В комплекте идут еще две встроенных стратегии (allTogether и bySpecies) и реализовать собственную стратегию для более специфичных сценариев атак должно быть предельно просто.
Остановка тестирования
Модификация логирования
По умолчанию, gremlins.js выводит в консоль все действия гремлинов и наблюдения могваев. Если для вас предпочтительней использовать альтернативный метод журналирования (к примеру, хранить активность гремлинов в localStorage и отправка их каждые 10 секунду c помощью AJAX), просто передайте объект logger с четырьмя методами (log, info, warn, и error) в метод logger() :
Вместо создания собственного логгера, посмотрите в сторону Minilog
Хаос и гремлины: тестирование веб-интерфейсов
В мире веб-разработки есть неписаное правило: поведение пользователей предсказать практически невозможно. Это способен подтвердить каждый, кто наблюдал за тем, как некто приступает к работе с новым для него сайтом или веб-приложением. Я, например, уже и не помню, сколько раз мне доводилось видеть подобное. Например, порой думается, что люди просто забывают о том, как пользоваться браузером на мобильнике. Иногда их действия настолько нелогичны, что кажется, будто перед тобой не реальный человек, работающий с реальным веб-сайтом, а пьеса в жанре театра абсурда: необычно, порой более чем, притягательно, есть над чем подумать, но… мы ведь не в театре.
Дело здесь в том, что разработчик не способен точно предсказать поведение пользователей в тот или иной момент работы с программой. Скажем, человек может быть весьма чем-то взволнован, в результате – попытается сделать что-то слишком быстро. То, как он вводит данные в поля и щёлкает по кнопкам, будет совсем непохоже на спокойное и сосредоточенное поведение. К сожалению, при проектировании и разработке программных продуктов, слишком часто ориентируются именно на подобный «идеальный вариант», а о том, что может произойти в других случаях, далёких от «идеала», не задумываются.
Разработчики стремятся создавать программные системы, надеясь на то, что пользователь поймёт их внутреннюю логику. Они видят пользователя рациональным, знающим, что, скажем, беспорядочные касания всего подряд на экране телефона могут привести к чему-нибудь крайне непредсказуемому. Странности, кстати, возможные и тогда, когда вполне обычный человек, случайно, возможно даже не глядя на экран компьютера или телефона, что-нибудь щёлкнет или чего-нибудь коснётся. Можете вспомнить, сколько раз вы сами так делали, скажем, разговаривая по телефону на ходу и параллельно пытаясь ответить на твит или электронное письмо?
Инструменты, которые позволяют исследовать реакцию компьютерных систем на непредсказуемые события, появились не вчера, но мы не будем слишком углубляться в историю. Рассмотрим близкий веб-разработчикам пример, когда в 2012-м году Netflix открыл код своего внутреннего сервиса Chaos Monkey. Эта система «выключает виртуальные машины и контейнеры, которые исполняются внутри продакшен-окружения». Говоря обычным языком, Chaos Monkey случайным образом отрубает сервера для того, чтобы можно было узнать, как поведёт себя система в подобном случае, убедиться, что весь сервис не рухнет в результате отказа нескольких машин.
То, что при проектировании приложений не стоит ограничиваться лишь их подготовкой к «идеальным вариантам», знают все. Но, если перевести эту проблему в плоскость разработки веб-интерфейсов, возникают вполне резонные вопросы: «Как найти непредсказуемые сбойные места и разрушительные для программы последовательности действий гипотетических пользователей? Если что-то подобное сделано для серверов, нельзя ли так же поступить с интерфейсами?».
Прежде чем ответить на этот вопрос, вспомним теорему о бесконечных обезьянах: «Абсолютно случайным образом ударяя по клавишам пишущей машинки, гипотетическая обезьяна рано или поздно напечатает одну из пьес Шекспира». Если это так, то всего одна обезьяна, чем бы она ни была, вполне способна найти баги и проблемы в веб-интерфейсе.
Обезьяны, в студию!
«Обезьянье тестирование» (monkey testing), или, как его ещё называют, «хаотическое тестирование», это методика испытания программных продуктов, основанная на имитации случайных действий пользователя, которые никак не связаны с реальными сценариями использования систем.
Если говорить о тестировании мобильных версий веб-сайтов, это могут быть случайные касания кнопок, разные жесты на сенсорном экране, ввод чего попало в поля. Цель такого тестирования – найти проблемы приложения или полностью нарушить его работоспособность. Это совсем не похоже на обычное модульное или приёмочное тестирование, когда пишут тестовые сценарии, содержащие наборы действий, происходящих в определённой последовательности и при определённых условиях. В итоге такие вот тесты, например, в сфере интерфейсов, сильно зависят от того, как разработчик видит их правильную работу.
Программисты обладают меньшим контролем над тем, как выполняются обезьяньи тесты, и так как каждый их запуск, в общем случае, подвергает приложение новому случайному набору испытаний, тестирование не ограничивается одним сценарием, оно скорее представляет собой бесконечный набор непредсказуемых сценариев взаимодействия пользователя и программы.
Хотя этот тип тестирования доступен на большинстве платформ, на которых исполняются самые разные приложения, нельзя сказать, что в веб-среде обезьяньи тесты получили должное распространение. Например, в Android SDK имеется встроенное средство UI Exerciser Monkey, с помощью которого можно проверить приложение, задействовав большинство интерфейсных и системных событий. Глядя на Android, вполне логичным было бы желание найти подобный стандартный функционал, скажем, в разделах «средства разработчика» популярных браузеров, но там «обезьяны» пока не водятся. Ситуацию исправила команда Marmelab, создав JavaScript-библиотеку хаотического тестирования веб-интерфейсов Gremlins.js.
Гремлины идут!
Всё указывает на то, что при разработке Gremlins.js создателей библиотеки вдохновляла пара комедийных ужастиков Джо Данте. «Гремлинами» в библиотеке называются функции, которые способны устроить адский беспорядок на плохо спроектированной странице. Библиотечные «могваи» — это мирные сущности, главная задача которых – наблюдать за происходящим, сообщать о том, что они видят, поддерживать процесс тестирования. Есть здесь и «Гизмо». В библиотеке он играет роль механизма, останавливающего сеанс тестирования.
Для того, чтобы воспользоваться библиотекой, запустив стандартную процедуру случайного тестирования, достаточно буквально пары строк кода или нескольких кликов мышью. В то же время, при необходимости, испытания можно весьма тонко настроить. Для того, чтобы приступить к работе, можно избрать один из трёх путей: подключить Gremlins.js к странице в виде автономной библиотеки, подключить как модуль Require.js, запустить из букмарклета. Рассмотрим эти способы.
▍Автономная библиотека
Самый простой способ создать тестовую среду – включить библиотеку непосредственно в веб-страницу, которую нужно испытать. Благодаря такому подходу, gremlins окажется в глобальном пространстве имён, библиотеку можно будет вызвать откуда угодно. Выглядит это так:
▍Модуль Require.js
Если в вашем проекте используется Require.js, Gremlins.js можно импортировать в нужном месте, не затрагивая глобальное пространство имён.
▍Использование букмарклета
Если вы не хотите интегрировать библиотеку в свой проект, выбираете путь эпизодического тестирования, можете воспользоваться букмарклетом, который позволяет испытать любую страницу, открытую в браузере. Вот ссылка из официальной документации, откуда букмарклет можно добавить в панель закладок.
Эксперименты
Если выбран вариант использования библиотеки, предусматривающий её включение в страницы или импорт с помощью Require.js, можно приступать к экспериментам с гремлинами в коде. В нашем примере показан вызов gremlins.createHorde().unleash(). Давайте разберёмся с тем, что при этом происходит.
В Gremlins.js предусмотрено пять «пород» (species в терминологии библиотеки) «гремлинов» — функций, которые реализуют различные варианты взаимодействия пользователя со страницей. Стандартная «стая» (horde), с настройками по умолчанию, включает в себя все пять пород. А именно, это следующие:
По умолчанию гремлины вызываются случайным образом с интервалом в 10 миллисекунд 1000 раз.
Как уже было сказано, в Gremlins.js имеются не только гремлины, которые вполне способны разорвать сбойную страницу на части. Есть здесь и мирные могваи:
Благодаря протоколированию происходящего и визуализации действий гремлинов, результаты испытания можно проанализировать, и, при необходимости, принять меры по исправлению ошибок.
Фактически, даже без каких-либо настроек, Gremlins.js реализует весьма приличный набор тестов.
Продвинутые эксперименты
Если после использования тестов в стандартной конфигурации вы не добились того, чего хотели, существует достаточное количество способов настройки испытаний. Например, возможно, в каждом сеансе тестирования, вы хотите сконцентрировать усилия лишь на каком-то конкретном компоненте страницы вместо того, чтобы постоянно тестировать её всю.
Селекция гремлинов
Если стандартных возможностей библиотеки вам не хватает, в частности, вас не устраивают существующие породы гремлинов, это легко поправить. Вы можете вывести собственную породу гремлинов, научить их делать всё то, чего вы ожидаете от пользователя вашего проекта.
Например, вам нужно проверить, что произойдёт, если некто попытается отправить форму случайным образом в любой момент работы с её элементами. Можно понадеяться на то, что clickerGremlin когда-нибудь щёлкнет по кнопке отправки, но лучше всего – создать собственного гремлина, который занимается исключительно отправкой формы. Это повысит шансы выполнения данной операции и даст нам контроль над тем, как она выполняется.
Для выведения новых пород гремлинов нужно немного разбираться в том, как создавать и настраивать события DOM в JavaScript. Поэтому давайте рассмотрим процесс создания гремлина, отправляющего форму.
Если вы хотите больше узнать про создание настраиваемых событий, взгляните на документацию Mozilla. Кроме того, стоит посмотреть на исходный код библиотеки, разобраться с тем, как в ней создаются события. Например, можно начать с clickerGremlin.
На самом деле, библиотека поддерживает куда больше способов настройки и расширения, нежели создание новых типов гремлинов. Здесь, например, и добавление новых пород могваев, и выбор сценариев тестирования, и исполнение кода до и после тестов. В конце концов, если вам хочется большего, на основе Gremlins.js можно создать собственный проект, который будет именно таким, каким вы видите JS-библиотеку тестирования интерфейсов.
Неслучайный выбор тестового сценария
Случайным образом выбираемые тестовые сценарии, новая стая гремлинов, появляющаяся после каждого запуска теста, и беспорядочно испытывающая страницу – это отличный способ поиска ошибок. Однако, если ошибка найдена, и вы поработали над её устранением, как убедиться в том, что она и вправду исправлена? В подобной ситуации хорошо бы иметь способ повторить тот тест, который её вызвал, узнать новую реакцию системы на него. Как раз для таких случаев, когда нужно несколько раз повторить один и тот же тестовый сценарий, существует вариант инициализации генератора случайных чисел, на основе которого моделируется поведение стаи. Делается это при помощи функции seed() :
Здесь хотелось бы отметить, что главная ценность обезьяньего тестирования, реализуемого с помощью Gremlins.js – это его непредсказуемость. Поэтому, хотя повтор одних и тех же сценариев полезен, использование лишь таких тестов ставит под вопрос сам смысл хаотического тестирования.
Выводы
Строить предположения о пользователях, основывать на них проектирование и разработку веб-проектов, означает заранее отказываться от учёта невероятного количества особых случаев. У пользователей могут быть медленные каналы связи, не самые новые устройства, да мало ли что и как может быть у конкретного человека. Нельзя гарантировать, что любопытный малыш лет пяти не доберётся до родительского телефона и не начнёт с увлечением тыкать во всё подряд на сенсорном дисплее. К чему это приведёт – большой вопрос. Нельзя заранее узнать о том, что некто из отдела маркетинга, впервые увидев новый сайт, не придёт в такой восторг, что станет, как безумный, щёлкать всё подряд. Ни порядок, ни скорость, ни повторяемость действий предсказать нельзя. Как разработчики, мы обязаны сделать для своих пользователей так, чтобы наши сервисы не валились ни с того ни с сего просто потому, что мы ожидаем от людей строго определённой модели правильного поведения.
Что такое 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 тестирование не требует предварительного планирования, документирования и проектирования тест-кейсов. И если такую задачу поручают специалистам, которые отличаются креативностью и хорошим знанием системы, это тестирование может сэкономить много времени и выявить больше багов, чем спланированное.