Noticiero Digital Nº 475

Cuando leemos artículos especialmente los de esta casa editorial, que tan gentilmente me acoge, o cuando escuchamos a los vendedores ofreciendo sus productos de software se menciona la palabra mágica: Calidad. Sin embargo, este término para cada uno de nosotros tiene un significado diferente, es decir, un concepto relativo. Para usted, amigo lector, ¿qué es calidad del software?

Cuando hablamos de “Calidad” se nos viene a la mente palabras como cumplimiento, requisito, usuario, cliente, necesidades, expectativas, grado, características, Normas ISO, Normas IEEE, satisfacción, y producto.

La conjugación de estos criterios nos leva a la definición de Calidad. La Norma NTP-ISO 9000 define a la Calidad como el “grado en el que un conjunto de características inherentes cumple con los requisitos”.

Ahora bien, si la Calidad es lo que está de moda veamos entonces algunas reflexiones al respecto. Si usted tiene un cronograma en sus manos en este momento o acaba de terminar uno le pregunto, ¿tiene en su fase de desarrollo el tiempo definido para las pruebas del testing? De ser así, usted ya tiene conciencia de la importancia del aseguramiento de la Calidad.

Mi segunda pregunta es: ¿En los planes de desarrollo se elaboran los planes de pruebas y qué tiempo les dedica a estos del conjunto del proyecto? Si los tiempos se sobrepasan en el Proyecto y, por ende, los costos, nos imaginamos que lo primero en sacrificar no serán las pruebas, y si usted no es el responsable, de repente es su Gerente, y así sucesivamente a través de toda la escalera jerárquica de la Empresa.

Parece una paradoja. Queremos más Calidad pero sin invertir en ella, o también a los TI nos hablan de la Calidad. Yo le pregunto a usted, ¿en la universidad o en el instituto que estudió le dictaron un curso de la Calidad del Software? ¿En sus años de experiencia me puede recomendar el nombre de una literatura al respecto?

Si la mayoría de sus respuestas han sido positivas, entonces está yendo por buen camino y sus usuarios le están muy agradecidos. De lo contrario, comience a preocuparse porque hoy en día el interés por la calidad de nuestros productos de software crece en forma continua y los clientes se alejan o rechazan de aquellos productos que no son confiables o poco fiables. Además, los que desarrollan software saben que redundan directamente en sus costos e imagen y, por ende, en las utilidades de las empresas.

Cuando hablamos de la garantía del software lo enfocaremos desde el Quality Assurance (QA) del Proyecto y del Testing.

En este artículo, conversaremos sobre el Quality Assurance del testing que es parte del QA del Proyecto. Es importante empezar con dos etapas muy bien definidas:
Plan de Pruebas (antes de) e Informe del Testing (después de).

Los entregables son dos documentos que agrupan a su vez una serie de anexos como Plan de Pruebas que tienen:

Una descripción del contenido del plan en la que básicamente se identifica lo siguiente: Identificación del Proyecto, propósito, ámbito y objetivos, documentos relacionados, necesidades del ambiente de pruebas, funciones a probar, funciones que no se probarán, enfoque general del Testing, orden de ejecución de las pruebas, documentación de las pruebas, criterios de inicio y de aprobación, criterios de término, responsabilidades, actividades y planificación.
El registro del ambiente de prueba, básicamente la configuración del hardware, librerías, perfiles de usuarios, versiones, archivos, pantallas.
Registro de los casos de prueba, escenarios, menús, transacciones, casos que enfoquen las causas y efectos esperados y obtenidos.
Registro de escenarios de pruebas.

Registros de los casos de pruebas.
Resumen de avance de pruebas que permita apreciar el número definido (Técnica de Caja Negra), las realizadas, pruebas conformes, pruebas con problemas.
El control de avances de incidencias registradas.
Los casos de pruebas por funcionalidad.
Los casos de pruebas por los desarrolladores

La fecha de entrega de estos documentos se realiza modularmente en cada una de los niveles de pruebas del Proyecto dependiendo su complejidad: Entregable en pruebas unitarias, modulares, integrales, con componentes y piloto. Las mismas que deben estar íntimamente ligadas y consideradas en el cronograma respectivo del Proyecto.

Ahora bien, para mover toda la cadena de proceso del aseguramiento de la calidad en el testing es necesario hacer funcionar los niveles, roles, ambientes, estatus, guías, puntos de control y los mismos entregables. Es muy importante la descripción de conceptos en el aseguramiento de la calidad en el testing, sabemos que tenemos niveles, roles, ambientes, estatus, guías, y puntos de control.

Los niveles se refiere a los niveles de pruebas que deben existir en cada uno de los pasos: Prueba unitaria, modular, integral, prueba integral con componente y piloto.

Los roles son los procesos que le toca desarrollar a las personas durante la cadena de procesos de pruebas y su alcance es para desarrolladores, analistas funcionales, implementadores, soporte técnico, usuario, producción, tester.

Los ambientes: Los de desarrollo, pruebas y producción. Estatus son las características de los programas en la que se encantarán congelados, es decir, sin modificaciones hasta el día de su ingreso a producción.

Las guías son los puntos que se requiere en cada uno de los pasos anteriores. Los puntos de control son los sitios de chequeo que servirán como check list de cumplimiento. Finalmente, los entregables son los reportes e informes manuales y mecanizados que se van entregando a través de la cadena descritos en el Plan de Calidad e Informes del Testing.