Lo que hay detrás de las pruebas unitarias
Leo en el blog de David Salgado una entrada acerca de pruebas unitarias que no tiene desperdicio, y leo aún con más interés si cabe los comentarios que dejan los lectores de su blog y de los que siempre se aprende algo.
Tentado me he visto desde el principio para escribir un comentario en su blog, de hecho, después de escribirlo y apunto de darle al botón de publicar he pensado que qué mejor sitio que mi propio blog para comentar algo con lo que me he «pegado» no una, sino mil veces, y que dada la extensión que puede tomar el tema, mejor abrir un nuevo hilo.
Paulovila hace unos comentarios acerca de si las pruebas unitarias no tienen sentido sino hay dinero para hacerlas, y no puedo estar más de acuerdo… con matices, matices que van a favor del comentario pero que ahora trataré de expresar de la mejor forma posible (espero que se me entienda perfectamente).
A niveles de coste, un proyecto debe ser iniciado solo si el coste del proyecto va a devolver un beneficio mayor que el propio coste, y siempre si ese beneficio está dentro de unos ratios marcados. El ROI o retorno de inversión es la mejor explicación para entender esto.
Para explicarlo de una forma más práctica, un proyecto debe ser iniciado si vamos a recuperar lo que hemos invertido y si tenemos claro que nos va a revertir un beneficio adicional al propio gasto, es decir, que no vamos a vender únicamente para cubrir los gastos porque entonces habremos perdido realmente tiempo con respecto a nuestra competencia y nuestra empresa no habrá crecido. Es lo que en castellano se diría la frase de comidos por servidos.
Dicho esto que es obvio, el problema fundamental de las empresas reside en lo que esas empresas contabilizan como gastos y partidas presupuestarias.
Evidentemente, y tampoco querría extenderme con muchísimo detalle, existen gastos directos y gastos indirectos. Los directos son muy claros y evidentes, mientras que los indirectos son más estimativos que los directos. Y no entro en valorar lo que se entiende por estimaciones porque daría para otra entrada mucho más larga que esta.
El caso es que muchas personas y empresas olvidan detallar gastos como por ejemplo la tinta y el papel de impresora, los bolígrafos, las libretas, los rotuladores para las pizarras, los cafés o incluso la luz por citar algunos pequeños ejemplos. Por eso muchas empresas deciden poner una partida presupuestaria de gastos generales.
Otro gasto son los sueldos del personal que va a trabajar en el proyecto, y ahí se prorratea siempre, ya que a lo mejor es necesario disponer de un Arquitecto de Software, pero ese Arquitecto estará en el proyecto durante un 7% del proyecto, por lo que los gastos a imputar se prorratean, y así hasta un largo etcétera que tampoco es cuestión de comentar ahora.
Tampoco trataríamos los gastos derivados de las licencias de Software y partida a través de su amortización. Y así podría seguir nombrando aspectos que muchas veces pasan desapercibidos… por lo menos en primera instancia.
Sin embargo, aún no he nombrado la base principal de esta entrada, de uno de esos «gastos», me refiero como no al gasto de las pruebas unitarias.
Aquí es donde quiero detenerme con más precisión para comentar algunas cosas que considero importantes y que cuando hablo con algunas personas veo que no quedan del todo claras.
Muchas empresas ven las pruebas unitarias como gasto que tendrían que salir de sus presupuestos. Algo que a todas luces es más que evidente.
El problema es que muchas empresas ven en ese gasto una pérdida y no una inversión. Ahí es donde se comienza a liar el asunto y donde debemos abrir bien los ojos.
Aquí podríamos definir que el gasto inicial de las pruebas unitarias y siempre y cuando las pruebas unitarias estén bien hechas (que no haya que repetirlas más de una vez porque están mal enfocadas o diseñadas), tendrá un retorno de inversión en modo de menos errores (nadie asegura que las pruebas unitarias resuelvan todos los males), mejor aspecto funcional, mejor experiencia y mayor satisfacción por parte del usuario, más seguridad y más convencimiento de que el Software hace lo que tiene que hacer, y por lo tanto, mayores posibilidades de que nuestro Software sea vendido a más usuarios o empresas que estarían satisfechos con la inversión (a modo de licencia) que han realizado por nuestro Software.
Evidentemente, cuanto mayor cualificado esté el equipo de desarrollo en
hacer esas pruebas unitarias, menor será el coste asociado a la
elaboración de esas pruebas unitarias, sin embargo, siempre habrá un
coste fijo asociado a la creación del propio conjunto de pruebas unitarias, y a medida que el proyecto avance, se irán cumplimentando y creando más pruebas unitarias. Porque otra cosa que no quiero tampoco discutir ahora, es que las pruebas unitarias deben hacerse al mismo tiempo que el desarrollo, porque sino luego, el coste para hacerlas es excesivamente elevado (no me acuerdo bien como estaba hecho, se me olvidan pasar pruebas que antes tenía claras, etc).
En todo esto siempre surge la misma pregunta: «¿para qué hacer pruebas unitarias?. Yo lo que quiero es tener mi Software ya hecho.».
A veces el tiempo apremia y muchas empresas están dispuestas a sacrificar parte de ese tiempo tan escaso a partes del desarrollo, y una de esas partes son las pruebas unitarias.
¿Con qué choca todo esto?. Con una sola cosa, la mentalidad de que las pruebas unitarias no revierten ningún beneficio ni afecta al ROI en nada más que los costes, cuando esto no es así.
Otra cosa es hacérselo ver a quienes tienen que tomar las decisiones, que ese es otro cantar.
En muy muy pocas empresas en las que he trabajado directa o indirectamente (y son unas cuantas), he podido ver a personas con las ideas claras sobre las pruebas unitarias. En un gran número de casos por no decir casi todos, las pruebas unitarias se entienden como gastos y sólo eso, gastos.
Siempre hago la misma pregunta. ¿Te comprarías un coche que nunca nadie lo ha probado?. Alguien diría, si no se ha probado yo no lo compraría,… pues bien, ese es el principio del ROI en cuanto a pruebas unitarias formuladas como gastos que retornan una inversión indirecta, porque si nadie ha probado nuestro Software… ¿con qué cara se lo instalamos a un cliente o lo vendemos?.
Indudablemente en esto hay una trampa manifiesta, y es que nadie nunca admite cual es la cantidad o calidad de esas pruebas unitarias y la cobertura de las mismas en su Software, y ya no hablemos de otros temas aparte de este hilo y que tienen que ver con las pruebas funcionales, etc.
Quizás en un futuro próximo se obligue al Software a llevar un sellito de «Probado», o como dicen algunas marcas «Testado», pero lo que está claro es que eso hoy por hoy no existe, y mucho menos mientras pensemos que las pruebas unitarias son evitables, que no ahorran tiempo y dinero en cuanto a mantenimiento del Software, que no aportan calidad al Software final o que son chorradas.
Lo único cierto es que nuestra cultura (al menos hablo de España) no está preparada para realizar pruebas unitarias al Software, y cambiar esa mentalidad cuesta más de una úlcera de estómago.
Finalmente y por asociarlo con las pruebas unitarias, nunca olvidaré una de las clases que recibí en la Universidad en la asignatura de marketing. Allí nos comentaban que es
difícil hacer un cliente, pero mantenerlo es más difícil, y perderlo
está chupado. Ahora bien un cliente perdido es casi imposible volverlo a
recuperar. ¿Alguien no se ha comprado «algo», le ha salido mal y no ha
querido volver a comprar esa misma marca nunca más y cada vez que le
pregunta alguien le cuenta su experiencia o dice… «esa marca ni de
coña»?.
Lo único cierto es que esto último que he puesto lo he podido constatar cada día, y aquí simplemente digo: que cada uno en su empresa haga lo que quiera, pero muchas veces no es lo que uno quiere sino lo que a uno le dejan hacer, y ahí es donde muchos desarrolladores nos mordemos las uñas hasta dejarnos los dedos casi pelados.
Yo lo tengo claro, las pruebas unitarias no son una elección y aportan calidad, pero ¿cómo cambiar el hábito y esta mentabilidad al menos a las empresas en España?. Si alguien tiene la fórmula de la coca-cola que la cuente por favor…
11 Responsesso far
Buenas Jorge,
Uff! Cuántas cosas que me gustaría comentar tanto en éste como en el otro post que citas, y qué poco tiempo. Dejo una reflexión de 5 minutos…
Sin tener ni **** idea de cómo se planifican/presupuestan proyectos en «la vida real en España» y sin conocer de primera mano la mentalidad del cliente (aunque, por lo que cuentas tú y otros, me voy haciendo una idea…); ¿no sería mucho más lógico, coherente con la filosofía de un ingeniero (de software) y ético de cara al cliente, vender el software como un «paquete» de funcionalidades/features y realizar cortes en el mismo en sentido vertical (features) en lugar de horizontal (etapas del desarrollo)?
Es decir, teniendo una lista de 15 funcionalidades que me gustaría que una aplicación tuviera, y considerando los recursos disponibles para este proyecto, sólo soy capaz de implementar con un nivel de calidad superior a los mínimos de calidad que mi empresa (mi marca!) tiene establecidos 12 de dichas funcionalidades. Esto, de entrada, se puede planificar en base a la prioridad de cada una de dichas funcionalidades (especificacion? requisitos? product backlog?) y la experiencia del gestor del proyecto hará que dichas estimaciones iniciales sean más o menos precisas. Posteriormente, quizá podamos añadir 1 ó 2 funcionalidades más, si con el paso de las iteraciones del proyecto vemos que le ganamos tiempo a la agenda del mismo. O quizá, algunas de las funcionalidades que en un principio habíamos acordado, no han llegado a un mínimo de calidad que nos permita sacarlas como parte de este producto… seguimos trabajando en ellas y pronto os llegarán… (Service Packs!).
Así es, a grandes rasgos y sin entrar en mucho detalle (y por tanto, dejando muchas imprecisiones en el camino), cómo funcionan las empresas con las que he tenido oportunidad de trabajar.
Una última objeción, quizá no debería hacértela a ti sino a bastante más gente por estos foros, y dicha sin acritud por supuesto: ¿Por qué hay tanta gente que emplea el término «pruebas unitarias» cuando, en realidad, muy pocos de ellos hablan (ya no digo implementan) otros tipos de pruebas? «Unitarias» no es una cualidad inherente al sustantivo «pruebas», ni nosotros somos el poeta Azorín, para emplear sistemáticamente epítetos (la nieve blanca, los verdes prados, las aguas cristalinas…). Esto, si el tiempo lo permite, me da pie a un puñado de posts… A ver si saco tiempo de algún sitio…
No me déis muchos palos en las respuestas, que ya anticipo que, seguramente, no voy a tener oportunidad de defenderme… : )
Saludos y a cuidarse,
M.
Si a los gurus y MVPs no les hacen caso en sus empresas, ´como para que nos lo hagan a los del montón…en España estamos perdidos, así nos va…
@Miguel, no solo no voy a darte yo palos por tu entrada (que de hecho no soy ni quien para hacerlo), sino que entiendo plenamente lo que dices. Por suerte no solo he trabajado en España, también fuera o con empresas de fuera, y lo que indicas de solo «comprometerse» (creo que es la palabra) «a lo que puedes cumplir» (que es el otro matiz) es lo que en España creo que no sabemos hacer (y generalizo sabiendo que hay empresas que sí lo hacen, vaya esto por delante).
Lo que dices a mí es lo que me gustaría hacer, pero… el día a día es lamentablemente otro en la inmensa mayoría.
Sobre las pruebas unitarias, totalmente de acuerdo en que no es lo último. Me he centrado en ellas por el post de David, pero en mi entrada hablo también de otras pruebas como las funcionales, etc… es decir, las únicas pruebas y válidas NO son las unitarias, son unas pruebas más de todas las que hay que hacer, pero esto como dices es para otra entrada que pensaba escribir más adelante.
No obstante, espero que saques tiempo para hacer tú una entrada de estos temas, porque realmente en la diversidad de opiniones o en las experiencias y puntos de vista de cada uno, nos enriquecemos más.
Muchas gracias por opinar. 🙂
@pregunton cojonero, te lo digo totalmente como lo pienso, no es cuestión de MVPs o gurús (lo primero lo soy todavía hoy, sobre lo segundo no me considero entrar en ese grupo igual que tampoco admito para nadie la palabra experto) es cuestión de mentalidad.
En España (en mi modesta opinión) hay esa mentalidad, por lo menos en cuanto al desarrollo del Software. En otras empresas o actividades industriales, si les dices que podemos ahorrar en pruebas directamente te echan o te dicen si estás loco, pero en Software no porque se piensa como un gasto sin retorno de inversión.
¿Cómo cambiar esta mentalidad?. No es una batalla perdida, pero sí de desgaste y de generar muchas úlceras estomacales. 🙁
Buenas,
Interesantes reflexiones…
A ver por partes… 😉
Empecemos por las pruebas unitarias: Yo creo que no debería ser necesario decir a un cliente que vamos a realizar pruebas unitarias. Para empezar a realizarlas debes estar convencido de que son necesarias y por lo tanto que las usas sí o sí. Forma parte de tu forma de trabajar y el cliente no tiene porque saber eso.
En este caso, si el cliente te pide valoración tu ya contarás el tiempo necesario para implementar las pruebas unitarias. El cliente no tiene porque conocer que un % de tu tiempo de desarrollo es de pruebas unitarias.
Evidentemente, siempre puede haber un competidor que valore lo mismo que tu en menos tiempo/más barato: Luego te toca «convencer» al cliente argumentando otras cosas… 🙂 Sí, ya se que es dificil…
Resto de pruebas (llamésmolas integración, funcionales, carga, stress, UATs).
Estas si que suelen tener una visibilidad y ahí si que muchas veces se choca con que el cliente las ve como «costos», en lugar de como ahorro.
Ahí si que en muchas empresas hay resistencia a realizar las pruebas: nos toca explicar mejor las ventajas, que aunque para nosotros sean evidentes para quien paga pueden no serlo tanto.
@Miquel
Tu planetamiento es realmente bueno. Pero con muchos clientes simplemente no se puede trabajar así: no les hables de que algunas funcionalidades vas a sacarlas a posteriori, porque el te dirá que quiere todo su proyecto. Hay clientes con mentalidades muy cerradas. No les expliques que iremos implementando cosas en base a sus prioridades y que iremos reestimando según vaya el tiempo, porque directamente no quieren ni oírlo.
Aquí como proveedor tienes dos opciones: tragar y trabajar con ese cliente, o ir a por otro cliente que entienda mejor como deben ser las cosas… Bueno, a veces puedes «buscar» dentro del cliente a alguien con mentalidad más abierta y que actúe de sponsor de esa manera de pensar, pero para lo bueno y para malo (y hay más de malo que de bueno) «this is spain».
Saludos! 😉
Hola,
este es un asunto que genera siempre mucha polémica, en mi opinión Eduard da en el clavo con:
«Empecemos por las pruebas unitarias: Yo creo que no debería ser necesario decir a un cliente que vamos a realizar pruebas unitarias. Para empezar a realizarlas debes estar convencido de que son necesarias y por lo tanto que las usas sí o sí. Forma parte de tu forma de trabajar y el cliente no tiene porque saber eso.
En este caso, si el cliente te pide valoración tu ya contarás el tiempo necesario para implementar las pruebas unitarias. El cliente no tiene porque conocer que un % de tu tiempo de desarrollo es de pruebas unitarias.»
En mi opinión, en las estimaciones de un proyecto pueden (y deben) ir incluidas las pruebas, no ya las unitarias sino toda la batería de pruebas y validaciones que debe pasar el software para asegurar su calidad. Posiblemente la mejor manera de incluir este tiempo en un proyecto es simplemente presupuestarlo como parte integral del mismo.
Como bien dice Eduard, a un cliente no hay por qué desglosarle que dentro de la fase de desarrollo están incluidos ciertos tipos de pruebas, es que para mi eso es desarrollo como lo es la instrumentación de la aplicación, punto. El desarrollo tarda tanto tiempo con tantos recursos y cuesta esto. Hasta ahí llega el conocimiento de la gente externa al proyecto y de puertas adentro en la fase de desarrollo hay lo que tenga que haber.
Se han puesto ejemplos de otras disciplinas, supongo que cuando un ingeniero de obras públicas presupuesta una obra tiene en cuenta sus pruebas y verificaciones de calidad de manera integral y transversal en el proyecto, sin especificarle al cliente cuántos segundos exactos se va a dedicar a eso dentro de la fase X, forma parte del proyecto.
Dicho esto, la pega fácil que se le puede poner es que vas a ser más caro que tu competencia por dedicar más tiempo/esfuerzo. Esto ya es matizable y no necesariamente cierto, pero ya no es una cuestión técnica, es una cuestión de filosofía de la empresa. Se trabaja poniendo el acento en entregar software de calidad, por encima de la media, sólido y que atraiga a clientes en el futuro o se apuesta por fabricar churros que en cuanto no exploten demasiado se liberan y a facturar…
Este es un tema de estrategia empresarial, no técnico y ahí es donde mucha gente técnica encontrará sus dilemas morales sobre cómo se hacen las cosas en muchas empresas cuando esa persona piensa que deberían hacerse de otra manera.
En España hay de ambas, tal vez los porcentajes de cada tipo es lo que alarma un poco.
@José, sí y no a lo que comentas y que cita @Eduard. Me explico:
Creo que debemos diferenciar entre clientes internos o clientes finales y consultoras. Cada uno de ellos actúa de forma dispar.
En todos ellos no obstante hay una máxima y es que cuanto más detallado quede todo mejor, o al menos, en cuestiones financieras es así y se pide todo lo más detallado posible. Otra cosa es que haya empresas de todo tipo y pasen de esto, pero lo normal debería ser así. Es lo que podríamos llamar como control del gasto… en otras palabras, a donde va mi dinero como empresa, donde lo gasto, donde lo invierto,… que hago con él.
Si inicias un proyecto y no detallas las pruebas, y tu coste es 1000, otra oferta u otra empresa podrá ganar el concurso poniendo 650 por ejemplo, y con esto no digo que el de 650 fuera mejor, sino que si se detallara justificaría porqué coger la de 1000 en lugar de la de 650 pese a que sea más cara. Si pones una partida general de desarrollo sin especificar, corres el riesgo de que no se valore todo el trabajo que se está llevando a cabo, o dicho de otra manera, que no se justifique correctamente el gasto. También podrías poner una partida del tipo Desarrollo + Pruebas, pero te aseguro que la mayoría de las ocasiones te pedirán especificar con concreción cada una de ellas.
A la hora de asumir y analizar gastos la cosa se complica, y eso… queramos o no, llega al equipo de desarrollo, a veces por medidas impuestas y otras porque sino el proyecto no sería «rentable» (y pongo rentable entre comillado por la cantidad de variables que conlleva).
¡Muchas gracias por opinar! 🙂
@Jorge, desde luego, estoy al tanto de ese tipo de cuestiones y con eso en mente he escrito el comentario.
A nivel interno es una cosa y externo es otra a nivel de detalle, seguro que en eso estamos de acuerdo, y me refería en mi comentario anterior a la pata externa en ese caso.
Una fase de desarrollo y pruebas es muy común en una oferta a un cliente, sin detallar al centímetro cómo se va a desgranar dicha fase, no especificas cuánto se va a dedicar a instrumentación, por ejemplo, otra cuestión que podría ser polémica para un cliente, decía antes.
Iba a escribir algo más pero me doy cuenta de que lo podemos hablar mañana en el TTT, con lo que mejor podemos seguir hablando allí 🙂
Genial José. 🙂
Aunque apuesto lo que sea a que todos estamos de acuerdo y en desacuerdo al mismo tiempo, porque los matices son miles. 🙁
Jorge, negociar las pruebas unitarias es negociar calidad. Hay quienes creen que se la puede negociar y otros piensan que no, yo estoy entre los segundos. Es una práctica de ingeniería y no debería discutirse con clientes.
En mi última entrada sobre este tema puse links a unos papers sobre la efectividad de TDD en algunas empresas: en IBM (en un projecto) redujeron la tasa de defectos en un 91%.
En otro, los resultados del estudio indicó que la densidad de defectos de 4 productos decreció entre un 40% y un 90% relativo a projectos similares en los que no se utilizó TDD, esto a un costo de entre un 15% y un 35% más en el esfuerzo de desarrollo.
Con estos números en la mano, la negociación podría ser distinta.
Parece que como informáticos que somos somos muy «BINARIOS», hacer o no hacer pruebas unitarias, esa es la cuestión, ya que eso implica un coste. Habéis hablado de dinero, de costes, de ROI… yo creo que las pruebas aportan calidad interna al producto, y hay que ofrecer la calidad justa y necesario, es decir, lo que el presupuesto permita. Entiendo que deberemos de alguna manera indicar ese nivel de pruebas en función de la cobertura de código, ¿no? … habrá algún proyecto que por su naturales y características, únicamente tenga un 10% de cobertura y otro del 80%.
En cualquier caso si descuidas la calidad a la larga lo pagas y el coste de cubrir garantías es mayor que el coste de establecer una buena política de pruebas unitarias e IC. Veáse la gráfica «cost of fixing bug»:
http://www.developertesting.com/archives/month200501/20050127-TheDeveloperTestingParadox.html