archivo

Archivo de la etiqueta: defecto

Me ha parecido muy interesante la siguiente reflexión de Michael Bolton: “Los tests que se han diseñado para confirmar una teoría predominante tienden a no revelar información nueva”, y es precisamente por eso, porque se centran en confirmar una hipótesis, sin entrar a estudiar otros aspectos que podrían resultar relevantes.

De hecho, muchos desarrolladores creen que han realizado un testing suficiente y después a las primeras de cambio otra persona, generalmente con más conocimiento funcional, que hace uso de las funcionalidades detecta defectos en poco tiempo, ¿por qué? Su conocimiento del negocio y de las expectativas del usuario es parcial y muchas veces ese testing se centra en aspectos de bajo nivel cuando la solución hace aguas a un nivel más alto.

Esto se extiende al plan de pruebas, entregable muy típico en contextos en los que un equipo independiente realiza un QC (control de la calidad), ¿realmente se confía en que pasando el plan de pruebas el sistema está libre de defectos?, y no solo por el hecho de que muchos de ellos son complicados de detectar, sino porque el plan de pruebas se centra en una visión concreta, en una teoría predominante por parte de la persona o personas que han colaborado en su elaboración. Sí, tal vez confirmemos que la teoría se cumple, pero si dejamos el testing en ese punto, muy probablemente estemos dejando escapar defectos que pueden tener un impacto importante cuando lleguen a producción.

Es por ese motivo que el testing debe ser considerado desde diferentes puntos de vista, en el que se combinen testing automático y manual, en el que intervengan diferentes personas, diferentes perfiles, en el que lo “reglado” se combine con lo exploratorio y en el que se tenga muy claro, qué nivel de defectos puede permitirse el producto y cuánto se está dispuesto a invertir para conseguirlo.

Partamos de una base cierta, cuanto más próximo se corrija un defecto desde el punto en que se originó menor será su impacto y menos costosa será su corrección.

Ante eso, podríamos tomar la decisión de que todo defecto se corrija en el momento en que se detecte y hacerla extensiva a todo el conjunto de desarrolladores.

De hecho esa práctica es acertada, si bien, habrá veces donde tocará decidir.

Supongamos que se detectan una serie de defectos en el proceso de paso a producción de un producto y que las vueltas a atrás son costosas, en tiempo y en esfuerzo, ¿decidimos siempre dar marcha a atrás?, pues depende, tocará evaluar el impacto del defecto y el coste que tiene volver a hacer una nueva entrega (que nadie garantiza que sea limpia y que no lleve consigo nuevos defectos), de esta forma, habrá veces que convenga seguir hacia adelante (lo cual no significa ignorar los defectos detectados) y otras en donde la versión no alcance el mínimo necesario para llegar a producción.

La decisión de si el defecto se debe corregir o no debe quedar en manos del responsable de definir la línea de desarrollo del producto que no es otro que el Product Owner, el cual debe asesorarse por personal técnico con el objeto de obtener información suficiente para tomar la decisión que mejor convenga al producto.

Se hace testing para detectar defectos, por tanto, tendrán éxito cuando cumplen su propósito. Esta es la visión de Boris Beizer en la siguiente reflexión: “Un test que revela un bug ha sido exitoso, no al revés”.

Podemos centrar el testing en secciones del código o en funcionalidades donde existe menos probabilidad de que existan defectos y probablemente no estemos aprovechando de manera adecuada el esfuerzo o, al menos, no con la rentabilidad que supondría enfocarlo de manera adecuada.

Una versión de lo anterior es hacer un testing “cómodo” para cubrir el expediente, sin entrar en tareas de mayor profundidad.

La función del testing es encontrar errores, dado que los desarrolladores no somos infalibles, si no se detectan defectos deberíamos plantearnos si efectivamente el testing que estamos haciendo está siendo efectivo, sobre todo si después comprobamos cómo van llegando a producción en una proporción muy superior a la que debería ser y/o a la inversión realizada.

La primera de las situaciones que Barry Boehm y Victor Basili citan en su artículo “Software Defect Reduction Top 10 List” en la revista IEEE Computer en enero de 2001, está muy en consonancia con el objetivo Lean de cero defectos y con una realidad que los que nos dedicamos a esta profesión conocemos y que sin embargo sigue siendo demasiado habitual: “Encontrar y arreglar un problema del software después de la entrega es a menuda 100 veces más caro que encontrarlo y arreglarlo durante las fases de toma de requisitos o diseño”.

Encontrar un defecto en producción implica el tiempo necesario en corregirlo, la realización de una nueva entrega y el coste que tiene sobre el proceso productivo hasta que se corrige. No todos los defectos son iguales y, por tanto, su impacto puede ser desde prácticamente nulo hasta dejar sin funcionamiento una parte de la aplicación o provocar daños intangibles como una mala imagen ante los clientes.

Con lo que tenemos que quedarnos es que efectivamente se tiene que ser más riguroso en el proceso de desarrollo de manera que los programadores se habitúen a probar mejor el software que están desarrollando, siendo extensible esto a las personas que tengan una visión más global del producto conforme se van integrando los componentes.

Y esto no solo debe tenerse en cuenta en la construcción ya que se tiene que tratar que las especificaciones sean de la mayor calidad e intención posible, de manera que se consiga reducir el número de iteraciones necesarias para tener depurada una determinada funcionalidad.