La semana pasada se
celebro el STAR East (Software Testing Analysis and Review East) y dos de las
sesiones que más llamaron mi atención estuvieron relacionadas con las historias
de testing, charlas impartidas por Isabel Evans y Jennifer Bonine.
Los reportes de bugs
son para los testers la forma principal de comunicación, pero, ¿Qué tan
efectivos son nuestros reportes? Al final de cuentas esta comunicación es en la
que se basa la colaboración ya que de los reportes, se desencadenan preguntas
como ¿Es un bug? ¿Lo vamos a resolver? ¿Cómo lo resolvemos?
Para quienes
entiendan la referencia del título, así es como se inician las historias de terror,
y es que con el tiempo me he dado cuenta, que si las historias de testing, son
de terror, es más sencillo que se involucren todos los stakeholders. No es lo
mismo reportar:
a) Error
de validaciones en login (con sus respectivos detalles)
A reportar
b) Es
posible ingresar a la cuenta de otros usuarios sin conocer su contraseña
poniendo en riesgo la integridad y confidencialidad de la información (con sus
respectivos detalles)
Si los reportes son técnicos,
las cosas pueden minimizarse, debemos recordar que es importante alertar a los
involucrados cuando es necesario.
Un ejemplo sencillo
que se mencionó en una de las charlas fue la forma en que la tripulación se
asegura que los pasajeros encargados de la puerta de emergencia hayan leído las
instrucciones con detenimiento.
La pregunta general es:
a) ¿Ha leído
usted los pasos necesarios para abrir la puerta de emergencia en caso de
incidente?
Pregunta que muchos
de nosotros contestamos afirmativamente cuando en ocasiones puede no ser
verdad, pero ¿qué pasaría si en lugar de esa pregunta se hace la siguiente?
b) ¿Está
usted preparado para abrir la puerta la puerta de emergencia que lo salvará a
usted y a los otros 180 pasajeros en este vuelo en caso de un accidente?
La forma en la que la
historia se cuenta, es fundamental para que los demás se involucren. Es común que
un reporte tenga distintas secciones, en mi opinión, un buen reporte de bug,
debe poder responder ciertas preguntas, las plantillas, los estándares pueden
omitirse si se tiene la responsabilidad de que estas preguntas puedan
responderse dentro de las cuales debe estar:
¿Y si no lo resolvemos?
Esta es justo la
pregunta a la que me refiero. No todas las historias deben ser de terror, pero
si aquellas en las que como testers creemos que se debe poner énfasis, la priorización
de actividades y riesgos es fundamental para elegir nuestras historias.
Para ustedes ¿Qué tan común
es que el reporte de bug que escriben/resuelven pueda contestar esta pregunta?
