Нове як старе. Як провести вдалий User Acceptance Testing для Reverse Engineering проєкту.

Привіт! Мене звати Анастасія Сердюк, протягом останніх п’яти років я співпрацюю з ЕРАМ як провідний бізнес аналітик. В ІТ я працюю вже понад 15 років. За цей час змінила кілька ролей: з розробки перейшла в аналітику, з аналітики – у менеджмент. Так склалося, що увесь мій досвід пов’язаний із впровадженням масштабних систем у крупні корпорації (роздрібна торгівля, банківський сектор, телекомунікації, освіта) переважно в частині регулярних процедур оновлення даних, інтеграції даних з інших систем та іншого back-end`а. 

В EPAM я брала участь або консультувала проєкти, вимоги до яких не надають користувачі, а здобуваються з існуючого коду. Це досить новий тип проєктів, у якого є свої закони і особливості. І таких проєктів, я впевнена, в майбутньому буде з'являтися все більше. Швидкий пошук на DOU за цією темою не дав багато результатів. Тому у цій статті я хочу поділитися власною експертизою та почати заповнювати цю інформаційну прогалину. 

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

Потреба в RE виникає в ситуаціях, коли клієнт використовує застарілий код, функціонал його влаштовує, але виникають складнощі з підтримкою, масштабуванням, доопрацюванням. І у нього немає документації або фахівців, які могли б описати алгоритм роботи цього коду. Відповідно, клієнт не може надати вимоги для створення нової системи. Вимоги доводиться витягати за допомогою RE, у даному випадку це означає читання старого коду. За витягнутим вимогам пишеться нова система, максимально подібна до попередньої. 

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

Написання парсеру, який автоматично транслює старий код в новий, - дуже приваблива, на перший погляд, ідея, особливо з точки зору розробників. На жаль, вона не вирішує нашу задачу - забезпечення підтримки, масштабування, розширення, відновлення архітектури, отримання документації та доступу до експертів, які розуміють, що і як робить система. 

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

Крім того, система - це не тільки і не стільки код, скільки сукупність компонентів, які спільно працюють та виконують бізнес задачу клієнта. Якщо система доволі складна, то одним лише парсером не вдастся створити рішення, яке працюватиме.

Що робити. 

Залучати з боку замовника або виконавця експертів, які вміють читати старий код, розуміти його, описувати поведінку і формувати вимоги для нової системи. За цим вимогам можуть працювати інші фахівці (як в стандартних проєктах: аналітик формулює вимоги, команда розробки їх реалізує), або ж код може читати сам розробник і він же - реалізовувати його в технологіях нової системи (але тоді втрачається етап документування і ускладнюється підтримка) . 

Чим більше зв'язків між компонентами системи і повторного використання коду, тим ближче до старого коду варто писати код нової системи. Якщо частини системи досить автономні, то можна дозволити собі оптимізацію і застосування сучасних best practices, якщо в старому коді їх не було. 

Альтернативний варіант - спочатку розібрати весь код, продумати нову архітектуру і реалізовувати її. Хоча такий підхід викликає сумніви у сучасних реаліях, коли важливий швидкий відгук користувачів, а етапи дискавері і дизайну проєкту намагаються зробити в максимально стислі терміни. Використовувати цей варіант, на мій погляд, можна хіба що для невеликих систем. 

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

Приймати систему, швидше за все, будуть бізнес-користувачі (експерти, які користувалися попередньою системою або тестували її / впроваджували / писали інструкції). Їх завдання - переконатися, що система робить те, що від неї очікується. Однак ця категорія користувачів, цілком ймовірно, може мати дуже поверхневе уявлення про систему, її складові та зв'язки. Можливо, такі користувачі не зможуть вручну перерахувати якісь показники (адже вони давно довіряють старій системі). І навряд чи вони погодяться на перехід в фазу продакшн, поки не упевняться у коректній роботі нової системи. 

При цьому саме бізнес-користувачі можуть дати інформацію про бізнес задачі системи. Розповісти, чого в старій системі не було, і з цим мирилися, а в новій -очікують, навіть якщо не говорять про це. Або ж якісь функції старої системи надавав, наприклад, термінал, і, хоча для нього немає вихідного коду, клієнт вважає його частиною системи і очікує на всі його бенефіти у постачанні. 

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

Що робити.

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

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

Але як можна переконати клієнта, що система виконує ті самі задачі з такою самою ефективністю, як і попередня? 

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

Організувати таке порівняння не завжди легко з точки зору можливостей і ресурсів, існують певні підводні камені й у того, як інтерпретувати результати порівняння. Детальніше про це ми поговоримо у наступних пунктах. 

Що робити

• Погоджуватися на такий спосіб приймання робіт. Попри усю потенційну складність саме UAT через порівняння результатів систем виявляє більшість нестиковок і, після коригування або домовленості про те, що ми вважаємо ці розбіжності вірними (таке теж цілком можливо), дає впевненість бізнес-користувачам у тому, що системі можна довіряти.
• Також необхідно залучати бізнес-користувачів до проведення тестів, щоб вони могли на власному досвіді відчути роботу системи. Нова система може виявитися більш стабільною, швидшою або «так само знайомою», і це усуне побоювання переходу. 
• Наполягати на участі технічних експертів старої системи (якщо вони є) для аналізу її роботи і пояснення моментів, що викликають сумніви. 
• Забезпечити необхідні ресурси або час команди на проведення тестів, аналіз результатів і виправлення, тому що таке порівняння може потребувати внесення значних змін до, здавалося б, вже завершених компонентів. 
• Закладати методи трасування результатів, які допоможуть аналізувати розбіжності. 
• У випадку порівняння баз даних і інших об'єктів, що займають значний дисковий простір, забезпечити можливість довготривалого зберігання всіх даних, необхідних для проведення тестів і аналізу результатів (двох початкових і двох кінцевих для кожного тесту). 

Приймання системи методом порівняння врешті решт призводить до питання: а чи всі комбінації вхідних параметрів, логічних розгалужень і бізнес-ситуацій ми покриваємо під час тестування? 

Можливо, більшість тестів ми проводимо на типовому сценарії, але втрачаємо інші, альтернативні. Добре, якщо клієнт знає усі необхідні набори даних і може допомогти в добірці потрібних тестових даних. Але це не завжди так. А в контексті RE-проєктів, навіть не дуже ймовірно. 

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

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

Що робити

• Узгодити кількість і набір даних, яких буде достатньо, щоб клієнт переконався в коректній роботі системи з точки зору бізнес функціоналу. Часто це досить вузький набір або ж його можна буде додатково звузити в процесі тестування, спираючись на результати попередніх тестів, зростаючу впевненість в системі з боку клієнта і, швидше за все, чималу вартість повного тестування. 
• Якщо клієнт не може сформулювати вичерпний набір, показати на підставі результатів аналізу коду типові варіанти запуску, контрольні параметри, що впливають на розгалуження, продемонструвати, які варіанти були покриті попередніми тестами, а які - ні. 
• Домовитися, яким чином дані потрібних наборів будуть доступними для тестування. Чи можна їх згенерувати вручну або за допомогою спеціального генератора? Чи будуть використані замасковані реальні дані старої системи? Яким буде механізм їх оперативного отримання? 
• Домовитися, яким чином будуть прийняті ті гілки коду, для яких з якоїсь причини не знайдеться тестових даних. Можливо, це якісь рідкісні або застарілі випадки. Або результат цих гілок має слабкий вплив на результати й ними можна знехтувати. 

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

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

Тут може виникнути розбіжність між очікуваннями замовника і виконавця. Наприклад, виконавець вважає, що збіг результатів не є обов'язковим, адже в систему вноситься стільки змін! А замовник, в свою чергу, не маючи можливості іншим чином перевірити поведінку системи, розраховує на збіг результатів, незважаючи на всі модифікації. 

Що робити

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

Результатом RE-проєкту може бути не тільки нова система, але й докладна документація до неї. І, що дуже важливо, - у клієнта сформується розуміння принципів роботи цієї системи. Тільки після досягнення цих результатів можна переходити до істотного її поліпшення і перетворення, продовжуючи роботу вже як на звичному проєкті - через визначення вимог і критеріїв приймання. Чим краще цю ідею вдасться «продати» клієнту ще до початку процесу RE, тим успішнішим буде проєкт в цілому. 

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

І, звичайно, необхідно вести переговори, працювати з очікуваннями, проводити презентації і забезпечувати всебічну взаємодію з клієнтом на всіх етапах роботи - від самого початку співпраці до завершення проєкту. 

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

• Проектів, де необхідно брати вимоги з існуючого коду, стає все більше. 
• Для розуміння бізнес-функції існуючого коду самого лише Reverse Engineering недостатньо, потрібно залучення бізнес- і технічних експертів. 
• Проєкти приймають бізнес-користувачі, і їх необхідно готувати до прийняття рішень. 
• Ймовірний механізм приймання таких систем бізнес-користувачами - порівняння результатів роботи старої та нової систем. 
• Залучення клієнта до проведення порівняльних тестів сприяє формуванню його впевненості в ефективності нової системи. 
• Порівняння результатів може вимагати значних ресурсів з боку клієнта і виконавця. 
• Необхідно домовитися про обмежений набір тестів, який покриватиме всі значущі варіанти поведінки системи. 
• Порівняння результатів систем - найпродуктивніший спосіб виявлення помилок реалізації і може призвести до значних до опрацювань системи.
• Чим більша кількість змін буде внесена в рамках створення нової системи, тим більше виявиться розбіжностей під час порівняння, і тим складнішим буде аналіз результатів та аргументація коректності роботи системи. Краще відкласти якомога більше змін на етап після порівняння результатів. 

Сподіваюся, даний матеріал допоможе комусь уникнути помилок і провести Reverse Engineering проєкт максимально ефективно й безболісно - як для вашої команди, так і для клієнта.