All in one - folyamat alapú tesztelés
- Folyamatfejlesztes
- Apr 2, 2019
- 2 min read
Egy folyamat automatizálásánál nemcsak a jelenlegi folyamatot kell tudni lefedni, hanem jó, ha van lehetőség azt kicsit hatékonyabbá tenni és néhány olyan dologgal "felturbózni", ami
✔ az ügyfélnek értéket jelent,
✔ nálunk mudaként jelentkezik és
✔ megvalósítható az új szoftverben is.
A projektben a folyamatokat folyamatábrákkal mutattuk be, ehhez találtunk ki üzleti igényeket. Az ábrák relevanciáját csak erősíti az, ha a cég egy multinacionális vállalat és a szoftvert is minden leányvállalatnál be akarják vezetni a különböző országokban.
A tapasztalat szerint sok esetben nem ugyanúgy folynak a munkák a különböző országokban, aminek oka lehet akár az eltérő jogi szabályozás, akár az infrastruktúrális környezet. Ilyenkor nagy segítséget jelent az ábra, mert segít közös nevezőre hozni a folyamattal kapcsolatos tudást és meg lehet jelölni benne az egyes országok közötti eltéréseket.
A folyamatábra kiváló támpontot ad az üzleti igények megfogalmazásához is.
Így biztosak lehetünk benne, hogy az egész folyamaton végigmentünk, mindenre gondoltunk. Az üzleti igényeket, folyamatokhoz, akár folyamatlépésekhez lehet kötni, illetve vannak olyan notációk (ábrázolási rendszerek), amikkel egy-egy vagy akár az összes adatobjektumot is ki tudjuk fejteni (gondolok itt azokra az adatcsomagokra például, amik vagy egy dokumentumból kerülnek be a rendszerbe, vagy a rendszerből kerülnek ki egy tájékoztató levélbe).
👍 Segíti a megértést,
👍 rövidebb munkaidőt eredményez,
👍 könnyebb validálni és
👍a fejlesztőknek lefejleszteni úgy, hogy átlátják és kontextusban tudják értelmezni a leadott üzleti igényeket, lehet, hogy tudnak egyszerűbb megoldási javaslattal szolgálni,
👍nem utolsó sorban kevesebb a hibázási lehetőség, így a hibajavítás is.
Ha megtörtént a folyamat megértése, üzleti igények összegyűjtése és a validációs kör(ök), akkor a fejlesztést követően sor kerülhet a tesztelésre.
Ekkor elő lehet venni pontosan azt a folyamatábrát (és a kötelezően mellékelendő jobb esetben excelt 😒, rosszabb esetben word-öt😢), ami tele van tűzdelve üzleti igényekkel, adatobjektumokkal és el lehet kezdeni a folyamat alapú tesztelést.
Vigyázat, ha nem tudjuk felhasználni pontosan azt a folyamatábrát, akkor egyrészt kihagytak valamilyen egyeztetésből, aminek a folyamat torzulása lehet a következménye, másrészt nem biztosítható a folyamat alapú tesztelés sem és a fejlesztések nyomonkövetése sem.
Fontos, hogy ne csak azokat teszteljük le, amiket üzleti igényként meghatároztunk, hanem az egész folyamatot, ugyanis nem lehet tudni, hogy egy adott fejlesztés a háttérben milyen hatást váltott ki a különböző folyamatlépésekre a folyamatokban. Meg lehet jelölni a részeket, amik nem/vagy nem úgy működnek, vissza lehet rá később térni és ez segíti reprodukálni is a hibát, mivel nyomonkövethető annak előállítása a folyamat mentén.
Ilyen értelemben szerintem nem baj, ha a tesztelést a folyamatfejlesztő végzi, vagy készíti elő, mert nagy hozzáadott értéket jelenthet nemcsak az, hogy a folyamatok mentén nagyobb a valószínűsége annak, hogy a tesztelés teljeskörű lesz, hanem annak is meg lehet a színtere, hogy a szoftveren/rendszeren kívül a manuális folyamatok is tesztelésre kerüljenek, mert valójában így adja ki ténylegesen a teljes egészet és csakis így biztosítható a teljesség.
Amit még mindenképpen érdemes lenne végiggondolni, hogy a riportok/jelentések/mutatószámok készítése az optimalizálás előtt és után milyen mennyiségben és mekkora befektetett munkával teremt még értéket. Ezt majd a következőkben még boncolgatom kicsit.
Comments