archivo

Archivo de la etiqueta: defectos

Es lo que tienen los defectos, cuando menos oportunos son, antes aparecen. De ahí que me parezca muy acertada la siguiente cita de Michael Stahl: “Los bugs irreproducibles se vuelven altamente reproducibles justo después de la entrega al cliente”.

Siempre es posible invertir más esfuerzo en la detección de defectos pero es necesario calibrar (todas las partes) qué impacto tiene la ocurrencia de determinados defectos en el software y la disponibilidad económica para hacer ese trabajo.

Es preferible siempre menos pero con más calidad y más garantías, sin embargo, muchos no lo ven así, prefiere llegar a lo que tenían pensado que debería ser el producto sin ponerse a analizar que completo no es lo mismo que correcto.

Cuanto más crítico sea el sistema más exhaustivo se tiene que ser con la localización de defectos y más se debe invertir en su detección lo más próxima posible a su origen (tanto de manera automática como manual), eso es muy importante y se debe tener en cuenta a la hora de hacer estimaciones ya sea como parte de cada historia de usuario o como parte de personas ajenas al equipo que desarrolla el sprint.

Resulta complicado que no lleguen defectos a producción. Llegado a un punto, la inversión a realizar para tratar de que el número de defectos que lleguen a producción sea cero, crecerá exponencialmente, si bien, no se trata solo de echar dinero, sino de hacer las cosas bien, y mucho mejor si se hacen desde un principio y están integradas como una parte más del proceso de desarrollo.

Cuanto mayor sea la complejidad del sistema, cuanta más deuda técnica exista, más posibilidades hay de surjan defectos y de que estos resulten, en ocasiones, complicados de detectar, porque en muchos casos serán consecuencia de una combinación de actuaciones del usuario que no ha sido contempladas o testeadas previamente.

¿Cuántas veces se ha tenido un cuidado extremo en tratar de que no se cuelen defectos y después, cuando el producto ha entrado en producción, han empezado a aparecer errores?

Por ese motivo, considero importante que los responsables funcionales y determinados usuarios empiecen a testear el producto (independientemente de la estrategia de testing utilizada por el equipo de desarrollo) desde la misma etapa de construcción, desde el mismo sprint, conforme se van completando historias de usuario. De esta forma, no solo se consigue perfilar mejor determinados aspectos de las historias, sino que también se permiten detectar defectos que probablemente hubieran llegado a producción.

Sobre lo comentado en este artículo, me parece muy interesante la siguiente cita de Brian Kernighan: “Cada nuevo usuario en un nuevo sistema descubre una nueva clase de bug”.

“Entre el 40% y el 50% de los programas de usuario contienen defectos no triviales”.

Se trata de errores que tienen un impacto entre moderado y sensible para los usuarios de un determinado sistema o lo que es lo mismo, se trata de defectos en secciones del programa más o menos críticas pero que suponen un bloqueo en el trabajo del usuario o que producen resultados erróneos que son complicados de detectar por los mismos a simple vista, por ejemplo, aquellos que son el resultado de cálculos matemáticos complejos o del cruce de datos de diversas fuentes.

Puestos en una balanza, en muchos casos, estos segundos tipos de errores son más peligrosos y relevantes que los primeros porque se corre el riesgo de entregar resultados o hacer interpretaciones sobre la información que son erróneos al tomarse como base cifras, valores o datos que se consideran ciertos, solo por el hecho de que se confía en que el sistema los ha calculado bien.

No basta solo con revisar fórmulas o métodos de cálculo, también es necesario conocer el negocio para detectar cálculos que no resultan lógicos, ¿cuántas veces le has dado numerosas vueltas a un algoritmo y no has visto errores y un usuario experto nada más ver el resultado del cálculo ha sospechado que había algo mal?, pero también, ¿cuántas veces el usuario tampoco ha detectado la existencia del problema? ya que lo mismo el juego de datos utilizado produce un resultado correcto pero con otro el resultado puede ser incorrecto.

Por ese motivo los sistemas críticos deben tener un testing acorde a sus necesidades, requieren un tratamiento especial y eso se debe tener en cuenta desde el punto de vista presupuestario porque se entiende que en sistemas de estas características hay mucho en juego y se debe ser especialmente riguroso ante el riesgo de que lleguen a producción defectos importantes que como dicen Boehm y Basili no resultan en la mitad de los casos triviales de detectar.

También resulta fundamental que los desarrolladores entiendan que la detección de defectos es un trabajo que empieza desde antes de escribir la primera línea de código. Si estamos tratando de describir con más detalle una historia de usuario y no contrastamos de manera adecuada con los responsables funcionales si hemos entendido bien lo que quieren y esperan, estaremos introduciendo de partida defectos que tendrán su reflejo en el código.

Por tanto, la detección de defectos debe empezar desde etapas muy tempranas y de manera ininterrumpida debe continuar durante todo el proceso de desarrollo y es un proceso en el que interviene el equipo de desarrollo, los propios usuarios, otros departamentos (como por ejemplo sistemas) y en el que pueden participar especialistas integrados o no en el equipo de desarrollo (si no forman parte directamente del equipo, al menos sí que deberían tener un cierto contacto para que puedan entender determinadas decisiones que se toman en el proyecto, entiendan el fundamento del producto que se está haciendo y puedan conocer las expectativas del usuario).

Los defectos pueden abarcar áreas funcionales y no funcionales por lo que el ámbito de actuación para detectarlos es bastante amplio. Pese a eso, no debemos olvidarnos de otro factor muy importante en la calidad del software como es la deuda técnica para servirnos de indicador sobre el grado de mantenibilidad (y su coste asociado) que tiene el producto software.

Los defectos son una variable importante para medir la calidad del software, ¿puede ser la más significativa? Si respondemos que sí, podemos pensar que con la detección de defectos ya hemos solucionado cualquier problema pero más importante que dar esa respuesta es entender primero qué es un defecto y qué estrategias se adoptan generalmente para detectarlos.

El concepto de defecto tradicionalmente se asocia a la desviación respecto a especificaciones o requisitos funcionales y a bugs. Es muy frecuente encontrarnos con equipos de personas especialistas en testing que reciben un plan de pruebas y lo ejecutan junto a una serie de prueba que ya tienen catalogadas para realizar de forma genérica en las aplicaciones (a modo de un testing exploratorio un tanto dirigido).

En el momento que la detección de defectos se deja en manos de un plan de pruebas es donde este sistema empieza a hacer aguas. El problema no es el plan de pruebas en sí, sino la actitud que sobre el mismo tienen los desarrolladores (suele ser una molestia, un documento que tienen que hacer porque un tercero se los ha pedido) y también los testers (en una orientación del trabajo hacia el cumplimiento de un proceso, ellos reciben una entrada, la procesan y devuelven un resultado, cuanto más rígida sea su visión de ese trabajo menos práctico será el plan de pruebas).

Por tanto, y de entrada, tenemos un problema de actitud y de enfoque que requiere ser trabajado. Si los desarrolladores no entienden la importancia de colaborar con terceros para la detección de defectos (tal vez penséis que no es necesario que exista un equipo de testing independiente, y os puedo dar la razón en que a veces no haría falta, pero hay que entender que si desarrollamos para terceros, el cliente pueda querer que un equipo que dependa directamente de él le evalúe el trabajo que se entrega) o el equipo de testing no entiende que debe colaborar con los desarrolladores para entender el contexto del proyecto, las características del producto y consultar dudas, de poco vale seguir avanzando en otros aspectos.

Nadie es infalible. La competencia tampoco. Si hasta el mejor jugador del mundo de fútbol es capaz de fallar un gol que puede meter hasta un alevín, ¿por qué no pueden fallar tus competidores?.

A la competencia hay que tenerle respeto y nunca se debe subestimar.

A la competencia nunca hay que temerle porque tras la marca hay personas y cualquier persona puede cometer errores.

A la competencia hay que conocerla, saber cuáles son sus virtudes y sobre todo cuáles son sus defectos. Utilizando otro símil futbolístico, ¿no es mejor conocer que el lateral izquierdo del equipo contrario es un coladero que desconocer ese detalle?. Si no sabes explotar los defectos de la competencia tienes un gran problema porque lo más probable es que ellos sí que sepan explotar los tuyos.

Haz un breve ejercicio respondiéndote a estas preguntas ya que en sus contestaciones te darás cuenta si estás aprovechando o no todos los recursos posibles para intentar hacer frente a tu competencia, ¿cuáles son tus principales competidores en cada segmento de mercado?, ¿cuáles son los principales defectos de cada uno?, ¿los has utilizado alguna vez a tu favor?, ¿crees que coinciden contigo el resto de personas en tu organización que participan en actividades comerciales?, ¿existe una estrategia común en este sentido?.