Menú

Proves d'aplicacions sanitàries: consells i escenaris importants de proves (part 2)

testing healthcare applications tips

Proveu El Nostre Instrument Per Eliminar Problemes

En l’últim article, vam fer un gran esforç pel que fa a la comprensió del domini sanitari. Estem preparats per tornar-nos a posar el barret de tester i ara intentem entendre com provar les aplicacions d’assistència sanitària.

=> Si no heu llegit la primera part, llegiu-la aquí: Com provar l'aplicació d'assistència sanitària - Introducció

Ara anem a triar cada aplicació / sistema i oferirem condicions que validarem en cadascuna d’elles.

Aquest article és útil per als provadors que ja formen part del domini de la salut o per als que vulguin entrar en aquest camp professional més calent.

Proves d

Comencem!

Què aprendreu:

Proves d 'aplicacions sanitàries Mostra Escenaris de prova

Aquests són els escenaris de prova de mostra per a:

Sistema d

Proves del sistema de proveïdor

# 1) El sistema del proveïdor ens ha de permetre introduir, editar i desar dades del proveïdor.

# 2) Flux positiu Proves del sistema: inclou escenaris per introduir diferents tipus de proveïdors, canviar-los, desar-los i consultar-los.

# 3) Flux negatiu Proves del sistema: inclou escenaris a

  • Deseu un proveïdor amb dades incompletes.
  • Deseu un proveïdor amb una data de vigència del contracte inferior a la data de llicència del proveïdor.
  • Introduïu les dades del proveïdor que ja estan disponibles al sistema i deseu-les.

# 4) Proves d’integració de sistemes ha d'incloure escenaris a

  • Valideu el feed a sistemes posteriors, com ara el feed to Member, el portal del proveïdor, el sistema de reclamacions i el sistema de finançament.
  • Valideu si els canvis del portal del proveïdor s’incorporen al registre del proveïdor respectiu.

Proves del sistema de corredor

# 1) El sistema de corredors hauria de ser capaç de fer el següent:

  • Introduïu, editeu i deseu les dades del corredor.
  • Calculeu la comissió del corredor en funció de les dades de pagament premium del sistema membre.

# 2) Flux positiu Les proves del sistema haurien d'incloure escenaris a

  • Introduïu, editeu i deseu el registre del corredor per als diferents tipus del corredor.
  • Calculeu la comissió del corredor actiu creant un fitxer de feeds amb el registre corresponent per als membres amb un pla diferent.

# 3) Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Introduïu un registre de broker amb dades insuficients i deseu-lo per als diferents tipus de broker.
  • Calculeu la comissió del corredor cessat creant un fitxer d'informació amb el registre corresponent per als membres amb un pla diferent
  • Calculeu la comissió del corredor no vàlid creant un fitxer de feeds amb el registre corresponent per als membres amb un pla diferent

# 4) Proves del sistema ha d'incloure escenaris a

  • Valideu els canals als sistemes posteriors, com ara el portal del corredor, el sistema financer i el sistema membre.
  • Valideu si els canvis del portal del corredor s’incorporen al registre corresponent del corredor.

Proves del sistema membre

El sistema membre ha de ser capaç de fer el següent:

tipus de metadades al magatzem de dades
  1. Inscriviu, rescindiu, restabliu i torneu a inscriure un membre
  2. Afegir i eliminar un dependent
  3. Genereu factura premium
  4. Tramiteu pagaments de primes

Inscripció: En una pòlissa individual, un assegurat s’afegeix en virtut d’un pla amb una data efectiva a partir de la qual pagarà una prima pels beneficis proporcionats per l’asseguradora i dels quals és elegible per presentar reclamacions i rebre cobertura.

A la política de grup, s'afegeix un membre al grup (que ja s'afegeix en virtut d'un pla) amb una data efectiva de la qual és apte per presentar reclamacions i rebre cobertura.

Finalització: En una pòlissa individual, la pòlissa finalitza amb una data de finalització de la qual un assegurat no estarà cobert pel pla d’assegurança.

A la política de grups, es pot donar de baixa al membre sol amb una data de finalització o bé es pot donar per acabat tot el grup.

Restabliment: Si un membre cessat sol·licita que la pòlissa estigui activa de nou i la data actual es troba dins del període de gràcia a partir de la data de finalització, el membre es pot restablir sense un buit de cobertura. La data de vigència de la política serà la mateixa data de vigència anterior i no la data actual.

Reinscripció: Si un membre cessat sol·licita que la pòlissa estigui activa de nou i la data actual superi el període de gràcia des de la data de finalització, el membre es podrà tornar a inscriure amb un buit de cobertura. La data de vigència de la política serà la data actual / futura i no serà la mateixa data de vigència anterior.

Per exemple , Un membre està inscrit en una pòlissa amb data de vigència com a 01/01/2013 i finalitzada el 31/12/2013. ens permet triar 30 dies com a període de gràcia fixat per la companyia d'assegurances.

Cas 1: Si el membre torna el 15/01/2014 i vol que la política sigui efectiva, ho serà Reincorporació si el membre paga la prima per al període 31/12/2013 a 15/01/2014, la data d'efectivitat de la pòlissa serà la mateixa antiga 01/01/2013.

Cas 2: Si el membre torna l’1 / 2/2014 i vol que la política torni a ser efectiva, ho serà Reinscripció i la data d’efectivitat de la política serà l’1 / 2/2014. Aquí hi ha un buit en la cobertura (01/01/2014 a 31/01/2014).

Flux positiu Les proves del sistema haurien d'incloure escenaris a

  • Inscriviu diferents tipus de membres amb dates efectives passades, actuals i futures.
  • Canvieu i consulteu els membres.
  • Genereu una factura premium per a un membre actiu per al mes que ve.
  • Cancel·leu un membre actiu amb una data de finalització anterior, actual i futura superior a la data efectiva.
  • Torneu a inscriure un membre cessat amb dates efectives passades, actuals i futures.
  • Restableix un membre cessat.

Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Inscriviu un membre amb dades insuficients.
  • Genereu una factura premium per al mes que ve per a un membre cessat.

Proves d’integració de sistemes ha d'incloure escenaris a

on s’emmagatzemen els APK a Android
  • Valideu el feed a sistemes posteriors, com ara el portal de membres, el portal del proveïdor, el sistema de corredors, el sistema de reclamacions i el sistema de finançament.
  • Valideu si els canvis del portal Membres s’incorporen al registre de membres respectiu.
  • Tramiteu el pagament d'una factura premium generada amb el feed del portal Membres que conté detalls del pagament.

Sistema de proves de reclamacions

Les reclamacions en salut tenen un codi de diagnòstic i un codi de procediment perquè la reclamació sigui detallada.

  • Codi de diagnòstic: Es refereix a la malaltia que tenia el pacient.
  • Codi de procediment: Fa referència al tractament que es proporciona al pacient.

El sistema de reclamacions hauria de ser capaç de fer el següent:

  • Introduïu, editeu i processeu reclamacions tant per al membre com per a un dependent.
  • S'han de generar errors per a reclamacions no vàlides basades en les dades incorrectes introduïdes.

Flux positiu La prova del sistema ha d'incloure escenaris per introduir, editar i processar reclamacions per al membre, així com per a un dependent.

Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Introduïu i valideu una reclamació amb un codi de diagnòstic i un codi de procediment no vàlids.
  • Introduïu i valideu una reclamació amb un identificador de proveïdor inactiu.
  • Introduïu i valideu una reclamació amb un membre cancel·lat.

Les proves d’integració de sistemes han d’incloure escenaris per validar l’alimentació de sistemes posteriors, com ara el portal de finances i proveïdors.

Proves del sistema financer

El sistema financer hauria de ser capaç d’escriure xecs de pagament i fer pagaments per EFT al destinatari respectiu mitjançant el processament dels feeds de diversos sistemes ascendents, com ara reclamacions, membres, proveïdors i sistemes d’intermediació.

Flux positiu La prova del sistema hauria d’incloure escenaris per comprovar si s’ha escollit l’adreça o el número de compte correctes per al proveïdor, membre o intermediari corresponent per al pagament.

Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Comproveu si es realitza el pagament per l’identificador de membre, proveïdor o intermediari no vàlid mitjançant la creació de registres respectius al feed.
  • Comproveu si el pagament es fa per l'import no vàlid (zero o negatiu) per al membre, el proveïdor o l'agent creant registres respectius al feed.

Les proves d’integració del sistema no són necessàries, ja que no tenen sistemes posteriors i els fluxos provinents del riu amunt es validen a les proves d’integració de sistemes dels sistemes respectius.

Prova del portal de membres

El portal per a membres ha de ser capaç de fer el següent:

  • Consulteu els detalls de la política i l’estat de la reclamació.
  • Feu sol·licituds de canvi als detalls de la política.
  • Feu pagaments de primes.

Flux positiu Les proves del sistema haurien d'incloure escenaris a

  • Inicieu la sessió i consulteu els detalls de la política i l’estat de la reclamació.
  • Feu una sol·licitud de canvi per canviar l'adreça, el nom, el número de telèfon, etc.
  • Feu pagaments de primes.

Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Inicieu la sessió amb credencials no vàlides.
  • Feu el pagament d’una factura premium pagada.
  • Efectueu el pagament amb un xec no vàlid.

Les proves d’integració de sistemes no són necessàries, ja que no tenen cap sistema aigües avall i les fonts dels sistemes aigües amunt es validen a les proves d’integració de sistemes de sistemes respectius.

Proves del portal del proveïdor

El portal del proveïdor hauria de ser capaç de fer el següent:

  • Consulteu els detalls del proveïdor, els detalls dels membres i l’estat de la reclamació.
  • Feu sol·licituds de canvi a la informació del proveïdor.

Flux positiu Les proves del sistema haurien d'incloure escenaris a

  • Inicieu la sessió i consulteu els detalls del proveïdor, les dades dels membres i l’estat de la reclamació.
  • Feu una sol·licitud de canvi per canviar l'adreça, el nom, el número de telèfon, etc.

Flux negatiu Les proves del sistema haurien d'incloure escenaris a

  • Inicieu la sessió amb credencials no vàlides
  • Veure els detalls del membre amb un identificador de membre no vàlid

Les proves d’integració de sistemes no són necessàries, ja que no tenen cap sistema aigües avall i les fonts del sistema aigües amunt es validen a les proves d’integració de sistemes de sistemes respectius.

Prova del portal del corredor

El portal de corredors hauria de ser capaç de fer el següent:

  • Consulteu els detalls del corredor i el pagament de comissions.
  • Feu sol·licituds de canvi als detalls del corredor.

Flux positiu Les proves del sistema haurien d'incloure escenaris a

  • Inicieu sessió i consulteu els detalls del corredor i el pagament de comissions.
  • Feu una sol·licitud de canvi per canviar l'adreça, el nom, el número de telèfon, etc.

Flux negatiu La prova del sistema ha d'incloure escenaris per iniciar la sessió amb credencials no vàlides.

Les proves d’integració del sistema no són necessàries, ja que no tenen sistemes posteriors i els fluxos provinents del riu amunt es validen a les proves d’integració del sistema dels sistemes respectius.

Això és tot: són tots els mòduls i els aspectes que provaríem en ells.

Consells importants per provar el programari sanitari

Consell 1) Les dates són importants i han de ser exactes perquè un lleuger canvi de data pot provocar que es noti un defecte important.

Consell núm. 2) A Healthcare, hi ha molts paràmetres de prova, com ara diferents tipus de pla, membres, proveïdors, corredors, mètode de càlcul de comissions, etc., de manera que s’ha de tenir precaució disseny de casos de prova en tenir una pista de paràmetres coberts i no coberts.

Consell núm. 3) Conegueu els usuaris empresarials dels sistemes respectius i pensar des de la seva perspectiva per trobar els millors defectes.

Consell núm. 4) No cal seguir el mateix ordre per a les proves del sistema i els escenaris que es proporcionen aquí només cobreixen la funcionalitat general d’una aplicació sanitària. És possible que també hàgiu d'incloure alguns escenaris més (més consells a això publicació) en funció dels requisits que rebeu.

millor tallafoc per a Windows 7 de 64 bits

Consell núm. 5) L’assistència sanitària s’està avançant cap a una manera rendible de proporcionar atenció. Així, han introduït un model d'intercanvi on el subscriptor pot tenir una visió dels plans de totes les asseguradores que augmenta la naturalesa competitiva de les asseguradores i, de manera indirecta, afirma la necessitat de reduir els costos.

A mesura que l’assistència sanitària evolucionarà, hi haurà la necessitat de canviar el programari que s’utilitza i els ingressos derivats de la TI es generaran, modificaran i provaran les aplicacions de programari implicades, cosa que significa que podem anticipar més projectes en aquest domini. Per tant, vigileu si això us interessa.

Consell núm. 6) La clau de l’èxit en les proves d’aplicació d’atenció mèdica són les reclamacions: el coneixement complet d’elles i com s’adjudiquen, etc.

Conclusió

Bé, això inclou els conceptes bàsics del domini sanitari i una manera de provar les aplicacions sanitàries.

Com a provadors, sabem que res és lliure de defectes. Aquest article també pot tenir alguns defectes, si trobeu algun defecte o teniu alguna pregunta, si us plau, deixeu un comentari. Agraïm els vostres valuosos comentaris sobre l'article, ja que ens conduirà cap a l'excel·lència i la millora.

Us desitjo tot el millor per al vostre futur esforç com a provador de salut. Ja ens veurem!

Lectura recomanada

^