Новое как старое. Как провести успешный User Acceptance Testing для Reverse Engineering проекта

Привет! Меня зовут Анастасия Сердюк, последние пять лет я сотрудничаю с EPAM, где сегодня занимаю позицию ведущего бизнес-аналитика. В IT я работаю немногим больше 15 лет. За это время сменила несколько ролей: из разработки перешла в аналитику, из аналитики — в менеджмент. Так сложилось, что весь мой опыт связан с внедрением масштабных систем в большие корпорации (розничная торговля, банковский сектор, телекоммуникации, образование), в основном в части регулярных процедур обновления данных, интеграции данных из других систем и прочего back-end`а.

В EPAM я участвовала или консультировала проекты, требования к которым не предоставляются пользователями, а добываются из существующего кода. Это достаточно новый тип проектов, у которого свои законы и особенности. И таких проектов, я уверена, в будущем будет появляться все больше. Беглый поиск на DOU по этой теме не дал много результатов. Потому в этой статье я хочу поделиться своей экспертизой и начать заполнять этот информационный пробел.

О каком типе Reverse Engineering проектов идет речь

Тип Reverse Engineering проектов (для удобства — в дальнейшем RE), о котором я пишу, — перенос старых решений на новые рельсы с сохранением функциональности. Например, из premise-дата центров в облако, из старых языков и архитектур — на современные.

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

Ниже я расскажу о тенденциях, вызовах и сценариях их преодоления, которые можно встретить во время работы с RE-проектами.

Вызов 1. Парсера недостаточно

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

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

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

Что делать

  • Привлекать со стороны заказчика или исполнителя экспертов, умеющих читать старый код, понимать его, описывать поведение и формировать требования для новой системы. По этим требованиям могут работать другие специалисты (как в стандартных проектах: аналитик формулирует требования, команда разработки их реализует), или же код может читать сам разработчик и он же — реализовывать его в технологиях новой системы (но тогда теряется этап документирования и усложняется поддержка).
  • Чем больше связей между компонентами системы и повторного использования кода, тем более близко к старому коду стоит писать код новой системы. Если части системы достаточно автономные, то можно себе позволить оптимизацию и применение современных best practices, если в старом коде они отсутствовали.
  • Альтернативный вариант — сначала разобрать весь код, продумать новую архитектуру и уже ее реализовать. Хотя я не очень уверена в таком подходе в современных реалиях, когда важен быстрый отклик пользователей, а этапы дискавери и дизайна проекта стараются сделать в минимальные сроки. Использовать этот вариант, на мой взгляд, можно разве что для небольших систем.

Вызов 2. Работу принимают бизнес-пользователи

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

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

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

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

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

Что делать

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

Но как можно убедить клиента, что система выполняет ту же задачу с таким же результатом, как и старая?

Вызов 3. User Acceptance Testing (UAT) через сравнение результатов систем

Показать эквивалентность работы двух систем в рамках RE-проекта можно, сравнив результаты систем при схожих входных данных и одинаковых сценариях. Для back-end компонентов сверяются базы данных, отчеты, точки интеграции с другими системами (файлы, сообщения и т.п.). Для front-end компонентов — через сравнение экранов.

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

Что делать

  • Соглашаться на такой способ приемки. При всей своей возможной сложности именно UAT через сравнение результатов систем выявляет большинство нестыковок и, после исправления или договоренности о том, что мы считаем эти расхождения верными (а это вполне возможно), дает уверенность бизнес-пользователям в том, что системе можно доверять.
  • Также необходимо привлекать бизнес-пользователей к проведению тестов, чтобы они могли на своем опыте убедиться в работе систем. Новая система может оказаться стабильнее, быстрее или «точно такой же знакомой», и это снимет опасения перехода.
  • Добиваться участия технических экспертов старой системы (если такие есть) для анализа ее работы и объяснения смысла сомнительных моментов.
  • Обеспечить необходимые ресурсы или время команды на проведение тестов, анализ результатов и исправление, т.к. такое сравнение может потребовать значительных изменений уже, казалось бы, завершенных компонентов.
  • Закладывать методы трассирования результатов, которые помогут при анализе расхождений.
  • В случае сравнения баз данных и других объектов, занимающих значительное дисковое пространство, обеспечить возможность долговременного хранения всех данных, необходимых для проведения тестов и анализа результатов (двух начальных и двух конечных для каждого теста).

Вызов 4. Нехватка тестовых данных или возможностей для тестирования

Приемка системы через сравнение рано или поздно приводит к вопросу: а все ли комбинации входящих параметров, логических ответвлений и бизнес-ситуаций мы покрываем при тестировании?

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

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

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

Что делать

  • Согласовать количество и набор данных, которых будет достаточно, чтобы клиент убедился в корректной работе системы с точки зрения бизнес-функций. Часто это довольно узкий набор или же его можно будет дополнительно сузить в процессе тестирования, опираясь на результаты прежних тестов, растущую уверенность в системе со стороны клиента и, скорее всего, немалую стоимость полного тестирования.
  • Если клиент затрудняется сформулировать достаточный набор, то показать на основании результатов анализа кода типичные варианты запуска, контрольные параметры, влияющие на разветвления, какие варианты были покрыты предыдущими тестами, а какие еще нет.
  • Договориться, каким образом данные нужных наборов станут доступны для тестирования. Можно ли их сгенерировать вручную или с помощью специального генератора? Будут ли использованы маскированные реальные данные старой системы? Каким будет механизм их оперативного получения?
  • Договориться, как будут приняты те ветки кода, для которых не найдется по какой-то причине тестовых данных. Возможно, это какие-то редкие или устаревшие случаи. Или результат этих веток имеет слабое влияние на результаты, и ими можно пренебречь.

Вызов 5. Модернизация новой системы влияет на результаты сравнения

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

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

Здесь нас может ожидать расхождение ожиданий заказчика и исполнителя. Например, исполнитель считает, что совпадение результатов не обязательно — в систему ведь вносится столько изменений! А заказчик, в свою очередь, не имея возможности иначе проверить поведение системы, рассчитывает на совпадение результатов, несмотря на все модификации.

Что делать

  • В некоторых случаях будет даже полезно отказаться от планируемых или уже реализованных оптимизаций с целью большей «сходимости» при сравнении и для повышения возможности повторного использования уже разработанной функциональности (например, если такое использование предполагала старая система). Так, нам может понадобиться сохранить структуру базы данных и отложить ее модернизацию на этап, следующий за этапом UAT через сравнение результатов. Оптимизацию системы стоит продумывать в том числе с оглядкой на необходимость сравнения со старой системой.
  • Вести список отличий старой системы от новой. Он понадобится для более быстрого анализа расхождений и аргументации корректности работы системы.
  • Иногда проще повторить баг по желанию клиента и согласованию с ним, чтобы избежать такого расхождения результатов, где почти невозможно просчитать root cause. Список багов старой системы, который воспроизвели в новой, также лучше вести. Возможно, клиент захочет их потом исправить.
  • Договориться с клиентом считать расхождения в результатах сравнения не багами, а некими задачами для исследования. Результатами такого исследование может стать понимание того, что систему нужно дорабатывать, или — что проблема находится в старой системе и ее сайд-эффектах. Багами же считать места, требующие доработки. Статистика «багов/небагов» в результате сравнения может стать дополнительным аргументом в переговорах о результатах работы систем и целесообразности дальнейшего тестирования.

Что еще стоит учесть

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

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

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

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

Главные выводы

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

  • Проектов, где необходимо брать требования из существующего кода, становится все больше.
  • Для понимания бизнес-функции существующего кода одного Reverse Engineering недостаточно, нужны бизнес- и технические эксперты.
  • Проекты принимают бизнес-пользователи, и их необходимо готовить к принятию решений.
  • Вероятный механизм приемки таких систем бизнес-пользователями — сравнение результатов работы старой и новой системы.
  • Привлечение клиента к проведению сравнительных тестов поспособствует формированию его уверенности в новой системе.
  • Сравнение результатов может требовать значительных ресурсов со стороны клиента и исполнителя.
  • Необходимо договориться об ограниченном наборе тестов, при этом покрывающем все значимые варианты поведения системы.
  • Сравнение результатов систем — самый продуктивный способ выявления неточностей реализации и может привести к значительным переделкам системы.
  • Чем больше изменений будет внесено в рамках создания новой системы, тем больше окажется расхождений при сравнении, и тем сложнее будет анализ результатов, аргументация корректности работы системы. Лучше отложить как можно больше изменений на этап после сравнения результатов.

Надеюсь, данный материал поможет кому-то избежать ошибок и провести Reverse Engineering проект максимально эффективно и безболезненно — как для вашей команды, так и для клиента.

👍НравитсяПонравилось6
В избранноеВ избранном2
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо, очень все по делу

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

Я меряла успешность UAT тем, что клиент систему официально принял и дал зеленый свет в сторону production release. Но тема UAT сама по себе емкая, отдельную статью писать можно.

Ну вот например бывают ситуации, когда клиент подпишет неглядя, т.к. у него самого «сроки горят» или «это не моя ответственность» или «а все равно я увольняюсь»

А потом в продакшне начинается свистопляска

И вроде как ответственность мы формально переложили, но «осадочек остался»

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

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

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

Вот это огромными бронзовыми буквами отлить: «Миграция — Отдельно, Новые Фичи — Отдельно»

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

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

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

Любое значительное изменение в таких проектах это огромный риск и делать их — искусство

При этом собрать и обсудить требования к улучшениям/изменениям, учесть их при планировании архитектуры — абсолютно обязательно

Так же в таких системах есть устаревшие или не используемые функции (которые можно не переносить и сократить сроки и бюджет)

Да, это очень важный элемент, но опять же, найти такие фичи, договориться об их исключении и особенно зафиксировать эти договоренности (explicitly out of scope) — не такая простая задача. Чаще всего такой анализ проводят, если фича получается очень дорогой в разработке или плохо ложится в архитектуру (т.е. делает дорогими остальные фичи, но позже).

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

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

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