¿Qué es probar software?

¿Qué hacen los ingenieros de pruebas? ¿demostrar que el software funciona correctamente? ¿buscar fallos? ¿mejorar la calidad del software? Los expertos ofrecen diferentes definiciones para las pruebas del software pero hay algo en lo que todos parecen estar de acuerdo: probar software no consiste en demostrar que éste funciona correctamente. Esta visión se resume perfectamente en el viejo dicho atribuido a Dijkstra:

Program testing can be used to show the presence of bugs, but never to show their absence!

No sé si este enunciado está probado matemática o lógicamente pero a mí me resulta intuitivamente correcto por un motivo de peso: las grandes empresas e instituciones multinacionales invierten millones y millones de dólares en reparar fallos de sistemas software. Algunos de esos fallos se publican periódicamente en el excelente blog “Risk Factor“ en el que por ejemplo, recientemente, se publicó un fallo en GMail por el cual dejó de tener acceso temporalmente a mensajes de 40.000 cuentas de correo. En mi opinión, si grandes corporaciones como Google no pueden lograr que sus sistemas no tengan fallos, es porque hoy en día resulta técnicamente imposible construir software que no tenga fallos.

Glenford J. Myers argumenta en su clásico libro “The Art of Software Testing“, en esta misma línea, que no sólo es imposible demostrar que un programa funciona correctamente, sino que resulta inconveniente plantearse como objetivo que el software funcione perfectamente. Para él, resulta mucho más adecuado incluso desde un punto de vista psicológico que los ingenieros de pruebas se planteen un objetivo factible, esto es, descubrir fallos en los programas:

Testing is the process of executing a program with the intent of finding errors

Efectivamente, probar software para encontrar fallos resulta destructivo a corto plazo pero, conforme vayamos ejecutando diferentes pruebas en el software, descubriendo y eliminando fallos, a largo plazo conseguiremos tener software mejor, software en el que podemos confiar porque sobre él hemos ejecutado muchas pruebas y hemos conseguido que pase todas (o muchas) de ellas. ¿Qué confianza nos da un producto software que nunca hemos probado? Obviamente, ninguna. ¿Cómo podemos tener confianza en que un programa funciona razonablemente bien? Sólo lo lograremos si lo hemos probado mucho, en muy diferentes situaciones, y el software se comporta adecuadamente en todas esas situaciones.

Pero ¿es necesario ejecutar un programa para descubrir fallos? Si un ingeniero de pruebas descubre un problema en un programa sin haberlo ejecutado ¿no puede reportarlo? Quizá sea mejor ampliar esa definición y revisar la que utiliza habitualmente Cem Kaner, y que por ejemplo puede encontrarse en las diapositivas de su charla sobre “Software Testing as a Social Science“:

Software testing is an empirical and technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.

Para Kaner, las pruebas no se reducen a ejecutar el software, sino que el ingeniero investiga el software empíricamente y desde un punto de vista técnico. Típicamente, por ejemplo, el ingeniero revisará la especificación al comenzar a diseñar pruebas de sistema. Si encuentra incongruencias en la especificación deberá tratar de determinar si se trata de un fallo, lo que puede requerir revisar actas de reuniones o ponerse en contacto con los analistas: el ingeniero de pruebas debe investigar para tener toda la información relevante respecto al software.

En cuanto al objetivo de las pruebas, en la definición de Kaner no se reduce exclusivamente a detectar fallos sino que se amplia a ofrecer información, datos, relacionados con la calidad de lo que se está probando. Dicha información tendrá unos destinatarios que, típicamente, pueden ser los encargados de desarrollar el software, los que deciden si el software se pone en producción o cualquier otra parte interesada. Lo que no hacen, o no deben hacer, los ingenieros de pruebas es tomar decisiones respecto al software. Deben estar especializados en extraer información del software y en comunicarla eficientemente a quienes deben tomar las decisiones oportunas. En un escenario típico recibirán un programa, diseñarán y ejecutarán un conjunto de pruebas y reportarán un conjunto de fallos. No es su labor decidir si los desarrolladores deben dedicar tiempo a eliminar esos fallos por lo que no puede decirse, estrictamente, que la calidad de un producto software esté asociada indisolublemente con la calidad de los procesos de pruebas. No se puede obtener un producto software de calidad sin haber ejecutado unas buenas pruebas, pero es preciso que la información que obtienen los ingenieros de pruebas sea utilizada adecuadamente por los destinatarios de dicha información en su toma de decisiones.

El árbol de los requisitos

Cuando analizo los requisitos de un sistema software, siempre pienso en ellos como si fueran un árbol. La raíz del árbol es el sistema software y de la raíz salen dos ramas: requisitos funcionales y requisitos no funcionales. En la rama funcional voy agrupando los requisitos en subsistemas, que suelen ser el siguiente nivel del árbol. A continuación las primeras funcionalidades, muy abstractas, formuladas en términos de objetivos del usuario. Luego se van detallando las funcionalidades y empezamos a refinar los requisitos de usuario hasta tener clara toda la especificación funcional, todo lo que debe hacer el sistema.

En la rama no funcional suelo categorizar los requisitos: rendimiento, frecuencia de tratamiento, seguridad, usabilidad, integración… Cada categoría es útil para detallar diferentes aspectos de la especificación del sistema, por ejemplo la frecuencia con que se ejecutan las funcionalidades influirá en la cantidad de información que se manejará y, por tanto, en el diseño de datos.

Para especificar el árbol de requisitos, uso un catálogo de requisitos para los niveles más altos del árbol. A nivel funcional, intento incluir en el catálogo las funcionalidades y los aspectos más importantes de cada función desde el punto de vista del usuario y del dominio. Especifico los requisitos detallados utilizando modelos: modelo funcional con casos de uso, modelo de dominio, modelo de los procesos de negocio o diagramas de transición de estados, entre otros. Los modelos son la representación de las ramas finales del árbol y las hojas.

Foto de un árbol araguaney en flor (publicada en Fotopedia, licencia CC).

Caso Práctico “Casas rurales”. Especificación funcional (v1)

Uno de los ejercicios que hago con mis alumnos consiste en elaborar una primera aproximación a la especificación funcional de un sistema utilizando diagramas de casos de uso. Para ello, a partir de un enunciado, se les pide que identifiquen las funcionalidades que debería tener el sistema que se describe, o sea, los casos de uso. También deben identificar los actores que participan en los casos de uso. El resultado de esa tarea para el caso práctico “Casas rurales” podría ser perfectamente el diagrama que se adjunta aquí.

En una especificación funcional completa, cada caso de uso tendrá asociada una descripción muy detallada de sus flujos normales y alternativos. A mis alumnos, en una primera versión de la especificación, lo que les pido es que describan brevemente los aspectos más relevantes de cada caso de uso.

• “Buscar y consultar casas rurales”:
  • El sistema debe facilitar que los clientes busquen casas rurales que se ajusten a sus necesidades.
  • Fundamentalmente se debe poder hacer búsquedas en cuanto a las fechas en que los clientes desean realizar la estancia y el número de personas que puede alojar cada casa rural, aunque también se utilizarán otros criterios.
  • En cuanto a la información que se debe mostrar sobre las casas rurales:
    • Se debe indicar claramente el número de personas que se pueden alojar en la casa.
    • Debe facilitarse que los clientes vean las fotos.
    • Se deben hacer visibles las ofertas de las casas rurales, indicando el precio normal y el precio de oferta.
    • Se deben hacer públicas las valoraciones y comentarios de otros usuarios.
• “Reservar casas rurales”:
  • El cliente debe poder realizar reservas de casas rurales.
  • En una reserva se podrán incluir varias casas.
  • El sistema debe indicar al cliente un código único que identifica a la reserva.
  • El pago de la señal asociada a la reserva se hará por tarjeta de crédito (contactando con una pasarela de pago) o bien por transferencia.
  • En caso de seleccionar el pago por transferencia:
    • El sistema debe informar al cliente de que debe realizar la transferencia indicando en el concepto el código único asociado a la reserva.
    • La reserva debe quedar pendiente de que el administrador confirme que se ha realizado la transferencia (ver caso de uso “anotar pagos por transferencia”).
• “Anotar pagos por transferencia”:
  • El sistema mostrará la lista de reservas realizadas recientemente y pendientes de pago por transferencia.
  • El administrador anotará para qué reservas se ha recibido la transferencia de la señal.
  • El sistema indicará para qué reservas ha transcurrido ya el número de días indicado por el parámetro PLAZO_PAGO_TRANS, para que el administrador pueda proceder a cancelar dichas reservas por no haberse recibido el pago de la señal.
  • Procesos manuales asociados al caso de uso:
    • Para determinar que una transferencia se ha hecho para una determinada señal, normalmente el administrador comprobará que el concepto de la transferencia coincide con el número de una reserva pendiente de pago.
    • En caso de que haya errores en el concepto de la transferencia y si se puede determinar la identidad del cliente a partir de la información en la transferencia, el administrador se pondrá en contacto con el cliente para verificar el pago.
• “Invitar a hacer valoración”:
  • Al transcurrir el plazo PLAZO_VAL después del último día de estancia en una casa rural, el sistema enviará un mensaje de correo al cliente que reservó dicha estancia, invitándole a valorar la casa rural.
  • En el mensaje de correo se incluirá un enlace directo para que el usuario pueda introducir su valoración.
• “Valorar casa rural”:
  • El cliente introducirá sus valoraciones numéricas y comentarios respecto a la casa rural en la que ha estado.
  • El dueño de la casa recibirá un mensaje de correo con una copia de las valoraciones y comentarios realizados por el cliente.
• “Supervisar valoraciones”:
  • El sistema mostrará una lista de las últimas valoraciones realizadas por clientes y que aún no hayan sido supervisadas.
  • El administrador revisará las valoraciones y las aprobará (por lo que a partir de ese momento serán visibles en el sitio web) o las censurará.
• “Incluir casa en catálogo”:
  • El administrador incluye los datos de una nueva casa en el catálogo del sitio web.
• “Gestionar descripciones de casas”
  • El dueño puede cambiar todos los datos relacionados con las descripciones de sus casas.
• “Configurar precios y temporadas”
  • El dueño puede configurar qué precios se cobran por sus casas y en qué temporadas son aplicables dichos precios.
• “Configurar ofertas”
  • El dueño puede configurar ofertas para sus casas.
  • Una oferta puede realizarse en diferentes periodos del año, independientemente de las temporadas y precios que se hayan definido para cada casa.
  • Las ofertas podrán definirse como un porcentaje o en valor absoluto sobre el precio.
• “Consultar reservas y valoraciones”
  • El sistema ofrece un listado de las reservas y las valoraciones que han recibido las casas de un determinado dueño.

Al realizar el análisis funcional, también suelo pedir que se vayan identificando parámetros del sistema. Dichos parámetros serían susceptibles de ser modificados por los administradores. Por ejemplo, en este caso práctico, podemos identificar estos parámetros:

• PLAZO_PAGO_TRANS: Plazo máximo que se da a un cliente para que realice la transferencia de la señal de una reserva (por defecto serán 4 días).
• PLAZO_VAL: Plazo que transcurrirá desde que termina una estancia en una casa rural hasta que el sistema envía al cliente la invitación para hacer una valoración de la casa (por defecto serán 2 días).

Estaré encantado de recibir vuestros comentarios 

Caso Práctico “Casas rurales”. Enunciado.

En mis clases suelo utilizar enunciados que describen casos prácticos de desarrollo de software, pidiendo a los alumnos que apliquen diferentes técnicas para elaborar una especificación. En esta entrada tenéis uno de esos enunciados. Concretamente, este caso práctico está diseñado para realizar una especificación funcional utilizando casos de uso y un modelo de dominio.

Una empresa de turismo rural desea implantar un sitio web en el que se facilite la consulta y reserva de las casas rurales que ofrece. Ahora mismo, la empresa gestiona 26 casas rurales en la zona de Asturias, aunque prevé que dicha cifra pueda aumentar y expandir su actividad a toda España.

El sitio web debe facilitar la consulta de las características de las casas rurales, con un buscador que tenga en cuenta el periodo en que los posibles clientes quieren alquilar la casa. En cuanto a las características de las casas, debe gestionarse la información sobre, por ejemplo, el número de personas que se pueden alojar en la casa y el número de habitaciones y baños. Debe indicarse claramente la situación de la casa y cómo llegar, así como facilitar la consulta de varias fotos de cada casa. Es muy importante indicar los precios de alquiler de las casas, con precios por días y/ó semanas y teniendo en cuenta que se definirán varias temporadas al año: típicamente sería una temporada alta con precios más elevados (verano, semana santa y puentes) y una temporada baja con precios más económicos (el resto del año), aunque el número de temporadas y su duración concreta debe ser configurable para cada casa. También se podrán definir periodos en que se realicen ofertas (p.ej. una casa rural desea ofrecer estancias durante el mes de marzo con un 10% de descuento).

Cuando una persona desea reservar una casa, deberá indicar sus datos personales y proceder al pago de una señal mediante tarjeta de crédito (conectándose a una pasarela de pago) o mediante transferencia. La señal es típicamente el 20% del precio total de la reserva, aunque dicho porcentaje puede variar de una casa a otra. El pago de la señal debe hacerse efectivo en un plazo de cuatro días desde la realización de la reserva, y siempre con una antelación de 24 horas respecto a la fecha en que comienza la estancia. El resto del pago se hará en el propio alojamiento, utilizando los medios de que disponga cada una de las casas rurales.

Para grupos grandes, el sistema debe facilitar que se realicen reservas de varias casas (típicamente cercanas) en el mismo periodo de tiempo. El proceso en este caso es igual al descrito anteriormente.

Asimismo la empresa desea que el sitio web dé la posibilidad a sus clientes de valorar las casas rurales después de la estancia. Para ello se desea que se envíe un e-mail invitando al cliente a visitar el sitio web para realizar dicha valoración. Esta valoración se realizará, a priori, indicando un número de estrellas entre 1 y 5 para diferentes aspectos de las casas como, por ejemplo, limpieza, confort, situación o trato personal, así como una valoración global. Asimismo, los clientes también podrán incluir comentarios positivos o negativos sobre las casas en sus valoraciones. Todas las valoraciones se harán públicas en el sitio web tras haber sido supervisadas por el administrador del sitio, con el objetivo de censurar los comentarios inadecuados (con insultos o excesos verbales). Además, también se enviará copia de las valoraciones, por email, a los dueños de las casas rurales. Éstos también podrán consultar a través del sitio web tanto los datos de las reservas como las valoraciones de sus casas.

Entradas del blog relacionadas con este enunciado:

• Caso práctico “Casas Rurales”. Especificación funcional (v1).

Hello world!

Bienvenidos a este blog. Me llamo José García Fanjul y soy ingeniero en informática y profesor de la Universidad de Oviedo. Pertenezco al Grupo de Investigación en Ingeniería del Software (GIIS) de dicha universidad. Podéis encontrarme en Twitter como @jgfanjul.

El objetivo de este blog es aprender sobre Ingeniería del Software. Aunque me interesan sobre todo los procesos de pruebas de software, también podemos hablar sobre análisis, diseño y construcción, metodologías, herramientas, buenas prácticas… en definitiva sobre cualquier tema relacionado con los procesos de desarrollo de software.

Podéis observar que no me he roto la cabeza buscando un nombre para el blog, creo que “Ingeniería y Software” es suficientemente descriptivo y directo. Como llevo años utilizando la abreviatura “isof” para referirme a la ingeniería del software, seguramente también la use en el blog con frecuencia. En cuanto a la primera entrada del blog, no podía tener otro nombre que “Hello world!”, que además es el nombre que le da por defecto WordPress  :-)

Espero aprender mucho con este blog y también espero colaborar a que vosotros lo hagáis, así que ¡Bienvenidos!