Cómo trabajan los testers sin requisitos: estrategias probadas
Evita preguntas abiertas como "¿Dónde va una publicación tras su creación?". Estas invitan a explicaciones largas y confusas. En su lugar, opta por opciones definidas: "¿La publicación aparece en el feed del usuario, en el feed de la comunidad, en ambos o en ninguno?"
Esto acelera la comunicación: las respuestas son rápidas (sí/no) o selecciones entre opciones predefinidas. Aplica esta técnica para aclarar comportamientos en escenarios específicos: estados, roles, casos extremos.
Regla 2: Visualiza las transiciones de estado
Muestra, no digas. Dibuja tablas de transición de estado para flujos complejos. Ejemplo: una orden de $500, una publicación automática, 20 quejas. ¿Qué ocurre? ¿Se elimina la publicación? ¿Y si no hay quejas?
Estas tablas cubren eventos comunes y raros. Generan preguntas recurrentes, agrupándolas en una sola consulta clara, ahorrando tiempo a todos.
Tabla ejemplo para un huésped ruidoso (factura bajo $200):
| Evento | Acción |
|--------|--------|
| Ruido del huésped con factura < $200 | Alerta | Ignorar |
| Quejas > 5 | Advertencia | Evacuar |
Regla 3: Matrices CRUD para cobertura total
Para trabajo backend, crea matrices de operaciones CRUD por rol y condiciones. Los desarrolladores manejan flujos principales (por ejemplo, bloquear la eliminación de contenido ajeno, protección contra inyección SQL), pero los casos extremos son responsabilidad de QA.
Estas matrices ayudan no solo en pruebas, sino también en la mejora del código. Comparte las matrices con los equipos backend antes del inicio de cada sprint: "¿Esto está cubierto, o debemos añadirlo?"
Matriz CRUD de ejemplo para publicaciones:
| Rol | Crear | Leer | Actualizar | Eliminar | Condiciones |
|-----|-------|------|------------|----------|-------------|
| Usuario | 200 - propia<br>400 - ajena | 200 - propia<br>200 - ajena | 200 - propia<br>400 - ajena | 200 - propia<br>400 - ajena | Solo sus propias publicaciones |
| Moderador | 403 | 200 | 200 | 200 | Si existen quejas |
| Administrador | 200 | 200 | 200 | 200 | Sin restricciones |
- Crear: Verifica acceso por rol y límites.
- Leer: Revisa filtros, paginación, caché.
- Actualizar/Eliminar: Asegúrate de atomicidad y efectos en cascada.
Tras 2–3 iteraciones, los equipos backend empiezan a solicitar estas listas durante la planificación de tareas.
Conclusiones clave
- Las preguntas cerradas reducen el ruido y enfocan en detalles cruciales.
- Las tablas de transición de estado y las matrices CRUD revelan el 80% de los requisitos implícitos visualmente.
- Compartir listas de verificación con desarrolladores acelera el ciclo: de tarea a prueba.
- Los requisitos implícitos son normales; recopilarlos forma parte del trabajo de un ingeniero de calidad.
- Delega la edición de requisitos a analistas: ellos tienen el contexto del producto.
Conclusión: Delega las ediciones
Los requisitos faltantes no son un problema: son la norma. Estas tres reglas transforman el caos en estructura. Regla final: no escribas requisitos tú mismo. Pásalos a los analistas. Ellos gestionan la propiedad del feature y mantienen el contexto. Así, el equipo permanece alineado y eficiente.
— Editorial Team
Aún no hay comentarios.