Menú

Prueba de aplicaciones sanitarias: consejos y escenarios de prueba importantes (parte 2)

testing healthcare applications tips

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

En el último artículo, hicimos un trabajo pesado en términos de comprensión del dominio de la atención médica. Estamos listos para ponernos de nuevo nuestro 'sombrero de tester' y ahora intentamos entender cómo probar las aplicaciones de atención médica.

=> Si no ha leído la parte 1, léala aquí: Cómo probar la aplicación de atención médica - Introducción

Ahora vamos a elegir cada aplicación / sistema y plantear las condiciones que vamos a validar en cada uno de ellos.

Este artículo es útil para los probadores que ya están en el dominio de la atención médica o para aquellos que desean ingresar en este campo profesional más candente.

Prueba de aplicaciones sanitarias

¡Empecemos!

Lo que vas a aprender:

Pruebas de aplicaciones sanitarias: el Muestra Escenarios de prueba

Estos son los escenarios de prueba de muestra para:

Sistema de seguro médico: componentes de prueba

Prueba del sistema del proveedor

#1) El sistema del proveedor debe permitirnos ingresar, editar y guardar los datos del proveedor.

#2) Flujo positivo Prueba del sistema: incluir escenarios para ingresar a diferentes tipos de Proveedores, modificarlos, guardarlos y consultarlos.

#3) Flujo negativo Prueba del sistema: incluir escenarios para

  • Guarde un proveedor con datos incompletos.
  • Guarde un proveedor con una fecha de vigencia del contrato menor que la fecha de la licencia del proveedor.
  • Ingrese los datos del proveedor que ya están disponibles en el sistema y guárdelos.

#4) Prueba de integración del sistema debe incluir escenarios para

  • Valide la alimentación a los sistemas posteriores, como la alimentación al sistema de miembros, el portal de proveedores, el sistema de reclamaciones y el sistema financiero.
  • Validar si los cambios del portal de proveedores están incorporados en el registro de proveedor respectivo.

Prueba del sistema de corredor

#1) Broker System debe ser capaz de lo siguiente:

  • Ingrese, edite y guarde los datos del corredor.
  • Calcule la comisión del corredor según los detalles del pago de la prima del sistema de miembros.

#2) Flujo positivo Las pruebas del sistema deben incluir escenarios para

  • Ingrese, edite y guarde el registro del corredor para diferentes tipos de corredor.
  • Calcule la comisión para el corredor activo creando un archivo de alimentación con el registro respectivo para miembros con un plan diferente.

#3) Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Ingrese un registro de corredor con datos insuficientes y guárdelo para diferentes tipos de corredor.
  • Calcule la comisión para el corredor rescindido creando un archivo de alimentación con el registro respectivo para miembros con un plan diferente
  • Calcule la comisión para el corredor inválido creando un archivo de alimentación con el registro respectivo para miembros con un plan diferente

#4) Prueba del sistema debe incluir escenarios para

  • Valide las fuentes de los sistemas posteriores, como el portal del corredor, el sistema financiero y el sistema de miembros.
  • Validar si los cambios del portal del Broker están incorporados en el registro del broker respectivo.

Prueba del sistema miembro

El sistema miembro debe ser capaz de lo siguiente:

mejores estudios de juegos para trabajar
  1. Inscribir, rescindir, reinstalar y volver a inscribir a un miembro
  2. Agregar y eliminar un dependiente
  3. Generar factura premium
  4. Procesar pagos de primas

Inscripción: En una póliza individual, un asegurado se agrega a un plan con una fecha de vigencia a partir de la cual pagará una prima por los beneficios proporcionados por la aseguradora y de la cual es elegible para presentar reclamos y recibir cobertura.

En la póliza de grupo, un miembro se agrega al grupo (que ya se agregó a un plan) con una fecha de vigencia en la cual él / ella es elegible para presentar reclamos y recibir cobertura.

Terminación: En una póliza individual, la póliza se termina con una fecha de terminación de la cual el titular de la póliza no estará cubierto por el plan de seguro.

En la Política de grupo, se puede dar de baja al miembro solo con una fecha de finalización o se puede dar de baja a todo el grupo.

Reinstalación: Si un miembro cancelado solicita que la póliza vuelva a estar activa y la fecha actual está dentro del período de gracia a partir de la fecha de terminación, entonces el miembro puede ser reintegrado sin una interrupción en la cobertura. La fecha de vigencia de la póliza será la misma fecha de vigencia anterior y no la fecha actual.

Reinscripción: Si un miembro cancelado solicita que la póliza vuelva a estar activa y la fecha actual supera el período de gracia a partir de la fecha de terminación, entonces el miembro puede volver a inscribirse con un período sin cobertura. La fecha de vigencia de la póliza será la fecha actual / futura y no será la misma fecha de vigencia anterior.

Por ejemplo , Un miembro está inscrito en una póliza con una fecha de vigencia como 1/1/2013 y termina el 12/31/2013. nos permite tomar 30 días como el período de gracia fijado por la compañía de seguros.

Caso 1: Si el miembro regresa el 15/1/2014 y quiere que la política sea efectiva, entonces es Reinstalación Si el miembro paga la prima para el período del 31/12/2013 al 15/1/2014, la fecha de vigencia de la póliza será la misma del 1/1/2013.

Caso 2: Si el miembro regresa el 2/1/2014 y quiere que la política sea efectiva nuevamente, entonces es Reinscripción y la fecha de vigencia de la póliza será el 2/1/2014. Aquí hay una brecha en la cobertura (1/1/2014 a 1/31/2014).

cómo instalar eclipse c ++

Flujo positivo Las pruebas del sistema deben incluir escenarios para

  • Inscribe a diferentes tipos de miembros con fechas de vigencia pasadas, actuales y futuras.
  • Cambie y pregunte sobre los miembros.
  • Genere una factura de prima para un miembro activo para el próximo mes.
  • Dar de baja a un miembro activo con una fecha de terminación pasada, actual y futura mayor que la fecha de vigencia.
  • Vuelva a inscribir a un miembro cancelado con fechas de vigencia pasadas, actuales y futuras.
  • Reincorporar a un miembro cesado.

Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Inscribe a un miembro con datos insuficientes.
  • Genere una factura de prima para el próximo mes para un miembro cancelado.

Prueba de integración del sistema debe incluir escenarios para

  • Valide la alimentación a los sistemas posteriores, como el portal de miembros, el portal de proveedores, el sistema de corredores, el sistema de reclamaciones y el sistema de finanzas.
  • Validar si los cambios del portal de miembros están incorporados en el registro de miembro respectivo.
  • Procese el pago de una factura premium generada con el feed del portal de miembros que tiene detalles del pago realizado.

Prueba del sistema de reclamaciones

Los reclamos en el cuidado de la salud tienen un código de diagnóstico y un código de procedimiento para que el reclamo sea detallado.

  • Código de diagnóstico: Se refiere a la enfermedad que tenía el paciente.
  • Código de procedimiento: Se refiere al tratamiento que se le brinda al paciente.

El sistema de reclamaciones debe ser capaz de lo siguiente:

  • Ingrese, edite y procese reclamos para el miembro y un dependiente.
  • Debe arrojar errores por reclamos no válidos basados ​​en los datos incorrectos ingresados.

Flujo positivo Las pruebas del sistema deben incluir escenarios para ingresar, editar y procesar reclamos tanto para el miembro como para un dependiente.

Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Ingrese y valide una reclamación con un código de diagnóstico y un código de procedimiento no válidos.
  • Ingrese y valide un reclamo con una identificación de proveedor inactiva.
  • Ingrese y valide un reclamo con un miembro cancelado.

Las pruebas de integración de sistemas deben incluir escenarios para validar la alimentación de los sistemas posteriores, como el portal de finanzas y proveedores.

Prueba del sistema financiero

El sistema financiero debe ser capaz de emitir cheques de pago y realizar pagos mediante transferencia electrónica de fondos al destinatario respectivo mediante el procesamiento de las fuentes de varios sistemas ascendentes, como reclamos, miembros, proveedores y sistemas de corredores.

Flujo positivo Las pruebas del sistema deben incluir escenarios para verificar si se elige la dirección o el número de cuenta correctos para el respectivo proveedor, miembro o corredor para el pago.

Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Verifique si el pago se realiza para el miembro, proveedor o ID de corredor no válido creando los registros respectivos en el feed.
  • Verifique si el pago se realiza por el monto no válido (cero o negativo) para el miembro, proveedor o corredor creando los registros respectivos en el feed.

Las pruebas de integración del sistema no son necesarias, ya que no tiene ningún sistema posterior y las fuentes del flujo ascendente se validan en las pruebas de integración del sistema de los sistemas respectivos.

Prueba del portal de miembros

El Portal para miembros debe tener la capacidad de lo siguiente:

  • Ver los detalles de la póliza y el estado del reclamo
  • Realice solicitudes de cambio en los detalles de la política.
  • Realice pagos de primas.

Flujo positivo Las pruebas del sistema deben incluir escenarios para

  • Inicie sesión y vea los detalles de la póliza y el estado de la reclamación.
  • Realice una solicitud de cambio para cambiar la dirección, el nombre, el número de teléfono, etc.
  • Realice pagos de primas.

Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Inicie sesión con credenciales no válidas.
  • Realice el pago de una factura de prima pagada.
  • Realice el pago con un cheque no válido.

Las pruebas de integración del sistema no son necesarias, ya que no tiene ningún sistema descendente y las fuentes de los sistemas ascendentes se validan en las pruebas de integración del sistema de los respectivos sistemas.

Prueba del portal de proveedores

El portal de proveedores debe ser capaz de lo siguiente:

  • Vea los detalles del proveedor, los detalles del miembro y el estado de la reclamación.
  • Realice solicitudes de cambio en los detalles del proveedor.

Flujo positivo Las pruebas del sistema deben incluir escenarios para

  • Inicie sesión y vea los detalles del proveedor, los detalles del miembro y el estado de la reclamación.
  • Realice una solicitud de cambio para cambiar la dirección, el nombre, el número de teléfono, etc.

Flujo negativo Las pruebas del sistema deben incluir escenarios para

  • Iniciar sesión con credenciales no válidas
  • Ver los detalles del miembro con una identificación de miembro no válida

Las pruebas de integración del sistema no son necesarias, ya que no tiene ningún sistema descendente y las fuentes del sistema ascendente se validan en las pruebas de integración del sistema de los respectivos sistemas.

Prueba del portal del corredor

Broker Portal debe ser capaz de lo siguiente:

  • Vea los detalles del corredor y el pago de comisiones.
  • Realice solicitudes de cambio en los detalles del corredor.

Flujo positivo Las pruebas del sistema deben incluir escenarios para

  • Inicie sesión y vea los detalles del corredor y el pago de comisiones.
  • Realice una solicitud de cambio para cambiar la dirección, el nombre, el número de teléfono, etc.

Flujo negativo Las pruebas del sistema deben incluir escenarios para iniciar sesión con credenciales no válidas.

Las pruebas de integración del sistema no son necesarias, ya que no tiene ningún sistema descendente y las alimentaciones del flujo ascendente se validan en las pruebas de integración del sistema de los sistemas respectivos.

Eso es todo, esos son todos los módulos y los aspectos que probaríamos en ellos.

Consejos importantes para probar software sanitario

Consejo n. ° 1) Las fechas son importantes y tienen que ser precisas porque un ligero cambio en la fecha puede hacer que un defecto importante pase desapercibido.

subcadena (0,0)

Consejo n. ° 2) En el sector de la salud, existen muchos parámetros de prueba, como diferentes tipos de planes, miembros, proveedores, corredores, método de cálculo de comisiones, etc., por lo que se debe tener cuidado al diseñar casos de prueba al tener una pista de parámetros cubiertos y no cubiertos.

Consejo n. ° 3) Conozca a los usuarios comerciales de los respectivos sistemas y piensa desde su perspectiva para encontrar los mejores defectos.

Consejo n. ° 4) No es necesario seguir el mismo orden para las pruebas del sistema y los escenarios proporcionados aquí solo cubren la funcionalidad general de una aplicación de atención médica. Es posible que también deba incluir algunos escenarios más (más sugerencias en esta publicación) según los requisitos que reciba.

Consejo n. ° 5) La atención médica se está moviendo ahora hacia una forma rentable de brindar atención. Por lo tanto, han introducido un modelo de intercambio en el que el suscriptor puede tener una visión de los planes dados por todas las aseguradoras, lo que aumenta la naturaleza competitiva de las aseguradoras, lo que indica indirectamente la necesidad de reducción de costos.

A medida que el cuidado de la salud evoluciona, será necesario el cambio en el software que se utiliza y se generarán ingresos para TI mediante la creación, modificación y prueba de las aplicaciones de software involucradas, lo que significa que podemos anticipar más proyectos en este dominio. Por lo tanto, esté atento, si esto le interesa.

Consejo n. ° 6) La clave del éxito en las pruebas de aplicaciones de atención médica son las afirmaciones: el conocimiento completo de ellas y cómo se adjudican, etc.

Conclusión

Bueno, eso cubre los conceptos básicos del dominio de la atención médica y una forma de probar las aplicaciones de atención médica.

Como probadores, sabemos que nada está libre de defectos. Este artículo también puede tener algunos defectos, si encuentra algún defecto o tiene alguna pregunta por favor deje un comentario. Agradecemos sus valiosos comentarios sobre el artículo, ya que nos conducirán hacia la excelencia y la mejora.

Le deseo todo lo mejor para sus futuros esfuerzos como evaluador de atención médica. ¡Nos vemos!

Lectura recomendada

^