ANEXO TÉCNICO

Actualmente el ICFES utiliza como metodología de Proyectos de desarrollo SCRUM, teniendo como principal objetivo generar constantemente nuevas versiones de los sistemas de información que generen valor de negocio, en los tiempos que se requieren y con alta calidad.

1.1 Concepto de calidad y pruebas del software

En el contexto del proceso de desarrollo de software entendemos la calidad desde los siguientes criterios básicos:

• Cumplimiento de los requisitos: “Conformance to requirements” (Xxxxxx -1979).

• Listo para su uso: “Fitness for use” (Juran and Gryna -1970).

Así mismos nos apoyamos en la definición establecido por la IEEE Std. 610 – 1991, donde se define la calidad del software como “el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.

Las actividades desarrolladas en la fase de pruebas hacen parte del ciclo de vida del desarrollo de software, estas actividades permiten tener cierta certeza sobre la funcionalidad esperada del sistema desarrollado, incluso permite verificar los flujos de excepción a fallos del sistema, estos pueden ser propios de la aplicación u ocasionados por causas externas al sistema.

La realización de estas pruebas de software, basadas en una metodología ágil de ejecución de pruebas, donde se definan y ejecuten tareas de verificación, garantizan la condición de calidad esperada por él sistema; estas pruebas pueden cumplir con principios ISTQB® (International Software Testing Qualifications Board) sin embargo se debe tener en cuenta que el objetivo principal es hacer la ejecución ágil de pruebas (Agile Testing) que permiten dar lineamientos y certifiquen que el producto sea probado y cumpla con la calidad necesaria incluso sin haber sido probado exhaustivamente.

1.2 Marco de referencia de los servicios a contratar

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

El marco de referencia aquí definido se suscribe a los siguientes estándares:

• ISO 9001:2000 que especifica los requisitos para un sistema de gestión de la calidad, ISO/IEC 9126:1991 ingeniería del software – calidad de producto, la cual contiene un modelo de calidad y medición que permite la evaluación de la calidad de un producto software.

• ISO 25000:2005

• IEEE 829 – 1998: Standard for Software Test Documentation. Define la documentación generada en cada una de las fases del proyecto de pruebas.

 IEEE 830 – 1998: Recommended Practice for Software Requirements Specifications. Proporciona una guía de buenas prácticas para la elaboración de una especificación de requerimientos.

• IEEE 1012 – 2004: Standard for Software Verification and Validation. Detalla los procesos de verificación y validación (V&V) del software, y su organización.

• IEEE 1061 – 1998: Standard for a Software Quality Metrics Methodology. Define el establecimiento, la implementación, el análisis y la validación de métricas de calidad de software.

• Estándares “de facto” aceptados por la industria.

Es conveniente recordar que la intención de las actividades de pruebas es asegurar la calidad de los productos de software desarrollados y con esto lograr niveles de satisfacción del cliente y de usuario favorables para la organización.

2 Servicio Pruebas de Software

2.1 Objetivo

Prestación de los servicios de ejecución pruebas ágiles de software, sobre los desarrollos de software del sistema PRISMA del ICFES.

2.2 Características del servicio

El servicio de ejecución de pruebas ágiles de software se prestará en las instalaciones del ICFES en Bogotá, y será tanto para los desarrollos de los grupos internos del ICFES como para el software desarrollado en un modelo tercerizado a una fábrica de software externa. A continuación se describen las condiciones mínimas requeridas, para que un contratista realice las pruebas de software:

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

La metodología definida debe garantizar que los sistemas actuales y los nuevos sistemas desarrollados por el ICFES cumplan con los requerimientos funcionales y no funcionales definidos con una ejecución ágil que permita tener el producto en condiciones de aceptación.

1. El contratista debe tomar como base metodológica los principios de pruebas agiles (agile testing) de la Agile Testing Alliance para establecer el plan de pruebas del ciclo de vida de los procesos.

Principios del Agile Testing

De forma similar a que el Manifiesto Ágil contiene principios que se aplican al desarrollo ágil de software, el Agile Testing engloba los siguientes principios:

 El Testing no es una fase: El testing continuo es la única forma de garantizar avance continuo, por esto, el testing se realiza continuamente junto con el desarrollo de software y demás actividades.

 El Testing hace avanzar el proyecto: Bajo métodos convencionales, el testing es una alcabala, en cambio en Agile Testing se proporciona retroalimentación continua, permitiendo corregir el rumbo continuamente durante el desarrollo de software.

 Todo el equipo realiza pruebas: en Agile Testing, los Analistas de negocio y Desarrolladores de software también ejecutan pruebas, no sólo los testers como en métodos convencionales.

 Reducir el tiempo para recibir retroalimentación: En Agile Testing, los equipos del área de negocio (el cliente) están involucrados en cada iteración, no solo al final durante la fase de aceptación, como resultado, el tiempo de retroalimentación se reduce y el costo de correcciones también es menor.

 Código limpio: Los defectos en el código se corrigen en la misma iteración, por lo que se mantiene el código limpio.

 Reducir la documentación de pruebas: Los Agile Testers usan listas de chequeo reusables en lugar de documentación extensa, se enfocan en la esencia de la prueba en lugar de detalles. Siguiendo principios ágiles estas listas de chequeo son el inicio de las definiciones de las pruebas y no el final, y el tester cuenta con libertad para aportar valor.

 Guiado por pruebas: El Agile Testing, las pruebas se hacen “durante” el desarrollo y no después del desarrollo como en métodos convencionales.

Algunas de las prácticas relacionadas con Agile Testing

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

 Test Driven Development (TDD): El desarrollo guiado por pruebas, es una técnica que combina un enfoque de refactorización del lado de desarrollo con un enfoque de probar primero en cuanto al testing. Aquí te dejamos el primero de una serie de artículos sobre el Test Driven Development (TDD).

 Acceptance Test Driven Development (ATDD): Es una dimensión del TDD aplicada al nivel de gestión de requerimientos de software, en el cual las pruebas escritas son a nivel de cliente, es decir, lo equivalente a una prueba de aceptación o test funcional. Aquí te dejamos un artículo sobre Acceptance Test Driven Development (ATDD) y como implementarlo con la herramienta Selenium.

 Behaviour Driven Development (BDD): También puede llamarse Story Driven Development. Bajo este enfoque primero se desarrolla una prueba funcional o de historia de usuario automatizada, luego se ejecuta el desarrollo aplicando TDD hasta que la prueba es exitosa. Aquí te compartimos un artículo sobre la herramienta Cucumber y su uso para aplicar Behaviour Driven Development (BDD).

 Testing exploratorio: Enfoque en el cual el aprendizaje de la funcionalidad, diseño de pruebas y ejecución de pruebas ocurren simultáneamente, en contraposición con el enfoque convencional en el cual primero se documenta la funcionalidad o requisito, luego se diseña el caso de prueba y luego se ejecuta de acuerdo a guiones prestablecidos. Las pruebas exploratorias no están predefinidas ni se ejecutan según un plan.

 Automatización de pruebas de regresión: Tanto la integración continua como la refactorización son prácticas necesarias para poder implementar una metodología ágil de desarrollo de software. Ambas técnicas implican modificar las fuentes de código constantemente, por lo que la automatización de pruebas de regresión por medio de herramientas es una necesidad imperiosa. Aquí te dejamos más información sobre herramientas para automatización de pruebas.

 Automatización de pruebas unitarias: Consiste en usar un marco de trabajo o framework (como NUnit) para ejecutar tus tests unitarios, en lugar de ejecutar estos manualmente una y otra vez cada vez que modificas el código. Para ello existen múltiples frameworks, muchos de los cuales pueden integrarse en los ambientes IDE. Estos test, usualmente desarrollados por los programadores utilizando herramientas tipo xUnit (Junit, Nunit, etc.), adicional a proveer guías para el diseño del software, que permiten verificar el comportamiento interno de pequeñas piezas de código y componentes menores (clases, métodos dentro de las clases, interacción entre clases y métodos, etc.). Sin embargo la responsabilidad del proveedor de pruebas es definir los lineamientos, estrategias, procedimientos y diseños para que el equipo de desarrollo interno ejecute estás pruebas.

2. El contratista deberá definir y ejecutar la metodología (actividades, roles, artefactos) de pruebas garantizando la ejecución de las siguientes pruebas:

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

3. El contratista utilizará las herramientas definidas por el ICFES en las actividades de pruebas de software para realizar la ejecución de pruebas y gestión de incidentes, verificando que se abarquen los tipos de pruebas definidos por el ICFES y su respectivo seguimiento. Estas herramientas son:

x. Xxxxxx

ii. TestLink

iii. JSF Unit

iv. Junit

v. Jmeter

vi. Kali Linux

vii. Selenium

viii. TestEngine

En caso en el que el contratista cuente con herramientas para su proceso de pruebas se evaluará en conjunto con el ICFES para definir cual set de herramientas se utilizará en la ejecución del contrato.

4. El contratista deberá entregar una estimación de esfuerzo definida en horas para las actividades relacionadas con pruebas por cada Sprint o ciclo realizado por cada miembro del equipo del contratista.

5. El contratista deberá hacer la generación de los datos de pruebas para hacer la ejecución de sus diferentes escenarios de pruebas. . El proveedor deberá generar todos los sets de datos (estructura, cantidad, relaciones entre datos), excepto

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

aquellos en que el ICFES decida apoyar su generación. En casos excepcionales por la cantidad de datos generados y la complejidad para procesos masivos el ICFES apoyará ésta generación, sin embargo para la ejecución de pruebas funcionales individuales o de flujos que no sean masivos será responsabilidad del contratista.

6. El contratista deberá ejecutar todas las pruebas de acuerdo a los casos definidos y acordados con el ICFES.

7. El contratista deberá realizar la transferencia del conocimiento al ICFES o a quien este designe durante la ejecución del contrato en los tiempos definidos en mutuo acuerdo por las partes. La transferencia de conocimiento se enfocará únicamente sobre los aspectos metodológicos y de desarrollo del proyecto definidos por el proveedor para la ejecución del contrato. Teniendo en cuenta las siguientes consideraciones:

Auditorio: El equipo del proyecto Prisma (Directivos de T.I., Gerente de Proyecto, Product Owner, Arquitectos de Datos, Arquitectos de Aplicaciones, Líderes de Desarrollo, Analistas de Desarrollo, Analistas Funcionales). Aproximadamente 30 personas.

Periodicidad: Al inicio del proyecto y cada vez que el contratista haga una modificación metodológica en su proceso.

Mecanismos: La transferencia de conocimiento se deberá realizar a manera de catedra en sesiones de no más de 10 personas con el equipo implicado y entregando la información digital que el contratista considere como apoyo al proceso.

Temática: Proceso metodológico de ejecución de pruebas (actividades, responsables, artefactos, etc.) definido y/o ejecutado por el contratista.

8. El contratista debe definir los lineamientos y estándares de calidad que se deberán seguir en el ICFES, e implementar los artefactos que los soportan (ej. Plantillas de validación y verificación, matrices, formatos, etc.), artefactos definidos y/o usados podrán ser utilizados libremente por el ICFES. Será decisión del ICFES proveer los artefactos definidos previamente para conocimiento y/o uso del contratista.

9. El contratista debe definir los indicadores de avance para el proceso de pruebas. Una vez se identifiquen las métricas necesarias se debe validar la viabilidad de obtención de las mismas, desde las herramientas utilizadas, y así generar los informes que permitirán realizar los análisis respectivos facilitando la toma de acciones y decisiones. Estos indicadores son independientes de los generados por el Scrum Tema en la ejecución de los Sprint, y se refieren únicamente a indicadores a nivel de ejecución y avance de tareas del equipo de pruebas del proveedor.

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

10. El contratista debe realizar una socialización y capacitación inicial sobre la metodología de pruebas de software propuesta, a los grupos de interesados que existan en el Instituto.

11. El contratista debe entregar una estimación de esfuerzo para cada ciclo de pruebas, a ser aprobada por el ICFES, y sobre la cual se realizará el pago del esfuerzo. La estructura del contrato determina que los 5 analistas tengan una dedicación mensual de 160 horas, si la tarea encomendada se realiza en un número de horas menor, las restantes deberán ocuparse según lo indique el ICFES. El cumplimiento del Sprint se medirá con indicadores propios de Scrum, pero la facturación del proveedor se debe realizar con relación a lo trabajado por el equipo de pruebas contratado.

2.3 Metodología

En la metodología de pruebas se deben establecer todas las etapas con sus actividades para ser realizadas durante el proceso de prueba de un producto entregado de software. Esta metodología debe permitir obtener la descripción de cada actividad a realizar, y a su vez debe establecer la documentación de entrada necesaria, así como la documentación de salida que se obtendrá durante el proceso de pruebas.

El contratista debe definir el proceso de pruebas y la metodología que serán ejecutadas durante la realización de los proyectos de desarrollo de software. Los proyectos de desarrollo y mantenimiento de software siguen una metodología que incluye fases, actividades y entregables del producto de software desarrollado. El proceso de pruebas definido por el proveedor deberá estar completamente alineado con la o las metodologías definidas para el desarrollo del software del ICFES, por tanto, el contratista deberá contemplar la ejecución de las actividades definidas de forma paralela a las fases de desarrollo definidas en los proyectos de desarrollo de software, y como complemento necesario a éstos. El control de la calidad asignado al proyecto permitirá determinar los niveles y tipologías de pruebas que deben contemplarse y aplicarse según la metodología usada. Las actividades de pruebas del producto de software deben estar enmarcadas dentro del siguiente esquema metodológico:

2.3.1 Planeación

Bajo el esquema de desarrollo de proyectos agiles, el equipo de pruebas hace parte de la planificación de los Sprint aportando información referente a la definición de los casos de prueba acorde a las historias de usuario diseñadas por el analista funcional. Estos casos de prueba deben discriminar que tipos de prueba (Automatizadas como JUnit, JSFUnit, Selenium o Manuales) se deben realizar para que historia de usuarios y que probar específicamente, este documento se realiza apoyado en desarrolladores e historias de

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

usuario más la experiencia que debe tener el Analista de pruebas teniendo en cuenta que no se solapen las pruebas del desarrollador y el analista de pruebas.

2.3.2 Ejecución

Durante el Sprint, se da inicio a la ejecución de las actividades necesarias para la ejecución de pruebas como configuración de ambientes de trabajo, ejecución de casos de prueba, elaboración de documentación e informes de seguimiento incluyendo los indicadores correspondientes, registro en herramientas de seguimiento y cualquier otra definida previamente y aceptada por el equipo de pruebas y el equipo responsable del producto de software. Durante la ejecución de pruebas se deben realizar actividades para cubrir aspectos como elaboración y ejecución de pruebas automatizadas a través de la grabación de scripts (Selenium, JMeter o cualquier herramienta para aplicaciones web definida por el ICFES) dentro del sprint de su equipo y acorde a los casos de prueba definidos al inicio del sprint. Teniendo en cuenta las siguientes actividades:

• Pruebas de Sistema: Estas pruebas se realizan sobre todo el sistema con el objeto de probar el correcto funcionamiento de los requerimientos funcionales y no funcionales determinados para cada módulo del sistema. Igualmente, se deben validar estándares y políticas del ICFES que serán entregados en su momento al proveedor adjudicatario. El proveedor puede realizar cuando lo considere necesario, la verificación de la estabilidad del producto entregado mediante la ejecución de las funcionalidades básicas (smoke testing).

• Pruebas de Integración: Las pruebas realizadas como integración deben verificar que al incrementar funcionalidades a las previamente probadas y certificadas, no se ha alterado el funcionamiento de estas y el sistema sigue funcionando según las necesidades para las cuales el producto de software fue construido.

• Pruebas Funcionales: El alcance de las pruebas desde el punto de vista funcional, estará acorde con los requerimientos entregados por el ICFES y con el diseño de los módulos correspondientes, considerando: la integración con otros aplicativos o plataformas, validaciones de usabilidad y de excepción, y reglas del negocio.

• Pruebas Automatizadas: En los escenarios que se definan conjuntamente entre el contratista y el ICFES, se requerirá automatizar las pruebas; para esto, deben ser completas, repetibles o reutilizables e independientes, especialmente para las pruebas de regresión.

• Pruebas de Aceptación de Usuario (UAT). Definir con el usuario final los casos prueba considerados en la ruta crítica, y acompañar al usuario en la realización de

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

pruebas para los casos previamente definidos y aprobados, con el fin de obtener su visto bueno con respecto a la solución implementada para suplir sus necesidades.

Y demás tipos de pruebas que se consideren indispensables para garantizar la calidad de los productos de software que se vayan a validar. La adecuación y correcto funcionamiento de los ambientes de trabajo necesarios para la ejecución de las pruebas serán responsabilidad del ICFES.

2.3.6 Seguimiento y Control

En esta etapa el contratista será el responsable de revisar los reportes de los errores encontrados en producción, y verificar si los escenarios cubiertos y los casos de prueba definidos cubrieron las pruebas correspondientes a las funcionalidades revisadas o si por el contrario son nuevos casos que no se contemplaron, en caso de no contemplarse el contratista asumirá los tiempos de la definición, ejecución de nuevos casos de prueba y la generación de informes necesarios para encontrar posibilidades de mejora.

2.3.7 Esquema general metodológico

A continuación se presenta el esquema metodológico de desarrollo donde se evidencia la participación del equipo de pruebas durante las diferentes etapas de los Sprint.

2.4 Funciones de roles adicionales

Auditor de Pruebas

Hacer una revisión del proceso para asegurar que exista una comunicación clara y oportuna respecto de las variaciones de ejecución del proceso de pruebas desde un punto de vista distinto de la función del Gerente de Aseguramiento de Calidad y Pruebas.

2.5 Despliegues

El ICFES es responsable de la realización de los despliegues de los aplicativos a probar en los ambientes de pruebas, y tendrá de forma permanente un analista para despliegues, teniendo en cuenta que esto facilitará la prestación del servicio y ejecución de las pruebas.

2.6 Gestión de Incidencias

El proceso de gestión de incidencias está directamente relacionado con la ejecución de pruebas y el seguimiento que de estas se realiza, así mismo, es utilizado para el reporte de

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

incidencias generadas por otros procesos como la verificación documental y las auditorías referidas en el Modelo Aseguramiento de Calidad (realizada por el ICFES o quien éste designe). El contratista deberá indicar como soporta y maneja la gestión de incidencias.

2.7 Entregables

Como resultado de las actividades de las distintas fases, el contratista debe generar como mínimo los siguientes entregables:

• Estimación de pruebas

• Matriz de trazabilidad de requerimientos, casos de uso o historias de usuario vs casos de prueba.

• Plan de pruebas y factores de riesgo de pruebas

• Cronograma de pruebas

• Informes de seguimiento de pruebas después de cada ciclo de pruebas.

• Especificación de casos de prueba

• Resultados de la ejecución de pruebas en las herramientas acordadas entre el contratista y el ICFES.

• Informe de avance de ejecución (diario y semanal por ciclo de prueba).

• Registro de incidencias en la herramienta determinada por el contratista.

• Informes finales de pruebas por sistema o módulo, incluyendo los indicadores.

• Informe de nivel de pruebas de integración y de sistema.

El Contratista debe entregar información en formato digital de toda la información que reside en sus herramientas.

2.8 Anexos

El contratista al iniciar la ejecución del contrato debe entregar un conjunto de documentos que expliquen en detalle los siguientes aspectos:

• Metodología de pruebas

• Procedimiento de Gestión de Incidencias

• Procedimiento de Automatización de pruebas

• Procedimiento de Gestión de Riesgos de Pruebas

2.9 Herramientas

La implementación y ejecución de la prueba son actividades donde los procedimientos o scripts de prueba, los casos de prueba y cualquier otra información necesaria para la ejecución de la prueba, se utilizan de una forma integrada, por lo tanto se requiere que los resultados de la ejecución de prueba y versiones del producto de software que está siendo

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

sometido a pruebas, queden registrados en las herramientas de prueba establecidas, esta información debe permitir comparar los resultados reales con los esperados, así como los diferentes reportes que contribuyen a asegurar la trazabilidad de las condiciones de prueba hacia las especificaciones entregadas en los documentos de casos de uso y diseño del producto de software. En este sentido el contratista usará las herramientas de las que disponga el ICFES para garantizar el desarrollo de las siguientes actividades:

• Planeación, ejecución, seguimiento y control de casos de prueba

• Gestión de incidencias

• Ejecución de pruebas de rendimiento, carga y stress

• Pruebas automatizadas

En caso de que el contratista ofrezca herramientas diferentes a las utilizadas por el ICFES

x. Xxxxxx

ii. TestLink

iii. JSF Unit

iv. Junit

v. Jmeter

vi. Kali Linux

vii. Selenium

viii. TestEngine

Se revisará su uso teniendo en cuentas los siguientes aspectos:

1. El licenciamiento será total responsabilidad del contratista.

2. La integración con las herramientas del ICFES estará a cargo del contratista y no deberá incurrir en desarrollos de software ni licenciamientos adicionales por parte del ICFES.

3. La información del proceso de pruebas deberá estar disponible inmediatamente se inicie la ejecución del contrato.

2.10 Procedimiento para la estimación de esfuerzo y pago de los servicios

El Contratista entregará la estimación para cada ciclo de pruebas en el formato acordado entre las partes para ser aprobado por el ICFES. En caso de requerirse el detalle de cada estimación, el Contratista deberá estar en capacidad de entregarlo. El ICFES se reserva el derecho de aprobar las estimaciones elaboradas por el contratista, y requerir los ajustes que sean necesarios. El pago de los servicios de pruebas de software se realizará sobre la ejecución aprobada del esfuerzo requerido para las fases de los ciclos de pruebas definidos. El contratista se compromete a ejecutar las pruebas en su totalidad, y a realizar el cobro de las mismas por el valor de horas acordado.

ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

3 Aspectos generales

3.1 Gestión de proyectos

La ejecución del servicio objeto del presente términos de condiciones se realizará como un proyecto, de forma que se pueda tener una gestión y control adecuado sobre el avance, logro de los objetivos y alcance propuesto. Se requiere que la metodología a utilizar por el oferente esté alineada con el Project Management Body of Knowledge (PMBOK®) del Project Management Institute (PMI). También, se deben cumplir los lineamientos que el ICFES indique al contratista con respecto a la gestión, reporte y control del proyecto. El contratista deberá presentar informes diarios y semanales del rendimiento del proyecto, adicionalmente asistir a todas las reuniones de seguimiento realizadas durante la ejecución del proyecto. El contratista debe contar con el licenciamiento de las herramientas de software necesarias para la realización de todos los procesos de la gerencia de proyectos, descritos en este anexo. Se requiere que el oferente use el software de gestión de proyectos Microsoft Project en la versión que determine el ICFES en el momento de la ejecución del contrato para poder revisar el cronograma, y cubierto por sus propias licencias.

3.2. Equipos de cómputo

El Contratista deberá disponer de los equipos de cómputo necesarios para el equipo de pruebas incluyendo las diferentes licencias de software utilizadas para la ejecución del contrato.

3.3. Lugar de ejecución del contrato

El Contratista deberá realizar las actividades relacionadas con la ejecución del contrato en las instalaciones del ICFES, en la ciudad de Bogotá.

Document Metadata

Table of Contents

ANEXO TÉCNICO

Document Metadata