Testowanie migracji danych- teoria i wyzwania dla testera

Wstęp, czyli co to jest migracja danych…

Migracja danych to zagadnienie teoretycznie proste. Przeniesiemy zapisane informacje z bazy do bazy, z systemu do systemu. Ale jak to się mówi, diabeł tkwi w szczegółach. Rzadko zdarza się prosta migracja, gdzie przenosimy zapisy wprost. Najczęściej zapisy muszą być konwertowane, przeliczane. Systemy zwykle różnią się strukturą zapisów, architekturą, słownikami. Do tego dochodzą aspekty funkcjonalności systemów – należy znać odpowiedź na pytanie, czy dane zapisane w bazie systemu docelowego będą poprawnie interpretowane.

Rodzaje migracji danych

• Migracja w formie centralizacji systemu rozproszonego​
  • Scenariusz wydaje się prosty. Mamy kilka instalacji systemu, a chcemy mieć bazę centralną. Budujemy skrypty kopiujące tabela po tabeli, rekord po rekordzie. I? Rozbijamy się o identyfikatory unikalne w ramach instalacji (bazy) a identyczne w innych instalacjach (identyfikatory klientów, dokumentów, zapisy słownikowe). O tym i o wielu innych aspektach należy pamiętać projektując migrację.
• Migracja danych do gotowego systemu
  • Firma kupiła nowy system i podjęto decyzję o przeniesieniu danych do nowego systemu (wszystkich, wybranych). I pojawia się pytanie: czy wszystkie wymagane informacje można przenieść – na to pytanie odpowiedzą min. analityk, architekt.
• Migracja do systemu budowanego lub gotowego customizowanego
  • W obydwu przypadkach wyzwaniem migracyjnym są sposoby zapisywania danych. I tutaj pojawia się pytanie: czy funkcjonalności nowego systemu będą poprawnie funkcjonować na nowych danych. Na to pytanie odpowie analityk. Ale to tester będzie docelowo weryfikował rozwiązanie.
• Migracja części lub całości danych
  • Czy migrowane będą wszystkie dane? Jeśli tak, to należy uwzględnić zapisy historyczne. Funkcjonalności dawno nie używane. I nasuwa się pytanie: czy jest to nam potrzebne?
    Często nie jest, ale jeśli zmigrujemy tylko część danych to system źródłowy musi być dostępny w sposób co najmniej dla ograniczonej liczby użytkowników i bez możliwości generowania zapisów.

A gdzie w tym testy? Opiszę to w dalszej części.

Dokumentacja ważna z punktu widzenia testów

• Plan Migracji Danych

Plan Migracji może zawierać: identyfikację procesów do przeniesienia, identyfikację procesów do zmiany/zbudowania, Identyfikację procesów już nieużywanych. Czyli daje Testerowi ogólne pojęcie, z jakimi wyzwaniami przyjdzie mu się zmierzyć.

• Mapowanie danych – dokumenty DMT:

Kluczowy dokument dla wszystkich operacyjnych uczestników projektu. Zawiera min. budowę mapowań, identyfikację obiektów, tabel, pól w systemie źródłowym, identyfikację obiektów, tabel, pól w systemie docelowym, zasady konwersji danych identyfikację słowników do wykonania mapowań.

• Identyfikacja danych do przeniesienia/zapisania przed migracją właściwą

Czyli ręczna lub półautomatyczna praca zespołu do późniejszej weryfikacji przez testera.

Część techniczna – czyli co tester powinien wiedzieć zanim zacznie migrację danych.

• Z jakimi bazami mamy do czynienia
• Gdzie znajdują się dane źródłowe
• Gdzie znajdują się dane docelowe
• Jakie są środowiska testowe (np. model flip-flop)
• Gdzie znajdują się dane tymczasowe (podczas konwersji)
• Czy dane będą anonimizowane
• Jakie możliwe problemy związane z jakością danych mogą wystąpić (np. w przypadku plików płaskich – znaki białe)
• Raportowanie (schematy, narzędzia)

Testy – część operacyjna

Kluczowe elementy, czyli o czym należy pomyśleć przed testami.

• Określić potrzebne zasoby
• Doszkolić testerów (funkcjonalności systemu docelowego, narzędzia, flow projektowego)
• Przedyskutować podejście do testów obiektów/tabel/pól – na podstawie DMT

A jakie testy mogą być wykonywane po migracji danych?

• Testy porównawcze przenoszonych pól (z uwzględnieniem konwersji)
• E2E (End to End) – czyli sprawdzimy, dane na ekranie systemu źródłowego i docelowego
• Testy funkcjonalności systemu docelowego na zmigrowanych danych
• Testy integracji
• Testy wydajnościowe
• Testy powdrożeniowe

Czy testy migracji są często wykonywane?

Odpowiedź brzmi – Tak.

Większość migracji nie jest zbyt spektakularna, ale wymaga dość rozbudowanych testów. Natomiast gdy mamy do czynienia np. z połączeniem banków (w listopadzie 2019 łączyły się Milenium i EuroBank oraz BNP Paribas i Raifeisen) zespoły testerskie wykonują niewidoczną dla klienta, ale kluczową rolę dbając by oszczędności, kredyty, lokaty itp. zostały zapisane w nowym systemie poprawnie.
Praca jest żmudna, odpowiedzialna, ale jednocześnie ciekawa.

Podsumowując

Dla testera testy migracji będą znaczącym etapem w rozwoju. Będą również ważną pozycją w portfolio zawodowym. Zachęcam do udziału w podobnych projektach.

W artykule Opowieści testerów – Sławomir przeczytasz historię tego, jak zostałem testerem oraz tego, jakie mam doświadczenie w testowaniu migracji danych.