Определенные функции пользуются повышенным спросом, и команда тестирования может извлечь выгоду, определив их приоритетность во время проверок. Это может определить направление тестирования, а также потенциальный успех программного обеспечения при запуске. Исследовательское тестирование направлено на разработку новых и креативных тестов, которые могут выявить проблемы в приложении. Это могут сделать даже тестировщики с ограниченным опытом, при условии, что они понимают программное обеспечение. Автоматизация выявляет проблемы, но команды тестирования и разработки несут ответственность за их устранение.
Либо выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. Исследовательское тестирование лучше всего подходит в ситуациях, когда документация недостаточная, либо вовсе отсутствует, в условиях очень ad hoc тестирование сжатых сроков и как дополнение к другим, более формальным, методам тестирования. Если при тестировании на основании тест-кейсов мы не отклоняемся, то, в случае с исследовательским тестированием, мы сами решаем куда отклоняться и в каком направлении двигаться.
Они могут экспериментировать, создавать разные сценарии и проверять систему с разных точек зрения. Исследовательское тестирование не имеет конкретного завершения, так как оно может быть внедрено в любой этап разработки. Однако важно уделить время для документирования результатов, создания отчетов о найденных дефектах и обмена информацией с командой разработки. Исследовательское тестирование требует от тестировщиков развития навыков исследования. Даже если тест-кейсы не предварительно определены, важно вести записи о процессе исследования. Регресс считается законченным именно тогда, когда пройдены все сценарии, и время на их прохождение в большинстве случаев согласовано с заказчиком или продактом.
При этом тестировщик полагается на свое общее представление о продукте, сравнение с похожими продуктами, собственный опыт. Однако при тестировании ad-hoc имеет смысл владеть общей информацией о продукте, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении и основных функциях и возможностях. После документирования дефектов и проблем команда должна определить их приоритетность в зависимости от их серьезности и влияния на приложение.
Общение очень важно при проведении парного тестирования, так как это позволяет убедиться, что оба тестировщика знают о проверках и их целях. Этот тур продвигает приложение дальше, тестируя самые сложные функции с более высокими (иногда максимальными) значениями, чтобы определить скорость обработки программного обеспечения. Исследовательское тестирование обычно проводится в формате “экскурсии” – когда тестировщик исследует программное обеспечение наиболее эффективным способом.
Этот тип тестирования используется, когда приложение является сложным, плохо изученным, или ограничения по времени не позволяют использовать более формальный подход к тестированию. Ad-hoc testing — это особый вид тестирования, не предполагающий никакой подготовки или планирования, здесь нет тестовых сценариев, как и какого-либо ожидания от результата. Нет нужды разрабатывать и придерживаться какого-либо плана, или вести документацию, нет никаких тест-кейсов (правда, от этого могут возникнуть трудности с тем, чтобы воспроизвести ошибку – никаких планов и документов то нет). Исследовательское тестирование имеет четкие цели и границы, но при этом позволяет членам команды использовать творческие тесты. Специальные тесты обычно не имеют определенных конечных целей, кроме как подтолкнуть программное обеспечение к тому, что оно может.
Старшие тестировщики особенно искусны в интерпретации журналов приложения, что позволяет им определить причину сложных проблем. Сами результаты принимают различные формы, поскольку исследовательское тестирование может включать в себя сотни уникальных тестов. Эти результаты составляют большую часть выходных данных процедуры тестирования, предоставляя жизненно важную информацию о состоянии приложения и его способности удовлетворять потребности пользователя. Команды тестирования программного обеспечения могут использовать эмуляторы для облегчения исследовательских проверок; это может быть полезно, но редко отражает практическую среду пользователя.
Различия Между Исследовательским Тестированием И Специальными Тестами
Но для этого у тестера должно быть общее понимание процесса и знание тестируемого продукта. Именно поэтому тестировать по принципу ad-hoc может только тот человек, который понимает, что из себя представляет продукт. Его нет ни для изучения продукта, ни для составления плана, ни для документирования процесса тестирования. Команды тестирования должны выполнять эти проверки наряду с обычными сценарными тестами; это единственный способ, с помощью которого отделы обеспечения качества могут обеспечить стабильно широкий охват тестами. Хотя для исследовательских проверок не требуется предварительное знание программного обеспечения или особо глубокие навыки, проверки все равно зависят от способностей и инициативы отдельных членов команды.
Несмотря на это, на некоторых проектах я сталкивалась с тем, что тестировщики начинали отклоняться от заданного курса и занимались просто поиском багов параллельно с тест-кейсами регресса. А в некоторых ситуациях регресс приходится проходить и вовсе без пошагового планирования. Это особенно актуально для “молодых” проектов, а также для продуктов, существовавших до этого вообще без тестирования. Не существует четких ограничений на типы проверок, которые относятся к разведочному тестированию; этот подход может охватывать все аспекты программного обеспечения, включая код.
Целью является выявление потенциальных проблем производительности или узких мест в системе путем имитации реального использования и нагрузки. Это тестирование фокусируется на функциональных требованиях к программному обеспечению. Тестировщики могут выполнять конкретные тесты, связанные с функциональными требованиями к ПО, но также могут свободно исследовать другие области приложения. Поэтому, каждая компания самостоятельно выбирает какому из видов тестирования отдавать приоритет, а каким и вовсе не стоит заниматься в данный момент. К любому процессу можно применять как формальные подходы (то есть по установленному порядку), так и те, которым до формальных очень далеко.
Тестирование на основе стратегии включает в себя широкий спектр специальных методов, в том числе тестирование граничной стоимости, методы эквивалентности, методы, основанные на риске, и многое другое. В этом случае предпочтение обычно отдается тестировщикам, которые уже знакомы с приложением, поскольку они могут разработать индивидуальные стратегии, включающие эти отдельные методы. При таком подходе приоритет отдается основным функциям приложения, что позволяет точно воспроизвести работу обычного пользователя https://deveducation.com/ с программой и выявить проблемы, которые он обнаружит естественным образом. Этот подход предполагает использование специального программного обеспечения, которое записывает действия тестировщиков, предоставляя им простые шаги для воспроизведения любой обнаруженной ими проблемы. Обычно это делается в виде видеоролика, в котором тестировщик дает комментарии, объясняющие его действия шаг за шагом. Активные тесты имеют более широкий охват, не жертвуя специфичностью торговой марки исследовательских проверок.
Совместная работа делает любую форму тестирования более эффективной за счет лучшего знакомства каждого члена команды с программным обеспечением. Изучение внутренней работы этого программного обеспечения может быть совместным процессом, обеспечивающим лучшее понимание в команде. Это позволяет тестировщикам разрабатывать более качественные проверки и тестовые случаи. Это означает, что тестировщики должны активно работать с программным обеспечением и выяснить, как оно работает, прежде чем разрабатывать тесты. Чтобы избежать недопонимания, команды тестирования должны составить четкий список каждой функции и проверок, которые они собираются выполнить. Это также означает, что тесты должны быть адекватно распределены по функциям программного обеспечения.
Преимущества И Недостатки Ad-hoc Testing
Хотя это может занять больше времени из-за того, что человеческие тестеры медленнее компьютеров, ручная проверка может сыграть важную роль в определении пользовательского опыта. Кроме того, исследовательское тестирование значительно лучше поддается адаптации, в то время как скриптовые тесты могут испытывать трудности в случае значительных изменений в программном обеспечении. Исследовательские тесты могут быстрее обнаружить ошибки и принять меры по их устранению, что делает первые особенно полезными в случаях, когда быстрая обратная связь имеет первостепенное значение.
- Однако зачастую это возможно только для ошибок, затрагивающих незначительные части программного обеспечения.
- Если человек совсем не будет знать продукт, то потратит время на его изучение, особенно если проект очень сложный и большой.
- По мере усложнения программного обеспечения возрастает вероятность появления ошибок; это может потребовать более тщательного тестирования.
- Взаимодействие между участниками может привести к обнаружению различных дефектов и идей для улучшения продукта.
Это связано с работой, которую они проделали, чтобы понять программное обеспечение – первый этап исследовательского процесса. Автоматические исследовательские тесты могут заметить несоответствия в программном обеспечении, но не смогут интерпретировать эти проблемы так же, как тестировщик-человек. Ручное исследовательское тестирование позволяет проводить более широкий спектр специальных проверок.
Главное, что нужно помнить об исследовательском тестировании, это то, что само по себе оно не является методикой тестирования. Еще один важный момент заключается в том, что исследовательское тестирование – это не только выполнение тестов. Тестировщики могут применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов. Также, исследовательское тестирование не должно выполняться небрежно, в спешке и без подготовки. Исследовательское тестирование может проводиться вручную, а может осуществляться с широким применением средств автоматизации, т.е.
Он может помочь обеспечить эффективность тестирования и его соответствие общим целям проекта. Свободное (интуитивное) тестирование (ad hoc testing) — полностью неформализованный подход, в котором не предполагается использования ни тест-кейсов, ни чек-листов, ни сценариев. Каждая из этих техник имеет свои преимущества и недостатки, и выбор зависит от конкретных потребностей и характеристик тестируемого приложения. Комбинирование разных техник исследовательского тестирования может быть наиболее эффективным способом обнаружения дефектов и улучшения качества программного продукта. Перед началом исследовательского тестирования тестировщики могут изучить доступную документацию, такую как технические спецификации и функциональные требования. Исследовательское тестирование дает свободу тестировщикам исследовать приложение, не ограничиваясь заданными сценариями.
Веб-сайты также проходят исследовательское тестирование, чтобы убедиться, что они работают как для пользователей, так и для персонала, поэтому тестировщики могут начать с входа на сайт. Это тестирует способность сайта создавать новые профили пользователей и проверяет, что пользователи не могут получить доступ к административным функциям. В этом сводном отчете о тестировании может быть даже сделан вывод о том, что в ходе проверок были допущены эксплуатационные ошибки, которые требуют повторного тестирования.
Платное решение может быть единственным способом удовлетворить потребности данного проекта; команда должна изучить различные варианты, прежде чем принять решение о выборе приложения. Testiny специализируется на ручном разведочном тестировании и предлагает интеллектуальный редактор, позволяющий тестировщикам разрабатывать проверки с использованием древовидной структуры для максимальной гибкости. Этот вариант полностью фокусируется на перспективе пользователя и предлагает централизованный центр результатов для обновления информации другими тестировщиками. Различные варианты сторонних производителей предлагают свои уникальные возможности, поэтому выбор команды может определить успех роботизированной автоматизации процессов; они должны рассмотреть все возможные варианты. Команда тестировщиков должна взять на себя обязательство обеспечить качественное ведение записей в ходе каждой проверки, предоставляя как можно больше подробностей в каждом отчете. Будь то автоматизированный отчет об ошибке или ручная запись выполненных тестов, хорошая документация упрощает разработчикам принятие мер в соответствии с выводами команды тестирования.
Каждый вид тестирования должен иметь строгую документацию, чтобы убедиться, что каждый член команды следует ожидаемому графику тестирования и что никто случайно не повторит проверку. Это усложняет отслеживание изменений и правок программного обеспечения с течением времени – автоматизированные программы обычно способны интуитивно учитывать это при выполнении тестов. Это включает в себя понимание того, как пользователи программного обеспечения, скорее всего, будут перемещаться или взаимодействовать с приложением, что автоматизация не может учесть. Время может стать ограничением, поскольку цель команды – протестировать как можно больше сценариев; в зависимости от предстоящих сроков, скорее всего, не удастся охватить все возможности. Хартия определяет рамки каждой сессии и детализирует любые конкретные цели, которые тестировщик намерен достичь.
Также на данный вид тестирования не пишутся тест-кейсы, что в свою очередь может вызвать определенные затруднения в попытках воспроизвести дефект в системе. Такой вид зачастую может дать сходу больше результата чем тестирование по заранее определенным сценариям. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основного функционала и выполняет нестандартные проверки, точнее некоторые из его проверок будут нестандартными. Это помогает тестировщикам обнаружить проблемы в приложении, которые в противном случае могут остаться незамеченными до запуска и привести к тому, что ключевые функции не будут работать. Ad-hoc testing — это более интуитивное и беспорядочное тестирование, когда тестировщик просто идет и проверяет, что ему хочется.
Тестировщики могут проводить тестирование шаг за шагом, последовательно проходя через разные части приложения. Это помогает систематически проверять каждую функциональность и выявлять дефекты на ранних этапах. Коллективное исследование, где тестировщики делятся опытом и находками, может быть очень продуктивным. – LinkedIn’s Exploratory Testing; здесь показано, как современное тестирование программного обеспечения использует исследовательские проверки. – Полный курс тестирования программного обеспечения 2023 от Udemy; это обучение широкому тестированию программного обеспечения в течение 28 часов. Сочетание ручного и автоматизированного разведочного тестирования может обеспечить наибольшую пользу, позволяя уделять равное внимание всем компонентам программного обеспечения.