context driven testing
7 základních principů kontextového testování s příkladem:
jaká aplikace vám umožňuje stahovat videa z YouTube
Když jedu na letiště, obvykle se vydám po dálnici, která mě tam dostane za minimální čas a vyhne se mýtnému. Ale ten den jsem se vydal na delší místní silniční trasu s mýtným. Protože jsem chtěl pár minut navíc s mým přítelem na cestě, který cestoval velmi dlouhou vzdálenost, aby strávil víkend s naší rodinou. Normální nejhorší volba se v tomto případě ukázala jako nejlepší.
Ale zvažte to.
Co kdybych měl málo plynu?
Co kdybych měl nedostatek peněz?
Zvolil bych jinou možnost. Proč? Kontext.
(obraz kredit )
Když se rozhodujete na základě, jedná se o kontextové rozhodnutí:
- Zúčastnění lidé
- Okolnosti
- Cíle
- Dostupné možnosti
- Emoce atd.
Co je to kontextové testování?
Kontextové testování je posun v myšlení (neboli škola testování) vyvinutý Cem Kanerem, Jamesem Bachem a Bretem Pettichordem. Podrobnosti o tom najdete v jejich slavné knize: Poučení z testování softwaru .
Existuje sedm základních principů. Z jejich knihy jsou přímo vybrány následující položky:
# 1) Hodnota jakékoli praxe závisí na jejím kontextu.
#dva) Existují osvědčené postupy v kontextu, ale neexistují žádné osvědčené postupy.
# 3) Lidé, kteří spolupracují, jsou nejdůležitější součástí kontextu každého projektu.
# 4) Projekty se časem rozvíjejí způsoby, které často nelze předvídat.
# 5) Produkt je řešením. Pokud problém není vyřešen, produkt nefunguje.
# 6) Dobré testování softwaru je náročný intelektuální proces.
# 7) Pouze na základě úsudku a dovedností, uplatňovaných ve spolupráci na celém projektu, jsme schopni dělat správné věci ve správnou dobu, abychom mohli efektivně testovat naše produkty.
Nebudu vysvětlovat každý z nich, protože to za nás dělá sami odborníci zde .
Jednoduše provedu vysvětlení založené na scénáři mého přístupu k testování na základě kontextu.
Příklad testování na základě kontextu:
Řekněme, že zahajuji testovací projekt - Projekt A, který zahrnuje end-to-end testování pro webovou aplikaci.
Jaká by byla moje strategie?
Podle standardních procesů to bude sled událostí:
- Shromážděte požadavky a pochopte aplikaci
- Vytvořte testovací plán
- Vytvoření testovací dokumentace - testovací scénáře, testovací případy, matice sledovatelnosti atd.
- Nechte zkontrolovat a schválit veškerou dokumentaci
- Nastavte prostředí QA a testovací data
- Proveďte provedení testu
- Vytvářejte hlášení o chybách
- Generujte a sdílejte zprávy o stavu provádění testů atd.
Pokud si položím otázku: „Jak jsem se rozhodl, že to je to, co musím dělat?“ Moje odpověď by byla, osvědčené postupy, standardy QA, odvětvové pokyny, výchozí hodnoty minulých zkušeností atd., Že?
Opakuji, co mě učili dělat nebo co jsem viděl dělat ostatní.
Je s tím něco špatně? Vůbec ne. To by mohlo fungovat také, protože pro tento přístup existuje určitý pocit opakovatelnosti a časově ověřené. Připravuje však cestu k optimálním výsledkům?
Pochybný. Proč?
Protože u každého projektu se budete zabývat různými okolnostmi:
- Zdokumentované vs. nezdokumentované požadavky
- Úzce fungující vs. geograficky distribuované týmy
- Vývojové a testovací týmy patřící do stejné společnosti vs. konkurence
- Dostatečný čas vs. Napjaté plány
- Složení vašeho týmu - Nováčci vs. zkušení. Vyškolení vs. netrénovaní.
- Dostupnost nástrojů - použití ručního vs. testovacího nástroje pro správu
- Typ projektu - Vyžaduje přísné dodržování pravidel (FDA nebo bankovnictví) vs. experimentální (například sociální média)
- Technologie projektu.Například:netestovali byste web a aplikaci pro Windows stejným způsobem
- Požadavky klientů (Někteří chtějí denní podrobné zprávy, jiní chtějí jen to nejdůležitější)
- Sledovaný proces (agilní vs. tradiční, skriptované vs. průzkumné testování)
Tento seznam není vyčerpávající a víte stejně dobře jako já, že pro každý projekt existuje mnoho proměnných.
Kontextové testování je, když necháte tyto okolnosti rozhodnout o vašich testovacích postupech, technikách a dokonce i definicích, spíše než standardních, průmyslově vnímaných “ osvědčené postupy' .
Řekněme, že toto jsou podrobnosti, se kterými pracuji pro projekt A:
- Pracuji s týmem 5-4 nováčků a 1 zkušeného testera.
- Nemám žádné zdokumentované požadavky.
- Můj tým je v Indii a vývojový tým v USA, takže pracujeme v opačných časových pásmech.
- Klient chce denní podrobnou zprávu o stavu
- Používáme webový nástroj pro sledování chyb, jako je Mantis nebo Bugzilla, a to je vše, co máme.
- Musím udělat 2 kola testování za 10 dní s 3 dny pro testovací dokumentaci
Zde je hrubý herní plán:
1) Vzhledem k tomu, že v týmu je spousta nováčků, potřebujeme spoustu vzájemných hodnocení.
dva) Potřebujeme také minimálně 2 diskusní setkání s týmem BA a Dev. To musí být formální, protože týmy jsou umístěny jinde a pro mne existuje malý prostor, abych k nim chodil s otázkami.
3) Jedná se o agresivní časovou osu testování dokumentace. Čím více dokumentace napíšeme, tím více recenzí potřebujeme, což odpovídá více času. Budeme tedy muset vést minimální dokumentaci. Budeme dokumentovat jen hlavní End-to-End TC a zbytek bude zkoumány průzkumně .
4) Denní zprávy o stavu během provádění testu budou vytvářeny a zasílány EOD každý den.
5) Většina testů je průzkumná, proto doporučte čas, abyste se pokusili udělat stručný přehled každého provedeného testu. Tímto způsobem víme, co je testováno a co ne.
6) Vady budou hlášeny do aplikace Mantis v reálném čase. Protože tým pracuje v jiném časovém pásmu, možná bude muset počkat celý den, než se ozve tým QA, pro případ, že by potřeboval vysvětlení. Proto uspořádejte každodenní hovor s pohodlným týmem, kde tým QA předvede opakování chyb. Tímto způsobem nebude třeba čekat a sledovat.
A tak dále.
Datum vydání náhlavní soupravy pro virtuální realitu pro Xbox
Jakmile budete mít celkovou strategii, napište základní testovací plán vysvětlující tyto body. Nyní jste připraveni dostat se do testovacího projektu po pečlivém zvážení a vytvoření strategie úspěchu na zakázku.
Celkem:
Tohle je Kontextové testování; učinit z vašich okolností (nikoli standardů) primární vstupy a vlivy pro vaši testovací strategii. Vyzývá nás, abychom se rozhlíželi a brali v úvahu vše kolem sebe.
Osobně jsem do tohoto konceptu zamilovaný, protože testovací postupy jsou příliš často vnímány jako rigidní a založené na napodobování. Někdo to udělal a byl úspěšně, takže to udělám také. To je druh obrazu, který děsí lidi, aby se pokusili zůstat v testovací kariéře.
Existuje však spousta prostoru pro kreativní myšlení, analytické dovednosti a rozhodování. Chcete-li se dozvědět více, přečtěte si o tomto tématu odkazy výše.
Šťastné kontextové testování
Doporučené čtení
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Testování stahování e-knih Primer
- 20 jednoduchých otázek ke kontrole softwaru Testování základních znalostí (online kvíz)
- 7 základních tipů pro testování vícejazyčných webových stránek
- Testování zátěže s výukovými programy HP LoadRunner
- Rozdíl mezi stolním počítačem, klientským serverem a webovým testováním
- Co je to gama testování? Fáze závěrečného testování
- Co je testování shody (testování shody)?