Siguenos en:

jueves, 12 de mayo de 2016

Someto a la aprobación de la sociedad de la media noche, esta historia a la que llamo. . . . . . . . . El bug



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?