Participar en pruebas
Probar es algo más que el proceso de asignar requisitos a la funcionalidad. Si bien es importante crear y ejecutar estos tipos de pruebas, deben probarse muchos más aspectos de la solución. Independientemente de la métrica específica que se esté probando, el proceso es bastante similar.
Un proceso de prueba suele seguir el siguiente flujo:
- Planificar. Revise la estrategia general para las pruebas. Desarrolle el plan de prueba. Realice el análisis necesario para las métricas de referencia. Identifique los escenarios empresariales clave que están dentro y fuera del alcance. Documente los requisitos, si aún no los ha completado.
- Preparar. Configure los entornos necesarios, las pruebas de rendimiento, las pruebas de adopción del usuario, etc. Revise los datos recibidos para la migración, tanto antes como después de las pruebas de migración. Valide los requisitos del sistema de alto nivel. Desarrolle los scripts necesarios.
- Ejecutar. Ejecute los scripts de prueba. Analice los resultados e identifique los posibles cuellos de botella. Revise los fallos y comportamientos.
- Informar. Prepare una evaluación detallada del plan de presentación de informes, los resultados y el plan de acción.
Tipos de pruebas
Es probable que el consultor funcional participe de alguna manera en cada uno de estos tipos de pruebas. Cada uno tiene posibles resultados decisivos y, con la profundidad de las habilidades del consultor funcional, son un gran recurso para ayudar al equipo de calidad a tener éxito.
Tipo de prueba
Descripción
Pruebas unitarias
Estas pruebas las realiza el creador de la aplicación o el desarrollador del código, ya que se crea un activo a lo largo del proceso de implementación. Estas pruebas unitarias deben realizarlas las personas que estén creando de forma activa la funcionalidad, es decir, un desarrollador, un consultor funcional, un analista de negocios, etc.
Pruebas funcionales/pruebas de sistema
Estas pruebas comprueban que la implementación cumpla con los requisitos y no tenga defectos. Las pruebas funcionales pueden realizarlas manualmente los recursos de los equipos del cliente o del partner, o pueden automatizarse.
Pruebas de aceptación
Estas pruebas las realizan los usuarios finales para dar una aprobación formal, y prueban la facilidad de uso del sistema. Las pruebas de aceptación suelen realizarse como una comprobación final antes de implementar la funcionalidad. En una implementación inicial, esta prueba se realiza al final del proyecto, pero en una implementación iterativa y ágil, la funcionalidad puede lanzarse en cada sprint, por lo que tendrá que realizar pruebas de aceptación durante todo el proyecto. Esta prueba suele denominarse UAT, prueba de aceptación del usuario.
Pruebas de regresión
Estas pruebas evalúan funciones no cambiadas para la regresión y suelen realizarse cada vez que hay una actualización del sistema. Los clientes deben tener un plan de prueba de regresión antes de cada actualización importante de la plataforma (dos veces al año) para comprobar que la configuración actual funcione de manera óptima después de la actualización. Las pruebas de regresión se pueden automatizar.
Pruebas de integración
El objetivo es que todos los sistemas integrados funcionen en armonía. Las pruebas de integración comprueban que todo funcione de forma conjunta, incluidos los servicios y datos integrados de terceros. Esta prueba se lleva a cabo después del desarrollo inicial de las integraciones.
Pruebas de rendimiento
Estas pruebas comprueban el rendimiento del sistema con la carga máxima prevista y el volumen máximo de transacciones, y suelen automatizarse y ejecutarse antes de la puesta en marcha o antes de incorporar un grupo grande de usuarios adicionales del sistema.
Pruebas de validación de datos
Estas pruebas comprueban la migración de datos para garantizar la calidad de los datos y suelen llevarlas a cabo la persona que escribió la integración o los recursos del cliente en estrecha colaboración con expertos en la materia que conocen los datos del cliente. Estos expertos deben comprender la transición y transformación de los datos y pueden confirmar que los datos migrados son válidos con el contexto adecuado. Este proceso puede implicar comprobaciones estándar, como recuentos de filas o la comprobación puntual de un subconjunto de datos migrados para comprobar que las columnas se han asignado correctamente. Este proceso también se denomina a veces prueba de migración de datos.
Pruebas de recuperación ante desastres
Estas pruebas implican probar lo que sucede si un desastre colapsa su sistema. Aunque Microsoft se encarga de la recuperación ante desastres importantes, debe asegurarse de contar con un plan para reanudar las operaciones después de que se produzca un desastre. Por ejemplo, comprobar que su código de origen esté actualizado para que pueda volver a crear sus entornos de desarrollo correctamente en caso de que se produzca un desastre.
Pruebas de puesta en marcha
Entre estas pruebas se incluyen simulacros del proceso completo de puesta en marcha que suelen realizarse antes de la puesta en marcha.
El papel del consultor funcional en las pruebas
Además de participar en el proceso de prueba real, debe estar preparado para ayudar a crear planes de prueba, o al menos revisarlos. Este proceso le ayudará a hacer mejor su trabajo al asegurarse de que las expectativas estén alineadas desde el principio hasta el final del ciclo de vida del proyecto. También ayuda al equipo de calidad al validar sus planes de prueba con sus acciones creando y configurando el sistema.
Aunque puede participar en cualquiera de las pruebas indicadas, es probable que el consultor funcional esté más involucrado en lo siguiente:
Pruebas funcionales
El objetivo de las pruebas funcionales es garantizar que el cliente haya identificado una estrategia en función de un conjunto de usuarios expertos y escenarios de casos de prueba que el equipo de pruebas utilizará para obtener una evaluación de la calidad de su solución.
Un aspecto importante de las pruebas funcionales es garantizar que no se introduzca una regresión a partir de los cambios que se sigan introduciendo, tanto antes como después de la puesta en marcha. A partir del conjunto completo de pruebas funcionales, se debe identificar un subconjunto como pruebas de regresión que se ejecutan de forma periódica para cada versión o actualización.
Pruebas de integración
Los aspectos más importantes de la implementación del proceso de negocio para que funcione correctamente, además de tener un gran impacto en la adopción general. El cliente debe garantizar que tenga previsto involucrar a los propietarios de otras aplicaciones que estén integradas con el sistema. Esta prueba también requerirá la definición de roles y responsabilidades claros para solucionar cualquier problema o realizar cambios según sea necesario.
Es posible que cada integración tenga su propio enfoque de prueba, que debe definirse. El equipo de pruebas debe participar desde el principio para ver cómo se probará cada escenario de integración. Los equipos deben garantizar que las integraciones necesarias tengan la capacidad de configurarse para admitir las pruebas.
Un aspecto clave de las pruebas de integración debe centrarse en los datos que entran y salen de la integración. Gran parte del debate de la sección de pruebas de validación de datos también puede aplicarse a los datos involucrados en las integraciones.
Pruebas de aceptación del usuario
Las pruebas de aceptación de usuario son fundamentales para garantizar la aprobación y la aceptación de la puesta en marcha del nuevo sistema. También podrían proporcionar un trabajo pendiente de solicitudes de características que se puede planificar como parte de las mejoras posteriores a la puesta en marcha.
Los clientes deben asegurarse de que los usuarios expertos o los usuarios clave se hayan identificado desde el principio, y deben mantenerse comprometidos durante todo el ciclo de vida del proyecto. Deben involucrar a este grupo, junto con una comunidad de usuarios adicionales, para probar la aplicación. Debe haber una definición clara de la estrategia correcta de prueba de los criterios de aceptación del usuario, ya que esta definición también se consolidará durante la decisión de seguir o no seguir con la puesta en marcha.