Rendelünk a tesztelés típusát - agilis tesztelési kvadránsok, agilerussia
Miközben elkészíti a következő hozzászólást a sorozatról az automatizálásról. Meg akartam osztani érdekes, véleményem szerint az Agile Testing című könyv anyagát: gyakorlati útmutatót a tesztelőknek és agilis csapatoknak.
Szóval sokféle tesztelés létezik: terhelés, ad hoc, józan, fekete doboz, fehér doboz és így tovább. És sokáig nem találkoztam olyan jó és érthető módon, amely véleményem szerint egy olyan rendszert tartalmazna, amely minden ilyen faj normális csoportosítását tartalmazza, valamint magyarázatot ad arra, mikor és miért kell őket felhasználni. És csak a múltkor olvastam az agilis tesztelési kvadránsokról (ATQ), amiről azt akarom mondani.
Valójában a rendszer így néz ki:
Mint látható, a klasszikus diagram 2 * 2. Tehát a tengelyek egyikének megfelelően a tesztek üzletileg orientált és technikailag orientált, a másik tengelyre oszlanak - a csapat támogatására és a "termékkritikára". Csak azt szeretném tudni, hogy a számozás nem mond semmit arról, mikor kell elvégezni ezeket a teszteket.
Menjünk végig az egyes ágazatokon.
A Q1 ág olyan jól ismert gyakorlat, mint a TDD. Ez egyszerű: az első tesztek, majd a kód. Ezek a tesztek elsősorban a fejlesztő csapat felelőssége. Mindezeket a teszteket CI-n keresztül kell futtatni a kód állandó minőségellenőrzéséhez. Mindez sok forrásban készült, azok számára, akik még nem gyakoroltak TDD-t, ezt a linket szeretném tájékoztatni.
A Q2 szektor több magas szintű tesztet tartalmaz, amelyek már foglalkoznak az üzletekkel. Ezeknek a teszteknek a sikeres átadása kötelező minden funkció befejezéséről. Mert azt mondhatjuk, hogy ez vagy az a funkció akkor működik, ha megoldja az üzleti felhasználók által felvetett feladatokat. Ezen a szinten az alkalmazás külső héja alapvetően tesztelt: felület, API, webes szolgáltatások stb. Másrészről ez a szektor magában foglalja a prototípusok, mocaps, minták és hasonlók tesztelését. Gyakran az "átvételi teszt" fogalmát használják a bevitt tesztekhez. bár ez nem teljesen igaz, hiszen a Q3 és Q4 szektorokból származó tesztek is érdemesek az átvételi teszteléshez.
A Q3 szektorból származó tesztek magukban foglalják a domain terület szakértői kötelező részvételét, használhatósági szakértőket, felhasználókat és így tovább. Gyakran előfordul, hogy a megvalósított funkciók nem igazán oldják meg az ügyfelek problémáit, vagy valami félreértette a fejlesztőcsapat. Ismét felmerülhet a domain objektumokkal való együttműködés új aspektusa, vagy világossá vált, hogy a tervezett felület nem volt kényelmes a felhasználók számára. Ez az a terület, ahol a "bírálatra" szánt tesztek jönnek létre. Azonnal foglaljon helyet, hogy a "kritika" szó itt pozitív konnotációval bír. Magától értetődik, hogy ez a teszt csak kézi, mivel egyetlen szkript sem észleli a jelzett problémákat, bár természetesen segédeszközöket is használhatunk, például az adatok betöltésére.
És végül a Q4 utolsó szektorában. amely olyan tesztekről szól, amelyek nem tesztelik az üzleti problémák megoldását, de arról beszélünk, hogy az alkalmazásunk milyen jól íródott, olyan kifejezések használatával, mint a biztonság, a teljesítmény, a stabilitás, a méretezhetőség stb. Ezek a tesztek segítenek ellenőrizni a nem funkcionális követelményeknek való megfelelést, ha vannak ilyenek, és megérteni, hogy az alkalmazást korai szakaszban tervezték. Ezek a tesztek nagyban hozzájárulnak a jövőbeli problémák elkerüléséhez. Nyilvánvaló, hogy az ilyen ellenőrzések elvégzéséhez speciális eszközöket kell használnunk, amelyek jelenleg igen nagyok.
Így az Agile Testing Quadranzusok egyfajta ellenőrző lista, amely azt mutatja, hogy a megfelelő irányba haladunk, hogy a folyamatok megfelelően automatizáltak és kézi vizsgálatokat végezhetnek. És ami a legfontosabb, az Agile Testing Quadrantok megmutatják, mennyire sikeres termékünk üzleti szempontból.