Menu

Jak otestovat aplikaci bez požadavků?

how test an application without requirements

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

Technicky neexistují žádné aplikace bez požadavků. Představte si software, který nedělá nic konkrétního, ale jednoduše se táhne řádek po řádku kódu. Bude to schodiště, které nikam nevede.

Veškerý software má požadavky a je zaměřen na konkrétní úkol; konkrétně se jedná o řešení problému. Tak bez požadavků software není možný.

Software bez dokumentovaných požadavků je však realitou, s níž se bohužel většina z nás potýká častěji máme rádi. Jedinou horší věcí by mohlo být, že dokumentace je nedostatečná, nepřesná nebo strašně zastaralá. Bohužel se to stává také.

zkouška bez požadavků

Upřímně řečeno, opravdu neexistuje žádná náhrada za dobře zdokumentovaný dokument funkčních / systémových požadavků s propracovanými případy použití a vzorovými obrazovkami. I když musíme uznat, že se to v průmyslu stává raritou kvůli rychlým vývojovým cyklům a posunu paradigmatu směrem k minimální nebo žádné dokumentaci.

Proto je tento článek pokusem o některé postupy, které jsme dodržovali, když jsme se ocitli v těchto situacích.

Přečtěte si také:

bezplatný zálohovací program pro Windows 7

Nejprve se podívejme na několik důvody, proč nemusí být dokumentace, začněte s:

  1. Opětovný otevření odloženého projektu
  2. Dokumentace bez formátu pracovního procesu
  3. Dokumentace může existovat - ale nemusí být podrobná ani úplná
  4. Kontinuální vydání a informace související se starší verzí nebyly archivovány, což má za následek mezeru v porozumění tomu, jak stávající funkce reaguje s novou.

To vše jsou překážky, které my testeři musíme statečně překonat a úspěšně se objevit. Jak přesně však, že?

Tady jsou 3 nejlepší metody pro testování aplikace bez požadavků:

Metoda č. 1:

Pracujte s jakoukoli malou dokumentací, která se vám dostane do rukou. Může to být základní jednoduché nevyřízené položky (v agilních projektech), soubor nápovědy, e-mail, starší verze BRD / FRD nebo staré testovací případy (zkontrolujte je ve svých nástrojích ALM a můžete je najít) atd.

Vyšetřujte, zeptejte se a vždy existuje nějaká zdokumentovaná zkouška, i když je to tenká.

Pokud to nefunguje, nezlevňujte ze své zkušenosti jako uživatel softwaru.Například, pokud musíte otestovat operaci převodu u bankovního účtu, nikdo nám nemusí říkat, jak to udělat, že? Protože jako zákazníci online bankovnictví všichni víme, že k převodu potřebujeme účty a účty s řadou dostupných finančních prostředků.

Dohodli jsme se, že ne všechny situace budou tak přímočaré, ale opět to tak může být.

Metoda č. 2:

Použijte starší / aktuální verzi aplikace jako referenci k otestování budoucího vydání softwarového produktu. Nyní připouštím, že to je v negaci pravidla: „Nikdy nepište testovací případy s použitím aplikace jako reference“. Když však pracujeme v méně než dokonalé situaci, musíme formulovat pravidla tak, aby vyhovovala našim potřebám.

Pomáhá přitom udržovat v perspektivě následující aspekty:

  • Aplikace může obsahovat chyby - takže pokud vás systém po registraci přímo přenese na Screen1 (pro náš příklad určitá hypotetická obrazovka) - nikdy nepředpokládejte, že jde o správné chování. Také pokud pole má alfanumerické znaky a je to telefonní číslo - otázka a ujistěte se, že aplikaci neberete jako povolený příklad očekávané funkce.
  • Ve výše uvedených situacích použijte svůj úsudek a využijte pomoc aplikace, abyste mohli začít, ale buďte kritičtí, když zpochybňujete, že funguje.

Metoda č. 3:

Promluvte si se členy projektového týmu:

  • Nabídněte účast na jejich schůzkách.
  • Zeptejte se, zda se můžete účastnit fází testování jednotky a integrace.
  • Pokud ne, zeptejte se, zda tým vývojářů může sdílet své výsledky testů jednotky a integrace.
  • Dohodněte si čas na přenos znalostí ve vhodnou dobu.

Nyní použijeme metody v příkladu:

Předpokládejme, že existuje nákupní web, kde můžete přidávat položky do nákupního košíku. V ideálním případě, kdyby existovala dokumentace, musí nám říci, jak do ní přidat položky, kolik položek v daném okamžiku může mít, co se stane, když položka, kterou jste přidali, najednou vyprodána, jaký je maximální počet stejných položek, které si můžete koupit současně, atd. Naše situace je taková, že v tuto chvíli NENÍ k dispozici ŽÁDNÝ.

Použijte metodu č. 1:

Vyhledejte veškerou možnou dokumentaci. Zeptejte se svého vývojářského týmu, jestli má mock-up obrazovky / podívejte se do nástroje ALM nebo vůbec něco. Pokud něco najdete, byl by to dobrý výchozí bod. Pokud ale tato metoda nic neukáže, můžete použít svůj úsudek / intuice testera.

Všichni víme, jak nákupní vozíky fungují, takže vytvořte své předpoklady a dosáhněte několika základních scénářů, například:

  • Položky lze přidat do nákupního košíku po procházení nebo prohledávání
  • Jakmile přidám položky do nákupního košíku, měl by se seznam položek obnovit
  • Uživatel by měl být schopen pokračovat v nakupování i po přidání několika položek do košíku
  • Přidání stejné položky dvakrát způsobí, že se počet přidaných položek zvýší
  • Položky lze aktualizovat
  • Položky lze odebrat
  • Celková částka by měla odpovídat součtu všech přidaných cen
  • Daně je třeba vypočítat na základě zadaného PSČ
  • Náklady na dopravu je třeba odpovídajícím způsobem připočítat

Můžeme pokračovat, ale jsem si jist, že obrázek získáte.

Použijte metodu č. 2:

Pokud je k dispozici starší verze aplikace, může to být užitečné při psaní testovacích případů, protože budete muset napsat přesné kroky, kam kliknout, kam zadat vstup, co zkontrolovat atd. Screenshoty / makety / drát - rámy - pokud jsou k dispozici, mohou být také skvělými náhražkami.

Jak vidíte na níže uvedené obrazovce, tyto věci jsou zřejmé - názvy polí, tlačítka nebo jiné prvky, které jsou přítomny atd. (pro zvětšení klikněte na obrázek)

zkouška bez požadavků

Nyní mají testeři několik otázek, například:

  1. Co se stane, když do pole pro částku zadám znak?
  2. Kdy přidám příliš mnoho položek?
  3. Jaký je maximální počet položek, které to může trvat? Atd.

Použijte metodu č. 3 :

Vezměte svůj seznam otázek na BA, vývojáře nebo dokonce na klienta a hledejte vysvětlení. Jakmile je metoda 3 hotová, měli byste být vybaveni všemi informacemi, které budete potřebovat k napsání podrobných testovacích případů a provedení testování s takovou jistotou, jako kdyby byla k dispozici podrobná dokumentace.

Dohodli jsme se, že jde o mnohem více kroků a mnohem více následných kroků, ale k zajištění testování kvality jsou tyto kroky nevyhnutelné.

Závěrem, vše není ztraceno, když dokumentace neexistuje nebo je nedostatečná. Stále existuje naděje! Podělte se, prosím, o své zkušenosti v podobných situacích.

O autorovi: Tento užitečný příspěvek napsal náš tým STH Swati S.

Jako vždy jsou vaše komentáře, dotazy a návrhy vítány.

Doporučené čtení

^