7 Consejos de Escritura de Casos de prueba para Mejorar Su Proceso de Prueba de Software ERP

Los casos de prueba son muy importantes para garantizar la calidad en su proceso de prueba de software ERP. Son los primeros pasos de un ciclo de pruebas y, si los casos de prueba no son de calidad suficiente, todo el proyecto se verá “sobrecargado”. Escribir casos de prueba “geniales” es una habilidad que se forma simplemente haciéndolo. Pero es muy útil tener algunas ideas que podrían ayudarte. Con este artículo quiero llegar a ti y darte sugerencias para que sea más fácil, más divertido y mejor. Los consejos que se dará en particular se relacionan con casos de prueba en las pruebas de aceptación de los sistemas ERP.

¿Qué son los casos de prueba?

Dentro del mundo de las pruebas de software, hay muchas definiciones de casos de prueba. Debido a esto, es importante nombrar nuestra definición. En nuestra filosofía, los casos de prueba (basados en IEEE610) son: “Un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.”Saber escribir buenos casos de prueba es extremadamente útil para cualquier persona que quiera hacer pruebas. Ya sea una prueba funcional, una prueba de aceptación del usuario, una prueba de una aplicación web o un módulo de un sistema ERP. En todas las situaciones descritas anteriormente, los casos de prueba determinan hasta qué punto los resultados dan un veredicto sobre los objetivos preestablecidos.

¿Por qué es tan difícil escribir casos de prueba?

Como se describe en la definición, los casos de prueba ayudan a guiar a los probadores a través de una secuencia de instrucciones de prueba para determinar si el software cumple o no los requisitos predefinidos. La ejecución de casos de prueba nos ayuda a recopilar y descubrir información para lograr ese objetivo u objetivo específico. El primer problema que encontramos directamente es la diversidad de posibles objetivos. Y debido a que hay diferentes tipos de pruebas y objetivos, hay diferentes tipos de casos de prueba correspondientes.

Un segundo problema está relacionado con el contenido de las instrucciones o pasos reales de la prueba. El nivel de estas instrucciones depende del tipo de probador que tiene que interpretar esta información y dar una opinión. Un probador profesional necesitará instrucciones diferentes en lugar de un usuario final que esté involucrado en las pruebas de aceptación de un sistema ERP

Consejo 1: Determine su objetivo y lo que desea reportar

Piense en lo que desea reportar, para que pueda determinar su objetivo derivado. Usando eso como base, tienes el esquema del caso de prueba a la vista. Hay muchos objetivos diferentes, donde siempre tenemos que preguntarnos qué estamos tratando de aprender o lograr cuando vamos a realizar la prueba. Estos son algunos ejemplos:

• Encontrar defectos: Este es el propósito clásico de las pruebas. Se realiza una prueba para exponer defectos.
• Maximizar el número de errores: La distinción entre” maximizar el número de errores “y” encontrar defectos ” es que el número total de errores es más importante que la cobertura.
• Bloquear lanzamientos prematuros de productos: El objetivo de esta prueba es encontrar prematuramente tantos defectos graves (obstáculos) para que nadie lleve el producto a la producción.
• Apoye a los gerentes con sus decisiones de ir/no ir: Los gerentes toman decisiones basadas en los riesgos. Indicaciones de riesgo como cobertura de pruebas, impacto de los problemas encontrados, etc. Dales un mejor contexto en el que basar sus decisiones.
• Evaluar la conformidad de acuerdo con la especificación: se verifican las supuestas especificaciones para su funcionamiento. No se tienen en cuenta todos los asuntos que no están asociados con las especificaciones.
• Evaluar la calidad: este es un objetivo difícil, porque la calidad es multidimensional. La naturaleza de la calidad depende de la naturaleza del producto. Para evaluar la calidad, deben elaborarse criterios claros, definidos de manera que puedan ser realmente mensurables.

Los resultados de la prueba obtenidos de los casos de prueba proporcionan información relevante directa sobre el objetivo.

Consejo 2: reserve suficiente tiempo de diseño

Reserve suficiente tiempo para diseñar sus casos de prueba, de modo que coincidan con sus objetivos. Los casos de prueba deficientes lo perseguirán durante todo el proceso de prueba. Comparación de los resultados de las pruebas, presentación de informes sobre varias rondas de pruebas, etc. Están determinados esencialmente por la calidad de sus casos de prueba.

Si ya se está quedando sin tiempo para diseñar, pero aún desea comenzar a probar, asegúrese de haber definido al menos los principales riesgos. Si 10 evaluadores deben revisar 5 casos de prueba con 1 paso de prueba, esto dará como resultado 50 resultados de prueba. No importa lo que estos 50 resultados den más información sobre la calidad que no hacer nada. Esto probablemente no sea exhaustivo, pero es un primer paso. A partir de ahí, se puede determinar el nivel de detalle de ciertas partes.

Preferimos que piense con mucha antelación sobre cómo debe diseñarse la prueba, y que los resultados de la prueba den una respuesta real al objetivo. Pero en realidad esto a veces es rebelde.

Consejo 3: Caso de prueba de nombre

Es importante nombrar los casos de prueba. En una prueba de ERP promedio, tiene fácilmente más de 500 casos de prueba. Comprenderá que una estructura de nombre lógico mejora la capacidad de búsqueda. En la literatura se refiere a menudo como un posible nombre, en la que el ser probados proceso, módulo, objeto, etc. Están todos incluidos en el nombre. Puede imaginar que proporcionar 500 casos de prueba con un título tan completo da una administración caótica. Con una simple hoja de Excel, puede perder fácilmente la visión general. Las herramientas de gestión de pruebas proporcionan una estructura con la que puede relacionar los casos de prueba con objetos reutilizables, sin que “contaminen” el nombre. También tiene herramientas de registro de pruebas que organizan estas relaciones de una manera diferente.

Dentro de TestMonitor, por ejemplo, inventamos una solución diferente. En la herramienta puede definir etiquetas o etiquetas que luego puede vincular a casos de prueba. Dentro de TestMonitor, los casos de prueba están vinculados a una o varias etiquetas de proceso de negocio, riesgo, requisito o aplicación. Esto permite agrupar los casos de prueba y recuperarlos desde diferentes perspectivas.

Para el nombre de un caso de prueba dentro de TestMonitor basta con una descripción clara del propósito del caso de prueba. Para hacerlo simple, describe una actividad con una expectativa implícita.

Nombre de caso de prueba de ejemplo:
“Terminación de la vivienda independiente de arrendamiento”
“Crear cliente” “Recibo de reserva provisional”
etc.

Ejemplo de caso de prueba “Recibo de reserva provisional” que está vinculado a varias etiquetas:

• proceso de negocio “Recepción de bienes”
• requisito “Requisito contractual”
• riesgo “Riesgo operativo”
• aplicación “ERP’

Es importante describir el resultado esperado por caso de prueba. El probador entonces sabe en qué dirección debe estar la “respuesta” y obtiene directamente un marco de prueba explícito.

Consejo 4: Descripción del paso de prueba

Como se describe en la definición, los casos de prueba son una colección de instrucciones de prueba que nos ayudan a descubrir información para lograr un objetivo en particular.

Un caso de prueba debe tener un principio y un final claros para determinar si el caso de prueba pasó o falló. Además, un caso de prueba se compone de una o más instrucciones o pasos de prueba, en los que hay múltiples caminos posibles para lograr el resultado deseado. A menudo, solo probar el camino del éxito es insuficiente. En ciertas situaciones, seguir caminos de no éxito solo puede marcar la diferencia.

Es importante definir los pasos de prueba con la mayor claridad posible para que el usuario final de una prueba de aceptación de usuario sepa exactamente lo que tiene que hacer. Por supuesto, hay condiciones previas para llegar a, como probador de nivel funcional, conocimiento del nuevo sistema,conocimiento de los posibles procesos de negocio ajustados, etc. Pero, en esencia, todos deben entender todos los pasos de la prueba.

Supongamos que describimos con más detalle el caso de prueba “Terminación de arrendamiento – casa independiente” para una ruta de éxito simple:

1. Seleccione una unidad y comience a rescindir el contrato de arrendamiento. Controlar si hay prerrequisitos entre los que la terminación del arrendamiento puede/no ser aceptada y crear un registro de esto.
2. Programe una cita para la inspección final.
3. Rellene los datos en la pantalla Terminación del contrato de arrendamiento. Verifique dos veces los datos del inquilino en la tarjeta de terminación del contrato de arrendamiento.
4. Registre la terminación del contrato de arrendamiento y envíe una carta de conformidad. Compruebe si la carta de confirmación ha llegado al archivo digital.
5. Compruebe en el registro de contratos de la unidad que el contrato actual se ha rescindido, que el contrato rescindido está vinculado a la rescisión del contrato de arrendamiento y que existe un contrato vacante de nueva creación.
6. Compruebe el nuevo contrato (vacante) según la política de alquiler y las plantillas de elementos.

¿Qué nota?

• Cada paso de la prueba comienza con un verbo
• Seguido de un tema
• Que concluye con detalles y posiblemente preguntas de control. Puede elegir poner las preguntas de control en pasos de prueba separados, pero la práctica muestra que la pregunta de control es un refinamiento de la acción y luego, lógicamente, se anotará como un paso de prueba.

En el ejemplo mencionado anteriormente, se asume que un especialista de un campo en particular evaluará el paso de la prueba. Y debido a que es un especialista, no se dan condiciones de entrada ni se esbozan expectativas explícitas, porque el especialista todavía tiene sus propios estudios de caso bajo la manga y sus expectativas son claras como el cristal.

Si actualmente no tiene un especialista, puede ampliar los pasos de prueba con condiciones de entrada y expectativas explícitas.

Por ejemplo, pruebe el paso 1 en el caso de prueba “Terminación de vivienda independiente de arrendamiento” con más detalles.

1. Seleccione la unidad “Fleet street 677” e inicie la terminación del contrato de arrendamiento. Las condiciones garantizan que no se pueda poner fin a esta dependencia antes de que se hayan pagado las cuotas atrasadas.
2. Etc.

Consejo 5: No más de 10 instrucciones de prueba en 1 caso de prueba

Regularmente nos encontramos con proyectos de prueba donde > 50 pasos de prueba se asignan a un caso de prueba. Esto es demasiado por algunas razones:

• Todos los pasos de la prueba deben tomarse por separado (o aprobarse explícitamente) antes de que un caso de prueba obtenga un veredicto.
• La evaluación final de un caso de prueba está determinada por la puntuación” peor”. Por lo tanto, es muy posible que 49 pasos de prueba se evalúen como “buenos” y uno como “incorrecto”, lo que resulta en un caso de prueba “incorrecto”. La medición de los pasos de ensayo será similar. Con esto quiero decir que prácticamente cada paso de la prueba debe ser igual al efecto de la evaluación. Si tiene 10 pasos de prueba que debe seguir, incluidos 2 pasos pequeños de prueba que son desproporcionados con los otros 8 pasos de prueba, debe reformularlos. Lo mismo se aplica al revés con un paso de prueba difícil.
• El probador se pierde rápidamente con demasiados pasos de prueba dentro de un caso de prueba. No hemos hecho un estudio científico al respecto, pero la práctica muestra que un caso de prueba no debe incluir más de 10 pasos de prueba. Se pueden pensar en muchas excepciones (controles de conversión, etc.), pero en la práctica, para una prueba de aceptación de usuario de un sistema ERP, esto funciona mejor.
• Es difícil para los desarrolladores reproducir el error encontrado. Con muchos pasos de prueba, el desarrollador perderá mucho tiempo tratando de recrear la situación.
• Las repeticiones o pruebas de casos de prueba grandes llevan demasiado tiempo. Cuando un probador detecta un fallo, el caso de prueba correspondiente tendrá que volver a probarse. Una nueva prueba requiere que se vuelva a evaluar ese mismo paso, obviamente desea evitar errores de regresión. Al tomar demasiados pasos de prueba, lo más probable es que esté haciendo demasiadas pruebas. De esta manera, el proceso de prueba lleva más tiempo y, eventualmente, puede sobrecargar sus probadores.

Además de eso, también tiene herramientas de registro de pruebas que pueden presentar los casos de prueba en varias formas al probador. TestMonitor, por ejemplo, tiene dos vistas diferentes. TestMonitor tiene una pantalla que muestra todos los pasos de prueba por separado por página y una pantalla en la que se presentan los casos de prueba por página, incluidos todos los pasos de prueba.La ventaja de la primera pantalla es que cada probador puede obtener más información para cada paso de prueba. La desventaja en caso de que el probador tenga más experiencia, tiene que hacer clic en “siguiente” cada vez que quiera proceder al siguiente paso de prueba. En la otra vista para cada caso de prueba, las ventajas y desventajas son viceversa.

Consejo 6: Revisión por un no diseñador / proveedor

En la práctica, vemos regularmente scripts de prueba preparados por los programadores del proveedor de software. Al revisar estos scripts de prueba por los probadores eventuales, generalmente hay más preguntas que respuestas. Por el contrario, esto funciona de la misma manera para los scripts de prueba preparados por sus propios empleados. Aporta un valor añadido real al revisarlas por parte del proveedor de software. Miran los scripts de prueba completados con ojos diferentes y siempre presentan adiciones o modificaciones significativas.

Con un poco de lluvia de ideas con los especialistas de los proveedores de software y la organización del cliente, rápidamente se enfoca en la esencia de lo que necesita ser probado. Luego tómese el tiempo para considerar los casos de prueba, los escenarios de no éxito y verá que su modelo de prueba se vuelve rápidamente más extenso y detallado. Además de eso, obtienes más información sobre la calidad que consideraste posible.

Consejo 7: Monitor de prueba

Además de eso, haga uso de una plataforma de prueba profesional y haga que la calidad sea realmente reveladora. Solicite una prueba gratuita de TestMonitor hoy mismo y vea y experimente la diferencia por sí mismo.

Si es un recién llegado al mundo de las pruebas, fácilmente se sentirá abrumado por toda la terminología de las pruebas que se lanza. En este artículo, trataremos de explicar parte de la jerga que puede encontrar en su vida diaria de pruebas, solo para que todo sea un poco más comprensible.

Comience a probar con TestMonitor

¿Todavía no es un usuario de TestMonitor? Las pruebas buenas y fáciles son una prioridad clave para los gerentes de control de calidad, los gerentes de pruebas, los gerentes de TI, los gerentes de pruebas y el administrador de versiones. TestMonitor también hace que las pruebas sean fáciles y divertidas para los usuarios de prueba.

Así que vamos a empezar. Es posible que desee ver nuestro video o descargar el folleto del producto. Pero, por supuesto, con una prueba gratuita, realmente puede experimentar la facilidad de uso de TestMonitor usted mismo.

Permanecer en contacto? Sigue TestMonitor en Twitter y LinkedIn.