Исследовательское тестирование: ошибки и заблуждения

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

Именно поэтому наиболее удачным решением может оказаться выбор исследовательского тестирования в моно-варианте. Поскольку сам термин «исследование» подразумевает индивидуальную заинтересованность и вовлеченность в процесс, мы все сразу же задумываемся о подводных камнях данного подхода.

Конечно, говоря о тестировании, нельзя не упомянуть распространенные ошибки самих тестировщиков. Есть такой психологический момент: если не обозначены рамки, то начинает казаться, что можно делать всё, что угодно. И этот процесс будет называться тестированием. Многие начинающие тестировщики совершенно необоснованно думают, что «исследовательское» тестирование позволяет не соблюдать основные принципы тестирования.

Заказчики и их заблуждения

Исследовательское тестирование не контролируемо и не управляемо

Представим, что задание на тестирование получено. Мы радостно потираем руки в предвкушении интересной динамичной деятельности, и тут приходит менеджер и говорит: «Ребят, да вы что, с меня голову снимут за ваши эксперименты! А как мы отчитаемся по покрытию функционала тестами? А как вы время оцените?». Резонные опасения, не правда ли? Так мы узнаём, что нашему менеджеру не хватает уверенности в том, что мы сможем грамотно выстроить процесс тестирования и представить его результаты в надлежащем виде.

На самом деле это сомнение очень заботит многих людей, которым предстоит принимать важные решения по продукту на основании результатов тестирования. Спешу успокоить — на этот случай есть несколько эффективных алгоритмов:
    • для начала проводится тщательный анализ продукта, его декомпозиция и определение приоритетных направлений для тестирования, которые можно и нужно документировать — всё это несомненно поможет команде тестирования не упустить важные детали;
    • если в процессе тестирования выявляются новые, непредусмотренные изначально варианты проверки, их можно обработать и зафиксировать;
    • в оценке времени на тестирование нам поможет как прошлый опыт, так и суммирование оценок на тестирование менее масштабных задач;
    • изначальный план дополняется и корректируется уже в процессе тестирования, что помогает держать его в актуальном состоянии. В итоге он превращается в прекрасный отчет, отражающий тестовое покрытие.

Исследовательское тестирование — не для новичков

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

В ряде случаев это может быть действительно так. Однако, если участников тестирования больше одного, с таким подходом можно и поспорить. В качестве примера расскажу случай из практики. К нам поступила срочная и неожиданная заявка на тестирование нового проекта — это была CMS (админка) для одного приложения. В качестве ресурсов у нас был один опытный тестировщик и один стажер. Мы решили сделать план админки и детализировать его с учетом предположений опытного тестировщика.

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

Таким образом, вовлекая в процесс исследовательского тестирования менее опытных членов команды, мы можем взглянуть на продукт другими глазами: не в разрезе проверяемого функционала, а опираясь на возможности разных членов команды. К тому же сфера тестирования располагает различными подходами к исследовательскому тестированию:
      • использование чит-листов;
      • сессионное тестирование;
      • парное тестирование;
      • тест-туры Джеймса Виттакера (James A. Whittaker).

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

Исследовательское тестирование не подходит для регрессионных проверок

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

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

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

Тестировщики и их заблуждения

Исследование продукта с целью дальнейшего написания тестов — это и есть исследовательское тестирование

Многие скажут, что это утверждение верно, и будут по-своему правы, ведь исследование проводится и в том, и в другом случае. Я же думаю, что имеет смысл разделять понятия «тестирование» и «тест-анализ».

По сути, готовясь к написанию тестов, мы действительно проводим исследование: выполняем анализ имеющейся документации, продумываем стратегию, расставляем приоритеты — то есть, определяем, ЧТО и КАК будем тестировать.

Если говорить об исследовательском тестировании, то конечной целью этого процесса является ответ на вопрос: «Насколько наш продукт соответствует этим ожиданиям?» Да, мы тоже проектируем тесты на ходу, но это лишь часть глобального процесса. Разные цели — разный результат, так что не совсем уместно называть исследовательским тестированием только подготовку к написанию тестов.

Исследовательское тестирование базируется на идее беспорядочного выполнения различных действий

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

Для исследовательского тестирования не нужна предварительная подготовка

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

Необязательно своевременно актуализировать статус проверок

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

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

А напоследок я скажу…

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

Об авторе

Занята в сфере IT и тестирования с 2011 года. Организовывала тестирование разнообразных программных продуктов. В данный момент работает тест-менеджером на крупном государственном проекте.

Поиск
Облако меток
8 марта (1)api (5)Game of testers (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)Опрос (1)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (6)аудит (2)аудит тестирования (2)аутсорс (4)баги (4)банковские приложения (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (13)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (21)лайф-хаки (3)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (13)обучение (8)оптимизация тестирования (13)оффлайн тренинги (1)поздравление (1)поздравления (6)пользовательские истории (1)пример (2)проблемы (2)проектные риски (1)проекты (4)процесс тестирования (25)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (1)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (4)управление рисками (1)успехи (5)целевая аудитория (3)юзабилити (3)
Получите совет