it-swarm-es.com

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

He estado involucrado en muchos proyectos en varias empresas porque he sido desarrollador durante mucho tiempo y soy contratista.

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

También estimo que menos del 10% de los proyectos se prueban minuciosamente metódicamente donde tienen probadores dedicados como parte del equipo, documento del plan de prueba, donde los desarrolladores escriben pruebas automatizadas y luego también hacen un seguimiento de la cobertura de prueba y miden resultados.

Dos preguntas

  1. ¿Cuáles son sus estimaciones porcentuales 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 presumir de ser superior a los demás), yo animo a otros desarrolladores (aquellos que no están expuestos a pruebas metódicas) a dar su respuesta también, porque de lo contrario, parecerá que se están realizando pruebas en todas partes ... excepto en su empresa.

27
Robert Koritnik

El patrón que he visto con las pruebas a lo largo de mi carrera muestra una fuerte correspondencia con el riesgo de fracaso en un proyecto. Es más probable que se prueben los proyectos grandes que los pequeños, es más probable que se prueben las aplicaciones de misión crítica que los sitios web de marketing únicos, es menos probable que se prueben los sistemas internos que los de cara al público.

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

11
Martin Brown

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

6
Ali

Si.

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

Los sitios web son a menudo agujeros de error (enlaces rotos son un defecto).

Los videojuegos suelen tener errores.

Windows (finalmente) es bastante confiable.

Los enrutadores son muy confiables

Los monitores de hospital "no se rompen"

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

4
Paul Nathan

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 está al tanto de las pruebas de código. El departamento de pruebas ni siquiera sabe sobre el código de prueba; en un nivel alto, solo siguen las especificaciones de alto nivel y verifican que las cumplamos, desde un punto de vista de comportamiento/funcional.

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

4
Wizard79

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

Una era una empresa sin fábrica de chips + firmware, que hacía pruebas fanáticas. Pruebas automatizadas 24/7 en decenas de instalaciones, cada una de las cuales prueba decenas de unidades en paralelo. Equipos de software dedicados al desarrollo de software de pruebas. Equipos de hardware dedicados a la construcción de bancos de pruebas. Pruebas de compatibilidad contra decenas de competidores. Demonios, incluso compraron una instalación de probador de chips de varios millones de dólares para desarrollar y depurar algunas de las pruebas que ejecutan las fábricas cuando los chips salen de la fundición.

Otro era un banco. Este es un entorno completamente diferente: no hay lanzamientos de productos, pero mucho, mucho software interno para seguir funcionando continuamente. Estos chicos probaron el cr * p con 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.

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

3
Roman Starkov

Actualmente escribo firmware integrado para una pequeña empresa de nueva creación que fabrica dispositivos médicos inalámbricos. Estamos obligados a realizar pruebas rigurosas y tener un departamento de calidad completamente independiente dirigido por alguien que depende directamente del director ejecutivo. Nunca antes había probado mi código tan a fondo por probadores separados (la única vez que se compara es cuando estaba trabajando en sistemas de televisión por satélite hace unos 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). Tanto nuestras metodologías de desarrollo como de prueba están sujetas a auditorías periódicas.

Por lo tanto, no son solo las grandes empresas las que realizan 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 empresas que prácticamente no realizaron pruebas formales. La mayoría de ellos ya no existen.

3
tcrosley

Las tres empresas para las que he trabajado durante los últimos 15 años tenían pruebas unitarias que se ejecutaban automáticamente.

En dos de esas empresas presioné para introducirlos.

3
sbi

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

3
LennyProgrammers

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

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

2
Shamim Hafiz

Por mucho que el purista que hay en mí no quiera aceptar que tiene que haber una gestión de riesgos incorporada en la decisión de cuán rigurosamente se prueba o si se realiza alguna prueba formalizada. Para las aplicaciones internas, que sospecho que son un gran% de proyectos de programación, el costo de liberar un error y luego parchearlo rápidamente después de que se note puede a veces ser superado 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.

2
JohnFx

En los últimos veinte años o más de mi carrera a través de ocho compañías, nunca he trabajado en un proyecto que no hiciera pruebas. La cantidad de pruebas difiere en cada empresa, pero todos los proyectos de desarrollo profesional en los que he trabajado hacían pruebas formales. Esto se aplica igualmente a las empresas pequeñas y medianas (donde "pequeña" significa menos de 10 empleados y "mediana" significa un par de miles de empleados o menos).

Algunas empresas no tenían muchas pruebas automatizadas, otras no tenían muchas pruebas manuales, pero tenían al menos una u otra.

0
Bryan Oakley

Casi todas las empresas en las que he estado hicieron pruebas metódicas. Mi empresa actual tiene algunas pruebas básicas de estilo unitario y eso no es suficiente. Hemos tenido algunos problemas de calidad debido a esto. Recomiendo encarecidamente realizar pruebas exhaustivas independientes en cualquier proyecto que vaya a ser utilizado por cualquier persona que no sea usted. El dinero gastado valdrá la pena. Las aplicaciones que no funcionan no se utilizan. Eso se aplica tanto al interior como al exterior.

0
Bill Leeper

Depende de las necesidades del cliente. En una situación de contrato, probablemente haya pruebas de aceptación. En la empresa suele ser una tarea fácil con pocas pruebas. Las cosas de consumo generalmente están muy cubiertas en funcionalidad frecuente, pero son toscas en los bordes.

0
anon

Respuesta corta: si

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 prueba depende del tipo de aplicación que se está desarrollando, el período de tiempo disponible y el conjunto de habilidades de los desarrolladores y 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 el que puede suceder lo inesperado (más requisitos) y los desarrolladores pueden verse presionados para cumplir y salir adelante con 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 en su mayoría pruebas ad hoc

    • muy formal que van 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 estos no siempre son tan significativos para los desarrolladores como para los gerentes.

A nivel individual, trato de mantener un entendimiento de mis opciones cuando se trata de escribir pruebas apropiadas para la tecnología con la que estoy tratando, y las ejercito a mi propia discreción. Básicamente, las cosas que son realmente significativas y beneficiosas para mi trabajo, y no tanto hacer números.

0
prusswan

Considere, por ejemplo, la biblioteca CPAN que es el cuerpo central del software contribuido para el lenguaje de programación Perl ...

En cualquier momento y cada vez que instala un paquete de esta [vasta ...] biblioteca, se ejecuta un conjunto automatizado de pruebas proporcionadas por el autor del paquete su máquina. Si alguna de esas pruebas falla, el paquete no se instalará.

Y luego, está "CPANTS". https://cpants.cpanauthors.org/

CPANTS es un servicio de prueba para distribuciones CPAN. Uno de sus objetivos es proporcionar algún tipo de medida de calidad llamada Kwalitee. Aunque parece y suena como calidad, una puntuación de Kwalitee más alta no siempre significa que una distribución sea más útil para usted. Todo lo que puede asegurar es que es menos probable que encuentre problemas en la instalación, el formato de los manuales, las licencias o tal vez la portabilidad, ya que la mayoría de las métricas de CPANTS se basan en problemas anteriores de la cadena de herramientas/control de calidad que puede recordar o no.

Sí ... este servicio automatizado prueba constantemente los nuevos lanzamientos de paquetes de CPAN, en todo tipo de plataformas de hardware y software muy diferentes (que se supone que el paquete es compatible ...) y prueba si realmente lo hace.

Por supuesto, esta no es la única biblioteca (o idioma) que hace esto de forma rutinaria.


Hace mucho tiempo, me di cuenta del valor personal del "desarrollo impulsado por pruebas". Escribe una clase, luego escribe una prueba para ella. A medida que continúe agregando al sistema, ejecute constantemente todas las pruebas.

"¡¡Suh-premio !!"

Wow ... ¿cómo rompimos esto? ... bueno, estoy contento de haber atrapado ese ¡uno antes! ¡Hubiera sido muy desagradable si hubiera llegado a producción!

UH Huh. Una vez que aprenda esa lección por sí mismo, incluso cuando sea el único desarrollador del proyecto, no la olvide.

0
Mike Robinson