En 2002, el Instituto Nacional de Normas y Tecnología (NIST) publicó un informe que detallaba el impacto económico de las pruebas de software inadecuadas (Informe NIST, 2002). El informe concluía que:
“…se estima que los costos anuales nacionales de una infraestructura inadecuada para pruebas de software oscilan entre 22.200 y 59.500 millones de dólares”.
El informe del NIST también señaló que el estado de las prácticas de pruebas de software era lamentablemente deficiente.
Siete años después, Wong et al., en un informe de la IEEE Reliability Society (Wong et al., 2009), revisaron 15 fallas de software ampliamente publicitadas, varias de las cuales provocaron pérdida de vidas, y concluyeron que:
“…es necesario implementar mejores procedimientos y prácticas de prueba, y esto es especialmente cierto en el caso del software relacionado con sistemas críticos para la seguridad”.
En un artículo más reciente, Wong et al. examinaron una variedad de fallas de software en varias industrias (Wong et al., 2017) e hicieron una observación bastante esclarecedora:
“…La triste verdad es que el software está lejos de estar libre de defectos y cada año se gastan grandes sumas de dinero para reparar o mantener el software (defectuoso)”.
El artículo analizó los fallos de software durante un período de 30 años, de 1985 a 2015; identificó la naturaleza de los errores de software que precipitaron los fallos, junto con otros factores contribuyentes, como el error del usuario; y clasificó los fallos en dos categorías: los que fueron fatales (resultaron en pérdida de vidas) y los que no fueron fatales pero resultaron en pérdidas económicas sustanciales. Los fallos fatales incluyeron el incidente de Therac-25 de 1985, donde al menos seis pacientes recibieron sobredosis de radiación, así como los accidentes de aviación civil entre 1995 y 1997, donde más de 650 personas perdieron la vida. También incluyó el incidente del ébola de 2014, donde un fallo del software de registros médicos electrónicos resultó en el diagnóstico erróneo de un paciente infectado con ébola, lo que resultó en una muerte posterior. Los fallos no fatales incluyeron un fallo del software de una planta de energía nuclear, que resultó en una pérdida de $2 millones, así como el fallo del software de Ariane 5, que resultó en una pérdida de $7 mil millones. En su conclusión, los autores ofrecieron la siguiente observación:
“…la ubicuidad del software integrado en infraestructuras públicas, sistemas de transporte, productos de consumo y más nos deja incrédulos de que alguien que ha trabajado en sistemas de software complejos pueda creer que es posible construir tales sistemas sin fallas…”
Lamentablemente, a pesar de estos relatos esclarecedores sobre los tipos de sistemas de software de los que dependemos cada vez más, hay un punto clave que no se tiene en cuenta en estos debates: la mayoría de los fallos de software pasan desapercibidos y no se informan. En algunos casos, el fallo es sutil (o incluso intermitente) y, por lo tanto, es fácil pasarlo por alto. Por ejemplo, una aplicación de software estadístico puede presentar estadísticas calculadas incorrectamente. Esas estadísticas calculadas incorrectamente son fallos, pero pueden no ser evidentes de inmediato, especialmente para un no experto. No obstante, esos fallos pueden conducir a decisiones incorrectas o subóptimas y, por lo tanto, podrían tener consecuencias muy importantes.
Es evidente que el arte de escribir software –independientemente de la sofisticación de los entornos de desarrollo integrados utilizados, la sofisticación de los métodos de programación o la habilidad de los programadores– es un arte imperfecto y dará lugar a errores. Esta realidad significa que depende del rigor del esfuerzo de prueba del software descubrir estos errores antes de que el software se lance al mercado. Como indican NIST y Wong et. al., no hacerlo puede tener consecuencias importantes. Barry Boehm, una figura icónica en la comunidad de ingeniería de software, señaló en su artículo seminal sobre la economía de la ingeniería de software (Boehm, 1984), que el costo de encontrar y corregir un error después de la implementación del software suele ser al menos 100 veces mayor que identificar y corregir el error antes de la implementación.
En vista de este contexto, ¿es cierto que los métodos de prueba de software son simplemente inadecuados? Yo diría que no es así. De hecho, la investigación sobre pruebas de software ha sido un área de investigación sólida durante más de 50 años. En 2014, Orso y Rothermel escribieron sobre el progreso sustancial en el desarrollo de métodos de prueba de software en los 15 años anteriores a su artículo (Orso y Rothermel, 2014). El período de 15 años anterior al 2000 también fue un período de desarrollo espectacular en los métodos de prueba de software. Glenford Myers (Myers, 1978) y Boris Beizer (Beizer, 1984), dos figuras icónicas en la comunidad de pruebas de software, realizaron su trabajo pionero en los años 70 y 80. Lamentablemente, el problema principal es la adopción, no la idoneidad de los métodos de prueba. La comunidad de desarrollo de software ha sido lenta en adoptar métodos rigurosos de prueba de software a lo largo de los años, a pesar de la evidencia empírica disponible de su utilidad (Kuhn et. al., 2015, Morgan, 2018). Esta situación se ha visto exacerbada por dos realidades del desarrollo de software. Las actividades de prueba de software son notoriamente insuficientes en cuanto a financiación y recursos. Además, la velocidad y la complejidad de las actividades de desarrollo de software han crecido drásticamente en los últimos años.
Los sistemas de software están ahora más presentes que nunca y desempeñan un papel cada vez más importante en nuestras vidas. La importancia crítica de los métodos de prueba de software robustos es evidente y es un aspecto del desarrollo de software del que todos los profesionales del desarrollo de software deben ser más conscientes. Para abordar esta necesidad, hemos emprendido esta serie de publicaciones en el blog. Esta publicación es la segunda de esa serie, y habrá más por venir.
Obras citadas
Beizer, Boris. Pruebas de sistemas de software y control de calidad . Van Nostrand Reinhold Co., 1984.
Boehm, Barry W. “Economía de la ingeniería de software”. Transacciones IEEE sobre ingeniería de software (1984): 4-21.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., y Kacker, RN (2015). “Pruebas combinatorias: teoría y práctica”. Advances in computers , 99 , 1-66.
Myers, Glenford J. “Un experimento controlado en pruebas de programas y recorridos/inspecciones de código”. Communications of the ACM 21.9 (1978): 760-768.
Morgan, J. (2018). “Pruebas combinatorias: un enfoque para las pruebas de sistemas y software basado en matrices de cobertura”. Métodos analíticos en pruebas de sistemas y software , 131-158.
Informe del NIST. “Los impactos económicos de una infraestructura inadecuada para las pruebas de software”. Informe de planificación del Instituto Nacional de Normas y Tecnología 02-3. Mayo de 2002.
Orso, A., y Rothermel, G. (2014) “Pruebas de software: un diario de viaje de investigación (2000-2014)”, en Actas sobre el futuro de la ingeniería de software , ACM, mayo de 2014, págs. 117-132
Wong, W. Eric, Vidroha Debroy y Andrew Restrepo. “El papel del software en los accidentes catastróficos recientes”. Informe anual de tecnología 2009 de la IEEE reliability society 59.3 (2009).
Wong, W. Eric, Xuelin Li y Philip A. Laplante. “Familiarizarse más con nuestros enemigos y allanar el camino: una revisión de los roles que desempeñaron los errores en los fallos de software”. Journal of Systems and Software 133 (2017): 68-94.
Si un software proporciona miles y miles de funciones diferentes, resulta difícil garantizar que todas ellas funcionen juntas y que dos funciones armonicen con una tercera.
Esto se puede ver en Tiny Traps en Jmp y JSL .
A veces, la combinación de 2 o 3 características interesantes produce un resultado inesperado.
Es difícil probar todas estas pequeñas interacciones, pero la inteligencia de enjambre del usuario tiene una oportunidad ; )
¡Muchas gracias al equipo de soporte de JMP por sus esfuerzos para organizar y canalizar los comentarios de los usuarios!
¡Gracias a los desarrolladores por su entusiasmo en brindarnos un software que funciona de maravillas!
Las pruebas combinatorias (consulte a continuación las referencias de la publicación) son un enfoque de prueba que se centra en los fallos que se deben a las interacciones. El objeto matemático subyacente es una matriz de cobertura y, por lo tanto, es un enfoque muy eficiente, ¡incluso cuando hay miles de entradas! Este será el tema de un próximo blog.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., y Kacker, RN (2015). “Pruebas combinatorias: teoría y práctica”. Advances in computers , 99 , 1-66.
Morgan, J. (2018). “Pruebas combinatorias: un enfoque para las pruebas de sistemas y software basado en matrices de cobertura”. Métodos analíticos en pruebas de sistemas y software , 131-158.
@Vins , existen métodos en desarrollo para hacer esto. Por lo tanto, la respuesta es "Sí y Sí". Hace apenas unas semanas, en MEMOCODE-2024 ( https://memocode2024.github.io/program.html ), nuestro colega presentó una charla sobre esto. La idea es utilizar el análisis bayesiano para guiar la selección de casos de prueba posteriores (es decir, un método de diseño de casos de prueba secuenciales). El título del artículo es:
"MaLT: diseño de casos de prueba guiados por aprendizaje automático y localización de fallas en sistemas de software complejos".
Las actas de la conferencia MEMOCODE-2024 se publicarán pronto, pero es posible que puedas encontrar el artículo si realizas una búsqueda en Google Scholar sobre el título. Probablemente hablaré un poco sobre esto en mi blog sobre pruebas combinatorias.
