¿Porque realizar Testing?


Este tema surgió de una pregunta realizada en el foro QALatinoamérica donde se solicita información estadística sobre la justificación de la implementación de las pruebas de software en el proceso de desarrollo de software.

Desde mi punto de vista la justificación del proceso de pruebas se basa en dos partes:

Justificación social y propagandística

Existen altas exigencias por parte de los clientes para poder implementar en producción el software que adquieren. Hoy en día el software acapara gran parte de las actividades diarias de las personas y pueden llegar a manejar desde grandes sumas de dinero hasta vidas de personas. Desde que nos levantamos hasta que nos acostamos estamos en continua relación con aplicaciones software ya sea mientras miramos televisión, compramos en el supermercado, hablamos por teléfono, etc…

Los desarrolladores son humanos y los humanos (como parte de nuestra esencia) cometemos errores, esto hace que los responsables de vender lo que ellos codifican inviertan lo suficiente para poder mitigar y reducir los riesgos del software que estan vendiendo para que el mismo este en condiciones de salir a producción con la menor cantidad posible de fallas.
Al mismo tiempo, las empresas pierden credibilidad, confianza y clientes al producir software con fallas, por lo que los lleva a implementar procesos de pruebas cada vez más rigurosos para reducirlos al máximo.
Este punto es complicado demostrarlo estadísticamente en forma genérica (ya que cada empresa tendrá su propia historia estadística en cuanto a fallas antes y después de incorporar el testing en su proceso de desarrollo de software), pero por experiencia, puedo decir que hoy en día los desarrolladores que trabajan dentro de una empresa con un proceso de desarrollo que incorpora las tareas de testing con un equipo independiente ronda entre el 20% y el 30% de fallas al momento de llegar a testing, por lo que si ese software (que llega a testing) saliera a producción, sería un impacto muy fuerte para la empresa que lo implemente. Este porcentaje puede variar dependiendo de variables como:

  • Independencia del equipo de testing: mientras más independiente sea, el equipo de desarrollo menos se preocupará por la calidad de su código ya que sabe que luego viene una etapa de testing que detectará sus fallas.
  • Madurez del proceso de desarrollo: cuan aceitado esta el proceso de desarrollo para que se implementen en forma precisa las distintas tareas de desarrollo como detección de requerimientos, elección de tecnologías, lineamientos de desarrollo, pruebas unitarias, etc…
  • Experiencia del equipo de desarrollo: La experiencia que tenga el equipo de desarrollo en la metodología de desarrollo, en la implementación de la tecnología y los lineamientos de desarrollo.
  • Contexto: Relacionado con la comodidad, facilidades, infraestructura que tenga el equipo de desarrollo para poder llevar a cabo sus tareas en forma eficiente.

En cuanto a las perdidas de las empresas, se pueden observar ejemplos de casos de fallas en producción que han costado millones en perdidas para clientes y juicios para los proveedores de software.

Fallas/bugs que causaron grandes daños en los últimos 5 años

El 2011 ya nos trajo grandes Bugs

Costo de la reparación de fallas
Este punto es importante ya que las tareas de testing se llevan a cabo para reducir y mitigar el riesgo de las fallas ya sea en forma dinámica (ejecutando casos de prueba) como estática (efectuando revisión de documentos). Los costos de la corrección de esos bugs se puede presentar en forma gráfica.

relativecostbugfix

Esto de muestra que la falta de inversión en un proceso de pruebas para mitigar y reducir la presencia de fallas en las ultimas etapas de desarrollo de software donde el costo de reparación de las fallas es muy alto puede ser mucho más costoso que si se hubieran implementado las pruebas.

Conclusión

La implementación de las pruebas en el proceso de desarrollo (ya sean tareas implementadas por el mismo desarrollador o por una persona ajena al código como un tester) no nos van a asegurar un software libre de los problemas antes mencionados pero si nos brindará un conocimiento de las condiciones en que se encuentra el software antes de entregar el mismo, el testing no asegura la calidad (Testing vs. QA), el testing brinda la información suficiente para tener una medida de la calidad del software desarrollado, sin ningún proceso de pruebas se reduce el conocimiento sobre como va a funcionar el software al momento de ser entregado.

4 comentarios sobre “¿Porque realizar Testing?

  1. Muy buen artículo!

    En los ítems que hacen variar el porcentaje de errores agregaría herramientas y plataformas utilizadas (aunque capaz esto se podría incluir en «Madurez del proceso de desarrollo» o en «Contexto».

    Por ejemplo, cuando trabajaba en Unisys, teníamos una aplicación cliente PowerBuilder cuya mensajería (y pantalla) se parametrizaba manualmente en función de especificaciones Linc (la plataforma propietaria de Unisys) en el lado del servidor. Cualquier cambio en la mensajería requería de bastante testing. Cuando armamos un parser que automáticamente actualizaba la parametrización, el testing de ese tipo de cambios pasó a prácticamente cero (ejem… a veces pasábamos sin testear en desarrollo incluso).

    Otro ejemplo son las plataformas. En Oxen tenemos desarrollos en iPhone (Objective C) y Android (Java). Por cuestiones del lenguaje (tipificado, recolector de basura, etc.) son mucho más propensas a errores las aplicaciones escritas en Obejctive C que las escritas en Java.

    Como dicen los yanquis, just my 2 cents

    Me gusta

Deja un comentario

Este sitio utiliza Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.