¿Cómo hago para construir un plan de prueba para nuestro departamento de control de calidad?

Question

Actualmente estamos preparando nuestro departamento de pruebas para una nueva versión de nuestro último proyecto. Obviamente, nos gustaría que sigan un plan exhaustivo para probar nuestro software y asegurar que los errores nos sean transmitidos (el equipo de desarrollo) antes del lanzamiento.

¿Existen buenas herramientas o metodologías a seguir para crear este plan de prueba?

Answer 1

Probar: Artifact: Test Plan

Answer 2

El mejor libro que he encontrado sobre el tema es Managing the Testing Process. El autor analiza cómo crear un plan de prueba.

En mi experiencia, los conceptos básicos de un plan de pruebas son las siguientes:

• Función Descripción
• Supuestos
• Documentación relacionada
• matriz de prueba
• pruebas válidas
• no válida/Error Condición pruebas
• Pruebas de estado (comportamiento o se basa en varios estados del objeto/sistema)
• pruebas de estrés
• pruebas de rendimiento
• métricas de rendimiento
• Herramientas necesarias
• Las preocupaciones ambientales (hardware específico, navegador, sistema operativo, etc.)

Si puede completar eso, el equipo debería poder realizar las pruebas bastante bien.

Una decisión que debe tomar es ¿qué tan capaz es el equipo de prueba? Prefiero que un plan de prueba sea un algoritmo para derivar todos los casos de prueba. Describa los tipos de casos, pero no necesariamente cada caso en detalle. Si el equipo es menos competente, es posible que deba deletrear cada caso específicamente.

Una última precaución. Evite el llamado de la sirena de ser demasiado detallado. No es probable que se siga un plan que no se puede mantener en la cabeza de alguien. Si su plan de prueba tiene 25 páginas, probablemente haya escrito demasiado.

Answer 3

Y no lo olvidemos, nunca habrá tiempo suficiente para hacer todas las pruebas que desea hacer. Entonces las pruebas en su plan necesitarán ser priorizadas. A menudo encuentro que priorizar por riesgo es la mejor manera de hacerlo.

Sin embargo, normalmente un plan de prueba sería desarrollado por el grupo QA, en coordinación con dev y PM. Si QA no está creando el plan por su cuenta, parece que su equipo de control de calidad podría usar una actualización. Por lo menos, incluso si dev está armando el plan inicial, el QA debería proporcionar algún aporte, ya que tendrán un punto de vista diferente. Cuantos más ojos tenga el plan de prueba, más completo será.

Answer 4

Las pruebas de unidad y de integración deben detectar muchos de los problemas en el nivel del código, pero no son excelentes para probar cómo se comporta el sistema desde el punto de vista del usuario.

Una vez que sepa qué se supone que debe hacer una función y cómo saber si funciona o no, automatice esa prueba (donde tenga sentido, obviamente) usando algo como TestComplete, SmarteScript. Estas pruebas son fáciles de ejecutar y automatizadas, por lo que siempre se ejecutarán de manera consistente sin preocuparse de que algo se escape entre las grietas.

Answer 5

QA debe estar escribiendo el plan de prueba, como señala Tom E. Deben comprometerse con el cliente para comprender los requisitos y con el equipo de desarrollo para comprender la implementación, pero al final del día, el equipo con la mentalidad de prueba debe ser el propietario del plan de prueba.

La única situación en la que se me ocurre dónde escribir un plan de prueba para un equipo de control de calidad es cuando tiene un equipo subcontratado haciendo control de calidad que todavía no está familiarizado con su producto. En ese caso, recomendaría tener uno o dos miembros senior del equipo colocados con usted durante el diseño y desarrollo; les ayuda a acelerar mucho más rápido y pueden transmitir ese conocimiento al resto del equipo.

Answer 6

hey Pavliks, I no sabe básico que desea, pero si quieres algo simplista y fácil de recoger y correr, echar un vistazo a este artículo: Writing a System Test Plans

si sabe bien su software , tiene MS Word instalado, y tiene buenas habilidades de documentación, es bueno ir

en términos de un protocolo de registro de fallas muy básico y genérico para ir con él, puede echar un vistazo a: Logging Bugs Like a Pro < - esto es todo sobre el registro de errores con el mínimo esfuerzo y capturando la información desnuda necesaria para investigar un error

- LM