¿Cuánto cuestan las pruebas unitarias?

Ahora, en la cima del ciclo económico en una industria tan activa como el desarrollo de software, no es habitual contar dinero. A menudo, este proceso, en principio, se posiciona como una actividad creativa, donde no hay necesidad de justificar nada, y el artista sabe mejor qué y cómo escribir. En particular, hay mucho debate sobre las pruebas unitarias y el TDD, pero, desafortunadamente, todos se deslizan en declaraciones no comprobadas y ataques emocionales, confirmados por pruebas de artículos y libros seleccionados con éxito por metodólogos que ganan en consultas y ventas de entrenamientos, que, en su a su vez, no contienen absolutamente ninguna estadística o cálculo, o, por el contrario, acusaciones radicales de smushylebstvo y otros pecados de la juventud.

A diferencia de argumentos vacíos similares, este artículo le dará no solo una reflexión, sino también una metodología para evaluar la viabilidad económica de introducir pruebas unitarias en un proyecto específico. Inmediatamente enfatizaré que, como cualquier evaluación, nuestra evaluación para el proyecto de implementación de la prueba unitaria se basará en suposiciones sobre el futuro del producto, el equipo y varios indicadores, que solo pueden evaluarse subjetivamente. Sin embargo, la situación en la que un programador realiza una evaluación experta de indicadores que están al menos relacionados de alguna manera con su campo de actividad es mucho mejor que preguntarle directamente si es rentable para la empresa utilizar pruebas unitarias o no. Al final, los programadores generalmente no están inclinados a pensar siquiera en indicadores financieros básicos, sino que no solo los desarrolladores, sino también los evaluadores y gerentes pueden evaluar el tiempo dedicado a escribir pruebas o la probabilidad de un error crítico en su ausencia.

Cual es el costo

En primer lugar, si vamos a calcular el costo de algo, primero debemos entender, al menos en términos generales, cuál es el valor. Cuando compramos un pan de salchicha, esta pregunta no surge, ya que una etiqueta de precio cuelga debajo de ella. Pero en el caso del proyecto, no estamos tratando con un pago único, sino con un flujo de efectivo que dura mucho tiempo, y lo invertimos primero y luego nos pagan. Para evaluarlo correctamente, debe tener en cuenta que el dinero recibido mañana costará menos que hoy. Si la salchicha se vendiera por suscripción, no sería difícil de hacer, el costo de la suscripción podría calcularse descontando los pagos futuros por la cantidad de inflación. Sin embargo, en el caso del proyecto, debemos tener en cuenta que la empresa, al invertir en él, espera no solo compensar sus costos, sino también ganar, tanto como para cubrir sus riesgos. Hay una gran cantidad de riesgos, pero al final todo se reduce al hecho de que el rendimiento del dinero invertido en la implementación del proyecto no está garantizado y mal pronosticado. El dinero se puede llevar a un banco o pedir prestado a un prestatario difícil y garantizar que pague intereses regularmente, pero no puede invertir en un proyecto para terminar con un flujo de pagos predecible según lo programado. Por lo tanto, desde el punto de vista del inversor, en este caso, la empresa, el flujo de caja descontado a la tasa de rendimiento requerida generada por el proyecto, también llamado valor presente neto, debe ser positivo:

$$

Para calcularlo, necesitamos saber cuánto dinero traerá o comerá el proyecto en el primer, segundo, tercer año, etc., así como la tasa de descuento, que no solo debería ser más rentable que en el banco, sino también cubrir los riesgos .

De hecho, esta es una fórmula algo simplificada. Estrictamente hablando, la tasa cambiará de año en año, por lo que WACC1 * WACC2 * WACC3, etc., debe usarse en el denominador, pero en la práctica incluso los tasadores profesionales descuidan esto, porque En virtud de la metodología de cálculo WACC, las expectativas del mercado con respecto a las tasas futuras ya se han incorporado a las tasas actuales y no es productivo hacer suposiciones al respecto.

Existen diferentes tipos de flujos de efectivo, pero tomé el flujo de efectivo más conveniente para nuestros propósitos para la empresa, que tiene en cuenta no solo el dinero adeudado a los propietarios, sino también a los acreedores. Por supuesto, la mayoría de las empresas de TI no tienen deudas notables simplemente porque nadie les presta sin garantía, y no tienen nada que prometer, pero todavía hay excepciones, por ejemplo, este enfoque puede ser conveniente al evaluar un proyecto en el desarrollo interno de una empresa de fabricación prestada . La segunda razón por la cual FCFF es de particular interés para nosotros es la simplicidad de su cálculo, FCFF es solo la utilidad operativa menos los impuestos, los costos netos de capital y los cambios en el capital de trabajo.

Dado que FCFF es un flujo de efectivo tanto para los propietarios como para los prestamistas al mismo tiempo, se descuenta a una tasa ponderada del costo de capital, tanto propio como prestado.

En las grandes empresas, el departamento financiero controla el costo del capital, por lo que puede preguntarlo, pero para el caso general, todavía necesitamos una fórmula para calcular el WACC:

$$

Aquí Re es el costo del capital, Rd es el costo del capital prestado (es decir, la tasa efectiva de las deudas de la compañía), P es el valor de mercado del capital, EV es el costo total de la empresa (EV = P + D, donde D es la deuda).

A continuación, debemos determinar Re, para esto existen diferentes modelos, pero la forma más fácil es tomar el modelo CAPM, donde Re = Rb + β * Premium, donde Rb es la tasa libre de riesgo, Premium es la prima para el retorno de la inversión en capital, no en prestado, y β es un factor de riesgo que muestra cuánto más riesgoso es nuestro proyecto con respecto al negocio de una determinada empresa promedio.

Cómo se garantiza la calidad y qué pruebas unitarias son

Ahora tenemos que decidir qué pruebas unitarias son. Por extraño que parezca, muchas personas, incluso cercanas al desarrollo, a menudo llaman pruebas unitarias de pruebas automatizadas, pero esto, por supuesto, no es así.

Las pruebas se dividen en funcionales y no funcionales. No funcional incluye cosas que no están directamente relacionadas con la funcionalidad del software, por ejemplo, pruebas de carga o pruebas relacionadas con la seguridad. Funcional, sin embargo, solo significa verificar el cumplimiento de los requisitos y la ausencia de errores en su implementación, se discutirá específicamente.

Lo primero que debe hacerse para garantizar la calidad es tomar la función de control de los desarrolladores y contratar a la persona responsable de ello. Entonces aparece un probador en el equipo, que se dedica a las pruebas manuales. Ningún proyecto serio es simplemente inconcebible sin una prueba manual; es la base que el proyecto necesita vitalmente y la gran mayoría de los problemas que se descubrirán y corregirán a tiempo serán el mérito de los evaluadores. En esta etapa, todo parece simple: si desea calidad, contrate a un especialista de calidad.

A medida que el proyecto crezca, el tiempo para las pruebas manuales será cada vez menor, por lo que los evaluadores estarán cada vez más ocupados trabajando con las nuevas capacidades del sistema y comprobarán cada vez menos aquellas partes del sistema que no deberían haber cambiado. Sin embargo, a medida que crece la complejidad del sistema y existe la posibilidad de que aparezcan dependencias explícitas e implícitas entre sus componentes, que los desarrolladores teóricamente pueden perder de vista, aún es recomendable verificar algunas cosas cada vez antes del lanzamiento. Este problema es especialmente grave en las metodologías flexibles con sus iteraciones cortas y lanzamientos frecuentes. Esto implica lógicamente la necesidad de automatizar el trabajo de los probadores, por ejemplo, escribir un script que haga clic en los botones y verifique el resultado en sí mismo, o use herramientas más potentes y convierta un probador ordinario en un especialista en pruebas automatizadas que pueda automatizar la parte rutinaria de su trabajo.

Estas medidas pueden proporcionar un nivel de calidad decente, pero no hay límite para la perfección. Lo que hacen los probadores se llama prueba de caja negra, su responsabilidad es no conocer todas las características de la implementación, por lo que las pruebas generalmente se centran en escenarios típicos y no establecen el objetivo de romper el sistema o verificar su comportamiento en condiciones atípicas. Además, algunas cosas no son fáciles de verificar simplemente debido a la falta de una interfaz, por ejemplo, si el objetivo de la iteración es desarrollar una biblioteca para acceder a datos o alguna API específica, para probarla necesitará escribir alguna aplicación o al menos algo que usaría este componente. En tales casos, debe devolver parcialmente la función de control de calidad a los desarrolladores y pedirles que escriban pruebas de integración. Este es el segundo tipo de pruebas automatizadas que se utilizan en el proyecto. Su objetivo es probar la corrección de la interacción de los componentes del sistema escritos por diferentes personas, probar el comportamiento de estos componentes en condiciones límite, así como la corrección de la reacción a fallas en el entorno.

Bueno, tenemos evaluadores que prueban el cumplimiento de los requisitos de todo el proyecto, hay pruebas para automatizar su trabajo y hay pruebas que prueban partes del proyecto escritas por diferentes desarrolladores, ¿qué más se puede hacer? Las pruebas unitarias afirman ser el cuarto nivel de control de calidad. Comprueban el código escrito por un programador y, como regla, prueban la parte mínima del código, que es básicamente adecuada para probar, por ejemplo, una clase separada. En la práctica, con mayor frecuencia el desarrollador mismo escribe pruebas unitarias para su propio código, y su número y necesidad están mal controlados. Según mis observaciones, aproximadamente el 40% del tiempo para desarrollar la característica en sí puede denominarse una cantidad típica de tiempo de desarrollador dedicado a las pruebas unitarias, aunque esta proporción puede variar mucho. El estudio de caso de código abierto del proyecto SQLite es ampliamente conocido, ya que debido al exceso de mano de obra gratuita poco calificada proporcionada por una gran cantidad de personas que desean trabajar en un proyecto bien conocido, esta fuerza de trabajo se utiliza a la manera del ejército, es decir, escribiendo pruebas unitarias inútiles, cuyo volumen en algún momento 100 veces el volumen del código del propio DBMS. Los casos inversos cuando las pruebas unitarias no se escriben o se escriben en un volumen mínimo tampoco son sorprendentes. Al final, casi todo el software desarrollado hasta el final del cero, es decir, antes de la era de la externalización y Agile, se creó sin pruebas unitarias.

Costos, ajuste de complejidad y persona-mes mítico.

Por supuesto, si necesita escribir pruebas unitarias o algo más, tendrá que dedicar más tiempo al proyecto o contratar desarrolladores adicionales. La pregunta principal que surge en este caso es si la dependencia del tiempo de desarrollo y el costo de la cantidad de código es lineal, o si obedece a otra ley.

Había una vez un repositorio SVN gratuito en el conocido servicio Assembla, que proporcionaba servicios de alojamiento de origen y herramientas de colaboración, es decir, un rastreador, estadísticas y otras tonterías. Más tarde, el obsequio terminó, pero no dejaron de enviar boletines y notificaciones. Entonces, en 2015, su empleado publicó una breve publicación titulada "¿Cuántas personas deberían discutir una tarea?" Ahora se conserva solo en el Archivo web . La esencia de la publicación fue la siguiente: el empleado recopiló estadísticas sobre los clientes, trazando la dependencia de la duración de la tarea en la cantidad de personas que la discutieron, el resultado fue el siguiente:



Se puede ver que la dependencia es no lineal. Por lo general, dos personas participan en la resolución de un problema que dura dos días, tres personas, cuatro días y cuatro personas, ya seis días. ¿Qué están haciendo allí? Podemos suponer que la tarea requiere varias etapas de trabajo, por ejemplo, en el caso de dos personas, Vasya hace su parte de la tarea y luego la transfiere a Petya, por lo que dura dos días. Tres personas ya pueden discutir y, una vez más, compartir responsabilidades, averiguar quién tiene la culpa y qué hacer, y un grupo de siete personas pasará seis días adicionales discutiendo, negociando y discutiendo entre sí.

Por supuesto, también se puede suponer que un equipo amigable de siete personas tiene tareas difíciles que son mucho más simples y cuantas más personas estén ocupadas con la tarea, mayor puede ser, ¡porque la amistad es mágica! Por lo tanto, tales consideraciones pueden parecer exageradas, y no las incluiré en los cálculos posteriores, sin embargo, si desea obtener una estimación más conservadora, no estaría fuera de lugar hacer alguna corrección para la no linealidad del crecimiento de costos con el crecimiento de la base del código del proyecto, que, por supuesto, También se incluyen pruebas unitarias, o para establecer un cierto margen de seguridad en los requisitos para el nivel de VPN.

Si explicamos la no linealidad de este cronograma únicamente por el crecimiento del tamaño del equipo, entonces los costos asociados con él se pueden estimar a partir de la siguiente tabla de la dependencia de la parte del tiempo perdido en la comunicación sobre el tamaño del grupo de trabajo:



Por ejemplo, si hay cinco desarrolladores en un equipo, y cree que necesita contratar a dos para que todos puedan dedicar un 40% adicional de su tiempo a las pruebas unitarias, prepárese para el hecho de que los costos de desarrollo pueden aumentar en más del 40%. El equipo crecerá y se volverá menos eficiente, en lugar de 5 * 0.625 = 3.125 unidades convencionales de productividad, tendrá 7 * 0.539 = 3.77 unidades, y la cantidad de trabajo aumentará de 1 a 1.4 unidades convencionales de trabajo, respectivamente, el tiempo requerido para el desarrollo aumentará en un 16%.

Una conclusión interesante que se puede extraer del gráfico es que cuando el número de personas es más de diez, el valor de cada nuevo participante se vuelve menor que el costo adicional de comunicación y la ley de Brooks comienza a funcionar. Solo queda tratar de dividir las tareas en tareas más pequeñas o involucrar a empleados más experimentados y eficientes en su implementación.

Por supuesto, es difícil decir que la no linealidad del gráfico de Assembla solo se asocia con una disminución de la eficiencia como resultado del crecimiento del equipo, pero está en buen acuerdo con la comprensión intuitiva de la complejidad y la ley de Brooks, por lo que si no desea correr riesgos y necesita una estimación conservadora, estos datos pueden Conviértete en una buena ayuda.

Los beneficios de las pruebas unitarias

Además de los costos, las pruebas unitarias también traen beneficios. Por supuesto, en la gran mayoría de los casos, un error que podría detectarse mediante pruebas unitarias se detectará en otros niveles de control de calidad, pero siempre existe la posibilidad de un fallo técnico y, en teoría, las pruebas unitarias pueden reducirlo. Personalmente, no conozco estos casos, afortunadamente, todos los evaluadores con los que trabajé eran personas extremadamente responsables, pero cuando se trata de probabilidades tan bajas, la experiencia personal puede ser poco representativa. Las fallas pueden tener diferentes consecuencias, por ejemplo, una compañía puede tener un SLA, cuya violación conllevará ciertas pérdidas financieras, por ejemplo, la compañía se verá obligada a dar a los clientes un mes de uso gratuito de sus servicios como compensación, perdiendo 1/12 de los ingresos. En este caso, ajustar el control de calidad, que reduce la probabilidad de violaciones de SLA durante el año del 10% al 8%, reducirá las pérdidas anuales promedio en aproximadamente un 0,17% de los ingresos. Este dinero será el componente positivo del flujo de caja que debe agregarse al modelo.

Tenga en cuenta que un cálculo tan simple es aplicable solo cuando la probabilidad de pérdidas es baja, si la probabilidad es superior al 15-20% y puede conducir a la quiebra o liquidación de la empresa, es aconsejable utilizar modelos de valoración opcionales, por ejemplo, como un árbol de decisión. Afortunadamente, en la mayoría de los casos, algún tipo de error estúpido no es algo que pueda llevar a la bancarrota a una empresa y no necesitamos sumergirnos en el horror de calcular el costo de las opciones.

Ejemplo uno: Bison

Bison es una gran tienda en línea, se hacen llamar el minorista en línea número 1 en Rusia. La compañía no es pública, pero en una reciente transacción de recapitalización, su capitalización total se estimó en 50 mil millones de rublos, que es el doble de los ingresos anuales. Se necesitaba una capitalización adicional debido a las pérdidas operativas, pero los accionistas esperan alcanzar un margen de beneficio operativo del 10% después de que la compañía logre obtener una mayor participación en el mercado y duplicar los ingresos dentro de un año, después de lo cual tendrá que comenzar a ganar, y el crecimiento de los ingresos disminuirá hasta un 30% en el segundo año, un 20% en el tercer año y finalmente establecido en un 10% en el cuarto y años posteriores. Sin embargo, los bancos no están muy seguros de esto y le dan a Bizon una larga advertencia, la deuda total de la compañía es de solo 10 mil millones de rublos a una tasa del 11%.Bison es una empresa bastante torpe y mal administrada a nivel operativo, la contratación descontrolada de empleados ya ha llevado al hecho de que emplea a 600 programadores, cuyo presupuesto de nómina total es de 1,5 mil millones de rublos por año y que gastan alrededor del 30% de su tiempo de trabajo en pruebas unitarias. La compañía no tiene obligaciones con los clientes y una falla técnica solo puede conducir a una interrupción temporal de las ventas, y en caso de falla, una reversión a la versión anterior del sitio demora aproximadamente una hora.

¿Cuál es el VPN del uso de pruebas unitarias en bisontes?

Los ingresos de Bison deben ser de 50, 65, 78 y 86 mil millones en el primer, segundo, tercer y cuarto año, respectivamente. Consideramos que la probabilidad de falla es del 33%, es decir, un incidente que puede abrumar su sitio durante mucho tiempo puede ocurrir aproximadamente una vez cada tres años, lo que no es tan malo. Suponga que el uso de pruebas unitarias puede reducirlo al 25% simplemente porque, además de los errores del desarrollador, también existe la posibilidad de varias fallas de hardware, ataques DDOS y otros problemas. Si el sitio web de la tienda en línea no está disponible durante una hora, el minorista no pierde más del 0.023% de los ingresos, incluso teniendo en cuenta el hecho de que los clientes están activos en promedio solo 12 horas al día. En otras palabras, las pruebas unitarias reducen las pérdidas de la compañía en 11.5 millones de rublos en el primer año, 14.8 en el segundo, 17.8 en el tercero y 19.6 millones en el cuarto año.

Incluso sin tener en cuenta el crecimiento del personal y los salarios de los desarrolladores, los costos de las pruebas unitarias ascenderán a 450 millones de rublos al año.

Creo que en esta etapa ya entiendes que las pruebas unitarias infligen un daño enorme en la condición financiera de Bison, incluso sin ajustar el aumento de la complejidad y los problemas asociados con la pérdida de capacidad de control. ¡Y esto ocurre en una situación en la que los accionistas se ven obligados a contribuir con dinero para financiar el trabajo de una empresa que genera pérdidas! Ningún otro cálculo puede rehabilitar las pruebas unitarias en este caso, pero continuaremos descubriendo cómo descontar el flujo de caja.

Volvamos a los desarrolladores, supongamos que la nómina crece un 10% por año, luego el efecto total de usar pruebas unitarias es -438, -480, -527 y -579 millones de rublos de pérdida operativa en el primer, segundo, tercer y cuarto año, respectivamente, después de lo cual la pérdida crece un 10% anual. Las pruebas unitarias en este caso no afectan los costos netos de capital y el capital de trabajo, pero la pérdida conduce a un ahorro fiscal del 20% del volumen de pérdida, respectivamente, debe multiplicarse por 0.8: -351, -384, -421 y -463 millones rublos

El EV de la compañía es de 50 + 10 = 60 mil millones de rublos, P representa el 83% del capital, D 17%, sabemos que el costo de la deuda es del 11% anual, luego, para calcular el WACC, solo queda encontrar el costo del capital. El bisonte funciona en Rusia, por lo tanto, como la tasa libre de riesgo, debe tomar el rendimiento efectivo de los bonos del gobierno con la mayor duración, ahora es del 7,6%. La prima por invertir en renta variable varía de un año a otro, pero por lo general está en la región del 4-6% anual, tomaremos el 5% y, para determinar el coeficiente β, miraremos el directorio y encontraremos allí el coeficiente de riesgo sin palanca para las empresas de la industria minorista en línea (sin palanca beta) igual a 1.3. Pero Bison tiene, aunque sea pequeño, pero deudas, por lo que debe hacer una enmienda y calcular el apalancamiento beta:

$$

Por lo tanto, la tasa de descuento WACC será

$$

Finalmente, calculamos la cantidad de pruebas unitarias para Bison, para esto descontamos los primeros años de crecimiento desigual por separado, y para los próximos años con un aumento del 10% por año, utilizamos el modelo Gordon.

El costo reducido del primer año será$$ millones de rublos, segundo $$ millones de terceros $$millones

A partir del cuarto año, las pérdidas crecen uniformemente en un 10% por año, respectivamente, después del tercer año, la fórmula puede calcular la pérdida nominal de las pruebas unitarias.$$ millones para ser traídos al primer año: $$Un millón de rublos.
En general, el daño por usar pruebas unitarias es$$ mil millones de rublos.

Ejemplo dos: hiperestal

Vasily es un prometedor graduado del Colegio de Tecnologías Innovadoras de Chelyabinsk. No hay Amazonas y Google en Chelyabinsk, pero hay muchas empresas siderúrgicas, una de las cuales tuvo la suerte de obtener. Al final resultó que, los presupuestos son modestos, el dinero es crónicamente corto, por lo que podría permitirse contratar a un programador solo con un salario de menos de 50 mil rublos, incluidos todos los impuestos y pagos obligatorios. La primera tarea de Vasily fue el software para controlar el funcionamiento de un alto horno. Este proyecto no debería demorar más de dos meses y es poco probable que reciba más apoyo y desarrollo.
Durante la visita de Vasily al taller, el especialista a cargo de la producción le dijo en términos generales lo siguiente: “¡Estimado colega! Presta atención a este cubo gigante de metal fundido. Si algo sale mal, no solo estaremos extremadamente desanimados, sino que también nos enfrentaremos a dificultades tecnológicas. El hecho es que si el alto horno se eleva, el metal en su interior se endurece y tomará tres meses eliminar las consecuencias del accidente. "No será fácil lidiar con una pieza gigante de metal en el taller y reemplazarla con un nuevo alto horno". Más tarde, Vasily descubrió que una parada de emergencia para un alto horno podría costarle a la compañía 8 mil millones de rublos.
Pregunta: ¿Vasily está preocupado por escribir pruebas unitarias?
Como ya no tengo la fuerza y ​​la paciencia para calcular lo obvio, diré inmediatamente la respuesta: por supuesto que sí. Vasily no tiene experiencia, tiene una alta probabilidad de cometer un error (doy el 50 por ciento, que solo sin la ayuda de colegas y sin un control de calidad adecuado, su programa fallará en algún lugar y el 10 por ciento, lo que conducirá a un accidente), su tiempo no vale nada, y el precio del error es extremadamente alto. Dado que en este ejemplo estamos hablando de un proyecto corto que se escribirá y se olvidará, no hay necesidad de descontar nada, es suficiente comparar el salario de Vasily durante dos meses, igual a 100 mil rublos y la pérdida esperada de alrededor del 10% * 8 mil millones = 800 millones de rublos.

Ejemplo tres: XSoft

XSoft es una exitosa compañía de outsourcing que acaba de firmar un contrato con otro cliente occidental. El cliente planea contratar a 7 programadores, su presupuesto en esta parte es de 15 millones de rublos al año, de los cuales XSoft tomará 3 millones. El cliente es una bardana y no entiende nada en el desarrollo. Desde el punto de vista de XSoft, ¿deberían los desarrolladores escribir pruebas unitarias?

Por supuesto que si! En este caso, el costo de escribir y respaldar las pruebas unitarias es asumido por el cliente, y para el contratista, la cantidad adicional de trabajo solo significa aumentar la duración del proyecto y las ganancias adicionales, que es al menos proporcional al número de horas hombre dedicadas a las pruebas unitarias y, en el mejor de los casos, crece más rápido que -para aumentar la base del código y la complejidad del proyecto. Con su permiso, no desarrollaré más esta idea, profundizaré en los detalles íntimos de la relación del subcontratista con el cliente y descontaré sus flujos de efectivo, ya que la conclusión ya es obvia.

Epílogo

El artículo resultó ser extenso, y espero no haberlo intentado en vano. Como cualquier proyecto en cualquier negocio, la decisión de usar pruebas unitarias en su proyecto debe estar económicamente justificada. Cuando las empresas de otras industrias planean comprar una máquina, abrir una fábrica o tienda, sin duda calcularán el VPN y / o la TIR. Es triste ver cómo TI sigue siendo una industria descuidada a este respecto. Pero conocer los conceptos básicos de las finanzas y el hábito de abrir Excel a tiempo puede brindarle una ventaja notable sobre sus competidores.