Výsledky založené na testování - Results based testing

Tento článek má několik problémů. Prosím pomozte vylepši to nebo diskutovat o těchto problémech na internetu diskusní stránka. (Zjistěte, jak a kdy tyto zprávy ze šablony odebrat) tento článek potřebuje další citace pro ověření. Prosím pomozte vylepšit tento článek podle přidávání citací ke spolehlivým zdrojům. Zdroj bez zdroje může být napaden a odstraněn. Najít zdroje: „Testování na základě výsledků“  – zprávy  · noviny  · knihy  · učenec  · JSTOR (Červenec 2015) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) tento článek potřebuje víc odkazy na další články pomoci integrovat to do encyklopedie. Prosím pomozte vylepšit tento článek přidáním odkazů které jsou relevantní pro kontext v rámci stávajícího textu. (Červenec 2015) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) tento článek je sirotek, jako žádné další články odkaz na to. Prosím zavést odkazy na tuto stránku z související články; zkuste Najít odkaz nástroj pro návrhy. (Září 2015) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

Testování na základě výsledků je Obchodní model pro testování softwaru. Tento obchodní model se skládá z alternativy cenový systém který umožňuje společnostem platit za hmyz které jsou detekovány, namísto času stráveného na projektu.

Popis

„Testování na základě výsledků“ (RBT) je alternativní cenový systém pro testování softwaru, který umožňuje společnostem platit za zjištěné chyby, místo za čas strávený na projektu. To bylo přijato v reakci na nespokojenost, kterou klienti vyjádřili k cenové struktuře používané většinou testovacích společností, a vedlo to k vyšší spokojenosti zákazníků a lepší přesnosti při detekci chyb.

Testování na základě výsledků obvykle zahrnuje tři prvky:[1]

1. Rozsah práce
2. Smluvní SLA
3. Cenový mechanismus

RBT se obvykle používá, když je část nebo celý proces testování softwaru zadán externě třetí straně a základní smluvní SLA společně s mechanismem stanovení cen stanoví přesnou platbu provedenou na každé úrovni SLA. Cenovým mechanismem může být flexibilní sazba pro každou úroveň SLA nebo mechanismus Penalty / odměny, vše s cílem vytvořit pobídku pro dodavatele testování ke splnění stanovených obchodních cílů (výsledků). RBT však může (a mělo by) být použito také pro interní testovací týmy, i když v takových případech je obtížnější implementovat mechanismus pokuty / odměny. období mohou sloužit jako základ pro cíle následujícího období.

Používání

Několik společností pro testování softwaru využívá tento přístup, včetně QualiTest, kteří se do značné míry spoléhají na úspěch, se kterým se setkali při používání tohoto modelu.

QualiTest uvádí, že testování založené na výsledcích přineslo výhody z následujících důvodů:

• Poskytněte poskytovateli testování finanční pobídky ke splnění obchodních cílů zákazníka
• Poskytněte poskytovateli testování finanční pobídky k inovaci a zlepšení procesu v souladu s obchodními cíli zákazníka a rozloží finanční riziko mezi obě strany
• Poskytuje rámec pro neustálé zlepšování
• Měří výkon poskytovatele testů.
• Poskytuje zákazníkům flexibilitu při rozšiřování nebo snižování testování v souladu s jeho obchodními potřebami.

Při hodnocení úrovně testování by mělo být změřeno několik klíčových indikátorů procesu (KPI). Hlavní důraz by měl být kladen na dvě hlavní otázky:

1. Jaké procento vad by mělo být zjištěno testováním?
2. Jaké jsou náklady vynaložené na dosažení výše uvedeného cíle?

Většina organizací nedokáže měřit tyto dva KPI a nedokáže poskytnout přesný přehled o kvalitě a efektivitě testování.

K měření procenta defektů zjištěných testováním (typ testu KPI pokrytí vs. KPI uniklých defektů) by organizace měla využít následující proces:

1. Hlášení vad - každá vada nahlášená testovacím týmem by měla být dokumentována v centrálním systému správy vad.
2. Všechny problémy nebo tikety podpory vznesené zákazníky / uživateli systému by měly být dokumentovány v centralizovaném systému. Obvykle tyto informace má tým podpory nebo helpdesku.
3. Každý lístek by měl být vyhodnocen testovacím týmem (někdy tým podpory lístky filtruje a poskytuje pouze lístky, které jsou výsledkem závady).
4. Každý lístek související s vadou by měl mít jeden z následujících stavů:

• Není to závada
• Známá vada
• Nelze najít testováním / nereprodukovatelnost
• Nový defekt

U této metriky se počítají pouze vady posledního stavu (Nová vada).

Výše uvedený proces je nesmírně důležitý v případě, že se organizace snaží zahájit implementaci RBT a neustále zlepšovat efektivitu a účinnost testovacího procesu. Měření pokrytí testem se dělí vydělením množství vad zjištěných poskytovatelem testování množstvím závady zjištěné uživateli systému. Vzhledem k tomu, že kritické vady mají pro organizaci jiný význam než méně závažné vady, je každá vada vynásobena její závažností. Například za předpokladu, že se použije stupnice od 1 do 5, bude kritická vada (závažnost = 5) počítána stejným způsobem jako 5 drobných vad (závažnost = 1).

Počítají se pouze vady zjištěné v určitém období po uvolnění systému (obvykle je to definováno jako 3 - 6 měsíců). Jakmile jsou údaje k dispozici, použije se k výpočtu hodnoty KPI následující vzorec:

(Σ defekty nalezené testováním) / (Σ defekty nalezené testováním + Σ skutečné defekty nalezené uživateli)

Reference

• Zylberman, Ayal. „Testování na základě výsledků“. www.qualitestgroup.com. QualiTest. Citováno 17. července 2015.