Ad-hoc тестирование – это исследовательский подход к тестированию программного обеспечения, при котором тестировщик не следует заранее составленному плану тестирования. Основная задача тестировщика — проанализировать работу приложения совершенно рандомным образом. Суть его в том, что тестировщики тестируют приложение или продукт случайным образом, без тест-кейсов.
Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску, чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. То есть, тестировщик может продолжать работу по тестированию белого ящика, хотя программа уже «бета-стадии», но в этом случае он не является частью «бета-тестирования». Но для этого у тестера должно быть общее понимание процесса и знание тестируемого продукта.
Разница между ad-hoc и exploratory testing в том, что теоретически, ad-hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определёнными техниками. Чаще всего такое тестирование выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. При этом тестировщик полагается на свое общее представление о продукте, сравнение с похожими продуктами, собственный опыт. Однако при тестировании ad-hoc имеет смысл владеть общей информацией о продукте, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении и основных функциях и возможностях. Это типично для компонентного тестирования, при котором тестируются только отдельные части системы.
Для проведения подобных проектов могут использоваться практически любые методы исследований. Методики подбираются только под поставленные перед исследователями задачи, для того чтобы предоставить заказчику точную и актуальную информацию. В связи с этим, куда практичнее продемонстрировать, что именно можно проанализировать и задокументировать в целях исследования. Каждый подход к тестированию должен выявлять те части приложения, которые могут выиграть от более тщательного внимания. Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию).
Это включает в себя настройки оборудования, программного обеспечения и сети. Дополнительный плюс ad-hoc тестирования — тестировщик проводит его в свободной форме, согласно своему пониманию системы. Он может добавлять различные проверки уже по ходу работы, что помогает выявлять ошибки. Благодаря этому можно найти баги, которые обычно проскакивают незамеченными. Благодаря им ad-hoc тестирование может стать более структурированным и эффективным.
После завершения тестирования необходимо проанализировать результаты, чтобы выявить тенденции и закономерности в обнаруженных дефектах и проблемах. Команда тестировщиков должна дать рекомендации по улучшению ПО и предоставить обратную связь команде разработчиков, чтобы помочь улучшить качество приложения. Хотя интуитивное тестирование часто бывает неструктурированным и гибким, создание плана тестирования, в котором описываются цели, методы и ожидаемые результаты, все равно важно. План также должен определять роли и обязанности каждого члена команды и включать график тестирования. Самый интересный аспект ad-hoc тестирования — отсутствие каких-либо методик продумывания тестов. Но, вместе с тем, воспроизвести это тестирование сложно, поскольку нет ни написанных тест-кейсов, ни документации.
Основные Преимущества Ad-hoc Testing:
В таком случае сроки поджимают, продукт нужно выводить на рынок уже вчера, а совсем без тестирования выпускать ПО никак нельзя, там будет полно багов. После определения тестовой среды и требований к данным перед началом тестирования важно убедиться, что они правильно установлены и настроены. Может понадобиться установка и настройка программного обеспечения, создание тестовой среды и подготовка тестовых данных. Тестовая среда должна быть настроена таким образом, чтобы максимально точно имитировать среду конечного пользователя.
В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования.
Главная цель ad-hoc тестирования — обнаружить баги при помощи случайных проверок. Таким образом удается выловить очень специфические и любопытные баги, которые легко пропустить, применяя другие методы. Однако при тестировании ad-hoc тестировщик должен иметь полные знания и осведомленность о тестируемой системе, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении, основных функциях и возможностях.
Примечания[править Править Код]
Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся.
Последнее особенно полезно, когда уровень знаний у тестировщиков различается. Поскольку нет никакой применимой документации, все что остается использовать тестировщику — здравый смысл, логику и накопленный опыт. Стоит отметить что любое, даже не очень знакомое вам приложение должно быть интуитивно понятным. Тестирование ad-hoc имеет смысл только в случае если тестировщик владеет общей информацией о продукте.
Adhoc тестирование может быть достигнуто с помощью методики тестирования программного обеспечения, называемой « угадывание ошибок». Люди, обладающие достаточным опытом работы с системой, могут угадывать ошибки, чтобы «угадать» наиболее вероятный источник ошибок. По мере выполнения тестов команда тестировщиков должна записывать результаты и сообщать о своих выводах. Это включает в себя документирование любых дефектов и обнаруженных проблем, а также любых положительных отзывов или предложений по улучшению. Исследовательское тестирование (exploratory testing) — это одновременное изучение программного продукта, проектирование тестов и их выполнение.
Вместе с тем оно может оказаться менее тщательным и эффективным, чем формальные методы тестирования. Это связано с тем, что из-за отсутствия планирования тестировщик может упустить некоторые важные аспекты ПО. Основное преимущество ad hoc тестирование ad-hoc тестирования — возможность выявить баги, которые остались бы незамеченными при других проверках. А поскольку для такого тестирования не нужно ничего планировать и структурировать, оно экономит много времени.
Вы можете провести тест для выявления таких проблем, как плохая навигация, запутанные макеты или сложные в использовании функции. Целью является выявление потенциальных проблем производительности или узких мест в системе путем имитации реального использования и нагрузки. Это тестирование фокусируется на функциональных требованиях к программному обеспечению.
Такой подход позволяет QA-специалистам обнаружить проблемы, которые не были выявлены с помощью более структурированных методов тестирования. Тестировщики могут выполнять конкретные тесты, связанные с функциональными требованиями к ПО, но также могут свободно исследовать другие области приложения. Однако важно отметить, что ad-hoc тестирование не должно быть единственным используемым подходом. Его непременно нужно дополнять более формальными методами тестирования, такими как регрессионное и модульное. QA-специалист, проводящий ad-hoc тестирование, должен хорошо знать тестируемое приложение и его основные функции.
Именно поэтому тестировать по принципу ad-hoc может только тот человек, который понимает, что из себя представляет продукт. Его нет ни для изучения продукта, ни для составления плана, ни для документирования процесса тестирования. В том числе следует решить, на каких аспектах ПО и типах дефектов будет сосредоточено тестирование и каковы ожидаемые результаты. Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов (а что подразумевается под формальными тестами?).
Постоянное Совершенствование Процесса Тестирования
Для каждого действительного дефекта должны быть написаны соответствующие контрольные примеры и они должны быть добавлены в запланированные контрольные примеры. Каждому багу следует присвоить уникальный идентификатор и отслеживать его до момента устранения. Тестировщики должны сотрудничать с разработчиками для предоставления обновлений по дефектам и обеспечения их своевременного устранения.
Ad-hoc тестирование не требует предварительного планирования, документирования и проектирования тест-кейсов. И если такую задачу поручают специалистам, которые отличаются креативностью и хорошим знанием системы, это тестирование может сэкономить много времени и выявить больше багов, чем спланированное. Основной недостаток ad-hoc тестирования состоит в том, что сам процесс тестирования не документируется, поскольку идет не по конкретному набору тест-кейсов. Для этого тестировщику приходится вспоминать, какие шаги привели его к нужной точке. Суть парного тестирования в том, что тестировщики работают вместе на одной машине и при этом делятся идеями и знаниями.
- Также важно, чтобы группа тестирования имела доступ к тестовой среде и данным и могла работать с ними контролируемым и безопасным образом.
- Эффективное управление тестовыми данными позволяет обеспечить надлежащую защиту конфиденциальных данных и исключить их использование в среде тестирования.
- Если они обнаруживают какие-либо проблемы с заявкой, они фиксируют их в неформальной обстановке и обсуждают дальнейшие шаги команды.
- Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску, чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой.
Но его также можно проводить и в процессе разработки, и после его завершения. Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов. Этот метод может быть успешным только без структуры или документации, и очень важно, чтобы тестировщики помнили об этом на каждом этапе. Даже без официального документирования, ведение записей может позволить команде неформально отслеживать отдельные специальные проверки.
После определения подхода к тестированию команда должна приступить к тестам, выполняя различные действия и наблюдая за реакцией приложения. После подбора команды тестировщиков важно убедиться, что все члены команды имеют необходимую подготовку и ресурсы для эффективного проведения ad-hoc тестирования. Может потребоваться обучение работе с конкретными инструментами или методам тестирования, предоставление доступа к тестовым средам и данным, а также налаживание каналов связи с командой разработчиков. Когда стоит проводить ad-hoc тестирование
Создание плана может помочь обеспечить эффективность ad-hoc тестирования и его соответствие общим целям проекта. Следующие finest practices гарантируют, что время на тестирование будет потрачено с умом, а шансы на успех будут максимальными. Описанные выше методы тестирования имеют основательные сходства и различия, поэтому стоит разделять эти две популярные методики в рамках тестирования.