archivo

Archivo de la etiqueta: Brian Marick

Me parece muy interesante la siguiente cita de Brian Marick: “Trabajar solo es trabajar sin red”. La cita la realizó reflexionando sobre el “pair testing” si bien es aplicable, en mi opinión, a todos los campos del desarrollo de software.

Respeto a quienes quieren trabajar solos, es su decisión y tiene sus ventajas y sus inconvenientes. Todo empieza y termina en ti y detrás tuya no hay nada ni nadie, es como dice Brian Marick, un salto sin red.

Sin embargo en el contexto de un equipo de proyecto hay que pensar en términos de equipo y no en términos individuales. Tienes tus tareas pero no eres ajeno a la dinámica de un equipo, formas parte de un engranaje y la maquinaria no funciona si cada componente lo hace a su aire.

La reflexión de Marick es extrapolable a los resultados de una determinada versión del producto, si lo revisa otro equipo o se revisa de nuevo el trabajo estaremos dando una oportunidad a detectar deficiencias y a reducir la incertidumbre sobe el resultado final.

La siguiente reflexión de Brian Marick no deja indiferente: “Los documentos del proyecto son una ficción interesante: útiles, pero nunca suficientes”.

Este es un tema controvertido en el que como es lógico existirán opiniones para todos los gustos y probablemente casi todas tengan su parte de razón.

Siempre hay detalles que no recoge la documentación (el proyecto es algo vivo y está sujeto a cambios y a nuevos matices) y hacer que recoja todos los detalles puede requerir un esfuerzo importante tanto para el documento en sí como en futuras actualizaciones del mismo (tal vez y ya es mucho decir, se consiga cerrar una documentación completa y de calidad de una versión del producto, mantener esto resultará complicado y de la misma manera que el software, la documentación “se deteriorará” con el tiempo).

Soy de la opinión (estoy convencido) de que el programador no debe inventar nada cuando está desarrollando pero eso es una cosa y otra que los detalles que no aparecen en la documentación deban aparecer reflejados finalmente en la misma ya sea de manera formal o informal (habrá situaciones donde resulte interesante (o rentable) y en otras no).

El testing exploratorio se centra en el producto y, por tanto, va más allá de la documentación del proyecto y el uso que se hace de la misma es el de un instrumento para comprender mejor la aplicación y para obtener información que pueda ser de utilidad para el testing. Consultas al equipo de desarrollo, al área usuaria y la revisión de la propia aplicación e incluso del código proporcionarán un mayor nivel de conocimiento.

No rechazo la documentación, no quiero que se entienda así, rechazo el exceso de formalidad y el exceso de documentación. Es un instrumento, no lo olvidemos, cuando se convierte en un fin, creyendo que a través de ese fin se consiguen los objetivos, tenemos un problema.

Brian Marick realiza una reflexión que me parece bastante acertada sobre cuál debería ser el objetivo principal de un equipo de testing (traducción libre): “Somos un servicio cuyo objetivo es reducir toda aquella incertidumbre que resulte negativa o perjudicial sobre el estado percibido del producto”.

Me gusta la reflexión porque no hace referencia a un proceso sino a una finalidad orientada a la calidad del producto final.

Un testing bien realizado permite reducir la diferencia entre la versión del producto y las expectativas del usuario además de reducir el número de errores que llegan a producción (eliminando críticos).

Si se hace bien ese trabajo la confianza sobre cada versión del software se mantiene o crece y eso resulta muy positivo para todos, en especial para los usuarios del sistema que no interpretarán cada iteración del producto como una fuente de problemas que tarda en estabilizarse.

Lo que para los usuarios es confianza para la organización y para el proveedor de servicios de desarrollo de software es dinero, el primero porque no ve afectada la disponibilidad del sistema y en consecuencia la producción y/o productividad en el uso de la herramienta para los segundos porque versiones no limpias de un producto requieren ser corregidas y provoca un esfuerzo adicional que generalmente tienen que asumir.

Hay testing que requiere conocimiento del negocio, en muchos casos si la materia es complicada el conocimiento que se requiere es bastante profundo y no es algo que se pueda conseguir en dos ratos.

Este testing se podría realizar aplicando técnicas de testing exploratorio pero se requeriría un apoyo importante por parte del equipo de proyecto salvo que se disponga del tiempo suficiente para que el tester pueda aprender con el soporte adecuado lo necesario del negocio para realizar las pruebas.

Siempre está la posibilidad de que los casos de prueba vengan desde el equipo de proyecto (con el soporte si se requiere del equipo de testing) en cuyo caso bastará con seguirlos (esta mayor simplicidad al final es fruto de un mayor esfuerzo por parte de otras personas, por lo que al final el esfuerzo lo que hace es distribuirse, si bien no todas las combinaciones son igual de efectivas), combinándose con las exploraciones que se estimen oportunas sobre la aplicación.

Cuanto más complejo sea el sistema desde el punto de vista del negocio más proximidad se requerirá por parte del equipo de testing (o por personas claves de dicho equipo), más interesante resulta el soporte por parte del equipo de proyecto (nunca está de más tener ayuda si es necesario) y más interesante resulta la realización de pruebas por parte del área usuaria (no solo en el momento de la aceptación, sino lo antes posible).

El testing no solo es encontrar bugs sino también localizar discrepancias con respecto a las expectativas de los usuarios.

La opinión de Brian Marick al respecto es la siguiente: “Para encontrar los bugs que los clientes ven – que son importantes para los clientes – necesitas escribir tests que verifiquen las áreas funcionales imitando tareas típicas de los usuarios. Este tipo de testing se denomina testing de escenarios, testing basado en tareas o testing de casos de uso”.

Brian Marick, hizo la siguiente reflexión orientándola al testing de software, sin embargo la idea es perfectamente válida para cualquier área del desarrollo de software y en general para cualquier tipo de tarea: “un buen modelo guía tu pensamiento, uno malo lo deforma”.

De ahí la importancia de pensar en cómo intentar alcanzar la solución a un problema en lugar de ir directamente a atacarlo. Analizar la situación, establecer un plan a seguir no es garantía de nada, hay que acertar, o por lo menos que la opción elegida en caso de ser errónea no presente una desviación tal que no sea posible enderezar el camino.

Lo que es evidente es que si un modelo, una metodología, una estrategia no produce buenos resultados en tus proyectos o para un determinado tipo de los mismos, lo mejor es buscar otras posibilidades. De no ser así, se adquirirá más destreza en las técnicas aplicadas, tal vez se consiga sacar más proyectos adelante con unos resultados aceptables, pero todo ello a base de mucho esfuerzo, desgaste y con la sensación de que muchos de los trabajos pueden irse al traste en cualquier momento.

Anclarse a ideas fijas es ir en contra de lo que es el propio proceso de desarrollo de software, tanto por la naturaleza adaptativa del desarrollo como nuestra propia evolución tanto personal como profesional.

Brian Marick es un experto en testing y en el lenguaje de programación Ruby. Fue uno de los firmantes del manifiesto ágil.

Toda la problemática del desarrollo de software viene originada por su naturaleza adaptativa que es el resultado de la infinidad de contingencias que se pueden producir a lo largo del proceso de desarrollo. Si lo que sucede a lo largo del proyecto fuera más previsible probablemente existirían menos problemas.

Sobre este tema Brian Marick realizó la siguiente reflexión:

“La verdadera complejidad de nuestro trabajo es que todo esta planificado bajo condiciones de incertidumbre e ignorancia. El código no es lo único que cambia: las calendarios se deslizan, se añaden nuevos objetivos, los requisitos cambian desde que se definen y durante el desarrollo, es cuando todos los participantes llegan a comprenden mejor el producto que se está implementando.”

Como en la traducción hay cambios sensibles respecto a la cita original (he realizado los cambios para que la idea quede más clara), os la pongo a continuación:

“The real complexity in our jobs is that all planning is done under conditions of uncertainty and ignorance. The code isn’t the only thing that changes. Schedules slip. New milestones are added for new features. Features are cut from the release. During development, everyone – marketers, developers and testers – comes to understand better what the product is really for.”

Existen diferentes corrientes que recomiendan una estrategia u otra para realizar las labores de testing en un proyecto de desarrollo de software.

En este artículo voy a analizar una de ellas, la escuela de testing de software orientada al contexto (Context-Driven school of software testing), que fue creada el 21 de noviembre de 1999, cuando Brian Marick, James Bach y Cem Kaner estaban discutiendo sobre la posibilidad de escribir conjuntamente un libro sobre testing de software. Estos autores llevaban, de manera individual, escribiendo libros y artículos sobre la materia, en la que se mostraban críticos con la forma en que se trabajaba de manera habitual en las tareas de testing de software.

A partir de ese momento se inició un debate a través de listas de correo que originó dos años después la publicación del primer libro sobre este concepto “Lessons Learned in Software Testing: A Context-Driven Approach” escrito por James Bach, Cem Kaner y Brett Pettichord y a la publicación del manifiesto del testing orientado al contexto.

La idea fundamental de esta corriente es que el testing de software debe adaptarse a la naturaleza del proyecto, a su contexto y no basarse en la simple aplicación de buenas prácticas. Todos los proyectos no son iguales, incluso en proyectos similares pueden producirse circunstancias en su proceso de desarrollo que den lugar a situaciones (contextos) distintos.

El objetivo por tanto es poder realizar el testing de un proyecto independientemente de las circunstancias del mismo y de su naturaleza y esto se consigue adaptándose a él, a su realidad, en lugar de intentar aplicar una serie de estrategias o conceptos generales que lo mismo no funcionan para este caso concreto o no son de aplicación (por ejemplo, si una determinada estrategia o procedimiento de pruebas implica disponer de una serie de entradas por parte del equipo de desarrollo y dichas entradas no existen, será necesario adaptarse a esta circunstancia en lugar de esperar a que se den las circunstancias para poder actuar, porque lo más probable es que no se den).

Tiene muchos aspectos en común con los principios expuestos en el manifiesto ágil para el desarrollo de software, de hecho los seguidores de esta corriente de testing de software, estarían de acuerdo con todos ellos.

El testing orientado al contexto tambień se basa en una serie de principios, concretamente siete:

– El valor de cualquier estrategia o práctica (de testing) depende de su contexto.

– Hay buenas prácticas en un contexto, pero no hay mejores prácticas.

– La gente, trabajando junta, es la parte más importante del contexto de un proyecto.

– Los proyectos se desarrollan con el tiempo (son adaptativos) por lo que a menudo no son predecibles.

– El producto es una solución, si el problema no se resuelve, el producto no funciona.

– Un buen trabajo de testing de software es consecuencia de un complejo proceso intelectual (por encima de seguir o no un determinado procedimiento).

– Solo a través del juicio y de la habilidad, cooperando a lo largo de todo el proyecto, permitirá realizar las tareas adecuadas en el momento adecuado para realizar el test de nuestros productos de manera efectiva.

Otros principios de este movimiento complementarios a los anteriores son lo siguientes:

– No es tarea de los testers solicitar documentación. Los buenos testers trabajan con la información que tienen, pueden utilizar documentos no oficiales y son muy específicos cuando solicitan información adicional.

– El testing es un servicio que proporciona información y no un servicio de aseguramiento de la calidad.

– El valor de las tareas de testing viene determinado por el hecho de que proporcionen información útil y a tiempo sobre la calidad del software.

– No hay garantías. No nos escondemos detrás de un plan de pruebas. Nosotros aprendemos como mejorar las pruebas cuando realizamos las mismas.

– Un tester es un defensor del cliente, para ello tienen que intenta ponerse en su posición.