Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Este documento ofrece una introducción al ciclo de vida de las pruebas en el contexto de la calidad de software. Se abordan conceptos clave como la verificación de diseño, las pruebas unitarias, las pruebas de sistema y el uso de inspecciones. Además, se presenta el método V y el estándar IEEE 829-2008 para la documentación de pruebas de software.
Tipo: Apuntes
1 / 13
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Palabras clave : pruebas de software , inspecciones, pruebas unitarias, pruebas de sistema.
Ciclo de vida de las pruebas Verificación del diseño Las pruebas en metodologías ágiles Verificación de requerimientos Principios de calidad del ciclo PDCA Verificación de la programación Notas finales
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.
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.
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.
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.
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.
Figura 2. Fases de desarrollo Fuente: Aksoy (s.f.)
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.
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.
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.
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.
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% 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% ingenier%C3%ADa%20de%20requisitos%20y%20pruebas%20de%20 software 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% 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% 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= 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= 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% 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:% nuevas%20perspectivas
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.
