X
BLOG

¿Cuánto cuestan realmente los defectos de software? El error de $ 2.3 mil millones

¿Cuánto cuestan realmente los defectos de software? El error de $ 2.3 mil millones Tiempo de leer: 5 minutos

Los equipos de desarrollo de software luchan por mantenerse al día con la incesante demanda actual de software más innovador, más rápido. La mayoría está explorando nuevas formas de acelerar los ciclos de lanzamiento (ágilapoyarse DevOps..). Sin embargo, según la cantidad de fallas de software que ahora aparecen en los titulares a diario, es evidente que simplemente acelerar los procesos existentes no es suficiente.

¿Cómo pueden los profesionales del desarrollo de software responder a esta necesidad de velocidad sin aumentar el riesgo de costosos defectos? Ese fue el tema de Wayne Ariola ¿Cuánto cuestan realmente los defectos? Mucho más de lo que piensas sesión en StarEast la semana pasada. Ariola reveló su investigación sobre el verdadero costo de los defectos de software y por qué se requiere un nuevo enfoque de prueba / control de calidad si no quiere ser responsable de una falla de software que lleve a su organización a los titulares.

La siguiente sinopsis de esa sesión fue escrita por Noel Wurst, editor en jefe at Skytap, el proveedor líder de entornos bajo demanda como servicio (EaaS). Fue publicado originalmente en el Blog de Skytap...

La cultura de calidad pasiva conduce a un "Ticker Shock"

Preguntar a una sala llena de probadores de software: "¿Cuánto cuestan realmente los defectos?" y luego decirles, "mucho más de lo que piensas", antes de que alguien tenga la oportunidad de responder, es un movimiento bastante valiente. Sin duda, es uno que podría haberle fracasado fácilmente al director de estrategia de Parasoft, Wayne Ariola, en la conferencia STAREAST de la semana pasada.

No fue contraproducente, y después de oleadas de pruebas del inmenso impacto financiero que los defectos de producción pueden tener en una empresa, tuve la sensación de que muchos en la sala tomaron notas mentales para tener conversaciones muy serias con varios departamentos al regresar a casa.

Todo el mundo sabe que los defectos provocan largas horas de reelaboración, y las versiones de nuevas funciones se retrasan, a veces se deben aplicar parches, pero cuantificar eso en golpes financieros reales no solo es difícil, esos números rara vez se comparten con desarrolladores, probadores y otros fuera de los niveles de inversionista y ejecutivo.

Citando fallas de software conocidas de bancos y seguros, los constantes hackeos de Sony, el problema de robo de identidad de Target en 2014 y la falla reciente del iPad de American Airlines, Ariola luego pasó a una serie de gráficos de líneas difíciles de digerir que mostraban la caída de los precios de las acciones en cada una de estas fallas. causado.

Inmediatamente después de estas fallas, a medida que crecían las noticias y aumentaban las acciones en las redes sociales, estas acciones continuaron cayendo. En algunos ejemplos, una vez que los precios comenzaron a subir nuevamente, se estabilizaron mucho más bajo que el precio por acción antes del lanzamiento o el descubrimiento de errores.

Ariola culpó de estos fallos a una “cultura de no centrarse en la calidad del software” y nadie estuvo en desacuerdo. Esto no quiere decir que esos probadores en la sala no estén enfocados en la calidad, pero ¿lo están todos los demás? No es probable. Y para algo tan difícil de cambiar como la cultura, no es el momento de que los evaluadores o cualquier otra persona señalen con el dedo. Es hora de enderezar el barco antes de que su organización sea la siguiente en los titulares.

Entonces, ¿cómo solucionamos esto?

Por un lado, Ariola dice que es hora de comenzar a compartir información financiera como los precios de las acciones con los desarrolladores, y agregaría propietarios de productos, diseñadores y cualquier otra persona que toque un candidato de lanzamiento antes de que se envíe. Y eso no significa enviar un correo electrónico trimestral a la empresa con poco más de una captura de pantalla del historial de acciones de tres meses.

Se trata de analizar el precio de las acciones de su empresa en el momento en que salió un nuevo lanzamiento y luego rastrear otros momentos importantes a partir de ahí. ¿Cuándo se encontró el error? ¿Quién lo encontró primero? ¿Fue publicitado? ¿Cuánto tiempo pasó hasta que se pudo arreglar? ¿Con qué rapidez podría el soporte resolver problemas y satisfacer a los clientes? Estos son los tipos de métricas que pueden impactar absolutamente algo tan aparentemente distante como lo que está sucediendo en Wall Street, un área donde algunos pueden no saber que tienen tanto impacto.

Y para aquellos que no funcionan para una empresa que cotiza en bolsa, existen otras métricas a seguir, como la cantidad de clientes que tiene o la cantidad de personas que actualmente usan su aplicación móvil. Ariola preguntó desde el principio: "¿Cuántos de ustedes han descargado alguna vez una aplicación que odiaban?" Por supuesto, todas las manos se levantaron y luego preguntó: "¿Y qué hiciste cuando te diste cuenta de que lo odiabas?" Todos gritamos orgullosos e inmediatamente al unísono: "¡Lo borramos!"

Esta es la mentalidad de hoy. Lo único que lleva menos tiempo descargar una aplicación móvil es eliminarla. Al igual que el precio de las acciones, si el número de suscriptores / usuarios de su software disminuye con más frecuencia de lo que aumenta, esto puede ser un problema grave.

Una sugerencia que se hizo para combatir las versiones con errores fue dejar de preguntar "¿Hemos terminado las pruebas" y, en cambio, preguntar "¿El candidato a la versión tiene un nivel de riesgo aceptable?" Algunos pueden asumir incorrectamente que esos dos son lo suficientemente similares como para no justificar un cambio en el enfoque de las pruebas, pero esto solo permite que la cultura actual continúe poniendo en riesgo su negocio y sus clientes.

Incluso si todos lograron ponerse de acuerdo de alguna manera en una definición de "terminado", cuando ocurra un desastre, nadie querrá escuchar (o incluso decir) "¡Pero terminamos las pruebas!" cuando alguien quiere saber cómo ese error entró en producción.

A medida que avanzaba la sesión, algunos en la sala compartieron historias de cómo estaban aumentando la cobertura con pruebas continuas, "moviéndose a la izquierda", utilizando recursos de desarrollo / prueba basados ​​en la nube—Y espero que estas historias hayan ayudado a inspirar a algunos de los que conocían el desafío que tenían por delante en casa.

Mientras leo este resumen, me doy cuenta de que he hecho que parezca que la sesión fue un sermón de fuego y azufre destinado a asustarnos a todos para que huyamos de regreso a nuestras oficinas y nunca volvamos a ver el tiempo libre ni a nuestras familias, pero eso está lejos del caso.

Todos entendieron el mensaje sin ser golpeados en la cabeza, se aplicó a todas las industrias de software del mundo, hubo mucha participación de la audiencia y Ariola casi logró pasar toda la sesión sin mencionar ni lanzar los productos de su propia compañía una sola vez. —Algo que literalmente nunca vi que se hiciera durante una presentación de un proveedor.

Durante la sección de preguntas y respuestas al final, un asistente preguntó con entusiasmo, lápiz y papel en la mano: "¿Tiene alguna virtualización de servicios, automatización de pruebas o herramientas de pruebas continuas que recomendarías?

Y después de una risa, no tuvo más remedio que sugerir Parasoft como una gran opción, y las risas y los aplausos de la multitud demostraron que definitivamente se había ganado el enchufe.

Libro de prueba continua

¿Desea obtener más información sobre el costo de la calidad y cómo asegurarse de que usted no es el responsable de liberar un error de mil millones de dólares en la naturaleza? Lea las 44 páginas de Parasoft Libro electrónico de prueba continua hoy para saber cómo empezar. Las copias impresas son disponible en Amazon.

De Alan Zeichick, SD Times

“Ariola y Dunlop dan en el blanco: todo se trata de riesgo. De eso se tratan los seguros, de eso se tratan los abogados, ese es el tipo de decisión que todo gerente de negocios y tecnología toma todo el día, todos los días. Tenemos que vivir con riesgo y hacer concesiones. ¿Más pruebas? En algún momento, de hecho, tenemos que cortarlo.

Es difícil, si no imposible, evaluar el riesgo empresarial de la calidad del software. Sí, la calidad del software es cara. Cuanto mayor sea la calidad, más tiempo llevará entregar el software y mayores serán los recursos que debe dedicar a la calidad del software. Y sí, es costoso tener fallas de software: puede perder dinero, perder clientes, sufrir demandas, dañar su marca y terminar en la portada de The Wall Street Journal. No está bien…

Ariola y Dunlop hacen un buen punto en su breve libro: no debemos aceptar que la tendencia hacia la aceleración del proceso de desarrollo mejorará mágicamente la calidad del software; de hecho, deberíamos esperar lo contrario. Y si vamos a mitigar el riesgo en el entorno actual, necesitamos rediseñar el proceso de desarrollo de software de una manera que considere el riesgo empresarial como una de las métricas, junto con los otros resultados tradicionales de nuestros sistemas de pruebas automatizadas e Integración Continua ".

Escrito por

Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft