¿Cómo organizas/diseñas tus scripts de prueba?

Question

Me interesa cómo otros organizan sus scripts de prueba o han visto buenos scripts de prueba organizados dondequiera que hayan trabajado. Además, qué nivel de detalle se encuentra en esos scripts de prueba. Esto se relaciona específicamente con los scripts de prueba creados para las pruebas manuales en lugar de los creados para cualquier prueba automatizada.

El problema es que existe una gran complejidad en los scripts de prueba, pero sin el beneficio de los principios utilizados en la organización de una base de código compleja o grande. Debe poder especificar qué debe hacer un fragmento de código, pero sin aburrir a alguien mientras lo leen.

Además, ¿cómo se diseñan los scripts de prueba, no estoy dispuesto a crear scripts completamente especificados adecuados para ser ejecutados por tipos de entrada de datos ya que ese no es el equipo que tenemos y la sobrecarga de mantenerlos parece demasiado alta. Además, me parece que especificar el proceso con tanto detalle elimina la responsabilidad de la persona que realmente hace la prueba de la calidad del producto. ¿Las personas especifican cada clic del botón y el valor que se ingresará? Si no, ¿qué nivel de detalle se especifica?

Answer 1

Las pruebas ejecutadas por humanos deben tener un nivel muy alto de abstracción.

E.g. un caso de prueba para el registro stackoverflow:

bueno:

Un visitante del sitio con una cuenta OpenID registros existentes como un usuario stackoverflow y mensajes una respuesta.

malo:

1) Vaya a http://stackoverflow.com 2) Haga clic en el enlace de conexión 3) Etc ...

Esto es importante por varias razones:

a) mantiene las pruebas mantenibles. Por lo tanto, no es necesario que actualice su script de prueba cada vez que los elementos de navegación se vuelvan a etiquetar (por ejemplo, "inicio de sesión" cambia a "iniciar sesión").

b) ahorra a sus probadores de enloquecer del tedio de los detalles de los minutos.

c) escribir guiones de prueba manuales detallados es un uso deficiente de los recursos de prueba finitos.
Los scripts de prueba manuales detallados desviarán a los verificadores para que escriban errores por problemas menores de documentación. Desea utilizar su tiempo para encontrar los errores reales que afectarán a los clientes.

Answer 2

Intento hacer que las pruebas manuales quepan en una estructura automatizada --- puede tener ambas.

Los esquemas de organización utilizados por las pruebas automatizadas (por ejemplo, los marcos xUnit) funcionan para . De hecho, se pueden usar para semiautomatizar las pruebas, al detener y solicitar que se ejecute una prueba manual, o que se ingrese una entrada, o que se inspeccione una GUI. El esquema generalmente es para reflejar la estructura de directorios del código de producción, o para incluir las pruebas dentro del código de producción, a veces como clases internas. Las pruebas por encima del nivel de la unidad a menudo pueden encajar en los directorios de nivel superior (suponiendo que tenga un árbol de directorios lo suficientemente profundo). Estas pruebas de nivel superior pueden ir en directorios (duplicados) que no tienen código de producción, pero están ahí para propósitos de organización.

El nivel de detalle --- bueno, eso depende, ¿verdad?

Answer 3

Las pruebas se pueden agrupar por prioridad. Las pruebas de BVT/humo podrían tener la prioridad más alta con funcionalidades, integración, regresión, localización, estrés y rendimiento con prioridades más bajas. Dependiendo de su pase de prueba, seleccionaría una prioridad y ejecutaría todas las pruebas con esa o más prioridades. Todo lo que necesita hacer es determinar qué prioridad es una prueba en particular.

Answer 4

Matt Andresen ha proporcionado una buena respuesta, en general, pero hay situaciones en las que no puede hacerlo de esa manera. Por ejemplo, cuando trabaja en aplicaciones validadas, debe cumplir con las reglamentaciones de otras partes como la FDA, y se somete a una auditoría, revisión, cierre de sesión muy intenso, que el formulario de 2 respuestas es necesario. Aunque optaría por pasar a la automatización con HP QuickTestPro o IBM RationaRobot en este caso.

Tal vez deberías probar con algunos repositorios de pruebas? Hay herramientas de HP QualityCenter y productos de IBM, pero esto puede ser costoso. Puede encontrar algunos más baratos, que le permitirán organizarlos en estructuras de árbol, por requerimiento/función, asignarles prioridades, agruparlos en trajes de prueba para lanzamientos, agruparlos en trajes de prueba de regresión, etc ...