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

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

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

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

Що взагалі треба перевіряти при міграційному тестуванні:

  • Сумісність нової/оновленої системи з усім можливим обладнанням/програмним забезпеченням, яке підтримує застаріла система
  • Перевірка того, що всі існуючі функції працюють як у застарілій системі
  • Перевірка того, чи час відповіді нової/оновленої системи є таким самим або меншим, ніж у старій системі
  • Перевірка зв’язків між серверами, обладнанням, програмним забезпеченням не порушується під час тестування

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

  • Підготуйте команду QA для SQL. Проведіть навчання з SQL запитами. Тому що 90% тестування міграції — це саме формування SQL запитів та розуміння схеми баз даних
  • Зробіть аналіз бізнес-ризиків, аналіз можливих помилок і підготуйте Mitigation plan
  • За можливості охоплюйте ризики в тестових сценаріях, якщо тестові дані дозволяють
  • Проаналізуйте чіткий обсяг міграційних тестів, коли та що слід перевіряти, в якому поядку
  • Визначте інструменти для міграції (автоматичні чи ручні). Вручну було доволі складно, але автоматично буває ще складніше
  • Визначте тестове середовище для міграції (окреме середовище для попередньої та післяміграції)
  • Зробіть хоч б маленький тест план та пропишіть там підходи до тестування, області тестування, кількість кіл тестування, розклад, підхід до створення даних та використання живих даних, специфікація тестового середовища, кваліфікація тестувальників тощо. Задокументуйте список завдань для міграції та заапрувте його у РО.

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

  • Налаштовано чіткий обсяг даних міграції
  • Виконується відображення даних між старою та новою системами
  • Визначено обов’язкові/необов’язкові поля
  • Всім QAsзрозуміла нова схема даних системи
  • Визначено кількість таблиць і зв’язків між ними
  • Визначено кількість записів у кожній таблиці
  • Визначено перевірку даних безпеки
  • Підготовлені тестові приклади для нових умов у новій системі

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

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

Ви можете додати до звіту такі дані:

  • Підсумок виконання тестів
  • Фази міграції та статуси результатів
  • Зафіксований час наступних дій:
    • Загальний час міграції
    • Простої системи
    • Час, витрачений на перенесення 1000 записів
    • Час, витрачений на відкат

Чи проводили ви коли-небудь міграційні тести на своїх проектах?

Може є чим ще доповнити мою статтю?

Мій інстаграм: www.instagram.com/masha.it.travels

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Питань, поза якими є реальна цікавість, а не бажання домахатись, є безліч. Сам працюю з даними, як тестувальник ВІ систем. Матеріалів на ДОУ практично нема по темі.

На мою думку стаття ні про що, ніякої конкретики. Враження ніби злизано з softwaretestinghelp крапка ком + гугло перекладач.

тож напишіть свою статтю, поділиться своїм безцінним досвідом з колегами, а то враження ніби не читали статтю

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