různé typy technik odhadu v testování softwaru

odhad testu softwaru je základní řídící operace používaná k určení přibližného časového rámce potřebného pro zahájení a dokončení jakéhokoli procesu v kontrolovaném prostředí.

je důležité, aby jakékoli plánování projektu nepřekročilo časové limity, stanovilo rozpočty a dostupné zdroje. Jedním z nejužitečnějších úkolů je kontrola zdrojů s ohledem na úsilí vynaložené na test.

inženýři v UTORU často využívají různé typy technik odhadu během testování softwaru. Tyto metody byly potvrzeny jako efektivní našimi klienty. Proto je projdeme a odhalíme jejich konkrétní klady a zápory, abyste byli informováni o tom, jak je nejlépe implementovat.

co je odhad testování softwaru?

odhad Softwarového testu je proces měření a řízení doby trvání a akcí potřebných k provedení úplného testu softwaru.

čas a úsilí je značně jednoduché vypočítat pro malé úkoly. Ale pro větší projekty. musí být zavedeny účinné strategie, aby nedocházelo k chybám. Pokud jsou podceňovány nebo nadhodnoceny, zdroje pro testování takových projektů se stanou buď nedostatečnými, nebo zcela zneužity.

Jak Týmy Odhadují Zdroje Pro Testování Softwaru?

před zahájením testu existují dvě velmi zásadní nejistoty, na kterých vše závisí a musí být mezi testerem a klientem vyžehleno. Patří mezi ně;

  • jaká je celková odhadovaná doba trvání celého postupu?
  • jaké jsou celkové odhadované náklady na proceduru z hlediska peněz a zdrojů?

co se odhaduje?

čas, zdroje, náklady a lidské dovednosti se obvykle určují během odhadu testování.

čas

účinnost týmového úsilí se obvykle posuzuje podle schopnosti dodat ve stanoveném časovém rámci, v termínu nebo před ním.

po kontrole standardní požadované doby trvání pro každou část projektu po ruce, projektoví manažeři vyvinout způsob, jak udržet naplánovat každý projekt.

zajišťuje, že vše je doručeno včas. Z tohoto důvodu, odhad času je jedním ze základních faktorů při budování vynikající pověst mezi zákazníky a mají dobrý počet věrných klientů.

zdroje

před zahájením jakéhokoli projektu je nutné zkontrolovat dostupné zdroje, ty, které by měly být zahrnuty, a doporučené náhrady, pokud některé nejsou snadno dostupné. Bez kontroly je velmi pravděpodobné, že projekty nebudou dokončeny před termínem.

náklady

při přípravě na jakýkoli zkušební proces musí být odhadovaný rozpočet plně zohledněn na všech frontách (finanční i nefinanční).

celkové náklady musí být vzaty v úvahu, aby bylo možné vzít v úvahu možné výdaje a zajistit, aby projekt zůstal v rámci stanoveného rozpočtu klienta, a pracovat na něm, pokud to není až.

uvedená pole jsou na sobě vzájemně závislá a vzájemně závislá. Doba trvání, která bude trvat, závisí také na dostupných nástrojích a daném rozpočtu.

v průběhu času byl postup při odhadu softwarových testů prováděn různými procesy za použití různých metodik a nástrojů, které postupem času pokročily ze stejného důvodu.

integrace a práce těchto technik také usnadnily postup průměrování.

typy technik odhadu testování softwaru

existuje mnoho odhadů a technik průměrování obecně, ale budeme se dívat pouze na několik populárních z tohoto článku.

program evaluation and review technique (PERT)

v této technice jsou úkoly rozděleny do 3 podkategorií, aby se lépe zjistil čas, který má být dokončen, a to;

optimistický scénář-O; v tomto případě se předpokládá, že náklady na trvání, peněžní prostředky a zdroje týkající se projektu jsou na nejvyšší optimální úrovni. To znamená, že jednotliví členové týmu QA pracují kolektivně co nejlépe, držet se času, bez tlaku, nepředvídatelný obrat událostí, nebo potřeba znovu provést práci a stále dodávat skvělou práci.

nejpravděpodobnější scénář – M; zde jsou zvažovány všechny věci; s ohledem na známý pracovní scénář a s ohledem na negativní a pozitivní možnosti, položky se odhadují, jak se to s největší pravděpodobností stane.

pesimistický scénář-P; to zvažuje nejnegativnější scénář, který by mohl být. Průměrování bude záviset na předpokladu, že bude nepochybně negativní výsledek, který bude řešen v každé jednotlivé fázi celého testování.

Pros of PERT

  • použití této techniky znamená, že tým pracuje s odhadem, který kontroluje všechny možné úmrtí a odměny na všech frontách.
  • týmy mohou přijít s hodnocením velmi blízkým realitě.
  • připravuje organizace na jakýkoli možný výsledek testu sestavení, když vypočítají každý myslitelný scénář a v případě potřeby se adekvátně připraví na jeho omezení.

nevýhody PERT

  • když se setkáte s větším množstvím testovacích projektů, použití této formy odhadu spotřebuje mnohem více času na podstoupení.
  • existuje vysoká pravděpodobnost, že dojde k nepřesným výpočtům.
  • zde použité hodnoty nejsou nikdy konstantní a mohly by se setkat s mnoha chybami, protože je to jen odhad.

user Case Point (UCP)

kdykoli někdo nebo něco používá a komunikuje s danou aplikací, entita je identifikována jako herec. Uvedená entita je dokumentována hlavně v neupravitelných váhách případu použití, které ovlivňují kapacitu procesu.

jakákoli komunikace mezi nimi zajistí zapojení všech od akcionářů po jednotlivce v týmu QA prostřednictvím různých sekvencí a definovaných cílů.

více než deset různých agentů ovlivňuje, jak komplikovaná je technická náročnost projektu, a asi osm si na něm vybírá složitou daň. To je v souladu se zjištěními Gustava Karnera.

tato metoda odhadu závisí na výpočtu více variant z takzvaných aktérů, vah případů uživatelů a bodů, které ovlivňují proces, technickou způsobilost a další faktory.

Za prvé, aby zahájili tento proces, budou muset zkontrolovat své příslušné složitosti a ovlivnit proces. Pak se další průměrování provádí použitím jejich vzorců pro výpočet.

po kontrole velikosti projektu určí zúčastnění dobu potřebnou před úplným dokončením procesu. Dva významné způsoby, jak tomu zabránit, jsou;

použitím Karnerovy metody a zvážením každého zkušebního případu jako spotřeby 20 hodin zaměstnanců.

použití času záznamu společnosti pro dokončení projektu, v každém případě pro výpočet statistických průměrů a odhad trvání aktuálního projektu.

UCP= Neupravitelný UCP x Faktor technické složitosti x faktor ovlivňující životní prostředí.

Pros UCP

  • v případě, že potřebujete pracovat předem a plánovat dopředu, pak je tato metoda odhadu pravděpodobně lepší, protože se provádí v počátečních fázích a pomáhá při prořezávání a schvalování velikosti rozpočtu.
  • pomocí některých speciálních nástrojů pro správu je možný automatický výpočet odhadů, což šetří spoustu času pro hodnotící tým a usnadňuje práci.

nevýhody UCP:

  • pokud požadavky na projekt nejsou uvedeny v bodech případu uživatele, to znemožňuje použití této techniky a tým QA bude muset získat jinou metodu.
  • když jsou uvedeny UCP a nejsou dostatečně přesné nebo explicitní, je pravděpodobné, že skončí negativně s odhady daleko od skutečných, protože tato metoda závisí nejen na dávání případových bodů,ale na jasných případech.

struktura rozdělení práce (WBS)

zde se technika odhadu hodnot provádí rozdělením primárního procesu do různých podkategorií. Prediktivní výpočet průměrné doby trvání v každé fázi postupně začíná hrubou prací na jednodušších šaržích, poté absolvováním obtížnosti i úrovně správnosti.

po počátečním procesu vyberte nejvyšší možnou hodnotu, na kterou jste dorazili, sečtěte je a získejte konečnou hodnotu, odhadněte úsilí a čas potřebný pro každý úkol.

Pros WBS

  • zjevnou výhodou této metody je, že usnadňuje rozpoznání každé minuty a potřebných detailů při rozdělení práce na menší bity. To znamená, že práce se provádí
  • je to vždy důkladné a transparentní, protože závěry jsou uvedeny v tabulce pro stejný účel a snadnější sledování.

nevýhody WBS:

  • tato povaha obvykle vyžaduje tření mysli a členů týmu a zúčastněných stran, aby využili své vnější zkušenosti.
  • změny ve specifikacích a potřebách klientů mohou vést k zastaralému a potřebnému týmu, aby se na to podíval a úplně přehodnotil.

Delphi metoda

Delphi metoda je velmi populární mezi testovacími týmy po celém světě. Údaje od dobrovolných účastníků jsou shromažďovány a pečlivě zkoumány několik a, v žádném konkrétním pořadí, dospět k dohodnutému závěru.

každá fáze vyšetření přináší novou nebo vylepšenou zpětnou vazbu dat, která pouze zvyšuje zdokonalení konečných zjištění s velmi zaslouženou důvěrou.

obvykle se tým skládá z ne více než deseti jednotlivců, kteří se setkávají, aby diskutovali o kritických vlastnostech projektu, které se chystají zahájit, a vyjádřili své názory na možné trvání projektu.

následně se tým znovu setkává a tentokrát jsou sdíleny názory od prvního rande. To dává členům další úhel přístupu k projektu. Názory však nejsou označeny jejich navrhovateli.

když členové týmu procházejí touto fází, budou mít další jednomyslnou diskusi a seskupení názorů přináší nový úhel vnímání.

to bude pokračovat, dokud se všichni nedohodnou na stejné stránce. Ačkoli obvyklý způsob, jak dělat metodu Delphi, tento formulář může být vylepšen tak, aby vyhovoval jeho potřebám a schopnostem.

Pros of DELPHI

  • vzhledem k tomu, že zde nejsou nutné žádné jedinečné vzorce nebo vybavení, je nejjednodušší ze šarže, kterou musí každý tým podstoupit, vše, co je potřeba, Jsou specifikace klienta a dobré jít.
  • odhad je velmi blízký přesnosti, protože v procesu setkání a sdílení nápadů je zvažováno mnoho profesionálních hledisek.

nevýhody DELPHI

  • jak snadné může být podstoupit, může to trvat hodně produktivního času, protože častěji než ne.
  • je náročné přijít s jedním komplexním odhadem po první várce schůzek a sdílet názory, takže to obvykle trvá několik.
  • i po spotřebování tolika času nelze výsledky recyklovat. Takže pro každý projekt, který má být spuštěn, je proces zahájen znovu s novými požadavky.

abych to shrnul

tento blogový příspěvek přezkoumal čtyři typy technik odhadu v testování softwaru a jak působivé jsou při plánování přiměřeného rozpočtu na testování.

po úspěšném odhadu můžete s jistotou říci správný přístup k outsourcingu vašich projektů společnostem QA?

zde je článek o tom, jak vybrat nejlepší přístup pro outsourcing QA.

řekněte nám, kterou z těchto taktik odhadu testování byste implementovali a jaký byl váš pohled?

Leave a Reply

Vaše e-mailová adresa nebude zveřejněna.