Moises Tablas de la Ley
Las Pruebas del Software son una parte básica del ciclo de vida del desarrollo del software pero me atrevo a decir que a la vez es una de las partes más desconocidas.
Sólo se trata de probar, ¿no?
Pues No. Las pruebas del software son mucho más y hay 7 mandamientos que tienes que conocer para realizar unas pruebas satisfactorias.
He estado releyendo un artículo de Tom Cagley de su blog Software Process and Measurement (que te recomiendo desde aqui) llamado Testing Principles Part 1: This is not Pokémon y coincido con él en que mucha gente no tiene en cuenta estos principios, ya bien sea porque los ha olvidado o porque nunca los supo.
Para que no te pase a tí vamos a ver uno a uno los 7 Mandamientos de las Pruebas del Software:
Cuando realizas una batería de pruebas y detectas una serie de errores, nadie te asegura que no existan más errores que la prueba no detecta, sólo sabes que los errores detectados existen.
El número de casos posibles a probar en el Testing de un software puede ser un número muy elevado, probablemente pueda ser infinito, por lo que debes asumir que no se pueden probar todos los casos.
Además, cualquier corrección que apliques al software para solventar incidencias detectadas, añadirá variables nuevas y éstas harán que el número de casos a probar vuelvan a aumentar.
Esto significa que al igual que un pesticida, un conjunto de pruebas detectará los errores para los que fue diseñado pero no encontrará los errores para los cuales no se construyó.
La automatización de la ejecución de los test pierde su valor con el tiempo ya que los errores que detecta no aparecerán pero no nos alertará sobre otros que se hayan introducido y para los cuales no había sido diseñado.
No debemos olvidar que hay una forma de prueba temprana del software. Recordemos los dos tipos de pruebas que se pueden efectuar:
Los errores suelen ocultarse detrás de otros errores, ya que suelen agruparse cuando aparecen. Esto hace que repetir las pruebas sea una inversión en tiempo importante que debe ser tenida en cuenta en el presupuesto del proyecto.
¿Cómo nos ayudarían en esto las herramientas de prueba estática? Pues como lo hace el corrector ortográfico a la hora de escribir en un procesador de texto, marcando lo que no es del todo correcto y haciéndonos ganar tiempo.
Para que las pruebas que se realizan sobre un software sean lo más eficientes y efectivas posibles, deben tener en cuenta el tipo de proyecto y el tipo de producto sobre el cual se realizan.
Por ejemplo, una lista de historias de usuario pueden ser revisadas de forma estática pero no pueden ser testadas de forma dinámica, ya que no tienen código que ejecutar.
Si una batería de pruebas no arroja ningún error, es decir todo ha ido bien, no significa en ningún caso que el software no tenga errores sino que dichas pruebas no lo han detectado.
¿Echas en falta algún otro mandamiento? ¿Añadirías algo más? ¡Deja un comentario!
Este año ha sido complicado. En el sentido de que ha sido un año duro.…
Y el año se acaba. Después de tantos días juntos en este blog hoy llegamos…
Las compañías energéticas están en el ojo del huracán con los precios que estamos sufriendo…
Sin duda hay una creencia muy extendida que piensa que las cosas se consiguen porque…
El Haiku de hoy de Taylor Swift me encanta. Resume perfectamente lo que no debes…
Las ideas innovadoras siempre son interesantes para que nos puedan inspirar. Si además ayudan a…
View Comments
Me ha gustado el artículo.
Quizá añadiría un octavo: el testing es cosa de todos. Demasiadas veces existe la tendencia hacia el volcado de la responsabilidad de testeo a los desarrolladores en exclusiva, ignorando el papel fundamental del rodaje del software en equipos de beta-testers u operarios finales, o la participación activa de los expertos en el campo en el que se desenvuelve el software.
Por otro lado, estos mandamientos se pueden llegar a conocer o incluso darse por obvios, pero la realidad es que no se terminan de asimilar plenamente y con todas sus implicaciones. Por lo general, la actitud de los involucrados -demasiadas veces los mismos técnicos- transmite la idea equivocada de que estos mandamientos "existen", pero son sorteables con "prácticas correctas" o "poniendo mucho cuidado". Esto hace, por ejemplo, que las incidencias que van surgiendo y que entrarían dentro de la normalidad de la evolución contínua de un producto, se vean como un fallo de procedimiento. De ahí se pasa a, en vez de establecer o fortalecer una política de actuación ante el error de software, se entra en bucles interminables de revisiones de procedimientos para evitar lo que es inevitable. La falta de éxito en esta política acaba contribuyendo al malestar de la dirección y la desmotivación de la parte técnica (tanto los que tienen asimilados los 'mandamientos' como los que no)
E importante: tampoco contribuye a educar a los clientes, que acaban siendo perpetuados en falacias (como, p.e, la que hace referencia séptimo mandamiento: "el software sin errores es posible").
Adrià gracias por tu magnifica exposición. Te tomo el 8º mandamiento para un futuro artículo, me parece de los más acertado.
La situación que describes es la realidad, creer que "de cierta forma" se puede pasar de puntillas por la realidad de las pruebas y que éstas no son tan necesarias.
A mí me sigue llamando la atención cuando en producción algo falla y esa misma persona que dijo que se pasara de puntillas por las pruebas se echa las manos la cabeza y pronuncia esa famosa frase de: ¿Pero no lo hemos probado?
Real como la vida misma
Me gustó mucho el articulo, está muy claro para los que recién nos incorporamos al mundo del Testing, además el 8° mandamiento lo comparto 100%, gracias por tu tiempo de escribir y se espera mas articulos como este.
Slds.
Gracias a ti por el comentario y bienvenido Patricio!
Otro mandamiento: Hay que probar que el sistema no hace lo que debe, y que hace lo que no debe