Techniky odhadu testů v testování softwaru
⚡ Chytré shrnutí
Techniky odhadu testování softwaru odhadují, jak dlouho bude testování trvat a kolik bude stát. Čtyřkrokový proces – rozdělení úkolů, přiřazení zodpovědných pracovníků, odhad úsilí a ověření se zúčastněnými stranami – proměňuje vágní časové harmonogramy v obhajitelný plán, který může management schválit.

Co je odhad testu softwaru?
Odhad softwarových testů je manažerská činnost, která odhaduje, jak dlouho bude testovací úkol trvat a kolik bude stát. Vytvoření věrohodného odhadu testování je jednou z nejdůležitějších odpovědností v správa testů protože ovlivňuje rozhodnutí o harmonogramu, rozpočtu a zdrojích.
Proč je důležitý odhad testů
Klienti si vždy před podpisem zkušební smlouvy položí dvě otázky:
U malých projektů je snadné na tyto otázky odpovědět. U většího projektu – například testování GuruWebové stránky banky 99 – k obhajobě odpovědi potřebujete strukturovanou techniku.
Co odhadnout?
- Zdroje: lidé, vybavení, zázemí, financování a cokoli dalšího potřebného k provedení práce.
- Čas: nejcennější zdroj v jakémkoli projektu – každé vydání má svůj termín.
- Lidské dovednosti: znalosti a zkušenosti týmu. Silnější testeři dokončí práci rychleji než méně zkušený tým.
- Cena: rozpočet projektu – kolik peněz je potřeba na provedení plánovaného testování.
Jak odhadnout
Běžné techniky odhadu softwarových testů jsou:
- Struktura rozdělení práce (WBS).
- Tříbodový odhad.
- Širokopásmový Delphi.
- Analýza funkčního bodu nebo testovacího bodu.
- Metoda bodů užití.
- Procentní rozdělení.
- Ad-hoc metoda.
Níže uvedený čtyřkrokový proces kombinuje několik technik, aby se dosáhlo obhajitelného odhadu. V příkladu je použito Guru99 Případová studie banky.
Krok 1) Rozdělte celý projekt na dílčí úkoly
Použití Work Breakdown Structure technika pro rozdělení komplexního projektu na moduly, podmoduly a nakonec na nejmenší smysluplné úkoly. Odhady jsou mnohem spolehlivější na úrovni listů než u vágních projektů s hlavním názvem.
Použijte techniku k prolomení GuruRozdělte projekt 99 Bank do pěti menších úkolů:
Každý úkol je poté rozdělen na dílčí úkoly, dokud není každý řádek dostatečně podrobný pro odhad.
| Úkol | Dílčí úkol |
|---|---|
| Analyzujte specifikaci softwarových požadavků | Prozkoumejte specifikace požadavků. |
| Proveďte rozhovory s vývojáři a dalšími zainteresovanými stranami, abyste se o webových stránkách dozvěděli více. | |
| Vytvořte specifikaci testu | Navrhněte testovací scénáře. |
| Vytvořte testovací případy. | |
| Revprohlížet a revidovat testovací případy. | |
| Proveďte testovací případy | Vytvořte testovací prostředí. |
| Proveďte testovací případy. | |
| Revzobrazit výsledky provedení testu. | |
| Nahlaste závady | vytvoření vada zprávy. |
| Nahlaste závady. |
Krok 2) Přidělte každý úkol jednomu členovi týmu
Přiřaďte každý dílčí úkol nejvhodnějšímu vlastníkovi.
| Úkol | Majitel |
|---|---|
| Analyzujte specifikaci softwarových požadavků | Všichni členové týmu |
| Vytvořte specifikaci testu | Tester / Testovací analytik |
| Vytvořte testovací prostředí | Správce testu |
| Proveďte testovací případy | Tester, administrátor testů |
| Hlásit závady | Tester |
Krok 3) Odhad úsilí pro každý úkol
V této fázi dobře fungují dvě doplňkové techniky:
- Metoda funkčních bodů.
- Tříbodový odhad.
Metoda 1) Metoda funkčních bodů
Manažer testování odhaduje velikost, trvání a náklady pro každý úkol.
Krok A) Odhadněte velikost úkolu
Vezměte si úkol „Vytvořit specifikaci testu“. Její velikost závisí na funkční velikosti testovaného systému – čím více funkcí, tím složitější systém. Funkční body se obvykle dělí do tří skupin: Složité, Střední a Jednoduché.
Na základě složitosti přiřadí manažer testování každému funkčnímu bodu váhu:
| Skupina | Vážení |
|---|---|
| Komplex | 5 |
| Střední | 3 |
| prostý | 1 |
Jedno GuruWebové stránky banky 99 jsou rozděleny do 12 funkčních bodů. Jejich komplexnost je shrnuta níže.
| # | Modul | Použitelné role | Description | Vážení |
|---|---|---|---|---|
| 1 | Dotaz na zůstatek | Manažer, Zákazník | Zákazník: zobrazit pouze zůstatek na vlastních účtech. Manažer: zobrazit zůstatek každého zákazníka pod dohledem. |
3 |
| 2 | Převod prostředků | Manažer, Zákazník | Zákazník: převádět finanční prostředky z vlastního účtu na libovolné místo určení. Manažer: převádět finanční prostředky z jakéhokoli zdroje do jakéhokoli místa určení. |
5 |
| 3 | Mini prohlášení | Manažer, Zákazník | Posledních pět transakcí na účtu. Zákazník: zobrazit pouze vlastní účty. Manažer: zobrazit jakýkoli účet. |
3 |
| 4 | Přizpůsobené prohlášení | Manažer, Zákazník | Filtrované transakce podle data nebo hodnoty. Zákazník: pouze vlastní účty. Manažer: jakýkoli účet. |
5 |
| 5 | Změnit heslo | Manažer, Zákazník | Zákazník: změnit si vlastní heslo. Manažer: změnit své heslo (ne heslo zákazníka). |
1 |
| 6 | Nový zákazník | Manažer | Přidávání a úprava údajů o zákazníkovi (adresa, e-mail, telefon). | 3 |
| 7 | Nový účet | Manažer | Spořicí a běžné účty; zákazník může vlastnit více účtů od každého. Správce přidává nové účty pro stávající zákazníky. | 5 |
| 8 | Upravit účet | Manažer | Upravit podrobnosti o existujícím účtu. | 1 |
| 9 | Smazat účet | Manažer | Smazat existující účet pro zákazníka. | 1 |
| 10 | Smazat zákazníka | Manažer | Smazat zákazníka pouze v případě, že neexistují žádné aktivní účty. | 1 |
| 11 | Vklad | Manažer | Vložte hotovost na jakýkoli účet na pobočce. | 3 |
| 12 | Výběr peněz | Manažer | Vyberte hotovost z jakéhokoli účtu na pobočce. | 3 |
Krok B) Odhad doby trvání úkolu
Jakmile je stanovena složitost, odhadněte dobu potřebnou k testování každé skupiny.
- Celkové úsilí: maximální úsilí o otestování všech funkcí webových stránek.
- Celkový počet funkčních bodů: celkový počet modulů webu.
- Odhad na funkční bod: průměrné úsilí na bod; závisí na produktivitě týmu.
Předpokládejme, že odhad týmu na funkční bod je 5 hodin/bodCelkové úsilí pro GuruPříklad banky 99 je:
| Skupina | Vážení | Funkční body | Celková cena |
|---|---|---|---|
| Komplex | 5 | 3 | 15 |
| Střední | 3 | 5 | 15 |
| prostý | 1 | 4 | 4 |
| Funkce Celkový počet bodů | 34 | ||
| Odhad za bod | 5 | ||
| Celkové odhadované úsilí (osobohodiny) | 170 | ||
Celkové úsilí potřebné k dokončení „Vytvoření specifikace testu“ je přibližně 170 osobohodinJakmile je známo potřebné úsilí, můžete přidělit zdroje a určit tak dobu trvání a náklady.
Krok C) Odhad nákladů na úkoly
Tento krok odpovídá na druhou otázku klienta – „Kolik to stojí?“. Předpokládejme průměrnou týmovou sazbu $ 5 / hodVýše uvedený úkol trvá 170 hodin, takže náklady jsou 170 × $5 = $850Pro výpočet rozpočtu projektu použijte stejný výpočet na každý úkol WBS.
Čím přesnější je odhad, tím lépe můžete spravovat rozpočet projektu a zajistit návratnost každé investice.
Metoda 2) Tříbodový odhad
Tříbodový odhad je strukturovaná technika, při které manažer testování poskytuje pro každý úkol tři hodnoty – optimistický, pravděpodobně, a pesimistický úsilí – na základě předchozích zkušeností nebo nejlepších odhadů.
Pro „Vytvořit specifikaci testu“ mohou být tyto tři hodnoty:
- Nejlepší případ: 120 osobohodin (cca 15 dní) se silným a zkušeným týmem.
- S největší pravděpodobností: 170 osobohodin (cca 21 dní) s typickým týmem a zdroji.
- Nejhorší případ: 200 osobohodin (cca 25 dní) s méně zkušeným týmem a dodatečnými úpravami.
Vypočítejte vážený průměr pomocí vzorce ve stylu PERT:
Hodnota E je vážený průměr — odhad hlavního textu pro „Vytvoření specifikace testu“.
Vyjádřit důvěru kolem sebe E, vypočítejte směrodatnou odchylku:
Pro Guru99 Příklad banky, na který odhad vychází 166.6 ± 13.33 osobohodin — rozmezí 153.33 až 179.99 osobohodin.
Krok 4) Ověřte odhad
Agregujte odhady všech úkolů z WBS a předložte plán představenstvu (generálnímu řediteli, projektovému manažerovi, klíčovým zainteresovaným stranám) k posouzení a schválení.
Projděte tabuli logicky odhadem, aby pochopili předpoklady, zvolené techniky a předpokládanou míru nepředvídanosti.
Nejlepší postupy pro odhadování testů
Přidejte čas vyrovnávací paměti
Plány zřídka přežijí kontakt s realitou – členové týmu odcházejí, testy trvají déle, než se očekávalo, závislosti se vytrácejí. Do každého odhadu začleňte rozumnou rezervu, aby harmonogram absorboval drobná překvapení.
Plánování dostupnosti zdrojů
Zohledněte plánovanou dovolenou, školení a pracovní pohotovost. Odhady, které ignorují dostupnost, vypadají na papíře skvěle, ale při realizaci selhávají.
Použijte minulé zkušenosti jako referenci
Historická data z podobných projektů jsou neocenitelná. Pokud jste loni testovali srovnatelný web, poučte se z jeho skutečných výsledků, zjištěných problémů a z rezervy, která situaci zachránila.
Držte se odhadu – ale znovu si ho projděte
Odhady nejsou podvrženétracts; jsou to nejlepší odhady. RevSledujte je na známých milnících a upravujte je pouze tehdy, když se požadavky podstatně změní nebo nové informace posunou situaci. Jakoukoli změnu s zákazníkem transparentně vyjednávejte.
Šablona odhadu testu softwaru
Stáhněte si soubor Excel pro odhad softwarových testů (.xlsx)
Další techniky odhadu
Kromě WBS, Function Point a Three-Point odhadu se široce používá několik dalších technik:
- Širokopásmový Delphi: iterativní konsenzuální odhad panelem expertů.
- Metoda případových studií: odvozuje úsilí z počtu a složitosti případů užití.
- Procentní rozdělení: přiděluje fixní procento celkového úsilí projektu na testování.
- Metoda ad-hoc: odborný úsudek, pokud chybí historická data.
Odhad zdola nahoru vs. shora dolů
Praktický pohled na odhad se také rozděluje na dvě doplňkové strategie:
- Odhad zdola nahoru: na základě úkolů na nejnižší úrovni WBS. Více zúčastněných stran, zkušených zaměstnanců a přispěvatelů spojí svá čísla, aby dosáhli přesného součtu. Ideální, když je práce dobře pochopena.
- Odhad shora dolů: klasifikuje projekt podle velikosti a složitosti a porovnává ho s dokončenými projekty podobného tvaru. Používá také průměrné úsilí na modelový případ a škáluje se podle předpokládaného počtu případů. Užitečné na začátku projektu, kdy je málo detailů.
Většina týmů kombinuje oba přístupy – shora dolů pro hlavní číslo, zdola nahoru pro sebevědomí – a výsledek překrývá sofistikovanými modely, pokud rozpočet toto úsilí odůvodňuje.














