Verificar un programa es parte inherente de la construcción de cualquier software. El programador debe asegurarse que sus líneas de código realicen lo que se espera y el programa se encuentra libre de posibles defectos “bugs”. Gran parte del problema de la verificación es la posibilidad de encontrar errores incluso después de que el programador lo ha verificado exhaustivamente. ¿Cómo es esto posible?
Esto es algo parecido a pasar por alto errores ortográficos o de redacción en un ensayo. Una persona no podría estar totalmente segura de que no tiene errores hasta que otra persona hace una revisión. Parecería que por más intentos que realice su autor, estos errores se esconden entre los párrafos. Algunos programadores tienen la idea de que un par de errores en un programa de 100 LOC no es tan grave, sin embargo si esta misma proporción se transfiere a programas de mayor tamaño significa que encontrarás 20 errores en 1000 LOC o 2,000 en 1,000,000 de LOC. Con esta cantidad de errores, tarde o temprano afectará el desempeño del sistema. Bastaría con pasar por alto uno solo de esos errores para causar graves daños al cliente.
13.1 Verificación del software
Verificar un software es una de las tareas de desarrollo más caras en cualquier proyecto y a la vez la única manera de comprobar los resultados de problemas complejos y conocer el comportamiento general del software. La efectividad de las pruebas a un software depende del tiempo que se destine para realizarlas, de la experiencia del tester, de la calidad del ambiente de pruebas, de la selección de los casos de prueba y de los datos ingresados. Esa es la razón por la que ningún departamento de pruebas puede garantizar encontrar el 100% de los defectos de un software. El reto del departamento de pruebas es utilizar uno o varios métodos de verificación que sean efectivos y ajustarse al tiempo que se le asignó al proyecto para las pruebas.
Pomeroy-Huff, et al. (2009), proponen los siguientes métodos de verificación:
Haz clic para conocer más detalle
Estándares del diseño
- Proporcionan una base para verificar que un diseño cumple las funciones previstas de forma adecuada.
Tablas de ejecución
- Permite comprobar la lógica de un programa de una forma sencilla y ordenada, aunque requiere de una intensa labor manual.
Tablas de rastreo
- Es una manera de verificar de forma general la lógica de un programa.
Máquina de estados
- Ofrece métodos de análisis que permiten verificar si el comportamiento del sistema es adecuado y por lo tanto correcto.
13.2 Técnicas de verificación
Revisiones independientes (Walkthroughs)
Las revisiones o walkthroughs son una actividad en la que una persona con experiencia, diferente al autor del código revisa los programas (códigos fuente, librerías, scritps, store procedures, rutinas de interfaz, etc.) y sus documentos relacionados. El objetivo es verificar el trabajo del programador. El resultado de esta revisión es un documento llamado Reporte de revisión, que contiene lo siguiente:
- Datos generales de la revisión: nombre del proyecto, nombre del programador, versión del código, fecha de revisión, autor(es) de la revisión, tipo de revisión y hallazgos.
- Defectos que no fueron detectados que incluyen errores lógicos, código basura, código malicioso, variables y constantes no utilizadas en la ejecución del programa, presencia de elementos “hard coding”, vicios de programación y estilos de codificación que no se encuentren alineados al estándar de la organización.
- Oportunidades o sugerencias de mejora que permitan generar un código más confiable, mejoras en el rendimiento de cómputo, ajustes que faciliten un futuro mantenimiento, encontrar oportunidades para la reutilización de código en futuros proyectos y eliminar redundancia innecesaria.
En las siguientes imágenes puedes encontrar un formato del reporte de revisión:
Recuperado de Chemuturi, M. (2010). Mastering Software Quality Assurance. EEUU: J. Ross Publishing.
De acuerdo con Chemuturi (2010) un aspecto importante en este tipo de revisiones es que no es necesario que el programador autor del código se encuentre presente, esto ofrece libertar a la persona que revisa el código. El programador podría apoyar de forma esporádica en resolver alguna duda. Para que esta técnica se aproveche como una actividad de aseguramiento de calidad, no debe considerarse como parte de la evaluación del desempeño del programador, ya que esto le crearía presión y trataría de justificar cualquier defecto encontrado en la revisión.
Revisiones guiadas (guided walkthrough)
Una variante de la revisión independiente, es una revisión guiada, en la que el autor se encuentra presente en la revisión y explica paso a paso el material objeto de la revisión. Este tipo de revisiones permite generar un ambiente propicio para el intercambio de ideas, y en opinión de Chemuturi (2010) tienen la ventaja de que la revisión tiene una duración más corta que la revisión independiente, aunque puede haber conflicto entre el programador y la persona que revisa sobre la idoneidad de una mejora. En estos casos se requerirá de una persona de mayor rango para resolver la controversia.
Las revisiones guiadas pueden ser realizadas entre el programador y un grupo de revisores. Usualmente esta es una estrategia de entrenamiento para programadores de recién ingreso, o bien para la revisión de la documentación del proyecto como las especificaciones de requerimientos, diseño de la arquitectura de software y casos de prueba.
Inspecciones
Las inspecciones permiten asegurar que los componentes requeridos se encuentren listos para las siguientes etapas del desarrollo. Toda inspección debe generar un reporte de inspección en el que se especifique si el sistema ha pasado o no ha pasado la inspección. Si el reporte de la inspección indica que no pasó la inspección, significa que requerirá de algunas acciones que rectifiquen los problemas encontrados. Una vez corregidos los hallazgos, se volverá a pasar por una nueva inspección.
En las siguientes imágenes puedes revisar un formato sugerido para realizar una inspección de software:
Recuperado de Chemuturi, M. (2010). Mastering Software Quality Assurance. EEUU: J. Ross Publishing.
Haz clic en cada inspección para conocer la información
Este tipo de inspección se realiza para certificar que los programas o el sistema se encuentra en condiciones para realizar las pruebas. Eso significa que los elementos como equipo (hardware), base de datos, software de seguridad, conectividad, configuración de terminales, plan de pruebas, casos de pruebas, capacitación de los testers y sistema de documentación de defectos, y criterios para aprobar el sistema se encuentran listos.
Las pruebas de aceptación del usuario o UAT (User Acceptance Test) son un requisito obligatorio para que el producto sea entregado al cliente. Dada la criticidad de esta actividad, el equipo técnico debe asegurarse que el sistema se encuentre en un estado de madurez óptimo. Cualquier descuido puede causar una mala impresión de la calidad del sistema al usuario y por ende un retraso en el pago por el desarrollo.
Esta inspección incluye la revisión de las funcionalidades del sistema, cierre de todos los defectos registrados en la etapa de pruebas, elaboración de casos de prueba que serán utilizados en las pruebas de aceptación, adecuaciones al ambiente de pruebas (hardware, catálogo de datos, generaciones de perfiles de usuario, garantizar el acceso al ambiente de pruebas a los usuarios), revisión al plan de aceptación y criterios de evaluación, y soporte técnico durante las pruebas.
Esta inspección generalmente la realiza el departamento de QA. Se enfoca en garantizar que el paquete que contiene todos los componentes del sistema se encuentren listos para ser instalados. Esta inspección incluye cerciorarse que las versiones de los programas sean las correctas, las rutinas para instalación se encuentren listas, exista un procedimiento de roll back en caso de alguna falla durante la instalación y que el paquete final tenga las aprobaciones de los responsables.
Auditorías
Las auditorías se enfocan principalmente en la verificación de la documentación del sistema de conformidad con los estándares establecidos para el proceso de desarrollo del software. Su objetivo es descubrir no conformidades (NC’s – nonconformances) o desviaciones a las normas, políticas o lineamientos previamente entendidos y acordados por el equipo técnico. Las auditorías deben ser llevadas a cabo por personas especialistas o certificadas en auditorías de sistemas. Generalmente tienen una duración de una o dos horas, en las que el auditor verifica los documentos del proyecto y documenta las posibles no conformidades. El reporte de auditoría es revisado por los usuarios involucrados en la elaboración de los documentos, quienes deberán realizar los ajustes necesarios y cerrar cada registro de no conformidad.
Cierre de registros de no conformidad
Los registros de no conformidad (NCR’s) sólo pueden ser cerrados cuando se han establecido acciones correctivas, se ha generado un plan de acciones preventivas para no volver a caer en fallas al estándar y tiene la aprobación del auditor.
Clasificación de auditorías de sistemas
Según Chemuturi (2010) existe una variedad de formas en las que se pueden clasificar las auditorías, por ejemplo:
Auditorías de conformidad |
Auditorías de investigación
|
Se enfoca en la eficacia de la implementación del proceso de desarrollo, comparando los documentos del proyecto con los estándares de la organización. |
Su objetivo es encontrar causas raíces que provoquen fallas o un éxito extraordinario. Se revisan documentos y se llevan a cabo entrevistas con el personal para realizar este análisis causa-raíz |
Auditorías verticales |
Auditorías horizontales
|
Se llevan a cabo en toda la organización o haciendo una selección de un grupo de proyectos. |
Son parecidas a las auditorías verticales sólo que se enfocan en un aspecto particular. Por ejemplo, confirmar que la gestión de configuración se lleve a cabo en toda la organización o en un grupo de proyectos seleccionados. |
Auditorías periódicas |
Auditorías al final de la etapa
|
| Se llevan a cabo con base en un calendario, por ejemplo, una auditoría cada tres meses. Estas auditorías se enfocan en un grupo pequeño de proyectos en cada periodo, con el objetivo de revisarlos todos al final del ciclo. |
Se inician al terminar alguna etapa del ciclo de vida del desarrollo de un sistema. Su objetivo es encontrar que cada etapa se haya realizado conforme al estándar propuesto por la organización. |
Auditorías internas |
Auditorías externas
|
| Se llevan a cabo por el personal interno de la organización, pero pertenecen a un área diferente a la auditada. |
Se llevan a cabo por una agencia que se especializa en la auditoría de los procesos de software, con el objetivo de obtener un certificado que otorga una organización independiente y de renombre. |
En las siguientes imágenes puedes revisar un formato del reporte de no conformidades, producto de la auditoría:
Recuperado de Chemuturi, M. (2010). Mastering Software Quality Assurance. EEUU: J. Ross Publishing.
13.3 Validación del software
Según Chemuturi (2010), la validación del software se refiere a todas aquellas actividades que permiten confirmar que las funcionalidades diseñadas fueron realmente construidas y trabajan como fueron especificadas originalmente, junto con otras funciones implícitas para garantizar la seguridad y usabilidad.
La validación pertenece a las tareas del proceso del software de manera que pueda asegurarle al cliente que tiene las características que solicitó.
Existen tres factores que determinan la validación:
- Debe ser lo más imparcial posible, es decir, una validación es más efectiva cuando es llevada a cabo por personas independientes de la organización que desarrolla el software y a la misma organización del cliente. Cuando esto no sea posible, es recomendable que intervenga personal que no tenga que ver con el proyecto.
- Debe confirmar el cumplimiento a las especificaciones del cliente y especificaciones externas aplicables.
- Debe ser llevada a cabo a través de un plan de trabajo y mediante un esfuerzo coordinado, con el propósito de infundir confianza a las partes interesadas.
Validación de las especificaciones del producto
Las especificaciones del producto son el corazón de los criterios que se definirán para determinar que un software cumple o no con su objetivo. Una definición ambigua de los requerimientos puede tener repercusiones considerables al momento de tratar de entregar el producto al cliente, por lo que no hay que esperar que el software haya avanzado en su construcción para realizar actividades de validación. Las mismas especificaciones deben ser validadas. Esta validación puede ser realizada a través de juntas de revisión en las que se encuentren el equipo técnico del proyecto y los stakeholders.
Validación del diseño del software
Para validar el diseño del software se necesita la intervención de un grupo de personas expertas, que realicen una revisión exhaustiva del diseño, con referencia tanto al documento de especificaciones como a requisitos externos relacionados con las mejores prácticas del dominio del proyecto del software.
Validación del producto del software
Para validar el producto del software se tiene que llevar a cabo un plan de validación, crear casos de prueba de validación, pruebas de aceptación del usuario y generar un reporte de validación:
Plan de validación
Las actividades de validación deben ser planeadas con anticipación. Este plan debe establecer con claridad los objetivos que espera alcanzar, los criterios para evaluar cada etapa del software, el tiempo que se destinará para realizar la validación y asignar a los responsables. Las actividades que involucran la validación del software deben estar relacionadas con la complejidad del proyecto y los riesgos de seguridad que implican. Validar un software de un equipo de monitoreo de signos vitales de un hospital no es igual al software destinado a un video juego para niños.
El plan de validación debe considerar lo siguiente:
- Listado de elementos que serán validados.
- Alcance de las pruebas, es decir, qué incluye y qué se excluye de las pruebas de validación.
- Características del ambiente de pruebas.
- Roles y responsabilidades de cada actividad de validación.
- Cronograma del plan.
Casos de pruebas de validación
Los casos de prueba se diseñan con la finalidad de llevar a cabo un orden y control sobre las pruebas de validación. En ellos se registran los datos de entrada, la descripción de las condiciones previas a la ejecución, la secuencia de pasos para probar la funcionalidad y los resultados esperados o las condiciones posteriores a la ejecución. Las organizaciones pueden tomar la decisión de dar a conocer los casos de prueba de validación al equipo técnico (casos abiertos de pruebas), lo que asegura el resultado de las pruebas, o bien puede determinar que las pruebas de validación sean determinadas por el equipo que validará el software (casos cerrados de pruebas), o incluso hacer un listado de casos abiertos y cerrados.
Pruebas de Aceptación (UAT)
Las pruebas de aceptación del usuario son particularmente útiles para validad el software, ya que nadie es mejor para poner a prueba sus propios requerimientos que el mismo cliente.
Según Sommerville (2011), el proceso para realizar las pruebas de aceptación del usuario es el siguiente:
Proceso de prueba de aceptación. Recuperado de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
El proceso inicia definiendo los criterios que se tomarán en cuenta para aceptar o rechazar un sistema, los cuales deben ser acordados entre el desarrollador y el cliente. Se establece un plan para determinar el tiempo y recursos necesarios. Se generan los casos que probarán tanto los requerimientos funcionales como los no funcionales. Se ejecutan los casos preferentemente en un ambiente lo más parecido al que finalmente será utilizado. Se documentan los resultados de las pruebas. Generalmente las pruebas UAT descubren problemas no detectados y es necesario que el desarrollador y el cliente decidan si deben retrasar la entrega para corregirlos, o bien ponerlo en producción e incorporar los cambios necesarios en la siguiente versión. Finalmente, como resultado de este esfuerzo, se necesita un reporte de prueba donde se especifique con claridad la aceptación o rechazo del sistema.
“La influencia del entorno de trabajo del usuario tiene un gran efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un sistema” (Sommerville, 2011).
Reportes de validación
Los reportes de validación incluyen los registros de no conformidades que fueron detectadas durante el proceso de validación, incluyen el nombre del proyecto, autores de la validación, descripción de los elementos validados, fecha, aprobaciones, descripción de la no conformidad y respuesta del equipo de desarrollo responsable. Los reportes de validación también incluyen registros de métricas obtenidas durante el proceso de pruebas. Las métricas constituyen un indicador estadístico que corrobora un reporte de no conformidad.
