Completo no es lo mismo que correcto

La cita que hace referencia el artículo, y que me trajo a la mente montones de situaciones vividas en algunos proyectos en los que he participado años atrás, fue la siguiente:

«Los bugs irreproducibles se vuelven altamente reproducibles justo después de la entrega al cliente».

e increiblemente, el porcentaje de ocurrencia es grande! La primera pregunta que se me ocurre hacer es: ¿Porqué no fueron detectados en las etapas previas a la entrega al usuario final? ¿Puede filtrase por le UAT?

Un párrafo siguiente del artículo refiere a:

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.

Acá me cabe preguntarme: ¿El impacto lo podría estimar / calcular sobre la base del mapping de casos de uso y casos de prueba, y determinando qué casos de prueba responden a un criterio de salida determinado?

Una reflexión aquí me surge: «…completo no es lo mismo que correcto»

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.

y es cierto, a veces «menos con mayor calidad» es mejor que «mucho con menor calidad». El tema aquí es ser lo suficientemente inteligente para saber y reconocer qué condiciones son las más representativas para someterlas a diversas pruebas.

Por último, una síntesis referido al párrafo aquí sería: «a mayor criticidad, mayor exhaustivo debe ser el testing»

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.

url: http://wp.me/ppBOQ-44n

 

Gus Terrera

Apasionado por el agile testing y la ia.

Deja una respuesta