Test Strategy Agilis módszertant alkalmazunk a projektjeink tesztelése során, ahol rövid sprintekben dolgozunk, melyekben csak néhány követelményre fokuszálunk. Előzőekből adódik, hogy ezen feladatok nem igényelnek bőséges dokumentációt. Nincs is rá szükségünk a rövid sprintek okozta idő korlátok miatt, ellenben megkövetelünk egy magas szintű agilis teszt stratégiát, ami irány mutatásként szolgál az agilis csapatunknak. Ezen dokumentumokban egy listát vezetünk a legjobb, leghasznosabb alkalmazásokról, és néhány formai struktúrát. Fontos azonban, hogy az agilitás nem azonos a strukturálatlan stratégiával. A „küldetésünk”, hogy az általunk készített/tesztelt rendszerek konvergáljanak a felhasználói követelményekhez. Ezen feladatokat elvégző csapatunk pedig a következő: Teszter
Szalkai Gábor Tóth Róbert Kiszner László
Tesztelői tapasztalat (év)
Elemző képesség (05)
Szakmai ismeret (05)
Adatbázis ismeret (05)
Biztonsági tudás (05)
Fejlesztői képesség (05)
Kreativitá s (05)
Monotonitá s tűrése (05)
0
4
2
3
3
3
4
4
0
4
4
3
3
4
4
2
0
4
3
3
3
4
4
2
Scope and Objectives: Ezen dokumentum arra szolgál, hogy a tesztelők láthassák, hogy milyen irányelvet követünk. A cég vezetői szem ügyre vehetik, hogy milyen tesztelői csapattal rendelkeznek, mivel a teszt manager esetleges training és fejlődések után frissítheti az egyes tesztelők képességeit. Ezekből kifolyólag pedig meg tudják beszélni a managerrel az esetleges csapatbeli változásokat, kiadásokat. 2 hetes sprintekre vannak ütemezve a feladatok, ezen idő alatt szükséges a tesztelőknek befejezniük az ezen időre eltervezett ütem tervet. Ezek bizonyos szinteket jelentenek, amiket tesztelünk. Különböző projektnél különböző lehet, hiszen valahol fontosabb a biztonság, mint a gyorsaság és a többi. Elfogadási kritériumnak(Acceptance criteria) 3 szempontnak kell megfelelnie: ● Azt írja le, hogy mit akarunk és nem a megoldást. ● Független az implementációtól. ● Relatíve magas szintűnek kell lennie.
Szoftver kiadása előtt az alábbi követelményeket kell teljesíteni(Exit criteria): ● Minden teszt esetnek le kell tudnia futnia. ● Nem szabad szoftvert kiadni magas prioritású hibával vagy 5%nál(tesztesetek számához viszonyítva) több közepes prioritású hibákkal. ● Rendszer sebessége nem csökkenhet jelentősen új feature miatt. ● Meggyőződni, hogy az új tesztek követik a tesztelési szabványt, amit a projekt esetében használunk. ● Kódot a kiadás előtti héttől kezdve már nem lehet módosítani. Ezzel is elkerülve az új hibák bevezetését a kód bázisba. ● User acceptance teszt lefuttatása a klienssel és meggyőződni, hogy elégedettek a módositásokkal. Test Environment: Szükséges megemlítenünk a környezetet ahol tesztelünk és megadni a biztonsági szükségleteinket. Szükséges adat „backup” és „restore”, mivel kódbeli probléma is okozhat adat vesztést, ami nem megengedett a cégünk szemléletében. Tehát lényeges ezen biztonsági mentések tárolása legalább 24 héten keresztül, és az ezekhez szükséges bónusz tárhely biztosítása. Fontosabb hardver követelményeink pedig a következőek: ● ● ● ● ●
10 db gép Windows, míg 6 db gép Linux operációs rendszert használ 8 Gb RAM 500 Gb HDD 120 Gb SSD Inter Core i54460 3.2GHz
Windows operációs rendszerekre megváltott licenseek: ● Office program csomag Roles and responsibilities: ● Project Manager o Role: Ő feladata, hogy a projektek időben elkészüljenek, a budget (rendelkezésre álló keret/pénz) figyelése/szabályozása és a megfelelő minőség biztosítása. Kommunikálnia kell a csapatával, hogy kellően motiváltak és sikeresek legyenek, ebbe beletartozik az is, hogy megtudakolja meg vannake elégedve a feladataikkal, akade problémájuk és, hogy szükségük vane trainingre. o Responsibilities: ▪ Irányítani/vezetni a projekt csapatot ▪ Új tagok toborzása ▪ Projekt tervezése és monitorozása/felügyelése ▪ Projekt terv készítése ▪ Projekttől való eltérés, azaz hiba, csúszás esetén korrigálás megtervezése ha szükséges
▪ Meeting a felhasználókkal ▪ Felhasználók számára szükségese training ▪ Eldönti, hogy a projekt minősége elegendőe ● Project Team Members o Role: A staff, akik aktívan dolgoznak a projekten, annak életciklusa folytán. (Néha lehet speciális szerepkörbe tartozó például projekt adminisztrátor is) o Responsibilities: ▪ Felhasználókkal meetingek, hogy mire is érdemes oda figyelni ▪ Dokumentáció és elemzés az aktuális és jövőbeli rendszerről ▪ Felhasználók trainingjeinek tartása ● Project Administrator o Role: projekt terv készítésben fő szerep és szükség esetén projekt weboldalának frissítése. Project Managernek nyújt támogatást. Nagyobb „crossfunctional” (több területet átfogó) rendszereknél szükséges ezen szerepkör. o Responsibilites: ▪ Project Managerrel történő munka, fejlesztési követelmények és prioritások definiálása ▪ Adatmigráció ▪ Konfiguráció reportálás ▪ Biztonsági és hozzáférési engedélyek felállítása ▪ Technikai stratégiában, policyben és procedúrákban segédkezés ▪ Minőségi szinvonalú technikai dokumentáció ▪ Reportálás/jelentés a menedzsmentnek és a felhasználóknak Testing Methods Program futtatása nélküli tesztelési módszerek (statikus): statikus analízis review Program futtatását felhasználó módszerek (dinamikus): Tapasztalat alapú Blackbox Whitebox
Testing Tools Managment tools: testrail Static testing tools: ● Static analysis: platform függő. ● Code review: gerrit ● Modeling tool: UML Test specification tools: ● Test design tool: Office ● Test data preparation tool: manuális(Office) vagy generált Test execution and logging tools: platform függő ● ● ● ● ●
Test execution tool Test harness/unittest framework Test comparators Coverage measurment tool Security tool
Performance and monitoring tools: platform függő ● Dynamic analysis tool ● Performance testing, Load testing and stress‐testing tool ● Monitoring tools Change Managment A cég a dokumentációkhoz és a forráskód kezeléshez használ verziókövető rendszert. A tesztelési dokumentációkban meg kell jelölni, hogy a szoftverfejlesztési verziókövető rendszer melyik verziójában volt a hiba megtalálható. Communication Több fajtája is van, amit fontos lehet megemlíteni. ● csapattagcsapatvezető: fontos, hogy a vezető megtalálja a megfelelő hangnemet a csapatával, és figyeljen arra, hogy az információ közlés ne legyen bántó/lenéző, az adott csapattag számára, hiszen ez ronthatja a morál, és ami még fontosabb az egyén hozzáállását is lerombolhatja ● csapattagcsapattag: jobbesetben (amire azt is mondhatnánk, hogy általában) ezen kommunikáció megoldott, tehát a tagok könnyebben kommunikálnak egymással, a projekt szempontjából akkor van ennek fontos szerepe, ha segítséget kell kérni/nyújtani az egyik tagtól/tagnak. Ennek lehet oka közös feladat rész, más által készített kód hibájának javítása és a többi. Bár meg kell jegyezni, hogy szükséges a tagokban magas csapat szellem és némi tolerancia.
● ügyfélcsapatvezető: a vezetőnek időnként érdeklődnie kell, hogy az ügyfél meg vane elégedve az addig elkészült munkával, esetleg merülteke fel benne kételyek, új kívánalmak, melyek még orvosolhatóak. ● ügyfélcsapattag: viszonylag ritka kommunikációs szint, olyan esetekben történhet meg, ha adott funkciót mutat be a fejlesztő, de itt inkább csak tanítási jelleg van. Training A teszt tervek elkészítésekor meghatározzuk a tesztelés során használandó technológiákat, eszközöket. Az esetleges hiányosságok a tesztelési fázis elején tréningek segítségével pótolhatóak.
