El control de calidad se realiza a lo largo de la vida de los proyectos, desde una buena planeación, un buen levantamiento de requerimientos y durante el proceso de desarrollo, pero sin duda una de las partes fundamentales será el proceso de pruebas.

El propósito de las pruebas va mucho más allá de sólo encontrar errores, sino el evitarlos en la medida de lo posible. Todos sabemos que es más eficiente prevenir y corregir errores en etapas tempranas.  

Aunque hace algunos años era normal que sólo el desarrollador ejecutara las pruebas unitarias, hoy es impensable desarrollar un proyecto sin este importante paso, ya que es la única manera de garantizar que la funcionalidad es la esperada y prevenir resultados fatales.

Mejores prácticas

Proceso: El proceso de pruebas es una secuencia de pasos lógicos para el logro de un resultado, la calidad de éste dependerá de forma directa de la calidad de las entradas, el diseño del propio proceso y de la habilidad de quienes lo ejecutan. Este proceso se irá refinando con la experiencia y lecciones aprendidas, y deberá estar estandarizado y ser bien conocido por todos los interesados del proyecto.

Especialistas: En más de una ocasión he visto cómo asignan el desarrollo de las pruebas a programadores junior o incluso becarios con nula capacitación, minimizando la complejidad de las pruebas y omitiendo la formación de especialistas.

De acuerdo con mi experiencia las personas que ejecutan las pruebas no sólo deberán contar con capacitación especializada, sino que deberán conocer el proceso de negocio y las diferentes variables con las cuales interactúa el producto, cabe mencionar que estas pruebas son independientes a las que realiza el programador.

Planeación y casos de prueba: La planeación y los casos de prueba son el primer paso para el correcto proceso de pruebas.

Los casos de prueba de software son un conjunto de situaciones que se llevarán a cabo a fin de verificar que el producto se comporta como es esperado, estas instrucciones deberán ser personalizadas para cada proyecto.

Dentro de los casos deberán considerarse temas como los requisitos del ambiente, precondiciones, resultado esperado para datos de entrada válidos como inválidos, y no sólo pensar en el “Happy Path”, sino en diferentes escenarios que pudieran darse con los usuarios finales. Estos documentos pueden realizarse una vez que se tengan aprobados los requerimientos y compartirlos frecuentemente con los desarrolladores.

Es importante que estos casos de prueba se mantengan claros y sencillos, a fin de que cualquier persona pueda seguirlos sin necesidad de información adicional.

Clasificar los errores: Dar prioridad y clasificar los “errores” detectados nos será de mucha ayuda para organizar la siguiente etapa de corrección. La prioridad puede ser “alta” para incidencias graves que afectan o impidan el funcionamiento, “media” para incidencias que no afectan la funcionalidad, aunque sí la experiencia como el desempeño, y “baja” cuando no afecte el funcionamiento como las mejoras de diseño. La clasificación puede referirse también al error encontrado, como por ejemplo la usabilidad, la ortografía, funcionalidad, por módulo, etc. De esta manera, los desarrolladores podrán enfocarse a los que tengan más alta prioridad.

Preparar datos de prueba: Usar una base de datos real tanto como una ficticia que no represente los datos suelen ser malas prácticas; debemos asegurarnos de que los datos sean representativos para todos los escenarios requeridos, esta tarea también deberá incluirse en el proceso de planeación y darle el tiempo suficiente.

Encontrar la raíz del problema: No basta con encontrar los errores y corregirlos, sino que deberemos estar seguros de conocer la causa raíz del problema. Es preocupante cuando el equipo responde que un “defecto de código se resolvió por sí sólo”. Ejercicios simples como los 5 porqués nos ayudarían muchísimo, así como las lecciones aprendidas del proyecto.

Uso de herramientas: Actualmente existen herramientas que nos apoyan en el proceso de calidad del software y nos facilitan la tarea, el uso de estás dependerá del tamaño y complejidad del software. Sin olvidar que se requiere que quien las ejecuta cuente con los conocimientos necesarios.

Reutilizar: Aunque cada proyecto es diferente, se pueden reutilizar algunos casos de pruebas para proyectos similares, lo cual ayudará a mejorar la calidad y eficiencia del producto y los equipos podrán ahorrar mucho tiempo y esfuerzo con esta simple estrategia. Sin embargo, la administración de pruebas requiere habilidades para poder visualizar qué cosas pueden ser utilizadas en el futuro.

Pruebas de aceptación de usuario: Aunque constituyen las últimas etapas, no por ello son menos importantes. Estas pruebas las realizan los usuarios de la aplicación cuando ya se ha corregido el producto.

No es recomendable pasar a esta etapa cuando aun se tengan errores de funcionamiento. A fin de obtener mejores resultados, deberemos identificar al tipo de usuario de la aplicación.

Por lo aquí expuesto, podemos afirmar que el proceso de pruebas es fundamental y deberemos darle la importancia y tiempo necesarios. El tipo, cantidad y herramientas que se empleen dependerá del tipo de producto.

________________________

La autora de este artículo, Yessika Lozada Contreras, ha sido CIO del Instituto Panamericano de Alta Dirección de Empresas (IPADE). Es profesora del Centro de Formación de Perfeccionamiento Directivo (ICAMI) y miembro del Consejo Editorial de CIO México. Puede contactarla en ylozada@alumni.ipade.mx