Тестування міграції

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

В цій статті я розповім про свій досвід тестування міграції даних з однієї версії продукту в іншу.

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

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

Нижче я приведу невеличкий список, на що потрібно звернути увагу при тестуванні міграції:

1. Перевірити чи всі дані мігрували з старої системи в нову. Щоб це зробити можна наприклад зрівняти кількість записів в таблицях між старою та новою системами. Це можна зробити підготувавши звичайні запити типу Select * From TableName

2. Перевірити чи були змінені, чи можливо перейменовані поля, типи данних, чи додані або видалені таблиці в базі, згідно новим вимогам.

3. Також перевірити що функціональність яка працювала в старій системі працює і в новій.

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

5. Перевірятися повинно кожне поле на те чи не було змінено тип даних, чи розмір допустимої кількості символів або навіть на пусті значення в полях.

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

7. Перевіряти чи раптом не мігрували видалені дані в нову систему, таке також можливо якщо дані були видалені з старої системи, а значення типу DeletedDate не мігрувало з БД.

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

9. Перевірити, що буде, якщо не заповнити якесь поле, що в новій системі має бути обов’язковим. В такому випадку через одне поле можуть втратитися всі дані з усієї форми.

10. Перевірити як генеруються репорти з даними, після міграції. Найпростіший варіант просто згенерувати репорт на старій системі та у новій та зрівняти їх.

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

Щоб протестувати міграцію бажано розбити процес на декілька етапів:

◾вибрати якусь частину функціоналу та підготувати тестові дані

◾запустити міграцію даних

◾перевірити що всі дані, які ви створювали, успішно перенеслися та відображаються у повному обсязі в новій системі

◾виявити помилки та задокументувати баг репорти і відправити їх на фікс

◾вибрати іншу частину функціоналу і повторити цикл

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

Happy Testing! 🤗

With Love from QAC 💛💙