STLC - Ejecución de prueba
La ejecución de la prueba es el proceso de ejecutar el código y comparar los resultados esperados y reales. Los siguientes factores deben tenerse en cuenta para un proceso de ejecución de prueba:
- Según un riesgo, seleccione un subconjunto de la suite de pruebas que se ejecutará para este ciclo.
- Asigne los casos de prueba en cada conjunto de pruebas a los probadores para su ejecución.
- Ejecute pruebas, informe errores y capture el estado de las pruebas de forma continua.
- Resuelva los problemas de bloqueo a medida que surjan.
- Informe el estado, ajuste las asignaciones y reconsidere los planes y las prioridades a diario.
- Informar los resultados y el estado del ciclo de prueba.
Los siguientes puntos deben tenerse en cuenta para la ejecución de la prueba.
En esta fase, el equipo de QA realiza la validación real de AUT basada en casos de prueba preparados y compara el resultado paso a paso con el resultado esperado.
El criterio de entrada de esta fase es la finalización del plan de prueba y la fase de desarrollo de casos de prueba, los datos de prueba también deben estar listos.
La validación de la configuración del entorno de prueba siempre se recomienda a través de pruebas de humo antes de ingresar oficialmente a la ejecución de la prueba.
Los criterios de salida requieren la validación exitosa de todos los casos de prueba; Los defectos deben cerrarse o aplazarse; La ejecución del caso de prueba y el informe de resumen de defectos deben estar listos.
Actividades para la ejecución de pruebas
El objetivo de esta fase es la validación en tiempo real de AUT antes de pasar a la producción / lanzamiento. Para cerrar esta fase, el equipo de control de calidad realiza diferentes tipos de pruebas para garantizar la calidad del producto. Junto con esta notificación de defectos y la repetición de pruebas también es una actividad crucial en esta fase. Las siguientes son las actividades importantes de esta fase:
Prueba de integración del sistema
La validación real de producto / AUT comienza aquí. La prueba de integración del sistema (SIT) es una técnica de prueba de caja negra que evalúa el cumplimiento del sistema frente a requisitos específicos / casos de prueba preparados.
Las pruebas de integración del sistema generalmente se realizan en un subconjunto del sistema. La SIT se puede realizar con un uso mínimo de herramientas de prueba, se verifica las interacciones intercambiadas y también se investiga el comportamiento de cada campo de datos dentro de la capa individual. Después de la integración, hay tres estados principales de flujo de datos:
- Estado de los datos dentro de la capa de integración
- Estado de los datos dentro de la capa de la base de datos
- Estado de los datos dentro de la capa de aplicación
Note- En las pruebas SIT, el equipo de QA intenta encontrar tantos defectos como sea posible para garantizar la calidad. El objetivo principal aquí es encontrar tantos errores como sea posible.
Notificación de defectos
Un error de software surge cuando el resultado esperado no coincide con el resultado real. Puede ser un error, falla, falla o falla en un programa de computadora. La mayoría de los errores surgen de errores y errores cometidos por desarrolladores o arquitectos.
Mientras realiza las pruebas de SIT, el equipo de control de calidad encuentra este tipo de defectos y es necesario informarlos a los miembros del equipo en cuestión. Los miembros toman más medidas y arreglan los defectos. Otra ventaja de los informes es que facilita el seguimiento del estado de los defectos. Hay muchas herramientas populares como ALM, QC, JIRA, Version One, Bugzilla que admiten informes y seguimiento de defectos.
El informe de defectos es un proceso para encontrar defectos en la aplicación que se está probando o en el producto probando o registrando los comentarios de los clientes y creando nuevas versiones del producto que corrigen los defectos en función de los comentarios del cliente.
El seguimiento de defectos también es un proceso importante en la ingeniería de software, ya que los sistemas complejos y críticos para el negocio tienen cientos de defectos. Uno de los factores más desafiantes es gestionar, evaluar y priorizar estos defectos. El número de defectos se multiplica durante un período de tiempo y, para gestionarlos de forma eficaz, se utiliza un sistema de seguimiento de defectos para facilitar el trabajo.
Mapeo de defectos
Una vez que se informa y registra el defecto, se debe asignar a los casos de prueba fallidos / bloqueados correspondientes y los requisitos correspondientes en la Matriz de trazabilidad de requisitos. Esta asignación la realiza Defect Reporter. Ayuda a hacer un informe de defectos adecuado y analizar la picardía en el producto. Una vez que los casos de prueba y los requisitos se mapean con el defecto, las partes interesadas pueden analizar y tomar una decisión sobre si corregir o diferir el defecto en función de la prioridad y la gravedad.
Nueva prueba
La repetición de la prueba consiste en ejecutar una prueba previamente fallida contra AUT para comprobar si el problema está resuelto. Una vez que se ha solucionado un defecto, se realiza una nueva prueba para verificar el escenario en las mismas condiciones ambientales.
Durante la nueva prueba, los evaluadores buscan detalles granulares en el área cambiada de funcionalidad, mientras que las pruebas de regresión cubren todas las funciones principales para garantizar que no se rompan funcionalidades debido a este cambio.
Pruebas de regresión
Una vez que todos los defectos están en estado cerrado, aplazado o rechazado y ninguno de los casos de prueba está en progreso / fallido / sin estado de ejecución, se puede decir que las pruebas de integración del sistema se basan completamente en los casos de prueba y los requisitos. Sin embargo, se requiere una ronda de pruebas rápidas para garantizar que ninguna de las funciones se rompa debido a cambios en el código o correcciones de defectos.
La prueba de regresión es una técnica de prueba de caja negra que consiste en volver a ejecutar aquellas pruebas que han tenido un impacto debido a cambios en el código. Estas pruebas deben ejecutarse con la mayor frecuencia posible a lo largo del ciclo de vida del desarrollo de software.
Tipos de pruebas de regresión
Final Regression Tests- Se realiza una "prueba de regresión final" para validar la compilación que no ha sufrido cambios durante un período de tiempo. Esta compilación se implementa o se envía a los clientes.
Regression Tests - Se realiza una prueba de regresión normal para verificar si la compilación NO ha roto ninguna otra parte de la aplicación debido a los cambios de código recientes para la corrección de defectos o para la mejora.
Diagrama de bloques de actividades
El siguiente diagrama de bloques muestra las actividades importantes realizadas en esta fase; también muestra la dependencia de las fases anteriores -
