Desarrollo de software. Context-Driven school of software testing
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.
Jummp 
Pingback: James Bach, los proyectos de desarrollo de software y las personas « Jummp