• Author / Uploaded
• Charliber Oficina

Citation preview

Unidad 1 / Escenario 2 Lectura fundamental

Ciclo de vida de las pruebas

Contenido 1

Ciclo de vida de las pruebas

2

Verificación de requerimientos

3

Verificación del diseño

4

Verificación de la programación

5

Principios de calidad del ciclo PDCA

6

Las pruebas en metodologías ágiles

7

Notas finales

Palabras clave: pruebas de software, inspecciones, pruebas unitarias, pruebas de sistema.

1. Ciclo de vida de las pruebas Las pruebas no se pueden apartar del ciclo de vida del desarrollo de software. Una vez que se ha definido el proceso y ciclo de vida del proyecto, la calidad y las pruebas van de la mano; se gestionan con el mismo ritmo en un plan específico para el aseguramiento que defina y se alinee con los objetivos, alcance, costos y tiempo establecidos por el plan general del proyecto. Las tareas relativas al aseguramiento forman parte del plan general y son consideradas actividades del proyecto. Como en todo proceso de software, las fases mínimas son el análisis, el diseño, la codificación, las pruebas y el mantenimiento. Usualmente las pruebas se consideran una fase, pero es claro que la calidad debe asegurarse en todas las etapas. Por lo tanto, el proceso de pruebas se realiza en cada una de estas fases. El propósito de las pruebas es validar que el análisis, diseño y codificación correspondan a los requerimientos, a través de un método de monitoreo y control ordenado. El mantenimiento (o avance por etapas) exige cambios sobre el software, que debe ser controlado por un proceso de administración de configuraciones que permita identificar componentes, versiones y facilite la integración. De allí la importancia de contemplar la documentación del usuario y la del sistema para cambios a futuro. Pero si hay una fase de verificación, ¿qué hacemos en las otras fases? Bien, ya vimos que la calidad no es solamente probar. Se requiere de procesos en los cuales la calidad se evidencie. Por ello, cada fase tiene una validación de la calidad que determina si el propósito de tal fase se cumple estableciendo los criterios de aceptación correspondientes. Cada proceso debe ir ligado con los datos de prueba que determinen que el producto se puede aceptar y el tipo de pruebas a realizar, como se muestra en la Figura 1, que desglosa el método V, diseñado por la Administración Federal Alemana para el control del proceso de desarrollo de software. En tal método, los requerimientos de usuario determinan las pruebas de aceptación por parte del cliente, dado que se define cada requisito como un conjunto verificable y medible, que el aplicativo debe cumplir. Así mismo, las pruebas del sistema corresponden al documento de especificación de requerimientos del software, que cubren en detalle los objetivos del programa que se debe entregar al cliente. La arquitectura del sistema se valida para establecer si cumple con las pruebas de integración de todos los subsistemas, módulos, aplicativos o librerías usadas para dar solución al problema planteado. El diseño detallado de cada programa, función o rutina debe cumplir con las pruebas unitarias para verificar que cada uno de los componentes cumple con las funciones asignadas, a partir de las entradas y salidas específicas y establecidas por los diseñadores e implementadas por los programadores. El plan de pruebas adaptado al ciclo de vida a desarrollar, en resumen, documenta la cobertura, los métodos, la documentación y las responsabilidades en cada fase del proyecto.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

2

El plan debe incluir al menos los objetivos, los elementos a probar, la estrategia a usar en el desarrollo de los procedimientos de prueba, su ambiente, criterios de aceptación, datos de prueba, tipos de prueba a realizar, sus responsables, el cronograma, los reportes y formatos, los riesgos, el control de cambios, la administración de la configuración, etc.

Figura 1. Modelo V de pruebas Fuente: 1tjf (s.f.)

En cada fase, las revisiones técnicas (inspecciones, presentaciones o revisión de pares) son las más adecuadas porque reducen la cantidad de errores producidos, porque se centran en áreas y objetivos particulares más pequeños, para asegurar que los componentes sean aptos para las fases posteriores de integración. Estas últimas son más costosas de corregir por las tareas a rehacer, las revisiones sirven además para documentar lecciones aprendidas y mejorar los procesos locales en cada etapa. De nuevo se usa el mecanismo de dividir y conquistar, al establecer un plan de pruebas en cada proceso llevado a cabo de manera estática, aunque en etapas posteriores, ya que hay software real a revisar en ejecución y pueden realizarse pruebas dinámicas. El modelo cíclico PDCA se aplica en cada fase con la definición del plan a seguir, la ejecución de las pruebas, el reporte de fallos encontrados y la corrección de los mismos. Así, no se pasa a la siguiente fase hasta que se esté libre de errores. En un modelo ágil, en espiral o por prototipos esto es igualmente válido que en los modelos tradicionales de línea conservadora. Para llevar a cabo una inspección de sigue el modelo de Fagan en el cual hay un líder, un relator, un programador y un inspector.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

3

Cómo mejorar... El estándar IEEE 829-2008 para la documentación de pruebas de software indica los elementos y etapas a ser cubiertas en un plan de pruebas.

La inspección se planea preparando el material, los participantes y la agenda. Se prepara para determinar el alcance de la prueba, asignar los roles y conocer del tema específico. Se lleva a cabo la inspección y el programador con los resultados conseguidos en el reporte, rehace el trabajo para entregar al líder y generar la siguiente inspección hasta su aceptación. Se llama prueba de pares porque son personas del equipo de trabajo y no auditores formales externos. Las inspecciones serán el mecanismo más usado en la gestión de pruebas, pues solo en las fases finales se tiene suficiente código para realizar pruebas dinámicas y de aceptación con la formalidad y rigor establecidos en el plan.

2. Verificación de requerimientos Las necesidades de usuario deben siempre terminar en una especificación de requerimientos de software que debe incluir una descomposición de funciones y una descripción de todas las interfaces. Esto para verificar el cumplimiento de requerimientos y definir los criterios de aceptación del sistema. En los procesos de mejora continua, los resultados de procesos anteriores llevan a la construcción de listas de chequeo que, clasificada en una taxonomía definida por la empresa, ayuda a la revisión de problemas presentados en el pasado y a la prevención y detección temprana de nuevos casos. Los errores deben ser documentados y reparados a la brevedad posible, porque ello fijará la prioridad y objetivos del proyecto a realizar, junto con sus costos, tiempo y esfuerzo requeridos. Una vez llegado a un acuerdo inicial, es necesario mantener un rastro que permita seguir cada requerimiento a través del código, las pruebas, los cambios, el tratamiento dado y su criterio de aceptación. Estas pruebas de aceptación son formales lideradas por el usuario final, en aras de validar el cumplimiento del producto final de software.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

4

Esto no quiere decir que no se puedan aceptar funciones por etapas o a medida que se vayan a montar en ambiente de producción. Esta es la base para la construcción de los casos de prueba, ya que se basa en las funciones solicitadas y en la descripción de los procedimientos o flujo de tareas obligados para llegar a los resultados requeridos por el cliente. Cada elemento de prueba debe documentarse indicando las características del mismo, de modo que se conozca su estado en cada momento del proyecto. A partir del PMBOK del PMI, en la Internet se ofrece una amplia gama de formatos que pueden servir a este propósito. Igualmente, la cantidad y esfuerzo deben estimarse para construir el plan de pruebas e integrarlo al proyecto determinando costos, tiempo, personal y adquisiciones necesarias para llevarlo a cabo.

3. Verificación del diseño El diseño es una representación del problema presentado en términos de los datos, el proceso de transformación y la presentación de las salidas en la plataforma del cliente y con la arquitectura adecuada a la solución requerida, de acuerdo a la lista de funciones determinada. El plan de pruebas de la fase anterior se complementa con la verificación de que todos los elementos representados en la especificación de requerimientos estén completos en el diseño realizado. Se generan adicionalmente matrices que determinan el tipo de pruebas a realizar y las de integración de acuerdo al grupo de funciones y módulos generados en el diseño. La logística y manejo de correcciones se agrega en esta fase, junto con el esbozo de la administración de configuraciones y las herramientas de pruebas. La fase de diseño proporciona la definición de la interfaz pública entre los programas a especificar, por lo que, de nuevo, las inspecciones son el medio de prueba preferido para detectar errores. Ya sea por fallas en el paso de argumentos o en el flujo de tareas de cada función definida para alcanzar la solución del problema. Igualmente, en este momento se alcanza a definir el conjunto de datos persistentes y la afectación que desde diferentes elementos del producto de software se tendrá. Con ello se pueden agregar factores de verificación adicionales como control de concurrencia, fallas de seguridad, doble afectación, etc. Las pruebas de integración y modulares empiezan a surgir por el agrupamiento de componentes y la separación de módulos con funciones específicas y necesarias en la interfaz pública de los programadores. Se puede validar el cumplimiento de prerrequisitos y las condiciones de las salidas, así como el tratamiento de los errores controlados por el sistema. El diseño de los algoritmos, que luego se codificarán, permite delinear los casos de prueba unitarios, avanzar en las pruebas de integración y modulares y terminar las de aceptación y del sistema. Los casos de prueba y el conjunto de datos se hacen cada vez más claros.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

5

La matriz de funciones, requerimientos, programas y elementos de prueba se va refinando. El flujo del programa permite la definición de combinación de datos a revisar y el establecimiento de límites y rangos a verificar la determinación de pruebas de carga, rendimiento y eficiencia. Con el diseño detallado podemos establecer casos de prueba de caja blanca y de caja negra, para las fases posteriores, además de las inspecciones del código, que son igualmente eficaces. La cobertura de las pruebas debe revisarse para establecer que todo el producto de software será probado; pues el detalle lleva a listas más largas de funciones y dejar de lado alguno es una posibilidad.

4. Verificación de la programación Para esta fase, el plan de pruebas está completo. Los resultados ya han sido definidos y la ejecución de los programas debe conducir a lograrlos. Se inician las pruebas dinámicas, a partir de las pruebas unitarias, las de integración, las modulares o de sistema y las de aceptación por parte del usuario. El propósito es detectar errores en ámbitos pequeños y solo al establecer su correcto comportamiento agregarlos al sistema. Cobra importancia el uso de herramientas para automatización de pruebas o la generación de datos aleatorios para las pruebas. Se pueden establecer técnicas de caja blanca y combinación de datos específicos para validar la lógica correcta del programa. Las pruebas se deben llevar a cabo en el ambiente de ejecución, pero no en el de producción, de tal suerte que no se afecten los datos reales, pero sean válidas las pruebas relacionadas con el desempeño y la interacción entre elementos internos y externos al sistema. Las pruebas de aceptación son ejecutadas por el usuario final y validan que los requerimientos establecidos se han cumplido y se realizan luego de que el equipo de desarrollo ha concluido las suyas, de acuerdo al plan de pruebas definido en el proyecto. Como se observa en la Figura 2, las diferentes fases del ciclo de desarrollo interactúan y aplican a lo largo del proyecto para obtener un producto de software de calidad y no de modo secuencial e independiente como era la usanza en el siglo pasado con proyectos de menor escala y con pocos o ningún usuario directo. Hoy en día estos elementos se entrelazan en ciclos de desarrollo cortos para mostrar avances y tomar decisiones sobre la marcha.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

6

Figura 2. Fases de desarrollo Fuente: Aksoy (s.f.)

5. Principios de calidad del ciclo PDCA Deming, en 1986, en su libro Out of the Crisis, indica que la calidad se logra con el cambio de filosofía, no con el seguimiento de pautas. Repasemos los puntos claves expuestos por él. Se debe pensar a futuro, planear a largo plazo, con la base de que la calidad requiere de educación, investigación e innovación para la mejora continua del producto, con un plan de aseguramiento de la calidad que mantenga el rumbo constante para las actividades diarias. Se debe cambiar de pensamiento, el aceptar los niveles de defectos y calidad va en contra de las leyes de la mejor continua de la calidad y afecta la productividad, mantenga criterios de tolerancia baja para los defectos y estándares altos para la calidad a lograr. Se debe anticipar los errores y detectar las causas que los producen, no se debe basar el sistema de calidad en la ejecución de pruebas exhaustivas; por el contrario, la mejora de los procesos y las técnicas de producción deben revisarse para asegurar la calidad, no solo del producto final sino de cada paso ejecutado. Se debe pensar en la calidad de los proveedores y no guiarse solo por su precio. La conciencia del trabajo en solitario no existe, las relaciones de negocios y el enfoque en aspectos especializados es cada vez más palpable. Por ello, se debe prestar atención a quienes proveen servicios en aras de obtener alineamiento en los aspectos de calidad, que aseguren un futuro para ambas partes y relaciones a largo plazo.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

7

La mejor continua exige actores instruidos constantemente. El entrenamiento es vital para el proceso; de lo contrario, los avances se harán por etapas y se tenderá a permanecer en un estado sin cambios a futuro, pues se creerá que ya las técnicas fueron aplicadas y no hay espacio para mayores mejoras. Se debe incentivar el conocimiento y la novedad en las personas. Se debe invertir en la gente. No basta con tener personal que haga el trabajo, toca que valore lo que hace y se sienta orgulloso de ello. Se debe entrenar al personal, escuchar sus opiniones, conocer los problemas que dificultan el desarrollo de su trabajo. Se debe inculcar que la calidad es parte de su responsabilidad, pero también el reconocimiento de un trabajo bien hecho. Se debe incentivar el liderazgo al delegar responsabilidades para que cada persona sienta que aporta al grupo y que se requiere de su buen desempeño. Se debe evitar generar retos que no se puedan cumplir y quemar el recurso. Es mejor contar con personas fiables y en mejora continua que quebrarlos y despedirlos por llevarlos más allá de sus limitaciones. Por el contrario, se debe descubrir sus fallas y entrenarlos para su mejora. Asociar la calidad con la detección de fallas en el personal conlleva al miedo. Igualmente, el temor entre áreas y las escalas de jerarquía en el personal afectan el desarrollo de la calidad, los aportes y sugerencias de mejora se convierten en piedras en el zapato. Por el contrario, se debe incentivar el trabajo en equipo, pero pensado siempre en la mejora de la empresa y que los errores descubiertos internamente no afectan, como sí lo hacen los hechos por el cliente. Se deben fijar metas realistas que describan el modo de lograrlas y especifiquen qué es aceptable y qué no lo es. La calidad no se consigue fijando metas sino mejorando los procesos y entendiendo las fallas que en ellos se presenta. Se deben definir estándares y procedimientos que ayuden a la empresa a tener calidad. Se debe impulsar la calidad desde el tope de la empresa. La calidad no se genera solo en las actividades operativas. El norte a seguir está dado por la mejora continua de la calidad; esta se logra a través del tiempo, con políticas e incentivos que redunden en beneficio para todos los integrantes de la organización.

6. Las pruebas en metodologías ágiles Como hemos dicho, el modo de llevar a cabo las pruebas va de la mano del ciclo de vida del desarrollo. Esto es válido aún para modelos en que el ciclo de vida no parece tan definido; más bien que parece planearse sobre la marcha. Si se siguen prácticas de desarrollo ágil, en consecuencia, las pruebas deben aportar al desarrollo. Deben verse no como una fase (una vez construido el software), sino en paralelo con el desarrollo, para garantizar que el avance continuo sea fiable.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

8

Ya que se da retroalimentación permanente de los cambios y las correcciones necesarias definidas, para que los tiempos de cada iteración se cumplan. No solo en cuanto a liberación de código sino en la verificación de su correcto comportamiento y aceptación antes de pasar al siguiente ciclo. Esto conlleva una reducción de la planeación y documentación de las pruebas, pero a cambio se centra en los casos de prueba siguiendo listas de chequeo. Por ello, debe involucrarse personal experto que aporte al grupo y no lo retrase. Algunos ingenieros que aplican métodos ágiles de desarrollo consideran que las técnicas de conducción de pruebas no aplican para las metodologías ágiles; aunque realmente sí lo hacen. Solo que lo antagónico entre los sistemas de desarrollo ingenieriles versus los métodos de desarrollo ágil se reflejan más en una lucha de pareceres que en las diferencias reales que los separan, las cuales son pocas. En pruebas ágiles se habla de desarrollo dirigido a pruebas, desarrollo dirigido a comportamiento o a aceptación, pero su núcleo se basa en los mismos principios y planes de los sistemas tradicionales, solo que, aplicados a cada iteración y funcionalidad, que se va agregando al software. De este modo, pequeños ciclos de la metodología de pruebas se desarrollan para pequeños grupos de requerimientos y en ciertos casos pueden ser probados dinámicamente solo hasta que se tenga el código fuente desarrollado o integrado. Por el contrario, en otras iteraciones las pruebas unitarias sí se realizan en el orden establecido, según como avance la programación. El reto es el tiempo, los imprevistos y la buena comunicación entre los integrantes para resolver rápidamente los inconvenientes presentados. El marco de referencia de pruebas ágiles se basa en 4 cuadrantes que dividen las pruebas entre dos ejes: i) aquellas que soportan el equipo de desarrollo y las que son críticas para el producto; el otro eje ii) las divide entre las que se hacen de cara al negocio y las que se hacen de cara a la tecnología. En cada cuadrante se ubican diferentes tipos de prueba y recomendaciones acerca de cómo llevarlas a cabo, pero es básicamente la aplicación de lo que se presenta en el módulo, solo bajo la filosofía de asegurar ciclos cortos, refactorización y reutilización del código. Para terminar, vale la pena indicar que en los cuadrantes se hacen recomendaciones para automatizar las pruebas. Sin embargo, esto debe hacerse con precaución, de tal suerte que la labor de programación de pruebas sea para aquellos aspectos que estén definidos como vitales y necesarios a entregar al cliente. De otro modo, se corre el riesgo de gastar esfuerzos en pruebas de elementos que no se sabe si serán o no importantes y definitivos en el software final a entregar.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

9

7. Notas finales Un plan de pruebas define las condiciones en que se ejecutarán, de acuerdo con el ciclo de vida del proyecto planteado. Se lleva a cabo a lo largo del proyecto en cada fase, para tratar de prevenir errores y hallarlos lo más pronto posible, esto evita costos mayores en etapas posteriores. La calidad y detección de errores va de la mano con las metodologías y herramientas de mejora de los procesos y el control a través de inspecciones para asegurar la calidad en cada etapa. La calidad no es labor de un día, ni un intento de un grupo de héroes, es una línea de pensamiento integral para cada labor diaria realizada con responsabilidad y entendiendo el beneficio de realizarla.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

10

Referencias Boloix, G. (2009). Evaluación en informática. Córdoba, AR: El Cid Editor | apuntes. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/ bibliopoligransp/detail.action?docID=3182407&query=Evaluaci%C3%B3n%20en%20 inform%C3%A1tica Echeverri, J., Aristizabal, M., González, L. Urrego, G., Polo, R. Reflexiones sobre ingeniería de requisitos y pruebas de software. (2013). Medellín, CO: Corporación Universitaria Remington. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu. co/lib/bibliopoligransp/detail.action?docID=4795310&query=Reflexiones%20sobre%20 ingenier%C3%ADa%20de%20requisitos%20y%20pruebas%20de%20software Hernándes, P. F. Á., & Ricardo, Z. P. M. (2006). Glosario de Términos Informáticos. Córdoba, AR: El Cid Editor. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran. edu.co/lib/bibliopoligransp/detail.action?docID=3167493&query=Glosario%20de%20 T%C3%A9rminos%20Inform%C3%A1ticos González, G. C., Domingo, N. R., & Pérez, M. Á. S. (2013). Técnicas de mejora de la calidad. Madrid, ES: UNED - Universidad Nacional de Educación a Distancia. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/detail. action?docID=3216137&query=T%C3%A9cnicas%20de%20mejora%20de%20la%20 calidad Gutiérrez, H. (2013). Control estadístico de la calidad y Seis Sigma (3a. ed.). México, D.F., MX: McGraw-Hill Interamericana. Recuperado de https://www.ebooks7-24.com/book. aspx?i=280 Gutiérrez, H. (2014). Calidad y productividad. (4a. ed.). México, D.F., MX: McGraw-Hill Interamericana. Recuperado de https://www.ebooks7-24.com/book.aspx?i=751 Maigua, G., & López, E. (2012). Buenas prácticas en la dirección y gestión de proyectos informáticos. Buenos Aires, AR: Editorial de la Universidad Tecnológica Nacional. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/ detail.action?docID=4909345&query=Buenas%20pr%C3%A1cticas%20en%20la%20 direcci%C3%B3n%20y%20gesti%C3%B3n%20de%20proyectos%20inform%C3%A1ticos Marcelino, A. M., & Ramírez, H. D. (2014). Administración de la calidad: nuevas perspectivas. México, D.F., MX: Grupo Editorial Patria. Recuperado de https:// ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/detail. action?docID=3227569&query=Administraci%C3%B3n%20de%20la%20calidad:%20 nuevas%20perspectivas

Pressman, R. (2010) Ingeniería del software un enfoque práctico (7a. ed.). México, D.F., MX: McGraw-Hill Interamericana. Recuperado de https://www.ebooks7-24.com/book. aspx?i=686 Project Management Institute. (2013). Guía de los fundamentos para la dirección de proyectos (guía del PMBOK®) -- Quinta edición. Pensilvania, EE.UU.

Referencias de gráficas 1tjf. (s.f.). Detailed Software Development Life Cycle V-Model Including Phases, levels, Documentation, Review [Ilustración]. Recuperado de https://www.123rf.com/search. php?word=v+model&imgtype=0&t_word=&t_lang=en&orderby=0&t_word=&t_ lang=en&oriSearch=cwqc&sti=lovmtztqt8wbpc8z3k|&mediapopup=14805492 Aksoy, R. (s.f.). Software engineering concept [Ilustración]. Recuperado de https:// www.123rf.com/stock-photo/software_verification.html?imgtype=0&oriSearch=code+ verification&sti=memnpvejo8m6uzlosi|&mediapopup=75970060

INFORMACIÓN TÉCNICA

Módulo: Pruebas y Calidad de Software Unidad 1: Calidad de software y el ciclo de vida de las pruebas. Escenario 2: Ciclo de vida de las pruebas Autor: Nelson Pérez Asesor Pedagógico: Manuel Fernando Guevara Diseñador Gráfico: Alejandro Torres Asistente: Ginna Quiroga Este material pertenece al Politécnico Grancolombiano. Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO POLITÉCNICO GRANCOLOMBIANO

13