archivo

Archivo de la etiqueta: caso de prueba

Nos centramos en demasiadas ocasiones, por ejemplo en los artículos que escribo al respecto peco mucho de ello, en el testing de carácter funcional, sin embargo en muchos sistemas resulta igualmente relevante el testing sobre aspectos nos funcionales.

Hay que tener en cuenta que los usuarios no solo verán satisfechas sus expectativas si el sistema responde a nivel funcional sino si también responde a la mayor parte de las especificaciones no funcionales (habrá algunas que de primera mano pasarán inadvertidas para los usuarios pero por ejemplo si hay un requisito no funcional que indica que el sistema debe tener un comportamiento adecuado con veinte usuarios accediendo de forma concurrente y después no lo tiene, esa expectativa que inicialmente parecía haberse satisfecho, pasa a convertirse en algo totalmente distinto).

Generalmente los casos de prueba están orientados a aspectos funcionales, dejando de un lado los requisitos no funcionales (seguridad, rendimiento, usabilidad, etc…) por lo que es muy posible que este tipo de defectos se presenten en entornos de producción provocando unos efectos que pueden dar lugar a verdaderas situaciones de crisis.

La rigurosidad del testing debe depender del nivel de criticidad del sistema que se va a poner en producción, ya sea en primera instancia o como consecuencia de una evolución del mismo. Esta rigurosidad se tendrá que ver reflejada en todas las etapas de desarrollo del software y tiene como objetivo evitar que lleguen a producción errores que sean críticos para el sistema y que puedan provocar un coste en vidas humanas o unas pérdidas económicas que puedan poner en jaque la subsistencia de una organización.

Esta rigurosidad estará relacionada con el número de casos de prueba a los que se somete el software, desde la misma definición de las pruebas unitarias a las pruebas de carácter funcional, así como a la propia verificación de la bondad de la técnica utilizada.

Hoy en día existen implantaciones software en sistemas empotrados, sistemas de información, etc… que manejan todo tipo de cosas. Como cada vez está más extendida la automatización, cada vez son mayores los sectores donde el software maneja funciones críticas. Incluso funciones que se pueden considerar no críticas, como por ejemplo la web de una organización, cada vez tiene un mayor grado de criticidad tanto en cuanto la forma en que muchos clientes acceden a la misma es través de Internet.

Por tanto, cada día que pasa es más importante que un producto llegue a producción tras superar un umbral de calidad específico definido para el mismo que permita tener confianza en una reducción importante de la probabilidad de que se produzcan errores críticos.

Hacer un buen testing no es sencillo, así como seleccionar el conjunto finito de casos que se va a estudiar (incrementar la cardinalidad de ese conjunto depende de factores económicos y el presupuesto debería estar ajustado a la criticidad del producto), ya que de el mismo depende que posibles errores importantes se puedan colar en producción.

Sobre esto es conveniente recordar una cita muy conocida de Edsger Wybe Dijkstra en la que comenta que: “El testing de los programas puede ser muy efectivo para mostrar la presencia de errores, sin embargo resulta inadecuado para mostrar su ausencia”.

Exploratory Testing es una estrategia o técnica para la realización de tareas de testing de software en las que el proceso de pruebas comprende el aprendizaje continuo del sistema (incluyendo el aprendizaje desde cero en el caso de que no se tengan conocimientos previos), el diseño de las pruebas y la ejecución de las mismas.

Se entiende en muchos casos como que el equipo de testing se enfrenta al sistema y empieza a realizar pruebas con el mismo (lo que en el argot se entiende como “bichear el sistema”), por lo que el aprendizaje, diseño de pruebas y su ejecución es algo que sucede de manera simultánea (o casi).

Sin embargo esto es llevar al extremo, desde mi punto de vista, la definición de testing exploratorio, lo cual le restaría efectividad y aplicabilidad. Yo entiendo el testing exploratorio como el hecho de que el equipo que realiza las pruebas tiene que construirse sus propias herramientas (sus casos de prueba) y sus propios manuales de instrucciones (el conocimiento funcional del sistema) a partir de especificaciones del sistema de información que no existen o no están recogidas en entregas documentales formales.

No obstante, es importante señalar que la descripción más formal de testing exploratorio entiende el mismo como la realización simultánea del aprendizaje, diseño de las pruebas y realización de las mismas.

No se considera una metodología, ya que no se especifica un procedimiento a seguir, sino una forma de entender las tareas de testing, por ese motivo, la forma en que se realiza este tipo de pruebas puede variar en función del equipo u organización que la aplique (o incluso dependiendo del proyecto con el que se esté trabajando)

La única expectativa, como producto formal, que se debe (puede) esperar de la aplicación de esta técnica es la obtención de un listado de errores.

Las principales ventajas de esta técnica son las siguientes:

– No se necesitan productos formales previos (determinadas entregas documentales y/o la definición/descripción de componentes que automaticen determinadas pruebas) para la realización del proceso de testing, lo que cual supone un disminución del esfuerzo realizado por el equipo de proyecto (que se dirige hacia el equipo de testing los cuales son especialistas en la realización de este tipo de tareas y van a realizar un aprovechamiento más óptimo de los recursos que se invierten en ellos).

Es importante hacer hincapié en que no se trata de que al equipo de testing se les presente el sistema (o un producto previo del proceso de desarrollo, ya que no necesariamente tendría que estar enfocado al testing del producto software) y que a partir de ahí ellos se enfrenten al problema. A veces puede ser así, pero lo normal sería ahorrar tiempo de aprendizaje, sobre todo en aspectos funcionales y esto se puede conseguir utilizando documentación del proyecto (la que haya, formal o no formal) y mediante conversaciones con el equipo de proyecto.

– Se considera que los errores más importantes del sistema de información se van a encontrar tan rápidamente que en con técnicas de testing basadas en planes de pruebas entregados por el equipo de proyecto (con o sin la ayuda del equipo de testing). Por lo menos, si no es tan rápido en un caso como en otro, sí que se considerará más rentable en relación esfuerzo/errores graves detectados.

– Producen una mayor motivación en el equipo que realiza las pruebas, ya que no se limitan a ejecutar paso a paso casos de prueba redactados por otros y verificar que el resultado coincide con el indicado y además permite obtener un conocimiento funcional del sistema que resulta fundamental independientemente de quien redacte los planes de prueba. El tester en este caso no es un autómata que recibe casos de prueba y devuelve un listado de incidencias, sino que tiene vocación de aprender más del sistema, enriqueciendo las tareas de testing con el conocimiento que va adquiriendo del sistema.

Los principales inconvenientes son los siguientes:

– El conocimiento funcional de determinados sistemas puede ser muy complejo, lo cual podría provocar que en las primeras pruebas realizadas por el equipo de testing, determinados aspectos funcionales de importancia que no han sido bien desarrollados no se detecten.

– Si no se documentan de alguna manera las pruebas que se están realizando puede provocar que en el futuro sea complicado volver a repetirlas. Recordemos que no se trata de una metodología, sino de una forma de enfocar el proceso de testing, por lo que el hecho de que se documente o no lo que se hace es algo discrepcional del equipo que está realizando las pruebas, del proyecto concreto o de las propia metodología que quiera imponer una organización para la realización de este tipo de pruebas.

El testing exploratorio es una técnica de testing adaptativo ya que con mayor o menor efectividad se puede aplicar en la mayoría de los proyectos y además, será la única opción posible (aunque se pueda combinar con otras técnicas) en proyectos donde los requisitos o especificaciones del sistema no se hayan recogido de manera formal o no se disponga de dicha información.

También resulta válida en sistemas de información, que por su criticidad, no requieren de un proceso formal para la realización de las pruebas, pudiéndose aplicar testing exploratorio a la globalidad del mismo o bien a partes concretas, dejando en este caso algunos aspectos funcionales que se puedan considerar más importantes para verificarse mediante casos de prueba específicos diseñado para ellos.

Sobre esto último hay que entender que no podemos considerar a todos los sistemas de información iguales, una aproximación a esto lo tenemos en la clasificación de los sistemas de información de Cockburn en la que se indica que para aplicar una metodología a un proyecto hay que analizar su criticidad y su envergadura (que se obtiene indirectamente a partir del tamaño del equipo de proyecto). Como todos los sistemas no son iguales, tampoco lo deberían ser las revisiones que se realizan sobre los mismos.

No tiene sentido desde un punto de vista práctico y económico, aplicar revisiones estrictas sobre productos que no son críticos, por ese motivo la aplicación de esta técnica (o en combinación con técnicas más formales) es entendida como un enfoque ágil para la realización de las pruebas en un doble sentido, tanto en su capacidad de adaptación ante las circunstancias reales de un sistema como en el hecho de que no se requiere invertir un esfuerzo tan importante.

Esta técnica también se aplica cuando se quiere complementar las tareas realizadas por un equipo de testing con las realizadas por otro independient. El primer testing puede tener un carácter más estricto, dejando el segundo para descubrir posibles errores no especificados en casos de prueba.

Para más información, se analiza esta técnica en el blog Testing Baires.