Menu

7kroková praktická implementace manuálního testování před vydáním výroby

7 step practical implementation manual testing before production release

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

V předchozím příspěvku této série o ručním testování jsem se pokusil vrhnout co nejvíce světla na základy ručního testování.

Pokud jste to zmeškali, můžete si je přečíst zde .

Doufám, že se vám podařilo dostat vás co nejblíže k odpovědím, které jste hledali.

V takovém případě byste rádi věděli více o praktické implementaci manuálního testování, jak se s ním lépe seznámit a jak v něm skutečně zahájit kariéru?

Tento článek osvětlí všechny tyto aspekty.

Implementace manuálního testování

Začněme.

Co se naučíte:

Cyklus ručního testování

Rozumět Cyklus ručního testování nebo Software Test Life Cycle (STLC), nejprve musíme porozumět životnímu cyklu vývoje softwaru (SDLC), o kterém jsem si jist, že mu již rozumíte.

Lidé na ně odkazují samostatně, ale nejsou si jisti, zda mohou skutečně existovat společně. Jsou navzájem úzce propojeni. Dokonce i tyto cykly mají tolik jejich verzí vytvořených a pohybujících se v internetovém prostoru, liší se hlavně podle toho, který vývojový model je vybrán.

Jako většina svět bude agilní v těchto dnech budu udržovat své věci zjednodušené kolem Agile.

7 praktických manuálních testovacích kroků před vydáním výroby

Tady jdu.

Pamatujte, že mluvím o SDLC i STLC.

# 1) Shromažďování požadavků

Fáze shromažďování požadavků

Obchodní analytik (osoba / tým odpovědný za shromažďování požadavků) požadavky dokumentuje. Dokumentují požadavky, to je vrchol, můžete se soustředit pouze na to. Tam, kde je to zdokumentováno, záleží méně.

Lidé k dokumentování používají cokoli, co jim vyhovuje, ale neomezují se pouze na tradiční platformy jako MS word doc, moderní platformy jako Jira / Rally a nástroje new age jako Trello.

# 2) Požadavek Diskuse / Sdílení

Fáze diskuse o požadavcích

Obchodní analytik by pak měl sdílet zdokumentované požadavky s vývojovým týmem, testovacím týmem a týmem UX (pokud je to nutné). To se obvykle děje prostřednictvím formálního setkání, kde SPOC (Single Point Of Contacts nebo celý tým, záleží) ze všech tří funkcí splňují a chápou celý požadavek.

Ve zdravé pracovní kultuře jsou požadavky diskutovány ze všech úhlů a každý člen schůzky může klást otázky a pochybovat. Po zodpovězení všech otázek a provedení potřebné úpravy požadavku lze tuto fázi považovat za Hotovou. To, co člověk nazývá tímto konkrétním jednáním / krokem a jeho dokumentací, se liší společnost od společnosti.

Další čtení=> Jak zkontrolovat dokument SRS

Po zodpovězení všech otázek a provedení potřebných úprav požadavku lze tuto fázi považovat za Hotovo .

To, co člověk nazývá tímto konkrétním jednáním / krokem a jeho dokumentací, se liší společnost od společnosti.

Například, dokumentace se nazývá nebo se rozpadá jako SRS (Specifikace systémových požadavků), Dokument požadavku, Epic, Uživatelský příběh, Bod příběhu (možná nejmenší jednotka požadavku) atd. Na podobných řádcích se tato schůzka, ve které je sdílen požadavek, nazývá jako Požadavek Diskusní setkání, Grooming, Děrovací setkání atd., Doufám, že to pochopíte?

Stisknutím těchto terminologií si budete vždy pamatovat hlavní myšlenku bez ohledu na různá jména.

Po zveřejnění této schůzky se spustí dva kroky současně, v žádném konkrétním pořadí, viz další dva kroky.

# 3) Navrhování

Vývojový tým začíná s jejich technickým návrhem, jakmile jsou projednány požadavky a pokud neexistují žádné významné nevyřízené body. To, co se děje v této fázi, se u jednotlivých společností liší.

Tato fáze může zahrnovat mimo jiné následující úkoly:

  • Rozhodování o rozvojovém přístupu
  • Příprava projektového dokumentu
  • Návrh vývojových diagramů
  • Odhad úsilí
  • Zjištění dopadu tohoto nového požadavku na jakoukoli existující funkčnost
  • Potřebujete opravit existující data atd.

Tým UX se může také zapojit do této fáze, když dojde ke změně uživatelského rozhraní nebo k vývoji nové obrazovky. Tým UX pomáhá vývojovému týmu a testovacímu týmu s prototypem uživatelského rozhraní pro funkčnost / funkci v diskusi. Může to být dokument Photoshopu, jednoduchý obrázek, prezentace PowerPoint nebo cokoli jiného, ​​díky čemuž vývojový tým pochopí, jak by se obrazovky měly vyvíjet.

Poznámka: V ideálním případě jsou tyto obrazovky nebo alespoň jejich konceptové verze zobrazeny v diskusní relaci Požadavek pouze proto, aby tým pomohl lépe porozumět. Bude označen podle původního požadavku, aby na něj bylo možné kdykoli odkázat.

# 4) Testovací scénář / návrh testovacího případu

Testovací scénář Fáze návrhu

Souběžně s fází projektování začíná testovací tým sestavováním testovacích scénářů a / nebo testovacích případů na základě diskutovaných požadavků. Zda jsou testovací scénáře vždy nejprve zapsány a poté rozděleny do testovacích případů, je něco, co opět není konstantní.

Podle mého názoru, ať už dokumentujete testovací scénáře nebo ne, jsou vždy před testovacími případy. Testovací scénář je vaší odrážkou, můžete říci, že vás povedou k dalšímu podrobnému rozboru. Jakmile je psaní testovacích případů ukončeno, lze je sdílet s vývojovým týmem, aby získali představu o rozsahu testování, a také se mohou ujistit, že vývoj, ke kterému došlo nebo došlo, vyhovuje písemným testovacím případům.

Jakmile je psaní testovacích případů ukončeno, lze je sdílet s vývojovým týmem, aby získali představu o rozsahu testování, a také se mohou ujistit, že vývoj, ke kterému došlo nebo došlo, vyhovuje písemným testovacím případům.

Po napsání testovacích případů se nejlépe nechte zkontrolovat testovacím olovem nebo rovnocenným partnerem z mnoha úhlů, jako například:

  • Pokrytí požadavků
  • Pravopisná gramatika
  • Standardy psaní testovacích případů (nic jiného než šablona, ​​kterou tým / společnost dodržuje)
  • Zpětná kompatibilita
  • Kompatibilita platformy
  • Testování referencí dat
  • Typy cíleného testování atd.

Další čtení=> Psaní testovacích případů z dokumentu SRS

V ideálním případě jsou až po kontrole a potřebných úpravách předány vývojovému týmu.

Když jsem řekl „jakmile skončí psaní testovacích případů“, měl jsem na mysli „všechny testovací případy budou napsány na základě úplné znalosti daného požadavku a možných testovacích scénářů, které byly do té doby odhaleny“. Je téměř nemožné mít 100% pokrytí testovacích případů na první pokus.

Existují defekty, které najdete v náhodných (ale zamýšlených) akcích, v čistě náhodných akcích (testování opic) a v některých vzácných scénářích. Je pravděpodobné, že na několika z nich budete chybět. A někdy vám mohou uniknout i ty velmi základní, koneckonců jste člověk. Ale tady vás může zachránit alespoň dobrý přehled testovacích případů a strukturovaný způsob psaní testovacích případů.

Tester nebo testovací tým častěji přidává do stávajícího bloku stále více testovacích případů, když odkrývají pravdu nebo více přemýšlejí o požadavcích.

Nyní už někteří z vás musí pochybovat o mých znalostech Testování softwaru, protože některé slovo (které se v Testování softwaru stalo jakýmsi standardem) zatím nepoužívám. Testovací plán, že?

Dovolte mi k tomu něco říct. Pevně ​​věřím v potřebu většiny informací, které jsou zmíněny v plánu zkoušek, ale považuji je za diskutabilní zdokumentovat je všechny na stejném místě a učinit je absolutně závaznými.

Každopádně je to celkem samostatné téma k diskusi. Sdílet informace „vyhovuje všem“ je obtížné, ale zkusím to.

Buď vy, vy, se svým testovacím kabelem nebo testovacím kabelem připravujete testovací plán, nebo dokumentujete požadované informace na různých místech.

Další čtení=> Jak psát dokument plánu testu

Informace, které by v této fázi měly být absolutně zmrazeny:

  • Rozsah testování: Požadavek, zpětná kompatibilita, platformy, zařízení atd.
  • Osoba / tým, který se chystá otestovat
  • Odhad zkušebního úsilí
  • Omezení: Veškeré předpoklady nebo omezení přijatá předem.
  • Lidé navíc dokumentují vstupní kritéria, výstupní kritéria, riziko atd., Což si myslím, že ve skutečnosti nemusí zvlášť zmínit, protože by to mělo být spíše normální porozumění.
    • Vstupní kritéria (Kdy začít testovat): Málo se spustí, když je k dispozici testovatelná část funkčnosti pro testování. Několik čekat na testování všech funkcí. Jakmile se zjistí, že základní tok funguje, spustí se testování.
    • Kritéria opuštění (Kdy zastavit): Pokud nejsou žádné blokátory, lze zastavit kritické a závažné (vystavené nárazům) defekty při testování v otevřené fázi. Nebo v polovině cesty, kdy je příliš mnoho závad, kterým čelí testování, mohou příslušné zúčastněné strany zastavit.
    • Riziko : Obchodní riziko nebo funkční riziko, pokud k testování nedojde podle dokumentovaného plánu.

# 5) Fáze vývoje

Fáze vývoje softwaru

Vývojový tým po fázi návrhu začíná skutečným vývojem a testováním jednotek, jakmile jsou hotové s vývojem testovatelných bloků požadavků. Mohou předat funkčnost pro testování v blocích, jakmile je implementována, nebo mohou předat celou funkcionalitu najednou.

V ideálním scénáři proběhne před předáním vyvinuté funkce pro testování formální kontrola kódu a testování v bílé krabici. v ideálním případě by vývojový tým měl kromě požadavků a návrhových dokumentů odkazovat také na testovací případy poskytnuté testovacím týmem.

# 6) Fáze testování

Jak již bylo zmíněno dříve, začátek této fáze se liší společnost od společnosti, tým za týmem.

Testovací tým začíná testovat, buď když je testovatelná (něco, co může být nezávisle testováno) část celého požadavku vyvinuta, nebo když je vyvinut celý požadavek.

otázky a odpovědi na pohovor s obchodními objekty

Dovolte mi v této fázi dále rozvinout a hovořit o důležitých úkolech:

  • Tester / Testovací tým začíná testovacím cyklem (průzkumné testování a provádění písemných testovacích případů) a protokolováním vad
  • Vývojový tým je řeší podle priority.
  • Nové sestavení (kód) je převzato z prostředí, ve kterém probíhá testování
  • Vyřešené vady jsou poté ověřeny testovacím / testovacím týmem a označeny jako opravené
  • Tento cyklus pokračuje, dokud není dosaženo kritérií pro ukončení času.
  • Pamatujte, že podle potřeby jsou vady označeny také jako Neplatné, Duplikovat a lze je také kategorizovat jako Vylepšení.

Další věc, která se liší od společnosti, je, kolik testovacích kol je třeba udělat. Stejně jako v některých případech se první kolo testování děje na malých součástech, jakmile jsou připraveny, a poté, co jsou vyvinuty všechny požadavky, následuje kolo testování end-to-end v jiném prostředí. Ale znovu jsem také slyšel o lidech, kteří provádějí tři řádná úplná testovací kola a čtvrté jako kolo zdravého rozumu / kouře.

První agendou, která stojí za provedením několika testovacích kol, je testování funkčnosti v různých prostředích a druhou za provádění komplexních testů, jakmile budou vyvinuty všechny body příběhu. Zdravé kolo obvykle získává rychlou důvěru, jakmile jsou všechny příběhy ve verzi vyvíjeny a testovány nezávisle.

Přečtěte si podrobné kroky=> Fáze provádění testu

# 7) Recenze obchodního analytika (BA)

Obchodní analytik zkontroluje požadovanou funkčnost buď odkazem na výsledek testu, nebo odkazem na výsledek testu plus hraním s aplikací, aby získal skutečný pocit. Tento krok je opět podroben různým akcím napříč společnostmi.

BA může zkontrolovat rozsah celého vydání najednou nebo po částech. V závislosti na tom samém může tento krok přijít před závěrečným testem zdravého rozumu nebo po posledním kole testování zdravého rozumu testovacím týmem.

U všech uživatelských příběhů / požadavků, které mají být splněny v konkrétním vydání (zásilce), proběhne výše 7 kroků. Jakmile jsou všechny tyto kroky splněny pro všechny požadavky, vydání je považováno za připravené k odeslání.

# 8) Zásilka / uvolnění

Vydání je označeno jako Připraveno k odeslání po úspěšné kontrole obchodním analytikem.

Doporučené čtení=> Testovací proces uvolnění

Typy ručního testování (číst člověk)

Pokud tedy musíme hovořit o celkových typech testování v číslech, pak jsem někde našel konec 100 typů testování s různými názvy . Abych byl upřímný, nejsem dost chytrý, abych pochopil rozdíl mezi všemi těmito typy (zamýšlený slovní hříčka).

Je to přímé a jednoduché: Lidské úsilí a inteligence otestují funkčnost aplikace proti danému požadavku. Dále se dělí na několik typů podle rozsahu a agendy testování. Druhy uvedené v následujícím odstavci.

Dále se dělí na několik typů podle rozsahu a agendy testování. Druhy uvedené v následujícím odstavci.

Pokud to mám dovoleno, dovolte mi promluvit několik řádků lidského testování (které doporučuji každému testeru, aby provedl pouze ruční funkční testování). Nenechte se zmást, podle mého názoru je ruční testování funkcí podmnožinou testování lidí. Protože existuje tolik věcí, které dokáže jen lidská mysl.

Níže je uveden seznam některých populárních a důležitých typů testování, které lze rozdělit na lidské testování:

  • Ruční funkční testování : Lidské úsilí a inteligence otestují funkčnost aplikace proti danému požadavku. Dále se dělí na několik typů podle rozsahu a agendy testování, jako je testování systému, testování jednotek, kouřové testování, testování zdravého rozumu, testování integrace, regresní testování, testování uživatelského rozhraní atd.
  • Testování výkonu : To bude kategorizováno do nefunkčního testování, že? Ale opět je to člověk, kdo to implementuje, ačkoli provedení se provádí buď člověkem, nebo nástrojem. Tester by měl toto testování provést alespoň z hlediska doby odezvy (aby zjistil, zda je to přijatelné), pokud nemá používat žádný nástroj pro testování zátěže a vše.
  • Prohlížeč / Testování kompatibility platformy: Testovaná aplikace by měla vypadat a fungovat podle očekávání (samozřejmě může existovat menší rozdíl v závislosti na enginu prohlížeče) napříč prohlížeči a platformami (nebo zařízeními, pokud se jedná o mobilní aplikaci).
  • Testování použitelnosti : Nejprve mi dovolte souhlasit s tím, že je to samo o sobě obrovské téma, které obvykle vlastní odborníci na testování použitelnosti. Stále věřím, že jako tester bychom měli přinejmenším hlásit nebo zdůrazňovat, pokud zjistíme, že je něco méně použitelného, ​​nebo bychom se měli podělit o svůj názor.
  • Testování zabezpečení : Opět velmi obrovský typ testování a samozřejmě vyžaduje spoustu praktických znalostí. Tester by se měl pokusit naučit a provést alespoň základní testy, jako je manipulace s URL, skriptování napříč weby, vkládání SQL, únos relace atd., V závislosti na dostupných znalostech a kdekoli je to možné.
  • Testování více nájemců: Pokud je vaše aplikace multi-tenant, tj. Jedna instance obsahující data více klientů, pak je toto testování nutností. Toto by mělo být provedeno bez ohledu na výslovnou zmínku v požadavcích. Data jednoho klienta, která se zobrazují druhému, jsou jakýmsi vývojovým a testovacím zločinem.

Poznámka: Výše uvedené pohledy jsou mé osobní pohledy. Doporučuji také, abyste si pro své znalosti prohlédli rozsáhlý seznam typů testování a podle potřeby je sledovali / používali. V průběhu let jsem pochopil, že ať už něco používáte nebo ne, v něco věříte nebo ne, měli byste mít stále nějaké znalosti o široce používaných pojmech ve vašem oboru.

To je pro tuto část vše. Děkuji za přečtení. Sdílejte své názory / zpětnou vazbu v komentářích.

V další a poslední části toho série výukových programů pro ruční testování , Pokusím se vám všem pomoci jakou přípravu byste měli dělat, pokud se chcete dostat do testovacího pole a jaké jsou možné způsoby, jak se tam dostat.

Doporučené čtení

^