Pruebas de software: revisión de casos de prueba

Cuando un ingeniero de pruebas prepara un caso de prueba, puede omitir algunos escenarios, como ingresar datos incorrectos y escribir pasos de navegación incorrectos, todo lo cual puede tener un impacto en el proceso general de ejecución de la prueba. Para evitar esto, se realizará una ronda de evaluación y aprobación antes de comenzar la prueba. Si se pierden algunos casos de prueba y no se realiza el procedimiento de revisión, la precisión del documento del caso de prueba será menor. Solo después de que se haya escrito el caso de prueba, todos los casos deben enviarse para su revisión a otro ingeniero de pruebas, conocido como revisor, para su revisión. En las pruebas de software , el examen de los casos de prueba es un paso crítico. Todas las funciones enumeradas en la Especificación de requisitos de softwarees abordado por el caso de prueba. El caso de prueba debe ser efectivo y cumplir con las pautas de redacción del caso de prueba. Cada caso de prueba debe verificarse para garantizar el éxito y la exhaustividad de la prueba. Aquí, discutiremos los siguientes puntos:

1. ¿Por qué revisar casos de prueba?
2. ¿Qué es el repositorio de casos de prueba?
3. Beneficios del repositorio de casos de prueba.
4. Proceso de revisión de casos de prueba.
5. Técnicas de Revisión de Casos de Prueba.
6. Sugerencias durante la revisión de casos de prueba.
7. Factores a considerar durante la revisión de casos de prueba.
8. Errores comunes durante la revisión de casos de prueba.
9. Clasificación de defectos en la revisión de los casos de prueba.

¿Por qué revisar casos de prueba?

Se debe realizar una revisión por pares en cualquier producto de trabajo que se considere entregable. Los casos de prueba, que son entregables importantes para el equipo de pruebas, se incluyen en esta categoría. Es fundamental escribir casos de prueba efectivos que descubran con éxito tantas fallas como sea posible durante el proceso de prueba. Como resultado, se requiere una verificación para determinar si:

• Los casos de prueba se desarrollan con la intención de detectar fallas y el requisito se entiende correctamente.
• Las áreas de impacto potencial se identifican y se ponen a prueba.
• Los datos de prueba son precisos y cubren todas las clases de dominio posibles. Hay escenarios que son tanto favorables como negativos.
• El comportamiento esperado se documenta con precisión.
• La cobertura de la prueba es suficiente.

¿Qué es el repositorio de casos de prueba?

Mantener los casos de prueba organizados vale la pena, particularmente en proyectos medianos a grandes. Además, la prueba es un procedimiento que se puede repetir. Todos se benefician de la reutilización de casos de prueba, ya que ahorra tiempo. Los elementos grandes de los proyectos se pueden repetir para la prueba. Mantener un repositorio de casos de prueba permite reutilizar los recursos de prueba anteriores según sea necesario, lo que ayuda a ahorrar tiempo. La buena noticia es que mantener un repositorio de casos de prueba bien organizado no es nada difícil. La cantidad y variedad de casos de prueba que constituyen la base de los ciclos de prueba a menudo están vinculadas al éxito de un equipo de prueba de software. La asimilación de casos de prueba puede requerir una cantidad significativa de tiempo y esfuerzo, y el objetivo principal es crear un repositorio de casos de prueba completo para cada aplicación.

• Un repositorio de casos de prueba es un área de almacenamiento centralizada para todos los casos de prueba de referencia (creados, revisados ​​y autorizados).
• Cuando el cliente proporciona los requisitos, el desarrollador comienza a construir los módulos y el ingeniero de pruebas comienza a escribir los casos de prueba.
• Los casos de prueba autorizados se almacenan en un repositorio de casos de prueba.
• Si un ingeniero de pruebas desea probar la aplicación, debe usar el repositorio de casos de prueba para obtener el caso de prueba.
• Podemos eliminar casos de prueba del repositorio de casos de prueba si no los necesitamos.
• Tenemos un repositorio de casos de prueba separado para cada versión.
• Sin la autorización del líder de prueba, los casos de prueba no pueden modificarse ni cambiarse una vez que se hayan establecido como referencia o guardados en el repositorio de casos de prueba.
• Si hay un bloqueo que afecta el software, el equipo de pruebas siempre tiene una copia de seguridad completa del repositorio de casos de prueba.

Además, debido a que un repositorio de casos de prueba aumenta con el tiempo, los evaluadores deben mantenerlo actualizado con cada nueva versión de la aplicación comercial o producto de software. Si esto no se hace, perderá la sincronización con la función y el comportamiento reales del software con el tiempo. Como resultado, los hallazgos de los ciclos de control de calidad posteriores se verán afectados.

Beneficios del repositorio de casos de prueba

Los siguientes son algunos de los beneficios de un repositorio de casos de prueba:

1. El repositorio se puede actualizar si surge algo nuevo.
2. Ahorra tiempo.
3. Las habilidades de escritura de casos de prueba de los probadores se evalúan en función del rendimiento.
4. Cobertura.
5. Ayuda con la presentación de informes.
6. Trazabilidad.
7. Se pueden crear gráficos para mostrar el estado de los casos de prueba (aprobado, reprobado, no probado).
8. Puede ayudar en el desarrollo de nuevos artículos similares.
9. Se pasan menos datos de un probador al siguiente.

Proceso de revisión de casos de prueba

La siguiente es la lista de actividades involucradas en el proceso de revisión:

1. Planificación: esta es la primera fase y comienza cuando el autor solicita un moderador para el proceso de revisión. El moderador es responsable de programar la fecha, hora, lugar e invitación de la revisión. La verificación de entrada se realiza para asegurarse de que el documento esté listo para su revisión y no tenga una gran cantidad de defectos. Una vez que el documento borra la verificación de entrada, el autor y el moderador deciden qué parte del documento se revisará.

2. Inicio: Este es un paso opcional en el proceso de revisión. El objetivo es dar una breve introducción sobre los objetivos de la revisión y los documentos para todos en la reunión. 

3. Preparación: Los revisores revisan el documento utilizando los documentos, procedimientos, reglas y listas de verificación relacionados proporcionados. Cada participante durante la revisión identifica los defectos, dudas y comentarios de acuerdo a su comprensión del documento.

4. Reunión de revisión: La reunión de revisión consta de tres fases:

• Fase de registro: Los problemas y defectos identificados durante la fase de preparación se registran página por página. El registro lo realiza un autor o escriba, donde un escriba es una persona que realiza el registro. Cada defecto y su gravedad deben registrarse.
• Fase de discusión: si algún defecto necesita discusión, se registrará y manejará en esta fase. El resultado de la discusión se documenta para propósitos futuros.
• Fase de decisión: los participantes deben tomar una decisión sobre el documento que se está revisando.

5. Reelaboración: si el número de defectos encontrados por página excede un cierto nivel, entonces el documento debe ser reelaborado. 

6. Seguimiento: El moderador verifica para asegurarse de que el autor haya tomado medidas en todos los defectos conocidos. 

Técnicas para la revisión de casos de prueba

Hay tres técnicas para llevar a cabo una revisión de caso de prueba:

1. Auto-revisión: Esto lo lleva a cabo el probador que escribió los casos de prueba. Al mirar SRS/FRD, puede ver si todos los requisitos se cumplen o no.
2. Revisión por pares: esto lo realiza otro evaluador que no está familiarizado con el sistema bajo prueba pero que no ha desarrollado los casos de prueba. Maker y Checker son otros dos nombres para lo mismo.
3. Revisión de supervisión: esto lo realiza un líder de equipo o un gerente que tiene un rango más alto que el probador que escribió los casos de prueba y tiene un amplio conocimiento de los requisitos y el sistema bajo prueba.

Sugerencias al revisar casos de prueba

A continuación se presentan algunos de los consejos que se deben tener en cuenta al revisar los casos de prueba:

• En el proceso de revisión, es mejor ceñirse a los números de versión. Por ejemplo, si revisa un plan de caso de prueba por primera vez, hágalo v.1. Una vez que el probador haya completado todos los cambios, vuelva a revisarlo y conviértalo en v.1.1. Así se podrá saber cuál es el más reciente y se tendrá un registro completo de los cambios del plan.
• Siempre es preferible reunirse con el probador cara a cara para asegurarse de que comprenda completamente todos los comentarios de la revisión.
• Si es posible, ejecute casos de prueba en el SUT (Sistema bajo prueba) para obtener una mejor comprensión de los resultados y las acciones involucradas en su ejecución.
• Es preferible tener una copia de SRS/FRD con usted mientras lee el caso de prueba como referencia.
• Si no está seguro acerca de un caso de prueba o el resultado esperado, consulte con el cliente o su supervisor antes de tomar una decisión.

Factores a considerar durante la revisión de casos de prueba

Durante la revisión, el revisor busca lo siguiente en los casos de prueba:

1. Plantilla: el revisor determina si la plantilla cumple con los requisitos del producto.

2. Cabecera: En la cabecera se comprobarán los siguientes aspectos:

• Es discutible si se capturan o no todas las cualidades.
• Es discutible si todos los rasgos son relevantes o no.
• Si todos los rasgos están llenos o no, depende de usted.

3. Cuerpo: mire los siguientes componentes en el cuerpo del caso de prueba:

• El caso de prueba debe escribirse de tal manera que el procedimiento de ejecución tome el menor tiempo posible.
• Es discutible si todas las circunstancias factibles están cubiertas o no.
• Busque un flujo que tenga la cantidad máxima de cobertura de prueba.
• Utilizar o no la técnica de diseño de casos de prueba.
• El caso de prueba debe ser fácil de comprender.

TestCaseName	Número de paso	Crítico		Comentarios del autor	Comentarios
		Comentarios	Gravedad
ST100 CNNB-ET001	7	Módulo no vinculado	Crítico		Se requiere condición previa
ST200 SNNC-XD007	45	Parametro invalido	Importante	Fijado	——–
NJ120 BKKL-PP330	18	Variable sin usar	Menor	Fijado	———
	07	Necesita más valor de entrada	Importante	No arreglado	——–

4. Informe de ejecución de texto:

• Es el último documento producido por un líder de prueba después de que se hayan terminado todas las pruebas.
• El informe de ejecución de la prueba definió la estabilidad de la aplicación e incluyó datos como el número de casos escritos, ejecutados, aprobados y fallidos, así como sus porcentajes.
• El informe de ejecución de la prueba es un informe resumido final que define la calidad de la aplicación y ayuda a determinar si el programa puede entregarse o no al cliente.
• Cada módulo tiene su propia hoja de cálculo para seguir su progreso.

Nombre del módulo	Casos de prueba totales	Casos de prueba totales ejecutados	Caso de prueba total superado	Caso de prueba total fallido	Pasar%	Fallar%
Marketing	110	110	100	10	90%	10%
Pago	200	200	150	50	75%	25%
Producción	70	70	70	0	100%	0%
Ventas	100	90	45	45	50%	50%
Préstamos	120	120	100	20	80%	20%
totales =	600	590	465	125	sesenta y cinco%	35%

Este informe fue escrito por el líder de prueba y el ingeniero de prueba presentó las características particulares que él o ella había probado e implementado.

El líder de prueba envía este informe a las siguientes direcciones:

• Equipo de desarrollo.
• Administración.
• Gerente de pruebas.
• Cliente.

Cuando un equipo de desarrollo requiere la lista de casos de prueba fallidos. Hay una lista de nombres de casos de prueba, estados relacionados y comentarios, como se muestra en la siguiente tabla. Los datos del caso de prueba de Ventas se muestran en la siguiente tabla:

Número de paso	Nombre del caso de prueba	Estado del caso de prueba	Comentarios
1	ST100 CNNB-ET001	Pasar	–
2	ST200 SNNC-XD007	Pasar	–
3	ST200 SNNC-XD007	Ha fallado	Insecto
.
.
.
.
98
99
100

Errores comunes durante la revisión de casos de prueba

A continuación se muestran algunos errores comunes que se verifican durante el proceso de revisión del caso de prueba:

1. Errores de ortografía: Los errores de ortografía a veces pueden causar mucha confusión o dificultar la comprensión de una declaración.
2. Replicación de Casos de Prueba: Se relaciona con la reducción de casos de prueba redundantes. Es posible que dos o más casos de prueba estén probando el mismo elemento y se puedan combinar en uno, ahorrando tiempo y espacio.
3. Estándar/Directrices: Es fundamental examinar si todos los estándares y directrices se están siguiendo correctamente durante el proceso de revisión.
4. Redundancia: Cuando un caso de prueba se vuelve obsoleto debido a un cambio en los requisitos o ciertos ajustes, se habla de redundancia. Este tipo de escenarios de prueba deben eliminarse.
5. La manera utilizada: los casos de prueba deben estar escritos en un lenguaje básico y fácil de entender.
6. Gramática : si la gramática es incorrecta, el caso de prueba puede malinterpretarse, lo que lleva a resultados incorrectos.
7. Formato de la plantilla: cuando se sigue una plantilla adecuada, es sencillo agregar/modificar casos de prueba en el futuro y el plan del caso de prueba aparece ordenado.

Clasificación de defectos en la revisión de los casos de prueba

Cuando estas listas de verificación se utilizan de manera consistente y se descubren problemas, se recomienda que los defectos se clasifiquen en una de las siguientes categorías:

• Casos de prueba incompletos.
• Faltan casos de prueba negativos.
• Sin datos de prueba.
• Datos de prueba inapropiados/incorrectos.
• Comportamiento esperado incorrecto.
• Problemas gramaticales.
• Errores tipográficos.
• Tiempo/voz inconsistente.
• Resultados incompletos/número de ejecuciones de prueba.
• La información del defecto no se registró en el caso de prueba.

Los defectos podrían colarse en la producción si los casos de prueba no se revisan a fondo. Como resultado, se podrían informar problemas de producción, lo que afectaría la calidad del Software. Resolver problemas en este momento sería mucho más costoso que corregirlos si se hubieran descubierto durante la fase de prueba.