Menu

Testování aplikací ve zdravotnictví - tipy a důležité testovací scénáře (část 2)

testing healthcare applications tips

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

V minulém článku jsme provedli těžký trénink, pokud jde o porozumění doméně zdravotní péče. Jsme připraveni nasadit náš „testovací klobouk“ zpět a nyní se snažíme pochopit, jak testovat aplikace zdravotní péče.

=> Pokud jste ještě nečetli část 1, přečtěte si ji zde: Jak testovat aplikaci zdravotní péče - úvod

Nyní vybereme každou aplikaci / systém a vymyslíme podmínky, které u každé z nich ověříme.

Tento článek je užitečný pro testery, kteří již jsou v doméně zdravotní péče, nebo pro ty, kteří chtějí vstoupit do této nejžhavější kariérní oblasti.

Testování aplikací ve zdravotnictví

Začněme!

Co se naučíte:

Testování aplikací ve zdravotnictví - Vzorek Testovací scénáře

Toto jsou ukázkové testovací scénáře pro:

Systém zdravotního pojištění - testování komponent

Testování systému poskytovatele

# 1) Systém poskytovatelů by nám měl umožnit zadávat, upravovat a ukládat data poskytovatele.

#dva) Pozitivní tok Testování systému: zahrnout scénáře pro vstup do různých typů Poskytovatelů, jejich změnu, uložení a informace o nich.

# 3) Negativní tok Testování systému: zahrnout scénáře do

  • Uložte poskytovatele s neúplnými daty.
  • Uložte poskytovatele s datem účinnosti smlouvy kratším než datum licence poskytovatele.
  • Zadejte údaje o poskytovateli, který je již v systému k dispozici, a uložte je.

# 4) Testování integrace systému by měl zahrnovat scénáře k

  • Ověřte zdroj pro následné systémy, jako je systém pro člena, portál poskytovatele, systém reklamací a finanční systém.
  • Ověřte, zda jsou změny z portálu poskytovatele začleněny do záznamu příslušného poskytovatele.

Testování makléřského systému

# 1) Broker System by měl být schopen:

  • Zadejte, upravte a uložte data makléře.
  • Vypočítejte provizi makléře na základě podrobností o placení pojistného z členského systému.

#dva) Pozitivní tok Testování systému by mělo zahrnovat scénáře

  • Zadejte, upravte a uložte záznam zprostředkovatele pro různé typy zprostředkovatele.
  • Vypočítejte provizi pro aktivního makléře vytvořením informačního kanálu s příslušným záznamem pro členy s jiným plánem.

# 3) Negativní tok Testování systému by mělo zahrnovat scénáře

  • Zadejte záznam makléře s nedostatečnými daty a uložte jej pro různé typy makléře.
  • Vypočítejte provizi pro ukončeného makléře vytvořením souboru zdroje s příslušným záznamem pro členy s jiným plánem
  • Vypočítejte provizi pro neplatného makléře vytvořením souboru zdroje s příslušným záznamem pro členy s jiným plánem

# 4) Testování systému by měl zahrnovat scénáře k

  • Ověřte kanály do následných systémů, jako je portál Broker, finanční systém a členský systém.
  • Ověřte, zda jsou změny z portálu Broker začleněny do příslušného záznamu makléře.

Testování členského systému

Členský systém by měl být schopen:

otázky na pohovor o agilní metodě skrumáže
  1. Zaregistrujte, ukončete, obnovte a znovu zaregistrujte člena
  2. Přidat a odebrat závislého
  3. Vygenerujte prémiový účet
  4. Zpracovat platby pojistného

Zápis: V individuální pojistné smlouvě je pojistník přidán do plánu s účinným datem, od kterého bude platit pojistné za dávky poskytované pojistitelem a od kterého je způsobilý pro přihlašování pojistných událostí a pro získání krytí.

V zásadách skupiny je člen přidán do skupiny (která je již přidána v rámci plánu) s účinným datem, ke kterému je způsobilý pro podávání žádostí a pokrytí.

Ukončení: V individuální pojistce je pojistka ukončena s datem ukončení, na které pojistník nebude pojištěn pojistným plánem.

V zásadách skupiny lze buď samotného člena ukončit s datem ukončení, nebo lze ukončit celou skupinu.

Obnovení: Pokud ukončený člen požádá o opětovné aktivování zásad a aktuální datum je v odkladné lhůtě od data ukončení, může být člen obnoven bez mezery v pokrytí. Datum účinnosti zásady bude stejné staré datum účinnosti, nikoli aktuální datum.

Opětovná registrace: Pokud ukončený člen požádá o opětovné aktivování zásady a aktuální datum je mimo období odkladu od data ukončení, může být člen znovu zaregistrován s mezerou v pokrytí. Datum účinnosti zásady bude aktuální / budoucí datum a nebude to stejné staré datum účinnosti.

Například , Člen je zapsán v pojistné smlouvě s účinností od 1. 1. 2013 a je ukončen 31. 12. 2013. umožňuje nám trvat 30 dní jako ochranná lhůta stanovená pojišťovnou.

Případ 1: Pokud se člen vrátí 15. 1. 2014 a chce, aby politika byla účinná, pak je Obnovení pokud člen platí pojistné za období od 31. 12. 2013 do 15. 1. 2014, bude datum účinnosti pojistky stejné staré 1. 1. 2013.

Případ 2: Pokud se člen vrátí 1. 2. 2014 a chce, aby politika byla znovu účinná, pak je Opětovná registrace a datum účinnosti zásad bude 1. 2. 2014. Zde existuje mezera v pokrytí (1. 1. 2014 až 31. 1. 2014).

Pozitivní tok Testování systému by mělo zahrnovat scénáře

jak otevřít soubor dat na iphone
  • Zaregistrujte různé typy členů s minulými, současnými a budoucími daty účinnosti.
  • Změňte a informujte se o členech.
  • Vygenerujte prémiový účet pro aktivního člena na příští měsíc.
  • Ukončete aktivního člena s minulým, současným a budoucím datem ukončení, které je větší než datum účinnosti.
  • Znovu zaregistrujte ukončeného člena s minulými, současnými a budoucími daty účinnosti.
  • Obnovte ukončeného člena.

Negativní tok Testování systému by mělo zahrnovat scénáře

  • Zaregistrujte člena s nedostatečnými daty.
  • Vygenerujte prémiový účet pro příští měsíc pro ukončeného člena.

Testování integrace systému by měl zahrnovat scénáře k

  • Ověřte zdroj do navazujících systémů, jako je členský portál, portál poskytovatele, zprostředkovatelský systém, nárokový systém a finanční systém.
  • Ověřte, zda jsou změny z portálu člena začleněny do příslušného záznamu člena.
  • Zpracujte platbu vygenerovaného prémiového účtu krmivem z členského portálu, který obsahuje podrobnosti o provedené platbě.

Systém testování reklamací

Tvrzení ve zdravotnictví mají diagnostický kód a kód postupu, aby byla tvrzení podrobná.

  • Diagnostický kód: Odkazuje na nemoc, kterou pacient měl.
  • Kód postupu: Odkazuje na léčbu poskytnutou pacientovi.

Claims System by měl být schopen:

  • Zadávejte, upravujte a zpracovávejte nároky pro člena i závislou osobu.
  • Měl by házet chyby pro neplatné nároky na základě nesprávně zadaných údajů.

Pozitivní tok Testování systému by mělo zahrnovat scénáře pro vstup, úpravy a zpracování deklarací pro člena i závislého člena.

Negativní tok Testování systému by mělo zahrnovat scénáře

  • Zadejte a ověřte reklamaci s neplatným diagnostickým kódem a kódem postupu.
  • Zadejte a ověřte nárok pomocí neaktivního ID poskytovatele.
  • Zadejte a ověřte nárok u ukončeného člena.

Testování integrace systému by mělo zahrnovat scénáře k ověření přívodu do následných systémů, jako je portál financí a poskytovatelů.

Testování finančního systému

Finanční systém by měl být schopen psát výplaty a provádět platby EFT příslušnému příjemci zpracováním zdrojů z různých předcházejících systémů, jako jsou systémy pohledávek, členů, poskytovatelů a makléřů.

Pozitivní tok Testování systému by mělo zahrnovat scénáře ke kontrole, zda je pro platbu zvolena správná adresa nebo číslo účtu pro příslušného poskytovatele, člena nebo makléře.

Negativní tok Testování systému by mělo zahrnovat scénáře

  • Zkontrolujte, zda je platba provedena za neplatné ID člena, poskytovatele nebo makléře vytvořením příslušných záznamů ve zdroji.
  • Zkontrolujte, zda je platba za neplatnou částku (nulová nebo záporná) pro člena, poskytovatele nebo zprostředkovatele vytvořením příslušných záznamů ve zdroji.

Testování integrace systému není nutné, protože nemá žádné následné systémy a kanály z upstream jsou ověřovány při testování integrace systému příslušných systémů.

Testování členského portálu

Členský portál by měl být schopen:

  • Zobrazit podrobnosti zásad a stav nároku.
  • Proveďte žádosti o změnu v podrobnostech zásad.
  • Provádějte platby pojistného.

Pozitivní tok Testování systému by mělo zahrnovat scénáře

  • Přihlaste se a zobrazte podrobnosti zásad a stav nároku.
  • Požádat o změnu za účelem změny adresy, jména, telefonního čísla atd.
  • Provádějte platby pojistného.

Negativní tok Testování systému by mělo zahrnovat scénáře

  • Přihlaste se s neplatnými přihlašovacími údaji.
  • Proveďte platbu za zaplacený účet za pojistné.
  • Proveďte platbu s neplatným šekem.

Testování integrace systému není nutné, protože nemá žádné navazující systémy a kanály z upstream systémů jsou ověřovány při testování integrace systémů příslušných systémů.

Testování portálu poskytovatele

Portál poskytovatele by měl být schopen:

  • Zobrazit podrobnosti poskytovatele, podrobnosti o členech a stav nároku.
  • V podrobnostech poskytovatele proveďte žádosti o změnu.

Pozitivní tok Testování systému by mělo zahrnovat scénáře

  • Přihlaste se a zobrazte podrobnosti poskytovatele, podrobnosti o členech a stav nároku.
  • Požádat o změnu za účelem změny adresy, jména, telefonního čísla atd.

Negativní tok Testování systému by mělo zahrnovat scénáře

  • Přihlaste se s neplatnými přihlašovacími údaji
  • Zobrazit podrobnosti člena s neplatným ID člena

Testování systémové integrace není nutné, protože nemá žádné navazující systémy a kanály z upstream systému jsou ověřovány při testování systémové integrace příslušných systémů.

Testování portálu brokera

Broker Portal by měl být schopen:

  • Zobrazit podrobnosti makléře a platby provize.
  • Proveďte žádosti o změnu v podrobnostech makléře.

Pozitivní tok Testování systému by mělo zahrnovat scénáře

  • Přihlaste se a prohlédněte si podrobnosti makléře a platbu provize.
  • Požádat o změnu za účelem změny adresy, jména, telefonního čísla atd.

Negativní tok Testování systému by mělo zahrnovat scénáře pro přihlášení s neplatnými přihlašovacími údaji.

Testování integrace systému není nutné, protože nemá žádné následné systémy a kanály z upstream jsou ověřovány v Testování integrace systému příslušných systémů.

To je vše - to jsou všechny moduly a aspekty, které bychom v nich testovali.

Důležité tipy pro testování zdravotnického softwaru

Tip č. 1) Data jsou důležitá a musí být přesná, protože nepatrná změna data může způsobit, že hlavní vada nebude zaznamenána.

Tip č. 2) Ve zdravotnictví existuje mnoho testovacích parametrů, jako jsou různé typy plánů, členové, poskytovatelé, makléři, metoda výpočtu provize atd. - proto je třeba dávat pozor při navrhování testovacích případů tím, že má sled parametrů pokrytý a nepokrytý.

Tip č. 3) Znát firemní uživatele pro příslušné systémy a přemýšlejte z jejich perspektivy najít nejlepší závady.

Tip č. 4) Pro testování systému není nutné dodržovat stejné pořadí a zde uvedené scénáře pokrývají pouze celkovou funkčnost aplikace zdravotní péče. Možná budete muset zahrnout několik dalších scénářů (více tipů na tento příspěvek) na základě požadavků, které obdržíte.

Tip č. 5) Zdravotní péče nyní směřuje k nákladově efektivnímu způsobu poskytování péče. Zavedli tedy výměnný model, kdy si předplatitel může prohlédnout plány dané všemi pojistiteli, což zvyšuje konkurenční povahu pojistitelů, čímž nepřímo uvádí potřebu snížení nákladů.

Jak se zdravotní péče vyvíjí, bude potřeba změnit používaný software a dojde k příjmu IT vytvořením, úpravami a testováním příslušných softwarových aplikací - což znamená, že v této oblasti můžeme očekávat další projekty. Pokud vás to tedy zajímá, dávejte pozor.

Tip č. 6) Klíčem k úspěchu v testování aplikací zdravotní péče jsou tvrzení - jejich úplná znalost a způsob jejich posuzování atd.

Závěr

To pokrývá základy oboru zdravotní péče a způsob testování aplikací ve zdravotnictví.

Jako testeři víme, že nic není bez vad. Tento článek může mít také některé vady, pokud zjistíte vadu nebo máte dotaz, zanechte prosím komentář. Uvítáme vaši cennou zpětnou vazbu k článku, protože nás posune k dokonalosti a zlepšení.

Přeji vám vše nejlepší pro vaše budoucí úsilí jako testera zdravotní péče. Nashledanou!

Doporučené čtení

^