top of page

Los beneficios más importantes de las Pruebas tempranas (Early Testing)

Actualizado: 26 jun 2021

Todo proyecto tiene por lo menos 3 vertientes de importancia: el tiempo, el dinero o presupuesto y la calidad del mismo. La implementación eficaz del principio de pruebas tempranas nos puede arrojar beneficios sobre todas estas áreas.



En el Post pasado estuvimos hablando de la importancia de la implementación del principio de "pruebas tempranas" o "Early testing" en los proyectos de software, en este post vamos a expandir sobre sus beneficios directos en 3 vertientes.


Beneficios en la Calidad

La calidad del producto es uno de los aspectos más importantes en un proyecto de software, por tanto es reconfortante saber que la implementación del principio de las pruebas tempranas impacta positivamente este pilar. A continuación veremos algunas formas de como seremos capaces de lograr esto:

  1. El equipo de pruebas tendrá la oportunidad de aportar valor en la validación de los requerimientos desde su concepción, permitiendo que se diminuyan la cantidad de futuros defectos.

  2. Los planes de prueba podrán ser desarrollados de manera que presenten un mayor nivel de cobertura. Lo anterior se desencadena como consecuencia del analisis oportuno sobre los requerimientos y la oportunidad de interactuar con los usuarios finales de manera temprana, trayendo como consecuencia que los criterios de prueba sean elaborados de forma más madura ya que los ingenieros de prueba tendrán mas tiempo para entender y evaluar lo que se espera del software desde las diferentes perspectivas del proyecto.

  3. Los ingenieros de calidad podran utilizar este tiempo de antelacion y preparacion para eliminar o disminuir considerablemente cualquier brecha de conocimiento en relacion a nuevos sistemas, interfaces o informaciones pertinentes a las pruebas del proyecto antes de que dicho proyecto sea llevado al proceso de pruebas formales.


Beneficios en el Presupuesto


El presupuesto de un proyecto es un factor crítico que por lo regular, es algo alienigena para la parte técnica de tecnología. Lamentablemente, el equipo de calidad de software no es la excepción a este inconveniente ya que no siempre tienen claro como agregar valor desde esta perspectiva más allá de realizar un buen proceso de selección de alguna herramienta de trabajo que genere un "ahorro" de presupuesto a grandes rasgos en el tiempo.


La buena noticia es que la implementacion de las pruebas tempranas crea una ventana de oportunidad para que el equipo colabore con el presupuesto del proyecto. Esta oportunidad viene dada por la realidad estadistica que establece que


El costo de la detección y resolución de un defecto está atado de manera exponencial a la etapa del ciclo de vida del desarrollo de software en donde sea efectuada dicha detección y posterior resolución.
Gráfico que explica la tendencia de como el resolver un defecto se vuelve mas caro basado en que tan tarde se encuentra en el proyecto
Costo relativo de resolución de defectos basado en su tiempo de detección

Existe una diferencia exponencial de por lo menos 5x en relación al costo de un defecto detectado en la etapa de requerimientos vs un defecto detectado en la etapa de "testing formal". Por otro lado, hay un impacto de por lo menos 15x sobre el presupuesto si dicho defecto es detectado en ambiente de producción.


En otras palabras, mientras más temprano se detecta un defecto en el Ciclo de vida del desarrollo de software, más barato es su corrección para el proyecto.


Beneficios en el tiempo


Uno de los males comunes en los proyectos de software es ver que en muchas ocasiones la etapa de "testing" se convierte en un "Cuello de botella" por distintos factores, de los cuales algunos estan en control del equipo de pruebas y otros no.


En una implementación ideal del "early testing" , los tiempos de prueba se optimizan por el hecho de que el equipo de prueba comienza a trabajar con bastante antelación sobre los requerimientos que están validando.


Cuando la etapa de "Testing" inicia, ya existe un plan de prueba maduro, conocimiento de las plataformas a probar, y hasta "edge cases" contemplados, por tanto, la mayor parte del tiempo será solo ejecución de pruebas, dando esto como resultado que al final, el "tiempo de prueba" sea mejor distribuido a lo largo del SDLC y se minimicen las brechas que permitan que el equipo de prueba se atrase.

Entradas Recientes

Ver todo
bottom of page