He tenido muchos problemas para obtener errores/tareas con la información correcta en ellos. Y otros puntos en los que se entrega una tarea a lo largo del flujo de trabajo requieren que el destinatario obtenga cierta información.
Para la reunión de mañana, nuestro PM nos ha pedido que identifiquemos qué listas de verificación necesitamos crear y qué creemos que debería estar en ellas.
Como desarrollador, sé lo que necesito cuando obtengo tareas del BA
Normalmente solo recibo una descripción vaga y necesito pedir estas cosas... Las recibo verbalmente, ya veces se escriben, a veces no... pero dado que siempre se necesitan, deben proporcionarse por adelantado. Es por eso que queremos incorporar una lista de verificación que el comunicador debe verificar dos veces antes de pasar una tarea.
Nuestro flujo de trabajo normalmente es el siguiente
Cualquiera puede identificar un problema para el BA.
BA crea la tarea y pasa a PM para su aprobación.
PM asigna la tarea al desarrollador.
El desarrollador pasa a Tech Lead para Tech Review.
Tech Lead pasa a control de calidad.
QA pasa a PM para la aprobación de la implementación.
PM asigna al líder técnico para la implementación.
El líder técnico pasa de nuevo a BA o QA para Health Check.
¿Cuáles creen que deberían ser elementos obligatorios en una lista de verificación en estos puntos de contacto? He añadido lo que creo que son necesarios. Agrego puntos desde la perspectiva del destinatario, no significa que el comunicador sea quien lo proporcione, pero deben asegurarse de que esté allí antes de continuar.
Creo que sus elementos iniciales del 1 al 4 lo resumen bastante para el 99% de todas las organizaciones. El problema es que a pesar de que les dice a sus evaluadores "qué" información se necesita, encuentro que el contenido suele ser muy pobre (ortografía, poco claro, etc.).
En cuanto a otros elementos de la lista de verificación, probablemente dependerá de su empresa real y del producto que se está probando (modelo/revisión de hardware), versión de firmware, etc.
Pero una cosa que me gusta (o animo encarecidamente) que la gente haga es mantenerlo en forma de oración innumerada 'simple', como:
A. Post Conditions:
1. Screen 'Some Name' has been loaded
2. The 'Some Name' panel is showing along with the proper ID label
B. Steps To Reproduce:
1. Select the ID label
2. Start typing another label ID
3. [...]
De esta manera, mantiene las cosas organizadas de manera muy simple, paso a paso (en comparación con un montón de texto en forma de párrafo).
Además, en el informe de error, es mucho más fácil hacer referencia a un paso diciendo "¿Puedes dar más detalles sobre el paso B.2?" en lugar de tratar de referirse a un paso específico en una parte de un párrafo, especialmente si el elemento referido se repite varias veces.
Cuando alguien quiere aportar su granito de arena, también puede escribir:
Try this workaround:
B.2.a. Select the existing ID
B.2.b. Press on the 'clear' key
Al instante, queda claro para todos dónde se sugiere la recomendación. Y nuevamente, todo está en forma de punto en lugar de párrafos.
Personalmente, considero que las listas de verificación son un poco peligrosas porque son difíciles de cambiar y veo lo que debería estar allí, pero generalmente no tengo idea de lo que falta.
Si yo fuera usted, escribiría un script que podría recopilar toda la información que necesito para solucionar el problema: archivos de registro, información del sistema y capturas de pantalla. Si tiene un script, ya no depende de la interacción humana innecesaria y los posibles errores. Si tiene una lista de verificación, el escritor del problema puede olvidar algo y debe preguntar. Un guión no olvida. Redujimos nuestro tiempo de respuesta en 3 días usando un script como este.
Lo siguiente que haría sería escribir los pasos en formato pepinillo :
Given I am on the login page
When I enter my password
Then I want to see its strength
Puede usar estos pasos para escribir escenarios pepino que se pueden ejecutar contra el sistema. Usamos este enfoque cuando lidiamos con defectos. Cuando encontré un problema, escribí mi escenario y me comprometí con el control de versiones. El desarrollador que realizó la tarea y comenzó a trabajar en el problema. Sabía que cuando el escenario se volvía verde, estaba arreglado. Así que puedes usar estos escenarios para
caffgeek