különböző típusú becslési technikák a szoftvertesztelésben
a Szoftverteszt becslés egy alapvető irányítási művelet, amelyet egy ellenőrzött környezetben végzett bármely folyamat elindításához és befejezéséhez szükséges hozzávetőleges időkeret meghatározására használnak.
minden projekttervezés számára fontos, hogy ne lépje túl a határidőket, a költségvetést és a rendelkezésre álló erőforrásokat. Az egyik leghasznosabb feladat itt az erőforrások ellenőrzése a tesztre fordított erőfeszítések fényében.
az UTOR mérnökei gyakran használnak különböző típusú becslési technikákat a szoftvertesztelés során. Ezeket a módszereket ügyfeleink megerősítették hatékonynak. Ezért áttekintjük őket, és feltárjuk konkrét előnyeiket és hátrányaikat, hogy tájékozódjunk arról, hogyan lehet a legjobban végrehajtani őket.
mi a szoftvertesztelés becslése?
a Szoftverteszt becslés a szoftver teljes teszteléséhez szükséges időtartam és műveletek mérésének és kezelésének folyamata.
az idő és az erőfeszítés jelentősen egyszerű kiszámítani a kis léptékű feladatok. De nagyobb projektekhez. hatékony stratégiákat kell bevezetni, hogy ne kövessenek el hibákat. Ha alábecsülik vagy túlbecsülik, az ilyen projektek tesztelési erőforrásai vagy elégtelenek, vagy teljesen visszaélnek velük.
Hogyan Becsülik Meg A Csapatok A Szoftvertesztelési Erőforrásokat?
a teszt megkezdése előtt két nagyon fontos bizonytalanságot kell tisztázni a tesztelő és az ügyfél között. Ezek a következők;
- mi a teljes eljárás becsült teljes időtartama?
- mennyi az eljárás teljes becsült költsége pénzben és erőforrásokban kifejezve?
mi a becsült?
az időt, az erőforrásokat, a költségeket és az emberi képességeket általában a teszt becslés során határozzák meg.
idő
a csapat erőfeszítéseinek hatékonyságát általában az alapján ítélik meg, hogy képesek-e teljesíteni egy meghatározott időkereten belül, a határidőn belül vagy azt megelőzően.
miután ellenőrizte a projekt minden egyes szakaszához szükséges szabványos időtartamot, a projektmenedzserek kidolgozzák az egyes projektek ütemezésének módját.
biztosítja, hogy mindent időben szállítsanak. Ezért az időbecslés az egyik legfontosabb tényező az ügyfelek jó hírnevének kialakításában és a hűséges ügyfelek jó számának megteremtésében.
erőforrások
mielőtt bármilyen projekt elindulna, kötelező ellenőrizni a rendelkezésre álló erőforrásokat, azokat, amelyeket be kell vonni, és ajánlott helyettesítőket, ha néhány nem áll rendelkezésre. Ennek ellenőrzése nélkül valószínűleg a projektek nem fejeződnek be a határidő előtt.
költség
bármely tesztfolyamatra való felkészülés során a becsült költségvetést teljes mértékben figyelembe kell venni minden fronton (mind pénzügyi, mind nem pénzügyi szempontból).
a teljes költséget figyelembe kell venni, hogy figyelembe vegyék a lehetséges kiadásokat, és biztosítsák, hogy a projekt az ügyfél által előírt költségvetésen belül maradjon, és dolgozzon rajta, ha nem felel meg.
az említett mezők mind összefüggenek egymással és egymástól függenek. Az időtartam a rendelkezésre álló eszközöktől és a költségvetéstől is függ.
az idő múlásával a szoftvertesztelés becslésének eljárása különböző folyamatokkal történt, különböző módszerek és eszközök felhasználásával, amelyek ugyanazon okból haladtak az idővel.
ezeknek a technikáknak az integrálása és működése sokkal könnyebbé tette az átlagolási eljárást is.
a szoftvertesztelési becslési technikák típusai
általában sok becslés és átlagolási technika létezik, de csak néhány népszerűt fogunk megvizsgálni a cikk tételéből.
PROGRAMÉRTÉKELÉSI és felülvizsgálati technika (PERT)
ebben a technikában a feladatokat 3 alkategóriára bontják, hogy jobban megállapítsák a befejezéshez szükséges időt, nevezetesen;
az optimista forgatókönyv – O; ebben az esetben a projekt időtartama, pénzbeli és erőforrás-költségei feltételezhetően a legmagasabb optimális szinten vannak. Ez azt jelenti, hogy a minőségbiztosítási csapat egyes tagjai együttesen a legjobb munkát végzik, időben tartanak, nyomás nélkül, kiszámíthatatlan fordulat, vagy annak szükségessége, hogy újra megvizsgálják az elvégzett munkát, és továbbra is nagyszerű munkát végezzenek.
a legvalószínűbb forgatókönyv-M; itt minden dolgot figyelembe veszünk; az ismerős munkaforgatókönyvet szem előtt tartva, a negatív és pozitív lehetőségeket szem előtt tartva, az elemek becslése szerint a legvalószínűbb.
a pesszimista forgatókönyv-P; Ez a lehető legnegatívabb forgatókönyvet veszi figyelembe. Az átlagolás azon a feltételezésen alapul, hogy kétségtelenül negatív eredményt kell kezelni a teljes tesztelés minden egyes szakaszában.
Pros of PERT
- ennek a technikának a használata azt jelenti, hogy a csapat olyan becsléssel dolgozik, amely ellenőrzi az összes lehetséges halálesetet és jutalmat minden fronton.
- a csapatok nagyon közel állhatnak a valósághoz.
- felkészíti a szervezeteket a build teszt esetleges eredményére, amikor kiszámítják az egyes elképzelhető forgatókönyveket, és megfelelően felkészülnek arra, hogy szükség esetén megfékezzék azt.
hátrányok PERT
- ha nagyobb számú tesztprojekttel szembesül, a becslés ezen formájának használata sokkal több időt vesz igénybe.
- nagy a valószínűsége annak, hogy pontatlan számítások történnek.
- az itt használt értékek soha nem állandóak, és sok hibával találkozhatunk, mivel végül is csak becslés.
User Case Point (UCP)
amikor valaki vagy valami használja és kommunikál a kérdéses alkalmazással, az entitást szereplőként azonosítják. Az említett entitást elsősorban a nem beállítható használati eset súlyokban dokumentálják, amelyek befolyásolják a folyamat kapacitását.
a köztes kommunikáció biztosítja mindenki részvételét a részvényesektől az egyénekig a minőségbiztosítási csapatban a különböző szekvenciákon és meghatározott célokon keresztül.
több mint tíz különböző tényező befolyásolja, hogy egy projekt technikai jellege mennyire bonyolult, és körülbelül nyolc összetett hatással van rá környezeti szempontból. Ez összhangban van Gustav Karner megállapításaival.
ez a becslési módszer az úgynevezett szereplők, felhasználói esetsúlyok és pontok több változatának kiszámításán alapul, amelyek befolyásolják a folyamatot, a szakszerűséget és más tényezőket.
először is, ennek a folyamatnak a megkezdéséhez át kell nézniük a saját bonyolultságukat, és befolyásolniuk kell a folyamatot. Ezután a további átlagolás a számítási képletek alkalmazásával történik.
a projekt nagyságának ellenőrzése után az érintettek meghatározzák a folyamat teljes befejezéséhez szükséges időt. Ennek megelőzésének két jelentős módja a következő;
Karner módszerét alkalmazva, és minden tesztesetet 20 munkaóra fogyasztásának tekintve.
a vállalati rekordidő használata a projekt befejezéséhez, mindenesetre a statisztikai átlagok kiszámításához és az aktuális projekt időtartamának kitalálásához.
UCP= nem módosítható UCP x MŰSZAKI komplexitási tényező X környezeti befolyásoló tényező.
az UCP előnyei
- abban az esetben, ha előre kell dolgoznia és idő előtt meg kell terveznie, akkor ez a becslési módszer valószínűleg jobb, mivel a kezdeti szakaszban történik, és segít a költségvetési méretek metszésében és jóváhagyásában.
- néhány speciális irányítási eszköz segítségével lehetséges a becslések automatikus kiszámítása, Ami sok időt takarít meg az értékelő csoport számára és megkönnyíti a munkát.
az UCP hátrányai:
- ha a projekt követelményei nincsenek megadva a felhasználói Esetpontokban, ez lehetetlenné teszi ennek a technikának a használatát, és a minőségbiztosítási csapatnak más módszert kell beszereznie.
- ha az UCP-k meg vannak adva, és nem elég pontosak vagy elég egyértelműek, akkor a legvalószínűbb, hogy negatívan végződik a valós becslésekkel, mivel ez a módszer nem csak az esetpontok megadásától, hanem az egyértelmű esetpontok megadásától is függ.
Munkabontási struktúra (WBS)
itt az értékek becslésének technikáját úgy végezzük, hogy az elsődleges folyamatot különböző alkategóriákra osztjuk. Az egyes szakaszok átlagos időtartamának prediktív kiszámítása fokozatosan a tétel egyszerűbbjeinek durva munkájával kezdődik, majd mind nehézségi, mind helyességi szinten érettségizik.
a kezdeti folyamat után válassza ki a lehető legmagasabb értéket, amelyet elért, és adja hozzá őket, és kapja meg a végső értéket, megbecsülve az egyes tevékenységekhez szükséges erőfeszítést és időt.
a WBS előnyei
- ennek a módszernek nyilvánvaló előnye, hogy megkönnyíti a perc és a szükséges részletek észlelését, miközben a munkát kisebb bitekre osztja. Ez azt jelenti, hogy a munka
- mindig alapos és átlátható,mivel a következtetések ugyanarra a célra és könnyebb nyomon követésre kerülnek.
a WBS hátrányai:
- ez a természet általában megköveteli az elmék és a csapattagok és az érdekeltek dörzsölését, hogy kihasználják a külső tapasztalataikat.
- a specifikációk és az ügyféligények változásai elavuláshoz vezethetnek, és szükségessé teszik a csapat számára, hogy vizsgálja meg és teljesen értékelje át.
Delphi módszer
a Delphi módszer világszerte igen népszerű a tesztelő csapatok körében. Az önkéntes résztvevőktől származó adatokat összegyűjtik és alaposan megvizsgálják, és nem külön sorrendben, megállapodott következtetésre jutnak.
a vizsgálat minden fázisa új vagy javított adatvisszajelzést eredményez, ami csak növeli a végső eredmények finomítását a megérdemelt bizalommal.
általában egy csapat legfeljebb tíz személyből áll, akik találkoznak, hogy megvitassák a projekt kritikus jellemzőit, és elmondják véleményüket a projekt lehetséges időtartamáról.
ezt követően a csapat újra összeül, és ezúttal az első dátum véleményét osztják meg. Ez a tagok számára egy másik megközelítési szöget ad a projektnek. A nézeteket azonban nem jelölik meg javaslataikhoz.
amikor a csapat tagjai túl vannak ezen a szakaszon, újabb egyhangú vitát folytatnak, és a vélemények összevetése figyelembe veszi az új észlelési szöget.
ez addig folytatódik, amíg mindenki egyetért ugyanazon az oldalon. Bár a Delphi módszer szokásos módja, ez a forma módosítható az igényeinek és képességeinek megfelelően.
a DELPHI előnyei
- mivel itt nincs szükség egyedi képletekre vagy berendezésekre, ez a legkönnyebb a tétel bármely csapat számára, csak az ügyfél specifikációira van szükség, és jó menni.
- a becslés nagyon közel áll a pontossághoz, mivel számos szakmai szempontot figyelembe vesznek a találkozó és az ötletmegosztás folyamatában.
Cons of DELPHI
- olyan egyszerű, mint lehet alávetni, ez eltarthat egy csomó produktív időt, mert gyakrabban, mint nem.
- kihívást jelent egy átfogó becslés elkészítése az első találkozók után és a vélemények megosztása, ezért általában néhányra van szükség.
- még ennyi idő elfogyasztása után sem lehet újrahasznosítani az eredményeket. Tehát minden egyes projekt futtatásához a folyamat újrakezdődik az új követelményekkel.
összefoglalva
ez a blogbejegyzés áttekintette a szoftvertesztelés négy becslési technikáját, és azt, hogy mennyire hatásosak az ésszerű tesztelési költségvetés tervezésében.
a sikeres becslés után biztos lehet benne,hogy a projektek kiszervezése a minőségbiztosítási vállalatokhoz?
itt van egy cikk, Hogyan kell kiválasztani a legjobb megközelítés QA outsourcing.
mondja el nekünk, hogy ezek közül a tesztelési becslési taktikák közül melyiket alkalmazná, és mi volt a betekintése?