Estamos pasando más tiempo implementando pruebas funcionales que implementando el sistema en sí, ¿es esto normal?

Básicamente, tenemos tres proyectos principales, dos de ellos son servicios web y el otro es una aplicación web. Si bien estoy satisfecho con cubrir todo lo que podamos de nuestros servicios web con pruebas funcionales (los tres proyectos tienen sus pruebas unitarias adecuadas), las pruebas funcionales para la aplicación web requieren mucho tiempo para que el desarrollador las implemente. Por mucho quiero decir dos veces, o algunas veces más, el tiempo que lleva implementar la funcionalidad que se está probando con la prueba unitaria incluida.

La política del administrador es probar cada funcionalidad que agreguemos, incluso si no es crítica para el negocio (es decir, un nuevo CRUD).

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 tiempo para implementarlas.

Entonces, ¿cuál es el valor de pasar más tiempo escribiendo pruebas funcionales, que escribiendo código del sistema, prueba unitaria y arreglando tikets de control de calidad? ¿Esto es normal? ¿No deberíamos escribir pruebas funcionales solo para la funcionalidad crítica y dejar que el control de calidad haga pruebas de regresión sobre ninguna funcionalidad crítica?

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

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

Existen 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 se ejecuta y funciona la aplicación en conjunto para lograr los requisitos comerciales.
• Cuando llegue el momento de actualizar una biblioteca de terceros, puede actualizarla y ejecutar su conjunto de pruebas funcionales para ver si algo se rompe. En lugar de tener que pasar por cada página usted mismo, puede hacer que una computadora lo haga por usted y le dé una lista de todas las pruebas que se rompieron.
• ¡Prueba de carga! Puede simular miles de usuarios simultáneos que acceden a su sitio a la vez y puede ver dónde su sitio se ralentiza y se dobla bajo la presión. Puede ver cómo se comporta su sitio web mucho antes de recibir una llamada nocturna que el sitio se ha bloqueado.
• Las pruebas funcionales requieren tiempo para realizarse manualmente. Sí, lleva mucho tiempo escribir los casos, pero si tuviera que sentarse con una carpeta con 500 páginas de pruebas que tenía que completar antes de poder enviar el producto, ¡desearía tener 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 omite algunas pruebas, de repente, los errores se arrastran en las páginas que están "hechas y probadas". Actualmente trabajo en un entorno como ese, y puedo asegurarles que es una pesadilla.

Al final, sí, lleva tiempo escribir estos casos, pero debe enorgullecerse de escribirlos. Es su forma de probar, sin lugar a dudas, que su código funciona y funciona con todas las demás funciones que existen. Cuando el control de calidad llega a usted y dice que hay un error, lo arregla y luego lo agrega a su conjunto de pruebas para mostrar 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 hace un pequeño cambio para que funcione con su código, notarás que ha roto otras 3 características 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 le dará la imagen completa y permitirá que los errores se escapen. Todo lo que se necesita es que se agregue una pequeña característica que no es crítica para el sistema, pero que interactúa indirectamente con una función crítica del sistema y usted tiene el potencial de tener un error introducido.

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

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

• los contratos de los servicios web no se describen suficientemente en el diseño. Los desarrolladores necesitan resolver los contratos durante las pruebas, que generalmente es un proceso de alineación que requiere mucho tiempo.

Habla con tus desarrolladores.

Suponiendo que se está desarrollando en sprints, estas pruebas funcionales son solo una 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.

¿Pasar más tiempo implementando pruebas funcionales que implementando el sistema en sí es normal?

Absolutamente. Es probable que escribir pruebas realmente buenas tome la mayoría del tiempo en muchas (buenas) tiendas.
Entonces una relación 2-1 está bien. Los desarrolladores menos experimentados a menudo no toman en cuenta todo el tiempo para las pruebas.

Existe la ley de rendimientos decrecientes. Suponiendo que primero escribe pruebas para el código más riesgoso, el valor generado por las pruebas adicionales 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 corregirlos es una carga continua.

Esto se trata de calidad.

Si necesita salir al 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 audición no desaparecerá, hará todo lo posible para no decepcionarlos. Cada boleto de error reducirá tu reputación Imagine que un error eliminará el 50 por ciento de su reputación, el siguiente, otro 25 por ciento y uno más. Entonces, ¿puede haber demasiadas pruebas?

Si por "es normal" preguntas si es común, no, ciertamente no lo es. Muchos equipos de desarrollo tienen malas prácticas de prueba (pertenezco a uno) e incluso libros de calidad que he leído consejos para pasar aproximadamente el mismo tiempo codificando la funcionalidad que las pruebas. Si normalmente pregunta si es saludable, depende, pero dos veces más pruebas de las necesarias es mejor que ninguna.

No tiene que ser crítico . Cuando prueba una funcionalidad, prueba algo útil para los 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 saberlo sin conocer la calidad a la que apuntan, sus recursos y a qué otra cosa podrían destinarla.