(Círculo de LabVIEW: Parte 5 de 6)
Este es el Círculo de LabVIEW: Pruebas de Aceptación, la quinta de una serie de entradas de blog que describen las diferentes etapas del ciclo de vida del proyecto LabVIEW desde la idea hasta el mercado. Aunque leerlos en orden ayudará a entender el panorama general, cada entrada del blog es independiente con una pequeña sección sobre el "RT Installer", una especie de producto de muestra utilizado en esta serie.
Esta entrada aborda lo que ocurre una vez finalizado el desarrollo principal. Describe el proceso que utilizamos para verificar que cada uno de los requisitos se ha implementado y es funcionalmente correcto según lo dictado por el alcance.
Las pruebas de aceptación pueden realizarse durante el desarrollo principal, cuando se cumplen los hitos de funcionalidad, o hacia el final del proceso de desarrollo, cuando se ha completado la mayor parte de la aplicación. En la mayoría de los proyectos, la verificación formal -no sólo la comprobación puntual de la funcionalidad- se realiza mejor al final del ciclo de vida del desarrollo. Algunas funcionalidades, especialmente los sistemas estrechamente acoplados o el control de recetas, SÓLO se pueden probar una vez que se han completado varias partes de la aplicación.
La verificación de requisitos es un proceso algo orgánico. A menudo se realiza con el cliente y el desarrollador codo con codo. Las pruebas de aceptación se apoyan en los siguientes documentos:
- Prueba de aceptación del sistema
- Descripciones de las pruebas del sistema
- Matriz de trazabilidad de requisitos
- Especificación de requisitos del sistema
Las descripciones de las pruebas proporcionan una colección de escenarios que recorren distintos procesos que cubren requisitos específicos. Una sola descripción de la prueba puede cubrir uno o más requisitos, mientras que otras descripciones de la prueba también pueden probar el mismo o diferentes requisitos de diferentes maneras.
El método que utilizamos para visualizar esta cobertura de requisitos es el uso de una matriz de trazabilidad de requisitos; este documento permite ver qué descripciones de pruebas cubren qué requisitos y el solapamiento entre pruebas.Debido al sesgo del desarrollador al crear descripciones de pruebas, generalmente hacemos que los desarrolladores las redacten y que el cliente las apruebe o modifique. El sesgo del desarrollador tiene el efecto de crear una descripción de prueba que tiene más probabilidades de pasar debido a cómo está escrita la aplicación que al proceso que está realizando.
El proceso de aceptación formal utiliza las "Hojas de Trabajo de Ejecución de Pruebas" incluidas en el Documento de Pruebas de Aceptación del Sistema. Este documento permite comunicar si se ha superado la descripción de una prueba y hacer anotaciones. Por ejemplo, el requisito facilitado anteriormente
Si la presión (PT-001) es superior al límite de sobrepresión (LIM-001), el software activará la alarma de sobreprión (ALM-001).
Una descripción de prueba para este requisito podría tener el siguiente aspecto:
Si esta descripción de prueba se completa con éxito, el requisito se ha cumplido.
Alternativamente, la hoja de trabajo permite pases condicionales. Por ejemplo, si la alarma de sobrepresión se dispara, pero no hay un indicador sonoro de sobrepresión, el cliente podría argumentar que el requisito "se ha superado con una excepción", diciendo que para que esta característica sea "totalmente funcional" necesita un claxon. Se trataría de una nueva función y sería discutible si entra en el ámbito de aplicación.
Además, el cliente podría realizar ciclos de presión por encima y por debajo de 100 psi, observando que la alarma se desactivaría y volvería a activarse (es decir, no se enclavaría) e identificarlo como un error, diciendo que falló. Una vez superadas las descripciones de las pruebas, no es necesario volver a ejecutarlas, a menos que se hayan realizado cambios en una parte de la aplicación incluida en los requisitos que cubre la descripción de la prueba.
Un SAT completadocon éxito es una colección de Hojas de Trabajo de Ejecución de Pruebas (TEWs) donde cada descripción de prueba ha sido ejecutada y superada sin excepción. Cada SAT completado proporciona a los desarrolladores los errores finales y las características a implementar para superar con éxito el SAT.
Una vez completado el desarrollo principal para el "RT Installer", ejecutamos el SAT internamente después de desarrollar los documentos apropiados. Debido a algunos problemas de configuración, ejecutamos 4 SATs y desarrollamos una lista de errores/características, algunos de los cuales implementamos durante el proceso SAT y otros los dejamos para más adelante. Los documentos relacionados son los siguientes:
- Véase el documento de prueba de aceptación del sistema para RT Installer.
- Consulte las descripciones de las pruebas del sistema para RT Installer.
- Véase la Matriz de Trazabilidad de Requisitos para el RT Installer.
- Véase la hoja de trabajo de ejecución de pruebas nº 1 (RT Installer).
- Véase la hoja de trabajo de ejecución de pruebas nº 2 (RT Installer)
- Véase la hoja de trabajo de ejecución de pruebas nº 3 (RT Installer)
- Véase la hoja de trabajo de ejecución de pruebas nº 4 (RT Installer)
Durante las pruebas de aceptación, observamos que el despliegue automático tardaba más de lo esperado. Como se ve en la característica de estado de origen #8, pensé que el proceso de despliegue automático podría optimizarse minimizando los reinicios. Puedes ver los vídeos del antes y el después aquí, así como la información de la hoja de cálculo del estado de origen.
(Antes de la característica #8)
(Después de aplicar la función nº 8)
La corrección permitió reducir en un 25% el tiempo de despliegue automático (12 m frente a 16 m) con exactamente la misma configuración.
