Agile TestingAgile TestingA teszteléssel kapcsolatos stratégia, tudás-, és erőforráshiány miatt számtalan fejlesztői óra telik hibajavítással, és mindez a profit kárára. Ezt az időt és pénzt új üzleti érték szállítására lehetne fordítani. |
Bármikor technikai vagy szakmai támogatásra lesz szükséged, mi rendelkezésedre állunk.
Képzünk téged a szakmában
Képezzük a csapatodat
Óradíjban skálázható módon elvégezzük nálad a feladatot
A hibajavítással töltött idő 70%-át megspórolhatod.
Vevői elégedettség növelése
A folyamatosan növekvő minőség és gyorsaság kultúrájának kialakítása
Növekvő profitráta
Szakértőid büszkék lesznek a munkájukra
Mi ez?
Célja a felhasználó és minden haszonélvező (stakeholder) elégedettségének vizsgálata. Ez a szint elsősorban megerősítő szemléletű, tehát az a jó teszt, amely sikeres működést produkál. A megerősítő cél például olyan hibák kimutatása, amelyek csak a végleges működtető környezetben vizsgálhatók.
Mit eredményez?
Feladata annak megállapítása, hogy a rendszer éles üzembe állítható-e.
Tipikusan hogyan mérhető?
Felhasználóktől érkező hibajegyek száma csökken.
Automata tesztek mennyire fedik a funkciókat, gernicfolyamatokat.
Mikor mondható sikeresnek?
Az egy üzleti döntés, hogy az UAT-ról altuálisan visszaérkező hibák mekkora hányadát szólítjuk meg ténylegesen.
Go és no-go döntéshozatali helyzeteket készít elő.
Abszolút sikeres, ha a megfelelő tesztelés mellet nem érkezik vissza hibajegy, és az összes teszteset lefut hibátlanul.
Megvalósítás eszközei
Végfelhasználói viselkedést modellező automata tesztek, tesztrobotok.
Milyen vevőoldali felkészültség kell hozzá?
Azonosított gerincfolyamatok.
User story-kból levezetett tesztforgatókönyvek, tesztesetek.
Economic view
Egy adott UAT teszt alkalmankénti ára mindig ugyanannyi, ha minden egyéb feltételt változatlannak tekintünk, és a teszt tartalma se változik.
Van egy kritikus UAT tesztmennyiség, ami fölött már jobban megéri a magasabb bekerülési küszöbű automata teszt, amit, ha változik a teszt forgatókönyv (és/vagy user story), akkor frissíteni kell.
Automata tesztelés esetén minden egyes teszt futtatásásval a teszt fajlagos költsége egyre kevesebb lesz.
Előfeltétel
Tesztforgatókönyv és/vagy User story
Visszacsatolás kezelése
Ügyfélszolgálat és fejlesztés operatív összekötése, összehangolása.
Mi ez?
A szoftvernek egy kisebb komponensének, kód szintű elemének a tesztelése. Ilyen például a létrehozott metódusok, függvények tesztelése.
Mit eredményez?
A tesztelés megvizsgálja, hogy a unit az elvárásnak megfelelően működik-e. Egy metódusnál a kapott érték megegyezik-e az elvárttal.
Tipikusan hogyan mérhető?
Manuális és/vagy automata tesztekkel, ahol nem az elvárt értékeket kapjuk.
Mikor mondható sikeresnek?
A szoftver kisebb komponensei, elemei az elvárásnak megfelelően működnek.
Megvalósítás eszközei
Például JUnit, PHPUnit
Economic view
A legalacsonyabb szintje a kód tesztelési tesztelési hierarchiának.
A Unit teszten keresztül tudjuk biztosítani, hogy a különböző újabb fejlesztési és tesztelési elemek összepakolásánál kibukjanak egyrészt a regressziós hibák, másrészt fejelsztés közben elkövetett kisebb a kódolási problémák.
A Unit teszt alkalmazásával bug helyett mistake lesz, ami olcsóbb: bug a piacról érkezik vissza, mistake-et a fejlesztés során még megfogjuk, mielőtt élesbe megy.
Így nem ég a profit a bugfixing miatt, nem lesz custmer dissatisfaction, a brand nem sérül.
Milyen vevőoldali felkészültség kell hozzá?
A fejlesztőknek kell unit teszt írással kapcsolatban kompetenciát felépíteniük.
Előfeltétel
Gerincfolyamatok azonosítása (Üzleti elemző csinálja)
Technológiai előkészítés, pl. Jenkins, monitorozásra
Fejlesztők felkészültsége
Visszacsatolás kezelése
Iteráció (Sprit) végén a mérések és a csapat ajánlása alapján döntés arról, hogy a következő iterációban mennyi erőforrást költsünk hibajavításra.
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
A modulok összeillesztése során keletkező hibák keresése. Két szoftver vagy ugyanazon szoftver összetevői közötti kommunikáció tesztelése, ellenőrzése. Az interfész tesztelés az egyik legfontosabb tesztelés a szoftver alkotóelemei közötti zökkenőmentes és biztonságos kommunikáció biztosítása érdekében.
Mit eredményez?
Szoftverek és/vagy szoftver összetevők közötti kommunikáció az elvártnak megfelelő lesz.
Tipikusan hogyan mérhető?
Manuális és/vagy automatizált teszteléssel
Mikor mondható sikeresnek?
Az elvártnak megfelelő szoftverek és/vagy szoftver összetevők közötti kommunikáció.
Megvalósítás eszközei
Pédául manuálisan, JMeter, Selenium, Silk Performer, Egyéb autómatizált tool, függ attól, hogy Webes vagy Desktop alkalmazásokat kell tesztelni
Economic view
Integrációs teszt: Stabilan működő szolgáltatás jön létre, ami biztosítja, hogy az új megoldások jól működnek együtt a már meglévő elemekkel, és ez fenntartja a vevői elégedetséget.
Az integrációs tesztek teszik biztonságossá a verziók élesítésést, ami pedig a visszatérő vevők és felhasználók számát és frekvenciáját növeli. Ha a retention-t erősíti, az rendben van.
Interface teszt: abban segít, hogy a különböző rendszerek jól csatlakozzank egymáshoz egy komplex szolgáltatást nyújtó termékben. A rendszerek közötti stabil működés mentesít a felhasználóknak okozott, akár kártérítési felelősséggel is együtt járó problémáktól.
Data leaking és adatvesztés nem lép fel.
Milyen vevőoldali felkészültség kell hozzá?
Interace-ek ismerete. Integrációs eljárás, szabályok, és elvárások megalkotása, felügyelete.
Előfeltétel
Interfészek átfogó üzleti ÉS technológiai dokumentációja.
Rendszerek közötti Business logic workflow.
Visszacsatolás kezelése
Interface és integrációs felelősök és a csapat szoros összekapcsolása a product ownerrel.
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
Már a komplett rendszert vizsgálja. Jellemzően Black-Box teszt. Elsődleges célja a vevő bizalmi szintjének növelése abban, hogy a rendszer megfelel az átfogó szakmai és üzleti követelményeknek.
Mit eredményez?
Rendszer megfelel a specifikációnak és a rendszertervnek.
Tipikusan hogyan mérhető?
Automata tesztekkel.
A tesztek folyamán fellépő hibák:
Mikor mondható sikeresnek?
A hiba megszűnése, vagy frekvenciűjának és hatásának jelentős csökkenése.
Megvalósítás eszközei
Például JMeter, Selenium, Silk Perfomer
Egyéb autómatizált tool, attól függően, hogy Webes vagy Desktop alkalmazásokat kell tesztelni.
Economic view
Ha a követelményeket egyre célravezetőbben határozzuk meg, és az agile módszertan szerint követjük a termék fejlődést, akkor minimalizáljuk a túlfejlesztési veszteséget. Egyben minimalizáljuk az alulfejlsztési veszteséget is, ami ezen a szinten sok hiba forrása.
Milyen vevőoldali felkészültség kell hozzá?
A termék üzleti logikájának, felépítésének, és a teszteszközök átfogó ismerete.
Előfeltétel
Követelmények egyértelmű listázása és igazítása a termék folyamatos fejlődéséhez.
Visszacsatolás kezelése
Az egy üzleti döntés, hogy a rendszer tesztről altuálisan visszaérkező hibák mekkora hányadát szólítjuk meg ténylegesen.
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
A szoftver tesztelésének egy típusa, amely ellenőrzi, hogy a közelmúltbeli program- vagy kódmódosítás befolyásolta-e hátrányosan a már működő szolgáltatásokat. A regressziós tesztelés nem más, mint a már végrehajtott tesztesetek teljes vagy részleges kiválasztása, amelyeket a meglévő funkciók megfelelő működésének biztosítása érdekében újra végrehajtanak.
Mit eredményez?
Egy olyan listát ad ereményül, ami megmutatja, hogy a korábban működő szolgáltatás egységekben keletkeztek-e hibák.
Tipikusan hogyan mérhető?
Automata tesztekkel. A tesztek folyamán fellépő hibák számával.
Mikor mondható sikeresnek?
A hiba korábbi detektálása, mielőtt az a felhasználóknál tudatosulna.
Megvalósítás eszközei
Például JMeter, Selenium, Silk Perfomer
Egyéb autómatizált tool, függ attól, hogy Webes vagy Desktop alkalmazásokat kell tesztelni.
Economic view
Ha a követelményeket egyre célravezetőbben határozzuk meg, és az agile módszertan szerint követjük a termék fejlődést, akkor minimalizáljuk a túlfejlesztési veszteséget. Egyben minimalizáljuk az alulfejlsztési veszteséget is, ami ezen a szinten sok hiba forrása.
Milyen vevőoldali felkészültség kell hozzá?
Agile boardban sprintekbe tervezni, tesztek kiértékelése, visszacsatolás kezelése
Előfeltétel
fejlesztői folyamatok része legyen, tesztforgatókönyv user story alapján
Visszacsatolás kezelése
ticketing, go-no go döntéshozatal
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
A szoftver kritikus részeinek tesztelését célozza meg. Olyan eseteket tartalmaz, melyek hibája esetén a további tesztek futtatása eredménytelen lenne.
Mit eredményez?
Gyors választ ad arra vonatkozóan, hogy érdemes-e tesztelésre átadni a szoftver aktuális verzióját. Ennek sikeressége esetén adhatjuk tovább a terméket a folyamat következő lépésére (átadás tesztelőknek illetve továbblépés verzió-build-re)
Tipikusan hogyan mérhető?
A tesztcsomagba beválogatott tesztesetek hiba nélkül futnak le.
Mikor mondható sikeresnek?
A tesztcsomagba beválogatott tesztesetek hiba nélkül futnak le.
Megvalósítás eszközei
Hamarosan
Economic view
A sepciális tesztelői erőforrások felhasználását hatékonyabbá teszi.
Nem kerül olyan build éles környezetbe, amiben magas bug-veszély van
A szállítási sebesség gyorsulni fog, mert az értékláncban hamarabb vesszük észre a hibát, így nem eredményez extra erőforrásfoglalást és zavart.
Az üzletileg magasan priorizált feladatok tesztelésést lehet még biztosabbá tenni ezzel.
Milyen vevőoldali felkészültség kell hozzá?
A megfeleő milestone-oknál, a külön tesztesetek megtervezése.
Előfeltétel
Tech lead határozza meg a fejlesztés során a kritikus pontokat.
Visszacsatolás kezelése
A fejlesztés javítása, esetleges újrapozícionálása majd a fejlesztés folytatása.
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
A szoftvernek egy bizonyos, célzott részletének tesztelése.
Mit eredményez?
Általában kódmódosítások után célszerű alkalmazni. A módosítás által érintett funkciókat célzó teszteket futtatjuk, nem az összes tesztet, ezzel időmegtakarítást érünk el, mindamellett, hogy az érintett kód helyességét ellenőrizzük.
Tipikusan hogyan mérhető?
A tesztcsomagba beválogatott tesztesetek hiba nélkül futnak le.
Mikor mondható sikeresnek?
A tesztcsomagba beválogatott tesztesetek hiba nélkül futnak le.
Megvalósítás eszközei
Hamarosan
Economic view
A szúrópróba teszt növeli a csapat bizalmát a munkájukban az által, hogy a termék szúrópróba szerű tesztelése is hiba nélkül lefut.
Milyen vevőoldali felkészültség kell hozzá?
core funkciókhoz tartozó tesztesetek megléte, core funkciók ismerete, célzott tesztelés igénye
Előfeltétel
Korábban fejlesztett kódok vagy külső rendszerek előzetes tesztelése.
Visszacsatolás kezelése
Ticketing, go no-go döntés.
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
A szoftver az ismert támadásokkal szembeni ellenálló-képességének ellenőrzése.
Mit eredményez?
Feladata, annak megállapítása, hogy lehet-e illetéktelenül hozzáférést szerezni a szoftver érzékeny/kritikus részeihez.
Tipikusan hogyan mérhető?
Biztonsági réseket felfedő tesztforgatókönyvek futtatásával.
Mikor mondható sikeresnek?
A tesztforgatókönyvek futtatása során egyszer sem sikerül illetéktelen hozzáférést szerezni, biztonsági rést találni.
Megvalósítás eszközei
Biztonsági tesztkövetelmény dokumentáció
Economic view
A SW által használt adatok tárolása, és használata bizontságosabbá válik.
A SW liszenszét és magát a SW-t mások nem tudják ellopni/másolni.
Milyen vevőoldali felkészültség kell hozzá?
A projekt tervezésben és ütemezésben kiemelt rész
Előfeltétel
biztonság igényes pontok meghatározása.
Mi ez?
A szoftver terhelhetőségét/teljesítőképességét vizsgálja alap, megemelt, és kritikus méretben megemelt terhelés mellett.
Mit eredményez?
Hamarosan
Elérhető célok
Megbizonyosdunk arról, hogy a rendszer az adott terhelésre hogy reagál.
Mit eredményez?
Megismerhetővé válnak a szoftver/rendszer teljesítőképességének korlátai és erőforrás-szükségletei.
Tipikusan hogyan mérhető?
A megírt forgatókönyvek közül a párhuzamosan futtatható példányokat tömegesen, egyszerre futtatjuk a rendszeren, és – a tesztforgatókönyvek eredményessége mellett – figyeljük a rendszer terhelési mutatóit.
Mikor mondható sikeresnek?
Ha az elért korlátok megfelelnek a szoftverrel szemben támasztott követelményeknek (a szoftver megfelelő válaszképesség mellett stabilan tudja kezelni az elvárt mennyiségű párhuzamos feladatottal járó terhelést)
Megvalósítás eszközei
Például Jmeter, Silk Performer
Economic view
Visszaad egy olyan eredményt, ami alapjána SW tulajdonosa/üzelemtetője képes lesz kiszolgálni SLA szerint a vevőit.
Milyen vevőoldali felkészültség kell hozzá?
A rendszer valós idejű használata közben a megnövekedett felhasználószámmal is biztosan jól működik.
A projekt tervezésben és ütemezésben kiemelt rész, illetve a terhelés várható becslése.
Előfeltétel
Felhasználás jellegéről egy leírás, terv
Előzetes terhelésbecslés
Szezonális hatás ha van
Skálázhatósági feltételrendszer/terv
Tudásmárix
Hamarosan
Mi ez?
Olyan műveletek összessége, amelyeket a szoftveralkalmazás adott funkciójának vagy funkcionalitásának ellenőrzésére hajtanak végre. A teszteset vizsgálati lépéseket, teszt adatokat, előfeltételeket, utófeltételeket tartalmaz, amelyeket egy adott vizsgálati szcenárióhoz fejlesztettek ki bármely követelmény igazolására. A teszteset konkrét változókat vagy feltételeket tartalmaz.
Mit eredményez?
Segítségével egy tesztelő összehasonlíthatja a várható, és a tényleges eredményeket annak megállapítására, hogy egy szoftver termék az ügyfél követelményeinek megfelelően működik-e.
Tipikusan hogyan mérhető?
A szoftver minden funkciójára van-e megfelelő számú teszteset, ami a funkcionalitás különböző bemeneti állapotaira elvárt választ rögzíti
Mikor mondható sikeresnek?
A tesztesetek létrehozása segítette a tesztelés hatékonyságának, minőségének javítását. Illetve a tesztesetek által feltárt hibák számának növekedése.
Megvalósítás eszközei
HP-QC
Economic view
Hatékonyan megfogott esetek, növelik a termék hibamentességét, így az ügyfelek elégedettebbek lesznek, magabiztosan használható szoftvert kapnak.
Milyen vevőoldali felkészültség kell hozzá?
A tesztelés legyen jelen a projekt tervezésekor.
Előfeltétel
Tesztmérnők, vagy őt kiváltó csapattag meghatározza a tesztelést
Tudásmárix
fejlesztői kompetencia, tesztmérnöki rendszerismeret, teszteléshez használt szoftverek ismerete, átfogó tesztforgatókönyv
Mi ez?
Az automatizált tesztek emberi beavatkozás nélkül teljesülnek. Technikai hátterük változatos: szkriptek, programozási nyelvek, speciális segédprogramok. Az automata tesztek gyorsan, nagy mennyiségű tesztet és tesztadatot képesek kezelni, így olyan feladatokra is alkalmasak, melyekre a manuális tesztek nem.
Mit eredményez?
Olyan tesztek is végrehajthatóak, amik manuális teszteléssel nem megvalósíthatóak, vagy csak nem gazdaságosan.
Tipikusan hogyan mérhető?
Tesztelés hatékonyságának növekedése és gyorsulása által
Mikor mondható sikeresnek?
Tesztelési idő/költség hatékonysága növekedett.
Megvalósítás eszközei
Jenkins, Ranorex. JMeter, Silk Performer, Selenium
Economic view
A fejlesztési költséget leszámítva „ingyen” futtatható
Azonnali reportokra képes, pl. warning, ticket, notification –> gyors információ
Időzíthető, amivel olyan időszakokban futtatható, amikor a legideálisabb, pl. nem dolgozik senki a SW-en –> teszteléssel járó terhelés nem a user-ek erőforrásait viszi el.
Milyen vevőoldali felkészültség kell hozzá?
Automatizált tesztelési kompetencia
Előfeltétel
Tesztforgatókönyv
Futtatási környezet
Döntés,h hol fut (éles/Dev)
Információt ki és milyen formában kapja meg
Tudásmárix
2
Mi ez?
A fejlesztőcsapat által meghatározott szintaktikai szabályok összessége, ami mentén a megírt kódot formázni szükséges, Lint-tel együtt.
Mit eredményez?
A meglévő fejlesztőcsapat hatékonyabban tud peer-review-t tartani, mivel a kód olvashatósága a mindenki által egyformán megírt formátum miatt egyszerű.
Új fejlesztőket is könnyebb onboarding-olni, mivel a teljes kódbázis egységes szintaktikai formában kerül kialakításra, ezért egyféle szabályrendszert kell megtanulni az olvasásához.
Tipikusan hogyan mérhető?
Van-e a fejlesztőcsapatban meghatározott szabályrendszer a kódformázásra.
Mikor mondható sikeresnek?
A fejlesztőcsapatban van meghatározott szabályrendszer a kódformázásra.
Economic view
Minél egységesebben fejlesztenek a fejlesztők, annál kisebb a hibázási lehetőség.
Ez a standardizálás nem öli meg a fejlesztői kreativitást.
Példa: Ha közösen írunk egy word doksit, akkor jó, ha mindenki ugyanazt a betűtípust és betűméretet alkalmazza.
Emberek helyettesíythetősége nő, könyebben átadhatóvá válik a kód. Új csapattag integrálása is könyebbé válik.
Hibakeresésnél átláthatóbb a kód.
Milyen vevőoldali felkészültség kell hozzá?
Architect/vezető fejlesztő által meghatározott alapelvek (, akár a csapattal bevonásával).
Előfeltétel
Csapaton belüle coding standard
Mi ez?
Fejlesztéskultúra fejlődési eszköz, a nyelv sajátosságainak és produktív megoldásainak ellenőrzésére/ajánlására.
Mit eredményez?
A fejlesztők ajánlásokat kaphatnak, hogy a megszokott módok mellett/helyett milyen produktív megoldások alkalmazhatóak az adott nyelven.
Tipikusan hogyan mérhető?
Van-e a fejlesztőcsapatban Lint-szoftver, és használják-e a napi fejlesztés során.
Mikor mondható sikeresnek?
A fejlesztőcsapatban van Lint-szoftver, és a mindennapos rutin része a személyes használat, illetve időközönként a csapatban megbeszélésre kerülnek a felmerülő ajánlások.
Economic view
Coding standard miatt a review-k ideje csökken, így nagyobb lehet a code coverage. Így nem új időt kell feltétlenül behozni, hanem lehet átcsoportosítani. Code legacy mentális terhelése csökkenhet
Cserélhetőség, és az új ember itegrálása ezzel is könnyebb.
A standard kódolási gyakorlaton keresztül felgyorsul a csapaton belüli tudásátadás. Hamarabb tudnak reagálni az elsetleges hibákra, így gyorsabb és olcsóbb a fejlesztés egész folyamata.
Milyen vevőoldali felkészültség kell hozzá?
Arhitect/vezető fejlesztő által meghatározott standard.
Előfeltétel
Elérhető (community szintű) coding standard
Elérhető toolok megvizsgálása (nyelv, projekt, csapat preferencia, etc)
Mi ez?
Annak a mérőszáma, hogy a production kód mekkora mekkora része van lefedve tesztekkel.
Mit eredményez?
A tesztekkel lefedett kód stabilitását adja azon keresztül, hogy garantálható a production kód módosítása esetén az elvárt funkcionalitás megőrzése.
Tipikusan hogyan mérhető?
A tesztek futtatása során alkalmazott CodeCoverage tool-ok használatával (pl.: JaCoCo)
Mikor mondható sikeresnek?
Ha az üzletkritikus funkcionalitás legalább 60-70%-ban lefedésre került. Ennél is jobb, ha a teljes kódbázisra is igaz a 60-70% (amellett, hogy az üzletkritikus funkcionalitás lefedettsége nem esik 60-70% alá).
Megvalósítás eszközei
JaCoCo
Economic view
A túltesztelés vesztesége és az alulfejelsztési hiba okozta hibázási költségek optimalizálása.
Milyen vevőoldali felkészültség kell hozzá?
Célmeghatározás, függően az erőforrásoktól, időtől, a piactól, a temrékkel kapcsolatos stratégiától, a várható product lifecycle-től, és a szerződésekben lefektetett feltételektől.
Előfeltétel
A termék profitabilitásának ismerete a várható tesztelési költségek függvényében, a tervezett code coverage függvényében.
Mi ez?
Kevésbé tesztelési technológiai kérdés, inkább hibázás lehetőségét csökkentő metódus.
A branchelési stratégia megalkotása és betartása fontos, hiánya fejlesztési kockázat lehet, például git által feloldható és fel nem oldható conflict-ok lehetnek pl automerge-nél.
Mit eredményez?
A párhuzamos fejlesztés során a brnachek újra összefuttatásakor nem írjuk felül a másik fejlesztő kódját, így csökkentjük a hiba lehetőségét.
Tipikusan hogyan mérhető?
Branch-elési stratégia kialakítás után a megfelelő „conflict” mentes merge-ök történnek meg.
Mikor mondható sikeresnek?
Ha a branch-ek összefűzése sikeres és a tesztek futtatása után nem keletkezik plusz hiba.
Megvalósítás eszközei
Különböző IDE-k, ami függ a branch-elés technológiájától.
Economic view
A branch-elési stratégia és a használt tesztek az integrációs tesztet tudják elővalidálni, ami azt eredményezi, hogy nem használódik fel olyan relatív drága tesztekre erőforrás, aminek a fókuszelemeit olcsóbb eszközökkel is lehet teljesíteni . Az intergrációs szintre el nem költött erőforrást további értékteremtésre lehet használni.
Milyen vevőoldali felkészültség kell hozzá?
Tech lead és a csapat meghozza a megfelelő szabályokat.
Előfeltétel
Technológiai szabályrendszer felállítása.
Mi ez?
Ne keletkezhessen hiba abból, hogy például egy formban az inputok összekeverednek. Ez lehet automata GUI teszt, pl Selenium, v manuális is.
Mit eredményez?
A fentebbi példa alapján a formok hibás kitöltésének ellenőrzése, és fejlesztői oldalról való korlátozása a szoftverbe bekerülő adatok helyességét segíti.
Tipikusan hogyan mérhető?
Validálási forgatókönyv alapú unit tesztek.
Mikor mondható sikeresnek?
Ha csak a megfelelő tartalom/input kerül a szoftverbe.
Megvalósítás eszközei
Például Regex, illetve egyéb frontend oldali validálási metódusok.
Economic view
Minnél biztonságosabb az adatbevitel és átfogóbb az ügyféledikáció annál kevesebb esélye van a vétlen adatvesztésnek vagy a SW káros működésnek.
Milyen vevőoldali felkészültség kell hozzá?
Fejlesztési erőforrás.
Előfeltétel
Validációs tervezés.
Mi ez?
Ügyfélelégedettséget növelhet, vagyis a hiánya csökkentheti azt, például ha kimegy egy nem stabil verzió, vagy nem tudnak visszaállni egy stabilra, mielőtt az a felhasználóknál tudatosulna.
Mit eredményez?
Az ügyfelek már a biztos verziót használják, ami egy aktív ingyenes UAT, és biztonságosabb a verzió frissítés is.
Tipikusan hogyan mérhető?
Stable verzió hibajegyek száma csökken, a beta / unstable visszajelzések mint hibajegy, egyre kisebb számban fordulnak elő.
Mikor mondható sikeresnek?
Ha az ügyfelek a stable verziót használva elégedettek, a béta használói pedig aktív visszajelzéseket küldenek.
Megvalósítás eszközei
Éles szerver duplikáció, verziókövetés.
Economic view
Ügyfélelégedettség növekedése a stable oldalon, és az új fejlesztések korábban elérhetőek azon ügyfelek számára akiknek korábban van szükségük 1-1 fejlesztésre.
Akik a legújabb verziót (béta) használják, közvetetten a tesztelési erőforrást növelik.
Milyen vevőoldali felkészültség kell hozzá?
Verziózás megtervezése.
Go/no-go/go-if döntések előkészítése.
Előfeltétel
üzleti döntés a béta és a atsbale verziók elérhetősége tekintetében.
Mi ez?
Ez a tesztesetek összefoglalása, nem konkrét teszt metódus.
Deklarálja a tesztelési igényeket, elvárásokat és teszteseteket,
+ gerincfolyamatok azonosítása,
+ nem triviális tesztesetek.
Mit eredményez?
Egy olyan dokumentum, amely alapján a tesztelők tisztában lesznek azzal, hogy milyen mélységben, minőségben, milyen eljárásokkal, és milyen szempontok alapján teszteljék a SW-t.
Tipikusan hogyan mérhető?
Tesztelői oldali elégedettség (pókhálódiagrammal), például érthetőség, feldolgozhatóság, reprodukálhatóság, stb.
Mikor mondható sikeresnek?
Ha a tesztelők külön kérdezés nélkül, egyértelműen el tudják végezni a tesztelési feladatokat.
Megvalósítás eszközei
Egy dokumentum, ami tartalmazza a tesztelési igényeket, eljárásokat, elvárásokat, és teszteseteket.
Economic view
A SW a tesztforgatókönyvben foglalt minőségben, tartalommal, és lefedettségben lesz letesztelve.
A tesztforghatókönyvek lehetővé teszik, hogy a rendelkezésre álló tesztelői erőforrás önszerveződő módon, optimálisan legyen felhasználva.
A projekt minden résztvevője számára, mind megrendelői, mind beszállítói oldalról transzparenssé válik a tesztelési folyamat és tartalom.
Milyen vevőoldali felkészültség kell hozzá?
Keletkező SW működésének ismerete
Tesztek megvalósíthatósági eszközeinek ismerete
Üzleti domain tudás
Előfeltétel
Üzleti igények, domain tudás és tesztelési módszertan ismeretek.
