Escribí la mayor parte de Testing Computer Software hace más de 25 años. Desde entonces, he señalado varias partes del libro que considero obsoletas o simplemente erróneas. Ver http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Puede ver más (vistas actuales, pero sin punteros explícitos de regreso a TCS) en mi sitio para el Curso de pruebas de software de Black Box (videos y diapositivas disponibles de forma gratuita), www.testingeducation.org/BBST
La cultura de prueba en ese entonces era en gran medida confirmatoria.
En las pruebas modernas, el enfoque de las pruebas unitarias es en gran medida confirmatorio: escribimos grandes colecciones de pruebas automatizadas que simplemente verifican que el software continúa funcionando según lo previsto. Las pruebas sirven como detectores de cambio: si algo en otras partes del código y esta parte ahora tiene problemas, o si los valores de datos que antes eran imposibles en el mundo real ahora están llegando a la aplicación, entonces los detectores de cambio se disparan, alertando al programador a un problema de mantenimiento.
Creo que la mentalidad confirmatoria es apropiada para las pruebas unitarias, pero imagine un mundo en el que todas las pruebas del sistema fueran confirmatorias (para las personas que hacen una distinción, por favor interpreten "prueba de integración del sistema" y "prueba de aceptación" como se incluye en mis comentarios sobre el sistema prueba.) El punto de prueba era confirmar que el programa cumplía con sus especificaciones y el enfoque dominante era construir un trillón (o al menos unos cientos) de pruebas de regresión a nivel de sistema que asignaran partes de la especificación a los comportamientos del programa. (Creo que la confirmación de especificación a comportamiento es útil, pero creo que es una pequeña porción de un objetivo más amplio).
Todavía hay grupos de prueba que operan de esta manera, pero ya no es la vista dominante. En aquel entonces, lo era. Escribí enfáticamente y dibujé contrastes agudos para señalar a las personas que constantemente estaban siendo entrenadas en esta mentalidad. Hoy, algunos de los agudos contrastes (incluido el citado aquí) están desactualizados. Se malinterpretan como ataques a las opiniones equivocadas.
A mi entender, las pruebas de software son un proceso empírico para aprender información relacionada con la calidad sobre un producto o servicio de software.
Una prueba debe estar diseñada para revelar información útil.
En aquel entonces, por cierto, nadie hablaba de las pruebas como método para revelar "información". En aquel entonces, la prueba era para (alguna versión de ...) encontrar errores o para (alguna versión de ...) verificar (verificar) el programa contra las especificaciones. No creo que la afirmación de que las pruebas son para revelar información útil entró en el vocabulario de pruebas hasta este siglo.
Imagine pruebas de calificación en términos de su valor de información. Una prueba que es muy probable que nos enseñe algo que no sabemos sobre el software tendría un valor de información muy alto. Una prueba que es muy probable que confirme algo que ya esperamos y que ya se ha demostrado muchas veces antes, tendría un valor de información bajo. Una forma de priorizar las pruebas es ejecutar pruebas de mayor valor de información antes de pruebas de menor valor de información.
Si simplificara demasiado esta priorización para atraer la atención de un programador, gerente de proyecto o gerente de procesos que no tiene ni idea acerca de las pruebas de software, diría "UNA PRUEBA QUE NO ESTÁ DISEÑADA PARA REVELAR UN ERROR ES UNA PÉRDIDA DE TIEMPO ". No es una traducción perfecta, pero para los lectores que no pueden entender o no entenderán ninguna sutileza o calificación, eso es lo más cercano a lo que va a llegar.
En aquel entonces, y lo veo nuevamente aquí, algunas de las personas que no entienden las pruebas responderían que una prueba diseñada para encontrar casos de esquina es una pérdida de tiempo en comparación con una prueba de un uso importante de una función principal. No entienden dos cosas. Primero, cuando los probadores encuentran tiempo para verificar los valores límite, los usos principales de las funciones principales ya se han ejercido varias veces. (Sí, hay excepciones, y la mayoría de los grupos de prueba prestarán mucha atención a esas excepciones). En segundo lugar, la razón para probar con valores extremos es que es más probable que el programa falle con valores extremos. Si no falla en el extremo, prueba otra cosa. Esta es una regla eficiente. Por otro lado, si falla en un valor extremo, el probador podría detenerse y reportar un error o el probador podría solucionar más problemas, para ver si el programa falla de la misma manera a valores más normales. Quién hace esa resolución de problemas (el probador o el programador) es una cuestión de cultura corporativa. Algunas compañías presupuestan el tiempo del probador para esto, otras presupuestan a los programadores, y algunas esperan que los programadores corrijan los errores del caso de esquina, ya sean generalizables o no, de modo que la resolución de problemas no sea relevante. El malentendido común: que los evaluadores están perdiendo el tiempo (en lugar de maximizar la eficiencia) al probar valores extremos es otra razón por la cual "Una prueba que no está diseñada para revelar un error es una pérdida de tiempo" es un mensaje apropiado para los evaluadores. Es un contrapunto al estímulo de algunos programadores para (en efecto) nunca ejecutar pruebas que puedan desafiar el programa. El mensaje está demasiado simplificado, pero toda la discusión está demasiado simplificada.
Por cierto, el "valor de la información" no puede ser el único sistema de priorización. No es mi regla cuando diseño conjuntos de pruebas unitarias. No es mi regla cuando diseño pruebas de verificación de compilación (también conocido como controles de cordura). En ambos casos, estoy más interesado en los tipos de cobertura que en el poder de las pruebas individuales. Hay otros casos (por ejemplo, pruebas automatizadas de alto volumen que son baratas de configurar, ejecutar y monitorear) donde el poder de las pruebas individuales es simplemente irrelevante para mi diseño. Estoy seguro de que puedes pensar en ejemplos adicionales.
Pero como regla general, si pudiera decir solo una regla (por ejemplo, hablar con un ejecutivo cuya cabeza explota si intenta procesar más de una oración), sería que una prueba de bajo valor de información suele ser una pérdida de tiempo.