Durante los últimos seis años, he trabajado en el desarrollo y la aceptación de pruebas de las aplicaciones para realizar y respaldar ensayos clínicos. Aplicaciones de varios tamaños y complejidad, big data, una gran cantidad de visualizaciones y vistas, almacenamiento de datos, ETL, etc. Los productos son utilizados por médicos, administración de ensayos clínicos y personas involucradas en el control y monitoreo de la investigación.
Para las aplicaciones que tienen o pueden tener un impacto directo en la vida y la salud de los pacientes, se requiere un proceso de prueba de aceptación formal. Los resultados de la prueba de aceptación junto con el resto del paquete de documentación se envían para su auditoría a la FDA (Food and Drug Administration, EE. UU.). La FDA autoriza el uso de la aplicación como herramienta para monitorear y realizar ensayos clínicos. En total, mi equipo ha desarrollado, probado y enviado a la producción más de treinta aplicaciones. En este artículo, hablaré brevemente sobre las pruebas de aceptación y la mejora de las herramientas utilizadas para ello.
Nota: No pretendo ser la verdad definitiva y entiendo completamente que la mayor parte de lo que escribo es un monólogo del Capitán Obvio. Pero espero que lo descrito pueda ser útil tanto para el nivel de entrada como para los equipos que se encuentran con esto en el trabajo diario, o al menos puede alegrar a aquellos que tienen procesos más simples.
FDA
Los ensayos clínicos son experimentos u observaciones realizados en investigación clínica. Dichos estudios prospectivos de investigación biomédica o conductual en participantes humanos están diseñados para responder preguntas específicas sobre intervenciones biomédicas o conductuales, incluidos nuevos tratamientos (como vacunas novedosas, medicamentos, opciones dietéticas, suplementos dietéticos y dispositivos médicos) e intervenciones conocidas que justifican estudios adicionales. y comparación. Los ensayos clínicos generan datos sobre seguridad y eficacia. Wikipedia
En otras palabras, para que la píldora para el dolor de cabeza llegue al mostrador de una farmacia en algún lugar de Brighton Beach, pasa por 3 fases de pruebas en humanos, durante las cuales se determina la cantidad de sustancia activa que debe contener la tableta, qué tan segura es y si cura el dolor de cabeza en absoluto.
¿Qué es la FDA en términos de lo que hacemos y cómo afecta el proceso de desarrollo y el ciclo de lanzamiento?
La Administración de Alimentos y Medicamentos (FDA o USFDA) es una agencia federal del Departamento de Salud y Servicios Humanos de los Estados Unidos, uno de los departamentos ejecutivos federales de los Estados Unidos. La FDA es responsable de proteger y promover la salud pública a través del control y supervisión de la seguridad alimentaria, los productos del tabaco, los suplementos dietéticos, los medicamentos farmacéuticos (medicamentos) recetados y de venta libre, las vacunas, los productos biofarmacéuticos, las transfusiones de sangre, los dispositivos médicos, la radiación electromagnética. dispositivos emisores (ERED), cosméticos, alimentos y piensos para animales y productos veterinarios. Wikipedia
De hecho, la FDA prácticamente no se refiere al proceso de desarrollo en sí, trabajamos de acuerdo con SCRUM habitual (para ser honesto, no es exactamente SCRUM; dicen que ahora está de moda llamar a ese proceso "SCRUM modificado") con un ciclo de lanzamiento de sprint. No entregamos a la producción al final de cada sprint (e incluso al final de tres sprints, e incluso diez si la línea de tiempo involucra 15 sprints), es decir, desde el punto de vista de la entrega al usuario final. , tenemos una metodología similar a una cascada.
En nuestro caso, la prueba se divide en dos partes independientes con diferentes líneas de tiempo, diferentes estimaciones y diferentes procesos. La primera parte es la prueba in-dev habitual, donde el probador es una parte integral del equipo de desarrollo y termina los sprints junto con el desarrollo. La segunda parte es la prueba de aceptación real y el mantenimiento de las actividades relacionadas (cuando sea necesario). El proceso se construye de acuerdo con la metodología V&V: requisitos funcionales y de usuario en la entrada, scripts de prueba y un paquete de documentación de respaldo en la salida.
El ciclo de lanzamiento depende del alcance del proyecto, los lanzamientos generalmente no son iterativos. Después del lanzamiento, la aplicación puede permanecer sin cambios durante mucho tiempo, un descanso entre lanzamientos puede variar de un par de meses a un año o más.
V&V
Qué es V&V y cómo afecta esto al proceso de aceptación.
“En la gestión de proyectos de software, pruebas de software e ingeniería de software, la verificación y validación (V&V) es el proceso de verificar que un sistema de software cumpla con las especificaciones y que cumpla con el propósito previsto. También puede referirse a un control de calidad de software. Normalmente es responsabilidad de los probadores de software como parte del ciclo de vida de desarrollo de software. En términos simples, la verificación del software es: "Suponiendo que deberíamos construir X, ¿nuestro software logra sus objetivos sin errores ni lagunas?" Por otro lado, la validación del software es: "¿Era X lo que deberíamos haber construido? ¿Cumple X con los requisitos de alto nivel? » Wikipedia
En otras palabras:
Verificación: ¿Estamos haciendo bien el producto?
Validación: ¿Estamos haciendo el producto correcto?
Significa que debemos probar las especificaciones funcionales y del usuario con la integridad necesaria y suficiente. Para nosotros, la primera V se convierte en prueba de aceptación técnica (SIT), la segunda en soporte de UAT, donde:
- SIT - Pruebas de integración de sistemas
- UAT - Prueba de aceptación del usuario
La visualización de la cobertura de requisitos se lleva a cabo en la Matriz de trazabilidad (una tabla regular en Excel o Word, me ocuparé más adelante), que permite el seguimiento de los requisitos hasta la prueba y viceversa. En el caso de utilizar la gestión electrónica de documentos, la matriz se construye automáticamente, las pruebas están vinculadas a los requisitos que se almacenan junto con las pruebas (juntas = HP ALM, por supuesto, no se mezclan). En caso de que el requisito no esté cubierto y no lo esté, justificamos por qué no lo cubrimos.
¿Cuándo no se requiere la cobertura requerida?
Por ejemplo, CFR Parte 11 (
Reglas de la FDA para registros electrónicos y firmas electrónicas ) contiene muchos requisitos que ya se han cubierto en Microsoft, por lo que si usamos Windows AD para la autenticación, no necesitamos cubrir esos requisitos nuevamente.
En última instancia, la esencia de las pruebas de aceptación se reduce a probar el cumplimiento del producto con los requisitos y los requisitos para el cumplimiento del producto.
Roles
En el proceso intervienen una gran cantidad de roles, que de una forma u otra son familiares para todos los involucrados en el desarrollo de software: Desarrollador (Junior, Middle, Senior, Lead), Unit Tester, SIT Tester, Technical Product Owner, Business Product Propietario, Scrum Master, Gerente de proyecto, Analista de negocios, Líder técnico, Líder de prueba SIT, Líder de prueba UAT, Control de calidad global, Soporte, Ingeniero de implementación y otros.
El rol específico para nosotros:
Control de calidad global . Esta es la persona del lado del cliente que es responsable de observar y cumplir con los requisitos para el proceso - Ciclo de vida del software y todo tipo de procedimientos operativos estándar (SOP) del lado del cliente - durante el desarrollo y la aceptación, y además proporciona un paquete de documentos para auditoria externa.
Documentación de aceptación
En el alcance del lanzamiento del producto, creamos un paquete de documentación que incorpora una gran cantidad de niveles de anidamiento, incluida la documentación que se relaciona con la forma en que se probó el producto, por qué se probó de esta manera y no de otra manera, lo que específicamente estaba en el alcance de la prueba y lo que no fue:
Plan de Validación y Lista de Equipo - PM es responsable de la creación y aprobación del documento. El documento generalmente incluye la descripción del sistema, la lista de artefactos de desarrollo y prueba, la estrategia de validación, la lista de roles y responsabilidades.
Estrategia de prueba : el documento que no pertenece a la aplicación específica pero existe para la rama de productos o una rama de prueba. Por ejemplo, ¿cómo determinamos qué parte de las pruebas se automatizaría, qué planeamos usar para la automatización, cómo planeamos realizar las pruebas manuales, si planeamos usar listas de verificación, guiones de prueba, ambos o cualquier cosa? más ¿Cómo planeamos decidir si realizar pruebas de rendimiento / carga / volumen o no? y cosas como esta
Plan de prueba : común para los equipos UAT y SIT, incluye una breve descripción del objeto de prueba, posibles restricciones, requisitos del entorno, tiempos, conjuntos de pruebas, etc.
Test Suite : un conjunto de pruebas o listas de verificación formadas por área funcional, tipo de prueba o cualquier otra característica.
Matriz de trazabilidad : una matriz con trazas desde los requisitos hasta las pruebas. El seguimiento de los requisitos como evidencia de cobertura es una parte importante del proceso. Usando el identificador de cualquier requisito, puede encontrar un paso específico en el que se prueba este requisito y proporcionar evidencia al revisor (captura de pantalla, archivo, etc.) para una versión específica de la aplicación (o para cada versión en la que este requisito fue cubierto formalmente). Por lo tanto, vincule, vincule y una vez más vincule las pruebas a los requisitos (tareas), sobre la base de los cuales obtendrá el resultado esperado, incluso si no se lo requiere, porque simplificaría su vida en el futuro. Si es imposible debido al uso de diferentes herramientas no integradoras, siempre puede dejar comentarios en tareas / pruebas, o hacer una matriz (Excel mencionado anteriormente), o crear una base de datos primitiva de tres tablas.
PDS : la especificación de diseño del producto, el responsable técnico o el arquitecto del sistema son responsables de la creación del documento. De hecho, es una especie de combinación de documentos de arquitectura de alto y bajo nivel (HLA y LLA).
FRS y
URS o
BRS : requisitos funcionales y de usuario. Por lo general, hay dos documentos separados, pero a veces hay una especificación de requisitos comerciales que incorpora ambas especificaciones.
Registro de defectos : un registro de errores identificados en la aplicación y / o requisitos durante la SIT formal.
Registro de problemas menores : un registro de cambios menores en los scripts de prueba (errores tipográficos, requisitos restantes o redundantes, cualquier error).
Informe de resumen de prueba : un informe sobre los resultados de la fase de prueba, que incluye lo siguiente:
- Información sobre las compilaciones utilizadas para las pruebas (incluidos los números de compilación y las fechas de implementación con información sobre los motivos de la implementación), el número de ciclos de prueba y los resultados de los scripts de prueba (aprobado / fallido).
- Una descripción de las discrepancias de los POE.
- La lista de defectos abiertos con justificaciones.
- El enlace al registro de defectos o al registro de defectos en sí.
- El enlace al registro de problemas menores o al propio registro.
- Una recomendación sobre la implementación en el entorno de producción.
Plan de implementación : el documento que se utiliza para la implementación en producción, incorpora una descripción de las reversiones.
Informe de resumen de validación : el documento de cierre del Plan de validación.
Aprobación de documentación
Cualquier proceso de aprobación de documentación puede dividirse en 3 etapas:
- Preparación de documentos.
- Revisar
- Aprobación
Veamos el ejemplo de un conjunto de pruebas.
Para escribir scripts de prueba y combinarlos en conjuntos de pruebas, utilizamos una plantilla estándar aprobada en el lado del cliente.
Párrafos de la suite de prueba:
- Nombre del proyecto y la aplicación.
- Versión de lanzamiento.
- Nombre e identificador único de la suite.
- Descripción (qué probamos y qué tipos de pruebas usamos).
- Probar guiones.
- Lista de aprobadores.
A su vez, cada prueba consta de:
- Nombre e identificador único del script de prueba.
- Descripción
- Precondiciones
- Postcondiciones.
- Referencias de trazabilidad.
- Instrucciones para la ejecución (por ejemplo, instrucciones sobre cómo enmascarar datos confidenciales).
- Pasos (procedimiento, resultados esperados y observados).
- Resultado del script de prueba.
- Probador
- Revisor
El ciclo de vida normal de la prueba se asemeja a una cascada y se ve así:
- Escritura
Análisis de requerimientos. Definición y aplicación de técnicas de diseño de prueba para la cobertura más adecuada de funcionalidad. Escribiendo pasos. - Ejecuciones en seco en entorno de desarrollo
En esta etapa, intentamos encontrar cómo la aplicación cumple con los requisitos y la mayoría de los errores posibles, incluidos los errores de requisitos. - Revisión de la persona responsable (SIT Team Lead)
Revisión estilística y lógica. - Ejecuciones en seco en ambiente de asiento
En esta etapa, se detectan los errores asociados con la instalación, el entorno y la configuración del entorno (de forma predeterminada, suponemos que el entorno SIT repite PROD exactamente o casi por completo). La finalización exitosa de esta etapa significa que la versión que se implementa es estable y la versión se puede considerar candidata. - Revisión del cliente (control de calidad global)
Global QC verifica que se cumplen los requisitos y que las pruebas escritas corresponden a los SOP de la empresa. - Aprobación (Global QC, Technical PO, Business PO).
- Ejecución formal de script de prueba en entorno SIT (versión candidata de lanzamiento)
Después de la aprobación de las pruebas para la ejecución (p. 6) y la finalización exitosa de las ejecuciones en seco en el entorno SIT (p. 4), la prueba se ejecuta formalmente en el entorno SIT con la fijación formal del resultado. Si los errores encontrados en los pases de ejecución en seco no son formales y simplemente se ingresaron en Jira de manera similar a lo que sucede durante el proceso de desarrollo, entonces se crea un formulario de defecto separado para cada error encontrado en la ejecución formal, que se incluye en la documentación de salida paquete para el producto. - Prueba de revisión de ejecución del script (SIT Team Lead).
Lo mismo para el punto 3. - Revisión del cliente (control de calidad global)
El control de calidad global verifica la corrección e integridad de completar los resultados, los posibles errores, la presencia de evidencia (por ejemplo, capturas de pantalla). Un punto importante, porque es Global QC el responsable de proporcionar un paquete de documentos a una auditoría externa (por la FDA o los clientes).
Trabajando con datos personales
Dado que la investigación se realiza utilizando la metodología doble ciego *, este es el menor de nuestros problemas. Pero los datos de médicos, nombres de compañías, números de protocolos de investigación, etc., deben cambiarse. Desde un punto de vista formal, si no podemos deshacernos de los datos confidenciales, tenemos que enmascararlos en las capturas de pantalla, pero esta es una situación bastante estándar y comprensible.
* doble ciego: los pacientes se dividen aleatoriamente en dos grupos, uno de los cuales recibe el fármaco del estudio y el segundo un placebo o un fármaco con eficacia comprobada. Al mismo tiempo, ni el médico ni el paciente saben a qué grupo fue asignado el paciente. Esto elimina el sesgo del médico y el efecto placebo. En el contexto de trabajar con datos personales, esto significa que en la mayoría de los casos la identidad del paciente no puede identificarse sobre la base de los datos almacenados en la base de datos o accesibles para el usuario.Pero el hecho de que este sea el menor de nuestros problemas no significa que no pueda traer problemas. Aquí hay un par de rastrillos (para no pisar dos veces) que obtuvimos en nuestros proyectos:
Puede ser divertido (no para nosotros en ese momento): "The Globe"
En una de las aplicaciones, para crear un efecto sorprendente y no solo, realmente necesitábamos crear un globo interactivo que pudieras rotar con el mouse, cambiar día / noche, etc. En el mundo, hay marcas en las direcciones, que se colorean según los valores y rangos en los que se encuentran estos valores (una especie de codificación de colores). Después de anonimizar la base de datos en el entorno de demostración, dos horas antes de la demostración, gracias al script de anonimato, nos quedamos sin códigos postales con todas las consecuencias.
Moraleja: no toque los datos dos horas antes de la demostración.
Historia número dos: "Sobre el anonimato"
Antecedentes: los datos se recopilan en el repositorio de una gran cantidad de fuentes, los datos pertenecen a diferentes dominios, pero están interconectados por identificadores.
La historia: los datos se cargaron en la base de datos y se anonimizaron antes de usarse para fines de prueba. Resultó que los datos no se descargaron de todas las fuentes necesarias. Luego cargaron la parte que faltaba. No fue posible conectar la segunda parte de los datos (aún no anonimizados) con la primera parte ya anonimizada. Como resultado, el inicio del trabajo en el entorno SIT se pospuso por dos semanas, para lo cual los equipos de implementación y soporte corrigieron los datos.
Moraleja: antes de anonimizar, debe asegurarse de que la base de datos contenga todo lo que debe contener y pensar de antemano en la aplicabilidad de los mecanismos de anonimización y ofuscación.
Flujo de trabajo electrónico vs papel en la práctica
El flujo de trabajo electrónico simplifica de alguna manera la comunicación y el proceso de revisión y aprobación desde el punto de vista del trabajo manual, pero prácticamente no ofrece ninguna ganancia en términos del tiempo de preparación para las pruebas y su ejecución. A continuación se enumeran los pros y los contras del flujo de trabajo electrónico versus el papel basado en el ejemplo de HP ALM.
Beneficios:
- Fácil de soportar.
- Menos trabajo manual.
- Todos los miembros del equipo en cualquier momento tienen acceso al estado actual de una prueba en particular.
- Historia de los cambios.
- Historia de ejecuciones.
- Puede realizar un seguimiento del tiempo necesario para completar la prueba.
- Fácil de planificar futuras carreras.
- Es difícil usar una versión incorrecta del script de prueba.
- Firma electrónica
Contras (específicamente para HP ALM):
- Gran cantidad de tiempo para formatear scripts.
- Problemas periódicos con la herramienta en sí.
- No es el mejor corrector ortográfico.
- Interfaz incómoda.
- El tiempo dedicado a escribir y revisar las pruebas es prácticamente el mismo que las pruebas en Word.
- Costo
Una historia real relacionada con el papeleo y las firmas manuales: "A Nightmare Before Release"
Una tarde, escribí 450 veces: “el color de los puntos en el gráfico corresponde al indicado en los requisitos. Apellido, nombre, fecha "y poner una firma, simplemente porque imprimimos en una impresora en blanco y negro, y el color de los puntos en los gráficos importaba.
Moraleja: la elección de los medios debe ser coherente con los objetivos.
Otra historia: "Pesado es bueno, pesado es confiable". ©
El flujo de trabajo del papel se trata del papel (quién lo dudaría). La fase de prueba de aceptación para una aplicación lejos de la más grande puede ser de unos cinco kilogramos de papel.
La conclusión que se sugiere a partir de las historias anteriores (y muchas no contadas): a pesar de los inconvenientes enumerados y no enumerados del flujo de trabajo electrónico, si puede elegir, definitivamente elija electrónica, incluso si HP ALM (ya no es HP).
Automatización
Una gran cantidad de visualizaciones no permite la automatización estable de aplicaciones, por lo tanto, como parte del enfoque inicial, nos limitamos a las pruebas unitarias (incluidas las pruebas en el lado de la base de datos) y las pruebas API, sin ningún intento de avanzar hacia E2E.
¿Cómo y por qué llegamos al menos a la automatización parcial?
La primera tarea fue explicarnos a nosotros mismos que en algunos casos realmente ganaríamos tiempo. Sí, es comprensible: no todos creen en la automatización y, a menudo, su uso no se justifica a sí mismo, porque se usa de manera incorrecta, no allí, y no para eso, pero este es un tema para una discusión por separado, de la cual existe son un poco menos que "la automatización debe tener !!!", pero aún así mucho.
Lo segundo es explicarle al cliente que ganará tiempo y que será lo suficientemente confiable y aceptable desde un punto de vista formal. La industria está controlada y hay razones para esto.
Tercero, y principal: determinar el algoritmo por el cual podemos tomar una decisión consciente sobre la automatización de probar una aplicación en particular o parte de la aplicación, y obtener el consentimiento para la automatización. Esto es importante porque está claro que el proceso de automatización no debe estar menos controlado que el proceso descrito para los scripts de prueba manual.
Después de explicar y justificar los dos primeros puntos para nosotros y para el cliente, escribimos una estrategia de prueba, pedimos a los analistas de negocios que agregaran campos adicionales a los requisitos, y formamos un conjunto de preguntas, dependiendo de las respuestas a las cuales podemos formar un conjunto para la automatización
La lista de preguntas en nuestro caso:
- ¿Es posible automatizar las pruebas en este caso particular?
- ¿Es un componente estable *?
- ¿Con qué frecuencia necesitamos ejecutar scripts de prueba para este componente?
- ¿Es una función crítica para el negocio? **
- ¿Qué tan difícil es automatizar las pruebas?
* Estable = el componente no ha cambiado durante algún tiempo y los cambios de componentes no están planificados para las próximas versiones.
** Se completa según el valor del campo agregado a los requisitos por el analista de negocios.
En general, el proceso de toma de decisiones es el siguiente:
- En la entrada, tenemos requisitos de FRS.
Creamos Design Matrix, donde cada fila es un requisito de FRS, y las columnas son:
- Descripción del requisito
- Preguntas 1-5
- Decisión del equipo
- Estimación aproximada
- Aprobación
- Comentarios
- El equipo formula respuestas a las preguntas y, sobre la base de los datos recibidos, determina si vale la pena automatizar la prueba de un requisito específico / grupo de requisitos en su totalidad o en parte.
- El cliente revisa la solución propuesta y aprueba la versión final.
- Después de la aprobación de Design Matrix, se escriben las pruebas automáticas. Los guiones para las pruebas automáticas se escriben en notación Gherkin y se someten a una revisión similar a la de las pruebas manuales (Control de calidad global, Propietario técnico, Propietario de empresa). Las definiciones de pasos, los objetos de página, etc., se revisan en las solicitudes de extracción, incluso por un especialista técnico por parte del cliente. Los resultados de las pruebas automáticas y los informes generados se revisan y aprueban en el lado del control de calidad global.
Dentro de dos años desde el momento de la implementación, cambiamos a la automatización parcial de las pruebas de aceptación de dos aplicaciones relacionadas con la descarga, configuración y visualización de datos en el almacén de datos, y en un futuro próximo planeamos continuar usando el enfoque combinado en otros productos desarrollados para el cliente, si es posible.
Conclusión
En conclusión, me gustaría señalar que la prueba de aceptación formal no es algo aterrador o inútil, como parece a muchas personas en la industria. Permite, aprovechando al máximo el enfoque de prueba de escenarios, facilitar la prueba de futuras versiones, confirmar el nivel necesario y suficiente de calidad de software y, en última instancia, tranquilizar al cliente. ¿Y qué, si no la tranquilidad del cliente, es importante en el desarrollo de outsourcing?