Узнайте, что такое Ad Hoc тестирование, когда его применять и как эффективно находить ошибки без строгого тест-плана.

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

Когда проводится Ad-hoc testing?

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

Кто проводит Ad-hoc testing?

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

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

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

Buddy Testing.

Суть этой проверки заключается в том, что два и более компаньона (buddies) пытаются одновременно найти баги в одном и том же модуле или системе. Их роли могут исполнять программист и тестировщик. Они имеют разную специализацию, но оба в достаточной мере знают продукт, чтобы проверять его без предварительной подготовки и изучения.

Плюсы Buddy Testing

– Участники разработки лучше понимают сам продукт. Это позволит довести программное обеспечение до соответствия всем ожиданиям.

– Разносторонний взгляд помогает обнаружить неочевидные проблемы на ранних стадиях и устранить их до того, как они станут серьезными.

– Члены команд из разных подразделений обмениваются знаниями и опытом. Это способствует поиску нетривиальных решений, способных существенно улучшить продукт и привнести в него что–то уникальное.

Минусы Buddy Testing

– Результаты тестирования могут оказаться излишне субъективными, если участники проверки имеют одинаковые взгляды на поиск и решение проблем.

– Если нагрузка на сотрудников распределена неравномерно в соответствии с графиком работ, то будет трудно выделить время на совместную проверку продукта.

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

Monkey Testing.

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

Плюсы Monkey Testing

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

– Monkey Testing прост в реализации, так как для него не требуются детально проработанные тестовые сценарии. Это позволяет сэкономить время, что важно для ранних этапов разработки, когда функциональность всё ещё находится в стадии изменений.

Минусы Monkey Testing

– Результаты тестирования могут быть трудными для интерпретации, потому что все действия производятся случайным образом. Особенно тяжело, если в процессе проверки не велась никакая документация. Впоследствии это может привести к тому, что некоторые неочевидные ошибки так и останутся незамеченными.

– Monkey Testing не дает достаточной глубины тестирования из–за своих ограниченных условий и непродуманности действий. В этом случае остается полагаться только на опыт тестировщика и удачу.

Pair Testing

В отличие от Buddy Testing, в этом случае проверка осуществляется исключительно тестировщиками, без участия разработчиков. Кроме того, этот подход подразумевает тестирование только одного модуля. Тестировщики делят между собой роли, чтобы один мог вести документацию, а второй изучать продукт и проверять его функции.

Плюсы Pair Testing

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

– Работая над одним и тем же модулем, тестировщики могут сфокусировать свое внимание на разных аспектах. Один может проверять функционал, а второй сосредоточиться на интерфейсе.

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

Минусы Pair Testing

– В случае, если между участниками тестирования нет доверительных отношений и открытой коммуникации, эффективность результатов будет снижена. Это не только отразится на производительности процесса и качестве продукта, но также может стать причиной возникновения конфликтов.

– Наличие двух тестировщиков на одной задаче повышает расходы. Это не всегда оправданно, особенно, если речь идет о начальных этапах разработки.

– Важно, чтобы уровень квалификации специалистов был примерно одинаковым, чтобы им было проще взаимодействовать между собой. Кроме того, более опытный тестировщик будет меньше переживать за то, что ему придется проверять работу ещё и за коллегой, так как нет уверенности в том, что тестирование прошло успешно.

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

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

Первое: определение области тестирования.

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

Второе: анализ требований и спецификаций.

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

Третье: фиксация результатов.

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

Четвертое: обратная связь.

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

Ad-hoc тестирование не требует строго соблюдения формальностей, но все–таки определенный алгоритм действий выработать необходимо, чтобы хотя бы немного упорядочить хаос. Это позволит сократить риски.

Существует несколько советов, которые позволят сделать процесс интуитивного тестирования более продуктивным и полезным.

– После каждого тестирования необходимо проводить анализ обнаруженных багов. Эта практика позволит улучшить свои навыки и опыт, что в дальнейшем можно будет применить при проверке аналогичных ПО.

– Не стоит составлять подробный план действий или сценарий, но можно сделать набросок пути в качестве ориентира. Если тестировщик или программист уже ранее имел дело с аналогичным продуктом, то он может предположить, в каком направлении искать баги. Визуализация этой информации в виде короткой заметки позволит не упустить важных нюансов.

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

– Сначала нужно проверить области, не покрытые тест–дизайном и тестовой документацией.

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

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

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

Интуитивное тестирование является быстрым способом проверки программного продукта в ограниченных условиях. Чтобы эффективно использовать этот подход, необходимо понимать его основные преимущества и недостатки.

Плюсы ad-hoc testing

– Это гибкий метод проверки программного обеспечения в целом или его отдельных модулей в частности. К тому же он ещё и очень быстрый, так как не требует заблаговременной подготовки и изучения ПО. Подразумевается, что тестировщик уже знает продукт.

– Метод удобно применять при динамичном проектировании, когда сроки разработки ограничены либо когда к программному продукту часто возникают новые требования. Это наилучший вариант вместо того, чтобы совсем отказаться от проверки.

– Дополнительно интуитивное тестирование проводят для поиска скрытых проблем, которые не удалось обнаружить при формальных проверках по сценарию.

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

– С каждой новой проверкой баги будут находиться все быстрее и легче, так как уже имеется наработанная база знаний и опыта. Это повышает ценность сотрудника, что компания может использовать себе на пользу.

Минусы ad-hoc testing

– Отсутствие системности снижает качество и эффективность проверки продукта. Иначе говоря, возрастает риск того, что важные баги будут пропущены.

– Недостаток времени на полноценную документацию снижает возможность воспроизвести условия, при которых была обнаружена проблема. Даже минимальные записи не всегда могут оказаться полезными.

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

– Проверку должны проводить опытные и высококвалифицированные специалисты, способные двигаться в новом продукте на ощупь, но при этом все–равно находить типичные для этого программного обеспечения баги.

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