Разделы портала

Онлайн-тренинги

.
Тестировщики и требования: непараллельные прямые
12.07.2011 11:29

Автор: Наталья Руколь

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

Роль требований в процессе разработки

Требования похожи на единорогов. Такие же прекрасные мифические создания, несущие людям счастье Smile В ~99% проектов, с которыми я сталкивалась, требования:

  • Были неполным
  • Были некорректным
  • Отсутствовали

Выбирайте любые пункты из трёх, а иногда и все вместе.

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

Как всегда, у нас есть выбор. Вариант #1 – подождать: а вдруг появятся? Чтобы ожидание не было скучным, можно разбавлять его регулярными жалобами на нехватку требований и байками из серии «а вот в нормальных компаниях…».

И есть вариант #2 – построить процесс таким образом, что у вас появятся требования. Именно об этом варианте мы и поговорим в статье.

Проектные цели – источник требований

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

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

Исходя из выявленных проектных требований, строится весь последующий процесс: планирование, проектирование, разработка, тестирование. Требования – это фундамент для построения успешного продукта. Если требования изначально не соответствуют цели, не выявлены, не согласованы между участниками проекта, то даже самая слаженная работа проектной команды не приведёт проект к успеху. При некорректных требованиях вы можете долго и упорно тестировать продукт, находить дефекты, проявлять активность, что-то заводить, исправлять, проверять… Но проекту это пользы не принесёт!

Что может сделать тестировщик?

Если бы эта статья была написана для аналитиков и РМов, всё было бы просто. Литературы про сбор и анализ требований предостаточно, различные методологии подробно разбирают, как их необходимо выявлять, документировать, отслеживать изменения. Моей задачей было бы сказать «Чуваки, это очень-очень важно, поймите это наконец-то!», привести пару примеров неудачных проектов, которые были провалены из-за неграмотной обработки требований, и на этом статья бы завершилась. Убедила, мотивировала, идите наконец-то работать. Но с тестированием ситуация немного другая. Формально требования вне нашей зоны ответственности, и их качество от нас не зависит. Мы лишь используем их в своей работе. Что же мы можем сделать? Ниже я структурирую советы по работе с требованиями, которые подходят или не подходят в зависимости от того, «насколько у вас всё запущено».

0. Узнаём бизнес-цели проекта

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

Кстати, не удивляйтесь, если РМ не сможет с первой попытки вразумительно ответить на эти вопросы – в российском ИТ-бизнесе это далеко не редкость. Спрашивайте, понимайте, пока у вас не появится чёткой картины проекта и понятных, измеримых критериев его успешности.

1. Выявляем требования

Иногда требований нет. При этом, я не имею в виду, что они не задокументированны – в небольшой проектной команде бывает достаточно проговорить общие требования вслух. Но бывают ситуации, когда их и впрямь нет. Недавно я участвовала в подобном проекте. Со стороны это выглядело следующим образом: «Разрабатываем систему видеовещания!». Какую? Зачем? Для кого? Кто целевая аудитория (ЦА)? Какие критерии успеха проекта? Ответов на эти вопросы не было. В итоге, разработчики несогласованно пилили модули, исходя из того, как они понимают слово «видеовещание». Дизайнеры рисовали интерфейс «симпатичный», а не «удовлетворяющий нашу ЦА». Результат предсказуем: срывы сроков, непрерывные переделывания, исправления, низкое качество результата.

Что в этой ситуации может сделать тестировщик?

1. Создать структуру требований.

Если вы не просто кликаете на кнопочки, а технологично подходите к тестированию, проектируете тесты, исследуете продукт с точки зрения пользователей, то вы в любом случае проводите его анализ и выявляете требования. Чаще всего, результат фиксируется в виде тестов, чек-листов, а иногда просто в голове в формате «это нужно бы проверить». Давайте попробуем выписать структуру требований самостоятельно? Это можно сделать, используя разные инструменты:

  • Jira, HP QC, Testlink – любой инструмент, хотя бы косвенно предназначенный для ведения требований (предпочтительно для сбора статистики, о которой речь пойдёт дальше)
  • Sharepoint-портал, табличный Google-doc, корпоративная wiki – любой инструмент, который позволяет распределено структурировать данные с иерархичным отображением

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

Что будет в аутентификации? Регистрация, вход, выход.

Какие требования к регистрации? Проверка валидности е-мейла, проверка что не робот и т.д.

И так мы постепенно от большего к меньшему, циклично выписываем требования. Не надо описывать детали, это пока не нужно. Главное – структура.

2. Согласовать структуру требований.

Для этого нужен аналитик или РМ. Отказывающийся от написания требований, он врядли откажется от согласования. Спросите, полна ли ваша структура требований, есть ли в ней всё, что он ждёт от продукта?

3. Определить приоритеты.

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

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

4. Расширить требования нефункциональными аспектами.

По каждому пункту ваших требований уточняйте: сколько пользователей? Как быстро? Какие объёмы данных? Какие ограничения? Постарайтесь собрать максимум информации, ведь без неё вы всё равно не сможете результативно тестировать свой продукт.

В результате, получится приблизительно следующая табличка:

Кажется, пришло время для двух сакральных вопросов: где тестировщику найти время на ведение требований и почему он должен это делать?

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

Могу поделиться своим опытом: создание структуры требований на продукт, состоящий из 2 млн. строк кода, заняло около двух дней в фоновом режиме. Требований получилось около 700.

Что же касается второго вопроса (почему он должен это делать?), ответ простой: «Колхоз – дело добровольное». Конечно, проявлять эту инициативу вовсе не обязательно, но если вы этого не сделаете – велик риск, что проект не достигнет своих целей, и как бы вы не старались с тестированием, существенная часть выполненных вами работ окажется никому не нужной.

2. Детализируем требования.

Структура требований – это уже очень хорошо. Допустим, её составил аналитик или вы, воспользовавшись стратегией из пункта 1. Но что вам даёт требование «Проверка валидности e-mail»? Оно может быть реализовано по-разному, с разными проверками, по-разному отображаться в пользовательском интерфейсе. Получается, наша структура – это только заголовки требований, описаний к которым пока что нет. На этом этапе для нас важнее всего общее понимание «как это должно быть реализовано» всеми участниками проекта, и при этом мы должны быть уверены, что именно эти способы реализации приведут наш проект к достижению бизнес-целей. Как мы можем этого достичь? Из своего опыта я могу предложить несколько вариантов действий.

1. Описать самим.

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

  • Вы заручились поддержкой РМ и выделили на это достаточно времени
  • Вы достаточно хорошо понимаете бизнес-сферу применения вашего продукта
  • У вас есть доступ к заказчику или представителям ЦА для выяснения спорных моментов
  • Вы знакомы с основными паттернами и техниками системного анализа
  • Вы очень любите анализ и хотите развиваться в этом направлении

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

2. Инициировать общепроектное согласование требований.

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

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

  • Конструктивный настрой участников проекта, понимание «зачем мы это делаем»
  • Приемлемые объёмы требований (тот самый продукт с 2 млн. строк кода мы обсуждали несколько недель почти непрерывно. Зато, как бы сильно мы не надоели друг другу за эти 2 недели, на Post Mortem’e решение согласовывать таким образом требования было единогласно признано самым полезным решением на проекте!)

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

3. Собрать статистику по требованиям и убедить в необходимости их создания

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

С одной стороны, это действительно так: тестирование очень сильно зависит от требований, и без них мы часто не понимаем что, как и в какой последовательности тестировать. Но с другой стороны баррикад наши просьбы требований часто выглядят как перебрасывание ответственности, этакий офисный пинг-понг. Если варианты 1 или 2 по каким-то причинам не получились (а чаще всего это значит, что не удалось заручиться поддержкой РМа), то вместо жалоб на нехватку документации вы можете пойти на «крайние меры»: собрать статистику по наличию требований. Имея структуру, созданную ещё на первом этапе, вы можете проставить плюсики и минусики: какие требования понятны и ясны, а какие – нет. В моей практике статистика «90% требований реализованы, из них 14% понятны участникам проекта» производила магическое действие на команду – конечно, не в случае, когда вы хотите заставить работать других людей, а когда и сами готовы проявить инициативу.

3. Тестируем требования

При желании вы легко найдёте критерии, по которым обычно проводится тестирование требований: полнота, непротиворечимость, атомарность, тестируемость и т.д. О том, как проводить тестирование требований, легко и доступно написано в книге Ron’a Patton’a “Software Testing”, поэтому повторяться я не буду. Хочется лишь добавить важный момент, усвоенный на практике через набивание шишек: если вы хотите, чтобы результаты тестирования требований приносили пользу проекту, обсудите этот процесс с РМом заранее. Договоритесь заводить на требования такие же полновесные баги, как и на код. Танцуйте, прыгайте с бубном, проводите презентации, учитесь активным продажам – сделайте всё, чтобы объяснить важность требований на проекте и заручиться поддержкой.

Выводы

  1. Вы всегда можете сказать, что не можете что-то полноценно тестировать из-за нехватки требований.
  2. Вы почти всегда можете инициировать процесс, при котором требования появятся.
  3. Ведение требований – «не ваша забота», и это действительно так. Но важен ли вам результат проекта?
  4. Никто не воспринимает всерьёз просьбы о создании требований! Если вам важно, чтобы они появились – проявите инициативу!
  5. Любая инициатива на проекте должна быть согласована с РМ. Продумайте хорошенько, что вы готовы ему предложить, и какую роль в предлагаемом решении готовы взять на себя.

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

** Все советы, данные в этой статье, благополучно протестированы на практике и показали свою эффективность.

*** Несмотря на то, что автор исповедует религию проактивности и инициативы, он признаёт наличие «неисправимых» проектов

Обсудить в форуме

Об авторе: Наталья Руколь, Лаборатория Качества

Ближайшие онлайн-тренинги автора: