exploratory testing vs scripted testing
Skutečné výhody průzkumného testování:
Testování softwaru bylo tradičně velmi rigidní činností, ale v posledních letech došlo k posunu od testování založeného na skriptech. Průzkumné testování , který je více založen na kontextu, se dostal do popředí. Je to proto, že dává testerům větší svobodu při využívání jejich dovedností a znalostí a dává jim odpovědnost za optimalizaci hodnoty jejich vlastní práce.
Ne každý je prodáván za hodnotu průzkumného testování. Pociťovaný nedostatek formálnosti a důraz na osobní odpovědnost mohou nastavit vyzvánění poplašných zvonů. Tato obava je však do značné míry založena na nesprávné interpretaci průzkumného testování. Nejde o vyhazování pravidel z okna a náhodné testování, je to ve skutečnosti velmi strukturované a systematické. A je také vysoce efektivní.
Skeptici chtějí konkrétní důkaz, že to dělá víc než zlepšování morálky testeru. Proto jsme se rozhodli provést studii, která by zkoumala kontextové průzkumné testování přímo proti testovacímu přístupu založenému na skriptu. Výsledky byly velmi zajímavé, jak se chystáte zjistit.
Co se naučíte:
stáhnout všechny skladby z youtube playlistu
- Kontextové (průzkumné testování) vs. skriptované testovací týmy
- Co to znamená?
- Závěr
- Doporučené čtení
Kontextové (průzkumné testování) vs. skriptované testovací týmy
Dva týmy, dva přístupy:
Začali jsme rozdělením testerů do dvou týmů po třech. Testeři v každém týmu měli stejné srovnatelné znalosti aplikací. Stejné definice pro závažnost závady (hlavní, vedlejší) byly stanoveny pro oba týmy. Oba týmy jim doručily stejné sestavení aplikace. Jeden tým („skriptovaný“) by použil tradiční testovací přístup založený na skriptu a druhý tým („průzkumný“) by přijal přístup založený na kontextu testování. Testovací činnosti by byly rozděleny do dvou fází po třech dnech.
Tým založený na scénáři identifikovalo pět obchodních pracovních toků k testování a vygenerovalo 15 testovacích případů. Rozsah testovacích případů byl omezený, takže testeři neměli žádnou svobodu zkoumat mimo hranice skriptu.
Průzkumný tým vytvořil dva vizuální myšlenkové mapy jeden, který identifikoval pokrytí testu a testovací listiny, a druhý pokrývající komponenty / moduly produktu. Tento proces vytvořil celkem 24 testovacích chart. Definované charty byly na vysoké úrovni a umožňovaly kontextovou interpretaci, což rozšiřovalo rozsah testovací relace pro testery.
Fáze 1:
Skriptovanému týmu se podařilo dokončit 6 testovacích případů za přidělené tři dny. V té době hlásili 6 hlavních závad.
Průzkumnému týmu se podařilo dokončit 13 testovacích relací v rozmezí od 30 minut do 180 minut. Hlásili 10 závažných závad a 5 menších závad.
Je zajímavé, že průzkumný tým nahlásil všechny vady, které skriptovaný tým nahlásil.
Fáze 2:
Skriptovaný tým se podařilo dokončit 9 testovacích případů tentokrát. Hlásili se 10 hlavních vad a 8 drobných vad .
Průzkumný tým dokončil 18 sezení. Hlásili se 14 hlavních vad a 5 drobných vad.
Ve fázi 2 skriptovaný tým nahlásil 2 hlavní a 1 menší vadu, kterou průzkumný tým nenalezl, ale průzkumný tým nahlásil 3 hlavní a 1 menší vadu, kterou skriptovaný tým nenahlásil.
To nebere v úvahu relativní složitost pracovních toků, které si testeři mohli vybrat v rámci těchto relací a testovacích případů, ale přesto můžeme vyvodit některé zajímavé závěry.
Co to znamená?
Ukázalo by se, že průzkumný přístup a odpovědnost a flexibilita, které přináší, vede k efektivnější formě testování. Je možné pokrýt více základů vývojem a přizpůsobením vašich testovacích chart v průběhu testovacích relací na základě toho, co má smysl v kontextu. Tato svoboda chybí při testování založeném na skriptu a může zabránit zjišťování defektů.
jak otevřít soubor SWF v systému Windows 7
Pevným přilepením ke skriptům vznikají opotřebované cesty a všechny vady odhalíme pouze odchylkou od těchto cest. Jak již několikrát zmínili vedoucí myšlenek v testovací komunitě: „Pokud si představíte produkt jako pole nášlapných min a každá nášlapná mina je vadou, pak je celkem jasné, že šlapání stejnou cestou znovu a znovu není způsob, jak je najít Všechno.'
Nakonec žádný z přístupů nebyl dokonalý, protože každý tým hlásil závady, které druhý tým nezjistil, i když průzkumný tým celkově hlásil více.
Realisticky to může znamenat, že správný přístup, pokud jde o to, aby se co nejvíce přiblížil „minimálním“ defektům, bude kombinací obou. Existuje však mnoho výhod kontextově orientovaný přístup které hovoří v jeho prospěch. Vyžaduje méně času na přípravu, méně dokumentace, dříve identifikuje problémy a vyzývá testery, aby využili analytické dovednosti a deduktivní uvažování. Získají hlubší a důkladnější porozumění produktu a skutečně působí jako obhájci koncového uživatele.
Závěr
Konečný výsledek ukazuje, že průzkumné testování vede k hlášení více defektů před uvedením do provozu, což má za následek lepší produkt dodaný týmem a nakonec více spokojených / splněných testerů což jsou všechny žádoucí výsledky, ať se na to podíváte jakkoli.
o autorovi
Mush Honda je ředitelem QA Technologie KMS , poskytovatel IT služeb v celém životním cyklu vývoje softwaru s kancelářemi v Atlantě v GA a Ho Či Minově městě ve Vietnamu. Předtím byl testerem ve společnostech Ernst & Young, Nexidia, Colibrium Partners and Connecture. Služby KMS zahrnují správu aplikací, testování, podporu, profesionální služby a rozšiřování zaměstnanců.
Souhlasíš? Neváhejte zveřejnit své komentáře a dotazy níže.
Výukový program PREV | DALŠÍ výukový program č. 4: Průzkumné testování s HP Sprinter
Doporučené čtení
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Některé zajímavé otázky týkající se testování softwaru
- Úloha pomocníka QA při testování softwaru
- Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
- Výběr testování softwaru jako vaší kariéry
- Práce na volné noze se softwarem pro testování technického obsahu Writer
- Jak používat prohlídky k zajištění úplného a důkladného průzkumného testování
- Testování stahování e-knih Primer