Windows-alkalmazások tesztelése: gyakorlatias terv

Egy Windows-alkalmazás demó módban rendezettnek tűnhet, és mégis lelassíthatja a működést hétfő reggel. Egy nem mentett szállítólevél, egy három sikertelen kísérlet után zárolt felhasználó, vagy egy frissítés után máshogy viselkedő nyomtatási párbeszédablak nem kozmetikai hiba. Aki tudni szeretné, hogyan kell tesztelni Windows-alkalmazásokat, ezért ne egyedi gomboknál kezdje, hanem azoknál a folyamatoknál, amelyek munkát, pénzt, vagy nyomon követhetőséget kerülnek.

Éppen a raktárban, a műhelyben, a diszpozícióban, és az adminisztrációban sok kritikus folyamat évek alatt kinőtt asztali szoftveren fut. Ott nem az számít, hogy egy teszteset lenyűgözően van megfogalmazva. A döntő az, hogy a munkatársak megbízhatóan el tudják-e végezni feladataikat reális körülmények között - hiányos adatokkal, változó jogosultságokkal, lassú hálózatokkal, és nem tervezett megszakításokkal is.

A Windows-alkalmazások tesztelése a kritikus folyamatokkal kezdődik

Nem minden funkció érdemli meg ugyanazt a teszterőfeszítést. Egy ritkán használt, manuális utólagos munkát igénylő exportot másképp kell értékelni, mint egy áruátvétel könyvelését, a címke létrehozását, vagy a napi megrendelés-egyeztetést. Kezdje tehát egy egyszerű kérdéssel: mi történik konkrétan, ha ez a folyamat meghiúsul?

Magas prioritást kapnak a készletre, szállításra, számlázásra, biztonságra, vagy ügyfélkommunikációra közvetlen hatást gyakorló folyamatok. Ide tartozik például a bejelentkezés és a jogosultság-ellenőrzés, a törzsadatok létrehozása és módosítása, a tranzakciókönyvelések, a dokumentumnyomtatás, az ERP- vagy szállítási szolgáltatásokhoz kapcsolódó interfészek, valamint a hiba utáni újraindítás. Még a csak kis csoport által használt funkciók is kritikusak lehetnek, ha megakadályozzák a hónapzárást vagy az áru felszabadítását.

Ezekből a folyamatokból nem elvont tesztlisták, hanem nyomon követhető munkalépések keletkeznek. Egy áruátvételi teszt például kezdődhet egy meglévő megrendeléssel, rögzíthet egy részszállítást, jelenthet egy eltérő mennyiséget, hozzárendelhet egy raktárhelyet, majd ellenőrizheti, hogy a készlet, a könyvelési napló, és a nyomtatott dokumentum megegyezik-e. Így a szoftver tényleges hatását teszteli, nem csak egyedi beviteli mezőket.

Olyan tesztalap kiépítése, amely tükrözi a működést

Sok hiba csak akkor válik láthatóvá, amikor a tesztkörnyezet közel kerül a valósághoz. Egy alkalmazás üres teszt-bérlővel gyakran másképp viselkedik, mint több éves mozgásadattal, zárolt cikkekkel, hiányzó kötelező információkkal, vagy már megnyitott tranzakciókkal.

Ezért tudatosan hozzon létre tesztadatokat. Nem feltétlenül van szüksége a produkció teljes másolatára. Célszerűbb egy kontrollált adatállomány tipikus, határeseti, és szándékosan hibás esetekkel: eltérő mértékegységű cikkek, speciális feltételekkel rendelkező ügyfelek, részszállítású megrendelések, különböző szerepkörű felhasználók, és már folyamatban lévő tranzakciók. A személyes adatokat ekkor anonimizálni kellene, vagy valósághű mintaadatokkal helyettesíteni.

A tesztalaphoz tartozik a technikai környezet is. Dokumentálja a Windows-verziót, felbontást, méretezést, telepített nyomtatókat, hálózati meghajtókat, adatbázis-verziót, csatlakoztatott szolgáltatásokat, és jogosultságokat. Ez szárazon hangzik, de később időt takarít meg. Ha egy hiba csak 125%-os méretezésű munkaállomásokon vagy egy bizonyos nyomtatómeghajtóval fordul elő, annak reprodukálhatónak kell lennie.

Ne csak az ideális esetet ellenőrizze

Az ideális eset mindenekelőtt azt bizonyítja, hogy az alkalmazást a várt útra építették. A működésben mellette nehéz helyzetek keletkeznek. Mi történik, ha egy felhasználó üresen hagy egy kötelező mezőt, kétszer indítja el ugyanazt a könyvelést, vagy elveszíti a kapcsolatot mentés közben? Konzisztens marad a folyamat? Érthető üzenetet kap a felhasználó? Biztonságosan tovább tud dolgozni?

Windows-alkalmazásoknál emellett a kezelés és az állapot különösen releváns. A párbeszédablakok megjelenhetnek a háttérben, a billentyűparancsok átfedhetik egymást, a fájlválasztó párbeszédablakok blokkolhatják a folyamatot. Ellenőrizze, hogy a fókusz, a hibaüzenetek, és a zárolások egyértelműek-e. Egy technikai kivétel cselekvési útmutató nélkül nem segít a műszakvezetőnek.

Manuális teszteket ott alkalmazni, ahol ítélőképesség szükséges

A manuális tesztek nem az elégtelen érettség jelei. Nélkülözhetetlenek, amikor új folyamat keletkezik, egy felület átépítésre kerül, vagy szakmai tudás dönti el a minőséget. Egy tapasztalt raktárvezető gyorsabban felismeri, mint egy szkript, hogy egy képernyő érthető-e nagy időnyomás alatt, vagy hogy egy figyelmeztetés túl későn jelenik-e meg.

A manuális tesztelés azonban drágává és megbízhatatlanná válik, ha ugyanazokat a stabil folyamatokat minden verzió előtt megismétlik. Ekkor a kiadás rendelkezésre álló emberektől, memóriától, és szétszórt jegyzetektől függ. A helyes átmenet az automatizálásra általában ott van, ahol egy folyamatot gyakran végrehajtanak, jelentős kárt okozhat, és világos várt eredményei vannak.

Egy jó manuális teszteset leírja a kiindulási helyzetet, a lépéseket, a várt eredményt, és a szükséges adatokat. Hiba esetén adjon hozzá képernyőképet, időbélyeget, alkalmazás- és build-verziót, valamint a pontos műveletet. A "Nyomtatás nem működik" nem használható hibaleírás. "A szállítási cím módosítása után a nyomtatási párbeszédablak nyitva marad, a 4711-es megrendelés nem kap PDF-et, és nem jelenik meg semmilyen üzenet" - az igen.

Automatizált regressziós tesztek ismétlődő kockázatokra

Az automatizálás nem azt ellenőrzi, hogy egy szoftver alapvetően jó-e. Azt ellenőrzi, hogy a korábban működő, definiált folyamatok egy változtatás után is működnek-e még. Ez különösen értékes olyan Windows-szoftvereknél, amelyek felületeit, adatbázis-logikáját, és külső interfészeit éveken át tovább fejlesztik.

Kezdje kicsiben. Válasszon először öt-tíz üzletkritikus folyamatot, amelyeket minden kiadás előtt ellenőrizni kell. Ide tartozhat a bejelentkezés account-lockout folyamattal, a megrendelés-rögzítés, a raktári könyvelés, a PDF- vagy címkenyomtatás, a szerepkörváltás, és egy központi importálás. Csak akkor éri meg a különleges esetekre való kiterjesztés, ha ezek a tesztek megbízhatóan futnak.

Asztali alkalmazásoknál az automatizált tesztek gyakran látható felületi elemeket vezérelnek: ablakokat, beviteli mezőket, táblázatokat, gombokat, és párbeszédablakokat. Ez működik, de érzékenyebb, mint egy tiszta interfészteszt. Kisebb elrendezés-változások, lassabb számítógépek, vagy nem egyértelműen elnevezett elemek megszakíthatják a teszteket. Ezért a fejlesztőknek, a szakterületnek, és a tesztfelelősöknek közösen kellene meghatározniuk, mely elemek stabilan címezhetők, és mely ellenőrzési lépéseket jobb adatbázison, naplón, vagy interfészen keresztül biztosítani.

Egy értelmes teszt emellett nemcsak azt ellenőrzi, hogy egy gombra rá lehetett-e kattintani. A szakmai következményt is ellenőrzi: elmentődött-e a könyvelés? Helyes-e a készlet? Létrejött-e dokumentum? Nem jött-e létre duplikált rekord? A látható interakció és az ellenőrizhető eredmény összetartozik.

A bizonyítékok a tesztelés eredményének részei

Kritikus alkalmazásoknál önmagában a zöld állapot ritkán elegendő. Amikor egy teszt meghiúsul, a csapatoknak gyorsan válaszra van szükségük három kérdésre: mi volt a kiindulási helyzet? Melyik lépésnél hiúsult meg a folyamat? Mit mutatott az alkalmazás abban a pillanatban?

A képernyőképek, a futási naplók, és adott esetben a képernyőfelvételek megbeszélhetővé teszik a hibákat. Jelentősen lerövidítik az átadást az üzemeltetés, a QA, és a fejlesztés között. Szabályozott vagy biztonságtudatos vállalatoknál emellett szilárd alapot jelentenek a jóváhagyások és eltérések nyomon követéséhez.

Ennek során a tárolási hely nem mellékes kérdés. A tesztfuttatások tartalmazhatnak belső ügyféladatokat, árlistákat, megrendelési információkat, vagy képernyőnézeteket. Aki érzékeny Windows-alkalmazásokat tesztel automatizáltan, annak tisztáznia kell, hogy ezek az adatok elhagyhatják-e a saját infrastruktúrát. Az önállóan üzemeltetett környezet, mint a COCO, itt hasznos lehet, mert a teszt végrehajtása, a bizonyíték, és a kiértékelés saját kontroll alatt marad. Hogy ez szükséges-e, az adatvédelmi előírásoktól, a szerződéses helyzettől, és a védelmi igénytől függ - nem minden csapatnak van szüksége ugyanarra az architektúrára ehhez.

A tesztelés beépítése a kiadási folyamatba

A legjobb tesztkatalógus elveszíti értékét, ha csak egy kapkodó éles indítás után használják. Határozzon meg egy fix időpontot: az automatizált alap-regressziók minden kiadás előtt lefutnak, a manuális átvétel ellenőrzi az új vagy megváltozott folyamatokat, és az ismert korlátozásokat nyíltan dokumentálják.

Nem minden sikertelen tesztnek kell megállítania egy kiadást. Egy ritkán használt adminisztrációs nézetben lévő hiba elfogadható lehet, ha létezik biztonságos megkerülő megoldás, és az érintett terület egyértelműen tájékoztatva van. Egy hibát, amely helytelenül könyveli a készleteket, vagy észrevétlenül zárolja a felhasználókat, másképp kell kezelni. Ezt a döntést az üzleti hatás alapján kellene meghozni, nem pusztán a piros tesztek száma alapján.

Tartsa karban a teszteket az alkalmazással együtt. Ha egy folyamat tudatosan megváltozik, frissítse a tesztesetet, a tesztadatokat, és a várt eredményt együtt a követelménnyel. Az elavult tesztek zajt keltenek, és idővel figyelmen kívül hagyják őket. Néhány megbízható ellenőrzés többet ér, mint több száz automatizált folyamat, amelyek eredményeit már senki sem veszi komolyan.

Végső soron nem arról van szó, hogy minden elképzelhető bevitelt szimuláljunk. Arról van szó, hogy megvédjük azt a munkát, amelynek másnap reggel ismét működnie kell. Kezdje egyetlen kritikus folyamattal, tegye bizonyíthatóvá az eredményét, és onnan építkezzen tovább.