Preliminares
Hace poco tiempo me invitaron a una prueba Beta, como no soy un profesional del área, pensé que podría dar mi punto de vista como usuario, después de todo, para los diseñadores de aplicaciones siempre es de utilidad "diseñar para el más torpe y tonto de los usuarios posibles"... ok, yo no caigo tan bajo en la escala de apreciación, pero bien, no soy experto en estas cosas y aunque me esfuerzo en tratar de comprenderlas, de seguro hay un montón de cosas que se me escapan.
Bien, retomando el tema, el asunto es que usé la aplicación en cuestión y revisé todas las opciones que fuí capaz de encontrar, creo que la usé lo suficiente como para considerarme un "usuario promedio", pero ahora me encontraba con la necesidad de presentar por escrito los resultados de mi experiencia con el software, tal cosa puede que no sea un problema para quienes se encargan de estas tareas en el campo de ingeniería de software o diseño de aplicaciones, pero para un "Inmigrante Digital" como yo, que aún recuerda sus primeros tiempos con las computadoras de pantallas negras con letras verdes, pues es una tarea a la que no estoy acostumbrado.
- Problema: ¿No sé bien cómo se hacen estos informes?
- Solución: Busca ayuda en línea y encuentra las indicaciones y de ser posible un formato que sirva de guía.
Recordando un apodo
Al momento de estar buscando una guía para cumplir con mi tarea, recordé un evento en el que me tocó ser un evaluador en un curso dictado por la Universidad en la que trabajaba, en ella los profesores trabajamos en grupos de tres personas para evaluar a cada participante.
Uno de los evaluadores, en cada grupo, era un profesor de los estudiantes en alguna de las materias en cuestión, los otros dos no teníamos que ver con sus procesos de formación académica y se nos podía considerar como observadores externos que serían imparciales.
Tomando en cuenta que el trabajo de evaluación siempre corre el riesgo de verse afectado por las preferencias subjetivas del evaluador y encontrando que no me dieron ningún listado de puntos de parámetros, más allá del temario del examen (lo que implica que mi apreciación subjetiva podría ser lo que guiará el resultado del puntaje), pues me decidí rápidamente por elaborar un conjunto de rasgos mínimos que debía tener la presentación, el manejo del tema y las técnicas-recursos empleados por el estudiante. Los organicé rápidamente y elaboré una Lista de Chequeo para usarlo en el momento de evaluar la presentación y las respuesta de cada estudiante.
Esto me pareció lo correcto, pero me encontré que mi actitud fue considerada de muy mal gusto por parte del profesor de los estudiantes y también por el otro colega que era evaluador en mi grupo, ellos eran de criterios mucho más "artísticamente libres" y veían en mi formalización normativa un comportamiento asfixiante de la creatividad y de la "riqueza expresiva de las presentaciones"... Ok, no me había esperado eso.
Me gané un apodo que los consideraron me ofendería un poco, en el que mezclaban mi apellido con un término que no les agradaba: "Baremo-Brito"
Source
Solo por si no queda claro, una definición de Baremo es:
... tabla de cálculos, que evita la actividad de realizar esos cálculos al público común o a un público específico, que se emplea para establecer un conjunto de normas fijadas por una institución para evaluar los méritos personales,es importante establecer una posición ordenada por méritos, es aquello que justifica un reconocimiento o un logro que explica un fracaso y la capacidad de empresas, las normas de admisión son un conjunto de puntuaciones parciales, resultados de análisis, lista de números índices, etc.
Source
No me molestó el asunto y seguí adelante con las evaluaciones, con la ventaja de que podía justificar cada una de las puntuaciones que asigne en criterios previamente establecidos y que disminuían los efectos de mi apreciación subjetiva. Nunca más fui seleccionado como evaluador, pero aprendí algo interesante de todo eso.
Hay que aceptar que por mi caracter, puedo parecer fácil de tratar, pero mi "manía normativa" me hace ser un "Bicho Raro" en muchos aspectos, soy partidario de establecer formatos, seguir protocolos de acción y evaluar con baremos. Así que ante una tarea que nunca he hecho, me parece normal buscar una guía y ver que tanto puedo usarla para cumplir con mi tarea.
Una guía o modelo para escribir un reporte de evaluación de software
Encontré en el sitio de Software Testing Help un post que creo que es lo que estaba buscando: How To Write An Effective Test Summary Report [Sample Report Download]
En general me daba una idea de lo que necesitaba hacer, pero como no es mi área y necesito reportar es mi resultado como usuario de la Beta, pues me propuse elaborarlo tipo lista de puntos a seguir para redactar mi material, usando el proporcionado por Software Testing Help como inspiración para eso.
Ahora bien, ¿qué debo contemplar en mi reporte?, según lo que he dicho. Las secciones del reporte que ellos presentan son:
- Propósito
- Descripción general de la aplicación
- Alcance de prueba
- Métricas
- Tipos de pruebas realizadas
- Prueba de entorno y herramientas
- Lecciones aprendidas
- Recomendaciones
- Mejores prácticas
- Criterios de salida
- Conclusión / Cerrar sesión
- Definiciones, acrónimos y abreviaturas.
Algunas de las secciones son bastante especializadas y al leer las descripciones no me sentí seguro de poder cumplir plenamente con el conocimiento técnico para realizar una evaluación de software tan exhaustiva, así que me tocó elegir los puntos que podría usar para elaborar mi propio reporte de prueba Beta desde el punto de vista de un usuario final. quedaron así:
- Propósito: Descripción breve del objetivo del reporte.
- Descripción general de la aplicación: Breve descripción de la aplicación probada.
- Alcance de las pruebas: Explica las funciones y las secciones que se sometieron a las pruebas. También se señala lo que no se pudo probar por no tener el nivel de usuario o por otras restricciones.
- Tipos de pruebas realizadas: Describe los diversos tipos de Pruebas realizadas. Para mi caso tendrían que cubrir: Tiempo de carga, usabilidad de la interfaz de usuario, selección de las paletas de colores, disponibilidad de canales de comunicación, funciones de compra-venta dentro de la aplicación, y opciones de personalización para cada usuario.
- Entorno y dispositivos para las pruebas: Proporciona detalles sobre el entorno de prueba en el que se realiza la evaluación, indicando las características y los dispositivos.
- Recomendaciones: Cualquier solución o sugerencia para mejorar la aplicación se puede mencionar aquí
- Mejores prácticas: Identificación de situaciones, condiciones y otros elementos que podrían proporcionar una ventaja al momento de hacer el trabajo de evaluación, esta información podría ser de utilidad para futuras pruebas.
- Conclusión: En esta sección se da el veredicto, si los resultados de la evaluación permite estar de acuerdo y da una "señal verde" (aprobación) para la aplicación o si la aplicación no cumple con lo esperado y toca decir "No se sugiere que la aplicación se implemente en su estado actual". Como Betatester, esto constituye sólo una sugerencia y deberán ser los superiores de la compañía de software quienes tomen la decisión.
Cerrando el tema
Hasta ahora, todo esto es sólo para poder escribir un reporte de evaluación de software como usuario de la Beta, de seguro es posible mejorarlo en muchos sentidos, pero quería compartirlo y dejar abierta la posibilidad de que otros compañeros pudieran señalar las debilidades y las maneras de mejorar esto para algún uso futuro.
El 20% de esta publicación está destinada a apoyar 
Project #HOPE Website