Dodávateľ ukáže pekné demo. Nový záznam sa uloží, graf sa prekreslí a e-mail príde. To ešte neznamená, že firma môže prestať používať starý systém.
Pri prevzatí potrebujete overiť, či tím dokončí svoju prácu aj s bežnými výnimkami. Obchod sa vráti na doplnenie, človek zmení pobočku, dokument sa nahrá druhýkrát a účtovný systém chvíľu neodpovedá. Práve tieto situácie sa v pripravenom deme ľahko stratia.
Preberacie skúšky nenahrádzajú technické testy vývojárov. Dopĺňajú ich o prevádzkovú správnosť: či pravidlá, údaje a výsledky zodpovedajú vašej firme. Ich základ si dohodnite už v zadaní pre dodávateľa.
Pripravte scenár, nie názov funkcie
Položka „otestovať ponuky“ nikomu nepovie, čo má urobiť. Lepší scenár obsahuje rolu, vstup, kroky a očakávaný výsledok.
Napríklad: obchodník vytvorí ponuku pre klienta s dvomi prevádzkami. Vyberie správnu prevádzku, pridá dohodnutú zľavu a odošle ponuku na schválenie. Vedúci ju schváli. Koordinátor vidí iba schválenú verziu a správne miesto realizácie.
Ku scenáru pridajte aj dôkaz. Môže to byť identifikátor skúšobného prípadu, výsledný dokument alebo export. Pri opakovanej skúške potom nemusíte hádať, ktorú ponuku ste včera kontrolovali.
Vyberte ľudí, ktorí túto prácu skutočne robia
Aspoň jeden scenár by mal prejsť budúci používateľ bez vedenia dodávateľom. Vysvetlite cieľ, nechajte ho pracovať a zapisujte, kde sa zastavil. Ak potrebuje doplniť pokyn, je to užitočná spätná väzba na rozhranie alebo zaškolenie.
Zapojte aj človeka z ďalšieho kroku procesu. Obchodník môže považovať ponuku za hotovú, no koordinátorovi chýba rozsah realizácie. Takýto problém odhalí až odovzdanie medzi rolami.
Určte jedného koordinátora testovania. Zbiera výsledky, rozlišuje chyby od nových požiadaviek a udržuje zoznam opakovaných skúšok. Bez tejto roly sa pripomienky rozdelia medzi chat, e-mail a telefonáty.
Skúška 1: bežný prípad od začiatku po koniec
Vytvorte nový prípad, spracujte ho, schváľte a ukončite. Skontrolujte všetky výstupy, na ktorých závisí ďalší tím: dokument, objednávku, termín, report aj údaj poslaný do iného systému.
Potom porovnajte výsledok so súčasným postupom. Každý rozdiel nemusí byť chyba. Nový systém môže počítať správne a stará tabuľka nesprávne. Rozdiel však musí niekto vysvetliť a potvrdiť.
Pri prehľadoch používajte niekoľko prípadov, ktoré poznáte do detailu. Overte súčet, filtre, dátumové obdobie a to, či sa do výsledku nezapočítala zrušená položka. Veľký graf z neznámych dát sa posudzuje ťažko.
Skúška 2: zmena a návrat do predchádzajúceho kroku
Zmeňte údaj, ktorý ovplyvňuje ďalšiu prácu. Môže ísť o termín, kontaktnú osobu, cenu alebo pobočku. Skontrolujte, kam sa zmena prenesie a kde má zostať pôvodná hodnota.
Vráťte schválenie na doplnenie. Zistite, kto dostane upozornenie a či po úprave treba nové schválenie. Pri dokumentoch overte, ktorá verzia je platná a či sa už podpísaný súbor nemôže nenápadne prepísať.
V projekte Transfer majú dodatky, ukončenia a pracovné pridelenia vlastné postupy. Podobné situácie treba v každom systéme pomenovať samostatne. Jediný úspešný nástup neoverí celý životný cyklus záznamu.
Skúška 3: človek vidí iba to, čo má
Pripravte skúšobné účty pre jednotlivé roly a pobočky. Overte povolenú prácu aj odmietnuté operácie. Používateľ z jednej firmy nesmie získať dokument inej firmy iba preto, že pozná jeho odkaz.
Kontrola oprávnení musí prebiehať aj na serveri pri jednotlivých požiadavkách. Skryté tlačidlo samo o sebe prístup nechráni. Tento princíp vysvetľuje OWASP v odporúčaniach pre autorizáciu.
Technické pokusy s priamymi požiadavkami nech vykoná poverený vývojár alebo tester v dohodnutom prostredí. Váš tím má predovšetkým potvrdiť pravidlá: kto smie čítať, meniť, exportovať a schvaľovať jednotlivé údaje.
Skúška 4: import a opakovaný prenos
Po skúšobnom importe porovnajte počty, vzorku záznamov, prílohy a väzby. Overte aj záznam s chýbajúcim povinným údajom. Potrebujete vedieť, či sa odmietne, odloží na opravu alebo doplní dohodnutým spôsobom.
Rovnaký prenos spustite v testovacom prostredí znovu. Skontrolujte, či nevznikli nechcené duplicity a či sa zmeny spracovali podľa dohodnutých pravidiel. Pri každej chybe má byť dohľadateľné, ktorý záznam a ktorá operácia zlyhali.
Pri napojení na účtovníctvo alebo podpisovanie použite skúšobné účty a dáta. Testovanie nemá nechtiac vystaviť skutočnú faktúru alebo odoslať klientovi dokument na podpis.
Skúška 5: výpadok a návrat do práce
Dohodnite s dodávateľom kontrolovanú skúšku nedostupnej integrácie. Používateľ má dostať zrozumiteľný stav. Tím má vedieť, či sa operácia zopakuje automaticky, čaká na opravu alebo sa vôbec nezačala.
Samostatne si nechajte ukázať obnovu zo zálohy v testovacom prostredí. Výsledkom má byť použiteľná obnovená aplikácia alebo dáta, nie iba zelená ikona zálohovania. Zaznamenajte čas skúšky a to, ktoré údaje sa obnovili.
Pripravte aj dočasný pracovný postup pre ľudí. Ak na hodinu nefunguje plánovanie, kde koordinátor zachytí novú zákazku a ako ju neskôr doplní? Zrozumiteľná odpoveď patrí k pripravenosti na spustenie.
Ako zapísať chybu, aby sa dala opraviť
Každý záznam má obsahovať rolu, prostredie, čas, kroky, očakávaný a skutočný výsledok. Priložte obrázok bez citlivých údajov alebo identifikátor skúšobného prípadu. „Nefunguje export“ je horší podklad než opis konkrétneho filtra a chýbajúcej položky.
Rozlišujte chybu blokujúcu prevádzku, chybu s prijateľným dočasným postupom a drobný problém zobrazenia. Pri každej rozhodnite, kto ju opraví a kto opravu znovu vyskúša. Ústne „už je to hotové“ nie je výsledok opakovanej skúšky.
Rozhodnutie o spustení
Pred prepnutím potvrďte výsledky povinných scenárov, zoznam otvorených chýb, plán importu a zodpovedných ľudí. Dohodnite čas posledného zápisu do starej evidencie a spôsob prípadného návratu. Pri súbežnej prevádzke musí byť jasné, ktorý systém je pre daný údaj rozhodujúci.
Záver skúšok má odpovedať na praktickú otázku: dokáže tím zajtra dokončiť svoju prácu a vie, koho kontaktovať pri probléme? Ak chcete pripraviť prvé scenáre pre svoj systém, prejdime spolu jeden pracovný postup.
