Почему требования так важны для тестировщика

Привет, тестировщики! Если вы работаете в сфере Quality Assurance — поздравляю, эта статья может быть вам интересной. Если у вас на проекте отсутствует документация/есть проблемы с требованиями о проекте — поздравляю, эта статья может быть полезной. Если у вас на проекте идеальное состояние задокументированных и поддерживаемых требований — вас просто поздравляю :)

За время своей недолгой карьеры (5,5 лет) мне удалось побывать на разных проектах с совершенно разной степенью культуры документирования требований. И сейчас я попробую детально рассказать о важности документирования требований и о том, как мы, QA-ниндзя, можем использовать это оружие в своей трудовой деятельности.

Обнаружить источник «боли»

Во многих проектах «боль» есть. Даже если нет ее источника. И больно, когда источник есть, но он не меняется с момента создания (только если вы не Waterfall’исты).

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

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

Одна из частых причин — невозможность исчерпывающего тестирования.

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

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

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

В целом мы понимали, что данный продукт делает, и, оперируя этими знаниями + старой версией, команда приступила к разработке. Вскоре пришла очередь тестирования. И тут я столкнулась с трудностями (QA-курсы меня к такому не готовили) — заводя дефект, я элементарно сталкивалась с затруднением указать дефекту параметры priority и severity и в основном из-за того, что не понимала, какую ценность несет в себе логика продукта для бизнеса. В процессе фиксов возникало еще больше возможных сценариев, обработку которых уже сложно было безболезненно вписать в код. Сквозь сорванные сроки, пачку дефектов, переработку и костыли (читай — сквозь боль и страдания) проект переродился руками нашей команды, и вот если бы мы уделили внимание еще и бизнес-стороне продукта, то смогли бы минимизировать эти страдания. Из продукта можно было сделать не только «конфету» для нужд компании, но и самостоятельный качественный софт для продажи. А так получили еще одну версию продукта, которую, по-моему, уже пора обновлять.

Не так страшен диагноз

Текст — это фиксация чьих-то мыслей в упорядоченной (если повезет) форме. Это чужие мысли, с чужим представлением о прекрасном, удобном и полном мироздании. И часто это представление может отличаться от вашего. Даже эта статья.

На этапе вступления тестировщика в разработку продукта (мы же помним, да? — чем раньше, тем лучше) он должен очистить свое сознание, учиться мыслить как заказчик (привет персонажное мышление). Но не отключать здравый смысл и пройденный опыт.

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

Я хороший урок вынесла в самом начале своей IT-карьеры, когда успешно свитчнулась со страхования в тестирование. Для меня один из первых проектов был настолько далек от моего понимания, что даже начала задаваться вопросом «А верно ли я изменила свою карьеру?». Нет, я понимала свои задачи, копала от пункта А и до забора, но вовсе не понимала и не видела целостность картины, занимаясь только её отдельными кусочками. И на каждых командных встречах непонимание общей картины в моих глазах превращалось в бездну. На проекте не было толком упорядоченной тестовой документации, тестировалось ad-hoc’ом, фиксировалось в гугл-таблицах, и моя бездна уволокла за собой много проверок, которые потом вылились в серьезные дефекты логики приложения (и громкие негативные высказывания стейкхолдера на демо). С тех пор я задаю вопросы.

Идея для иллюстраций взята из lizclimo

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

Когда я поступал в университет, родители мне сказали, что сначала я буду работать на оценки, потом оценки будут работать на меня. Здесь подобная зависимость: сначала вы трудитесь на понимание продукта, потом это понимание расширит ваш кругозор и станет работать на вас и на продуктивность команды.

Ко мне эта аналогия прошла спустя время и определенный багаж опыта. Например, это значительно упрощает процесс общения с девелоперами — когда фикс дефекта имеет несколько вариантов решения. Чертовски приятно, скажу вам, когда разработчик приходит и предлагает сделать А или Б, и ты понимаешь, что А может повлиять на логическое флоу продукта, а Б просто нанесет небольшой вред UX. И, принимая ответственность за фикс через Б, я четко понимаю, что это не нанесет вреда бизнесу компании.

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

Построение общего анамнеза

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

Это будет полезно, потому что:

  • ваше время не будет уходить на объяснение понятий вновь прибывшим (да и бывалым);
  • вновь прибывшим плюс один артикль в рамках онбординга и ознакомления с продуктом;
  • дефекты и CR-тикеты могут быть легко найдены в 1500+ тасок в Jira.

У бизнеса не всегда «красная линия» может быть красного цвета и линией. Уточнить не будет лишним. Вы можете удивиться услышанному в 50% случаев (самый яркий скетч). Даже если все участники команды ясно понимают, о чем речь, полезно будет зафиксировать это. И заапрувить коллегами с разными ролями.

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

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

Курс экзорцизма

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

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

Покупатель, который захочет купить на нашем портале себе сладенького, будет изучать каждый из этих двух продуктов. Разная визуализация печенек вызовет резонанс. Про овсяное печенье он просмотрит 20+ фотографий в разных ракурсах и ноль полезной информации. Как выглядят бисквитные, даже не поймет, но изучит много малопонятного для него текста с описанием состава. И, скорее всего, покупатель покинет портал, а владелец потеряет ценного покупателя-сладкоежку. Я бы на месте покупателя погуглила доставку крафтового темного.

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

Побочные эффекты

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

Время

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

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

Ответственность

Плохо, когда это один человек. Даже если это такой хороший человек, как вы. Этот человек становится bottle-neck данной активности. Никто не отменял отпуска, усталость от обязанностей, да и выгорание на занимаемой должности.

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

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

Документация для документации

Если пункт 1 и пункт 2 не отбили желание, вот вам еще один.

Есть интересная фраза (подслушано в одной довольно бюрократической конторе): чем больше бумаг, тем чище жопа.

Правда, в нашем случае документацией мы не прикрываем свой тыл от неожиданных претензий к качеству продукта. Документацией мы стандартизируем подход к продукту. Но фраза веселит.

Возможны несколько вариантов решения и этой проблемы:

  • Самый простой в исполнении (но тяжелый во внедрении) — разработать темплейт для требований, по которому будет следовать вся команда разработки. И обязательно, чтобы для продукта этот темплейт адаптировался с функцией «поддержки в актуальном виде». Плюс — в любой момент разработки актуальны не только твои идеальные кейсы для тестирования, но и требования. Минус — ответственный подход составителя требований в вашей команде (как, собственно, и наличие самого составителя; или см. пункт 2).
  • Еще вариант (если невозможен первый) — надоедаем, уточняем, просим рассказать, показать, задаем вопросы. С последующей фиксацией всего услышанного и увиденного. Одна из практик — если что-то упущено/отличается от требований — это дефект. Плюс — резолюция от ответственного за требования, что «так и задумано», зафиксирована письменно, или требования обновлены; вам готовый список таких дефектов в разделе «Ожидаемое поведение» на Confluence. Минус — драгоценное время на рассмотрение дефекта всех задействованных участников вечеринки; в Jira уже 2500+ тасок по проекту.
  • Ну и самый локальный вариант — скромная страничка в вашем пространстве для тестовой документации. Вы там царь и бог — фиксируете все проблемные моменты продукта и сохраняете для потомков. Плюс — вы все реже будете задаваться вопросом «А оно должно так?»; можно смело ссылаться на данный документ в спорных ситуациях. Минус — то же самое время на создание и поддержку; документ полезный, но пользу приносит только вам и вашей команде (жаль, что не всем остальным).

Заключение

Почему требованиями не могут выступать тест-кейсы/чек-листы? Все возможно. Если вы очень маленькая команда и разрабатываете мини-продукт. Но с ростом первого и второго качество продукта не должно страдать из-за недостатка хорошей и продуманной документации.

Мы уже выяснили, как элементарное упущение анализа и тестирования требований может повлиять на стоимость фиксов после релиза. Как с этим бороться — варианты тоже есть. В статье указала именно те, которые были пережиты мной и моей командой.

Нужно ли бороться с «болью» — выбор исключительно ваш. Но не это ли превращает «тестировщика» в «QA Engineer»?

👍НравитсяПонравилось16
В избранноеВ избранном4
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
В данном кейсе QA выходит на сцену, садиться напротив двух стейкхолдеров и ищет «золотую серединку».

ця фраза виглядає дивно, чому куа має шукати золоту середину з стейкхолдерами??

садиться напротив двух стейкхолдеров и ищет «золотую серединку»

на какой стул сам сядешь, а на какой стейкхолдера посадишь

Спасибо за поднятие важной темы о требованиях.
Расшарил статью Катерины на LI и дал свой фидбек/мысли со стороны Б/С аналитика www.linkedin.com/...​-6837047245834080256-y0-l

Ха — если бы были требования и документация то ИТ давно бы уже стало заурядной инженерной дисциплиной. Как, например, расчет зубчатых передач или разводка электронных плат. Даже схемы процов давно уже проектируют компьютеры.
Потому что когда есть четкие требования, когда задачу можно формализовать — то ее решение это уже «дело техники». А вот когда «пойди туда — не знаю куда, принеси то — не знаю что», то тут никакой ИИ не справится — только Иван-дурак нужен!
Пока заказчиками программ были ученые или военные — то и программистов было немного. А вот когда софт потребовался бизнесу — тут уже вместо требований только фантазия заказчика! Спрос рождает предложение — в ответ ИТ перешел на аджайл. Если нет четких требований — то вместо четкого результата может быть только гибкий процесс.
P.S. Можно провести обратную аналогию — многие компании сейчас отказываются от QA именно потому что QA нужны требования. А их нет — потому что юзеры сами не знают чего хотят. В итоге пускай юзеры сами и тестят — если их устраивает значит все ок.

Во многих проектах «боль» есть. Даже если нет ее источника.

Шедевральная фраза )))

BA + QA = «друзя на век» ( пока проект)))

Чем позже после начала работы над проектом найден дефект (в дизайне, в коде), тем он дороже

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

Если вы получаете требования на последней фазе, то я вам смело говорю — вы не умеете работать с заказчиками. Это больше напоминает позицию, которая прекрасно описана в статье — «больше бумаги — чище жопа». Поэтому и появляются процессы длиною в вечность, и поэтому «waterfall жив». Что мешает работать с требованиями на старте или вовлекаться в суть продукта? :) вы сами, я думаю, ответите на этот вопрос. А я вам подскажу, ответ — название в роли — контроль качества. Тестировщики — чуть другая роль.

Конечно «не умею», где уж фрилансеру-то уметь :)
Суть в том, что полная формализация требований до того, как всё будет готово — миф. И тем более до того, как всё только начнёт исполняться. Вернее, это возможно, но чем глубже детализация, тем больше время-денег это стоит. И стоимость растёт экспоненциально.

Бюрократия — далеко не единственный, и уж точно не лучший источник достоверных данных. Наиболее достоверные данные даёт конфликт. А вот уже конфликту не помешают пусть не оковы, но рамки бюрократии. Миф же состоит в том, что бюрократы между собой договорятся. Наверху, ага. При том что соединить системой нужно не верхние, а низовые слои, те самые звенья цепи, которые осуществляют реальные дела.

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

Вот так выглядит твой миф в действии.

PS. А вотерфолл — живее всех живых. Для тех, кто знает, что задачи вотерфолла прекрасно поддаются параллелизации и конвейризации.

А я разве что-то написал про полную формализацию требований? Перечитал еще раз, нет такого в моем сообщении. Где-то, разве, написал, что бюрократы должны договариваться? Да, опять — нет же. Я не знаю, откуда вы это берете. Месседж был абсолютно противоположный тому, что вы пытаетесь мне привязать. Давайте еще раз. Работать с требованиями нужно на старте, проекта, а не ждать когда заказчик их изложит полностью/частично. Заказчик — существо непостоянное, он видит продукт только таким, каким он есть в его голове. И зачастую сам факт проработки требований, подталкивает его к озвучивании новых деталей. Более того, то как видит заказчик продукт, и то как вы его видите после изучения тонн BRD — это разные продукты. И это неоспоримая правда, иначе не было бы всех этих мемчиков, которыми вы так умело «прикрываетесь». А чтобы этого избежать, с заказчикам нужно уметь работать, BA должен понимать не только требования, но и суть продукта, QA должен видеть не только тест-кейсы, а вникать в суть продукта и проводить оценку его качества. Вот в чем смысл :)

Таки где-то писал

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

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

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

Это цитата из статьи, а не из моего сообщения. Смешались и кони, и люди :) Опять же, важно осознавать масштабы компании и проекта. Тут, как мне кажется, должен быть прозрачный подход на разных уровнях от заказчика до исполнителя. Хочешь хороший продукт? — не абстрагируйся и участвуй в его разработке, хочешь на выходе получить проблему — отдай все на откуп команды. В моей практике, заказчики, которые были вовлечены в создание продукта со старта — добивались лучших результатов, чем заказчики, занявшие позицию — «я за это заплатил», «ты ж ИТшник»

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

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

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

100%, жаль только, что у вас все плохо :) можете посидеть поплакать и пожаловаться как не справедлива ваша жизнь :)

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

Не понимаю, о чем вы говорите. Видимо вы меня с кем-то путаете :)

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

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

Спасибо за статью.

Подписаться на комментарии