En su artículo Software Process and Measurement, Tom Cagley habla sobre puntos que se olvidan que casi nunca se hablan cuandos se va a desarrollar un software, y estoy seguro que cualquier desarrollador de software básico, intermedio o avanzado coincidirá.
1 - Los testeos sólo confirman la existencia de los errores que encuentran.
Cuando realizas un conjunto de pruebas y se detectan una serie de errores, nadie te asegura que no existan más bugs en el software que el conjunto de prueba no detecta, sólo sabes que los errores detectados existen.
2 - Es imposible, casi infinito, probar todos los casos posibles.
El número de casos posibles a probar para encontrar errores en el Testing de un software puede ser un número 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 encontrada en la batería de pruebas para solventar bugs detectados, añadirá variables nuevas y éstas harán que el número de casos a probar vuelva a aumentar. ¡Triste pero cierto!
3 - La Paradoja del Pesticida: La eficacia de tu batería de pruebas en busca de errores disminuye con el paso del tiempo
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.
4 - Los bugs se ocultan detrás de otros bugs.
Los bugs suelen ocultarse detrás de otros bugs, ya que suelen agruparse cuando aparecen. Esto hace que repetir las pruebas sea una inversión en tiempo que debe ser tenida en cuenta en el presupuesto del inicial del proyecto.
5 - Un software sin errores es una mentira.
Si una batería de pruebas en tu fase de Testing no arroja ningún error o Bug, es decir todo ha ido bien, no significa en ningún caso que el software no presente errores es mas bien que en dichas pruebas no han sido capaz de detectarlos. No existe software sin errores.
Por ultimo cito una frase que no recuerdo donde leí pero es muy cierta.
"Un software que no presenta errores, seguramente es un software que nadie usa."
Fuente del artículo
https://tcagley.wordpress.com/2014/05/15/testing-principles-part-1-this-is-not-pokemon/
