Prueba de características

¿Qué es la prueba de características?

La prueba de características (feature testing) consiste en comprobar que una función concreta de un producto de software, como la búsqueda, el pago o un nuevo botón de exportación, hace lo que dicen sus requisitos, de principio a fin, antes y después del lanzamiento. Cubre el caso normal, los datos no válidos, los permisos y la interacción con el resto del producto. Es más acotada que probar toda la aplicación y más amplia que una prueba unitaria.

Cómo funciona

1. Anota lo que debe hacer la función: criterios de aceptación, entradas, salidas, roles que pueden usarla.
2. Deriva casos de prueba: uso normal, valores límite, datos erróneos, falta de permisos, acciones interrumpidas.
3. Ejecútalos sobre una versión en un entorno de pruebas, primero a mano y después automatizados donde se repitan.
4. Revisa lo cercano: otras funciones que comparten datos o pantallas con ella.
5. Corrige, vuelve a probar y conserva los casos útiles como suite automatizada.

Qué cubre una prueba de características

• Funcionalidad: se comporta como se especificó, incluidos los mensajes de error y los estados vacíos.
• Integración: funciona con la base de datos, el proveedor de pagos u otros servicios a los que llama. Para interfaces HTTP, consulta las pruebas de API.
• Usabilidad y accesibilidad: las personas pueden completarla, también con teclado y tecnologías de apoyo. Mira las pruebas de accesibilidad automatizadas y las pruebas manuales de accesibilidad.
• Rendimiento: sigue siendo aceptable con una carga realista. Una función que pasa las pruebas funcionales puede ser demasiado lenta con muchos usuarios a la vez.
• Seguridad básica: comprobaciones de autorización y tratamiento de entradas de esa función.

Un ejemplo sencillo

Un equipo añade "exportar resultados a CSV". Las pruebas comprueban que el archivo se abre con las columnas correctas, que un resultado vacío da un mensaje claro, que un usuario con rol de solo lectura no exporta lo que no puede ver, que los caracteres especiales se conservan y que una exportación de 100 000 filas termina en lugar de agotar el tiempo. Después se vuelve a probar cada vez que cambia la página de resultados, lo que se conoce como pruebas de regresión.

Pruebas de características, lanzamiento y producción

Los equipos suelen lanzar una función detrás de un interruptor para probarla con tráfico real sin riesgo: consulta los feature flags y el despliegue progresivo de funciones. Tras el lanzamiento, las comprobaciones automáticas siguen vigilándola. La monitorización de API de LoadFocus puede llamar a los endpoints de la función de forma programada y avisar de los fallos, y las pruebas de carga muestran cómo se comporta con muchos usuarios a la vez. Para ver un ejemplo de cómo detectar una ralentización entre versiones, lee detectar una regresión de rendimiento con pruebas automatizadas (en inglés).

Errores comunes

• Probar solo el caso ideal.
• No escribir criterios de aceptación, de modo que nadie sabe qué significa "funciona".
• Probar la función aislada y no ver lo que rompe en otros sitios.
• Dejar el rendimiento y la accesibilidad para después del lanzamiento.
• Depender de repeticiones manuales para algo que cambia en cada versión.

Preguntas frecuentes

¿Qué diferencia hay entre la prueba de características y la prueba funcional?

La prueba funcional comprueba que el software hace lo que dicen los requisitos. La prueba de características lo aplica a una función concreta cada vez. En la práctica los términos se solapan mucho.

¿La prueba de características es lo mismo que la de regresión?

No. La primera verifica que una función trabaja como se especificó. La de regresión repite pruebas existentes tras un cambio para confirmar que no se ha roto nada que funcionaba.

¿Deben ser manuales o automatizadas?

Ambas. Explora a mano mientras la función es nueva y poco clara, y automatiza después los casos que repetirás en cada versión.

¿Quién escribe las pruebas de características?

Depende: los desarrolladores escriben pruebas unitarias y de integración, QA las de extremo a extremo y el responsable de producto aporta los criterios de aceptación. Lo importante es que los criterios existan antes de probar.

¿Es lo mismo que las pruebas A/B?

No. La prueba de características comprueba que una función funciona. Las pruebas A/B comparan dos variantes con usuarios reales para ver cuál rinde mejor según una métrica.