Procesos de pruebas a sistemas operativos GNU/Linux

Transcripción

1 Procesos de pruebas a sistemas operativos GNU/Linux Testing process to GNU/Linux operating system Ing. Mónica Ma. Albo Castro Resumen La industria de software en el mercado es cada vez más competitiva, por lo que se deben presentar productos con la menor cantidad posible de efectos no deseados, ya sean errores o no. Los modelos de desarrollo de software que se promueven con el objetivo de lograr desarrollos más efectivos proponen actividades que aseguren y verifiquen la calidad de los productos. La actividad de pruebas verifica no solo la calidad final sino que el software cumple con todos los requerimientos, para lo cual existen diferentes tipos y estrategias de realización. Los sistemas operativos son un producto de software que a su vez incluye otros, por esta razón todo su proceso de desarrollo es altamente complejo incluido las pruebas. Los sistemas operativos GNU/Linux son una variante libre y un ejemplo de desarrollo basado en componentes, pues hereda un gran número de elementos desarrollados por terceros. Sin embargo es necesario verificar su calidad como en cualquier otro producto. El presente trabajo muestra un estudio de los diferentes procesos de pruebas que aplican los equipos de desarrollo de sistemas operativos GNU/Linux. Finalmente muestra el proceso de pruebas que utiliza actualmente la distribución cubana GNU/Linux Nova para garantizar la liberación de un producto con calidad para la migración a software libre en Cuba. Abstract The software industry in the market is more and more competitive, so it should present products with the least amount of unwanted effects, whether or not errors. The software development models that are promoted with the aim of achieving more effective development proposed activities to ensure and verify the quality of the products. The activity test verifies not only the final quality but the software meets all requirements, for which there are different types and implementation strategies. Operating systems are a software product which in turn includes other, therefore the whole process of development is highly complex tests included. The GNU / Linux operating systems are free version and an example of component-based development, as inherited a large number of elements developed by third parties. However it is necessary to check its quality as any other product. This paper presents a study of the various testing processes that apply development teams of GNU/Linux operating systems. Finally shows the testing process currently used by the Cuban distribution GNU/Linux Nova to secure the release of a quality product for migration to free software in Cuba. Introducción La evolución de la industria del software ha establecido modelos de desarrollo que exigen productos de alta calidad que aseguren la competitividad en el mercado. La calidad de software es un proceso que aplicado de manera eficaz genera un producto útil que proporcione un valor medible para los que lo producen y los que lo utilizan (1). Desarrollar software con calidad en tiempo y costos eficientes se puede conseguir aplicando buenas prácticas definidas en los diferentes modelos de desarrollo, entre las cuales se encuentra verificar continuamente la calidad del software (2). Esta es una práctica que puede incluir actividades de auditoría a los procesos del desarrollo para garantizar su correcto desempeño pero debe incluir también pruebas al software que muestren un resultado de calidad. Los modelos de desarrollo más difundidos en la industria de software incluyen entre sus procesos el aseguramiento de la calidad del software, el cual se ocupa de gestionar la calidad, tanto del proceso como del producto final, a través de diferentes actividades entre las que se pueden encontrar (1): Pruebas de software: función de control de calidad que tiene como objetivo principal encontrar errores. Por tanto se debe asegurar que las pruebas se planean y se llevan a cabo de manera eficiente.

2 Recopilación y análisis de errores/defectos: recopilar y analizar datos de errores y defectos para entender mejor cómo se presentan y cuáles son las actividades de ingeniería de software más adecuadas para su eliminación. Las pruebas dentro del desarrollo de un software tienen como propósito fundamental, como se mencionó anteriormente, comprobar el resultado del producto obtenido y su calidad antes de entregarlo al cliente (3). Las pruebas son un proceso individual y se han desarrollado varias estrategias de pruebas dependiendo de cada tipo de desarrollo y elemento a probar, todas ellas cumplen con varias características comunes (1): Las pruebas comienzan a nivel de componentes y trabajan hasta lograr la integración de todo el sistema. Diferentes técnicas de pruebas son apropiadas para diferentes enfoques de la ingeniería y en diferentes momentos del software. Las pruebas son conducidas por el desarrollador de software y un equipo independiente de pruebas. Las pruebas y la depuración son actividades diferentes pero esta última debe incluirse en la estrategia. Entre los distintos productos de software cuya calidad puede ser crítica para su utilización se encuentran los sistemas operativos, debido a que son el software que administra el hardware y proporciona las bases para las aplicaciones, actuando como intermediario entre el hardware y el usuario; algunos se diseñan para ser prácticos, otros para ser eficientes y otros para ambos objetivos (4). Definición que muestra un tipo de software grande y complejo que requiere un proceso de desarrollo cuidadoso que vaya diseñando y definiendo pieza por pieza el producto final. En la actualidad hay varios tipos de sistemas operativos (SO en lo adelante), pues estos pueden ser de propósito general o específico para una única funcionalidad como los desarrollados para equipos médicos e industriales. Dentro de los de propósito general hay varios que han ganado un lugar significativo en el mercado como son: Microsoft Windows, MacOS y GNU/Linux. La distribución cubana GNU/Linux Nova creada en la Universidad de Ciencias Informáticas al calor del proceso de migración a software libre que se lleva a cabo en Cuba, ha sufrido varios contratiempos en su despliegue en la isla. Entre ellos (5): Incompatibilidad con las diferencias entre equipamiento informático existente y el utilizado en el desarrollo. Errores durante la instalación en diferentes entornos. Falta de concordancia con las políticas trazadas en la Guía Cubana de Migración a Software Libre. El análisis de estas dificultades mostró que se utilizaba un proceso de desarrollo empírico sin actividades ingenieriles que aporten calidad al producto final. La única actividad de verificación y validación incluida es la de pruebas a elementos críticos del desarrollo como el instalador, que además son realizadas solamente por los desarrolladores. A raíz de estos resultados se comenzó a trabajar en un proceso de pruebas que permitiera liberar productos con menor número de no conformidades. Buscando además referencia de los procesos de liberación de productos homólogos y la aplicación de estándares internacionales de calidad. En este trabajo se muestra el análisis de estándares de calidad de alta referencia internacional, así como de los procesos que aplican algunas de las más difundidas distribuciones GNU/Linux para liberar sus productos. Estándares de Calidad En la actualidad existen varios modelos y estándares de calidad que establecen los elementos fundamentales requeridos para obtener productos de calidad. Una gran parte de estos se enfocan en proponer actividades y buenas prácticas durante el proceso de desarrollo con la premisa de que un proceso con calidad dará como resultado un producto con calidad. No obstante algunos proponen elementos específicos, asociados a los productos directamente, para la evaluación de su calidad. El ISO/IEC no es un estándar de calidad propiamente pero es el que brinda un marco común para el ciclo de vida del software y por tanto es altamente referenciado por los estándares de calidad. En varios de los procesos tanto del ciclo primario como del ciclo de soporte tratan sobre el aseguramiento y evaluación de la calidad del producto, con una evidente relación entre ellos. Entre las actividades se menciona el establecimiento de criterios de aceptación del producto, con las correspondientes pruebas de aceptación y su evaluación. Además se propone la realización de actividades de aseguramiento de la calidad tales como revisiones del producto por el cliente, también se expone los distintos niveles a los que se debe probar un producto de software. (6)

3 Por su parte la ISO/IEC es una guía para la aplicación de la ISO 9001, estándar de calidad de referencia internacional, a las especificaciones de los productos de software, sin modificar los requerimientos de este. El estándar trata cuatro enfoques del sistema de gestión de la calidad, Responsabilidad de la Dirección, Gestión de los Recursos, Realización del Producto y Medición, Análisis y Mejora. Para la presente investigación la autora se concentró en los elementos que propone el estándar para la Realización del Producto puesto que el objetivo es la evaluación de la calidad del producto de software. Entre los elementos tratados en la Realización del Producto propone que la planificación de la calidad debe definirse en conjunto con el proceso de desarrollo del software. (7) Para lograr planificar la calidad con el proceso de desarrollo el estándar propone varios elementos que deben tenerse en cuenta en las distintas actividades. Los requerimientos se considerarán completos luego de revisar y evaluar las necesidades del cliente por los desarrolladores y asociados en lo posible con las características de calidad. Los resultados de la etapa de diseño y desarrollo deben proporcionarse de tal manera que permitan la verificación respecto a los elementos de entrada y deben tener definidos criterios de aceptación para su validación. La verificación se realiza para asegurarse de que los resultados del diseño y desarrollo cumplen con los requisitos de entrada. Se puede realizar a través de revisiones de las salidas, demostraciones y/o prototipos, simulaciones o pruebas. (7) La validación del software está dirigida a proporcionar una razonable confianza de que este cumple con sus requisitos de operación, por lo que se realiza antes de proponer el producto para la aceptación del cliente. Deben tenerse en cuenta los posibles riesgos generado por las diferencias que tenga el ambiente de validación con el ambiente real donde se aplicará el software. Esta actividad puede realizarse a través de las pruebas, las cuales se pueden realizar a varios niveles. Las pruebas también deben ser planificadas definiendo los tipos de pruebas, los objetivos, la secuencia y alcance, los casos de pruebas, los datos de pruebas y los resultados esperados. Los procedimientos de pruebas deben cubrir el registro y análisis de los resultados obtenidos. (7) Otro estándar de referencia internacional en la industria del software es CMMI, el cual es un modelo de calidad que ofrece buenas prácticas que deben desempeñarse en un proceso para obtener productos con calidad. CMMI estructura estas prácticas en áreas de procesos de las cuales se analizarán la de Verificación y Validación que son las asociadas a la evaluación de la calidad del producto de software. El área de procesos verificación tiene como objetivo asegurar que el producto de software seleccionado cumple con sus requerimientos. Es un proceso incremental que se va realizando a través de todo el ciclo de desarrollo del producto, o sea, desde la verificación de los requerimientos hasta la del producto final. Las revisiones son un elemento importante en la verificación porque provee mecanismos efectivos para eliminar defectos, a través del entendimiento de los productos de trabajo asociados. (8) El área de procesos de validación tiene como objetivo demostrar que un producto o componente satisface la utilidad para la que fue creado cuando es colocado en el ambiente que será utilizado. Las actividades de validación pueden ser aplicadas a todos los aspectos del producto en cualquiera de sus ambientes. Debe seleccionarse de los productos de trabajo el que prediga mejor la satisfacción de las necesidades del usuario. El ambiente de validación debe simular el ambiente real donde se aplicará el producto, además debe incluirse a los usuarios finales en estas actividades. A pesar de su similitud con el área de verificación la diferencia radica en que esta se encarga de comprobar que el producto cumple con las funciones y objetivos por los cuales se desarrolló y la verificación como se mencionó lo que chequea es los requerimientos y los defectos derivados del desarrollo. (8) Las mencionadas características de calidad se recogen en el estándar ISO/IEC 9126 el cual ofrece un modelo de calidad de los productos de software común, a través de la definición de seis características de calidad y un modelo de evaluación de los productos de software aplicando métricas. Las características definidas son útiles no solo para la evaluación de la calidad sino además para definir entre otros usos los requisitos de calidad. Estas son aplicables a todo tipo de software, incluidos los programas de computación y los datos contenidos en el firmware. Provee una consistente terminología sobre la calidad del software y un marco para especificar los requisitos de calidad, permitiendo el intercambio entre las diversas capacidades del producto. (9) El marco del modelo de calidad de la ISO/IEC 9126 establece que desde las primeras etapas del desarrollo hay que comprender las necesidades reales del usuario con el mayor detalle posible, y representarlas en requisitos. Estas se pueden utilizar cuando se especifican la calidad externa e interna mediante las características y subcaracterísticas de calidad del producto de software. El

4 objetivo es lograr la calidad necesaria y suficiente para cada contexto de uso específico cuando el producto se entrega a los usuarios y estos lo usan en la práctica. (9) El producto de software íntegro se evalúa por los niveles de las métricas externas escogidas. La calidad del producto de software se debe evaluar fijando los objetivos de calidad para los productos finales e intermedios. La calidad del producto se debe desglosar jerárquicamente en características y subcaracterísticas que pueden usarse como una lista de chequeo en problemas relacionados con la calidad. Una explicación de cómo podría este modelo de calidad aplicarse en la evaluación de productos de software se contiene en el estándar ISO/IEC (9) Este estándar proporciona métodos para la medición y evaluación de la calidad de los productos de software en consonancia con el modelo de calidad de la ISO/IEC La importancia de las características de calidad de un software depende de la misión y objetivo del sistema del cual son parte, las necesidades del producto de software a ser evaluado deciden la relevancia de las características de calidad que satisfacen los requerimientos del sistema. (10) Para la evaluación de la calidad de un producto de software deben especificarse requerimientos de calidad en términos de las características y subcaracterísticas de calidad. Para lograr una correcta definición de estos debe conseguirse una especificación suficientemente detallada de las necesidades del software que resalte las características de calidad relevantes. Para esto puede realizarse una revisión de los requerimientos con los usuarios finales de forma que los evalúen acorde a sus necesidades. A partir de ahí deben identificarse los atributos de calidad para cada subcaracterística, teniendo en cuenta que estos son las propiedades medibles de un producto de software. (10) Una vez identificados los requerimientos de calidad del producto y los atributos, se define los niveles de evaluación que serán requeridos dependiendo del software. La evaluación de la calidad cuando se establecen atributos a todos los niveles del modelo de calidad se observa dentro del ciclo de vida del software de la siguiente forma: la calidad interna se mide para la verificación, o sea, en la etapa de diseño y desarrollo, la calidad externa se mide para la validación, o sea, etapa de integración y pruebas del sistema, la calidad en el uso se mide para comprobar su aplicación y recibir retroalimentación, o sea, etapa de operación. (10) Finalmente luego de ejecutada la evaluación se analizan los resultados en correspondencia con la escala de aceptación establecida para cada característica de calidad. Se pueden concretar en cuatro las actividades de un proceso de evaluación de la calidad de un producto de software cualquiera: Establecer los requerimientos de la evaluación, Especificar, Diseñar y Ejecutar la evaluación. Los resultados de la evaluación de la calidad aplicando esta norma puede ser utilizada por los directivos y desarrolladores/mantenedores para medir el cumplimiento de los requerimientos y realizar las mejoras donde sea necesario. De la misma manera el personal de mejoras del proceso puede utilizar estos resultados para determinar cómo el proceso puede ser mejorado, a través del estudio y examen de la información de la calidad de los productos del proyecto. (10) Pruebas en distribuciones GNU/Linux En el epígrafe anterior durante el análisis de los modelos de calidad de software se pudo apreciar que las pruebas juegan un papel fundamental en la evaluación de la calidad. Los diferentes autores sobre ingeniería de software plantean criterios que concuerdan mayormente, las diferencias fundamentales en las estrategias de pruebas radican en detalles sobre la forma de documentar o de evaluar la prueba. Los elementos básicos que debe cumplir cualquier proceso de pruebas son: Planificación de las pruebas: comienza desde las primeras etapas del desarrollo, se ajusta a las necesidades de cada iteración a medida que estas se vayan ejecutando. Se establece una estrategia central a seguir en función de las características del software, definiendo los ciclos de pruebas que se ejecutarán en cada iteración, así como una estimación de recursos necesarios y el calendario. Diseño de las pruebas: se puede realizar en paralelo con el desarrollo, en función de los requerimientos, los modelos obtenidos del análisis y el diseño, así como la arquitectura definida para el software. De esta manera se diseñan las pruebas para los distintos niveles. Las técnicas a aplicar para cada prueba dependerán de las características del software.

5 Ejecución de las pruebas: a partir de la estrategia definida en el plan de pruebas y de las iteraciones de desarrollo definidas se ejecutarán primero las pruebas de componentes de forma individual, aunque pueden probarse varios componentes en paralelo. A medida que se vayan obteniendo componentes con el nivel de calidad definido se comienzan a ejecutar las pruebas de integración, con las correspondientes pruebas de regresión necesarias. Cuando se tenga una construcción funcional del software se comienzan con las pruebas del sistema como un todo. De forma análoga a las anteriores cuando se tengan resultados con un nivel de calidad aceptable según los parámetros definidos se pasa a las pruebas de aceptación. Evaluación de las pruebas: en cada ciclo corto de pruebas al terminar de ejecutarlas se evaluaran los resultados de las mismas utilizando métricas que permitan establecer un nivel de calidad del software, así como el cumplimiento de los requerimientos. Cuando se prueba un SO de propósito general el dominio de datos y funcionalidades es muy amplio, implica todas las funcionalidades de todas las aplicaciones, la combinación al ejecutar más de una aplicación de forma concurrente, las funcionalidades de configuración del sistema, todas las variantes de configuraciones. En fin probar un SO completamente como se realiza a las aplicaciones implicaría mucho más tiempo del que requiere su desarrollo, por lo que se crean estrategias diferentes. Una de estas es la acción de liberar una versión del producto para que sea puesto a prueba por los propios usuarios a través del uso diario. Las distribuciones GNU/Linux no escapan a esta estrategia de pruebas por ello han creado mecanismos para incrementar su efectividad en la aceptación de los usuarios. Entre las diversas distribuciones GNU/Linux existen un conjunto de estas que basan su desarrollo netamente en las comunidades, como es el caso de GNU/Linux Debian. Otras son desarrolladas por empresas, con el apoyo de la comunidad, entre estos casos se puede encontrar a Ubuntu, Fedora. Por último se encuentran las distribuciones con licencias más restrictivas que poseen generalmente mayor robustez a cambio de un costo monetario por obtener soporte del sistema, como la distribución Red Hat. La diferencia en cuanto a quien lleva a cabo el desarrollo de una distribución implica que en ocasiones no es publicada documentación sobre el proceso de desarrollo de la misma, aunque existen elementos claves en cuanto a los procesos de pruebas que son visibles en todas las distribuciones. Este es el caso de la liberación de versiones mínimamente funcionales con el objetivo de someterlas a prueba por la comunidad, tal como se mencionó anteriormente. Bajo el concepto de versión alpha (α), beta (β), testing y estable, las distribuciones GNU/Linux pasan por un exhaustivo ciclo de pruebas que puede incluir en su equipo de probadores a usuarios finales con pocos conocimientos sobre informática. Este proceso aunque permite involucrar al usuario en las pruebas del software para obtener mayor calidad, trae como desventajas: Descontento de los clientes cuando alguna de las versiones, a pesar de ser intermedias, no cumple con sus expectativas. Períodos de pruebas muy largos y dependientes de los errores reportados por la comunidad. Debian es un proyecto colaborativo que tiene como objetivo el desarrollo y mantenimiento del sistema operativo libre con el mismo nombre, basado inicialmente en el núcleo Linux, aunque actualmente se trabaja en versiones para los núcleos de FreeBSD y Hurd, este último del proyecto GNU. Este proyecto ofrece más de paquetes de software precompilados y empaquetados en un formato que ofrece facilidades para su instalación, actualización y desinstalación. (11) El proyecto Debian cuenta con un grupo de personas dedicadas al aseguramiento de la calidad del producto final liberado (QA group), reciben el apoyo de los desarrolladores a través del esfuerzo de estos por mantener los paquetes lo más libre de errores como sea posible. Adicionalmente el proyecto se estructura en 3 distribuciones que facilitan el trabajo del grupo de aseguramiento de la calidad, estas son: Estable, Pruebas (testing), Inestable. Esta última es donde se cargan o ubican todos los paquetes de software inicialmente y comienzan a pasar por un conjunto de pruebas antes de su liberación. En la distribución Pruebas se colocan los paquetes que luego de un tiempo en la Inestable cumplen con: estar sincronizados con la arquitectura en la que fueron construidos, no tener dependencias que generen inestabilidad en su comportamiento, tener menos errores críticos que la versión del paquete que se encuentra actualmente en Pruebas. (11)

6 De esta manera los paquetes de software presentes en Pruebas se van convirtiendo en candidatos a liberación. A partir de este momento los administradores o el equipo de liberación toma la responsabilidad de decidir cuando la distribución está lista para ser candidata a liberar como estable. Para liberar una versión de Debian como estable, o lo que es igual, pasar los paquetes de Pruebas a Estable, el primer paso es comenzar un congelamiento de la distribución Pruebas a través de la disminución de propagación de paquetes desde la Inestable y se somete a ciclos de pruebas con vistas a la liberación de la Estable. (11) Durante un período todos los esfuerzos se centran en realizar correcciones de errores críticos de liberación en los paquetes que se encuentran en Pruebas. Una vez que los errores estén por debajo del valor máximo aceptable se congela la distribución Pruebas y se pasa a Estable siendo liberada como producto final a la comunidad. El grupo QA cada cierto tiempo convoca a la comunidad a lo que se conoce como bug squashing parties con el objetivo de eliminar la mayor cantidad de errores posibles. En su anuncio en las listas de desarrolladores el área en que se debe enfocar la búsqueda de los problemas, aunque generalmente se enfoca en los errores críticos de liberación. (11) Además el proyecto Debian cuenta también con un sistema de seguimiento de fallos (BTS por sus siglas en ingles), que sirve como apoyo a las actividades de pruebas. Este almacena los detalles de los fallos reportados por usuarios y desarrolladores asignándole un número, hasta que se marca como resuelto o arreglado. Los fallos reciben una clasificación que ayuda a establecer prioridades para su resolución, entre estas se encuentran: critico, grave, serio, importante, normal, menor, entre otros. (11) En el caso de Ubuntu es una distribución GNU/Linux que basa su desarrollo en la mencionada Debian, bajo la filosofía de crear un entorno más fácil de utilizar por todos. Aunque mantiene las ideas del desarrollo colaborativo, a través de la comunidad, también es sostenida por una empresa, Canonical, la cual posee un portafolio de servicios. En la comunidad radica el mayor peso del desarrollo y dentro de esta hay líderes responsables de elementos críticos del proyecto. (12) Al igual que Debian cuenta con un equipo de calidad (QATeam) que se encarga de asegurar la calidad de los productos a liberar. Apoyado fuertemente en la comunidad centra sus actividades en la realización de pruebas, ya sean manuales, automáticas, a la imagen 1, a las aplicaciones, entre otras clasificaciones. Para sus actividades este equipo cuenta con un repositorio principal (QA Tracker) donde gestionan los casos de pruebas y sus resultados. Este se encuentra estructurado de forma jerárquica partiendo de los hitos de desarrollo con sus estados (en este caso entre paréntesis), ejemplo: Trusty Alpha 1 (liberado), Trusty Daily (pruebas), etcétera. (12) Cada hito contiene una lista de los productos desarrollados, estos se muestran con la versión, el número de casos de pruebas diseñados y cuántos de estos han sido ejecutados y los errores generales reportados hasta el momento. En este punto se brinda la opción de descargar el producto y acceder a los casos de prueba asociados con sus respectivos resultados, los cuales son clasificados en (12): Obligatorios: son aquellos que siempre deben ser ejecutados, desde que comienza a probarse el componente hasta que se comprueba que funciona correctamente. De ejecución única: deben ejecutarse al menos una vez, pero no es requerido volverlos a ejecutar cuando sale una nueva versión del componente. Opcionales: no son relevantes para considerar el componente probado pero ayuda a asegurar que no existirán regresiones. Una vez que se acceda a los detalles del producto se observa un listado de todos los casos de pruebas con sus respectivos resultados, ya sea que fue satisfactoria o que fallo o que está siendo ejecutado, así como los errores que fueron reportados en sus ejecuciones. Los errores que se muestran en los distintos niveles están clasificados en críticos y no críticos, lo cual ayuda a establecer las prioridades para su resolución. En los detalles del caso de prueba se puede observar que básicamente estos describen los pasos a ejecutar y los resultados esperados. (12) En caso de que ocurra un fallo o no se comporte de la forma esperada se reporta como error, para lo cual se debe consultar primero la lista de los ya reportados en ejecuciones anteriores del caso de prueba y para no duplicarlo se anota el número del reporte anterior 1 Una imagen ISO es un archivo donde se almacena una copia o imagen exacta de un sistema de ficheros.

7 para incluirlo en el reporte del error. De esta forma se evita la duplicación del reporte y permite al equipo que realice la corrección analizar las distintas ocurrencias del mismo. Ubuntu además utiliza pruebas automáticas a través de herramientas y scripts, en este caso autopilots y autopkg. La primera se utiliza para realizar pruebas funcionales incluyendo la simulación de la interacción del usuario y publica los resultados automáticamente, el equipo de QA mantiene un repositorio para estas pruebas. En el caso de las pruebas autopkg son ejecutados durante la construcción de cada paquete, se ejecutan automáticamente por el buildbots 2, ayudando a probar la integración para garantizar las funcionalidades básicas. (12) Por su parte Fedora es un sistema operativo Linux desarrollado por el proyecto que lleva el mismo nombre, el cual es una colaboración de miembros de las comunidades de software libre a nivel mundial. Posee un proyecto de aseguramiento de la calidad que se encarga de mejorar continuamente la calidad de las liberaciones y actualizaciones de la distribución. Entre las actividades fundamentales que realizan se encuentran (13): A través del sistema de probadores experimentados, probar todas las actualizaciones de los paquetes del camino crítico antes de que sean aceptados. Desarrollar y ejecutar herramientas que de forma automática encuentren errores potenciales. Trabajar con los desarrolladores e ingenieros de liberación para mantener los criterios de liberación, los cuales son utilizados para determinar que errores deben corregirse primero. Gestionar el proceso de liberación conjunto con el equipo de ingenieros de liberación, incluyendo la solicitud de productos candidatos para su validación. La utilización de criterios de validación tiene como objetivo principal especificar claramente los criterios que debe cumplir cada una de las liberaciones del producto. Esto ayuda a reducir la toma de decisiones subjetivas respecto a cuándo se está listo para entregar una versión del producto. Permite mostrar, a aquellos que no están involucrados en el desarrollo, los objetivos y metas de la versión en proceso de liberación. Además ayuda a enfocar el propósito de la misma, evitando tareas que salgan del alcance y valorando si se está en el camino correcto para lograr los objetivos. Los criterios de liberación pueden ser utilizados para valorar si los errores reportados son críticos para la finalización y posterior liberación del producto, estos se definen en función de los requisitos del producto. (13) Para el proyecto Fedora se establece como política que la mayor prioridad la tiene cumplir con la fecha planificada para la liberación, por tanto si una funcionalidad (paquete de software o característica añadida) no puede ser liberada con calidad se saca de la versión. Para garantizar calidad en la fecha planificada como segunda prioridad se deben solucionar primeramente los errores reportados en las actualizaciones de los paquetes. Las nuevas funcionalidades o características pueden ser añadidas en las próximas liberaciones, por lo tanto no son una prioridad. Puede ocurrir que un requerimiento no se cumpla correctamente para determinado perfil de hardware o bajo ciertas condiciones de ejecución, en estos casos se reporta al equipo de liberación quien se encarga de decidir la criticidad del error. (13) Pruebas en distribución GNU/Linux Nova La distribución GNU/Linux Nova como se mencionó anteriormente se desarrolla en el centro de desarrollo de software CESOL de la UCI, y actualmente está propuesta como solución principal para la migración a software libre en Cuba. El hecho de que sea un proyecto de un centro de desarrollo que debe cumplir ciertas normas y estándares institucionalizados ha generado la necesidad de que se definiera un proceso de desarrollo formal, a diferencia de sus productos homólogos. El proceso de desarrollo actual de la distribución se estructura como muestra la Figura 1, observándose dos momentos fundamentales de pruebas de software, las pruebas a los paquetes de software que se añaden al repositorio y las pruebas del sistema previo a la liberación. 2 Sistema de automatización del proceso compilación/prueba que ayuda a los proyectos de software a realizar la construcción con prueba de ejecución cada vez que la base de código se cambia. La idea es poner a prueba constantemente el software o asegurarse de que todavía compila para que los errores simples se descubran más pronto, antes de que sea cara su corrección.

8 Figura 1: Proceso de Desarrollo de Nova El proceso de pruebas para la distribución GNU/Linux Nova se concentra en las pruebas del sistema e intenta contener algunos elementos de sus similares y buenas prácticas de los estándares de calidad institucionalizados en el centro. Entre estos se encuentra CMMI para las buenas prácticas del proceso teniendo como referente del ciclo de desarrollo al ISO/IEC Por ellos cuenta con las siguientes actividades (ver Figura 2): Figura 2: Proceso de Pruebas de Nova Planificación de las pruebas: fundamentalmente gestiona el Plan de Pruebas, desde las primeras etapas del desarrollo del software se definen los tipos de pruebas, las condiciones, los recursos necesarios y el macrocronograma. Cuando se culmina el diseño de las pruebas y la selección de las pruebas automáticas y el producto está listo para entrar en la etapa

9 de se debe realizar una planificación más concreta de las actividades específicas de las pruebas con los recursos con los que se cuenta en el momento. Diseño de las pruebas: se definen cuáles serán las pruebas a realizar, sus condiciones y pasos de ejecución. Los casos de pruebas se clasifican según quien los ejecuta y la forma en que se ejecutan, por un lado las pruebas que ejecutan los probadores y las de aceptación por el cliente. Estas últimas teniendo en cuenta los criterios de aceptación de los clientes o usuarios hacia los que va dirigido el producto. Por otra parte las pruebas manuales o automáticas, debido a que hay requerimientos específicos que son complejos de evaluar manualmente, ejemplo los de rendimiento. Las alternativas automáticas requieren de una guía que indiquen el resultado esperado. Selección y/o implementación de las pruebas automáticas: seleccionar, configurar o implementar las pruebas que se realizarán de forma automática. Para lograr esto se deben seleccionar los casos de pruebas que necesitan ejecutarse de esta manera, revisar la batería de pruebas que ofrece la herramienta utilizada con este fin, seleccionar las necesarias y configurar o implementar las pruebas que satisfagan el resto. Las pruebas automáticas que se implementen deben probarse para validar su funcionalidad antes del ciclo de prueba, evitando así que los resultados del proceso de pruebas no sean válidos y acertados. Ejecución de las pruebas: verificar la calidad del producto y comunicarlo al equipo de desarrollo para que tome decisiones al respecto, se ejecutan los casos de pruebas y comunican las no conformidades al equipo. Es importante tener en cuenta en el momento que se realizará cada ciclo de pruebas pues de eso depende la batería de casos de prueba a ejecutar. La comunicación de las no conformidades al equipo debe hacerse en un lugar accesible a todos para que se solucionen con mayor prontitud. Los casos de prueba deben mantenerse actualizados en función de los cambios que pueden haber surgido durante el desarrollo, para que luego no queden reportes de no conformidades que no procedan. Las pruebas automáticas mencionadas anteriormente se realizan con la herramienta Phoronix Test Suite, la cual es una herramienta desarrollada por el proyecto Phoronix que ha recibido la colaboración de múltiples productores de hardware y se difunde bajo licencia GPL v3. Contiene más de 160 perfiles de pruebas que incluyen el chequeo del hardware y tiene un soporte opcional para realizar comparaciones de los resultados en su página web oficial con otras distribuciones o sistemas operativos. En la última actividad es donde se evidencia la estrategia de pruebas definida para el producto de software a evaluar, generalmente se realizan diferentes iteraciones, las pruebas a la versión Alpha, al Beta, las pruebas de uso diario y las pruebas de aceptación (ver Figuras 3 y 4). En el proceso definido se aplican las buenas prácticas de CMMI en las áreas de proceso de Verificación y Validación, además se evidencian fundamentalmente en su integración al proceso de desarrollo actividades de la ISO/IEC Figura 4: Pruebas a la versión Beta Figura 3: Pruebas a la versión Alpha. Al igual que las otras distribuciones GNU/Linux, Nova basa las decisiones de liberación en la existencia de un valor mínimo aceptable de errores con lo que define una evaluación cualitativa de la calidad. A diferencia de los productos homólogos, que fueron creciendo con la comunidad que apoya su desarrollo, Nova se ha desarrollado como un proyecto institucional y con poco apoyo comunitario. Esto último incide en que no se puede realizar un amplio proceso de pruebas en un período de tiempo relativamente corto que logre una evaluación amplia y detallada del producto final.

10 Conclusiones Las pruebas desempeñan un papel fundamental en la evaluación de la calidad de un producto de software, permitiendo observar su comportamiento y verificar cada una de las funcionalidades del mismo. Para lograr esto un proceso de prueba debe ser estratégicamente planificado acorde a los planes de desarrollo y definir y diseñar casos de pruebas que abarquen todos los requerimientos del producto. Otro elemento importante es ejecutar varias iteraciones de pruebas comprobando que se van corrigiendo los errores y no conformidades a través de la evaluación de los resultados. Las pruebas a las distribuciones GNU/Linux son un proceso complejo debido a la dimensión del producto, sin embargo a través de la estrategia de las liberaciones de pruebas se consigue incluir a la comunidad para lograr abarcar más elementos de pruebas. La distribución GNU/Linux Nova posee un proceso de pruebas que aplica las buenas prácticas de CMMI y de los proceso de pruebas de sus productos homólogos, con lo que logra realizar liberaciones de productos con un mínimo aceptable de no conformidades. Referencias 1. Pressman, Roger S. Software engineering: a practioner's aproach. 7ma. Nueva York : McGraw-Hill, Kruchen, Philipe. The Rational Unified Process: An introduction. 3ra. Boston : Pearson Education, Jacobson, I., Booch, G. and Rumbaugh, J. El proceso unificado de desarrollo de software. Madrid : Pearson Educación S.A., Silberschatz, A., Galvin, P. B. and Gagne, G. Fundamentos de sistemas operativos. 7ma. Madrid : McGraw-Hill/Internacional de España, Pierra F., Allan. Conceptualización y reestructuración estrategica de la distribución cubana de GNU/Linux "Nova". La Habana, Cuba : Universidad de Ciencias Informáticas, IEEE. ISO/IEC 12207: Standard for Information Technology - Software life cycle processes Oficina Nacional de Normalización (NC). Ingeniería de Software - Directivas para la aplicación de la NC ISO 9001:2001 al software de computación (ISO/IEC 90003:2004, IDT) Software Engineering Institute. CMMI for Development, v CMU/SEI-2010-TR Oficina Nacional de Normalización. Ingeniería de Software - Calidad del producto - Parte 1: Modelo de Calidad (ISO/IEC :2001, IDT) ISO/IEC. ISO/IEC 14598: Standard for Information Technology - Software product evaluation : Debian. Debian the universal operating system. Wiki page for Debian QA Group. [Online] Octubre Canonical Ltd. Ubuntu Community. Wiki QATeam. [Online] Red Hat Inc. Fedora Project Wiki. [Online] Octubre