Парное тестирование — возьмём от ХР лучшее

Вячеслав Панкратов, автор проекта "Тестер", http://software-testing.ru

Совершенно верно, парное тестирование, то есть работа двух тестировщиков в паре над одной задачей и буквально за одной машиной.

Работа в паре присуща экстремальному программированию, собственно видя как работают в паре наши ХР-шники (я говорю о ХР-team компании в которой я работаю на данный момент) я и решил опробовать этот подход со своими коллегами по отделу. Наблюдая практическое применение ХР при решении разноплановых задач и ту лёгкость в управлении ресурсами которую даёт ХР-команде применения основ методологии ХР, я решил взять некоторые аспекты для работы команды тестирования. Возьмём от ХР лучшее.

Зачем нам парное тестирование?

Первый раз я усадил двух тестеров за одну машину, когда нужно было вводить в курс дел по одному из наших проектов нового игрока нашей test-team. К слову сказать, проект вёлся нами уже несколько месяцев, функции команды тестирования по отношению к данному продукту заключались в финальном тестировании перед очередным релизом. Проект очень небольшой, документации по нему нет. Проводили то, что мы называем «профессиональным» тестированием, то есть тестированием, в котором тестировщик выполняет все функции эксперта по данной системе и владеет полным набором информации по проекту. Проект растёт, функции реализуются, назрела необходимоть формализации процесса тестирования, пусть даже и в столь небольшом проекте. Будем писать чек-листы. Новый игрок усаживается рядом с одним из опытных тестировщиков, ему же в руки вручается недружелюбный МАК (будем и с Мак ОС знакомиться и со специфичным Маковским приложением). Начинается пояснение: что за продукт, зачем, как он работает, то есть по-сути устно излагается product vision. Почему бы не положить это на "бумагу"? Открывается Excel на соседней машинке. Более опытный "штурмует" — то есть выполняет функции штурмана, поясняет и сам же записывает, пока обучаемый вникает в незнакомые кнопочки и покоряет однокнопочную мышь. Совмещая функции ознакомления и документирования начал создавать чек-лист по нашему продукту. Получается, что новый игрок не зная всех функций системы задаёт много вопросов, которые просто и понятно ложатся в основу чек-листа, а штурман обладая всеми знаниями по системе со своей стороны дополняет чек-лист ожидаемым поведением системы. Составление чек-листа, как один из аспектов тестирвоания приложения в паре даётся гораздо легче. Штурман — тот кто видит чек-лист и приложение на более высоком уровне, управляет уровнем детализации чек-листа и следит за покрытием всех тестовых сценариев, а непосредственно пилот — тестер в руках которого тестовое окружение и приложение под тестом, углубляется в тестирование как таковое, не овлекаясь на писателький труд. В данном случае парная работа была просто необходима — нужен момент передачи знаний по проекту, а кроме того, удалось сосредоточить нового игрока исключительно на проекте в новой незнакомой ему ОС.

Как на практике?

Получив первый удачный результат парной работы, я попытался посмотреть со стороны на свою работу как ведущего тестировщика или менеджера нашей команды. Что я делаю когда ко мне, как к человеку наиболее погружённому в проект, возникает вопрос от кого из тестировщиков? Я подьезжаю к нему на кресле и втыкаюсь носом в монитор и головой в вопрос. Опять таки — мы начинаем работать в паре.

Поставим эксперимент.

Сдвигаются два монитора — на одном открываются рабочие документы: чек-лист и release notes по последней версии продукта и наш клиент багтрекера, на второй машине запускается vmWare с тестовым окружением. Суть эксперимента — на полноценный проход по чек-листу нашего приложения под тестом (эксперимент ставился на среднем по сложности проекте) одному тестировщику требуется полный рабочий день, кроме того остаётся полчаса на свободный поиск (если к концу рабочего дня остаётся время и желание погонять приложение в вольном режиме). Посмотрим какое время потратят два тестера на эту задачу.

Как построили работу?

Основываясь на опыте работы в паре в бытность разработчиком, и на подсмотренные у ХР-команды «манёвры», мы менялись раз в 15 минут. Попеременно «штурмуя» и «пилотируя» устаёшь меньше — это могу сказать с уверенностью. Внимание не рассеивается. Постоянное общение не даёт «залипать» в трудных моментах. Штурман идёт по чек-листу и периодически направляет пилота — делаем раз, два, три, потом смотрим: здесь, здесь, здесь… Потом меняемся.

Первые результаты.

Обед у нас ровно посредине рабочего дня: работаем с 9-00 до 13-00, потом час обеда и ещё с 14-00 до 18-00 (восем часов + час обеда). К 12-00 мы полностью прошли по первому тестовому окружению. При этом не особо уставая, делая обычные перерывы на кофе, кроме того, я периодически прерывался на менеджерские задачи (катание на кресле к другим тестерам). Уточню, что до 12-00 мы успели выполнить и «вольную программу» — то есть в процессе работы возникали идеи, которые отклоняли курс от чек-листа, но мы реализовывали и их, не откладывая на потом. Обычно мы при прохождении по чек-листу, стараемся записывать идеи на «вольную программу» на листик, чтобы не сбиваться с ритма. При работе в паре, проблемы с отклонениями от ритма нет — мы ведём друг друга и спокойно возвращаемся к чек-листу, потому что штурман занят именно этим — направлением работы по тестированию и отслеживаением, в каком месте мы остановились. К обеду мы не только выполнили обычный план разделённый надвое, но и намного его опередили — процентов на 25 (3 часа вместо ориентироваочных 4-ёх). Прикнув по времени, что есть ещё полный рабочий час, мы приянлись за второе тестовое окружение. После перерыва на обед, мы смогли выделить время на актуализацию чек-листа, выполнению нескольких утомительных тасков (проверке локализации — привет японии!) и вернуться к тестированию. До вечера мы спокойно выполнили обучную норму двух тестировщиков и успели закрыть несколько сопутствующих тасков (к примеру, у штурмана на бекграунде ставилось тестовое окружение — работа не требующая пристального внимания, но нежелательная во время непосредственного тестирования).

На чём экономим?

Нет промежутка времени, который тратится на переход от приложения под тестом к рабочей документации и обратно (иногда это переход от одной рабочей станции к другой, а иногда выход из виртуального окружения и обратно, так как под тестовыми окружениями мы не держим офисных приложений и утилит создания и редактирования скриншотов). Описание ошибки сокращается более чем существенно, пока пилот снимает скриншоты или пишет ролик, штурман успевает описать проблему, выставить приоритет (где это возможно по нашему процессу) и присоединить скриншоты, которые к этому моменту уже готовы. Про то, что возрастает качество описания проблемы я не говорю — двое всегда выскажутся точнее и понятнее. Штурман по ходу может советывать, где можно углубиться в ветку прохода, или работая с багтрекером, просматривать «починенные баги» и закрывать их.

Психологический эффект.

Работать в паре легче. Нет впечатления (особенно у начинающих тестеров), что ты что-то пропустишь. Постоянно общаясь работающие в паре продолжают делиться информацией по проекту и опытом («у нас как-то был прикол, если японская локаль по умолчанию не установлена, то инсталлятор не «отстреливал» какой язык предлагать по умолчанию» — знакомые фразы?).

Когда это полезно.

Если в команде есть новый игрок, парное тестирование просто необходимо — лучшего погружения в проект чем само тестирование не бывает (можно часами читать проектную документацию, а можно сесть и посмотреть/потрогать). Кроме того, если процесс тестирования недостаточно формализирован, нет полноценной рабочей документации (чек-листы к примеру чисто формальные — есть и есть) — работая я паре, тестировщики проходят по системе не просто быстрее, но и качественнее. Кроме того, если команда (как в нашем случае) работает на нескольких параллельных проектах, то постоянная ротация игроков в парах даёт интересный еффект применения подходов тестирования, которые ранее использовались в соседних проектах. Особо это нужно, если компания выпускает несколько проектов или линеек продуктов, в которых должны применяться одни и теже структурные принципы и поддерживаться единый стиль политики по отношению к пользователю или заказчику — игроки комады тестирования видят разные проекты и могут при тестирования конкретного продукта предлагать изменения или уданые решения, увиденные в других продуктах.

Возьмём от ХР лучшее?