Bevezetés
Jó napot, Habr-lakók. Nemrég egy tesztfeladatot oldottam meg egy fintech cég QA Lead pozíciójára. Az első feladat, egy tesztterv elkészítése teljes ellenőrzőlistával és példákkal, hogy ellenőrizzük egy elektromos vízforraló működését, trivialis feladatként kezelhető.
Nehezen találhatunk jobb teszttervet teljes ellenőrzőlistával.
A második rész viszont már azt a kérdést vetette fel: "Vannak-e olyan problémák, amelyek minden tesztelő számára akadályozzák a hatékony munkát?"
Az első dolog, ami eszembe jutott: sorra venni az összes észlelhető problémát, amivel a tesztelés során találkoztam, elvetni a lényegteleneket, az összes többit általánosítani. De gyorsan rájöttem, hogy az induktív módszer a kérdésre nem a "mindenki"-ről, hanem legjobb esetben a "többség"-ről ad választ. Ezért úgy döntöttem, hogy más szemszögből közelítek, deduktív módon, és íme, amit találtam.
Definíciók
Az első dolog, amit általában tesztelés közben teszek, hogy megpróbálom megérteni, miről is szól a feladat, ehhez pedig meg kell értenem a feladatban használt szavak jelentését. A kulcsszavak, amelyekkel foglalkozni kell:
- probléma
- tesztelő
- tesztelő munkája
- a tesztelő hatékonysága
Kérjük, nézzünk utána a Wikipédiának és az egészséges észnek:
(ó-görög πρόβλημα) széles értelemben - egy összetett elméleti vagy gyakorlati kérdés, amely tanulmányozást, megoldást igényel; a tudományban - ellentmondásos helyzet, amely ellentétes nézőpontok formájában jelentkezik bármilyen jelenség, objektum, folyamat magyarázatában, és amely megfelelő elméletet követel meg a megoldásához; az életben a probléma egyértelműen fogalmazódik meg az emberek számára abban a formában, hogy "tudom, hogy mit, de nem tudom, hogyan", azaz ismert, hogy mit kell elérni, de nem ismert, hogyan lehet ezt megtenni. A késői latin problēma szónak, a görög πρόβλημα „előrevetett, elénk állított” szóból származik; a προβάλλω „előre dobni, magunk elé állítani; vádolni” kifejezésből.
Nincs túl sok értelme, valójában a "probléma" = "bármilyen dolog, amivel foglalkozni kell".
— szakember (a típusok megkülönböztetése nélkül, mivel minden tesztelő érdekel minket), aki részt vesz egy komponens vagy rendszer tesztelésében, és tevékenysége eredménye a következő:
— a teszteléshez kapcsolódó intézkedések komplexuma.
(latinul: effectivus) — a elért eredmény és a felhasznált erőforrások közötti arány (:2015).
— a cselekvések (vagy események) sorozatának következménye, amely minőségi vagy mennyiségi formában fejeződik ki. A lehetséges eredmények közé tartozik az előny, a hátrány, a haszon, a veszteség, az érték és a győzelem.
Ahogy a "problémához" is, itt is kevés az értelme: valami, ami a munka eredményeként keletkezett.
— mennyiségileg mérhető képessége egy személy vagy emberek tevékenységének végrehajtására; körülmények, amelyek lehetővé teszik, hogy bizonyos átalakításokkal kívánt eredményt kapjunk. A tesztelő egy ember, és a létfontosságú erőforrások elmélete szerint minden ember négy gazdasági eszközzel rendelkezik:
pénzeszközök (jövedelem) — megújuló erőforrás;
energia (életerő) — részben megújuló erőforrás;
idő — fix és alapvetően nem megújuló erőforrás;
tudás (információ) — megújuló erőforrás, amely a humán tőke része, ami növelhető és csökkenthető is..
Szeretném megjegyezni, hogy a hatékonyság meghatározása az esetünkben nem teljesen pontos, mivel minél több tudást használunk, annál alacsonyabb a hatékonyság. Ezért újraértelmezném a hatékonyságot úgy, mint "az elért eredmény és a felhasznált erőforrások közötti arány". Így minden helyes: a tudás munka közben nem fogy el, de csökkenti a tesztelő egyetlen alapvetően nem megújuló erőforrásának költségeit — az idejét.
Megoldás
Tehát keressük a tesztelők globális problémáit, amelyek rontják a munkájuk hatékonyságát.
A legfontosabb erőforrás, amelyet a tesztelő munkája során felhasznál, az ideje (a többi erőforrás ehhez vagy úgy kapcsolódik), és ahhoz, hogy a hatékonyság korrekt számításáról beszélhessünk, az eredményt is az időhöz kell igazítani.
Ehhez vegyük szemügyre azt a rendszert, amelynek életerejét a tesztelő biztosítja a munkájával. Ilyen rendszer egy projekt, amelynek csapatába tartozik tesztelő. A projekt életciklusát durván a következő algoritmus szerint képzelhetjük el:
- Követelmények kezelése
- Műszaki követelmény képzése
- Fejlesztés
- Tesztelés
- Gyártásba adás
- Támogatás (lásd 1. pont)
Eközben az egész projekt rekurzívan felbontható alprojektekre (funkciókra), amelyek ugyanezen életciklussal rendelkeznek.
A projekt szempontjából a megvalósítás hatékonysága annál nagyobb, minél kevesebb időt fordítanak rá.
Így eljutunk a tesztelő maximálisan lehetséges hatékonyságának definíciójához a projekt szempontjából - ez egy olyan állapot, amikor a tesztelésre szánt idő nulla. A tesztelők összes problémája az, hogy ezt az időt elérni lehetetlen.
Mit lehet ezzel tenni?
A következtetések meglehetősen nyilvánvalóak és sokan régóta használják:
- A fejlesztésnek és a tesztelésnek gyakorlatilag egy időben kell kezdődnie és végződnie (ezzel általában a QA osztály foglalkozik). ). Az ideális eset az, amikor az összes fejlesztett funkció a készség pillanatában már automatikus teszteléssel van lefedve, amelyet regressziós (ha lehetséges, akkor elő-commit) tesztelés keretében szerveznek meg valamilyen módon. .
- Minél több funkció van a projektben (minél bonyolultabb), annál több időt kell fordítani annak ellenőrzésére, hogy az új funkció ne rongálja meg a régit. Ezért minél bonyolultabb a projekt, annál nagyobb automatizálásra van szükség a regressziós teszteléshez. .
- Minden alkalommal, amikor hibát hagyunk a produkcióban, és a felhasználó azt megtalálja, további időt kell fordítanunk a projekt életciklusának végigjárására a 1. ponttól (Követelmények kezelése, ebben az esetben a felhasználók esetén). Mivel a hiba kihagyásának okai általában ismeretlenek, csak egy optimalizálási út marad - minden felhasználók által felfedezett hibát be kell vonni a regressziós tesztelésbe, hogy biztosak lehessünk abban, hogy többé nem fog megjelenni.
Forrás: habr.com
