Bevezetés
Jó napot, habrovszkiak. Éppen most oldottam meg egy tesztfeladatot egy minőségbiztosítási vezető állás betöltésére egy fintech cégnél. Az első feladat, egy tesztterv elkészítése egy teljes ellenőrző listával és az elektromos vízforraló tesztelésének teszteseteinek példáival, triviálisan megoldható:
Nehéz jobb teszttervet elképzelni teljes ellenőrzőlistával.
A második rész azonban egy kérdésnek bizonyult: „Van-e olyan probléma, amely minden tesztelőnél közös, ami megakadályozza, hogy hatékonyabban dolgozzanak?”
Elsőként az jutott eszembe, hogy felsoroljam az összes többé-kevésbé észrevehető problémát, amivel a tesztelés során találkoztam, kigyomláljuk az apróságokat, a többit pedig összefoglaljam. De hamar rájöttem, hogy az induktív módszer olyan kérdésre ad választ, amely nem „mindenre”, hanem legjobb esetben is csak a tesztelők „többségére” vonatkozik. Ezért úgy döntöttem, hogy a másik oldalról, deduktívan közelítem meg a dolgot, és ez történt.
meghatározzák
Az első dolog, amit általában megteszek egy új probléma megoldása során, hogy megpróbálom megérteni, miről is van szó, és ehhez meg kell értenem az ezt feltevő szavak jelentését. A megértendő kulcsszavak a következők:
- probléma
- vizsgáló
- tesztelői munka
- tesztelő hatékonysága
Forduljunk a Wikipédiához és a józan észhez:
(ógörög πρόβλημα) tág értelemben - összetett elméleti vagy gyakorlati kérdés, amely tanulmányozást és megoldást igényel; a tudományban - ellentmondásos helyzet, amely ellentétes álláspontok formájában jelenik meg bármely jelenség, tárgy, folyamat magyarázatában, és ennek megoldásához megfelelő elméletre van szükség; az életben a probléma az emberek számára érthető formában fogalmazódik meg: „tudom mit, nem tudom hogyan”, azaz tudjuk, mit kell megszerezni, de nem tudni, hogyan kell csinálni. . Későről jön. lat. probléma, görögből. πρόβλημα „előredobva, előre elhelyezve”; προβάλλω szóból „dobj előre, tedd magad elé; feddés".
Ennek nincs sok értelme, valójában „probléma” = „bármi, amivel foglalkozni kell”.
- egy szakember (nem fogunk típusokra osztani, hiszen minden tesztelő érdekel minket), aki részt vesz egy alkatrész vagy rendszer tesztelésében, melynek eredménye:
— a teszteléssel kapcsolatos tevékenységek összessége.
(lat. Effectivus) - az elért eredmény és a felhasznált erőforrások kapcsolata (: 2015).
- cselekvések (eredmények) vagy események láncolatának (sorozatának) következménye, minőségileg vagy mennyiségileg kifejezve. A lehetséges következmények közé tartozik az előny, a hátrány, a nyereség, a veszteség, az érték és a győzelem.
Mint a „problémának”, ennek is kevés az értelme: valami, ami a munka eredményeként jött ki.
- egy személy vagy emberek bármely tevékenységének mennyiségileg mérhető lehetősége; feltételek, amelyek lehetővé teszik a kívánt eredmény elérését bizonyos transzformációk segítségével. A tesztelő személy, és a létfontosságú erőforrások elméletével összhangban minden személy négy gazdasági eszköz tulajdonosa:
a készpénz (jövedelem) megújuló erőforrás;
az energia (életerő) részben megújuló erőforrás;
az idő állandó és alapvetően nem megújuló erőforrás;
a tudás (információ) megújuló erőforrás, a humán tőke része, amely növekedhet és megsemmisülhet.
Szeretném megjegyezni, hogy a hatékonyság definíciója esetünkben nem teljesen helyes, hiszen minél több tudást használunk fel, annál alacsonyabb a hatékonyság. Ezért a hatékonyságot újrafogalmaznám: „az elért eredmények és a ráfordított erőforrások aránya”. Akkor minden helyes: a tudás nem megy kárba a munka során, de csökkenti a tesztelő egyetlen alapvetően nem megújuló erőforrásának - idejének - költségeit.
döntés
Tehát a tesztelők globális problémáit keressük, amelyek rontják munkájuk hatékonyságát.
A tesztelő munkájára fordított legjelentősebb erőforrás az ő ideje (a többi így vagy úgy leszűkíthető), és ahhoz, hogy a hatékonyság helyes számításáról beszélhessünk, az eredményt is időre kell redukálni. .
Ehhez vegyünk egy olyan rendszert, amelynek életképességét a tesztelő munkájával biztosítja. Ilyen rendszer egy olyan projekt, amelynek csapatában van egy tesztelő is. A projekt életciklusa nagyjából a következő algoritmussal ábrázolható:
- Követelményekkel való munka
- Műszaki specifikációk kialakítása
- tervezés
- tesztelés
- Gyártásba bocsátás
- Támogatás (ugrás az 1. tételhez)
Ebben az esetben a teljes projekt rekurzív módon felosztható alprojektekre (tulajdonságokra), azonos életciklussal.
A projekt szempontjából minél kevesebb időt fordítanak rá, annál hatékonyabb a megvalósítás.
Így elérkeztünk a tesztelő maximális lehetséges hatékonyságának meghatározásához a projekt szempontjából - ez az az állapota a projektnek, amikor a tesztelési idő nulla. Minden tesztelőnél gyakori probléma, hogy ezt az időt nem tudják elérni.
Hogyan kezeljük?
A következtetések meglehetősen nyilvánvalóak, és sokan használják őket régóta:
- A fejlesztésnek és a tesztelésnek szinte egyszerre kell kezdődnie és befejeződnie (ezt általában az osztály végzi el ). Az ideális megoldás az, ha az összes fejlesztés alatt álló funkcionalitást készenléti időpontra már lefedik az automatikus tesztek, regressziós (és ha lehetséges, előzetes véglegesítési) tesztelésbe szervezve valamilyen módon. .
- Minél több funkcióval rendelkezik egy projekt (minél összetettebb), annál több időt kell fordítani annak ellenőrzésére, hogy az új funkció nem töri-e meg a régit. Ezért minél összetettebb a projekt, annál több automatizálásra van szükség .
- Minden alkalommal, amikor kihagyunk egy hibát a termelésben, és egy felhasználó megtalálja, további időt kell töltenünk a projekt életciklusának végighaladásával az 1. ponttól kezdve (Követelmények kezelése, jelen esetben felhasználók). Mivel a hiba hiányának okai általában ismeretlenek, csak egyetlen optimalizálási útvonalunk maradt: minden felhasználó által talált hibát be kell vonni a regressziós tesztbe, hogy megbizonyosodjunk arról, hogy nem jelenik meg újra.
Forrás: will.com