“Las pruebas de software son para cobardes, todo a producción”

 

Una simple frase cómo la anterior define una problemática en el desarrollo de software de algunas empresa, la falta de un ciclo de desarrollo definido y de la importancia de que todas las etapas sean consideradas indispensables como la propia codificación.

Es muy común asumir que los programadores pueden hacer su trabajo con calidad al momento de hacer la codificación, lo cual aún después de muchos años de experiencia, puede ser riesgoso ya que la calidad de la programación depende de muchos factores humanos (estrés, enfermedades, problemas familiares, cansancio, etc.) que pueden incidir en la calidad del producto final.

En todos los procesos de producción de un buen producto existe un paso importante de control de calidad que se define con parámetros muy claros de pruebas al producto final para garantizar una calidad homogénea ¿alguien se imagina un automóvil Toyota que se entregue sin probar?

Así debemos considerar todos los productos de software que produzcamos en nuestra empresa, los cuales tenemos que pasar siempre por un área de control de calidad, que pueda someter a diferentes etapas de pruebas con metodologías, métricas y controles, a los productos cuya información ayude a tomar la decisión de liberar o no un producto de acuerdo a los parámetros de calidad que se definan con el cliente.

Una forma de medir la calidad de un producto de software, es a través de la densidad de defectos, la cual podemos traducir como el numero de defectos que son introducidos en el código por cierta cantidad de lineas de código (LOC) que son programadas es un producto, esta medida define estadísticamente que por cada mil líneas de código que se escriben, estaremos esperando que el programa tenga un número especifico de errores en él.

Las referencias que tenemos, es que el promedio de la industria en esta métrica es de 15 a 50 errores por cada 1000 líneas de código en aplicaciones desarrolladas; aún cuando tomáramos el valor más bajo, podemos citar los siguiente ejemplos:

• Aplicación promedio de iPhone   400 mil líneas (LOC) 6 mil errores
• Android 12 millones 180 mil errores
• Office 2013 44 millones 660 mil errores
• Visual Estudio 2010 50 millones 750 mil errores

 

Estos números de defectos no identificados se ven impresionantes puestos en una tabla que sólo nos hace pensar en cuál es calidad de las aplicaciones hechas por profesionales con un proceso definido y medido. Aquí aplica un consejo que doy en general “la información puede servir para tranquilizar o para espantar” depende de uno mismo en que sentido verlo. Debemos tomar en cuenta que esa cantidad de defecto los conocemos por qué son el resultado de un proceso ordenado de pruebas con diferentes etapas como pruebas de caja blanca , caja negra, caja gris, etc. lo cual nos permite tener información para analizar y conocer los riesgos que corremos al generar aplicaciones sin pasar por un proceso de pruebas.

Ahora, imaginemos una situación en la cual una empresa no le da importancia a las pruebas de software y no aplica una metodología ordenadas y por lo tanto, no tiene métricas para sus aplicaciones, así que estamos generando productos con una cantidad impresionante de defectos los cuales ignoramos, pero los usuario finales sí los encontrarán al momento de utilizar la aplicación dando una imagen negativa del trabajo que se hace.

Entonces, para poder mejorar, tenemos que medir, ¿qué sucede en la industria cuando se hacen pruebas? Microsoft menciona que después de hacer pruebas, la densidad de defectos pasa de 15 por 1000 LOC a 0.5 defectos post liberación, esto significa que pasan de 660 mil errores a 22 mil errores; un número muy grande pero significa reducir la densidad a un 3% de los defectos en una aplicación, lo cual les ha funcionado nivel mundial

Humphrey, uno de los gurús de desarrollo de software, dice que un software desarrollado que utilice TSP (metodología de pruebas desarrollado por el) ayuda a llegar a 0.1 defectos por 1000 LOC, lo cual significaría pasar de 180 mil errores a 1200  para una sistema operativo como android muy significativo y muy útil para la apreciación de calidad de un producto

Por lo tanto ¿cómo llegamos a una situación en la cual podamos mejorar y conocer la calidad de nuestro productos?

 

 

1. El primero paso es definir estándares de programación, es decir, debemos definir cómo los programadores hacen la codificación para que una línea de código siempre sea una linea de código por ejemplo:

Un programador define variable de esta forma: int a,b,c;

Un programador define variables:

int a;

int b;

int c;

Ambos ejemplos anteriores, son validos en la programación pero, al momento de contar líneas de código producirán diferentes resultados por lo tanto, hay que definir estándares de programación muy claros y asegurarse de que estos se sigan para que podamos conocer de forma exacta y uniforme la cantidad de líneas de código de un producto y con eso hacer una contabilización que podamos usar para definir la densidad deseada de forma homogénea

 

2. Definir un ciclo de desarrollo de software el cual incluya la etapa de pruebas y seleccionar una metodología de pruebas de software, tomemos como definición que una metodología de pruebas son estrategias y tipos de pruebas que se usan para certificar que una aplicación sometida a ellas cumple con las expectativas del cliente. ¿Cuál elegir?  La que mejor se adapte a su organización y después mejorar, lo importante es comenzar.

3. Implementar un área de pruebas de software con personal dedicado exclusivamente a esta tarea con independencia del área de codificación y que siga la metodología definida.

4. Implementar el uso de un software para el registro, control y seguimiento de los defectos encontrados en la aplicación por el área de pruebas, esto es muy importante ya que, es a través de este registro que podremos saber la calidad de nuestro producto para determinar el momento de la liberación del mismo con la mejora de la calidad de acuerdo con el número de defectos encontrados en la cantidad de líneas de nuestro producto.

Una vez tomadas estas acciones enumeradas, podemos conocer la densidad de defectos que generan nuestras áreas y con eso podremos definir las métricas necesarias para la liberación de un producto. Por ejemplo, si tenemos un producto de 400 mil líneas y nuestra área de pruebas ya encontró y registro 6 mil errores, entonces podemos pensar que estamos en la media de la industrias y así definir cuál será nuestra densidad de defectos objetivo de nuestro producto para mejorar liberar a un ambiente de producción.

 

Concluyendo, no debemos olvidar la importancia de las pruebas de software en nuestras empresas, esto nos ayudará a ser mejores y dar un mejor servicio a nuestros clientes. Liberar aplicaciones a ambientes productivos sin conocer el estado de la aplicación, es un riesgo o una receta para el desastre.

 

Existen otras acciones que nos pueden ayudar a reducir la densidad de defectos en nuestros productos, como puden ser:

1. Compra de librerías de terceros que estén certificadas y probadas.
2. Desarrollo de librerías propias de la empresa, las cuales pasen por todas las etapas de un ciclo de desarrollo de software que ya están estables y puedan usarse en diferentes proyectos
3. Reutilizacion de códigos de otros proyectos que ya estén debidamente probados y liberados.

 

Por ultimo, dejé un punto fuera por la importancia en su definición y que más adelante tocaré en otros artículos, me refiero a que también es necesario definir una clasificación y tipificación de defectos,  es decir ¿qué es un defecto? Concepto, por además, importante en la etapa de pruebas.