7 Problemas en la validación de software que encontramos con frecuencia

Eludir los problemas de validación de software recurrentes te ahorra tiempo, dinero y otros recursos valiosos. Siguiendo la Ley de Pareto (80/20), la mayoría de estas incidencias están concentradas en 22 categorías. Aun así, te mostramos a qué debes estar atento durante este proceso. 

Principales problemas de validación de software en las organizaciones

Debido a la naturaleza del proceso, los problemas de validación de software suelen ser variados. Habitualmente, cuando las organizaciones no cuentan con la asesoría adecuada o les falta experiencia en este campo, aparecen fallas como: 

Ausencia de planificación 

Cualquier proyecto que esté relacionado con informática necesita de una buena hoja de ruta para su ejecución. Por este motivo, te recomendamos diseñar un plan de validación previo que considere los pasos necesarios antes de comenzar con las actividades. Debería ser un documento que describa el enfoque para mantener el estatus de validación del sistema. 

Asimismo, el plan debe mostrar el alcance de las actividades de validación, el propósito de las pruebas, las funciones del equipo de trabajo y los criterios de aceptación para el programa. Este documento también tendrían que incluir información específica sobre si el sistema está siendo analizado en varias pruebas y satisfacer las políticas regulatorias asociadas con las GMP. 

GDP deficientes (Buenas Prácticas de Documentación)

¿De que forma afectan los Problemas en la validación de software el cumplimiento de buenas practicas de documentacion

A pesar de que existen múltiples opciones para registrar, guardar y gestionar la información de forma eficiente, muchas empresas siguen apelando a métodos pocos efectivos: 

  • Datos faltantes

    . A menudo, resulta difícil encontrar la información que corrobora un requisito específico en la evidencia aportada. 

  • Pruebas incompletas

    . Los scripts de prueba no evaluaron de manera completa o adecuada el requisito asociado. Por ejemplo, una captura de pantalla llena de datos desorganizados. 

  • Evidencia de pruebas y datos a mano

    . Suele tratarse de los resultados de las pruebas que son registrados de tal forma que se prestan a confusión sobre su veracidad. 

  • Ambigüedades

    . Son registros que pueden ser entendidos de varias maneras y que no establecen un criterio exclusivo. Términos como “o” y “cualquiera” en los requisitos son indicativos claros de la falta de especificación. 

  • Correcciones hechas a mano

    . Con frecuencia, esta acción puede cambiar el sentido de un resultado esperado o de un requisito. Esto empeora si el personal no entrega un informe de discrepancia o una solicitud de enmienda. Dentro de las GDP, estas correcciones son permitidas sin documentación de apoyo siempre que se trate de errores ortográficos.

Imposibilidad de marcar trazabilidad

Aunque este aspecto puede ser crítico dentro del proceso, está entre los problemas de validación de software más recurrentes. Estas fallas están condensadas con 3 situaciones: 

  • La matriz de trazabilidad no dio cuenta de un paso de observación en las instrucciones de prueba (script) ni de una especificación trazable. 
  • El seguimiento estaba roto. Esto fue producto de: uno de los requisitos descritos o uno de los resultados de las pruebas era huérfano. También es posible que el requisito careciera de descendientes o pruebas. 
  • La matriz de trazabilidad estaba incompleta. Los detalles del requisito no estaban numerados de manera explícita ni trazados hacia los pasos de prueba vinculados. Los requisitos no fueron seguidos hacia el nivel del detalle, así que los inspectores tuvieron que inferir los enlaces detallados entre los pasos y especificaciones dentro del script de prueba. 

Resultados de pruebas no verificables 

Con frecuencia, los resultados esperados no son descritos de forma minuciosa para que el inspector independiente pueda compararlos y verificarlos con relación a los resultados reales. En el Estándar IEEE para la Documentación de la Prueba de Software (Std. 829.1988), su cláusula 6.2.4 establece: “… proporcione el valor exacto (con tolerancias donde corresponda) para cada característica u output requerido”. 

Para la secuencia de comandos ejecutada, los verdaderos resultados no fueron obtenidos o registrado de manera tal que le haya permitido al inspector independiente, compararlos con los resultados esperados. Por ejemplo, no se vio el “OK” en la columna resultado-real con referencia a una captura de pantalla. 

Requisitos definidos de forma incorrecta

Problemas en la validación de software que encontramos con frecuenciaCuando se trata de la implementación de un sistema, su actualización, extensión y más, esta labor debe estar acompañada de un análisis meticuloso del flujo de trabajo. Esto te permitirá contar con un conjunto preciso de requisitos. Sin esta condición, la validación del software en cuestión no podrá verificar si el sistema funciona como esperas. 

Si quieres evitar estos problemas de validación de software, necesitas requisitos funcionales y bien diseñados para garantizar la seguridad de la información. Estos deben estar listados y numerados dentro de una matriz que facilita su trazabilidad hacia otros documentos, como las instrucciones de prueba, el resumen de validación, el diseño de especificaciones, etc.

El hecho de tener requisitos definidos incorrectamente, puede conducir a instrucciones de prueba ambiguas. Esta situación aumenta la dificultad de saber qué es lo que se está probando con exactitud. En consecuencia, te será mucho más complicado confirmar a través de la validación del sistema que el software cumple con su propósito. 

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *