Menu

Jak zkontrolovat dokument SRS a vytvořit testovací scénáře - školení testování softwaru na živém projektu - 2. den

how review srs document

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

Toto je druhý tutoriál v našem „Bezplatné školení o testování softwaru online na živém projektu“ série. Pokud jste zde nový, podívejte se na první úvodní výukový program: Kompletní školení v oblasti testování softwaru na živém projektu.

Pojďme se nyní podívat na podrobnou analýzu toho, jak se postup SRS děje, co je to, co musíme z tohoto kroku identifikovat, jaké předběžné kroky musíme udělat, než začneme, jaké jsou výzvy, kterým bychom mohli čelit atd podrobným způsobem.

Jak zkontrolovat dokument SRS a vytvořit testovací scénáře_

Fáze návrhu SDLC:

Další fází SDLC je „Design“ - to je místo, kde jsou funkční požadavky převedeny do technických detailů. Do tohoto kroku jsou zapojeny vývojové, designové, environmentální a datové týmy. Výsledkem tohoto kroku je obvykle dokument technického návrhu - TDD.

Vstupem je dokument SRS jak pro vytvoření TDD, tak pro tým QA, který má začít pracovat na aspektu QA projektu - což je revize SRS a identifikace cíle testu.

Co se naučíte:

Co je to SRS Review?

SRS je dokument vytvořený vývojovým týmem ve spolupráci s obchodními analytiky a týmy pro prostředí / data. Po dokončení bude tento dokument obvykle sdílen s týmem QA prostřednictvím schůzky, kde je uspořádán podrobný návod.

Někdy pro již existující aplikaci možná nebudeme potřebovat formální schůzku a někoho, kdo nás provede tímto dokumentem. Možná bychom měli potřebné informace, abychom to mohli udělat sami.

Recenze SRS není nic jiného než projít dokumentem specifikace funkčních požadavků a pokusit se pochopit, jak bude vypadat cílová aplikace.

Formální formát a ukázka jsme s vámi všichni sdíleli v předchozím článku. To nutně neznamená, že všechny SRS budou takto zdokumentovány přesně. Vždy forma je druhotná vůči obsahu .

Některé týmy se rozhodnou napsat seznam s odrážkami, některé týmy zahrnou případy použití, některé týmy zahrnou ukázkové snímky obrazovky (například dokument, který jsme měli) a některé pouze popíšou podrobnosti v odstavcích.

Předběžné kroky k přezkoumání specifikace softwarových požadavků

Krok 1) Dokumenty procházejí několika revizemi, takže se ujistěte, že máme správnou verzi odkazovaného dokumentu, SRS.

Krok 2) Stanovte pokyny ohledně toho, co se od každého člena týmu očekává na konci kontroly. Jinými slovy, rozhodněte se, jaké výstupy se od tohoto kroku očekávají - výstupem tohoto kroku je obvykle identifikace testovacích scénářů. Testovací scénáře nejsou nic jiného než jednořádkové ukazatele „co otestovat“ pro určité funkce.

Krok č. 3) Stanovte také pokyny, jak má být tento výstup prezentován - myslím šablonu.

Krok č. 4) Rozhodněte se, zda každý člen týmu bude pracovat na celém dokumentu, nebo si jej rozdělte mezi sebe. Důrazně doporučujeme, aby si každý přečetl vše, protože to zabrání koncentraci znalostí u určitých členů týmu.

Ale v případě obrovského projektu s dokumenty SRS běžícími téměř na 1000 stránkách je nejpraktičtější přístup rozbití modulu dokumentu a jeho přiřazení jednotlivým členům týmu.

Krok č. 5) Kontrola SRS také pomáhá lépe porozumět, pokud existují nějaké specifické předpoklady vyžadované pro testování softwaru.

Krok č. 6) Jako vedlejší produkt je identifikován seznam dotazů, u nichž je obtížné porozumět některým funkcím, nebo pokud je třeba zahrnout více informací do funkčních požadavků nebo pokud se v SRS vyskytnou chyby.

Co musíme začít?

  • Správná verze dokumentu SRS
  • Jasné pokyny, kdo bude na čem pracovat a kolik času mají.
  • Šablona pro vytvoření testovacích scénářů.
  • Další informace o tom, na koho se obrátit v případě dotazu nebo koho nahlásit v případě nesrovnalosti v dokumentaci

Kdo by tyto informace poskytl?

Vedoucí týmů jsou obecně odpovědní za poskytnutí všech položek uvedených v části výše. Vstupy členů týmu jsou však vždy důležité pro úspěch celého tohoto úsilí.

Vedoucí týmu se často ptají - Jaký druh vstupů? Nebylo by lepší přiřadit určitý modul někomu, kdo se o něj zajímá, než členovi týmu, který tomu tak není? Nebylo by hezké rozhodnout o cílovém datu na základě názoru týmu, než rozhodnout o nich? Pro úspěch projektu jsou také důležité šablony.

Obecně platí, že šablony mají vyšší míru efektivity, pokud jsou přizpůsobeny pohodlí a pohodlí konkrétního týmu. Je tedy třeba poznamenat, že tým vede více než cokoli jiného. Zapojení vašeho týmu do každodenních rozhodnutí je zásadní pro hladký průběh projektu.

Je šablona vyžadována pro testovací scénáře?

Proč šablona pro testovací scénáře - nestačí, když vytvoříme pouze seznam?

Určitě je. Softwarové projekty však nejsou přehlídky „jednoho člověka“. Zahrnují týmová práce .

Představte si tým 4 osob, pokud se každý z nich rozhodne zkontrolovat každý jeden modul specifikace softwarových požadavků. Člen týmu A vytvořil seznam na list papíru. Člen týmu 2 použil list aplikace Excel. Člen týmu 3 použil poznámkový blok. Člen týmu 4 použil slovo doc. Jak konsolidujeme veškerou práci odvedenou na konci dne?

Jak také můžeme rozhodnout, který z nich je standardem a jak můžeme říci, co je správné a co ne, pokud bychom nejprve nevytvořili pravidla?

To je to, co je šablona: Sada pokynů a dohodnutý formát pro jednotnost a shodu pro celý tým.

Jak vytvořit šablonu pro scénáře QA Test?

Šablony nemusí být komplikované nebo nepružné.

Vše, co musí být, je efektivní mechanismus k vytvoření užitečného artefaktu testování. Něco jednoduchého, jako je ten, který vidíme níže:

šablona testovacích scénářů

Záhlaví této šablony obsahuje prostor potřebný k zachycení základních informací o projektu, aktuálním dokumentu a odkazovaném dokumentu.

Níže uvedená tabulka nám umožní vytvořit testovací scénáře. Zahrnuty jsou sloupce:

Sloupec č. 1) ID testovacího scénáře
Každá entita v našem procesu testování musí být jednoznačně identifikovatelná. Každému testovacímu scénáři tedy musí být přiřazeno ID. Je třeba definovat pravidla, která je třeba dodržovat při přiřazování tohoto ID.

V zájmu tohoto článku se budeme řídit konvencí pojmenování jako TS (předpona, která znamená Testovací scénář) následovaná znakem „_“, názvem modulu MĚ (Modul Moje informace projektu Orange HRM) následovaný ‚_‘ a poté podsekcí ( Například, MĚ pro modul Moje informace, P pro fotografii atd.) následované sériovým číslem. Příklad by mohl být: „TS_MI_MIM_01“.

Sloupec č. 2) Požadavek
Pomáhá nám, že když vytváříme testovací scénář, měli bychom být schopni jej namapovat zpět do části dokumentu SRS, odkud jsme jej vybrali. Pokud mají požadavky ID, mohli bychom je použít. Pokud tomu tak není, čísla sekcí nebo dokonce čísla stránek dokumentu SRS, odkud jsme zjistili, budou splnitelné požadavky.

Sloupec č. 3) Popis testovacího scénáře
Jedna linka určující „co otestovat“. Také bychom to označili jako testovací cíl.

Sloupec č. 4) Důležitost
To má poskytnout představu o tom, jak důležitá je určitá funkčnost pro AUT. K tomuto poli lze přiřadit hodnoty jako vysoká, střední a nízká. Můžete také zvolit bodový systém, například 1–5, z nichž 5 je nejdůležitější a 1 méně důležitý. Ať už toto pole může mít jakoukoli hodnotu, musí být předem rozhodnuto.

Sloupec č. 5) Počet testovacích případů
Hrubý odhad, kolik jednotlivých testovacích případů bychom mohli nakonec napsat, že jeden testovací scénář. Například, Chcete-li otestovat přihlášení - zahrnujeme tyto situace: Opravte uživatelské jméno a heslo. Opravte uživatelské jméno a nesprávné heslo. Správné heslo a nesprávné uživatelské jméno. Ověření funkce přihlášení bude mít tedy za následek 3 testovací případy.

Poznámka: Tuto šablonu můžete podle potřeby rozšířit nebo odstranit pole.

Například , můžete přidat „Zkontrolováno“ do záhlaví nebo odebrat datum vytvoření atd. Také v tabulce můžete zahrnout pole „Vytvořeno“ k označení testera odpovědného za určitý scénář testu nebo odebrat „Ne. sloupce Testovací případy “. Volba je na tobě. Jděte s tím, co funguje nejlépe pro celý tým.

Podívejme se nyní na náš dokument Orange HRM SRS a vytvořme testovací scénáře

Profesionální tip: podívejte se na obsah vzorku SRS, který jsme poskytli v 1. tutoriálech, abyste získali dobrou představu o tom, jak bude jakýkoli dokument plynout a kolik práce to může zahrnovat.

Sekce 1 je účelem dokumentu. Žádné testovatelné požadavky.

Oddíl 2.1 : Přehled projektu - Publikum - žádné testovatelné požadavky.

Oddíl 2.2 : Hardware a hostování - Tato část hovoří o tom, jak bude hostován web Orange HRM. Je tato informace pro nás, testery, důležitá? Odpověď je Ano a Ne. Ano, protože když testujeme, musíme mít prostředí podobné prostředí v reálném čase.

To nám dává představu o tom, jak to musí být. Ne, protože to není testovatelný požadavek - jakýsi předpoklad pro to, aby testování proběhlo.

Část 3: Zde je přihlašovací obrazovka a podrobnosti o typu účtu, který musíme mít pro vstup na web. Toto je testovatelný požadavek. Musí to tedy být součástí našich testovacích scénářů.

Přečtěte si dokument testovacích scénářů, kde byly přidány testovací scénáře pro několik částí SRS. Pro praxi prosím přidejte ostatní scénáře podobným způsobem. Jdu však přímo k části 4 dokumentu.

Část 4: Estetické / HTML požadavky a směrnice - Tato část nejlépe vysvětluje, jak některé požadavky nemusí dávat smysl testovacímu týmu v době kontroly SRS, ale tým by si je měl poznamenat jako všechny testovatelné požadavky.

příkaz cut v unixu s příklady

Jak je otestovat a pokud potřebujeme konkrétní nastavení / pomoc jakéhokoli týmu k jeho ověření, jsou podrobnosti, které v tuto chvíli možná neznáme. Ale učinit je součástí našeho rozsahu testování je prvním krokem k zajištění toho, že nám nebudou chybět.

Ukázkové testovací scénáře pro aplikaci OrangeHRM: (kliknutím obrázek zvětšíte)

šablona testovacích scénářů

=> Přečtěte si a stáhněte dokument Testovací scénáře Pro více informací.

Některá důležitá pozorování týkající se kontroly SRS

# 1) Žádné informace nesmí zůstat nezakryté.
#dva) Proveďte analýzu proveditelnosti ohledně toho, zda je určitý požadavek správný či nikoli, a také toho, zda jej lze testovat či nikoli.
# 3) Pokud neexistuje samostatný výkon / zabezpečení nebo jiná forma testovacích týmů - je naší prací zajistit, aby byly brány v úvahu všechny nefunkční požadavky.
# 4) Ne všechny informace jsou zaměřeny na testery, takže je důležité pochopit, co je třeba poznamenat a co ne.
# 5) Důležitost a ne. testovacích případů pro testovací scénář nemusí být přesné a mohou být vyplněny přibližnou hodnotou nebo mohou být prázdné.

Shrnuto, výsledky kontroly SRS vedou k:

  • Seznam testovacích scénářů
  • Zkontrolovat výsledky - chyby dokumentace nebo požadavku zjištěné statickým procházením / ověřováním dokumentu SRS
  • Seznam otázek pro lepší porozumění - v případě jakýchkoli
  • Předběžná představa o tom, jak má testovací prostředí vypadat
  • Identifikace rozsahu testu a hrubá představa o tom, kolik testovacích případů bychom nakonec mohli mít - kolik času tedy potřebujeme na dokumentaci a případné provedení.

Důležité poznámky:

# 1) Scénáře testování nejsou externími výstupy (nesdílenými s Business Analysts nebo Dev týmy), ale jsou důležité pro interní spotřebu QA. Jsou naším prvním krokem k cíli 100% pokrytí testu. Testovací scénáře, jakmile jsou dokončeny, projdou peer review a po dokončení jsou všechny konsolidovány.

Další podrobnosti o kontrole dokumentů QA najdete v článku: Jak provádět kontroly dokumentace k testu v 6 jednoduchých krocích.

#dva) Mohli bychom použít nástroj pro správu testů jako HP ALM nebo qTest k vytvoření testovacích scénářů. Vytváření testovacích scénářů v reálném čase je však manuální činností. Podle mého názoru je to pohodlnější ručně. Jelikož je to krok 1, ještě nemusíme vynášet velké zbraně. Nejlepším způsobem, jak na to, jsou jednoduché listy aplikace Excel.

Dalším krokem k této sérii je to - budeme pracovat na vytváření testovacích případů a dostaneme se dále do fáze návrhu testu. Před tím se také dostaneme do - Co je plánování testů?Kde zapadá do celého projektu QA? Jako vždy, pracujte s námi pro dosažení nejlepších výsledků.

QA Training Day 3: Jak psát dokument SRS od nuly.

Své dotazy a komentáře prosím nechte přicházet. Vážíme si vaší čtenářské zkušenosti!

Doporučené čtení

^