No es posible probar todo

Si nos preguntamos ¿cuántas pruebas podríamos ejecutar para una funcionalidad? … depende de muchas variables:

• Cuántos datos tengo que poner en cada pantalla
• Cuántos valores distintos puedo poner en cada campo de la pantalla
• ¡¡¡cómo combinar esos datos!!!
• Además, puedo ejecutar en distintos navegadores, en distintos celulares, sistemas operativos, etc., etc.

Entonces la respuesta es: ¡infinitos casos!

Claramente, no tenemos tiempo para probar todo.

La forma en la que los testers estaremos aportando calidad al software es principalmente buscando fallos. Por supuesto. Digamos que si no encuentro fallo todo el costo del testing me lo pude haber ahorrado. ¿No? ¡Nooo! Porque si no encontramos fallos entonces tenemos más confianza en que los usuarios encontrarán menos problemas.

¿Se trata de encontrar la mayor cantidad de fallos posible? ¿Un tester que encuentra cien fallos en un día hizo mejor su trabajo que uno que apenas encontró 15? De ser así, la estrategia más efectiva sería centrarse en un módulo que esté más verde, que tenga errores más fáciles de encontrar, me centro en diseñar y ejecutar más pruebas para ese módulo, pues ahí encontraré más fallos.

¡NO! La idea es encontrar la mayor cantidad de fallos que más calidad le aporten al producto. O sea, los que al cliente más le van a molestar.

¡Ojo!, el objetivo no tiene por qué ser el mismo a lo largo del tiempo, pero sí es importante que se tenga claro en cada momento cuál es. Puede ser válido en cierto momento tener como objetivo del testing encontrar la mayor cantidad de errores posibles, entonces seguramente el testing se enfoque en las áreas más complejas del software o más verdes. Si el objetivo es dar seguridad a los usuarios, entonces seguramente se enfoque el testing en los escenarios más usados por los clientes.

Existen distintas técnicas de diseño de casos de prueba, que permiten seleccionar la menor cantidad de casos con mayor probabilidad de encontrar fallas en el sistema. Por este motivo, estos casos se consideran los más interesantes para ejecutar, ya que el testing exhaustivo (ver definición o ejemplo) no solo es imposible de ejecutar en un tiempo acotado, sino que también es muy caro e ineficiente. Es así que se vuelve necesario seleccionar de una forma inteligente los valores de entrada que tengan más posibilidades de descubrir un error.