A minőség nem az utolsó ellenőrzés. A fejlesztés teljes folyamatának tulajdonsága.

Először azt határozzuk meg, mit jelent ennél a terméknél a „jó”

A minőség többdimenziós. Ide tartozhat a helyes üzleti működés, a használhatóság, a teljesítmény, a biztonság, a hozzáférhetőség, a kompatibilitás, az adatpontosság, a rendelkezésre állás és a helyreállíthatóság. Ezek közül nem mindegyik egyformán fontos minden terméknél.

A minőségstratégia összeköti a termék kockázatait a szükséges ellenőrzésekkel. Meghatározzuk a kritikus felhasználói utakat, a magas következménnyel járó hibákat, az automatizálásra érdemes területeket, a szükséges tesztkörnyezeteket és azt, milyen eredmény kell egy kiadás elfogadásához.

Kockázatalapú tesztelés

A tesztelési figyelmet a hiba valószínűsége és következménye alapján osztjuk el. Egy ritkán használt képernyő kisebb vizuális eltérése más súlyú, mint egy jogosultsági hiba, adatvesztés, helytelen számítás vagy a fő ügyfélfolyamat leállása. A prioritások nyílt kimondása segít abban, hogy a korlátozott idő a legfontosabb bizonyítékokra fordítódjon.

Elfogadási feltételek

Az olyan megfogalmazás, mint „működjön megfelelően”, nem tesztelhető követelmény. A funkciókhoz megfigyelhető állapotokat, kimeneteket, hibaviselkedést és jogosultsági feltételeket fogalmazunk meg. Ez közös kapaszkodót ad a termékmenedzsmentnek, a fejlesztésnek és a tesztelésnek.

Nem tesztesetek halmaza, hanem fenntartható ellenőrzési rendszer

Nagyobb terméknél a tesztautomatizáció önálló szoftvertermékké válik. Kódja, függőségei, környezetei, adatai és karbantartási igényei vannak. Ha minden teszt más mintát követ, az eredmények ingadoznak, a futás lassú, a hibák pedig nehezen értelmezhetők, az automatizáció a bizalom helyett új zajt termel.

Az enterprise keretrendszer egységesíti a tesztfelépítést, a konfigurációt, az adatelőkészítést, a környezetkezelést, a riportolást és a hibadiagnosztikát. Törekszünk arra, hogy egy sikertelen ellenőrzésből gyorsan kiderüljön: valódi termékhiba, környezeti probléma, instabil teszt vagy hibás tesztadat okozta-e.

A keretrendszer lehetséges elemei

• újrafelhasználható tesztkomponensek és konvenciók
• környezetenként elkülönített konfiguráció
• kontrollált tesztadat-előkészítés és takarítás
• API- és felületi segédrétegek
• párhuzamos vagy célzott tesztfuttatás
• képernyőképek, hálózati és alkalmazásnaplók a hibák vizsgálatához
• egységes riportok és eredménytörténet
• CI/CD-folyamatba kapcsolt minőségi kapuk
• instabil tesztek felismerése és karbantartási folyamata
• jogosultságok és titkos konfigurációk védett kezelése

Az ember nem egy lassúcska automata teszt

A manuális tesztelő értéke a megfigyelésben, összefüggések felismerésében és új kérdések feltevésében van. A feltáró tesztelés során a tesztelő egyszerre tanulja a terméket, hajt végre vizsgálatot és alakítja a következő ellenőrzési irányt. Ez különösen hasznos új funkciónál, bizonytalan követelménynél, összetett használati helyzetnél és felhasználói élmény vizsgálatánál.

Az előre rögzített ellenőrzőlisták és tesztesetek ott értékesek, ahol következetes lefedettséget, auditálhatóságot vagy ismételhetőséget kell biztosítani. A feltáró és a szkriptelt megközelítés nem egymás alternatívája; együtt adnak jobb képet.

Használhatósági hibák

Egy funkció technikailag helyes lehet, miközben a felhasználó nem érti, mi történt, nem találja a következő lépést, vagy félreérthető visszajelzést kap. A QA a következetességet, az állapotok láthatóságát, a hibaüzeneteket és a megszakított folyamatokból való visszatérést is vizsgálhatja.

Az új funkció nem ronthatja el csendben a régit

A regressziós készlet a termék legfontosabb, korábban működő képességeit ellenőrzi egy változtatás után. Nem kell minden korábbi tesztet minden kiadásnál azonos módon lefuttatni. A változás hatóköre, a komponensek függősége és a kockázat alapján célzott készlet választható.

A gyakran futó regressziós tesztek automatizálása gyors visszajelzést adhat, de csak akkor, ha az eredmények megbízhatók. Az ingadozó, ok nélkül időnként elbukó tesztek csökkentik a csapat figyelmét. Az instabilitást ezért hibaként kezeljük, nem a tesztautomatizáció természetes állapotaként.

Nem elég, hogy működik. A szükséges terhelés mellett is használhatónak kell maradnia.

A teljesítményvizsgálat célja a rendszer válaszidejének, áteresztőképességének, erőforrás-használatának és stabilitásának megismerése meghatározott terhelési modell mellett. A teszt csak akkor értelmezhető, ha valószerű felhasználói viselkedést, adatméretet, rendszerkapcsolatokat és mérési környezetet képvisel.

Több ellenőrzési réteg, nem egyetlen „biztonságos” pecsét

A biztonsági tesztelés célja a sebezhetőségek és gyenge konfigurációk felismerése, valamint annak ellenőrzése, hogy a rendszer biztonsági kontrolljai a tervezett módon működnek-e. Egy sikeres vizsgálat nem bizonyítja, hogy a szoftverben nincs ismeretlen hiba vagy jövőben megjelenő sérülékenység. A biztonság folyamatos kockázatkezelés.

A jó hibajegy nem ítélet, hanem reprodukálható bizonyíték

A hibaleírás tartalmazza az érintett verziót és környezetet, a kiinduló állapotot, a reprodukció lépéseit, a várt és tényleges eredményt, valamint a rendelkezésre álló műszaki nyomokat. A prioritást nem a hiba látványossága, hanem az üzleti hatás, az érintett felhasználók, a kerülőút és az előfordulás valószínűsége alapján kell meghatározni.

A tesztjelentés nem pusztán sikeres és sikertelen esetek száma. Összefoglalja a vizsgálat hatókörét, a nem tesztelt területeket, az ismert korlátozásokat, a nyitott kockázatokat és azt a verziót, amelyre az eredmény vonatkozik. Ez teszi lehetővé a tudatos kiadási döntést.

A QA információt ad a döntéshez – nem veszi át az üzleti felelősséget

Az élesítés előtti értékelés bemutatja a kritikus funkciók állapotát, a regressziós eredményt, a nyitott hibákat, a teljesítmény- és biztonsági kockázatokat, valamint az ismert környezeti korlátokat. A termék-, üzleti és technikai felelősök ezek alapján hoznak kiadási döntést.

Bizonyos eltérések elfogadhatók lehetnek későbbi javítással, mások azonnali blokkolást indokolnak. A lényeg, hogy a kompromisszum ismert és dokumentált legyen, ne az éles használat során derüljön ki véletlenül.