Végfelhasználói elfogadási teszt (UAT)

Az ingatlan.com termékfejlesztési ciklusában elértünk egy olyan pontot amikor remek alkalom nyílik egy bővebb csoport tesztelésbe történő bevonására.  Az alábbi lehető legtömörebb módon igyekszem ennek a célcsoportnak eladni és átadni a végfelhasználói elfogadási tesztet.

Mi a célja?

• Hogy olyan rendszer kerüljön szállításra amely a lehető legjobban szolgálja ki a megrendelői igényeket
• Biztosítsa, hogy a rendszer minőségi mutatói megfeleljenek a megrendelőnek
• Csökkentse a módosítási igények számát a bevezetés után, ezáltal csökkentse a termék összköltségét
• Funkcionális követelményeknek megfelelő termék a felhasználók megítélése alapján legyen elfogadva, azaz a végső jóváhagyást a rendszer használói tegyék meg

Előfeltételek

• A rendszer bevezetésre kész állapotban van
  • Fejlesztés és a migráció sikeresen befejeződött
  • A rendszer elérhető az éles üzemnek megfelelő környezetben az éles beállításokkal
  • Unit és integrációs tesztek sikeresek
  • Manuális és automatizált funkcionális tesztek sikeresek
  • Az éles rendszer felhasználóit reprezentáló felhasználói csoport kijelölésre került

Feladatok

• Üzleti igények felmérése
• Elfogadási kritériumok megfogalmazása
• Teszt terv elkészítése
• Teszt esetek elkészítése
• Tesztek futtatása
• Eredmények rögzítése, kiértékelése
• Üzleti célok elérésének ellenörzése

A sikeres kiválasztási folyamat 7 lépése

A sikeres kiválasztási folyamat 7 lépése:

1. Gondold át a feladatköröket, és alkoss egy jó profilt.
2. Adj kellő mennyiségi információt a HR-nek ahhoz, hogy hatékonyan előszűrjék a jelentkezőket.
3. Készíts egy tesztet, amellyel az alapvető készségeket és kompetenciákat mérheted fel.
4. Az értékelés módját előre gondold át.
5. Szakmai interjúkörre is érkezz konkrét kérdéssorral, hogy a fókusz minden esetben megmaradjon,
   akkor is, ha a jelölt elkalandozna.
6. Feltétlenül írj a személyes benyomásaidról is, döntő lehet a későbbiekben.
7. Bátran változtass és vizsgáld felül a korábbi pontokat, ha elégedetlen vagy az eredménnyel.

Felvételi procedúra tapasztalatok

2011 augusztusa óta 56 HR által előszűrt önéletrajz jutott el hozzám. Olyan embereké, akik közvetlenül, ajánlás útján, vagy valamely partnerünkön keresztül történt megkeresés hatására jelentkeztek az Arkonhoz senior szoftvertesztelő vagy tesztautomatizálási mérnők pozícióira.

A mai napig 3 ember kapott ajánlatot a cégtől, és ezt az ajánlatot mindannyian elfogadták. 15, 23 majd 18 jelentkező közül sikerült kiválasztani a legjobbakat, ami igencsak jó aránynak mondható. Év elején konzultáltam egy kollégával és elmondása szerint náluk előfordult már, hogy 50 emberből 1 teljesítette a felvételi procedúrát és “élte” túl a próbaidőt.

 

Az összegyűjtött információk alapján kimondható, hogy a jelentkezőink

• között kevés volt a hölgy – 14%,
• jellemzően szakirányú felsőfokú képzettséggel rendelkeznek,
• 7% rendelkezett 8 évnél több tapasztalattal, majdnem felüknek 3-5 év tapasztalata van,
• kevés a minősítést szerzett tesztelő, mindösszesen 21%,
• 72% 30 év alatti volt.

 

Továbbá nagyon nagy előrelépés, hogy

• mellőzzük a DISZK személyiség profil rendszert mivel azon kevés esetben amikor sor került az értékelésre, semmilyen mérhető összefüggés nem volt a jelentkező adottságai, szakmai felkészültsége és a csapatba való beilleszkedés sikeressége között,
• pontosan ismerjük a partnereink szállítási minőségét,
• a jelentkezők juttatási elvárásait, és hogy
• jellemzően mely cégektől érkező jelölteket érdemes kizárni a későbbiekben a felvételi folyamatból.
  (Sose gondoltam volna, hogy erre sor kerül, de statisztikailag indokolt.)

 

Lássuk mit mutatnak a grafikonok:

Sikeresen az teljesítette a szakmai teszteket, aki a példa program tesztelése során és az elméleti kérdéssor megválaszolása során legalább a világos zöld jelölésnek megfelelő értéket érte el.

Alap szintnek az ISTQB – CTFL vizsgája számít.

Külön köszönöm minden jelentkezőnek aki megtisztelt minket azzal, hogy részt vett a kiválasztási folyamatban. Sokan nem jutottak tovább a szakmai teszten és interjúkörön, ennek oka jellemzően az általunk megfogalmazott szakmai elvárások magas foka, illetve a kiírt profiltól való eltérés, nem pedig az alapvető készség vagy kompetencia hiánya volt.

További sikeres munkát kívánok mindenkinek!

Mi a Continuous Integration?

Ezen kérdés megválaszolására én is egy klasszikust hívok segítségül, ahogyan sokan mások is megtették már, ő Martin Fowler aki a lehető legkifejezőbben foglalta össze a CI lényegét. Bár a CI az Extreme Programming gyakorlatának szerves része, más agilis módszertan használatakor is javasolt az alkalmazása.

“A Continuous Integration – azaz a folyamatos integráció – egy szoftver fejlesztési módszer melyben a fejlesztőcsapat tagjai az általuk írt kódot legalább napi rendszerességgel integrálják a korábbi fejlesztések közé, ez napi többszöri integrálást jelent. Minden új kód integrálása során automatizált tesztek ellenőrzik, hogy a rendszerbe való illesztés során okozott-e valamilyen hibát az új kódrészlet és ennek eredményeként a lehető leghamarabb visszajelzést ad az integráció eredményéről” [1][2].

 

[1] 2006 – Martin Fowler, Continuous Integration,
[2] 2000 – Martin Fowler, Continuous Integration (original version).

Cleanroom módszertan

Napjainkban nagyon divatos és nagyon eredményesen alkalmazható szoftverfejlesztési módszertanokat használ a szoftveripar és teszi ezt minden korábbinál szélesebb körben. Ezek az agilis módszertanok. Arról viszont igencsak kevesen tudnak, hogy ezeket megelőzte a Harlan D. Mills által felállított Cleanroom szoftver fejlesztési módszertan, melynek célja az igazolhatóan magas megbízhatóságú szoftverek szállítása volt.

Hogyan érték el ezt már a ’80-as években?
Egy pofon egyszerű “trükkel”. A hangsúlyt a hibák előrejelzésére fektették és nem az utólagos javításukra. Azaz a lehető legkorábbi visszajelzést adták a szoftver ellenőrzése során. Erre törekednek az agilis módszertanok is.

Azon túl, hogy a korai visszajelzések fontosak voltak ebben a rendszerben, magának a szoftver tervezésének és implementálásának folyamata a felülről lefelé építkezett. Először a rendszer vázát (magját) fejlesztették le és csak ezután a további komponenseket. Azaz a megvalósításhoz vezető úton a magasabb szintű terveket megvalósító absztrakt megoldások fejlesztése volt az elsődleges és ezután következtek az alacsonyabb szintű megoldások. Ezeket pedig nagy gyakorisággal integrálták a rendszerbe, hogy az esetleges hibák és azok okai a lehető legegyszerűbben és legbiztosabban megoldásra kerülhessenek. Ezt nevezzük napjainkban Continuous Integration-nek.

Miért is volt ez olyan fontos?
Azért mert a szoftver fejlesztési projektek egyik legnehezebb részét az teszi ki, hogy a már meglévő fejlesztéseket és az újonnan elkészülteket integráljuk. A szoftvertesztelők különösképpen a bőrükön szokták érezni ennek súlyát, hiszen ilyen esetben gyakorta előfordul úgynevezett “side-effect”, azaz olyan hiba melyet az újonnan integrált kód vált ki a rendszer olyan részein melyen közvetlenül nem történt kód módosítás. Ilyenkor halljuk a fejlesztőktől, hogy “ez elméletileg nem lehetséges”. Mégis sok sötét foltot találhatunk az elméleteken, ilyen az élet.

Fontosnak tartom kihangsúlyozni, hogy egy új rendszer agilis módszertannal való fejlesztése esetén célszerű egy kicsit visszakacsingatni a Cleanroom-ra, mivel ez fejezi ki legjobban azt a gondolatiságot amire a projekt korai fázisaiban szüksége lehet a szereplőknek. Előfordulhat, hogy az első pár demó áldozatul esik ennek a szemléletnek, de a későbbi fejlesztési ütem mindenkit kárpótolni fog!

Az Arkonnál kimondva, kimondatlanul is megjelenik egy kicsit a Cleanroom a SCRUM köntös mögött, aminek szoftvertesztelőként kimondottan örülök, annak ellenére is, hogy nehéz megfelelni neki.