 |
Estrategias
La manera de llevar a cabo la fase de test varía enormemente en función del tipo de proyecto de que se trate. Existen diversos condicionantes que influyen en la forma de realizar el test del producto:
Tipo de producto: en general, la función del producto determina la forma de llevar a cabo el control de calidad. Por ejemplo, siendo ambos productos multimedia, el test de un videojuego basado en una aventura gráfica será mucho más complejo de testar que el de una presentación de negocios. Mientras en el primero deberemos esforzarnos por comprobar que la funcionalidad es correcta cualquiera que sea el recorrido que realice el usuario, en el caso de una presentación corporativa, con una estructura de navegación mucho más simple, deberemos dedicar más esfuerzo en la corrección de los textos y la adecuación de la presentación.
Plataforma: también la plataforma para la que estamos produciendo condiciona la forma de realizar el test. En el caso de que desarrollemos un producto on-line, además del control de calidad previo a la publicación que asegure la corrección de los contenidos y la funcionalidad del sitio web, deberemos establecer una evaluación periódica de la capacidad del servidor y del ancho de banda disponible para atender a todos los usuarios.
En los productos off-line, la plataforma para la que desarrollamos influye en el control de calidad a realizar. Si los requisitos del producto establecen que éste funcione para una versión específica de un sistema operativo, tendremos muchas menos dificultades que si desarrollamos un producto multiplataforma. Por ejemplo, si nuestro producto es un quiosco multimedia que va a ser implantado bajo un único modelo de ordenador, tendremos menos dificultades que si desarrollamos un CD-ROM multiplataforma.
Público objetivo: el público al que nos dirigimos condicionará también la forma de llevar a cabo el control de calidad. Por ejemplo, si desarrollamos un producto para niños de corta edad deberemos pensar en que los controles en pantalla sean fácilmente identificables y respondan a los intereses de este perfil de usuario. En cambio, un producto para ancianos tendrá unos requisitos de navegación y presentación claramente diferentes. Como ya mencionamos en el apartado de recursos, es importante contar con personas del público objetivo para efectuar un buen control de calidad.
Complejidad técnica: la componente tecnológica condiciona enormemente los requisitos del control de calidad. Los productos desarrollados con herramientas de autor serán en general más simples que aquellos que utilizan desarrollos propios combinando tecnologías diversas. El equipo de desarrollo conoce en cada caso los riesgos de los recursos que utiliza nuestro producto.
Piensa en las principales acciones que requeriría el control de calidad de los siguientes productos:
un buscador de Internet,
una enciclopedia multimedia en CD-ROM,
un DVD-video sobre recetas de cocina japonesa.
Referentes
Durante el test de la aplicación debemos disponer en todo momento de los documentos en los que se establecen los objetivos del producto. Estos documentos serán nuestra referencia a la hora de detectar las deficiencias a corregir:
El prototipo de producto o maqueta: en la fase de diseño de producto se trata de un elemento clave durante el test de usuario. Nos será de gran utilidad para evaluar las percepciones del usuario respecto a la navegación y la presentación del producto. Ha de ser lo suficientemente flexible para que podamos modificarlo con facilidad y someterlo de nuevo a test. Lo mantendremos «vivo» hasta el cierre de la fase de diseño, momento en que el prototipo pasará a ser un referente más para el control de calidad.
Documentos de diseño: la especificación de los diseños de la información, interacción y presentación serán especialmente útiles a la hora de valorar el funcionamiento de la navegación, la usabilidad del producto o su presentación gráfica.
Lista de especificaciones técnicas: es esencial para conocer los requisitos de los ordenadores que formarán el banco de pruebas e imprescindible durante el test. Las especificaciones técnicas del producto establecen el sistema operativo para el que se ha diseñado la aplicación, la configuración mínima del ordenador del usuario (CPU, memoria RAM, tarjeta de gráficos, tarjeta de sonido), el software de soporte necesario (que siempre deberíamos incluir en el propio soporte en caso de los productos off-line o con un enlace a los sitios web).
Libro de estilo: el documento que recoge las directrices que deberán cumplir los contenidos del sitio. Será de utilidad ante las dudas que puedan surgir con respecto al texto, imágenes, audiovisuales que componen la obra.
Lista de errores conocidos: una lista con la descripción de las características no disponibles –o con errores ya identificados– de la versión en fase de pruebas.
Cuando estamos en la fase de control de calidad final, un cambio en los criterios generales en que se basa el producto puede significar una nueva revisión para muchos elementos o funciones previamente aprobados.
Sólo cuando sea realmente imprescindible debemos modificar los criterios establecidos durante la fase de diseño de nuestro producto. Es precisamente durante el control de calidad cuando podremos apreciar la enorme importancia de disponer de un diseño sólido, a prueba de cualquier incidencia.
Informes de error
Como ya mencionamos en el apartado de planificación, el ciclo de test requiere que las incidencias que se encuentren se documenten de la mejor forma posible. A tal efecto, se utilizan los llamados informes de error (o bug reports en la jerga del sector): para esta función normalmente se diseñan unos formularios que facilitan al máximo la recopilación de información por parte de los testadores.
Normalmente un formulario de informe de error consta —como mínimo— de los siguientes apartados:
Nombre de la persona que realiza el test.
Configuración del ordenador: que puede ser una referencia a otro documento donde se describa con detalle.
Versión de la aplicación: alfa, beta, release candidate.
Clase: error, deficiencia, mejora.
Tipo: contenido, funcionalidad, diseño.
Pantalla en la que se produce: el lugar dentro de la aplicación en que se da el error, por ejemplo: página de resultados de búsqueda.
Antecedentes: descripción de la situación desde la que se ha llegado a producir el error.
¿Se puede reproducir? Sí/no: se trata de determinar si se puede provocar de nuevo el error o si por el contrario no hay forma aparente de que suceda de nuevo.
Descripción: texto descriptivo.
Puede ser chocante la inclusión de un campo «clase» que permite distinguir entre errores, deficiencias y mejoras. La intención es aprovechar el proceso de control de calidad al máximo, de manera que cualquier incidencia pueda detectarse en este momento, incluso si no se trata propiamente de un error, sino de una deficiencia o una propuesta de mejora. Posteriormente, el responsable de control de calidad determinará las acciones a emprender considerando también el contenido de este apartado.
Formulario de informe de error
Algunos de los apartados podrían adecuarse a la estructura del producto que estamos desarrollando, por ejemplo incluyendo en la sección «pantalla» una lista de las pantallas de la aplicación, de manera que evitemos denominaciones ambiguas; así facilitaremos todavía más la tarea de los testadores. Éstos deben tener ejemplares del formulario de informe de error siempre a mano y deben estar instruidos acerca de los criterios que se aplican a la hora de rellenarlos.
Gestión de los informes de error
El responsable de control de calidad se ocupará de gestionar los informes de error basándose en el siguiente proceso:
Consolidar los diversos informes de error generados por los testadores, identificando los duplicados y asegurando la correcta descripción de todos ellos.
Clasificar y priorizar la lista de incidencias de acuerdo con los responsables editoriales, de desarrollo y de diseño. Es necesario determinar qué incidencias se corregirán y en qué momento estará disponible la nueva versión para comprobar su implementación.
Asignar un responsable para la resolución de cada incidencia en función de su naturaleza: los programadores para la funcionalidad, los editores para los contenidos y la navegación, y los diseñadores gráficos para la presentación.
Hacer el seguimiento de la resolución de la incidencia.
Preparar el siguiente ciclo de test sobre la nueva versión de la aplicación en que los testadores deberán comprobar la implementación de las incidencias que se determinaron en su momento.
En general, además, el responsable de test deberá mantener actualizada la lista de errores conocidos, uno de los documentos de referencia descrito más arriba.
Test de usuario
No intervenir durante la sesión de test: cuando nuestro producto salga al mercado, evidentemente no estaremos detrás de cada usuario para explicarle lo que significa cada icono o la función de determinado botón. Es importante que el usuario reaccione de forma independiente. Sólo de esta manera podemos valorar su aportación.
Registrar los comentarios y reacciones del usuario: tomar nota de todos sus comentarios por insignificantes que parezcan.
En algunos casos, por ejemplo cuando trabajamos en un producto orientado a niños de corta edad, puede ser útil disponer de una cámara de vídeo que recoja las expresiones del usuario de forma simultánea a lo que aparece en la pantalla.
Test de funcionalidad
Asegurarse de que se prueban todas las opciones y las combinaciones posibles: es necesario equivocarse, hacer lo imprevisto y llevar la aplicación a situaciones extremas.
Probar bajo el máximo número posible de ordenadores: con las más diversas configuraciones de hardware y software.
Realizar revisiones sobre versiones previas: de esta forma optimizamos el tiempo dedicado al control de calidad y podemos detectar posibles incidencias con la antelación necesaria.
Realizar controles de calidad incluso a posteriori: especialmente en los productos on-line, cada vez que aparece una nueva versión del sistema operativo o del navegador, debemos asegurarnos que nuestra aplicación funciona correctamente.
Test de contenidos
Revisar los contenidos durante el proceso de producción: de esta manera la única revisión que deberán sufrir será la validación de la presentación de los mismos.
Controlar y acotar al máximo las modificaciones a los criterios de diseño y al libro de estilo de la obra; de esta forma evitamos duplicar los procesos de revisión.
Evitar la tentación de modificar los contenidos que han pasado control de calidad con el fin de evitar errores y controlar la implementación de las nuevas versiones de contenido. Cualquier modificación debe preverse de acuerdo con el equipo de producción.
|
Si bien el control de calidad debe ser una constante durante todo el proyecto, la complejidad tecnológica y editorial de un producto multimedia hace imprescindible una revisión a fondo de la funcionalidad y los contenidos de nuestra aplicación. A la hora de realizar el plan de proyecto debemos considerar la importancia del control de calidad, reservando los recursos humanos y materiales necesarios para el mismo. La estrategia a seguir para llevar a cabo esta tarea dependerá del diseño, la tecnología y el público objetivo al que nos dirigimos. |
 |
|
 |
