INTRODUCCIÓN

La medición es considerada como una eficaz herramienta en las pruebas a los

software, es la base para: detectar las desviaciones del rendimiento aceptable en los
procesos y producto de software, y las oportunidades de mejora, identificar y priorizar
las principales preocupaciones, dar seguimiento a la solución y mejorar la calidad del
producto.

Las mediciones permiten además cuantificar tanto el proceso como el producto.

Proporcionan la visión del desempeño del proceso permitiendo: desarrollar perfiles de
los datos de los proyectos anteriores que se pueden utilizar para la planificación y
mejora del proceso; analizar un proceso para determinar cómo mejorarlo; determinar
la eficacia de modificaciones en el proceso, (Pomero y Cannon, 2003).

En el proceso de prueba las mediciones pueden ser usadas para, (Kaner y Pretichord,
2001).

- Monitorizar el proceso de prueba: Mostrar visibilidad sobre las actividades de

pruebas. Esta información puede ser usada para medir el criterio de terminación de las
pruebas y evaluar el progreso contra lo planificado.

- Reportar las pruebas: Métricas recolectadas al finalizar cada etapa de prueba para
evaluar la adecuación de los objetivos de la etapa, la adecuación de la estrategia de
pruebas tomada y la efectividad de las pruebas con respecto a sus objetivos.

- Controlar las pruebas: Acciones correctivas tomadas como el resultado de la

información, las métricas tomadas y reportadas.

En el Laboratorio Industrial de Pruebas de Software (LIPS) del Departamento de

Pruebas de Software de (Calisoft) no se evalúan los productos de software por las
características de calidad debido a la carencia de mediciones realizadas a los mismo, lo
que influye negativamente en la opinión del cliente sobre la calidad del producto, de
ahí la necesidad de insertar desde etapas tempranas de las pruebas un grupo de
métricas de calidad.

TIPOS DE METRICAS

 DE USUABILIDAD:

Al evaluar la usabilidad de una interfaz muchas veces oímos (o leemos) esa frase que dice
“Hay que contar con las opiniones de los usuarios para adecuar la aplicación a sus
necesidades”. Sí, pero con matices importantes. Es cierto que hay que escuchar sus
opiniones, pero más importante es saber interpretarlas adecuadamente. Haciendo caso
solo de todas las opiniones de los usuarios NO resolveremos todos los problemas. La
principal tarea del experto en usabilidad es detectar también aquellos problemas que están
implícitos en los comentarios y en el uso . Éstos, la mayoría de veces no se expresan de
forma verbal. Una forma de detectar parte de éstos problemas es a través de la medición de
métricas. ¿Qué son las métricas de usabilidad? Podríamos definirlas como aquellos
criterios o variables que son medibles de forma objetiva. Mientras que la interpretación de
una opinión es un análisis cualitativo o subjetivo por parte del experto, la interpretación de
datos objetivos responde a un análisis cuantitativo. Este tipo de variables se estructuran,
como norma general, en tres grandes grupos: Efectividad: variables que nos permiten
medir la exactitud y la plenitud con la que se alcanzan los objetivos de una tarea concreta.
Algunas de las variables más típicas son: Porcentaje total de tareas completadas.
Porcentaje de tareas completadas en el primer intento. Porcentaje de usuarios que
completan las tareas. Ratio de éxitos y fracasos. Número de veces que los usuarios solicitan
ayuda por no saber que hacer. Eficiencia: se refiere al esfuerzo que un usuario tiene que
hacer para conseguir un objetivo. Algunas variables típicas son: Tiempo empleado en
completar cada tarea. Porcentaje o número de errores cometidos. Porcentaje de errores o
problemas según su severidad. Tiempo empleado en recuperarse de los errores. Número de
clicks realizados para completar una tarea. Número de páginas visitadas para completar
una tarea. Tiempo empleado en determinadas páginas o grupos de páginas. Porcentaje o
número de veces que se acude a ayudas, FAQ o similar. Satisfacción: se refiere a aquellas
que tienen que ver más con lo emocional o subjetivo. Para medir el grado de satisfacción
puedes utilizar criterios como: Porcentaje de usuarios que después de utilizar el producto
lo recomendaría a un amigo. Proporción de adjetivos positivos o negativos que cada
usuario de al producto. Porcentaje de usuarios que califican el producto más fácil de usar
que cualquiera de la competencia directa. Número de veces que el usuario expresa
satisfacción o insatisfacción. Además de las reflejadas aquí, es posible crear cualquier otra
métrica que resulte de utilidad. Por ejemplo, puedes medir el porcentaje de incremento de
ventas que tienes antes y después de hacer un rediseño.

 DE CALIDAD:

El concepto de métrica es el termino que describe muchos y muy variados casos

de medición. Siendo una métrica una medida estadística (no cuantitativa como en otras
disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de software, los
cuales deben ser medidos desde diferentes puntos de vista como el análisis, construcción,
funcional, documentación, métodos, proceso, usuario, entre otros.El concepto de métrica
es el termino que describe muchos y muy variados casos de medición. Siendo una métrica
una medida estadística (no cuantitativa como en otras disciplinas ejemplo física) que se
aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde
diferentes puntos de vista como el análisis, construcción,
funcional, documentación, métodos, proceso, usuario, entre otros.

 DE PUNTO DE FUNCION DE ALBRECHT:

Miden la aplicación desde una perspectiva del usuario dejando de lado los detalles de
codificación, estos evalúan con fiabilidad.

El valor comercial de un sistema para el usuario.

Tamaño del proyecto, costo y tiempo de desarrollo.
Calidad y productividad del programados.
Esfuerzo de adaptación, modificación y mantenimiento.
Posibilidad de desarrollo propio.
Beneficios de implementación en 4GL.

 METRICAS DE MANTENIBILIDAD DEL SOFTWARE:

Las métricas de mantenibilidad no pueden medir el coste de realizar un cambio particular

al sistema software, sino que miden aspectos de la complejidad y la calidad de los
programas ya que existe una alta correlación entre la complejidad y la mantenibilidad (a
mayor complejidad menor mantenibilidad) y entre la calidad y la mantenibilidad (a mayor
calidad mayor mantenibilidad – y viceversa – ).
Existen maneras de medir la mantenibilidad para todos los elementos software que están o
estarán sometidos a mantenimiento: código, documentos de usuario, documentos de
análisis o diseño, etc.
Las métricas del software se pueden clasificar en tres categories (vease (Kan1, 2002)):
Métricas de producto. Estas métricas describen las características del producto que de
alguna forma determinan la mantenibilidad, por ejemplo el tamaño, complejidad o
características del diseño.
Métricas del proceso. Las métricas del proceso pueden ser utilizadas para mejorar el
desarrollo y mantenibilidad del software. Algunos ejemplos incluyen la eficacia de eliminar
defectos durante el desarrollo, el patrón en el que aparecen los defectos durante las
pruebas o el tiempo fijo de respuesta del proceso.
Métricas de proyecto. Las métricas de proyecto describen las características y ejecución del
proyecto. Por ejemplo, el número de desarrolladores, el patrón de staffing en el ciclo de
vida, coste, planificación y productividad del software.
Proceso de pruebas de
calidad de Software
04 mayo / MICROTECH

Las pruebas de calidad en un Software ERP son todos aquellos procesos cuya
ejecución permiten conocer la calidad del mismo, así como los posibles fallos
que puedan existir a corto, medio o largo plazo. Cuando se realizan pruebas en
los software de gestión empresarial es posible predecir su comportamiento
durante la implantación, su grado de manejabilidad y su interfaz gráfica.

Existen diferentes maneras para realizar las pruebas de calidad, las

mismas van dadas por el contexto que representa cada uno de los clientes en
particular, en otras palabras, no hay un plan de prueba que pueda servir para
todos los escenarios, porque puede ser que una prueba para un software ERP
específico sea perfecta, pero en otro puede llegar a ser perjudicial.

TIPOS DE PRUEBAS DE CALIDAD DE SOFTWARE

Todas las pruebas de este tipo varían, no obstante, su finalidad sigue siendo la
misma y es el hecho de comprobar y dar el visto bueno a todo el software de
una empresa, sin importar que se trate de un ERP para empresas
instaladoras o para empresas distribuidoras. A continuación se explican
algunas pruebas de calidad:

 PRUEBAS DE FUNCIONAMIENTO: Dentro de esta categoría es posible

encontrar tres subgrupos, los cuales se clasifican, según sus objetivos,
en:
o Testing de función: Enfocada en conseguir informes sobre la
aptitud de las funciones, los métodos y los servicios que
componen el ERP.
o Testing de seguridad: Ideada para comprobar la seguridad de
los datos que maneja el ERP para Pymes, es decir, los datos de la
empresa.
o Testing de volumen: Dirigida a medir la velocidad del ERP para
procesar grandes cantidades de información en la base de datos,
bien sea en entrada o en salida.
 PRUEBAS DE USABILIDAD: La finalidad de éstas es comprobar la
relación del usuario con el software de gestión empresarial, prestando
 especial atención a la interfaz, la experiencia del usuario, asistentes de
ayuda integrados, interactividad, entre otras cosas.
 PRUEBAS DE FIABILIDAD: Al igual que las de funcionamiento, se
dividen en tres grupos:
o Testing de integridad: Trata de valorar y calificar la resistencia a
fallos que presenta el software.
o Testing de estructura: Consiste en verificar que cada una de las
partes que componen el diseño del software ERP se encuentren
conectadas a las funciones correctas, en otras palabras, que no
exista contenido huérfano en el ERP.
o Testing de estrés: Se utiliza para evaluar el comportamiento del
software ERP en situaciones poco usuales, como por ejemplo,
una sobre carga de funciones, la saturación de la memoria, la
restricción de los recursos compartidos, etc…
 PRUEBAS DE RENDIMIENTO: Miden la relación función resultado de
un ERP, éstas se dividen en:
o Testing Benchamark: Se encarga de cuantificar el rendimiento
de un nuevo componente del ERP, comparándolo directamente
con otro existente.
o Testing de contención: Ésta valora la capacidad de respuesta de
un elemento, en cuanto a sus habilidades, al momento de ser
requerido por diversos actores, un ejemplo de dicho elemento
podría ser el registro de recursos o la memoria.
o Testing de carga: Su finalidad es probar y asegurar los límites
operacionales del software de gestión empresarial, mediante la
aplicación de cargas de trabajo promedio. Por ejemplo, si se
quiere hacer la prueba sobre un ERP para una empresa de
obras y servicios, es necesario indicar cuales son las cargas
habituales de trabajo de las mismas.
 PRUEBAS PARA LA CAPACIDAD DE SOPORTE: Existen dos formas
de medirlo, éstas son:
o Testing de configuración: Su principal objetivo es asegurarse
que un ERP funciona de forma correcta, sin importar la
configuración que la empresa decida aplicar, tanto a nivel de
software como a nivel hardware. De igual forma es posible aplicar
esta prueba como un medidor de rendimiento del sistema, o bien
utilizarla en asociación con una prueba especializada en dicho
tema.
o Testing de instalación: Es probablemente una de las pruebas
más importantes, puesto que de ella dependerá, en gran medida,
la correcta implementación del ERP. Consiste en certificar que el
software ERP se encuentra en plena capacidad de ser
instalado en condiciones extremas de hardware o de
software, como por ejemplo, problemas con la capacidad de
memoria o con la velocidad de procesamiento.