Menu

Ako otestovať aplikáciu bez požiadaviek?

how test an application without requirements

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

Technicky neexistujú žiadne aplikácie bez požiadaviek. Predstavte si softvér, ktorý nerobí nič konkrétne, ale jednoducho sa tiahne riadok po riadku kódu. Bude to schodisko, ktoré nikam nevedie.

Celý softvér má požiadavky a je zameraný na konkrétnu úlohu; konkrétne ide o riešenie problému. Takže menej požiadaviek softvér nie je možné.

Softvér bez zdokumentovaných požiadaviek je však realitou, s ktorou sa bohužiaľ väčšina z nás stretáva častejšie máme radi. Horšie by mohlo byť len to, že dokumentácia je nedostatočná, nepresná alebo strašne zastaraná. Bohužiaľ, aj to sa stáva.

skúška bez požiadaviek

Úprimne povedané, skutočne neexistuje žiadna náhrada za dobre zdokumentovaný dokument s požiadavkami na funkčné / systémové požiadavky s prepracovanými prípadmi použitia a vzorovými obrazovkami. Aj keď musíme pripustiť, že sa to v priemysle stáva zriedkavosťou kvôli rýchlym vývojovým cyklom a posunu paradigmy k minimálnej alebo žiadnej dokumentácii.

Preto je tento článok pokusom o niektoré praktiky, ktoré sme dodržali, keď sme sa ocitli v týchto situáciách.

Prečítajte si tiež:

rozhovor s obchodným analytikom otázky a odpovede ppt

Najprv sa pozrime na niekoľko dôvody, prečo nemusí byť dokumentácia, najskôr:

  1. Policový projekt sa znovu otvára
  2. Dokumentácia bez formátu pracovného procesu
  3. Dokumentácia môže existovať, ale nemusí byť podrobná alebo úplná
  4. Priebežné vydania a informácie súvisiace so staršou verziou sa nearchivovali, čo má za následok medzeru v porozumení toho, ako súčasná funkčnosť reaguje s novou.

To všetko sú prekážky, ktoré musíme my testéri statočne prekonať a úspešne sa objaviť. Ako presne však, že?

Tu sú tri najlepšie spôsoby testovania aplikácie bez požiadaviek:

Metóda č. 1:

Pracujte s akoukoľvek malou dokumentáciou, ktorá sa vám dostane do rúk. Môže to byť základný jednoduchý nevybavený dokument (v agilných projektoch), súbor pomocníka, e-mail, staršia verzia BRD / FRD alebo staré testovacie prípady (vyhľadajte ich vo svojich nástrojoch ALM a môžete ich nájsť) atď.

Vyšetrite, opýtajte sa a vždy existuje nejaká zdokumentovaná skúška, aj keď je tenká.

Ak to nefunguje, nezľavujte zo svojej skúsenosti s používaním softvéru.Napríklad, ak musíte otestovať prevodovú operáciu bankového účtu, nemusí nám nikto rozprávať, ako na to, že? Pretože ako zákazníci online bankovníctva všetci vieme, že na prevod potrebujeme účty z a na množstvo finančných prostriedkov, ktoré sú k dispozícii.

Dohodli sme sa, že nie všetky situácie budú také jednoduché, ale opäť to tak môže byť.

Metóda č. 2:

Na testovanie budúceho vydania softvérového produktu použite ako referenciu staršiu / aktuálnu verziu aplikácie. Teraz pripúšťam, že to je v rozpore s pravidlom „Nikdy nepíšte testovacie prípady s použitím aplikácie ako referencie“. Keď však pracujeme v nie úplne dokonalej situácii, musíme pripraviť pravidlá tak, aby vyhovovali našim potrebám.

Pomáha pri tom udržiavať v perspektíve nasledujúce aspekty:

  • Aplikácia môže obsahovať chyby, takže ak vás systém po registrácii priamo zavedie na obrazovku Screen1 (pre náš príklad ide o určitú hypotetickú obrazovku) - nikdy nepokladajte za správne správanie. Rovnako, ak má pole alfanumerické znaky a je to telefónne číslo, je to otázka a uistite sa, že aplikáciu neberiete ako zaručený príklad očakávanej funkčnosti.
  • Vo vyššie uvedených situáciách využite svoj úsudok a využite pomoc aplikácie, aby ste mohli začať, ale buďte kritickí k otázke, či funguje.

Metóda č. 3:

Porozprávajte sa s členmi projektového tímu:

  • Ponuka účasti na ich stretnutiach.
  • Spýtajte sa, či sa môžete zúčastniť fáz testovania jednotky a integrácie.
  • Ak nie, opýtajte sa, či môže vývojársky tím zdieľať výsledky svojich testov jednotky a integrácie.
  • Dohodnite si čas na prenos vedomostí vo vhodnom čase.

Teraz použijeme metódy v príklade:

Predpokladajme, že existuje nákupná stránka, kde môžete pridávať položky do nákupného košíka. V ideálnom prípade, ak by existovala dokumentácia, musí nám povedať, ako do nej pridať položky, koľko položiek v danom okamihu môže mať, čo sa stane, keď položka, ktorú ste pridali, náhle vypredá, aký je maximálny počet rovnakých predmetov, ktoré si môžete kúpiť súčasne, atď. Naša situácia je taká, že ŽIADNE z nich nie sú v súčasnosti k dispozícii.

Použiť metódu č. 1:

Nájdite všetku možnú dokumentáciu. Opýtajte sa svojho vývojového tímu, či má vzorové obrazovky / hľadanie v nástroji ALM alebo niečo podobné. Ak niečo nájdete, bol by to dobrý východiskový bod. Ak sa však touto metódou nič neobjaví, môžete použiť svoju úsudok / intuícia testera.

Všetci vieme, ako fungujú nákupné vozíky, takže urobte svoje predpoklady a dospejte k niekoľkým základným scenárom, ako napríklad:

  • Položky je možné po prehliadaní alebo prehľadaní pridať do nákupného košíka
  • Po pridaní položiek do nákupného košíka by sa mal zoznam položiek obnoviť
  • Používateľ by mal byť schopný pokračovať v nakupovaní aj po pridaní niekoľkých položiek do košíka
  • Ak dvakrát pridáte tú istú položku, zvýši sa počet pridaných položiek
  • Položky je možné aktualizovať
  • Položky je možné odstrániť
  • Celková suma by sa mala rovnať súčtu všetkých pridaných cien
  • Dane by sa mali počítať na základe zadaného PSČ
  • Podľa toho je potrebné pripočítať náklady na dopravu

Môžeme pokračovať, ale som si istý, že si to uvedomíš.

Použiť metódu č. 2:

Ak je k dispozícii staršia verzia aplikácie, môže to byť užitočné pri písaní testovacích prípadov, pretože budete musieť napísať presné kroky, kam kliknúť, kam zadať vstup, čo skontrolovať atď. Screenshoty / makety / drôt rámy - ak sú k dispozícii, môžu byť tiež skvelými náhradami.

Ako vidíte na obrazovke nižšie, tieto veci sú zrejmé - názvy polí, tlačidlá alebo ďalšie prvky, atď. (kliknite na obrázok pre zväčšenie)

skúška bez požiadaviek

Teraz majú testéri niekoľko otázok, napríklad:

  1. Čo sa stane, keď do poľa sumy zadám znak?
  2. Kedy pridám príliš veľa položiek?
  3. Aké je maximum č. z položiek, ktoré to môže trvať? Atď.

Použite metódu č. 3 :

Odošlite zoznam otázok na BA, vývojára alebo dokonca ku klientovi a hľadajte vysvetlenie. Po dokončení metódy 3 by ste mali byť vybavení všetkými informáciami, ktoré budete potrebovať na napísanie podrobných testovacích prípadov a na vykonanie testov s takou istotou, ako keby bola k dispozícii podrobná dokumentácia.

Dohodli sme sa, že je to oveľa viac krokov a oveľa viac následných krokov, ale na zabezpečenie testovania kvality sú tieto kroky nevyhnutné.

Na záver, všetko sa nestratí, keď dokumentácia neexistuje alebo je nedostatočná. Stále existuje nádej! Podeľte sa, prosím, o svoje skúsenosti z podobných situácií.

O autorovi: Tento užitočný príspevok napísal náš člen tímu STH Swati S.

Ako vždy sú vaše pripomienky, otázky a návrhy vítané.

Odporúčané čítanie

^