V&V no significa venganza

En los últimos seis años, he estado desarrollando y aceptando probar una variedad de aplicaciones en términos de complejidad y tamaño para realizar y mantener ensayos clínicos. Big data, una gran cantidad de visualizaciones y vistas, almacenamiento de datos, ETL y similares. El producto es utilizado por médicos, gerentes 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 producción más de treinta aplicaciones. En este artículo, hablaré brevemente sobre las pruebas de aceptación y el desarrollo de herramientas en un grupo pequeño.

Nota: No pretendo ser la verdad definitiva y entiendo que la mayor parte de lo que escribo es sobre la evidencia del monólogo del capitán. Pero espero que lo descrito resulte útil tanto para el nivel de entrada como para los equipos que se encuentran con esto en el trabajo diario, o al menos complacer a aquellos que tienen procesos más simples.

FDA

Los estudios clínicos en todo el mundo son un paso integral en el desarrollo de medicamentos, que precede a su registro y uso médico generalizado. En ensayos clínicos, se estudia un nuevo medicamento para obtener datos sobre su efectividad y seguridad. Wikipedia

En otras palabras, para que una píldora "de la cabeza" llegue al mostrador de una farmacia en algún lugar de Brighton Beach, pasa 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 en absoluto dolor de cabeza

¿Qué es la FDA para nosotros y cómo afecta el proceso de desarrollo y el ciclo de lanzamiento?

Food and Drug Administration (FDA, USFDA, cartas. Food and Drug Administration) es una agencia del Departamento de Salud y Servicios Humanos de los EE. UU., Uno de los departamentos ejecutivos federales. El departamento está involucrado en el control de calidad de productos alimenticios, productos farmacéuticos, cosméticos, productos de tabaco y algunas otras categorías de productos, y también supervisa el cumplimiento de la legislación y las normas en esta área. Wikipedia

La FDA prácticamente no se refiere al proceso de desarrollo en sí, trabajamos en el SCRUM habitual (o más bien, no en SCRUM, dicen que ahora está de moda llamar a ese "SCRUM modificado") con un ciclo de liberación sin sprint. No vamos a la producción al final del 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 algo parecido a una cascada.

Las pruebas en nuestro caso se dividen 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 (cuando sea necesario). El proceso se construye de acuerdo con la metodología V&V: requisitos funcionales y de usuario en la entrada, pruebas y un paquete de documentación de respaldo en la salida.

El ciclo de lanzamiento depende del volumen de trabajo, los lanzamientos generalmente no pasan por iteraciones. Después del lanzamiento, la aplicación puede permanecer sin cambios durante mucho tiempo, es decir, un descanso entre lanzamientos, de un par de meses a un año o más.

V&V

¿Qué tipo de animal es este, V&V, y cómo se refleja esto en el 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

Traducción libre:

“En la gestión de proyectos, pruebas y desarrollo de software, la verificación y validación (V&V) es el proceso de verificar que el software desarrollado cumple con las especificaciones y cumple con la función prevista. También se puede atribuir al control de calidad en general. Por lo general, los ingenieros de pruebas son responsables de la verificación y validación del ciclo de vida del desarrollo de software. En palabras simples, la verificación del software se puede describir como: "Supongamos que tenemos que desarrollar el sistema X. ¿Hemos logrado el objetivo sin errores ni suposiciones?" Por otro lado, la validación del software es "El sistema X desarrollado es realmente algo ¿Qué queríamos conseguir? ¿El sistema X cumple con los requisitos de alto nivel?

En otras palabras:
Verificación: ¿Estamos haciendo bien el producto?
Validación: ¿Estamos haciendo el producto correcto?

Esto 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 (SIT), la segunda en mantenimiento (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, naturalmente, no se almacena un montón). En caso de que el requisito no esté cubierto y no lo esté, explicamos por qué.

¿Cuándo no es necesario el requisito de cobertura?

Por ejemplo, CFR Parte 11 (las reglas establecidas por la FDA con respecto a los registros electrónicos y las firmas electrónicas ) contiene una gran cantidad de requisitos que ya están cubiertos por Microsoft y si usamos Windows AD para la autenticación, no necesitamos cubrirlos nuevamente.

En última instancia, la esencia de las pruebas de aceptación se reduce a probar el cumplimiento del producto con los requisitos y 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 Owner, 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.

Nuestro papel específico es el control de calidad global . Esta es la persona del lado del cliente, responsable del cumplimiento de los requisitos del proceso, el 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 auditoría externa.

Documentación de aceptación

Como parte del lanzamiento del producto, se crea un paquete de documentación con una gran cantidad de niveles de anidación, incluida la documentación relacionada con la forma en que se probó el producto, por qué se probó de esta manera y no de otra manera, y qué se probó específicamente y qué se dejó fuera:

Plan de Validación y Lista de Equipo - PM es responsable de escribir y aprobar el documento. Un documento generalmente incluye una descripción del sistema, una lista de artefactos que se crearán durante el desarrollo y las pruebas, una estrategia de validación y una lista de roles con responsabilidades.

Estrategia de prueba : un documento que no se aplica a una aplicación específica, pero se crea para una rama de producto separada o para una rama de prueba separada. Por ejemplo, cómo y por qué determinamos qué automatizaremos y qué no; qué tecnologías; cómo organizaremos las pruebas manuales (listas de verificación o scripts de prueba, o ambos juntos, o algo completamente diferente); cómo decidimos si manejaremos la carga o no; y así sucesivamente.

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 : matriz de traza desde el requisito hasta la prueba. El rastreo como evidencia de cobertura es una parte importante del proceso. Al identificar cualquier requisito, puede encontrar un paso específico en el que este requisito se confirma y proporcionar evidencia al revisor (captura de pantalla, archivo, etc.) para una versión particular de la aplicación (o para cada versión en la que este requisito se cubrió 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. 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 archivar una base de datos primitiva de tres tablas.

PDS - Product Design Specification, un documento desarrollado por un asesor técnico o arquitecto de proyecto, esencialmente una combinación de arquitectura de aplicaciones de alto y bajo nivel (HLA y LLA).

FRS y URS o BRS son requisitos funcionales y de usuario, generalmente en forma de dos documentos separados, pero a veces combinados en la Especificación de requisitos comerciales.

Registro de defectos : un registro de defectos detectados durante las pruebas (defectos y requisitos de la aplicación).

Registro de problemas menores : un registro de errores menores en las pruebas (errores tipográficos, requisitos faltantes / innecesarios, etc.) cualquier error que fundamentalmente no cambie el significado de la prueba).

Informe de resumen de prueba : informe sobre los resultados de la prueba. TSR es el documento de cierre para el plan de prueba y contiene:

• Información sobre los ensambles que se probaron (incluidos los números de compilación y las fechas de implementación), la cantidad de ciclos de prueba y los resultados de la prueba.
• Descripción de las infracciones cometidas en relación con el plan de prueba y los procedimientos de prueba (SOP) aprobados para su ejecución por la empresa.
• Lista de defectos abiertos que explican los motivos de la transferencia a la próxima versión.
• Enlace al registro de defectos o al registro en sí.
• Un enlace al registro de errores de prueba o al registro en sí.
• Una recomendación para una decisión de instalar en producción.

Plan de implementación : un documento del que el soporte y la integración son responsables, se compila durante las instalaciones en el entorno SIT y posteriormente se utiliza para implementar la versión en producción.

Informe de resumen de validación : documento de cierre del plan de validación.

Aprobación de documentos

Cualquier proceso de aprobación de documentación se divide condicionalmente en 3 etapas:

• Elaboración del documento.
• Revisar
• Declaración

Considere el ejemplo de Test Suite.

Para escribir scripts de prueba y combinarlos en conjuntos de pruebas, utilizamos una plantilla estándar aprobada en el lado del cliente.

Los componentes del kit de prueba:

• El nombre del proyecto y la aplicación.
• Versión de lanzamiento.
• El nombre y el identificador único del conjunto.
• Descripción (qué probamos, qué tipos de pruebas usamos).
• Pruebas
• Lista de aprobadores.

A su vez, cada prueba incluye:

• Nombre e identificador único dentro del conjunto.
• Descripción
• Precondiciones
• Postcondiciones.
• Rastreo (números de requisitos cubiertos en la prueba).
• Características de ejecución (por ejemplo, instrucciones para enmascarar datos confidenciales).
• Pasos (acciones requeridas, resultados esperados y reales).
• El resultado de la prueba.
• Realizado
• Revuever

El ciclo de vida normal de una prueba se asemeja a una cascada de retroalimentación y se ve así:

1. Ortografía
   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.
2. Pasaje de prueba / pasajes en vírgenes
   En esta etapa, se evalúa en qué medida la aplicación cumple con los requisitos, y la mayor parte de los posibles errores, incluidos los errores de requisitos, se eliminan.
3. Revisión del gerente de proyecto (líder del equipo SIT)
   Revisión estilística y lógica.
4. Pases de prueba / pases en entorno SIT
   En esta etapa, se detectan los errores asociados con la instalación, el entorno y la configuración del entorno (de forma predeterminada, se cree que el entorno SIT repite PROD de forma exacta o casi completa). La finalización exitosa de esta etapa significa que la versión que está rodeada es estable y el lanzamiento puede considerarse un candidato.
5. Revisión del cliente (control de calidad global)
   Global QC verifica que se cumplan los requisitos y que las pruebas escritas de SOP están en su lugar con la compañía.
6. Aprobación (Global QC, Technical PO, Business PO).
7. Ejecución de prueba formal en entorno SIT (versión candidata de lanzamiento)
   Después de la aprobación de las pruebas para el pasaje (p. 6) y la finalización exitosa de los pases de prueba en el entorno SIT (p. 4), la prueba se realiza formalmente en el entorno SIT con la fijación formal del resultado. Si los errores encontrados en los pases de prueba no se formalizan y simplemente se ingresan 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 el pase formal, que se incluye en el paquete de documentación de salida para el producto.
8. Revisión de los resultados del pasaje responsable del proyecto (SIT Team Lead).
   De manera similar al punto 3, se verifica el estilo de relleno y se analizan los resultados.
9. 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 confirmaciones (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).

Trabajar 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., 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 - método 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 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 que solíamos pisar en nuestros proyectos:

Una pretensión de diversión: un globo

En una de las aplicaciones para crear un efecto sorprendente, no solo necesitábamos crear un globo interactivo que puedas rotar con el mouse, cambiar día / noche, etc. En el mundo hay marcas en las direcciones, que se colorean en función de los valores y rangos en los que se encuentran estos valores (como la 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: "Acerca del 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.

Historial: los datos se cargaron en el repositorio y se anonimizaron antes de usarse con fines de prueba. Resultó que los datos no se descargaron de todas las fuentes necesarias. Luego cargaron la parte que faltaba. No fue posible vincular 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, o pensar de antemano sobre la aplicabilidad del mecanismo de anonimización y ofuscación.

Flujo de trabajo electrónico vs papel en la práctica

El que trabajó con HP ALM no se ríe del circo.

La gestión electrónica de documentos simplifica un poco la comunicación y el proceso de revisión y aprobación desde el punto de vista del trabajo manual, pero prácticamente no da un escape en el tiempo en el contexto del tiempo de preparación para la prueba 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.

Pros:

• Es fácil mantener actualizada la última versión.
• Menos hecho a mano.
• Todos los miembros del equipo en cualquier momento tienen acceso al estado actual de una prueba en particular.
• Cambia el historial.
• Historia del pasaje.
• Puede realizar un seguimiento del tiempo necesario para completar la prueba.
• Es más fácil planificar el tiempo para más pases.
• Debemos intentar utilizar la versión incorrecta de la prueba para el pasaje.
• Firma electrónica

Contras (específicamente para HP ALM):

• Se dedica mucho tiempo a las pruebas de formato.
• Problemas periódicos con la herramienta en sí.
• Falta de un corrector ortográfico normal.
• Interfaz incómoda.
• El tiempo dedicado a escribir y revisar las pruebas es prácticamente el mismo que las pruebas en Word.
• Costo

Estudio de caso relacionado con el papeleo y las firmas manuales: "The Nightmare Before Release"

Por una noche, escribí 450 veces, "el color de los puntos en el gráfico corresponde al indicado en los requisitos, el apellido es el nombre de la fecha" y puse 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.

Historia número dos: "La gravedad es buena, la gravedad es confiable"

El flujo de trabajo en papel es papel (quién dudaría). Para la recepción de una aplicación lejos de la más grande, puede resultar en la región de cinco kilogramos.



La conclusión que se sugiere a partir de las historias anteriores (y muchas otras no contadas): a pesar de los inconvenientes enumerados y no enumerados de la gestión de documentos electrónicos, 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 pruebas unitarias (incluso en el lado base) y 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 todo el mundo cree en la automatización y, a menudo, su uso no se justifica a sí mismo, porque se usa de manera incorrecta, no existe, y no por eso, pero este es un tema para un informe separado, ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡!!! ", Pero aún en cantidad.

El 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 por una razón.

Tercero, y principal: determinar el algoritmo mediante 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 a la luz del proceso de aprobación de la documentación descrito anteriormente usando el Test Suite manual como ejemplo, queda claro que el proceso de automatización no debe ser menos controlado.

Después de explicar y justificar los dos primeros puntos para nosotros y para el cliente, redactamos una estrategia de prueba, solicitamos a los analistas de negocios que agregaran campos adicionales a los requisitos y formamos un conjunto de preguntas, dependiendo de las respuestas a las que puede formar un conjunto para la automatización.

La lista de preguntas en nuestro caso:

1. ¿Es posible automatizar las pruebas en este caso particular?
2. ¿Las pruebas del componente * se automatizarán para que sean estables?
3. ¿Con qué frecuencia debemos ejecutar pruebas escritas para un componente?
4. ¿Es esta funcionalidad crítica para los negocios? **
5. ¿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 fija según el valor del campo agregado a los requisitos por el analista de negocios.


En términos generales, el proceso de toma de decisiones es el siguiente:

1. La entrada recibe los requisitos de FRS.
   Se compila una matriz de diseño, donde cada fila es un requisito de FRS. Como columnas:
   
   • Descripción del requisito
   • Preguntas 1-5
   • Decisión del equipo
   • Tiempo estimado de escritura
   • Aprobación
   • Comentarios
2. 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.
3. El cliente revisa la solución propuesta y aprueba la versión final.
4. Después de la aprobación de Design Matrix, se escriben las pruebas automáticas. Los guiones para las pruebas automáticas se describen en 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 el grupo de solicitudes, incluido un especialista técnico por parte del cliente. Los resultados de las pruebas automáticas y los informes generados se anticipan del lado del control de calidad global.

Durante los dos años transcurridos desde la introducció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, quiero señalar que las pruebas de aceptación formal no son algo aterrador o inútil, como parece a muchos. Permite, aprovechando al máximo el enfoque de prueba basado en escenarios, para 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 personalizado?