archivo

Archivos diarios: mayo 19, 2011

James Marcus Bach es un experto en testing, autor de numeros artículos y libros sobre la materia. Es uno de los creadores de la corriente de testing de software denominada “Context-Driven school of software testing” y defiende la aplicación de técnicas de testing exploratorio.

Me parece muy interesante la reflexión que realiza sobre la importancia de las personas en los proyectos de desarrollo de software (traducción libre): “Todo lo realmente interesante que ocurre en los proyectos de desarrollo de software con el tiempo se reduce a las personas”.

Para mi las personas son lo más importante en los proyectos de desarrollo de software. Son muchas las causas que pueden provocar el fracaso de un proyecto pero hay una que inevitablemente te lleva a esa situación y es una incorrecta gestión y/o interrelación entre las personas que participan en el desarrollo: área usuaria, equipo de proyecto y responsables técnicos del cliente.

Se desarrolla para personas, por lo que la idea de que lo tecnológico es lo importante solo tiene sentido en el caso de que sea de utilidad para todas las partes que intervienen. Muchas veces olvidamos que nuestra misión está en proporcionar soluciones y que la tecnología es el medio y no el fin.

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.