Когда тестирование программного обеспечения выполняется без надлежащего планирования и документирования, это называется Adhoc Testing. Такого рода тесты выполняются только один раз, если мы не выявим дефекты.
Adhoc тесты проводятся после формального тестирования приложения. Adhoc методы являются наименее формальным типом тестирования, поскольку это НЕ структурированный подход. Следовательно, дефекты, обнаруженные с помощью этого метода, трудно воспроизвести, поскольку для этих сценариев нет согласованных тестовых случаев.
Тестирование проводится с ведомом тестировщика о приложении, и тестировщик тестирует в произвольном порядке без соблюдения спецификаций / требований. Следовательно, успех тестирования Adhoc зависит от возможностей тестировщика, который проводит тестирование. Тестер должен находить дефекты без какого-либо надлежащего планирования и документации, основываясь исключительно на интуиции тестера.
Когда проводить тестирование Adhoc?
Adhoc тестирование может быть выполнено, когда есть ограниченное время, чтобы сделать исчерпывающее тестирование и обычно выполняется после формального выполнения теста. Adhoc-тестирование будет эффективным только в том случае, если тестировщик глубоко разбирается в тестируемой системе.
Тестирование друзей: два друга, один из команды разработчиков и один из команды тестирования, совместно работают над выявлением дефектов в одном модуле. Приятное тестирование помогает тестировщикам разрабатывать лучшие тестовые примеры, в то время как команда разработчиков также может вносить изменения в проект на ранней стадии. Этот вид тестирования обычно происходит после завершения модульного тестирования.
Парное тестирование: двум тестерам назначены одинаковые модули, и они обмениваются идеями и работают в одних и тех же системах для поиска дефектов. Один тестер выполняет тесты, в то время как другой тестер записывает записи о своих выводах.
Обезьяна Тестирование: Тестирование выполняется случайным образом без каких-либо тестовых случаев, чтобы сломать систему.
Подготовка. При получении сведений о дефектах в похожем приложении вероятность обнаружения дефектов в приложении возрастает.
Создание грубой идеи: создавая грубую идею на месте, у тестера будет целенаправленный подход. НЕ требуется документировать подробный план относительно того, что тестировать и как тестировать.
Разделяй и властвуй: проверяя приложение по частям, мы лучше сфокусируемся и лучше поймем проблемы, если они есть.
Ориентация на критические функциональные возможности. Тестировщик должен ориентироваться на те области, которые НЕ охватываются при разработке тестовых случаев.
Использование инструментов: Дефекты также можно выявить с помощью профилировщиков, отладчиков и даже мониторов задач. Следовательно, будучи опытным в использовании этих инструментов, можно обнаружить несколько дефектов.
Документирование результатов: хотя тестирование проводится случайным образом, лучше документировать тесты, если позволяет время, и записывать отклонения, если таковые имеются. Если дефекты обнаружены, создаются соответствующие тестовые наборы, чтобы помочь тестировщикам повторно протестировать сценарий.