A teszteléshez szükséges idő kiszámítása
... Vagy más szavakkal, hogyan számolod ki a tesztelés idejét, hogy mindenki hisz benne? Végtére is, valójában általában két célunk van. Az első az idő számlálása annak érdekében, hogy ne tévedjen, és helyezze el megfelelően az erőforrásokat - valószínűleg először nem fog jól működni. A második cél reálisabb: mérje meg a tesztelés idejét, hogy bizonyíthassa valakinek, hogy több emberre van szüksége a csapatban, magyarázza el, miért nincs időnk, stb. Furcsa, amint úgy tűnhet, 50 után végzett a második és az első fog működni!
Most nézzük meg, hogyan számoljuk meg a tesztelés idejét konkrét példákon.
1. eset: "Itt van a TK, mennyi időt vesz igénybe a vizsgálati esetek írása?"
Tegyük fel, hogy egy nagy mappát találunk egy jól megírt technikai specifikációval (TOR). Arra kérdezik tőlük, hogy mennyi ideig tart a teszthelyzetek (TC) elkészítéséhez.
Mielőtt válaszolnánk erre a kérdésre, tudnunk kell:
- Ki fog írni a TS-t?
- Mi az a személy szintje? aki TS-t fog írni: kevesebb vagy több tapasztalata van, mint te? Nyilvánvaló, hogy ha kevesebb tapasztalata van, szüksége lesz több időre. Ha ugyanolyan tapasztalatai vannak, mint te, akkor az értékelésed összeolvad. Ha valaki meredekebb, mint te, akkor egyáltalán nem világos, hogy miért kérte fel az időt.
- Mi a technológia ismerete? Lehet-e az ember alacsony szintű tesztelést folytatni, jó mindent megérteni, meg fogja érteni, hogy mi történik a bázissal, például?
- Mi a tárgyi tudás szintje? Ez még fontosabb, mint a technológia ismereteinek szintje, mert ha például egy bizonyos kifinomult pénzügyi alkalmazás tesztelésére van szükségünk, és egyáltalán nem értjük, hogy milyen kötvények és lehetőségek vannak, sok időbe fog telni a domain megértése. Anélkül, hogy megértenék, mennyire összetett TK, mennyire bonyolult a termék, és végül, mennyire terjedelmes és milyen TS-t kell egyáltalán igen nehéz.
- Miért és kinek írták a TS-ket?
- Magának - ha teszteljük belső fejlődésünket. Van saját termékünk, csapatunk, és TS-t írunk termékeink számára.
- Az ügyfél számára. Néha az ügyfél csak tesztelést rendel, és néha csak a TS-t. Néha megpróbálja egyszer tesztelni, majd hagyjon neki egy mesterséget, amellyel meg tudja próbálni magát. A TS-nek az ügyfél számára kevésbé részletes és részletes, de másképp, mint ha a TS-t magunknak írnánk. Tehát mi magunk is megértjük a tesztelés összes feltételt, de talán a TS-ben minden részletre bonyolult dolgokat részletezni fogunk. Az ügyfél tökéletesen meg tudja érteni a témát, de nem tudja, mi az űrlap érvényesítés, és ezt meg kell magyaráznia.
- Az átvételi teszteléshez - ebben az esetben a TS még nehezebb írni, mint az ügyfél számára, mert ez a tesztelés, amelynek eredményét az ügyfél nem fogadhatja el, ha nem akarja. Ezért a TS-t sokkal inkább formálisabbá tesszük az átvételi teszthez - nem szabad olyan formulákkal rendelkezni, mint a "minden jól működik", mert ilyen jármű esetén az ügyfél nem vehet el semmit tőled és soha.
- Az automatizáláshoz. Itt meg kell fontolnunk a tesztelést, az adatok vezérlését, az automatizálást, stb.
- A lélek számára. Ebben az esetben csak meg akarjuk érteni, és nincs kérelem a csapattól a teszteléshez.
- Hol íródnak, milyen tesztelési rendszerben?
- Ez egy ismerős környezet.
- Ismeretlen környezet. Ismeretlen környezetben természetesen több időre van szükségünk.
Az összes kérdésre adott válaszoktól függ, hogy mennyi ideig tart egy pozitív teszteset - T1. Érdemes megfontolni egy negatív jármű írásának idejét is (ez T-1 lesz). Tapasztalatom szerint a negatív TC-k általában hosszabb ideig íródnak - általában többre van szükségük. Természetesen itt vannak különböző módszerek, de számomra úgy tűnik számomra, hogy minél jobban ismerjük a domainet, annál jobb megértjük az alkalmazást, annál jobb megértjük, hol és hogyan csökken, annál inkább negatív TS-t fogunk kapni. Ha például három negatív TS van, egy negatív, akkor talán félreérted az alkalmazást. Ha 500 negatív TS-t találsz egy pozitívnak, ez jó munka. Van egy pozitív és negatív TS összefüggése - általában ½-ról 1/5-ra.
T. ch. Meg kell számolnunk az időtartamot, hogy írjunk egy pozitív TS-t, hogy becsüljük a pozitív és negatív arányokat, és teljes időtartamot számítsunk ki.
Értékelési lehetőségek:
- Durva szakértő. Például tudjuk, hogy általában 5 TS-t írunk a TK egyik oldalára. Általában egy TC írunk 20 percet. A technikai feladat 300 oldal. 5 x 20 x 300 = 30000 - ez az, hogy hány perc múlva TS-t írunk.
- A tesztelés időről időre X-ot veszi.
- Vizsgálati esetek írása időről időre tesztelés céljából
- Megtörjük a TK-t homogén részekké (például a funkcionális szerint), és megpróbáljuk írni a TS-t minden egyes részre
- Megnézzük, mennyi időt töltöttünk a TS-nek az egyes részek bizonyos oldalára történő írásakor, ebből kiindulva kiszámítjuk, mennyi időt kell eltölteni a TS-nek minden egyes részhez
- Hozzáadjuk az egyes részekre számított időt
Most próbáljuk kiszámítani, hogy hány órát nagyjából megyünk írni a TS-nek (de figyeljünk, és egyáltalán nem teszteljük):
Becslések nem értenek egyet velünk, de ez normális - legalább sikerült kb. És ha elegendő idő áll rendelkezésünkre ahhoz, hogy értékeljük, többféle módon értékelhetünk.
Az idő számítása az Agile segítségével
Most beszéljünk rugalmas fejlesztési módszerekről, amikor nincs technikai feladat. Nem világos, hogyan kell értékelni, de vannak még néhány megközelítés. Például:
- csak sétálni a hátralékban;
- írjon magas szintű TS-t;
- írja le a sprintben található összes tevékenységet, és próbálja meg becsülni, hogy mennyi időbe telik - ezt a megközelítést az alábbiakban tárgyaljuk.
Most egy kis kitérés a QA menedzserek, projektmenedzserek számára. Minden olyan lépés, amellyel teszt eseteket hozhatunk létre és indíthatunk, amelyek a következő összetevőkre oszthatók:
2. eset: "Itt van egy funkcionalitás, mennyi időt vesz igénybe tesztelni?"
Mennyi időbe telik a funkcionalitás ezen vagy a részének tesztelése? Ahhoz, hogy kitaláljuk, vannak különböző módok:
Láthatja, hogy mennyi időbe telik nekünk hasonló funkciók tesztelése. - Ugyanazt a funkciót tekintheti meg. Ha ezt már teszteltük. Nagyon kényelmes! Ha természetesen rögzítetted a legutoljára, mennyi idő telt el.
- Deduktív értékelés - ha tudjuk, hogy mennyi ez a funkció kerül sor az általános funkcionális (ha például már tudjuk, hogy mennyi időt vesz igénybe a teljes regresszió), csak látni, hogy ez a funkcionális tesztelés lesz, például az ötödik rész az idő.
- Induktív értékelés - emlékszünk arra, hogy mennyi időt töltünk minden járművön. Ezt a funkcionalitást tekintjük át, és megértjük, hogy teszteléséhez 10-15 TC szükséges.
Mi a fontos ebben az esetben emlékezni? Az új funkciók újra megkövetelhetik a környezet előkészítéséhez szükséges időt. Fontos megjegyezni a rendszer megismerésének egy együtthatóját: több időt vesz igénybe a teszteknél, ha először futtatod őket, mint ha másodszor vagy harmadszor futtatod őket. De ha a második alkalommal egy hónap múlva jön, akkor még mindig elindul, mint először - azonban mindenkinek sajátja van.
3. eset: "Miért nincs időd semmit tenni?"
Ezután egy nagyon gyakori kérdés a tesztelők: „mit csinálnak, miért érvényesülnek semmit, hogy miért kell segíteni automatizálásával miért nem akarsz minden nap megjelent egy új verzió - rögzíti újat nem . "
Annak érdekében, hogy megmutathassuk, mit csinálunk, minden projektre leírhatunk minden feladatot, amelyet egy sprintben hajtunk végre, és naponta írjuk ki őket: számoljuk meg, mennyi időt töltöttünk minden egyes feladaton ezen vagy azon a napon. Tehát láthatja az átlagos, maximális és minimális terhelést.
Példa egy ilyen táblázatra:
Amikor megcsináltam, láttam, hogy nem mindig terhelik a terhelés - néha a terhelés nagy, néha fél napja semmi köze. Ez lehetővé teszi bizonyos következtetések levonását, és valahogy optimalizálja a folyamatot, terjeszti a terhelést - pl. Néhány dolgot előre, még akkor is, ha ez nem teljesen összhangban van a folyamat logikájával. Például, ha sok sprint van a sprint elején, elkezdhetünk egyéni cikkeket írni a következő sprinthez. Bár nem tudjuk, hogy a szerkezet a következő sprint, mégis a legnagyobb valószínűséggel képes kitalálni, hogy itt ez a két vagy három történet akkor biztosan - ezek általában a legkritikusabb, ezek általában mindig kell átírni, ezért jó gyakorlat.
A rakomány napról napra megvan. És ha kiderül, hogy minden nap 24 órányi tesztelésre van szükségünk, és csak két emberünk van ... Szóval szükségünk van egy harmadik tesztelőre!
4.1. Eset: "Pénteken, és még korábban is kiadjuk a gyűlést - tehát mennyi időre van szükség a teszteléshez?"
Ebben az esetben a tesztelési folyamat a következőképpen épül fel:
- Füst teszt + teszt teljes visszafejlődése x számának legfontosabb platformok + teszt az alapvető funkciókat az összes platformon + teszteket a teljes regressziót platformok (lásd. Mátrix).
- Újra tesztelés: füstvizsgálat + érvényesítés x minden platform.
A platformok teljes regressziójának tesztelése ebben az esetben a következőképpen történik (Cr, FF, stb., Itt - különböző platformok, ebben az esetben - böngészők):
Ebből a mátrixból látjuk, hogy minden platformon teszteljük a funkcionalitás egy részét: végül kiderül, hogy minden funkciót ellenőrizünk, és minden platformon teszteljük a munkát. Ezt a mátrixot is eltolhatjuk - végül kiderül, hogy bizonyos számú futás esetén minden egyes funkciót ellenőrizünk minden egyes platformon. Ez egy egyszerű rendszer - és előfordulhat, hogy a 20 konfigurációk képes automatizálni tesztelés - természetesen ebben az esetben nincs ideje, hogy ellenőrizze, és ellenőrizni fogják a mátrix.
Ennek eredményeként a következő képletet kapjuk:
ΣT = (Tprec + Treg) x (Qmain + 1) + (Tprec + Tbase + Tsmoke) x Qconf + (Tsmoke + Tvalidation) x Qconf x Qreturns
Qmain - a fő konfigurációk száma, amelyeken mindent tesztelünk.
Qreturns - a visszatérítések száma.Ezzel a formulával egyértelmű, hogy mennyi idő lesz. Ezzel megpróbálhatja követni az időt, és nézze meg, hogy a tesztelés mennyi időt vesz igénybe. Világossá válik továbbá, hogy hol és mi jobb automatizálni - meg fogjuk érteni, hogy az automatizálás mennyire időt takarít meg nekünk.
4.2 eset: "Túl sok teszt! Gyorsabban megyünk.
Ha gyorsabb tesztelésre van szükségünk, akkor csökkenthetjük a tesztek számát a következő elveken:
- Megvizsgáljuk a prioritásokat:
- teszt esetek - ha feljegyezzük a jármű prioritásait. Ezután csak a legmagasabb prioritású TS-vel dolgozunk;
- egyéni történetek vagy hibák. ha a jármûink hozzá vannak rendelve.
- Megtekinthetjük a kibocsátáshoz kapcsolódó megjegyzéseket (kiadási megjegyzéseket), amelyek a következőket tartalmazzák:
- kritikus fontosságú funkcionális. amelyek nélkül az alkalmazás nem fog működni, és senki sem igényli;
- a bejelentett új funkcionalitás - mivel nyilvánosan bejelentették, a felhasználók ellenőrizni fogják;
- a kritikus hibák korrekciója (valószínűleg a hibákat már ellenőrzik);
- a hibák állítólagos helyesbítései - kijelentettük, hogy valamit korrigáltunk, és mi ellenőrzik;
- ismert problémák - paradox módon, bár úgy tűnik, de feltétlenül meg kell vizsgálnunk azokat a hibákat, amelyeket hibának számítottunk, amellyel felszabadítottuk a terméket. Miért ez? Először ellenőrizni kell, hogy hatásuk pontosan megegyezik-e azzal, amit leírtunk. Másodszor ellenőrizzük, hogy működik-e a hiba kerülő megoldása.
- Ahelyett, hogy csökkentené a tesztelés mennyiségét, növelheti a parancsot.
- Programozók hozzáadása - mindenekelőtt a saját projektből. Például adatgenerátorokat és anyagokat írhatnak - mindent az automatizáláshoz vagy a félig automatizáláshoz. Jól teszik, és a tesztelésért való felelősség még mindig nincs rajta - így nem szenvednek attól a ténytől, hogy kódjuk nem működik jól. Ugyanezen okból kérheti néhány programozótól, hogy ellenőrizze a többi programozó kódját.
- Hívja a tesztelőket más projektekből vagy ebből a projektből, de tegyen valami mást.
Általában a tényleges tesztelési folyamatot háromszög formájában lehet ábrázolni. Ennek a háromszögnek a szögei:
- A vizsgálat volumene.
- A csapatok száma.
- Term. amelyre tesztet kell végezni.
A sebesség és a minőségi vizsgálatok függ ezen a három területen - nevezetesen felettük meg kell gondolni, hogy sikeresen tervezni a munkát. Például, ha azt kérik, hogy megvizsgálja a termék az irreálisan rövid idő, és mi nem felel meg, vagy megtagadják az ilyen munkát (ha nem szeretné, hogy kiadja a rossz minőségű termék, természetesen), vagy a munka a fenti szempontokat. Akkor tudjuk:
- Csökkentse a tesztelés mennyiségét.
- Növelje a csapat tagjainak számát.
- Kérjen több időt a tesztelésre.
Ez utóbbi módszer talán a legmegbízhatóbb: végül is az emberek képesek lehetnek munkatársként segíteni a csapatot, és a tesztelés mennyiségének csökkentése nyers termék megjelenéséhez vezethet.
Is van egy módja -, hogy megkérdezze, miért ilyen kifejezések. Talán csak egy függvényre van szükségünk egy ügyfél számára - akkor magánjellegűvé tesszük, majd később mindent megpróbálunk.
Végül egy másik ügy: a már kiadott projekt befejezése
Ha a projekt már ki, de kapott egy kérelmet, hogy módosítsa azt, ahogy számítani a vizsgálat időpontjában, a fejlesztési és így tovább. E. Ebben az esetben az idő a szokásos, de szorozzuk meg kettővel, mert minden ember minden feledésbe merült már más projektekben - ez időt vesz igénybe, hogy megismerjék a rendszert. Célja továbbá a kívül lehet a standard ciklus, így, kivéve a túl ezt a tesztet, akkor szükség lehet a teljes regresszió - majd adjuk hozzá az idő, hogy a teljes regresszió.
Kapcsolódó cikkek