Апр. 22

Новое как старое. Как провести успешный 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 проект максимально эффективно и безболезненно — как для вашей команды, так и для клиента.