Pruebas automatizadas de software para el mundo GxP

La agrupación de pruebas para garantizar que tanto los riesgos como los requisitos estén cubiertos, y la automatización de la matriz de trazabilidad, es un aspecto crucial de las pruebas de software automatizadas. Es necesario realizar un seguimiento de las pruebas ejecutadas, adjuntar pruebas a esas ejecuciones y documentar el entorno utilizado.   

Además, es esencial determinar a qué características afectan los errores descubiertos y realizar un seguimiento de los rastros de las implementaciones fallidas, al tiempo que se mide el progreso mediante KPI, teniendo en cuenta las limitaciones de tiempo y presupuesto.

Después de corregir los errores, es necesario volver a ejecutar algunas pruebas para confirmar la corrección y asegurarse de que no se produzca ninguna regresión posterior mientras se realiza un seguimiento de los rastros de la implementación fallida. Después del lanzamiento, los resultados de la ejecución de las pruebas deben conservarse con fines de archivado y se deben seleccionar pruebas específicas para futuras pruebas de regresión. Es importante demostrar el efecto de la selección de pruebas en la matriz de trazabilidad, y cada ejecución futura de pruebas debe mantenerse en un archivo separado.

Todos los datos registrados durante el proceso de prueba se adhieren a los principios de ALCOA+.

Imagina una situación en la que hay diez parámetros, cada uno con cinco valores, que deben probarse en función de la evaluación de riesgos. Describir cada combinación de parámetros llevaría mucho tiempo.

También estamos reemplazando un sistema existente con un nuevo software y necesitamos asegurarnos de que el nuevo software proporcione las mismas respuestas que el anterior. Afortunadamente, el software antiguo sigue los principios de ALCOA+ y tenemos una base de datos de todas las decisiones y registros anteriores.

Para automatizar el proceso de creación de casos de prueba, creamos scripts, hojas de cálculo y extractos de bases de datos, entre otras herramientas.

Data exchange with authorities requires following a specific standard. The standard involves exchanging data via a comma-separated values file where the first and last lines include specifications such as file format, number of records, and timestamp, while each line in the middle represents a record with a fingerprint-based on complex mathematics.

As we replace our existing system with new software, we use test case deduction to test all different cases in the old database. To facilitate this process, we create two test oracles.

The first test oracle compares the decisions made by the new system with the decisions made by the old system stored in the old database. The second test oracle compares the output file with the authorities’ standard by checking each line, including fingerprint comparisons with its own calculations.

Como el sistema aún está en desarrollo, algunos componentes se pueden probar, pero es posible que ciertos componentes de entrada o salida aún no estén disponibles. Para superar este problema, creamos códigos auxiliares y controladores que reemplazan estos componentes con fines de prueba.

Una vez que el sistema esté disponible, requerirá un costoso dispositivo GC-MS para su operación. Como no tenemos el presupuesto para comprar uno para probar, lo reemplazamos con un trozo que replica el estado del dispositivo con un simple conjunto de luces.

Para asegurarnos de que nuestro plan de recuperación ante desastres funcione contra los fallos de GC-MS, debemos probar el software sin romper nuestro dispositivo GC-MS real. Para ello, utilizamos un código auxiliar para simular el evento de error.

Para mejorar la capacidad de mantenimiento del código fuente por parte de los miembros del equipo, hemos implementado pautas específicas para el formato y la organización del código, que se describen en una instrucción de trabajo. Además, nos adherimos a las mejores prácticas para el lenguaje de programación, que incluyen el formato de código adecuado y evitar las características del lenguaje que se consideran malas prácticas.

Estas directrices se verifican automáticamente a través del análisis de código estático y se genera un informe durante la noche para garantizar el cumplimiento de las convenciones establecidas. Además, la herramienta se despliega en las máquinas de los desarrolladores para detectar e informar de cualquier infracción en tiempo real a medida que realizan cambios en el código.

El código fuente sigue una estructura clara que utiliza diferentes niveles de abstracción, y utiliza objetos y funciones para representar conceptos y acciones, respectivamente.

El comportamiento del software es predecible, lo que nos permite crear pruebas para cada función y objeto, así como para sus interacciones. Estas pruebas se ejecutan automáticamente para asegurarse de que el software se comporta como se espera y los resultados se asocian con el software compilado.

Además de comprobar el comportamiento del software, también utilizamos pruebas a nivel de código para medir el porcentaje de declaraciones y decisiones que se ejecutan durante esas pruebas.

Un enfoque para desarrollar el software es utilizar la metodología ágil de desarrollo basado en pruebas, que implica crear primero pruebas unitarias y de integración y desarrollar el código hasta que todas las pruebas se superen con éxito.

Una vez que el desarrollador completa su trabajo, el código se agrega a un repositorio central de código fuente. Cada noche, utilizamos este repositorio central para construir el software y realizar pruebas unitarias y análisis de código estático. A continuación, conectamos los informes generados al software y los ponemos a disposición en un sitio web de intranet.

También creamos un informe que describe los cambios realizados desde la última compilación. Esto permite al equipo de QA acceder a la versión más actualizada del software con cierto grado de confianza y comprender qué modificaciones se han realizado.

Los scripts de prueba se han desarrollado para verificar las funciones del software con respecto a sus requisitos durante las cualificaciones de funcionamiento y de ejecución del proceso (OQ/PQ), lo que incluye la prueba de la interfaz de usuario.

Sin embargo, repetir estas pruebas con diferentes combinaciones de variables y realizar actividades de revalidación y regresión puede llevar mucho tiempo y desmotivar a los evaluadores.

Para hacer frente a esto, se ha implementado la automatización de pruebas de caja negra para automatizar la ejecución de estas pruebas.

Para garantizar que el sistema pueda manejar 100 conexiones simultáneas y terabytes de datos, empleamos una herramienta que genera 100 conexiones paralelas y envía datos continuamente hasta que se hayan procesado 100 terabytes. Las acciones de las conexiones pueden ser continuas o pausadas, y la herramienta proporciona informes sobre la capacidad de respuesta del sistema en todo el escenario. Esto nos permite verificar que el sistema puede manejar la carga requerida y proporciona información sobre posibles problemas de rendimiento.

Utilizamos una herramienta que realiza pruebas de seguridad mediante la aplicación de varios patrones de piratas informáticos para intentar violar la seguridad del software o hacer que no esté disponible. Se informan los resultados de cada prueba, indicando si el intento fue exitoso o fallido.

Las pruebas de software automatizadas proporcionan numerosos beneficios, el más evidente de los cuales es el ahorro de tiempo y costos. También reduce la variabilidad en la planificación, aumenta la trazabilidad y produce resultados más consistentes a través de la evaluación sistemática. Las pruebas automatizadas también permiten probar elementos inaccesibles que no pueden ser evaluados por humanos, y reduce la carga de las pruebas, haciéndolas menos tediosas y más atractivas para los evaluadores.

La introducción de una herramienta de prueba automatizada implica costos iniciales y continuos.
 
Adquirir conocimientos sobre la herramienta es un paso inicial necesario. Además, hay tareas como seleccionar y adquirir la herramienta, e integrarla en el ecosistema de la empresa y otras herramientas. Estas tareas requieren recursos y tiempo.
 
De forma continua, hay que tener en cuenta los costes de propiedad de las herramientas de  IT tradicionales, así como el mantenimiento y la adaptación de las pruebas a otras plataformas. El uso de la herramienta debe evaluarse y mejorarse constantemente para garantizar que siga siendo eficaz. Cualquier falta de disponibilidad de la herramienta podría afectar potencialmente a la estrategia empresarial.

Además de los riesgos habituales de las nuevas tecnologías (gestión del cambio, malas expectativas, evaluación del mantenimiento, mala evaluación del retorno de la inversión, etc.), las personas podrían utilizar la herramienta de forma demasiado sistemática, lo que llevaría a una reducción de la eficiencia (automatización de pruebas no recurrentes o difíciles de automatizar), los probadores podrían reducir su experiencia en las pruebas manuales y su compromiso, lo que llevaría a una menor cobertura de las pruebas.
 
Y, por supuesto, estamos en la industria GxP, donde hay muchas regulaciones...

Una herramienta automatizada no puede ser tan creativa como los humanos y se limita a lo que se pregunta: los humanos tienen los ojos en todas partes cuando realizan una prueba, lo que una máquina no puede hacer, lo que lleva a encontrar menos errores. ¿Y cómo puede una máquina juzgar la usabilidad y la apariencia del software? Por último, pulsar el botón de parada de emergencia de un dispositivo y ver las imágenes son ejemplos de cosas que aún deben ser realizadas por un ser humano.
 
Por otro lado, las herramientas de prueba no pueden crear informes de errores para humanos. Cualquier ejecución de prueba fallida dará lugar a una interpretación manual del error antes de documentar el error.