Los resultados positivos de las pruebas negativas
Como testers de software e ingenieros de automatización, a menudo pensamos en el camino feliz: el recorrido que el usuario probablemente seguirá cuando use nuestra aplicación. Cuando escribimos nuestras pruebas automatizadas de UI queremos asegurarnos de estar automatizando esos caminos felices, y cuando escribimos automatización de API queremos verificar que cada endpoint devuelva una respuesta “200 OK” o alguna otra respuesta exitosa similar.
Pero es importante pensar en las pruebas negativas, tanto en nuestras pruebas manuales como automatizadas. Aquí hay algunas razones por las que debemos hacerlo.
Nuestras pruebas automatizadas pueden estar pasando por razones equivocadas
Cuando comencé a escribir pruebas automatizadas de UI en JavaScript, no entendía el concepto de promesa. Simplemente asumía que al solicitar un elemento, no se devolvería hasta que realmente se hubiera localizado. Me sentí muy emocionada cuando mis pruebas arrojaban el resultado verde de “Pasó”, hasta que un compañero sugirió que intentara hacer que la prueba fallara comprobando un valor distinto. Volvió a pasar porque en realidad estaba validando contra la promesa existente, que siempre devolvía “Verdadero”. Eso me enseñó algo muy valioso: nunca asumas que tus pruebas automatizadas funcionan correctamente solo porque pasan. Asegúrate de ejecutar algunos escenarios en los que tus pruebas deberían fallar, y verifica que efectivamente fallen. De esta manera, puedes estar segura de que realmente estás probando lo que crees que estás probando.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Las pruebas negativas pueden exponer errores mal gestionados que podrían afectar al usuario
En las pruebas de API, cualquier error relacionado con el cliente debe resultar en una respuesta de nivel 400 y no en un error de servidor de nivel 500. Si realizas pruebas negativas y descubres que una respuesta 403 ahora se devuelve como 500, esto podría significar que el código ya no está manejando correctamente ese caso de uso. Una respuesta 500 del servidor podría impedir que el usuario obtenga la información adecuada para corregir su error, o peor aún, podría hacer que la aplicación se bloquee.
Las pruebas negativas pueden encontrar fallos de seguridad
Tan importante como asegurarnos de que un usuario puede iniciar sesión en una aplicación es verificar que no pueda iniciar sesión cuando no debería hacerlo. Si solo ejecutas una prueba de inicio de sesión con un nombre de usuario y contraseña válidos, ¡estás dejando de lado un aspecto fundamental! He visto situaciones donde un usuario podía iniciar sesión con cualquier cosa como contraseña, situaciones en las que podía iniciar sesión con la contraseña en blanco o incluso con nombre de usuario y contraseña incorrectos.
También es crucial verificar que ciertos usuarios no tengan acceso a partes específicas de una aplicación. Tener una página de administración cuidadosamente probada y funcional no servirá de mucho si resulta que cualquier usuario aleatorio puede acceder a ella.
Las pruebas negativas mantienen limpia tu base de datos
Como mencioné en el Capítulo 12, tener buenos datos válidos en tu base de datos ayudará a mantener saludable tu aplicación. Los datos que no se ajustan a las expectativas pueden provocar que las páginas web se bloqueen, no se carguen o que la información se muestre incorrectamente. Cuantas más pruebas negativas puedas realizar en tus entradas, más te asegurarás de tener solo datos correctos.
En cada campo de entrada del que soy responsable de probar, me gusta saber exactamente qué caracteres están permitidos. Así puedo ejecutar una gran cantidad de pruebas negativas para asegurarme de que las entradas con caracteres prohibidos sean rechazadas.
A veces los usuarios toman el camino negativo
Es muy fácil, especialmente con una nueva función que se lanza apresuradamente para cumplir un plazo, olvidar probar los caminos del usuario donde harán clic en el botón Cancelar o Eliminar. Pero los usuarios hacen esto constantemente; piensa en las veces que has pensado en realizar una compra en línea y luego cambiaste de opinión, eliminando un artículo de tu carrito. Imagina tu frustración si no pudieras quitar algo de tu carrito o si un botón Cancelar no vaciara un formulario para que puedas comenzar de nuevo. La experiencia del usuario en este aspecto es tan crucial como el camino feliz.
Las pruebas de software se tratan de buscar comportamientos inesperados para encontrarlos antes que el usuario lo haga. Cuando las pruebas negativas se combinan con las de camino feliz, podemos asegurar que nuestros usuarios no se llevarán sorpresas desagradables.
Si buscas optimizar aún más tus procesos de pruebas, considera integrar una herramienta de gestión de bases de datos de primer nivel para gestionar tus necesidades complejas de datos.
El libro The Complete Software Tester
Cuando descubrí mi pasión por el testing de software en 2009, quería aprender todo lo posible sobre el tema, pero encontré muy pocos libros que pudieran enseñarme. Terminé aprendiendo por prueba y error, leyendo publicaciones en blogs y conversando con mis compañeros de trabajo. Hoy existen excelentes libros sobre áreas específicas de testing, como el testing exploratorio, el testing ágil y la automatización de pruebas, pero no conozco ningún libro que busque ser una referencia completa sobre pruebas de software.
Escribí The Complete Software Tester porque quería ofrecer tanto a testers nuevos como experimentados las ideas y herramientas que necesitan para ser lo más eficaces posible. Para consejos rápidos de QA y más recomendaciones de libros, suscríbete al boletín de The QA Lead.
Lectura relacionada: ¿QUÉ ES ZEPHYR SCALE?
Lista relacionada de herramientas:
- SOFTWARE DE PRUEBAS DE RENDIMIENTO PARA EQUIPOS DE QA
- HERRAMIENTAS DE AUTOMATIZACIÓN DE PRUEBAS ETL PARA EQUIPOS DE QA
También vale la pena revisar:
