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 Szakmai ismeret Adatbázis ismeret Biztonsági tudás Fejlesztői képesség Kreativitá s Monotonitá s tűrése 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 2 4 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 i5 4460 3.2GHz Windows operációs rendszerekre megváltott license ek: 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 vannak e elégedve a feladataikkal, akad e problémájuk és, hogy szükségük van e training re. 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
Testing Methods Meeting a felhasználókkal Felhasználók számára szükséges e 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 Manager nek nyújt támogatást. Nagyobb cross functional (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, policy ben é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 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ú Black box White box
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/unit test 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. csapattag csapatvezető: 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 csapattag csapattag: jobb esetben (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él csapatvezető: a vezetőnek időnként érdeklődnie kell, hogy az ügyfél meg van e elégedve az addig elkészült munkával, esetleg merültek e fel benne kételyek, új kívánalmak, melyek még orvosolhatóak. ügyfél csapattag: 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.