Conceptos basicos

Proceso del software

conjunto de actividades y resultados asociados que conducen a la creación de un producto software.

[Sommerville, 2002]

Aproximación lógica a la adquisición , el suministro, el desarrollo, la explotación y el mantenimiento del software (norma IEEE 1074) [IEEE, 1999]

Ciclo de vida del software

ELEMENTOS DEL CICLO DE VIDA

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas panificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).

PROCESOS

Ciclo de vida lineal

Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).

Ciclo de vida con prototipado

A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.

Ciclo de vida en espiral

El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.

ETAPA 2

MODELO EN V

En los niveles lógicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un resultado verificable.

En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación.

El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.

El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.

El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.

El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.

PRUEBAS DE SOFTWARE

La prueba de software es un conjunto de herramientas, Técnicas y métodos que hacen a la excelencia del desempeño de un programa, así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener. Las técnicas para encontrar problemas en un programa son extensamente variadas y van desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas que ayudan a aliviar el peso y el costo de tiempo de esta actividad. Pero de nada serviría conocer todas las técnicas de prueba de software, si un programa carece de documentación, el código es confuso, o no se han seguido pasos para la planificación y desarrollo del software, ya que sería como buscar una aguja en un pajar. Es por eso que en este trabajo monográfico nos hemos volcado a definir no solo las herramientas, técnicas y métodos de prueba sino que también a todo el trabajo previo de control de calidad en el desarrollo de software, ya que sabemos que mucho mejor que encontrar y solucionar un problema es prevenir que no ocurra.

EJEMPLO CAJA NEGRA

Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba.

Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y muy variados.

EJEMPLO

Pruebas de Unidades

Estas pruebas son un proceso para evaluar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa, con el objetivo de probar primero los bloques desarrollados más pequeños del sistema final, que probarlo en su totalidad.

Al aplicar estas pruebas se obtuvo como resultado la comunicación del sistema con el servidor, que proporciona la conexión a la base de datos y el servidor local, todo esta conexión con el fin de procesar información en cada uno de los módulos que componen el sistema propuesto, en este caso no se evidenció ninguna ruptura de comunicación entre sus módulos, por lo cual esta prueba fue superada por el sistema.

Pruebas de Integración

El objetivo de estas pruebas es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, para cubrir la funcionalidad establecida y que se ajusten a los requisitos no funcionales especificados en las verificaciones correspondientes.

Las pruebas de integración se evalúan a través de la prueba de caja negra, donde se centran lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación, con la aplicación de esta técnica se obtiene un conjunto de pruebas que: reduce el número de casos de pruebas y dicen algo sobre la presencia o ausencia de errores.

Caja Negra Falla Correcciones

Pruebas de entradas de datos Ingresaba cualquier tipo de carácter. Validar los campos.

Pruebas de consulta (Listado, actualización y eliminación de registros)

Problemas con la conexión de la base de datos. Configurar la clave del servidor appserver para establecer conexión a la base de datos.

Prueba de ingreso de cuenta del sistema No se presentaron. ______________________

Pruebas de salidas de información No se presentaron. ______________________

Cuadro Nº 28: Resultados de la Caja Negra

Pruebas de Aceptación

Las pruebas de aceptación tienen como función validar en que sistema cumpla con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento, estas pruebas las realiza el cliente. Con respeto a las pruebas funcionales, se hacen sobre el sistema completo, y buscan una cobertura de la especificación de requisitos, no se realizan durante el desarrollo, pues sería impresentable para el cliente; son presentadas una vez pasada todas las pruebas de integración por parte del desarrollador.

Se emplean técnicas denominadas "pruebas alfa" y "pruebas beta". Las pruebas alfa consisten en invitar al cliente a que maneje al entorno de desarrollo a probar el sistema, se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resultados. Las pruebas beta vienen después de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que está fuera de control, aquí el cliente se queda a solo con el producto y trata de encontrarle fallos (reales o imaginarios) de los que informa al desarrollador.

Ejemplo de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.

-Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.

-Ejecuten todos los bucles en sus límites operacionales. -Ejerciten las estructuras internas de datos para asegurar su

validez.

Pruebas de flujo de control:

En estas pruebas se quiere encontrar errores en la parte lógica del programa. Utilizando las condiciones simples (operador-relación) o con condiciones complejas (N x [operador-relación]). Por ejemplo este encuentra errores con los paréntesis, con variables y hasta de operaciones aritméticas.

Pruebas de bifurcación (branch testing)

Como lo dice su titulo, es ligado a una bifurcación o para bucles. Con ella podemos definir si algún bucle esta correctamente implementado y si las lineas de código donde exista una condición es la mejor opción o si debería ser cambiada.

Pruebas de caminos básicos:

Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute mínimo una vez. Acá se usan herramientas como grafos, diagramas de flujo, la complejidad ciclomática, entre otros.La partición de equivalencia es un método de prueba de Caja Negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. La partición equivalente se dirige a una definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. En otras palabras, este método intenta dividir el dominio de entrada de un programa en un número finito de clases de equivalencia. 

De tal modo que se pueda asumir razonablemente que una prueba realizada con un valor representativo de cada clase es equivalente a una prueba realzada con cualquier otro valor de dicha clase. Esto quiere decir que si el caso de prueba correspondiente a una clase de equivalencia detecta un error, el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo error. Y viceversa, si un caso de prueba no ha detectado ningún error, es de esperar que ninguno de los casos de prueba correspondientes a la misma clase de equivalencia encuentre ningún error. El diseño de casos de prueba según esta técnica consta de dos pasos:

1. Identificar las clases de equivalencia.2. Identificar los casos de prueba.

EJEMPLO PRUEBAS DE INTEGRACIÓN

La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.

Prueba de regresión La prueba de regresión consiste en volver a ejecutar un subconjunto de

pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. La prueba de regresión es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales.

El conjunto de pruebas de regresión contiene tres clases diferentes de casos de prueba:

Una muestra representativa de pruebas que ejercite todas las funciones del software;

Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio;

o Pruebas que se centran en los componentes del software que han cambiado.

Prueba de humo

Esta prueba es utilizada cuando se ha desarrollado un producto software “empaquetado”. Es diseñado como un mecanismo para proyectos críticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base sólida. La prueba de humo comprende las siguientes actividades:

1. Los componentes software que han sido traducidos al código se integran en una “construcción”. Una construcción incluye fichas de datos, librerías, módulos reutilizables y componentes de ingeniería que se requieren para implementar una o más funciones del producto.

2. Se diseña una serie de pruebas para descubrir errores que impiden a la construcción realizar su función adecuadamente. El objetivo será descubrir errores “bloqueantes” que tengan la mayor probabilidad de impedir al proyecto de software el cumplimiento de su planificación.

3. Es habitual en la prueba de humo que la construcción se integre con otras construcciones y que se aplica una prueba de humo al producto completo. La integración puede hacerse bien de forma descendente o ascendente.

PRUEBA DE VALIDACIÓN

La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. La validación del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos.

Se llevan a cabo dos pruebas

PRUEBA ALFA

Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado.

PRUEBA BETA

Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no está presente en esta prueba. La prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentran durante la prueba e informa al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la clase de clientes

PRUEBA DEL SISTEMA

Su propósito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

EJEMPLO PRUEBAS DEL SISTEMA

son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Testeo de código fuente

El testeo unitario es un proceso que se ejecuta paralelo al desarollo del código fuente del producto. Se programan casos de testeo que llaman a una parte especifica del código fuente del producto. Así se comprueba el correcto funcionamiento de ese código, y el conjunto de todos los casos de testeo unitario comprueban a su vez el correcto funcionamiento del producto total o parcialmente, dependiendo de la cobertura de los casos de testeo unitario.

Testeo de funcionalidad.

¿Hemos desarrollado lo que el cliente nos ha pedido? ¿El producto funciona bien junto con los otros componentes del sistema? En el testeo de Aceptación, Funcionalidad e Integración, definimos casos y escenarios de testeo para comprobar el correcto funcionamiento de todo el producto o parte del mismo. El estudio del diseño de funcionalidad del producto es el punto de arranque para estos casos y escenarios de testeo, pero también se definen durante el proceso de dessarollo.

Testeo del rendimiento

El entorno de desarollo normalmente solo nos permite ejecutar el producto de un modo limitado, por ejemplo con solo un usuario o con casos de cálculo simples. Pero también se quiere medir el funcionamiento del producto en entornos reales: con cálculos complejos, con más usuarios o llamadas paralelas al sistema. En el testeo de rendimiento se testea el correcto funcionamiento del producto utilizando herramientes que generan llamadas paralelas o simulan grandes grupos de usuarios. También se hacen hipótesis de la escalabilidad del producto.

EJEMPLO PRUEBAS DE CONTENIDO

Las actividades de esta etapa consisten en hacer revisiones precisas de la forma en que se despliegan las páginas del sitio y ver si cumplen con los Términos de Referencia en estos temas y, además, si cumplen con los estándares mínimos definidos y la normativa vigente.

Verificación de Contenidos

es una prueba básica para revisar si el Sitio Web desarrollado incluye todos los contenidos que se han especificado en los Términos de Referencia o los que se hayan definido en el marco del plan de desarrollo. Se puede hacer en forma manual o automática, de acuerdo a las siguientes orientaciones:

Sistema Manual

se refiere a hacer una revisión manual de los contenidos del Sitio Web a través de la navegación de sus páginas. Para ello se recomienda primero construir un índice de contenidos y luego verificar la existencia de cada uno de los ítemes que contiene, a través de hacer un recorrido exhaustivo del sitio. Los elementos que deben probarse obligatoriamente son:

Verificación de ortografía y redacción Verificación de enlaces principales Verificación de imágenes en páginas Verificación de existencia de archivos adjuntos Verificación de Lista de Chequeo de Accesibilidad

Sistema Automático

especialmente orientado a la verificación y detección de enlaces rotos, lo cual se puede hacer utilizando sistemas basados en Internet o, bien, software especializado.

Sistemas Basados en Internet:

se recomienda usar el servicio de validación de enlaces del W3C Check Link

Software

se recomienda bajar y usar desde su computador el software gratuito para verificación de enlaces: Xenu. De igual manera, los actuales software de creación de sitios Web permiten manejar en forma controlada los enlaces internos; un error común de este tipo es que una foto se vea normalmente en el computador de desarrollo, pero no en el Sitio Web, Esto ocurre porque es referida en forma absoluta desde una ubicación en un disco duro local o en red, en lugar de un directorio de imágenes del Sitio Web.

Nota: se recomienda hacer estas pruebas en ambientes controlados diferentes a los usados para el desarrollo (diferentes redes y computadores), para que los resultados sean confiables.

Pruebas de Funcionalidades y Operación

Las actividades de esta etapa se refieren a hacer chequeos completos respecto de las funcionalidades y aplicaciones que ofrece el sitio, ya sean de aplicaciones simples como formularios hasta más complejas, como consultas y modificaciones de registros en base de datos.

Validación de Formularios

Campos Obligatorios: se debe validar que en los formularios sean ingresados todos

aquellos campos que sean necesarios; éstos deben ser marcados de alguna manera (usualmente con un asterisco) que permita a los usuarios entender la obligatoriedad de ingresar información en ellos; adicionalmente, debe indicarse tal condición en forma explícita.

Validaciones Locales: para reducir la carga de validaciones en el servidor, se

recomienda incorporar la mayor cantidad de éstas en el computador del cliente, utilizando en formaestándar el lenguaje Javascript para hacerlas.

Sintaxis de Ingreso: se debe validar que, en algunos casos, los campos sean

ingresados con datos válidos; el mejor ejemplo es el caso del ingreso del número de RUT o Cédula de Identidad, cuyos números tienen un algoritmo conocido para ser validado.

Suscripción a Servicios: se debe validar que cada vez que se realice la suscripción a un

servicio que ofrezca el Sitio Web, se envíe un e-mail al usuario (para lo cual se debe necesariamente solicitar su dirección de correo electrónico) en el que se le informe sobre el resultado de lo realizado. Quien pruebe el sistema debe validar que el sistema esté enviando correctamente los e-mails y que dicho e-mail llegó a la dirección correspondiente; en este caso se recomienda probar con una dirección de recepción externa a la institución desde la cual se prueba.

Sistemas de Búsqueda:

si se cuenta con ellos, se debe validar que efectivamente permitan encontrar documentos existentes en el sitio; en este sentido se deben ingresar documentos específicos y luego buscarlos de manera de asegurarse que la funcionalidad está operando adecuadamente. Si el sistema de búsqueda tiene una versión de búsqueda avanzada, se debe asegurar de que las opciones ofrecidas encuentren los documentos de la manera en que se ofrezca. El formulario para hacer la búsqueda debe ser intuitivo, evitándose el lenguaje técnico y específico que impida entender su funcionamiento entre usuarios con menores conocimientos de los temas abordados en la institución.

Sistemas de Feedback:

si se cuenta con sistemas de envío de preguntas o reclamos (al estilo de los indicados para la Oficina de Informaciones, Reclamos y Sugerencias, OIRS), se debe asegurar de que se está completando el ciclo de vida de la consulta. En este sentido se debe validar que el sitio realiza la consulta y que ésta es recibida por el funcionario encargado de atenderla. De otra manera, la funcionalidad podría operar computacionalmente pero no en términos de tramitación.

Sistemas de Compra

si se cuenta con sistemas de pago en línea, se debe revisar cuidadosamente el flujo de trabajo de la aplicación y asegurarse de que en cada uno de los pasos se está asegurando la calidad y seguridad de la transacción.

EJEMPLOS PRUEBA DE USABILIDAD

Las pruebas de usabilidad son un servicio de aseguramiento de calidad que consiste en invitar a profesionales, cuyo perfil se adapta al de su público objetivo, a probar su producto y proporcionar comentarios valiosos sobre su facilidad de uso y eficiencia.

Chequeos de Usabilidad

se trata de comprobaciones de la usabilidad del Sitio Web impulsadas desde la primera versión de la Guía Web de Gobierno. Gracias a este trabajo inicial, fue posible establecer una lista de más de veinte aspectos que podían ser chequeados manualmente por los encargados de los Sitios Web de Gobierno, gracias a los cuales era posible determinar el grado de usabilidad presente en sus Sitios Web.

Pautas para tests de Usuario en Sitios de Gobierno:

es un documento que permite desarrollar un test de usuario; contempla las preguntas más relevantes que se deben realizar y el procedimiento para llevarlo a cabo exitosamente.

Pautas para Tests Heurísticos

es un documento que muestra los temas principales que se deben abordar en un test de este tipo, mostrando los aspectos centrales y la forma de evaluar para generar el informe final correspondiente.

Checklist de Usabilidad

documento que apoya la comprobación de usabilidad de un Sitio Web, a través de preguntas directas acerca de las características de su interfaz.