¿Necesitamos datos de prueba o podemos confiar en pruebas unitarias y pruebas manuales?

Actualmente estamos trabajando en un proyecto PHP / MySQL mediano / grande. Estamos realizando pruebas unitarias con PHPUnit y QUnit y tenemos dos probadores de tiempo completo que prueban manualmente la aplicación. Nuestros datos de prueba (simulados) se crean actualmente con scripts SQL.

Tenemos problemas con el mantenimiento de scripts para datos de prueba. La lógica de negocios es bastante compleja y un cambio "simple" en los datos de prueba a menudo produce varios errores en la aplicación (que no son errores reales, solo el producto de datos no válidos). Esto se ha convertido en una gran carga para todo el equipo porque constantemente estamos creando y cambiando tablas.

Realmente no veo el punto de mantener los datos de prueba en los scripts porque todo se puede agregar manualmente en la aplicación en aproximadamente 5 minutos con la interfaz de usuario. Nuestro primer ministro no está de acuerdo y dice que tener un proyecto que no podemos implementar con datos de prueba es una mala práctica.

¿Deberíamos abandonar el mantenimiento de los scripts con datos de prueba y simplemente dejar que los evaluadores prueben la aplicación sin datos? ¿Cuál es la mejor práctica?

testing unit-testing quality manual-testing Christian P
fuente

Respuestas:

Estás mezclando dos conceptos diferentes. Una es la verificación , que se basa en pruebas unitarias y revisiones por pares. Esto lo pueden hacer los propios desarrolladores, sin datos de prueba y su intención es verificar que se cumplan un conjunto de requisitos.

El segundo es la validación , y esto lo realiza QA (sus evaluadores). Para este paso, necesita datos de prueba ya que el probador no necesita tener ningún conocimiento de la programación en la aplicación, solo sus casos de uso previstos. Su objetivo es validar que la aplicación se comporta según lo previsto en un entorno de producción.

Ambos procesos son importantes y necesarios para entregar un producto de calidad al cliente. No puede confiar solo en las pruebas unitarias. Lo que necesita descubrir es una forma confiable de manejar sus datos de prueba para garantizar que sean válidos.

EDITAR: OK, entiendo lo que estás preguntando. La respuesta es sí, porque el trabajo del Probador no es generar los datos de prueba, solo probar la aplicación. Necesita construir sus scripts de una manera que permita un mantenimiento más fácil y garantice la inserción de datos válidos. Sin los datos de prueba, el probador no tendrá nada que probar. Dicho esto, sin embargo, si tiene acceso al entorno de prueba , no veo por qué no puede insertar los datos de prueba manualmente en lugar de usar scripts.

AJC
fuente

Tal vez dije mal mi pregunta al mencionar la prueba de la unidad y los datos de prueba. Entiendo que la validación no es lo mismo que la prueba unitaria. Mi problema aquí es que los datos de prueba que estamos creando con los scripts se pueden crear a través de la interfaz de usuario en 5 minutos. Para insertar estos datos en la aplicación, no necesita conocer la programación, solo debe seguir los casos de prueba.

Christian P

@ christian.p revise mi actualización con respecto a su aclaración de la pregunta.

AJC

Entonces, ¿su solución es abandonar los scripts y solo agregar datos de prueba manualmente a través de la interfaz de usuario? ¿Qué pasa con la respuesta que P.Brian.Mackey proporcionó y sus respuestas para acoplar los datos con la interfaz de usuario?

Christian P

@ christian.p Bueno, estoy de acuerdo en que debes usar scripts. PERO no hay formalidad o regla que diga que TIENES que hacerlo. La razón principal para usar scripts para generar datos simulados es la velocidad (automatización) y el acceso (al entorno de prueba). Si tiene acceso y ES MÁS rápido y fácil hacerlo manualmente, no hay razón para que no pueda hacerlo. (PERO mantenga un registro de los datos que probó).

AJC

cada probador tiene su propio entorno de prueba y los probadores están abandonando completamente la base de datos varias veces al día, por lo que no es práctico agregar manualmente los datos de prueba, pero podemos pedirles cortésmente que agreguen algunos datos para las pruebas.

Christian P

Sí, tener pruebas unitarias y maquetas de datos es una buena práctica. El gerente del proyecto es correcto. Dado que realizar un cambio "simple" en los datos de la prueba a menudo produce errores, ese es el núcleo del problema.

El código necesita mejoras. No hacerlo (decir, oye, no necesitamos pruebas) no es una solución, es simplemente agregar deuda técnica . Divida el código en unidades más pequeñas y más probables porque ser incapaz de identificar unidades sin rotura es un problema.

Comienza a hacer un refactor. Mantenga las mejoras pequeñas para que sean manejables. Busque antipatrones como clases / métodos de Dios, que no sigan SECO, responsabilidad única, etc.

Finalmente, mire TDD para ver si funciona para el equipo. TDD funciona bien para garantizar que todo su código sea apto para pruebas (porque primero escribe las pruebas) y también para asegurarse de mantenerse delgado al escribir solo el código suficiente para pasar las pruebas (minimizar la ingeniería).

En general, si una serie de complejos procesos de lógica de negocios produce un conjunto de datos, entonces veo esto como un informe. Encapsular el informe. Ejecute el informe y use el objeto resultante como entrada para la próxima prueba.

P.Brian.Mackey
fuente

Necesito aclarar un poco las cosas: "El simple cambio en los datos de prueba produce errores" - el problema aquí no está en la aplicación - la aplicación funciona bien cuando los datos son válidos (y no puede agregar datos no válidos manualmente) . El problema aquí es que los datos de prueba no válidos pueden producir errores al intentar trabajar en esos datos. Entonces, ¿debemos probar los datos de prueba también?

Christian P

No te tropieces con una falacia de arenque rojo. El hecho de que los datos de prueba introduzcan un error es un problema completamente diferente. Eliminar las pruebas no es una solución, "gobernar el gobierno" es algo completamente distinto también. El problema es el código. No es comprobable porque nos está diciendo que no puede escribir pruebas que no rompan las cosas. Es por eso que necesitas mejorar el código.

P.Brian.Mackey

Quizás entendiste mal mi pregunta. Tenemos pruebas unitarias de trabajo y cada nueva funcionalidad que escribimos tiene pruebas unitarias. No estoy sugiriendo que eliminemos las pruebas que no pasan o que no escribamos pruebas en absoluto. Solo estoy sugiriendo que no usemos los scripts para crear datos simulados en la base de datos porque los probadores manuales están haciendo lo mismo.

Christian P

"Realmente no veo el punto de mantener los datos de prueba en las secuencias de comandos" <- Lo que estoy diciendo es abandonar el soporte de prueba. No eliminación de pruebas antiguas. Es una mala idea. Está disminuyendo la reproducibilidad y conectándose a una interfaz de usuario que es parte de lo que está intentando probar y puede adaptarse al cambio. Desacoplarse de la interfaz de usuario. Mantener la automatización de datos.

P.Brian.Mackey

Pero, ¿cómo abordamos el problema de los datos simulados no válidos? Si continuamos creando datos simulados para la base de datos, ¿cómo verificamos si los datos simulados están bien o no? Si la regla de negocio requiere ese valor X = 2 y la base de datos acepta X = 100, ¿cómo verificamos la integridad de los datos de prueba cuando la regla de negocio es compleja?

Christian P

Este es un problema muy común y muy difícil también. Las pruebas automatizadas que se ejecutan en una base de datos (incluso una base de datos en memoria, como HSQLDB ) suelen ser lentas, no deterministas y, dado que una falla en la prueba solo indica que hay un problema en algún lugar de su código o en sus datos, son No mucho informativo.

En mi experiencia, la mejor estrategia es centrarse en las pruebas unitarias para la lógica empresarial. Intente cubrir la mayor cantidad posible de su código de dominio principal. Si acierta esta parte, lo cual es un gran desafío, logrará la mejor relación costo-beneficio para las pruebas automatizadas. En cuanto a la capa de persistencia, normalmente invierto mucho menos esfuerzo en pruebas automatizadas y lo dejo a probadores manuales dedicados.

Pero si realmente desea (o necesita) automatizar las pruebas de persistencia, le recomendaría que lea Software creciente orientado a objetos, guiado por pruebas . Este libro tiene un capítulo entero dedicado a las pruebas de persistencia.

Otavio Macedo
fuente