1. Korábbi projekt tapasztalatai
1.1. Korai hozzáférés biztosítása a tesztelendő komponensekhez nem tudott megtörténni
1.2. Mérési időablakok rossz kihasználtsága, biztosítás hiánya (előfeltételek nem teljesülése miatt)
1.3. Integrált tesztrendszer hozzáférés hiány
1.4. Tesztadat hiány, korlát
1.5. Késői, hiányos spec.
1.6. Tesztelést blokkoló funkcionális rendszerhibák
1.7. Teszt entry feltételek hiánya
1.8. Kozkázatkezelés
1.8.1. Rengeteg erőforrást elvitt, nem csak a performanciamérésről szólt (workaround-workaround)
1.8.2. Kell az erős sponzor támogatottság
2. Jelen állapot
2.1. Mi még újak vagyunk AFR-ben, kevés infónk
2.2. Bizonytalanságot érzünk még a tervek/specifikációk oldaláról
2.3. Az idő folyamatosan csökken, a véghatáridő törvényi megfelelés miatt nem tólható
2.3.1. kb. 130 munkanap a határidőig!
2.4. Hogyan jövünk a képbe?
2.4.1. Konkrét speckók nélkül készült a becslés
2.4.1.1. Funkcionális
2.4.1.2. Performencia
2.4.2. Valamennyire ismerjük a Bank és Oracle működését, sajátosságait
2.4.3. Van technikai ismeretünk a bank technikai csatornájának kezelésében (MQ)
2.4.4. Csináltunk performanciamérést a fenti környezetben és kontextusban, amely jelentős gyorsító tényező
3. Célok
3.1. Funkcionális tesztek teljesülése
3.2. Performancia tesztek teljesülése
3.3. Egyéb Banki projekteknek, szempontoknak való megfelelés
3.3.1. pl. Popeye projekttel átfedés/ütemezés
3.3.2. Üzemeltetési szempontok
3.3.3. Fejlesztési szempontok (kell-e támogatni a fejlesztést a funkcionális tesztekkel?)
3.3.3.1. Hangolás támogatás?
3.3.4. Határidő, költségkeret, stb.
3.4. Újrafelhasználható teszteknek kell lennie a bevezetést követően is? Hosszútávú ÜZEMLETETHETŐSÉG!
4. Stratégia
4.1. AFR egyediség
4.1.1. Komplexebb a TRAFO-nál
4.1.1.1. Nem az MQ interfész az egyedüli
4.1.1.2. Több rendszer, több szenzor
4.1.1.3. Itt funkcionális tesztelés is kell
4.1.1.4. Több szállító: kommunikáció, felelősség --> nagyobb kockázat, hosszabb folyamatok
4.1.2. Üzenetek nem bejáratottak, CR-ekre lehet számítani
4.1.3. Amire valószínűleg készülni kell
4.1.3.1. Teszt entry feltételek hiánya, időablak nem megfelelő kihasználása
4.1.3.2. Rengeteg rögtönzés
4.1.3.3. Csúszások, átütemezések, köztes célok kitalálása megvalósítása
4.2. Rövidtáv
4.2.1. Saját eszköz használat
4.2.1.1. Ismerjük a saját performanciális és funkcionális teszt eszközünket
4.2.1.2. Nem kell betanulnunk, azonnal rajtvonalhoz állhatunk
4.2.2. Gyors scope és ütemterv készítés
4.2.3. Teszt infrastruktúra kiépítés
4.2.4. KPI-k meghatározása
4.2.4.1. Külső, belső
4.2.5. Prioritások meghatározása a tesztek ütemezéséhez
4.2.5.1. (hagyma)héjszerű tervek: ha a technika csatornákon ok a performancia, akkor külsőbb komponensek (pl. NETBANKÁR) vizsgálata
4.3. Következő lépések
4.3.1. Előfeltételek
4.3.1.1. Specifikációk, tesztadatok, működő komponensek
4.3.2. Tesztek megírása, futtatása
4.3.3. Különböző tesztkörök futtatás
4.3.4. Teszt kiértékelések
4.4. Mennyi?
4.4.1. Részletesebb terv alapján pontosítható
4.4.2. Legalább 2 hónapos feladat csomagokat kell szemlélni.
4.4.3. Licenc kérdések
4.4.3.1. Kell/Nem kell döntés?
4.4.3.2. Opciók (bérlet/egyszeri/stb.)
4.4.4. Határidő ...