Testni podaci poslovne integracije ne moraju biti kopija produkcije. Za pouzdanu provjeru potrebno je odabrati reprezentativne poslovne scenarije, rubne slučajeve i stvarne odnose među zapisima, uz uklanjanje nepotrebnih osobnih podataka. Polazište nije pitanje koliko redaka prenijeti, nego koje odluke, tokove i iznimke integracija mora obraditi.
Kopiranje cijele produkcije često izgleda kao najbrži put do realističnog testa. U praksi otvara nekoliko pitanja: koji su podaci doista potrebni, tko odobrava njihov prijenos, ostaju li veze među zapisima valjane i može li se iz testnog skupa ponovno prepoznati osoba.
Bolji je postupak izgraditi mali, namjenski skup. Takav skup obuhvaća transakcije koje pokazuju očekivano ponašanje procesa i one koje provjeravaju njegove granice. Primjerice, integracija naloga između ERP-a i vanjskog sustava može zahtijevati otvoren, djelomično obrađen i zatvoren nalog, stavku bez izborne vrijednosti, promjenu šifre partnera, poništenje i ponovljenu obradu iste poruke.
Broj zapisa nije mjerilo pokrivenosti. Mjerilo je mogućnost provjere poslovne odluke: što se šalje, što se odbija, što se evidentira kao iznimka i tko odlučuje o nastavku rada.
Prije tehničkog rada korisno je proći Screening poslovnog procesa i zapisati granice procesa. Time se izbjegava čest propust: tehnički ispravna poruka koja poslovno vodi u pogrešno stanje.
Za svaki tok integracije prvo navesti poslovne događaje. Zatim svakom događaju pridružiti najmanji skup zapisa potreban za provjeru.
Praktičan početni skup scenarija može sadržavati:
Ovaj popis nije univerzalan. Proizvodnja, računovodstvo i prodaja koriste različite statuse, odgovornosti i posljedice pogreške. Vlasnik procesa mora potvrditi scenarije jer tehnički tim ne može sam odrediti prihvatljivu poslovnu iznimku.
U hipotetskom procesu ERP šalje nalog vanjskom sustavu, a vanjski sustav vraća status isporuke. Testni skup ne treba sadržavati sve stvarne kupce ni cijelu povijest naloga. Potrebni su, primjerice, jedan nalog s jednom stavkom, jedan s više stavki, nalog s djelomičnom isporukom, nalog s otkazivanjem i nalog za koji povratni status ne odgovara očekivanom stanju ERP-a.
Za svaki nalog treba zadržati veze koje test provjerava: zaglavlje i stavke, šifre artikala, skladište, status, referencu vanjskog sustava i redoslijed događaja. Naziv kupca, kontakt, adresa, osobni identifikatori i drugi podaci bez testne svrhe ne ulaze u skup. Ako je polje nužno za format poruke, koristiti sintetičku vrijednost prema dogovorenom pravilu, a ne stvarni osobni podatak.
Integracije često ovise o vezama: dokument pripada partneru, stavka pripada dokumentu, knjiženje pripada kontu, a status se vraća na prethodni događaj. Zato je korisnije odabrati povezane lance zapisa nego nasumično uzorkovati retke iz više tablica.
Ograničenja podataka mogu pomoći pri tehničkoj provjeri skupa. Jedinstvenost, obvezna polja i vanjski ključevi tipični su mehanizmi za provjeru identiteta zapisa i njihovih veza. PostgreSQL dokumentacija opisuje ograničenja poput UNIQUE , NOT NULL i stranih ključeva te njihovu ulogu u integritetu podataka: PostgreSQL Constraints .
No ograničenje baze nije poslovno pravilo. Ono može spriječiti duplikat ili vezu na nepostojeći zapis, ali ne određuje smije li se nalog poslati nakon određenog statusa, tko odobrava korekciju ili koja je reakcija na djelomičnu isporuku. Takva pravila treba zasebno zapisati, dodijeliti im vlasnika i provjeriti ih kroz scenarij.
Maskiranje mijenja vrijednost polja. To može uključivati zamjenu imena, adrese, e-pošte ili broja dokumenta. Korisno je, ali samo po sebi ne potvrđuje kako se osoba ne može prepoznati iz kombinacije preostalih polja, veza i rijetkih događaja.
Kod anonimiziranih poslovnih scenarija potrebno je postaviti dodatno pitanje: može li osoba biti rekonstruirana ili razumno izdvojena iz testnog skupa uz podatke koji su dostupni osobama s pristupom testu? Odgovor ovisi o sadržaju skupa, kontekstu pristupa i kombinaciji atributa. Ne postoji univerzalna zamjena polja koja sama rješava taj rizik.
Zato postupak treba uključiti provjeru:
Kada se rizik ne može prihvatljivo procijeniti ili smanjiti, sigurniji izbor je sintetički scenarij. Sintetički podaci ipak moraju zadržati format, kardinalnost, šifarnike i međusobne veze potrebne za integracijski test.
Za svako polje i vezu korisno je donijeti jednu od četiri odluke:
Odluku treba povezati s vlasnikom. Poslovni vlasnik potvrđuje scenarij i posljedicu iznimke. Vlasnik izvornog podatka potvrđuje značenje, dostupnost i ograničenja ulaza. Tehnički vlasnik definira ekstrakciju, transformaciju, učitavanje i provjere. Osoba odgovorna za test potvrđuje izvršenje i evidenciju rezultata. Kada se odgovornosti ne razdvoje, maskiranje često postane tehnički zadatak bez poslovne provjere.
Prije izrade skupa potvrditi sljedeće stavke.
Kriteriji moraju biti provjerljivi bez izmišljene početne ili ciljne vrijednosti. Primjeri su:
Mali skup podataka neće otkriti svaki problem razmjera, vremena obrade ili rijetke kombinacije iz produkcije. Potpuna kopija produkcije također nije dokaz pune pokrivenosti: može propustiti eksplicitno testiranje iznimke i donijeti nepotrebne podatke u testno okruženje.
Zato odvojiti dva pitanja. Prvo je funkcionalna i poslovna pokrivenost scenarija. Drugo je opterećenje, volumen i ponašanje pod većim brojem poruka. Za drugo pitanje pripremiti zaseban plan s podacima koji su prikladni za takav test.
Sljedeći korak je održati kratku radionicu s vlasnikom procesa, vlasnikom izvornog podatka i tehničkim vlasnikom. Kao izlaz radionice trebaju nastati popis scenarija, odluke po poljima i vezama, iznimke te kriteriji prihvata. Kada su granice procesa nejasne, Razgovarajte s ORKA timom o strukturiranju tog pregleda.