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

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привет, тестировщики! Если вы работаете в сфере 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»?