Az ISTQB a világ egyik, ha nem a legnagyobb szoftver minőséggel foglalkozó szervezete. Adataik szerint világszerte közel 1 millió certifikációt szereztek már meg náluk a különböző informatikai szakemberek.
A szervezet 1998-ban alakult és a CTFL első verzióját még 2005-ben írták, amikor a szoftverfejlesztéssel foglalkozó cégek nagy része még a Waterfall modellben dolgozott.
Az utóbbi években ez azonban megváltozott.
Mára a cégek 79%-a állítja azt magáról, hogy valamilyen arányban, de agilisan működnek, az ISTQB felmérése szerint.
Az elmúlt években a megkérdezett cégek olyan szoftvertesztelőket kerestek, akik
- kritikus szemléletűek,
- analitikusan gondolkodnak,
- együttműködőek,
- önállóan is jól dolgoznak,
- fontos számukra a minőségi munka,
- nyitottak a csapatmunkára,
- képzett szakemberek.
Mindezek vezettek el addig, hogy a szervezet (ISTQB) elgondolkodjon azon, hogy az alapszintű szoftvertesztelői vizsgáját, a CTFL-t újraírja és a mai igényekhez igazítsa.
Na, de mi változott?
Chapter 1.
A Fundamentals of Testing című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
Az új syllabusban további részletezésre kerülnek, valamint újabb célokat is bemutatnak a tesztelés szükségessége mellett.
A tesztelési szerepkört teljesen újragondolták ebben a verzióban. Ahelyett, hogy a szoftvertesztelést “csak” egy teljes munkaidős pozícióként értelmezhetjük, átveszi azokat az egyéb szerepköröket is, amiben tesztelői aktivitást végezhetnek, merthogy egy fejlesztői csapaton belül potenciálisan bárki végezhet tesztelői feladatot.
A teszteléshez szükséges készségeket/képességeket tekintve egy sokkal holisztikusabb hozzáállást mutatnak itt be, nagyobb hangsúlyt fektetve az emberi készségekre a technikai tudással szemben.
Úgy gondolják, hogy a minőség nem egy ember, hanem egy csapat által kitűzött cél, ezért a teljes csapat megközelítés (Whole Team Approach) is bekerült az új anyagba.
Nem csak a szoftver minősége, hanem a folyamatok minősége is fontos, amibe beletartozik a dokumentáció, a határidők, a kommunikáció és az együttműködés minősége is.
Chapter 2.
A Testing Throughout the Software Development Lifecycle című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
A tesztelés különböző módon hat a más-más szoftverfejlesztési modellekben. Ezeket a különbségeket fejtik ki ebben a fejezetben részletesen.
A “Test First Approach” már jól ismert az Agilis és a DevOps megközelítések lévén. Ennek megfelelően a DevOps-ot is bevezették ebben a verzióban, nem az eszközök, inkább az együttműködési és kommunikációs szempontok miatt.
Az uralkodó szemlélet az, hogy a cél a felismerés helyett a megelőzés.
A “Shift-left approach” is megjelenik új tartalomként. Ez is egy együttműködést előtérbe helyező szemlélet, szintén megelőzési céllal.
A Retrospektív visszatekintés is bekerült az anyagba, az értékelő megbeszélések fontossága a fejlődés érdekében.
Chapter 3.
A Static Testing című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
Ebbe a fejezetbe beemeltek egy hatékony visszajelzési mechanizmust, ami minél kisebb, rövidebb, gyakoribb visszajelzéseket jelent, ezek elnyújtása helyett. A megelőzés fontosságára itt is felhívják a figyelmet. Hiszen minél előbb megtalálsz egy problémát, annál olcsóbb lesz kezelni azt.
Chapter 4.
A Test Analysis and Design című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
A “Decision testing” helyett beemelték a “Branch testing”-et.
Emellett a “Checklist-based testing” is bemutatásra kerül benne.
Az együttműködés alapú user story-k írásról is beszélünk ebben a fejezetben. Mitől lesz egy követelmény annyira jó, hogy elfogadásra kerüljön?
Az ATDD bemutatása (Acceptance Test Drive Development). Az ATDD egy olyan megközelítés, amely során a teszteseteket az elfogadási kritériumokból eredeztetik és már a fejlesztés előtt megírásra kerülnek elősegítve, hogy az implementáció magasabb minőségű legyen.
Chapter 5.
A Managing the Test Activities című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
A “Release” tervezés ebbe a fejezetbe került bele; csakúgy, mint az iteráció tervezés is.
Ahogy a különböző becslési technikák is. A tesztpiramis bemutatása nem csak agilis szemszögből, hanem a különböző tesztelési szinteknek megfelelően is pl. tesztautomatizálási oldalról. A szoftvertesztelési kvadránsok részletes bemutatásra kerültek, ami az egyik legholisztikusabb és tisztább megközelítés a fejlesztési projekteket tekintve.
Chapter 6.
A Test Tools című fejezetben a következő témákat érintően kerültek be változások a syllabusba:
A DevOps eszközök is bemutatásra kerülnek az utolsó fejezetben. Továbbá azok az eszközök is, amik az együttműködést segítik.
Hogyan tovább?
Az ISTQB ajánlása szerint a CTFL 4.0-ra ugyanúgy, mint a korábbi verzióra is 3 nap alatt fel lehet készülni.
A CTFL 4.0 NEM a korábbi CTFL és a CTFL-AT összeolvadása, hanem a korábbi, 3.1-es CTFL syllabus újraírása kiegészítve az agilis tesztelők számára is fontos irányelvekkel.
Jelenleg vagy a korábbi 3.1-es CTFL+CTFL-AT együttesen, vagy csak a CTFL 4.0 szükséges és elégséges az advanced szintű agilis vizsgákhoz, azok előfeltételeként.
A korábban megszerzett ISTQB certifikációkat NEM kell megújítani, de a tudás frissítése miatt ajánlott elsajátítani a CTFL 4.0 anyagát.
Határidők:
-
- május 9-ig még lehet vizsgázni a CTFL 3.1-ből angolul.
-
- november 9-ig még lehet vizsgázni a CTFL 3.1-ből a saját anyanyelven, esetünkben magyarul.
A TesterLab következő CTFL felkészítő képzésére itt tudtok jelentkezni: Jelentkezem!
