Las pruebas que comprueban la corrección del código fuente de una aplicación son
Unidad 4: Aspectos técnicos del Testing de software
4.1. La prueba de sistema dentro del CVD
Lo que sí tiene que quedar en claro es que es justificadamente necesario tener una metodología de pruebas bien integra con el proceso de desarrollo.
¿Y cómo se integra?
Más allá del modelo de ciclo de vida que adopte el proyecto para el desarrollo del sistema, las pruebas deben adaptarse e integrarse al modelo de CVD adoptado por desarrollo.
Considerando un proceso de desarrollo en términos generales, se puede decir que éste contiene las etapas de Análisis, Diseño, Implementación o Desarrollo propiamente dicho y Mantenimiento
Nótese que no se ha establecido una etapa de pruebas, ya que la misma estaría contenida en la fase de Implementación.
Como ya se ha visto: Análisis o Requerimiento, sería la etapa de requerimientos y es la que determina la viabilidad y especificación de los requerimientos, Diseño la etapa en la que se especifica el diseño general y detallado del sistema, Implementación implica la codificación, pruebas, depuración e instalación del sistema y el Mantenimiento es la parte del ciclo de vida de desarrollo en la que el sistema se mejora y/o se modifica.
Modelo Secuencial
También llamado modelo en cascada.
En este CVD las actividades de desarrollo se llevan una después de la otra, es decir secuencialmente
La etapa de pruebas se la separa de la etapa de Implementación, siendo que es la materia de estudios u lo que se desea destacar.
El control de la calidad y las pruebas llegan tarde al proyecto. Y eso genera que se realicen sólo si resta tiempo. Cuando las pruebas se hacen tan tarde, cada error encontrado tiene un alto costo.
Análisis de Requerimientos—diseño– Implementación –Pruebas de Aceptación–mantenimiento
Es necesario introducir puntos de control de calidad mucho antes en el CVD.
Modelo V
Es uno de los más usados en interacción con pruebas, ya que organiza las actividades de pruebas en sus diferentes niveles.
En este modelo hay un ordenamiento de las actividades, tanto de desarrollo como de pruebas, en una secuencia de tiempo. Las actividades de Desarrollo y de Pruebas están desarrolladas como dos ramas iguales dibujando una V, donde para cada nivel de desarrollo existe un nivel de pruebas correspondiente
Partiendo con los Requerimientos, ni bien se cumple con esta etapa de desarrollo, se sigue con la siguiente que es Diseño. Respecto de pruebas, se puede ver una correspondencia con las Pruebas de Aceptación. Lo que se puede adelantar de este nivel, no es la ejecución, ya que el producto todavía no fue programado, ni siquiera fue diseñado
. Lo que se puede adelantar es la Especificación de los casos de pruebas para el nivel de aceptación
Lo mismo para todas las etapas siguientes. Ni bien se termina con el diseño funcional, se cuenta con todo para poder hacer la especificación de los casos de pruebas de sistemas, y otros.
Cuando se tiene ya el código desarrollado, es el momento en que se puede comenzar con la ejecución de los casos
Al adelantar la especificación, ni bien se cuenta con los primeros componentes, se puede comenzar con la ejecución.
Esta es una primera ventaja explicada
La otra es que, cuando se están especificando los casos de pruebas, por ejemplo con el documento de Requerimientos listo, necesariamente se están revisando esos documentos, eliminando ambigüedades, supuestos y puntos que pudieran estar faltando.
Es Verificación porque cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le precede.
Recordar que verificar significa comprobar si los requisitos y definiciones de niveles previos han sido implementados correctamente.
Es Validación porque se refiere a la corrección de cada nivel de desarrollo. Validar significa comprobar lo adecuado de los resultados de un nivel de desarrollo
Modelo Incremental
Este modelo responde al proceso de establecer requerimientos, diseñar, construir y probar un sistema en ciclos de desarrollos más cortos. Se ejecutan de forma continua, constituyendo una iteración.
Tras cada iteración se debe alcanzar la aprobación del cliente. Debe contar con personal entrenado ya que la calidad que obtenga va a depender de la calidad del equipo.
Cada iteración contribuye con una funcionalidad a desarrollar, y puede ser probada por separado. En cada iteración, la verificación (relación con el nivel precedente) y la validación (grado de corrección del producto dentro del nivel actual) se pueden efectuar por separado.
Ya que por cada iteración, es necesario probar las funcionalidades nuevas y a su vez volver a probar el sistema completo para asegurar que lo que antes funcionaba, sigue funcionando.
4.2.Proceso de pruebas
Los procedimientos especifican lo que debería hacerse durante cada fase y cada subfase de trabajo, y tareas son detalladas suficientemente.
Dependiendo del enfoque que se seleccione el proceso de pruebas tendrá lugar en diferentes puntos del proceso de desarrollo.
¿Qué debería contener un proceso de pruebas?
• Identificación de requerimientos de Prueba • Planeamiento de la prueba • Ejecución de la prueba • Clasificación de los errores • Mediciones • Seguimiento de los errores • Administración del proyecto de pruebas
Como las pruebas constituyen un proceso en sí mismas, partiendo del proceso básico (Planificación, Especificación, Desarrollo de la prueba, Ejecución, Evaluación y Seguimiento)
Planificación de las pruebas
Tomando a las pruebas como proyecto en sí mismo, requiere de diversas actividades a desarrollar que tienen que ver con la planificación.
– ¿Qué va a ser probado?-¿Qué es necesario para probar: equipos, recursos…?
Incluye la definición del alcance y de los riegos, la identificación de los objetivos de las pruebas y los criterios de salida de pruebas, la determinación del enfoque de las pruebas y en función del enfoque las técnicas, los niveles de cobertura y criterios de satisfacción.
Implica, como en todo proyecto, establecer el equipo de pruebas requerido y su programación. Se deben explicitar los detalles del nivel de recursos y si es necesario o no formación adicional.
Todo esto que se defina, debe quedar contenido en un documento denominado Plan de Pruebas.
El mismo puede ser un documento de 20 ó más hojas, o sólo un par de hojas
Análisis y diseño de pruebas
Se debe analizar la testeabilidad definida como la capacidad del sistema, componente u objeto, a ser probado.
Esta etapa es el proceso de definir los casos de pruebas que mejor permitan verificar que se cumplan los requerimientos de prueba.
Se analizan las especificaciones, el comportamiento y estructura del sistema, para identificar las condiciones de prueba.
Dentro del diseño de los casos de pruebas, está el diseñar el entorno de prueba, con la carga de los conjuntos de datos y las conexiones con los sistemas adyacentes. Dentro de esta etapa se debe establecer la trazabilidad bidireccional entre requerimientos, casos de pruebas y bases de las pruebas.
Implementación y ejecución de las pruebas
Se debe realizar el cierre de la implementación de los casos de pruebas, los cuales tienen que quedar priorizados, y a partir de ahí, se deben generar los procedimientos de pruebas, sean automatizados o no.
Si fuera necesario, se debe verificar y actualizar la trazabilidad de los casos de pruebas.
A medida que se realiza la ejecución de las pruebas, se deben registrar los resultados obtenidos. Como resultado de la comparación con los resultados esperados, se determinan las fallas.
La salida de la Implementación y ejecución de las pruebas son los registros de pruebas, que pueden ser: Listas de chequeo de sets de pruebas corridos y Registros de defectos.
Dentro de la ejecución también quedan descriptas las pruebas de regresión (asegurar que los cambios no han revelado otros defectos o introducido nuevos defectos)
Evaluación del criterio de salida
Es necesario evaluar la ejecución de pruebas con respecto a objetivos definidos al momento de la planificación (por ejemplo, criterios de salida). Esta fase debe proporcionar información de manera que permita, en función de los resultados arrojados, decidir si llevar a cabo pruebas adicionales o no.
Cierre de las pruebas
Esta es una de las fases más importantes, ya que muchos de los inconvenientes que puede traer la instalación del sistema, viene por no hacerse o no hacerse formalmente el cierre de las pruebas.
Implica:
-Cerrar informes de incidencias, o bien, generar de solicitudes de cambio para cualquier punto que permaneciera abierto
– Comprobar qué entregables planificados han sido entregados y probados
– Documentar la aceptación del sistema, que frecuentemente se da al momento de las pruebas de aceptación.
– De la recopilación de datos de las actividades del proceso de pruebas finalizadas, se debe consolidar la experiencia, alimentando las buenas prácticas para mejorar la madurez del proceso de pruebas, y las lecciones aprendidas para futuros proyectos
– Como en todo proyecto, se deben archivar los productos de soporte de prueba
Control de las pruebas
El estado del proceso de pruebas se determina comparando el progreso logrado con respecto al plan de pruebas. El plan de pruebas puede ser modificado en función de la información adquirida a partir del control de prueba
Dentro del control de pruebas, además de lo anterior, se miden y analizan resultados, se diseñan e inician las medidas correctivas y se preparan y toman decisiones.
4.3. Ciclo de vida de las pruebas
Recordar que se ha explicado, como actual visión de las pruebas, que la prueba debe ser desarrollada de manera paralela al proceso de desarrollo y como una actividad que tiene sus propias fases de análisis, diseño, implementación, ejecución y mantenimiento, que, relacionadas a la gestión de un proyecto de pruebas serán denominadas como: Planificación, Especificación, Desarrollo de la prueba, Ejecución, Evaluación y Seguimiento:
Se puede apreciar que, ni bien se tengan los primeros requerimientos listos (dentro de la fase de Requerimientos), se puede comenzar con las actividades de Planificación de las pruebas, es decir definir un proyecto de pruebas para que pueda ser correctamente medido y controlado, definir los objetivos, las estrategias de pruebas, los entregables y los recursos necesarios.
Lo mismo al momento del Diseño.
Ni bien se encuentren los primeros requerimientos diseñados, se puede comenzar con la Especificación de las pruebas. Esto quiere decir que, se comienzan a diseñar los casos de pruebas que se llevarán adelante durante la fase de ejecución.
Antes de la etapa de Ejecución de las pruebas, que no puede llevarse a cabo hasta que no estén los primeros componentes individuales listos (si se comienza con un nivel de pruebas de componentes), existe una etapa denominada Desarrollo de la prueba.
Esta etapa implica crear los las pruebas automatizadas, en caso de adoptar una estrategia así, y de crear los desarrollos especiales que fueron definidas durante la fase de diseño
Si se está dentro de un proceso de pruebas con herramientas que automatizan la ejecución, esta etapa de Desarrollo, es la etapa donde se generan los robots de pruebas, las baterías de datos, los archivos de inicialización de bases de datos para la ejecución automatizada.
Una vez que se cuenta con el primer componente de desarrollo, pueden comenzarse las pruebas. El primer componente, módulo o sistema que llega a pruebas, da inicio al primer ciclo de Ejecución de pruebas. Luego de ejecutar el primer ciclo de pruebas, de tienen identificados todas las fallas, es decir, qué casos de pruebas no corrieron satisfactoriamente. Una vez identificados las fallas, durante la Evaluación de la prueba, se analizan los resultados de una prueba para determinar si los criterios de prueba se satisfacen o no.
Este proceso de Ejecución y Evaluación se vuelve iterativo y en conjunto con la fase de Desarrollo del sistema, hasta tanto se alcanza el criterio satisfacción planteado.
Cada ciclo puede implicar el correr todos los casos de pruebas planteados. Otro esquema puede ser que el primer ciclo corre todos los casos de pruebas, y en los sucesivos, sólo se corren los casos que fallaron y en la medida que los defectos fueron removidos. Y otro esquema podría ser, que el primer ciclo corre todos los casos de pruebas planteados para una unidad mínima de componente desarrollada, y los sucesivos pueden ir siendo incrementales, agregando funcionalidad a probar.
Como se puede apreciar en la gráfica, la etapa de Seguimiento es una etapa que acompaña a todo el proceso de pruebas. Es el proceso de registrar los incidentes de las pruebas o los problemas del usuario, investigándolos y creando una estructura que permita solucionarlos.
Es la fase en la que se va evaluando la cobertura alcanzada con las pruebas para determinar cuándo se para de probar, como así también es la que atiende a cualquier modificación, o cambio que se pueda presentar en el proyecto
Dentro de las actividades de Mantenimiento está la mejora y/o modificación del sistema una vez que éste se encuentra instalado y funcionando, lo que implica desarrollo, y por ende pruebas. El proceso iterativo de Corrección – Ejecución es el mismo al planteado para la primera vez. Inclusive se pueden volver a dar, dependiendo de la envergadura de la modificación y/o mejora, todas las fases de pruebas, desde la Planificación hasta la Evaluación, con Seguimiento incluido.
4.4.Prueba de los cambios: Retesting y Testing de Regresión
En todo ciclo de vida de desarrollo, además de las etapas de Análisis o Requerimiento, Diseño e Implementación, donde se incluye programación y pruebas, está la etapa de Mantenimiento.
Esta es una etapa del ciclo de vida de desarrollo en la que el sistema se mejora y/o se modifica.
Por otra parte, las organizaciones desarrolladoras de sistemas, buscan con un producto atender a un segmento de mercado y no a un cliente en particular, ello lleva a entregar soluciones a los clientes y no solo productos.
Entonces, una de las razones por la que un software se modifica es la extensión funcional, y la otra fundamental es por la corrección de errores.
Cualquier cambio que se haga sobre el objeto de pruebas, ya sea por corrección, funcionalidad nueva o funcionalidad que se extiende, por más pequeño que parezca, puede tener efectos secundarios y eso genera la necesidad de repetir las pruebas para asegurar su funcionamiento.
Re-testing
Como se dijo antes se corrige un defecto, se debe re-testear. El retesting valida solamente que el defecto se corrigió. Corregir un defecto implica que el objeto de pruebas ha cambiado y en ese cambio pueden haberse introducido nuevos defectos que con el re-testing solamente no serán descubiertos.
El Testing de Regresión es correr un set de pruebas más amplio, para asegurar que no aparecerán nuevos defectos, incluso repitiendo pruebas que ya han sido verificadas previamente.
Entonces, ¿cuándo se debe aplicar testing de regresión?
Se debe aplicar toda vez que hay un cambio en el producto o en el ambiente, ya sea por una corrección de un defecto o por una ampliación de la funcionalidad.
El testing de regresión se aplica para probar que aspectos del producto no han cambiado
En la mayoría de los casos no es viable una prueba de regresión completa por sus altos costes y también por el tiempo que demanda llevarlas a cabo
Entonces, ¿qué casos de pruebas se deberían seleccionar?
– Que cubren funciones críticas de seguridad y del negocio. – Que pertenecen a sectores donde regularmente cambian. – Que cubren funciones con una tasa alta de defectos. – Que representan la funcionalidad estándar sin las variaciones especiales. – Que tienen prioridad alta. – Que prueban la configuración frecuentemente utilizada.
Después de todo lo visto, ¿qué forma adoptan las pruebas de regresión? ¿Constituyen una técnica, un nivel de pruebas, son caja negra o caja blanca o son una estrategia?
Las pruebas de regresión no son un nivel en sí mismas, ya que pueden ser realizadas en todos los niveles de prueba.
En general son de caja negra, pero en realidad pueden adoptar cualquier enfoque que sea necesario para garantizar el funcionamiento del paquete de sistema que se está liberando al cliente
No es una técnica sino que es parte de la estrategia que se adopta para el aseguramiento de calidad cuando se hace mantenimiento de sistemas
Las pruebas típicas después de un cambio
: Repetición de pruebas
Re-testing, pruebas tras la corrección de errores.
Pruebas de regresión:
pruebas para descubrir nuevos defectos introducidos recientemente.
4.5. Tipos de pruebas
El ISTQB (2011) establece cuatro tipos de pruebas:
1) Pruebas funcionales con el objetivo de probar la función del sistema
2) Pruebas no funcionales con el objetivo de probar las carácterísticas del producto, como pueden ser la interfaz de usuario, la performance, el estrés.
3) Pruebas estructurales que tiene el objetivo de probar la estructura/arquitectura software
4) Pruebas de asociadas al cambio, es decir aquellas que prueban el sistema después de los cambios son el re-testing y las pruebas de Regresión.
Pruebas funcionales
La función es el objeto de prueba. Las pruebas se hacen para verificar los requisitos funcionales que fueron establecidos en las especificaciones, casos o escenarios de negocio o cualquier documento que establezca lo que el sistema debe hacer.
El enfoque a utilizar es el de caja negra
Las pruebas funcionales se pueden llevar a cabo en todos los niveles de prueba: componentes, de sistema, de integración y de aceptación.
Para llevar adelante la prueba se utiliza combinaciones de datos de prueba derivados a partir de los casos de prueba.
Pruebas no funcionales
Tienen que ver con las carácterísticas del sistema en cuanto a la manera en que lleva a cabo sus funciones.
Probar el sistema respecto de los tiempos en ejecutar sus funciones está dentro de las pruebas no funcionales.
La ISO 9126 (2001) establece una serie de carácterísticas de calidad no funcionales como la fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad.
Pruebas no funcionales típicas son:
Pruebas de carga:
Implica someter al sistema a fuertes cargas de trabajo como tráfico excesivo o cargas elevadas de transacciones simultáneas, y múltiples usuarios simultáneos
– Pruebas de estrés:
Consiste en encontrar errores debidos a la escasez de recursos como falta de memoria, falta de espacio en disco. Además de encontrar errores debidos a la existencia de recursos compartidos como recursos del sistema.
– Pruebas de volumen:
Es someter al sistema a grandes cantidades de datos para observar si falla al llegar a los límites para los cuales fue concebido.
– Pruebas de performance:
Son las pruebas que permiten medir los tiempos de respuesta y el comportamiento en la concurrencia
– Prueba de estabilidad:
Es la prueba que se hace para medir el rendimiento en un modo de operación continuo.
– Pruebas de interfaz de usuario:
Esta prueba consiste en revisar el estado de los objetos, los modos de ventana, los menús, que los controles tengan un tamaño estándar, además de la redacción y ortografía de mensajes y de todo lo que aparezca en pantalla
-Prueba de robustez:
Es la prueba para medir la reacción a entradas erróneas o datos no especificados, a fallos hardware.
– Pruebas de seguridad y accesibilidad:
Toman relevancia en los desarrollos web
Unidad 5: Testing de desarrollos web
Por las nuevas tecnologías de desarrollo la mayoría de los sistemas utilizan ingeniería web, y son desarrollados con lenguajes que soportan la implementación web.
Diferencias entre aplicación convencional y aplicación web
Una aplicación convencional tiene estas carácterísticas fundamentales que la diferencian de una aplicación web: – Se instala – Necesita bibliotecas especiales – Es estática
Por el contrario, una aplicación web, como tal, tiene las siguientes carácterísticas – Es desplegable en browsers – Presenta un conjunto de objetos que se visualizan y operan en forma independiente – Es dinámica
Y en cuanto a los aspectos específicos, se pueden citar: –
Multiplicidad de perfiles de usuarios. – Diferentes comportamientos de esos perfiles. – Atributos de calidad que responden a necesidades de diferentes audiencias. – Diferentes tipos de habilidades y conocimientos del equipo de proyecto. – Procesos de desarrollo de rápida generación. – Alto nivel de orientación a la funcionalidad del sistema.
la ingeniería web requiere enfoques sistemáticos y disciplinarios. Emplea herramientas y metodologías robustas pero flexibles. La ingeniería web se desarrolla en un ambiente multidisciplinario, e involucra áreas como:
– Ingeniería de Sistemas e Ingeniería de Software – Interfaces usuarias – Multimedia – Modelado – Simulación – Prueba – Gestión de Proyectos – Sociología – Diseño Gráfico
Dimensiones de calidad para pruebas de aplicaciones web
Tal como lo expresa Pressman (2006)
la calidad que se incorpora en una aplicación web depende del diseño. En ambos casos se deben examinar ciertas dimensiones de calidad inherentes al desarrollo web. Entre las que se pueden destacar, están:
– Navegabilidad
Vínculos rotos, inadecuados o erróneos.
– Interoperabilidad:
que realiza interfaces adecuadas con otras aplicaciones o bases de datos.
– Seguridad:
valorar el nivel de vulnerabilidad. –
Facilidad de uso:
para cada perfil de usuario involucrado.
– Contenido
Tanto en semántica (consistencia, ambigüedades, exactitud de la información presentada) como en sintáctica (ortografía, puntuación, gramática).
– Estructura:
que entrega adecuadamente contenido y función, y que puede ser extensible.
Proceso de desarrollo web
Presenta algunas diferencias generales, entre las cuales están:
– Requerimientos livianos:
no hay una especificación de requerimientos detallada sino que está restringida a la reducida tecnología de un browser
. – El desarrollo es simple y rápido.
– Por ello es que los proyectos se caracterizan por ser cortos
. – Las pruebas son poco minuciosas, dinámicas, altamente orientadas al contenido y a la visualización
Elementos diferenciadores del desarrollo web
Hay un cuadro…Esta en el celuar
calidad—proceso–equipo de proyercto—– usuario
El desafío de las pruebas
Pasando puntualmente a las pruebas, se presentan una serie de dificultades a la hora de detectar un error durante las pruebas de aplicaciones web
– Es muy difícil independizar un error del entorno.
Una prueba con una conexión por módem de 56K, resulta muy diferente, o de resultados diferentes a una prueba con conexión dedicada. Como una aplicación web es implementada en varias configuraciones y ambientes distintos, puede ser muy difícil y hasta imposible reproducir un error.
¿Cómo saber si un error determinado es un error de programación o de configuración?
El rastreo de un error puede ser difícil a través de las tres capas de arquitectura: cliente, servidor, red.
El ambiente desempeña un papel importante en el diagnóstico de los errores que se descubran durante las pruebas.
Clasificación de los sitios web
– Estáticos:
es el tipo más simple de sitio, donde la única opción de la página es hacer clic.
Estáticos con formularios:
son usados para recopilar información de usuarios, orientados a recolección de datos.
– Con acceso dinámico de datos:
front-end de datos, almacenados en un repositorio externo. Los resultados son archivos HTML.
– Dinámicamente generado:
la interfaz gráfica y cada una de las páginas retornadas por el servidor son generadas dinámicamente.
Aplicaciones web:
conjunto de funcionalidades y componentes que usan ambientes web