Cuando un equipo de pruebas se incorpora a tu proyecto, lo primero que pedirá son tus requisitos. Esa petición suena vaga cuando lo que tienes son especificaciones antiguas, unos cuantos tickets y conocimiento que vive en la cabeza de las personas. Los requisitos de pruebas de software son las descripciones escritas de lo que tu producto debería hacer, lo bastante claras como para que alguien ajeno a tu equipo pueda comprobar el resultado.
Cubren las funcionalidades que estás construyendo, las reglas de negocio que hay detrás y las condiciones que deciden si algo funciona. Los testers los leen para aprender qué cuenta como correcto.
Sin embargo, “tener requisitos” y “tener requisitos contra los que alguien pueda probar” son dos cosas distintas. Muchos equipos tienen documentos que describen el producto con precisión y aun así dejan al tester sin forma de demostrar que una funcionalidad funciona. De esa diferencia trata esta guía, porque decide con qué rapidez arrancan tus pruebas y cuánto de ellas se apoya en conjeturas.
Verás qué documentos usan realmente los testers, qué hace que un requisito sea verificable, cómo revisa un equipo de QA los que le envías y por dónde empezar cuando no existe ninguno. Si esto último te suena familiar, nuestros servicios de redacción técnica cubren exactamente esa brecha.
¿Qué Requisitos de Pruebas de Software Necesita un Equipo de QA?
La mayoría de los equipos entregan las especificaciones y los tickets que ya tienen y esperan que sea suficiente. Normalmente no lo es, aunque la carencia rara vez está donde esperan. Cuatro documentos llevan la información que los testers necesitan, y probablemente ya tengas dos de ellos:
- SRS, la especificación de requisitos de software. Es el documento detallado, que enumera cada funcionalidad y describe cómo debería comportarse.
- BRD, el documento de requisitos de negocio. Se sitúa por encima del SRS y explica por qué existe el producto y a quién sirve.
- Historias de usuario y casos de uso. Abordan lo mismo desde el lado de la persona, mostrando qué intenta conseguir alguien.
- Criterios de aceptación. Son los más breves y a menudo los más útiles, un puñado de condiciones que zanjan si una funcionalidad está terminada.
SRS
Cómo debería comportarse cada funcionalidad
Analista de negocio o product owner
Los testers adivinan el comportamiento previsto y luego reportan funcionalidades correctas como errores
BRD
Por qué existe el producto y a quién sirve
Responsables de negocio
El esfuerzo se reparte por igual en lugar de proteger lo que te da dinero
Historias de usuario y casos de uso
Qué intenta lograr una persona
Product owner, junto con el equipo
La cobertura sigue pantallas en lugar de recorridos reales, así que los caminos rotos sobreviven
Criterios de aceptación
Las condiciones que zanjan si una funcionalidad está lista
Product owner, refinado con QA
Cada release termina en una discusión sobre si el trabajo está terminado
No necesitas los cuatro para empezar. Un conjunto claro de criterios de aceptación hace más por un tester que una especificación de cien páginas que nadie ha abierto desde el año pasado. Lo que importa es que alguien ajeno a la conversación pueda leer tus requisitos de pruebas de software y saber qué comprobar.
También hay un estándar oficial detrás de todo esto. ISO/IEC/IEEE 29148, actualmente en su edición de 2018, cubre cómo deberían escribirse los requisitos y qué debería contener una especificación. Es casi seguro que no necesitas leerlo, y la mayoría de los equipos nunca lo hace. Conviene saber que existe, porque un auditor, un regulador o un gran cliente corporativo puede preguntarte qué estándar siguen tus requisitos.
¿Qué Hace que un Requisito Sea Verificable?
Un requisito es verificable cuando una persona que no lo escribió puede leerlo, comprobar el producto y llegar a la misma conclusión que todos los demás. Suena obvio, pero se pierde porque quien lo escribió ya sabe lo que quería decir, así que los huecos le resultan invisibles.
Esta es la diferencia en la práctica.
La aplicación debería cargar rápido.
La lista de productos aparece en menos de 3 segundos con una conexión móvil normal.
Los usuarios deberían poder restablecer su contraseña.
El correo de restablecimiento llega en menos de 2 minutos y el enlace deja de funcionar a las 24 horas.
El checkout debería gestionar los errores con elegancia.
Si una tarjeta es rechazada, el carrito conserva sus artículos, no se mueve dinero y el comprador ve el motivo.
Fíjate en lo que cambió: cada versión verificable nombra algo que una persona puede observar y sobre lo que puede estar de acuerdo. Ninguna necesitaba más detalle técnico, solo una decisión que alguien tenía que tomar tarde o temprano.
Tres preguntas te dirán si un requisito está listo:
- ¿Puedes describir cómo es “que funcione” sin las palabras bueno, rápido o fácil?
- ¿Dos personas que lo leyeran esperarían el mismo resultado?
- ¿Puede alguien comprobarlo sin preguntarle al autor qué quiso decir?
Responde sí a las tres y el requisito se convierte casi directamente en un caso de prueba, que es donde suele empezar nuestro trabajo de pruebas funcionales.
¿Cómo Revisa un Equipo de QA Tus Requisitos?
Antes de que nadie ejecute una sola prueba, un buen equipo de QA lee lo que le enviaste y vuelve con preguntas. Esa revisión es rápida y evita mucho trabajo desperdiciado después.
Un revisor busca un conjunto concreto de problemas:
- Qué debería pasar cuando algo falla, ya que la mayoría de los documentos describen solo el éxito
- Situaciones que nadie mencionó, como una cuenta vacía, un visitante que llega por primera vez o una tarjeta caducada
- Dos documentos que dicen cosas distintas sobre la misma funcionalidad
- Reglas sin ningún número asociado, como rápido, seguro o fácil de usar
- Quién tiene permiso para hacer qué, cuando nadie lo ha puesto por escrito
Cada punto de esa lista se convierte en una pregunta para tu equipo. Responder una mientras los documentos todavía se están escribiendo es rápido. La misma pregunta después del lanzamiento significa cambiar código, volver a ejecutar las pruebas y explicar el retraso a quien reportó el problema.
Conviene separar algunos términos relacionados. Los requisitos son el punto de partida de las pruebas. Los objetivos de las pruebas de software son su finalidad. Comprobar tu producto contra esos documentos se llama verificación, y confirmar que resuelve el problema correcto es validación. Explicamos la diferencia en verificación vs validación en pruebas de software.
Por Qué No Deberías Esperar a la Documentación Final
Los equipos suelen frenar a QA hasta que el papeleo está terminado. Sin embargo, en un producto que todavía se está construyendo, nunca llega a estarlo del todo.
Esperar te cuesta dos veces:
- Las contradicciones sobreviven. Un conflicto entre dos documentos pasa desapercibido hasta que alguien escribe código basándose en él, y para entonces arreglarlo significa reconstruir en lugar de editar.
- Pierdes a tu mejor lector. Un ingeniero de QA que repasa una especificación a medio escribir detectará las piezas que faltan por pura costumbre.
Así que entrega lo que existe hoy, por parcial que sea. Los testers pueden empezar a construir comprobaciones a partir de las partes ya cerradas mientras el resto se pone al día, y sus preguntas alimentan directamente los documentos que sigues escribiendo.
Por eso nos incorporamos a los proyectos en la fase en la que estén, en lugar de esperar a un traspaso terminado. Nuestra guía sobre pruebas ágiles muestra cómo funciona esto sprint a sprint, y nuestro recorrido por las fases de las pruebas de software cubre las etapas por las que pasa el propio trabajo.
Qué Hacer Cuando Tus Requisitos Están Incompletos
Muchos productos llegan hasta nosotros casi sin nada escrito. Es normal, sobre todo cuando el equipo que construyó la primera versión ya no está. Tienes más materia prima de la que crees.
- Escribe lo que el producto hace ahora. En un producto en funcionamiento, el comportamiento actual es una fuente legítima, y confirmarlo es mejor que inventarlo desde cero.
- Empieza por los recorridos que generan ingresos. El registro, el checkout y la renovación merecen condiciones escritas mucho antes que una pantalla de ajustes.
- Convierte lo que la gente sabe en criterios de aceptación sobre la marcha. Cada respuesta que alguien da en una reunión es un requisito esperando a ser capturado.
- Guarda esas decisiones en un sitio localizable. Una página compartida es mejor que un hilo de chat, que es mejor que la memoria de una sola persona.
Ese trabajo es de redacción más que de pruebas, así que la mayoría de los proveedores de QA te lo devolverá directamente y esperará. Nosotros, en cambio, escribimos los documentos que faltan y después probamos contra ellos, lo que te ahorra pagar a dos empresas para que se pongan de acuerdo entre sí.
Así funcionó el proyecto de Logo Maker Shop. Su versión para Android llegó hasta nosotros sin ninguna documentación de pruebas, y las reglas que sí existían estaban dispersas como comentarios en pantallas de Figma. Reconstruimos el resto a partir de cómo ya se comportaba la app de iOS, fuimos pidiendo lo que faltaba sobre la marcha y escribimos 270 casos de prueba desde cero.
Cómo QAwerk Cierra la Brecha de Requisitos
Unos requisitos de pruebas de software claros compensan por una razón puramente comercial. Reducen las horas que tu equipo dedica a explicar el producto, disminuyen los defectos que resultan ser malentendidos y acaban con la discusión sobre si una funcionalidad está terminada. Los requisitos verificables son lo que hace posibles esas tres cosas.
Cuando tus documentos se quedan cortos, cerramos la brecha en tres pasos. Primero leemos lo que tienes y volvemos con las preguntas que plantea. Después ponemos por escrito las piezas que faltan, para que tus casos de prueba nazcan de un documento y no de una suposición. Mientras tanto, las pruebas arrancan sobre lo que ya está acordado y crecen desde ahí. Lo hemos hecho en más de 300 proyectos, con más de 30 ingenieros de QA senior en el equipo que promedian 9 años de experiencia cada uno.
Si no tienes claro si lo que tienes es suficiente para probar, reserva una llamada con nuestro equipo de QA y revisaremos tus documentos antes de que te comprometas a nada.
FAQ
¿Qué son los requisitos de pruebas de software?
Los requisitos de pruebas de software son aquello a partir de lo cual trabaja un equipo de QA, normalmente una especificación, un documento de negocio, historias de usuario, criterios de aceptación o alguna mezcla de todo eso. Su función es declarar qué debería hacer el producto en términos lo bastante precisos como para que un tester pueda decidir, sin preguntar a nadie, si un resultado dado es correcto o es un defecto.
¿Qué es un SRS en pruebas?
Un SRS, o especificación de requisitos de software, es el documento extenso que expone cada funcionalidad en detalle. Usar un SRS para probar significa que cada resultado esperado se remonta a una línea escrita, así que un tester puede distinguir un defecto real de algo construido así a propósito. Los equipos que trabajan en sprints cortos suelen saltárselo y apoyarse en historias de usuario más criterios de aceptación.
¿Qué hace que un requisito sea verificable?
Fíjate en los adjetivos. Rápido, seguro, intuitivo y fácil de usar describen una opinión más que un resultado, así que dos personas los juzgarán de forma distinta. Una versión verificable pone algo medible en su lugar: un tiempo de carga, una regla de permisos o los pasos exactos que una persona completa. Reescribir uno suele llevar una frase, y elimina una discusión que de otro modo tendrías en el lanzamiento.
¿Se pueden iniciar las pruebas sin requisitos completos?
Sí, y aguantar hasta tener documentos completos suele costar más que empezar pronto. Un equipo de QA puede trabajar a partir de especificaciones parciales, del comportamiento actual del producto y de conversaciones con quienes mejor lo conocen. La revisión saca a la luz los huecos por ti, que es más rápido que escribirlo todo primero y encontrar las contradicciones después.
¿Quién escribe los criterios de aceptación?
Normalmente el product owner los redacta y luego los refina con los desarrolladores y testers que trabajarán con ellos. Escribirlos en solitario es el error habitual, porque las condiciones tienden a cubrir solo el caso en que todo funciona. Una revisión breve con QA añade las que ese primer borrador se deja, y ahí es donde empiezan de verdad casi todos los desacuerdos sobre lo que está terminado.
Gratis para Ti: Plantilla de Casos de Prueba
