Manuális vagy automatizált tesztelés — mikor éri meg?
Az automatizálás akkor éri meg, ha ugyanazt a tesztet sokszor kell ugyanúgy lefuttatni: a stabil, üzletkritikus folyamatok regressziójánál, gyakori kiadások mellett. Az új funkciót, a feltáró tesztet és a felhasználói átvételt kézzel érdemes tesztelni. A megtérülés egyetlen képlettel becsülhető: az egyszeri felépítési költség osztva az évente megspórolt kézi ráfordítással. Az alábbi számpéldában minden feltevés látható, a saját számaival újraszámolhatja.
Mikor érdemes automatizálni?
Akkor, ha egy teszt egyszerre stabil, gyakran fut és üzletkritikus. Minél több igaz az alábbiakból, annál gyorsabban térül meg:
Mennyibe kerül a kézi és az automatizált tesztelés? Számpélda
A számításhoz hat bemenet kell. Kettő (N és M) a közepes Dynamics 365 rendszereknél jellemző sáv; a többi feltevés, amelyet a saját helyzetére kell cserélni. A példa nem ajánlat és nem mért eredmény, hanem a módszer bemutatása.
| Jel | Mit jelent | Érték a példában | Honnan |
|---|---|---|---|
| N | kiadások száma évente (két Microsoft-hullám, saját fejlesztések, javítások) | 6 / 8 / 10 | jellemző sáv: 6–10 |
| M | kézi regressziós teszt kiadásonként | 2 / 3,5 / 5 embernap | jellemző sáv közepes Dynamics 365 rendszernél: 2–5 embernap |
| B | az automatizált készlet felépítése (egyszeri) | 30 embernap (40 teszteset × 0,75 nap) | feltevés — a valós érték az eszköztől és a rendszertől függ |
| A | automatizált futás után kiadásonként: hibaelemzés, tesztkarbantartás (1 nap) és a maradék kézi ellenőrzés (0,5 nap) | 1,5 embernap | feltevés |
| L | eszközlicensz évente | 0 (Playwright) | Tosca vagy Katalon csapatverzió esetén az éves díjjal nő a költség |
| D | napidíj | a saját napidíja | a példa embernapban számol; forintra a saját belső vagy tesztelői napidíjával szorozza fel |
A képlet: éves megtakarítás = N × (M − A) − L/D (embernapban), megtérülés = B ÷ éves megtakarítás (években). A kézi regresszió is, az automatizált futtatás utáni munka is a napidíjjal szorozva lesz forint.
| Forgatókönyv | Kézi regresszió évente (N × M) | Automatizált futtatás évente (N × A) | Megtakarítás évente | Megtérülés (B ÷ megtakarítás) |
|---|---|---|---|---|
| Kis rendszer: 6 kiadás, 2 nap | 12 embernap | 9 embernap | 3 embernap | kb. 10 év — nem éri meg |
| Közepes: 8 kiadás, 3,5 nap | 28 embernap | 12 embernap | 16 embernap | kb. 23 hónap |
| Nagy: 10 kiadás, 5 nap | 50 embernap | 15 embernap | 35 embernap | kb. 10 hónap |
Mindhárom sorban ugyanaz a 30 embernapos felépítés és licenszdíj nélküli eszköz. Ha Tosca- vagy Katalon-licensz is kell, annak éves díja a megtakarításból vonódik le, és a megtérülés kitolódik.
Mit mutat a számpélda a megtérülésről?
Gyakorlati ökölszabály: ha a kézi regresszió kiadásonként legalább 3 embernap, és évente legalább 8 kiadás van, az automatizálást érdemes kiszámolni. Release wave-ekkel ez a Dynamics 365 rendszerek többségére igaz — lásd miért romlik el a testreszabás a release wave-nél.
Melyik teszttípus marad kézi, és melyik automatizálható?
| Teszttípus | Mire való | Kézzel vagy automatizáltan? |
|---|---|---|
| Funkcionális teszt | az új vagy módosított funkció megfelel-e a követelménynek | először kézzel; ami stabil és üzletkritikus, átkerül az automatizált regresszióba |
| Feltáró teszt | forgatókönyv nélküli, időkeretes keresés a szélsőséges esetek és váratlan utak hibáira | mindig kézzel — ez emberi kíváncsiság, nem szkript |
| Rendszerintegrációs teszt (SIT) | az adat végponttól végpontig átjut-e: CRM → ERP → számlázó | az első kör kézzel; a stabil interfészek API-szinten automatizálhatók |
| Felhasználói átvételi teszt (UAT) | az üzlet elfogadja-e a megoldást | kézzel, a kulcsfelhasználók végzik; ez üzleti döntés, nem automatizáljuk |
| Kézi regressziós teszt | ami eddig működött, működik-e a változás után | a fő automatizálási jelölt: ugyanaz, sokszor, ugyanúgy |
A kettő tehát nem verseny, hanem munkamegosztás: a kézi tesztelés az újat és az emberi ítéletet igénylőt fedi, az automatizálás a régit védi. A kézi tesztesetek közben nem vesznek el — a stabilakból lesz az automatizált készlet.
Mi az a tesztpiramis, és hová kerül benne a felületi teszt?
A tesztpiramis azt mutatja, melyik szinten hány tesztet érdemes tartani: alul sok gyors és olcsó, felül kevés lassú és drága.
Dynamics 365-ben a legtöbb kockázat a testreszabásokban és az integrációkban van, ezért a felületi szint mellett az API-szintet is lefedjük. A részleteket és az eszközöket a tesztautomatizálás oldalon írjuk le.
Hogyan érdemes elkezdeni?
Gyakori kérdések
Mennyibe kerül a tesztautomatizálás?
Három tételből áll: az eszközlicensz (Playwright ingyenes, a Tosca és a Katalon csapatverziója éves díjas), a tesztkészlet felépítése (egyszeri) és a karbantartás (folyamatos). A fenti számpélda a módszert mutatja; konkrét ajánlatot a rendszer és a tesztesetek felmérése után adunk.
Mikor térül meg a tesztautomatizálás?
Ha az egyszeri felépítési költség osztva az évente megspórolt kézi ráfordítással elfogadható időt ad. A példánkban kis rendszernél kb. 10 év (nem éri meg), közepesnél kb. 23 hónap, nagynál kb. 10 hónap — a feltevések a táblázatban láthatók.
Kiváltja az automatizálás a manuális tesztelést?
Nem. A regressziót váltja ki, az új funkciók tesztjét, a feltáró tesztet és a felhasználói átvételt nem. A kettő munkamegosztás.
Hány tesztesetet érdemes automatizálni?
Egy közepes Dynamics 365 rendszernél 30–50 kockázatalapon kiválasztott teszteset fedi a kockázat nagyjából 80 %-át. A ritka, változékony vagy egyszeri eseteket kézzel olcsóbb ellenőrizni.
Milyen gyorsan van eredmény?
Az eredmény már az első körrel megjelenik: néhány kritikus folyamat automatizált tesztjével kezdünk, és ezek rögtön CI-ben futnak; onnantól minden kiadás előtt van visszajelzés.
Beszéljünk a projektjéről.
Vegye fel velünk a kapcsolatot, és néhány napon belül jelentkezünk Önnél!
Kapcsolatfelvétel