¿Las pruebas de software se realizan realmente en proyectos profesionales?

He participado en muchos proyectos en varias compañías porque he sido desarrollador durante mucho tiempo y soy contratista.

Calculo que menos del 20% de los proyectos se prueban metódicamente. Con pruebas metódicas me refiero a cualquier prueba más allá de la prueba ad-hoc sin plan.

También calculo que menos del 10% de los proyectos se someten a pruebas metódicas exhaustivas cuando cuentan con evaluadores dedicados como parte del equipo, documento del plan de prueba, donde los desarrolladores escriben pruebas automatizadas y luego también realizan un seguimiento de la cobertura de la prueba y miden los resultados.

Dos preguntas

1. ¿Cuáles son sus porcentajes estimados sobre este tema?
2. ¿Cuál es su experiencia profesional con respecto a las pruebas de software?

Nota adicional

Dado que la pregunta de prueba metódica puede obtener respuestas bastante sesgadas (a la gente le gusta alardear de ser superior a los demás), aliento a otros desarrolladores (aquellos que no están expuestos a la prueba metódica) a que también brinden su respuesta, porque de lo contrario parecería que la prueba es se hace en todas partes ... excepto en su empresa.

El patrón que he visto al probar durante mi carrera muestra una fuerte correspondencia con el riesgo de fracaso en un proyecto. Los proyectos grandes tienen más probabilidades de ser probados que los pequeños, las aplicaciones de misión crítica tienen más probabilidades de ser probadas que las de sitios web de marketing, los sistemas internos tienen menos probabilidades de ser probados que los públicos.

Dicho esto, todavía hay proyectos que se han probado en exceso y aquellos que no se han probado lo suficiente, pero estos son la minoría.

Todo lo que producimos se prueba completamente. Si nuestro equipo interno de control de calidad está sobrecargado, tenemos un equipo offshore que prueba los proyectos. No son tan buenos como nuestro equipo interno, pero ese es un tema diferente.

Las tres empresas para las que he trabajado durante los últimos 15 años tuvieron pruebas unitarias que se ejecutaron automáticamente.

En dos de esas compañías presioné para presentarlas.

En los últimos 9 años, básicamente solo he cumplido con las pruebas de aceptación / regresión. Solo hubo unas pocas pruebas unitarias.

Sí.

La cantidad de pruebas es proporcional a la confiabilidad requerida de la aplicación, así como a la madurez de la cultura del programador.

Con frecuencia, los sitios web caminan con agujeros de error (los enlaces rotos son un defecto).

Los videojuegos suelen tener errores.

Windows (finalmente) es bastante confiable.

Los enrutadores son muy confiables

Los monitores del hospital "no se rompen"

Tenga en cuenta que el costo fiscal de la falla también se correlaciona con la confiabilidad.

En 10 años nunca trabajé en un proyecto con pruebas formales de código.

En mi trabajo actual solo tenemos pruebas funcionales.

El problema es que nadie en la administración sabe siquiera sobre las pruebas de código. El departamento de pruebas ni siquiera sabe acerca de las pruebas de código, solo siguen las especificaciones de alto nivel y verifican si cumplimos desde un punto de vista conductual / funcional.

No tenemos un líder de software calificado que nos obligue a codificar bien. El resultado es un código de espagueti, muchas regresiones, horarios perdidos, etc.

Somos una empresa offshore de tamaño medio en el sur de Asia. Sin embargo, siempre realizamos proyectos basados ​​en EE. UU. Y trabajamos directamente con los requisitos enviados por la empresa estadounidense.

Aplicamos pruebas metódicas en cada aplicación que creamos. Quizás, la calidad de las pruebas no está a la altura, pero las empleamos.

Por mucho que el purista en mí no quiera aceptar que tiene que haber una gestión de riesgos incorporada en la decisión de cuán rigurosamente prueba o si realiza pruebas formales. Para las aplicaciones internas, que sospecho que son un gran porcentaje de proyectos de programación, el costo de liberar un error y luego repararlo rápidamente después de notarlo a veces puede ser compensado por el costo de un equipo de prueba completo. Por supuesto, depende de la aplicación y del costo potencial de las fallas.

Dicho esto, no creo que la planificación de la gestión de riesgos sea la razón de la falta de pruebas formalizadas. Creo que es más el resultado de que los gerentes no técnicos no entienden el valor que proporciona y solo ven el costo.

Mi muestra es muy pequeña para deducir porcentajes, pero aquí va de todos modos.

Una de ellas era una compañía de chips + firmware fabless, que realizó pruebas fanáticas. Pruebas automatizadas las 24 horas del día, los 7 días de la semana en decenas de instalaciones, cada una de las cuales prueba decenas de unidades en paralelo. Equipos de software dedicados al desarrollo de software de prueba. Equipos de hardware dedicados a la construcción de plataformas de prueba. Pruebas de compatibilidad contra decenas de competidores. Diablos, incluso compraron una instalación multimillonaria de probadores de chips para desarrollar y depurar algunas de las pruebas que los fabs ejecutan cuando los chips salen de la fundición.

Otro era un banco. Este es un entorno completamente diferente: no hay lanzamientos de productos, pero sí muchísimo software interno para seguir funcionando continuamente. Estos tipos probaron la cr * p de cada cambio que hicieron. Tenían una separación muy estricta de los entornos DEV / QA / PROD, pruebas de regresión automatizadas, pruebas de control de calidad obligatorias firmadas por los usuarios finales antes de su lanzamiento a producción, etc.

Entonces, sí, la gente hace pruebas metódicas. Pero como puede ver, nunca he trabajado en un lugar que envíe su software GUI típico para el usuario típico de la computadora.

Actualmente escribo firmware integrado para una pequeña empresa de inicio que fabrica dispositivos médicos inalámbricos. Estamos obligados a realizar pruebas rigurosas, y tenemos un departamento de calidad completamente separado dirigido por alguien que informa directamente al CEO. Nunca antes había probado mi código de manera tan exhaustiva por probadores separados (la única vez que se compara es cuando estaba trabajando en sistemas de televisión por satélite hace aproximadamente 15 años).

Los resultados de nuestras pruebas se envían a la FDA (hasta ahora hemos obtenido dos autorizaciones de la FDA: cada presentación tenía alrededor de 500 páginas). Nuestras metodologías de desarrollo y prueba están sujetas a auditorías periódicas.

Por lo tanto, no solo las grandes empresas hacen muchas pruebas formales.

Nota: en mis más de 25 años de programación / consultoría por contrato, también he trabajado para muchas compañías que prácticamente no realizaron pruebas formales. La mayoría de ellos ya no están.

Casi todas las empresas en las que he estado hicieron pruebas metódicas. Mi compañía actual tiene algunas pruebas básicas de estilo de unidad y eso no es suficiente. Hemos tenido algunos problemas de calidad debido a esto. Recomiendo pruebas exhaustivas independientes en cualquier proyecto que sea utilizado por cualquier persona además de usted. El dinero gastado valdrá la pena. Las aplicaciones que no funcionan no se utilizan. Eso se aplica tanto para enfrentar internamente como para enfrentar externamente.

En los últimos veinte años de mi carrera en ocho o más compañías, nunca he trabajado en un proyecto que no haya realizado pruebas. La cantidad de pruebas fue diferente en cada empresa, pero cada proyecto de desarrollo profesional en el que he trabajado realizó pruebas formales. Esto se aplica igualmente a las pequeñas y medianas empresas (donde "pequeño" significa menos de 10 empleados y "mediano" significa un par de miles de empleados o menos).

Algunas compañías no tenían muchas pruebas automatizadas, algunas no tenían muchas pruebas manuales, pero tenían al menos una u otra.

Depende de las necesidades del cliente. En una situación contractual, probablemente haya pruebas de aceptación. En casa suele ser una bofetada con pocas pruebas. Los productos de consumo suelen estar muy cubiertos de funcionalidad frecuente, pero son toscos.

Respuesta corta: sí

Respuesta larga:

1. No tengo una buena estimación para la primera categoría (probablemente esté a cierta distancia de cero, pero ¿cuánto?), Pero mi experiencia en realidad corrobora con su segunda estimación. Es difícil dar porcentajes significativos, ya que la cantidad y el tipo de pruebas dependen del tipo de aplicación que se desarrolle y del marco de tiempo disponible, así como del conjunto de habilidades de los desarrolladores y de cómo se ejecuta el proyecto. En la práctica, el obstáculo más importante para los desarrolladores sería la prueba de aceptación, ya que es un hito importante para fines de facturación. Pero también es el momento en que puede ocurrir lo inesperado (más requisitos) y los desarrolladores pueden verse presionados a entregar y superar cualquier prueba ad hoc que sea posible y oportuna (en esta etapa), además del tiempo necesario para la resolución de problemas y la superación lo inesperado.

2. He pasado por una variedad de proyectos con diferentes combinaciones de factores mencionados anteriormente:

   • sin pruebas unitarias formales, solo pruebas de integración y principalmente pruebas ad hoc

   • muy formal, desde pruebas unitarias hasta planes de prueba detallados que involucran recursos de control de calidad dedicados, pruebas automatizadas (realizadas por los probadores con su propio conjunto de herramientas) e informes de cobertura de código. Pero esto no siempre es significativo tanto para los desarrolladores como para los gerentes

A nivel individual, trato de mantener una comprensión de mis opciones cuando se trata de escribir pruebas apropiadas y apropiadas para la tecnología con la que estoy trabajando, y ejercitarlas a mi propia discreción. Básicamente, las cosas que en realidad son significativas y beneficiosas para mi trabajo, y no tanto para obtener números.