¿Qué hay de confirmar la funcionalidad en las pruebas positivas y demostrar que está funcionando? ¿Debo decir que es una pérdida de tiempo? ¿Qué tipo de concepto hay detrás de esta cita?
Las pruebas fallidas, es decir, las pruebas que no encuentran errores son una pérdida de tiempo.
Ingeniería web: la disciplina del desarrollo sistemático de aplicaciones web citando a Cem Kaner .
Respuestas:
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.
fuente
La idea es, según Kaner, "dado que se le acabará el tiempo antes de quedarse sin casos de prueba, es esencial usar el tiempo disponible de la manera más eficiente posible".
El concepto detrás de la cita que usted solicita se presenta y explica en detalle en el artículo de Testing Computer Software de Cem Kaner , Jack Falk, Hung Quoc Nguyen, en el capítulo "LOS OBJETIVOS Y LÍMITES DE LAS PRUEBAS":
Verá, el punto anterior es que debe priorizar sus pruebas sabiamente. Se espera que las pruebas tomen una cantidad limitada de tiempo y es imposible probar todo en el tiempo dado.
Imagínese que pasó un día (semana, mes) ejecutando pruebas, no encontró errores y dejó pasar algunos errores porque no tuvo tiempo para ejecutar una prueba que lo revelara. Si esto sucede, no puede simplemente decir "no es mi culpa porque estaba ocupado ejecutando otras pruebas" para justificar esta falla; si usted lo dice, seguirá siendo responsable.
Perdió el tiempo ejecutando pruebas que no revelaban errores y, debido a esto, se perdió una prueba que encontraría un error.
(En caso de que si uno se pregunta, como se pierde por encima general son inevitables, no importa cuanto lo intente, y no son maneras de tratar con ellos, pero eso sería más un tema de una pregunta separada ... y probablemente un mejor ajuste para SQA. SE.)
fuente
Bueno, no conozco al Sr. Caner, pero en mi humilde opinión
son una pérdida de tiempo Eso incluye la situación en la que ya tiene algunas pruebas (no importa si son automáticas o simplemente en una lista de verificación), y agrega nuevas pruebas que validan esencialmente los mismos casos que ya tiene. Por lo tanto, sus nuevas pruebas no encontrarán más errores que los existentes.
Tal situación puede suceder, por ejemplo, si solo revisa al azar una lista aleatoria, podría decir también "sin cerebro" (perdóneme esa palabra), eligió casos de prueba en su programa, sin pensar si verifican un nuevo caso límite, una nueva equivalencia clases de sus datos de entrada, o si aumentan la cobertura del código en relación con las pruebas ya escritas.
fuente
En mi opinión, esta cita se refiere a pruebas demasiado generales o unrobusts.
Si realiza una prueba para una función que valida los correos electrónicos y en la prueba solo proporciona correos electrónicos válidos, esa prueba es completamente inútil. Tendría que probar esta función para "cualquier" cadena posible, correos electrónicos no válidos, correos electrónicos demasiado largos, caracteres unicode (áêñç ....)
Si codifica una prueba que solo verifica que [email protected] devuelve verdadero y name @ com devuelve falso, esa prueba es igual a ninguna prueba.
fuente