Исследовательское Тестирование: Когда Его Стоит Применять И Как Это Делать Хабр

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

Часто его применяют в случаях, когда нет тест-кейсов для исследования некоторого аспекта поведения продукта. Либо выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. Ключевым фактором успеха при выполнении исследовательского тестирования является именно работа по сценарию, а не выполнение разрозненных бездумных операций.

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

По Сценариям

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

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

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

Buddy Testing

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

Он написал книгу в соавторстве с Тревором Пинчем про конструирование научного знания; другую книгу вместе с Робом Эвансом, про опыт; и третью о том, как ученые оценивают отдельные результаты экспериментов. Эпоха ИТ 2.zero длилась довольно долго и основывалась на таком ключевом понятии как исследовательско-сценарный континуум. В 1999 году Джеймсу поручили разработать формализованный процесс исследовательского тестирования для Microsoft. Идея “формального ad hoc тестирования” казалась парадоксальной и спровоцировала конфликт, который был разрешен путем конструктивных споров между Джеймсом и Кемом. Эти дебаты повлекли за собой рождение концепции, которую мы определяем как ИТ 2.zero. Изначально никто не разделял исследовательское тестирование и тестирование по сценариям.

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

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

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

Если вы занимаетесь только сценарным тестированием, то вы на самом деле немотивированно проверяете, а не тестируете по-настоящему. Существует даже специальный сценарный подход, называемый сессионным тестированием (session-based testing). Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов (а что подразумевается под формальными тестами?). Но его также можно проводить и в процессе разработки, и после его завершения. Дополнительный плюс ad-hoc тестирования — тестировщик проводит его в свободной форме, согласно своему пониманию системы.

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

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

“Не относящееся к знанию” звучит как “глупое”, как приговор проверкам. Иногда необходимо потратить массу времени на подготовку и объяснение тестов для изменения дизайна программы. С интуитивным тестированием нет необходимости тратить время, так как оно не требует спецификаций и планирования. Когда стоит проводить ad-hoc тестирование Ad-hoc testing бывает полезным, когда у вас нет времени на длительный и всеобъемлющий процесс тестирования, требующий подготовки требований и тест-кейсов. Также ad-hoc тестирование не гарантирует, что все ошибки будут найдены.

Таким образом QA может найти ошибки, которые не вошли бы в тест-кейсы, и обеспечить их устранение. Под “сценарием” мы понимаем любую систему контроля или факторы (даже временные), влияющие на тестирование и лежащие за пределами сферы влияния тестировщика. Сценариями могут быть не только четкие инструкции, которым вы должны следовать.

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

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

Работать с тестовыми данными также лучше при помощи мощных инструментов. Это поможет обеспечить согласованность и точность ad hoc тестирование тестовых данных и сэкономит время. Тестировщики должны сообщить о найденных дефектах команде разработчиков.

Этот тип тестирования используется, когда приложение является сложным, плохо изученным, или ограничения по времени не позволяют использовать более формальный подход к тестированию. Ad-hoc тестирование – это исследовательский подход к тестированию программного обеспечения, при котором тестировщик не следует заранее составленному плану тестирования. Мы смогли воспринять тестирование таким образом, так как за прошедшие десять лет приобрели глубокое понимание навыков и элементов тестирования. Оно перестало быть неким “креативным и загадочным” умением, с которым рождаются. То, что мы назвали “исследовательским тестированием” в девяностых, стало называться “свободным (freestyle) исследовательским тестированием”. Интуитивное тестирование (англ. advert hoc testing)– это вид тестирования, который выполняется без спецификаций и планирования.

Более подробно прочитать про данный вид тестирования можно в статье “Основы тестирования. Например, в прошлой версии системы управления больницей модуль отчетов зависал и выдавал ошибки, и возможно есть смысл сейчас протестировать его в первую очередь. Суть такого тестирования заключается в исследовании программы, то есть в изучении ее поведения. Тестировщик сам решает, что делать, когда, в каком объеме, и в каком порядке. Обычно проводится при нехватке времени, а также когда требования заказчика недостаточно ясно и полно сформулированы.

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