Pasamos más tiempo implementando pruebas funcionales que implementando el propio sistema, ¿es esto normal?

12

Básicamente, tenemos tres proyectos principales, dos de ellos son servicios web y el otro es una aplicación web. Aunque estoy satisfecho con cubrir tanto como podamos de nuestros servicios web con pruebas funcionales (los tres proyectos tienen sus pruebas unitarias correctas), las pruebas funcionales para la aplicación web están demorando mucho tiempo en implementarse. Por mucho me refiero a dos veces, o a veces más, el tiempo que lleva implementar la funcionalidad que se está probando con la prueba de unidad incluida.

La política del administrador es probar cada una de las funciones que agregamos, incluso si no es crítica para el negocio (es decir, un nuevo C.R.U.D).

Estoy de acuerdo con probar todas las funciones de los servicios web, porque es difícil probarlas manualmente y, además, estas pruebas se ejecutan rápidamente y no requieren mucho para implementarlas.

Entonces, ¿cuál es el valor de pasar más tiempo escribiendo la prueba funcional, que escribiendo el código del sistema, la prueba de la unidad y arreglando las cuentas de control de calidad? ¿Esto es normal? ¿No deberíamos escribir pruebas funcionales solo para funciones críticas y permitir que QA realice pruebas de regresión en lugar de funciones críticas?

Nota: no estamos desarrollando software médico o software de la NASA o nada que sea crítico.

    
pregunta Pablo Lascano 04.02.2013 - 22:48

6 respuestas

16

Las pruebas funcionales son muy importantes. Sí, toman tiempo para escribir, pero si estás escribiendo las pruebas funcionales correctas, valdrán la pena.

Hay algunas buenas razones para realizar pruebas funcionales automatizadas en una aplicación.

  • Cuando se agrega una nueva característica a su sitio web, le informa de inmediato si los cambios realizados para esa nueva característica rompen cualquier otra funcionalidad en su sitio.
  • Es un conocimiento documentado de cómo la aplicación se ejecuta y funciona en conjunto para lograr los requisitos comerciales.
  • Cuando sea el momento de actualizar una biblioteca de terceros, puede actualizarla y ejecutar su conjunto de prueba funcional para ver si algo se rompe. En lugar de tener que pasar por cada página, puede hacer que una computadora lo haga por usted y le dé una lista de todas las pruebas que se rompieron.
  • pruebas de carga! Puede simular miles de usuarios simultáneos que llegan a su sitio a la vez y puede ver dónde se ralentiza su sitio y se dobla bajo la presión. Puedes ver cómo se comporta tu sitio web mucho antes de que recibas una llamada nocturna que dice que el sitio se ha bloqueado.
  • Las pruebas funcionales toman tiempo para hacerlas manualmente. Sí, lleva mucho tiempo escribir los casos, ¡pero si tuvo que sentarse con una carpeta con 500 páginas de pruebas que tenía que completar antes de poder enviar el producto, le gustaría que se realizara las pruebas automatizadas!
  • Los documentos de prueba se desactualizan rápidamente. Cuando se agrega una nueva función, debe asegurarse de actualizar el documento de prueba maestro. Si alguien se salta algunas pruebas, todos ustedes los errores repentinos se arrastran hacia páginas que están "hechas y probadas" yo Actualmente trabajo en un entorno como ese, y te puedo asegurar, es una pesadilla.

Al final, sí, lleva tiempo escribir estos casos, pero debe enorgullecerse de escribirlos. Es su forma de demostrar, sin lugar a dudas, que su código funciona y funciona con todas las otras características que existen. Cuando el QA llega a usted y dice que hay un error, lo arregla y luego lo agrega a su conjunto de pruebas para demostrar que está solucionado y asegurarse de que nunca vuelva a suceder.

Es tu red de seguridad. Cuando alguien entra y secuestra un proceso almacenado y realiza un pequeño cambio para que funcione con su código, se dará cuenta de que ha roto otras 3 funciones en el proceso. ¡Lo atraparás esa noche y no la noche anterior a la fecha límite!

En cuanto a escribir pruebas funcionales solo para funciones críticas del sistema. Eso no te dará la imagen completa y permitirá que los insectos se escapen. Todo lo que necesita es agregar una pequeña característica que no sea crítica para el sistema, pero que interactúe indirectamente con una función crítica del sistema y que tenga la posibilidad de que se presente un error.

    
respondido por el Tyanna 05.02.2013 - 01:29
7

Más de 2 veces ... me parece un poco demasiado. Es posible que desee analizar los motivos de esto, podrían incluir:

  • soporte de herramientas incorrectas para la creación y mantenimiento de las pruebas

  • los contratos de los servicios web no están suficientemente descritos en el diseño. Los desarrolladores deben elaborar los contratos mientras realizan las pruebas, lo que suele llevar mucho tiempo el proceso de alineación.

Habla con tus desarrolladores.

Suponiendo que está desarrollando en sprints, realice estas pruebas funcionales solo como parte del sprint. No se hace sin estas pruebas. Si no lo tiene, su tiempo para las pruebas de integración después de la fase de desarrollo podría duplicarse.

    
respondido por el Andreas Huppert 04.02.2013 - 23:53
3

¿Pasar más tiempo implementando la prueba funcional que implementando el sistema en sí es normal?

Absolutamente. Escribir pruebas realmente buenas es probable que tome la mayor parte del tiempo en muchas (buenas) tiendas.
Así que una proporción de 2-1 está bien. Los desarrolladores con menos experiencia a menudo no toman todo el tiempo para las pruebas en cuenta.

    
respondido por el Michael Durrant 05.02.2013 - 03:28
1

Se trata de calidad.

Si necesita obtener el mercado, desarrollará su aplicación lo más rápido posible. Incluso puede no tener pruebas automáticas en absoluto =) pero entregará su aplicación a su auditorio antes que sus competidores.

Pero si sabe que su auditorio no desaparecerá, hará todo lo posible para no decepcionarlos. Cada ticket de error derribará tu reputación. Imagina que un error eliminará el 50 por ciento de tu reputación, el otro, otro 25 por ciento y uno más. Entonces, ¿puede haber demasiadas pruebas?

    
respondido por el Nikita U. 04.02.2013 - 23:25
1

Existe la ley de rendimientos decrecientes. Suponiendo que escriba primero las pruebas para el código más riesgoso, el valor generado por otras pruebas disminuye con el tiempo.

Las pruebas unitarias son código, por lo que contendrán errores (al igual que todos los demás códigos). Arreglar esos errores lleva tiempo.

En mi experiencia, las pruebas unitarias contienen muchos más errores que el sistema que están probando, y solucionarlos es una carga continua.

    
respondido por el user147272 17.06.2016 - 16:22
0

Si por "es normal" usted pregunta si es común, no, ciertamente no lo es. Muchos equipos de desarrollo tienen prácticas de prueba deficientes (pertenezco a una) e incluso libros de calidad. He leído consejos para dedicar aproximadamente tanto tiempo a la codificación de la funcionalidad como a las pruebas. Si lo normal es que preguntes si es saludable, depende, pero dos veces más pruebas de las necesarias es mejor que ninguna prueba.

No tiene que ser crítico . Cuando prueba una funcionalidad, prueba algo útil para usuarios finales, y es su responsabilidad saber (y no adivinar) que todo el tiempo funciona correctamente. Si necesita dos veces más para ese objetivo, entonces debe hacerse de esa manera, si es posible.

También es posible que su política sea demasiado estricta con respecto a las pruebas automatizadas, pero es difícil decirlo sin saber la calidad a la que apuntan, sus recursos y cualquier otra cosa a la que puedan asignar.

    
respondido por el Arthur Havlicek 17.06.2016 - 19:03

Lea otras preguntas en las etiquetas