Menu

Ako skontrolovať dokument SRS a vytvoriť testovacie scenáre - školenie o testovaní softvéru na živom projekte - 2. deň

how review srs document

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Toto je druhý návod v našom „Bezplatné školenie na testovanie softvéru online na živom projekte“ série. Ak ste tu nový, pozrite si prvý úvodný návod: Kompletné školenie o testovaní softvéru na živom projekte.

Poďme sa teraz venovať podrobnej analýze toho, ako sa postupuje po SRS, čo je to, čo musíme od tohto kroku zistiť, aké predbežné kroky musíme podniknúť, než začneme, aké sú výzvy, ktorým môžeme čeliť atď. podrobným spôsobom.

implementácia prioritného frontu c ++

Ako skontrolovať dokument SRS a vytvoriť testovacie scenáre_

Fáza návrhu SDLC:

Ďalšou fázou SDLC je „Dizajn“ - tu sa funkčné požiadavky premietajú do technických detailov. Do tohto kroku sú zapojené vývojové, dizajnové, environmentálne a dátové tímy. Výsledkom tohto kroku je zvyčajne dokument o technickom dizajne - TDD.

Vstupom je dokument SRS pre vytvorenie TDD aj pre tím QA, ktorý má začať pracovať na aspekte QA projektu - ktorým je preskúmanie SRS a identifikácia cieľa testu.

Čo sa dozviete:

Čo je to recenzia SRS?

SRS je dokument, ktorý vytvára vývojový tím v spolupráci s obchodnými analytikmi a tímami pre prostredie a dáta. Po dokončení bude tento dokument zvyčajne zdieľaný s tímom QA prostredníctvom stretnutia, na ktorom je dohodnutý podrobný návod.

Niekedy pre už existujúcu aplikáciu možno nebudeme potrebovať formálne stretnutie a niekoho, kto nás prevedie týmto dokumentom. Možno by sme mali potrebné informácie, aby sme to mohli urobiť sami.

Recenzia SRS nie je nič iné, ako prejsť dokumentom špecifikácie funkčných požiadaviek a pokúsiť sa pochopiť, aká bude cieľová aplikácia.

O formálnom formáte a ukážke sme sa s vami všetkými podelili v predchádzajúcom článku. To nemusí nevyhnutne znamenať, že všetky SRS budú dokumentované týmto spôsobom presne. Vždy, forma je druhoradá k obsahu .

Niektoré tímy sa rozhodnú napísať zoznam s odrážkami, niektoré tímy zahrnú prípady použitia, niektoré tímy ukážkové snímky obrazovky (napríklad dokument, ktorý sme mali) a niektoré iba popisujú podrobnosti v odsekoch.

Preskúmanie predbežných krokov k požiadavkám na softvér

Krok 1) Dokumenty prechádzajú viacerými revíziami, takže sa uistite, že máme správnu verziu referenčného dokumentu, SRS.

Krok 2) Stanovte pokyny k tomu, čo sa od každého člena tímu očakáva na konci kontroly. Inými slovami, rozhodnúť o tom, aké výsledky sa očakávajú od tohto kroku - výstupom tohto kroku je zvyčajne identifikácia testovacích scenárov. Testovacie scenáre nie sú ničím iným ako jednoriadkovým ukazovateľom toho, čo je treba otestovať, pokiaľ ide o určité funkcie.

Krok č. 3) Stanovte tiež pokyny, ako sa má tento produkt prezentovať - ​​myslím tým šablónu.

Krok č. 4) Rozhodnite sa, či bude každý člen tímu pracovať na celom dokumente, alebo si ho rozdelíte medzi seba. Dôrazne sa odporúča, aby si každý prečítal všetko, pretože to zabráni koncentrácii vedomostí s určitými členmi tímu.

Ale v prípade veľkého projektu, ktorého dokumenty SRS majú takmer 1000 strán, je praktický prístup rozbitia modulu dokumentu a jeho priradenia jednotlivým členom tímu.

Krok č. 5) Revízia SRS tiež pomáha lepšie pochopiť, či existujú nejaké konkrétne predpoklady vyžadované na testovanie softvéru.

Krok č. 6) Ako vedľajší produkt je identifikovaný zoznam otázok, pri ktorých je ťažké pochopiť niektoré funkcie, alebo ak je potrebné do funkčných požiadaviek zahrnúť viac informácií, alebo ak dôjde k chybám v SRS.

Čo potrebujeme, aby sme mohli začať?

  • Správna verzia dokumentu SRS
  • Jasné pokyny, kto bude na čom pracovať a koľko času majú.
  • Šablóna na vytvorenie testovacích scenárov.
  • Ďalšie informácie o tom, na koho sa máte obrátiť v prípade otázok alebo koho nahlásiť v prípade nesúladu dokumentácie

Kto by poskytol tieto informácie?

Vedúci tímov sú všeobecne zodpovední za poskytnutie všetkých položiek uvedených v časti vyššie. Pre úspech celého tohto snaženia sú však vždy dôležité príspevky členov tímu.

Vedúci tímu sa často pýtajú - Aký druh vstupov? Nebolo by lepšie prideliť určitý modul niekomu, kto sa oň zaujíma, ako členovi tímu, ktorý nie je? Nebolo by pekné rozhodnúť sa o cieľovom termíne na základe názoru tímu, ako by malo byť rozhodovanie o nich? Pre úspech projektu sú dôležité aj šablóny.

Spravidla majú šablóny vyššiu mieru efektívnosti, keď sú prispôsobené pohodliu a komfortu konkrétneho tímu. Je preto potrebné poznamenať, že tím vedie viac než čokoľvek iné. Pre bezproblémový priebeh projektu je rozhodujúce zapojenie vášho tímu do každodenných rozhodnutí.

Vyžaduje sa šablóna pre testovacie scenáre?

Prečo šablóna pre testovacie scenáre - nestačí, ak vytvoríme iba zoznam?

Urcite je. Softvérové ​​projekty však nie sú prehliadkami „jedného človeka“. Zahŕňajú tímová práca .

Predstavte si štvorčlenný tím, ak sa každý z nich rozhodne skontrolovať každý jeden modul špecifikácie softvérových požiadaviek. Člen tímu A vytvoril zoznam na list papiera. Člen tímu 2 použil hárok programu Excel. Člen tímu 3 použil poznámkový blok. Člen tímu 4 použil slovo doc. Ako zlúčime všetku prácu vykonanú na konci projektu?

Ako tiež môžeme rozhodnúť, ktorý z nich je štandardom a ako môžeme povedať, čo je správne a čo nie, ak by sme najskôr nevytvorili pravidlá?

To je to, čo je šablóna: Súbor pokynov a dohodnutý formát jednotnosti a súladu pre celý tím.

Ako vytvoriť šablónu pre scenáre testovania kvality?

Šablóny nemusia byť komplikované alebo nepružné.

Všetko, čo musia byť, je efektívny mechanizmus na vytvorenie užitočného artefaktu na testovanie. Niečo jednoduché, ako je to, ktoré vidíme nižšie:

šablóna testovacích scenárov

Hlavička tejto šablóny obsahuje miesto potrebné na zachytenie základných informácií o projekte, aktuálnom dokumente a referenčnom dokumente.

Nasledujúca tabuľka nám umožní vytvoriť testovacie scenáre. Zahrnuté stĺpce sú:

Stĺpec 1) ID testovacieho scenára
Každá entita v našom testovacom procese musí byť jednoznačne identifikovateľná. Každému testovaciemu scenáru musí byť teda pridelené ID. Musia byť definované pravidlá, ktoré treba dodržiavať pri prideľovaní tohto ID.

V záujme tohto článku sa budeme riadiť konvenciou pomenovania ako TS (predpona, ktorá znamená Testovací scenár), za ktorou nasleduje „_“, názov modulu Ja (Modul Moje informácie projektu Orange HRM), za ktorým nasleduje ‘_’ a potom podsekcia ( Napríklad, Ja pre modul Moje informácie, P za fotografiou atď.), za ktorým nasleduje sériové číslo. Príklad: „TS_MI_MIM_01“.

Stĺpec 2) Požiadavka
Pomáha to, že keď vytvárame testovací scenár, mali by sme byť schopní ho namapovať späť do časti dokumentu SRS, odkiaľ sme ho vybrali. Ak majú požiadavky ID, mohli by sme ich použiť. Ak nie, čísla sekcií alebo dokonca čísla strán dokumentu SRS, odkiaľ sme zistili, bude robiť testovateľná požiadavka.

Stĺpec 3) Popis scenára testu
Jeden riadok so špecifikáciou „čo testovať“. Tiež by sme to označili ako cieľ testu.

Stĺpec č. 4) Dôležitosť
To má poskytnúť predstavu o tom, aké dôležité sú určité funkcie pre AUT. Tomuto poľu je možné priradiť hodnoty ako vysoká, stredná a nízka. Môžete si tiež zvoliť bodový systém, napríklad 1-5, z ktorých 5 je najdôležitejších, 1 je menej dôležitých. Nech už bude mať toto pole akúkoľvek hodnotu, musí sa vopred rozhodnúť.

najlepší program na prevod youtube na mp3

Stĺpec 5) Počet testovacích prípadov
Hrubý odhad počtu individuálnych testovacích prípadov, ktoré by sme mohli skončiť pri písaní jedného testovacieho scenára. Napríklad, Na otestovanie prihlásenia zahrňujeme tieto situácie: Opravte používateľské meno a heslo. Opravte používateľské meno a nesprávne heslo. Správne heslo a nesprávne používateľské meno. Výsledkom validácie funkcie prihlásenia budú 3 testovacie prípady.

Poznámka: Túto šablónu môžete rozšíriť alebo odstrániť polia, ktoré považujete za vhodné.

Napríklad , môžete do záhlavia pridať slovo „Skontrolované používateľom“ alebo môžete odstrániť dátum vytvorenia atď. Do tabuľky môžete tiež zahrnúť pole „Vytvorené používateľom“ na určenie testera zodpovedného za určitý testovací scenár alebo odstránenie „Nie. stĺpca Testovacie prípady “. Výber je na tebe. Choďte s tým, čo najlepšie funguje pre celý tím.

Pozrime sa teraz na náš dokument Orange HRM SRS a vytvorme testovacie scenáre

Profesionálny tip: pozrite sa na obsah vzorky SRS, ktorú sme poskytli v 1. tutoriáloch, aby ste získali dobrú predstavu o tom, ako bude akýkoľvek dokument plynúť a koľko práce to môže vyžadovať.

Sekcia 1 je účel dokumentu. Žiadne testovateľné požiadavky.

Oddiel 2.1 : Prehľad projektu - publikum - ani tam nie sú testovateľné požiadavky.

Oddiel 2.2 : Hardvér a hosťovanie - Táto časť hovorí o tom, ako bude hostená stránka Orange HRM. Je táto informácia dôležitá pre nás testerov? Odpoveď je áno a nie. Áno, pretože keď testujeme, musíme mať prostredie podobné prostrediu v reálnom čase.

Toto nám dáva predstavu o tom, ako to musí byť. Nie, pretože to nie je testovateľná požiadavka - akýsi predpoklad na to, aby sa testovanie uskutočnilo.

Oddiel 3: Nachádza sa tu prihlasovacia obrazovka a podrobnosti o type účtu, ktorý musíme mať na vstup na stránku. Toto je testovateľná požiadavka. Musí to byť teda súčasť našich testovacích scenárov.

Prečítajte si dokument testovacích scenárov, kde boli pridané testovacie scenáre pre niekoľko sekcií SRS. Pre prax prosím doplňte ostatné scenáre podobným spôsobom. Idem však priamo do časti 4 dokumentu.

Oddiel 4: Estetické / HTML požiadavky a pokyny - Táto časť najlepšie vysvetľuje, ako niektoré požiadavky nemusia mať zmysel pre testovací tím v čase kontroly SRS, ale tím by ich mal poznačiť ako testovateľné požiadavky.

Ako ich otestovať a či potrebujeme konkrétne nastavenie / pomoc ktoréhokoľvek tímu na jeho overenie, sú podrobnosti, ktoré v tejto chvíli nemusíme vedieť. To, že sme sa stali súčasťou nášho testovacieho rozsahu, je však prvým krokom k zaisteniu, aby nám nechýbali.

Vzorové testovacie scenáre pre aplikáciu OrangeHRM: (kliknite pre zväčšenie obrázku)

šablóna testovacích scenárov

=> Prečítajte si a stiahnite si dokument Testovacie scenáre Pre viac informácií.

Niektoré dôležité pripomienky týkajúce sa preskúmania SRS

# 1) Žiadne informácie nesmú zostať nezakryté.
#dva) Vykonajte analýzu uskutočniteľnosti, či je určitá požiadavka správna alebo nie, a tiež či je možné ju testovať alebo nie.
# 3) Pokiaľ neexistuje samostatný výkon / zabezpečenie alebo iná forma testovacích tímov, je našou úlohou zabezpečiť, aby sa zohľadnili všetky nefunkčné požiadavky.
# 4) Nie všetky informácie sú zamerané na testerov, takže je dôležité pochopiť, čo si treba všimnúť a čo nie.
# 5) Dôležitosť a č. testovacích prípadov pre testovací scenár nemusí byť presných a je možné ich vyplniť približnou hodnotou alebo môžu zostať prázdne.

Ak to zhrnieme, výsledkom kontroly SRS sú:

  • Zoznam testovacích scenárov
  • Výsledky kontroly - chyby dokumentácie / požiadavky nájdené statickým prechodom / overením dokumentu SRS
  • Zoznam otázok pre lepšie pochopenie - v prípade akýchkoľvek
  • Predbežná predstava o tom, aké má byť testovacie prostredie
  • Identifikácia rozsahu testu a približná predstava o tom, koľko testovacích prípadov by sme nakoniec mohli mať - toľko času potrebujeme na dokumentáciu a nakoniec na vykonanie.

Dôležité poznámky:

# 1) Testovacie scenáre nie sú externými produktmi (nezdieľajú ich obchodní analytici alebo vývojové tímy), ale sú dôležité pre internú spotrebu QA. Sú našim prvým krokom k cieľu 100% pokrytia testu. Po dokončení testovacie scenáre prejdú partnerským hodnotením a po dokončení sú všetky konsolidované.

Viac podrobností o kontrole dokumentov QA nájdete v článku: Ako vykonať preskúmanie dokumentácie k testu v 6 jednoduchých krokoch.

.net c # otázky z rozhovoru

#dva) Mohli by sme použiť nástroj na správu testov ako HP ALM alebo qTest vytvoriť testovacie scenáre. Tvorba testovacích scenárov v reálnom čase je však manuálna aktivita. Podľa môjho názoru je to pohodlnejšie manuálne. Pretože je to krok 1, nemusíme ešte vynášať veľké zbrane. Najlepším spôsobom, ako na to, sú jednoduché listy programu Excel.

Ďalším krokom k tejto sérii je to - budeme pracovať na vytváraní testovacích prípadov a dostaneme sa ďalej do fázy navrhovania testu. Predtým sa tiež dostaneme do - Čo je plánovanie testov?Kam zapadá do celého projektu QA? Ako vždy, aj teraz s nami pracujte na najlepších výsledkoch.

QA Training Day 3: Ako písať dokument SRS od nuly.

Majte prosím svoje otázky a pripomienky k dispozícii. Vážime si vašu čítanosť!

Odporúčané čítanie

^