how test banking domain applications
Kompletní průvodce testováním bankovní aplikace: Proces a tipy pro testování BFSI (bankovnictví, finanční služby a pojištění)
Bankovní aplikace jsou jednou z nejsložitějších aplikací v dnešním odvětví vývoje a testování softwaru.
Co dělá bankovní aplikace tak složitými? Jaký přístup je třeba dodržet při testování složitých pracovních postupů v bankovních aplikacích?
V tomto článku zdůrazníme různé fáze a techniky testování bankovních aplikací.
Co se naučíte:
- Jak otestovat bankovní aplikace?
- Důležitost testování bankovní aplikace
- Pracovní postup testování bankovních aplikací
- Ukázkové testovací případy pro bankovní aplikace
- Závěr
Jak otestovat bankovní aplikace?
Různé funkce prováděné bankovními aplikacemi jsou:
Pojďme nejprve pochopit vlastnosti bankovní aplikace:
- Víceúrovňová funkce pro podporu tisíců souběžných uživatelských relací
- Integrace ve velkém měřítku: Bankovní aplikace se obvykle integruje s řadou dalších aplikací, jako je nástroj Bill Pay a obchodní účty
- Složité obchodní pracovní postupy
- Real-Time a dávkové zpracování
- Vysoká rychlost transakcí za sekundu
- Zabezpečené transakce
- Robustní sekce Reporting pro sledování každodenních transakcí
- Silný audit pro řešení problémů se zákazníky
- Masivní úložný systém
- Správa po katastrofě / obnovení.
Výše uvedených deset bodů je nejdůležitější vlastnosti bankovní aplikace.
Bankovní aplikace mají při provádění operace několik úrovní.
Například , do Bankovní aplikace může mít:
- Webový server komunikuje s koncovými uživateli prostřednictvím prohlížeče
- Middle Tier k ověření vstupu a výstupu pro webový server
- DataBase pro ukládání dat a postupů
- Transakční procesor, kterým může být velkokapacitní mainframe nebo jakýkoli jiný starší systém k provádění bilionů transakcí za sekundu.
Pokud mluvíme o testování bankovních aplikací, vyžaduje to Metodika testování typu end to end zahrnující několik technik testování softwaru k zajištění:
- Celkové pokrytí všech bankovních pracovních toků a obchodních požadavků
- Funkční stránka aplikace
- Bezpečnostní aspekt aplikace
- Integrita dat
- Konkurence
- Uživatelská zkušenost
Co dělá bankovní aplikace tak složitými?
- Bankovní software se zabývá hlavně důvěrnými finančními údaji, takže výkon softwaru by měl být bezchybný a bezpečný.
- Vývojáři dávají při vývoji těchto aplikací přednost komplikovanému designu, aby zajistili, že aplikace běží požadovaným bezpečným způsobem.
- Bankovnictví je neustále se měnící svět. Bankovnictví je dnes k dispozici zákazníkovi pomocí různých kanálů, jako jsou kamenné pobočky, bankomaty, online bankovnictví a péče o zákazníky.
- S příchodem technologie zaplavilo mnoho peněženek trhy, které se připojují k bankovním systémům pro finanční transakce.
- Očekává se také, že bankovnictví bude fungovat 24 X 7 s vysokým výkonem. Nelze připustit, aby aktualizace softwaru, okamžité opravy atd. Ovlivnily tuto dostupnost.
- Bankovní svět je také velmi ovlivněn neustálými změnami, které přináší vláda v podobě bankovních předpisů. Jakékoli změny v daňové struktuře mají dopad také na bankovní systém.
- Bankovní systém musí být také aktuální, pokud jde o nové technologie. Analytika dat, jako je zpracování velkých dat a získávání instinktů z velkých dat pomocí Data Science, roste v bankovním světě.
Výše uvedené body činí bankovní systém pro vývojáře složitým, aby kolem něj vytvořili softwarovou aplikaci.
Důležitost testování bankovní aplikace
- Testování bankovní aplikace zajišťuje, že všechny činnosti jsou nejen dobře provedeny, ale také zůstávají chráněny a zabezpečeny.
- Bankovní software je komplikovaný tisíci závislostmi, proces testování vyžaduje více času, zdrojů a nepřetržité sledování.
- Vzhledem k tomu, že se jedná o finance, je třeba přísně dodržovat pokyny. Testeři i vývojáři by měli mít dobré znalosti domény.
- A co je nejdůležitější, je třeba zajistit, aby zákony a předpisy byly při finančních transakcích dodržovány správně. To lze zajistit pouze pomocí testování.
- Je také důležité zajistit, aby aplikace a infrastruktura, na které byla aplikace nasazena, dokázaly zvládnout zátěž, zejména během špičkových pracovních hodin, aniž by došlo k narušení. To lze zajistit provedením testování výkonu.
- V dnešním digitálním světě se všichni zajímají o bezpečnost. Bankovní aplikace a finanční transakce, které jsou v ní prováděny, musí být zabezpečeny před jakýmkoli pokusem o vloupání. To lze zajistit provedením testování zabezpečení. Testování zabezpečení pomáhá prosazovat průmyslové standardy k zabezpečení finančních transakcí.
- Je také důležité zajistit, aby se různé moduly bankovní aplikace správně integrovaly a dosáhly cíle klienta. Testování integrace systému pomáhá dosáhnout tohoto úkolu.
Pracovní postup testování bankovních aplikací
Typické fáze testování bankovních aplikací jsou zobrazeny v pracovním postupu níže. Budeme diskutovat o každé fázi individuálně.
Toto je Waterfallův model testování aplikace.
# 1) Shromažďování požadavků
Fáze shromažďování požadavků zahrnuje dokumentaci požadavků buď jako funkční specifikace, nebo jako případy použití. Požadavky jsou shromažďovány podle potřeb zákazníků a dokumentovány bankovními experty nebo obchodními analytiky.
Odborníci se podílejí na psaní požadavků na více než jeden předmět, protože samotné bankovnictví má více subdomén a integrace všech těchto domén bude jednou plnohodnotnou bankovní aplikací.
Například, Bankovní aplikace může mít samostatné moduly pro převody, kreditní karty, zprávy, úvěrové účty, platby účtů, obchodování atd.
# 2) Kontrola požadavků
Výsledek shromáždění požadavků je kontrolován všemi zúčastněnými stranami, jako jsou QA Engineers, Development Leads a Peer Business Analysts.
Křížově kontrolují, zda nejsou porušeny ani stávající obchodní pracovní postupy, ani nové pracovní postupy. Všechny požadavky jsou ověřeny a ověřeny. Následné akce a revize dokumentů požadavků se provádějí na základě stejných.
# 3) Příprava obchodního scénáře
V této fázi odvodí QA Engineers obchodní scénáře z dokumentů požadavků (specifikace funkcí nebo případy použití); Obchodní scénáře jsou odvozeny takovým způsobem, že jsou pokryty všechny obchodní požadavky. Obchodní scénáře jsou scénáře na vysoké úrovni bez podrobných kroků.
Dále jsou tyto obchodní scénáře přezkoumány obchodními analytiky, aby bylo zajištěno, že jsou splněny všechny obchodní požadavky. Pro BA je snazší kontrolovat scénáře na vysoké úrovni než kontrolovat podrobné testovací případy na nízké úrovni.
Například , zákazník otevírající Pevný vklad na rozhraní digitálního bankovnictví může být obchodním scénářem. Podobně můžeme mít různé obchodní scénáře související s vytvořením účtu čistého bankovnictví, online vklady, online převody atd.
# 4) Funkční testování
V této fázi se provádí funkční testování a provádějí se obvyklé činnosti testování softwaru, například:
Příprava testovacího případu: V této fázi jsou testovací případy odvozeny z obchodních scénářů, jeden obchodní scénář vede k několika pozitivním testovacím případům a negativním testovacím případům. Obecně se během této fáze používají nástroje Microsoft Excel, Test Director nebo Quality Center.
Recenze testovacího případu: Recenze peer QA Engineers
Modelový případ Provedení: Provedení testovacího případu může být manuální nebo automatické zahrnující nástroje jako QC, QTP atd.
Funkční testování bankovní aplikace se zcela liší od běžného testování softwaru. Protože tyto aplikace fungují s penězi zákazníka a citlivými finančními údaji, je nutné je důkladně otestovat. Žádný důležitý obchodní scénář by neměl být ponechán k pokrytí.
Zdroj QA, který testuje aplikaci, by měl mít také základní znalosti o bankovní doméně.
# 5) Testování databáze
Bankovní aplikace zahrnuje složité transakce, které se provádějí na úrovni uživatelského rozhraní i na úrovni databáze. Proto je testování databáze stejně důležité jako funkční testování. Databáze je komplikovaná a v aplikaci je zcela samostatná vrstva, a proto její testování provádějí databázoví specialisté. Používá techniky jako:
- Načítání dat
- Migrace databáze
- Testování schématu DB a datových typů
- Pravidla testování
- Testování uložených postupů a funkcí
- Testování spouštěčů
- Integrita dat
Hlavním účelem testování databáze je zajistit, aby:
- Aplikace je schopna ukládat a načítat data z databáze bez jakékoli ztráty dat.
- Dokončené transakce by měly být potvrzeny a zrušené transakce jsou vráceny zpět, aby nedocházelo k nesouladu uložených dat.
- Přístup do databáze a základních tabulek mají povoleny pouze autorizované aplikace a uživatelé.
Existují primárně tři způsoby testování databáze:
- Strukturální testování
- Funkční testování
- Nefunkční testování
Strukturální testování
Zahrnuje testování databázových objektů, jako jsou databáze, schémata, tabulky, pohledy, spouštěče, řízení přístupu atd. Zajištění synchronizace datových typů v tabulkách s odpovídajícími proměnnými v aplikaci. Ověření dat a referenční integrity v tabulkách.
Například, Pole množství v aplikaci by mělo mít v tabulce datový typ desítkové / plovoucí.
- Aby uživatelé vyhověli normám, měli by mít přístupy prostřednictvím pohledů.
Funkční testování
Zahrnuje testování databází, které splňují požadavky uživatelů. Existují dva způsoby, jak toho dosáhnout: testování černé skříňky a testování bílé skříňky.
Například, Když provádíme online převod peněz, měla by být částka z účtu odesílatele odepsána a na účet příjemce měla být připsána přesně stejná částka. Pokud transakce selže, měly by být vráceny celé transakce a účet odesílatele by neměl být odepsán ani připsán zpět.
Nefunkční testování
Zahrnuje zátěžové a zátěžové testování a optimalizaci výkonu. Testování zátěže pomáhá při identifikaci největšího počtu transakcí, které lze provádět souběžně bez ovlivnění výkonu databáze.
Například, Na základě vstupu ze zátěžového a zátěžového testování se bankovní aplikace mohou rozhodnout přidat do své aplikace více zdrojů během špičkové pracovní doby a snížit zdroje během mimo pracovní dobu. To pomáhá bance optimálně využívat zdroje a šetřit peníze.
# 6) Testování zabezpečení
Testování zabezpečení je obvykle poslední fází testovacího cyklu. Předpokladem pro zahájení testování zabezpečení je dokončení funkčního a nefunkčního testování. Testování zabezpečení je jednou z hlavních fází celého cyklu testování aplikací, protože tato fáze zajišťuje, že aplikace odpovídá federálním a průmyslovým standardům.
Vzhledem k povaze dat, která přenášejí, jsou bankovní aplikace velmi citlivé a jsou hlavním cílem hackerů a podvodných aktivit. Testování zabezpečení zajišťuje, že aplikace nemá žádnou takovou chybu zabezpečení webu, která by mohla vystavit citlivá data vetřelci nebo útočníkovi. Rovněž zajišťuje, že aplikace je v souladu se standardy, jako je OWASP.
V této fázi je hlavním úkolem skenování celé aplikace, které se provádí pomocí nástrojů jako IBM AppScan nebo HP WebInspect (to jsou nejoblíbenější nástroje).
Po dokončení skenování se zpráva o skenování zveřejní. V této zprávě jsou falešná pozitiva odfiltrována a zbývající chyby zabezpečení jsou hlášeny vývojovému týmu, aby začaly problémy opravovat v závislosti na závažnosti každého problému.
V tomto kroku se také provádí penetrační testování, aby se odhalilo šíření chyb. Důkladné testování zabezpečení by mělo být provedeno napříč platformami, sítěmi a OS.
Nějaký jiný Ruční nástroje pro testování zabezpečení použité jsou Paros Proxy , Http hodinky , Burp Suite , a Opevnit.
Hlavním účelem testování zabezpečení je určit všechny chyby zabezpečení, které softwarová aplikace může mít.
Testování zabezpečení testuje aplikaci proti:
- Jakýkoli externí útok nebo pokus o hacknutí aplikace se zlým úmyslem.
- Jakákoli mezera v softwarové aplikaci by mohla být zneužita a způsobit ztrátu dat nebo peněžní ztrátu.
- Jakákoli chyba zabezpečení v síti, serverech a pracovních stanicích, které jsou hostitelem aplikace.
Následují různé typy testování zabezpečení:
Testování zranitelnosti: Je vyvinut a spuštěn automatizovaný program pro kontrolu různých zranitelností.
Bezpečnostní skenování: Tato varianta se točí kolem vyšetřování slabých míst v síti a systému a poskytuje řešení ke snížení souvisejícího rizika.
Penetrační testování: Tato varianta testování zabezpečení napodobuje hackerský pokus o zachycení zranitelných míst a mezer, které by jinak mohly získat přístup k databázi nebo datům aplikace.
Bezpečnostní audit: Zahrnuje auditování aplikace a přidružených sítí pro případná přerušení zabezpečení.
Posouzení rizik: Tato varianta provádí analýzu za účelem posouzení úrovně rizika v případě, že dojde k zneužití chyby zabezpečení nebo mezery ke zlému úmyslu. Toto riziko lze rozdělit na nízké, střední a vysoké. Na základě úrovně rizika testovací tým doporučuje vhodná opatření ke snížení nebo odvrácení rizika.
Etické hackerství: To provádí organizace na svých systémech, aby identifikovala mezery, které by mohly být zneužity v její aplikaci nebo síti. Záměrem tohoto druhu hackerství není krádež nebo poškození aplikace nebo sítě.
Posouzení polohy: Toto je zastřešující hodnocení zahrnující bezpečnostní skenování, hodnocení rizik a etické hackerství.
SQL Injection: K získání přístupu k databázi serveru lze použít SQL Injection. Testování se provádí, aby se zajistilo, že kód funguje správně, což spouští dotazy na databázi na základě následujících vstupů od uživatele:
- Závorky
- Apostrofy
- Čárky
- Uvozovky
Další fáze testování aplikace BFSI
Kromě výše uvedených hlavních fází mohou existovat různé fáze, jako je testování integrace, testování použitelnosti, uživatelské akceptační testování a testování výkonu.
Pojďme si krátce promluvit také o těchto fázích:
Testování integrace
Jak víte, v bankovní aplikaci může existovat několik různých modulů, jako jsou převody, platby účtů, vklady atd. A proto existuje spousta vyvinutých komponent. Při testování integrace byly všechny komponenty integrovány společně a ověřeny.
Testování použitelnosti
Bankovní aplikace slouží široké škále zákazníků. Někteří z těchto zákazníků mohou postrádat dovednosti a povědomí potřebné k provádění bankovních úkolů přes aplikaci.
Bankovní aplikace by tedy měla být testována na jednoduchý a efektivní design, aby byla použitelná pro různé skupiny zákazníků. Jednodušší a snadno použitelné rozhraní je, že vyšší počet zákazníků bude mít z bankovní aplikace prospěch.
Jde o zkoumání úrovně snadnosti, kterou mají obchodní uživatelé nebo zákazníci bank při používání aplikace. Toto testování neprovádí vývojář ani tester, ale provádí ho obchodní uživatelé.
Například, V dnešní době každý používá mobilní aplikace. Bankovní aplikace by měla být uživatelsky přívětivá a měla by být snadno srozumitelná a měla by ji používat koncový uživatel.
Druhy testování použitelnosti
Srovnávací testování použitelnosti: Jedná se o testování založené na srovnání, kde je snadnost použitelnosti jedné webové stránky nebo aplikace s jinou. Cílem takového testování je poskytnout nejlepší uživatelskou zkušenost.
Explorativní testování použitelnosti: Cílem tohoto testování je zjistit, jaké funkce by měla mít nová aplikace nebo software, aby splňovaly požadavky zákazníků banky.
Následují výhody a nevýhody testování použitelnosti
nejlepší weby ke stahování videí z YouTube
Výhody:
- Koncoví uživatelé aplikace jsou obvykle zapojeni do testování, a proto se získává zpětná vazba z první ruky.
- Spíše než trávit čas analýzou a diskusí o funkci, kterou by produkt měl nebo neměl mít, je lepší získat vstupy přímo od koncového uživatele.
- Můžeme předem zachytit jakékoli potenciální problémy.
Nevýhody:
- Protože je do testování zapojeno více koncových uživatelů, může jejich požadavek, pokud není přesný, ovlivnit požadavek.
- Může být ovlivněn zdroj od koncových uživatelů.
Testování výkonu
Některá časová období, jako je výplata, konec finančního roku, sváteční období, mohou přinést změnu nebo prudký nárůst obvyklého provozu aplikace. Proto by mělo být provedeno důkladné testování výkonu, aby zákazníci nebyli ovlivněni poruchami výkonu.
Významným příkladem z minulosti, kdy byli zákazníci bank osobně ovlivněni kvůli selhání výkonu, je výpadek IT NatWest a RBS cyber Monday IT, při kterém měli zákazníci debetní a kreditní karty odmítnuté transakce napříč obchody v zemi.
testování přijetí uživatele
To se provádí zapojením koncových uživatelů, aby se zajistilo, že aplikace vyhovuje scénářům reálného světa a bude přijata uživateli, pokud bude spuštěna.
V dnešním scénáři většina bankovních projektů využívá : Metody Agile / Scrum, RUP a Continuous Integration a balíčky nástrojů jako Microsoft VSTS a Rational Tools.
Jak jsme již zmínili o RUP výše, RUP znamená Rational Unified Process, což je iterační metodika vývoje softwaru zavedená společností IBM, která zahrnuje čtyři fáze, ve kterých se provádějí vývojové a testovací činnosti.
Čtyři fáze jsou
i) Počátek
ii) Spolupráce
iii) Konstrukce a
iv) Přechod
RUP široce zahrnuje nástroje IBM Rational.
Ukázkové testovací případy pro bankovní aplikace
Testovací případy pro novou pobočku
- Vytvořte novou větev s platnými a neplatnými daty testu.
- Vytvořte novou větev bez dat.
- Vytvořte novou větev se stávajícími daty pobočky.
- Ověřte možnosti resetování a zrušení.
- Aktualizujte podrobnosti větve o platná a neplatná data testu.
- Aktualizujte podrobnosti větve o existující testovací data větve.
- Ověřte, zda lze novou větev uložit.
- Ověřte, že možnost zrušení funguje.
- Ověřte odstranění větve se závislostmi i bez nich.
- Ověřte, zda možnost hledání pobočky funguje.
Testovací případy pro novou roli
- Vytvořte novou roli s platnými a neplatnými daty testu.
- Vytvořte novou roli bez dat.
- Ověřte, zda lze pomocí existujících testovacích dat vytvořit novou roli.
- Ověřte popis role a typy rolí.
- Ověřte, zda možnost zrušení a resetování funguje.
- Ověřte proces mazání rolí se závislostí i bez ní.
- Ověřte odkazy na stránce podrobností role.
- Ověřte přihlášení správce bez testovacích dat.
- Ověřte všechny domovské odkazy pro roli správce.
- Ověřte, že správce může změnit heslo s platnými a neplatnými daty testu.
- Ověřte, že se administrátor úspěšně odhlásil.
Testovací případy pro zákazníka a bankéře
- Ověřte, zda všechny odkazy návštěvníků a zákazníků fungují správně.
- Ověřte přihlašovací údaje zákazníka pomocí platných a neplatných testovacích údajů.
- Ověřte přihlášení zákazníka bez jakýchkoli údajů.
- Ověřte přihlášení bankéře bez jakýchkoli údajů.
- Ověřte přihlášení bankéře pomocí platných nebo neplatných testovacích údajů.
- Ověřte, zda se zákazník nebo bankéř může úspěšně odhlásit.
Testovací případy pro nové uživatele
- Ověřte, zda lze nového uživatele vytvořit pomocí platných a neplatných testovacích dat.
- Vytvořte nového uživatele s existujícími daty testu větve
- Ověřte, zda možnost zrušení a obnovení funguje správně.
- Aktualizujte údaje o uživateli platnými a neplatnými údaji o testu.
- Ověřte odstranění nového uživatele.
- zkontrolujte, zda lze nového uživatele ověřit.
- Ověřte povinné vstupní parametry.
- Ověřte volitelné vstupní parametry.
- Ověřte, zda lze uživatele vytvořit bez volitelných parametrů.
Testovací případy pro vytvoření nového účtu
- Vytvořte nový účet s platnými a neplatnými uživatelskými údaji.
- Ověřte, zda lze aktualizovat údaje o uživateli.
- Ověřte, zda lze uložit nového uživatele.
- Vytvořte nový účet s údaji stávajícího uživatele.
- Ověřte, že uživatel může vložit částku na nově vytvořený účet (a aktualizovat zůstatek).
- Ověřte, že uživatel může vybrat částku z nového účtu (po vkladu a aktualizaci zůstatku).
- V případě platu účet ověří název společnosti a další podrobnosti poskytne uživatel.
- Ověřte, zda je v případě sekundárního účtu zadáno číslo primárního účtu.
- Ověřte údaje o uživateli poskytnuté v případech aktuálního účtu.
- V případě společného účtu ověřte poskytnuté doklady ke společnému účtu.
- Ověřte, zda je možné udržovat nulový zůstatek na mzdovém účtu.
- Ověřte, zda je možné udržovat nulový zůstatek nebo minimální zůstatek pro nemzdový účet.
- Ověřte, že se nový uživatel může úspěšně odhlásit.
Testovací případy pro aplikace v oblasti bankovnictví
- Zkontrolujte, zda je uživatel schopen otevřít web banky.
- Zkontrolujte, zda fungují všechny odkazy na webu.
- Ověřte, zda je uživatel schopen vytvořit nový účet.
- Zkontrolujte, zda je uživatel schopen se přihlásit pomocí platného a neplatného uživatelského jména a hesla.
- Ověřte, zda je některé z uživatelských jmen nebo hesel při přihlášení prázdné, uživateli by nemělo být umožněno přihlášení a zobrazí se výstražná zpráva.
- Zkontrolujte, zda má uživatel povoleno měnit heslo.
- Pokud je zadán neplatný uživatel nebo heslo, zobrazí se příslušná chybová zpráva.
- Uživatelé s neplatným heslem by neměli mít povoleno se přihlásit.
- Ověřte, že po opakovaných pokusech o přihlášení pomocí nesprávného hesla by se uživateli měla zobrazit chybová zpráva a být blokován.
- Zkontrolujte, zda je uživatel schopen provádět některé základní transakce.
- Ověřte, zda je uživatel schopen přidat příjemce s platnými a neplatnými údaji.
- Ověřte, zda uživatel může příjemce odstranit.
- Ověřte, zda je uživatel schopen provádět transakce s nově přidaným příjemcem.
- Po transakci ověřte, zda jsou aktualizovány účty uživatelů i příjemců.
- Zkontrolujte, zda je uživatel schopen zadat částku v desítkovém čísle.
- Ověřte, zda uživatel není schopen zadat záporná čísla do pole částky.
- Ověřte, zda má uživatel povoleno provádět transakce s minimálním zůstatkem nebo bez něj.
- Ověřte, zda uživatel může udělat nový RD.
- Ověřte, zda se zobrazuje správná zpráva v případě transakce provedené s nedostatečným zůstatkem.
- Před provedením jakékoli transakce zkontrolujte, zda je uživatel požádán o potvrzení.
- Ověřte, zda je při každé úspěšné transakci poskytnuto potvrzení.
- Ověřte, zda je uživatel schopen převést peníze na více účtů.
- ověřit, zda uživatel může transakci zrušit.
- Ověřte, že podrobnosti účtu odrážejí také provedené finanční transakce.
- Ověřte, zda je implementována funkce časového limitu.
- ověřte, že v případě časového limitu relace by se měl uživatel znovu přihlásit.
- ověřte, zda je v případě nečinnosti proveden správný časový limit relace.
- ověřte, že je uživatel při transakci převezen do zabezpečeného režimu.
- Ověřte, zda se uživatel může úspěšně odhlásit.
- Ověřte možnosti vyhledávání a resetování.
Závěr
V tomto článku jsme diskutovali jak složitá může být bankovní aplikace a jaké jsou typické fáze testování aplikace . Kromě toho jsme také diskutovali o současných trendech sledovaných IT průmysly, včetně metodik a nástrojů vývoje softwaru.
Neváhejte se podělit o své zkušenosti nebo dotazy týkající se tohoto tématu!
Doporučené čtení
- Jak otestovat aplikaci investičního bankovnictví (s 34+ důležitými testovacími scénáři)
- Jak otestovat systém retailového bankovnictví
- Jak otestovat aplikaci zdravotní péče - 1. část
- Nejlepší nástroje pro testování softwaru 2021 [QA Test Automation Tools]
- Alfa testování a beta testování (kompletní průvodce)
- Testování stahování e-knih Primer
- Funkční testování vs. nefunkční testování
- Instalace aplikací a jejich příprava na testování Appium