Menú

Ejecución de pruebas en pruebas de software: proceso exacto y plan con ejemplo

test execution software testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Proceso y plan exactos para ejecutar casos de prueba con ejemplos reales.

Hoy, en nuestro Mini curso de formación de pruebas de software , estamos avanzando hacia la última etapa del STLC, que es la Ejecución de pruebas .

Puede consultar la lista de todos los tutoriales publicados en esta serie gratuita de formación de control de calidad en esta página: Capacitación de prueba de software de extremo a extremo en un proyecto en vivo.

La ejecución de la prueba es, sin duda, la fase más importante y de 'desarrollo' de la STLC y también todo el ciclo de vida del desarrollo. La razón es que la contribución y el trabajo de cada equipo / miembro del equipo se valida aquí:

Ejecución de pruebas en pruebas de software

  • ¿El analista de negocios ha interpretado correctamente los requisitos?
  • ¿El equipo de desarrollo ha traducido los requisitos comerciales a requisitos funcionales y, finalmente, a codificar correctamente?
  • ¿El arquitecto de datos y los administradores de bases de datos han diseñado los sistemas de back-end adecuados?

Bueno, la ejecución de la prueba es donde se encontrarían todas las respuestas a estas preguntas. Eso nos convierte en QAs los héroes de todo el proceso de creación de software, ¿no es así? :)

La ejecución de la prueba también es la parte de 'prueba' del SDLC.

software sql gratuito para windows 10

Una vez que los casos de prueba están escritos, compartidos con los BA y el equipo de desarrollo, revisados ​​por ellos, los cambios se notifican al equipo de control de calidad (si corresponde), el equipo de control de calidad hace las modificaciones necesarias: la fase de diseño de la prueba está completa. Ahora, tener los casos de prueba listos no significa que podamos iniciar la ejecución de la prueba. Necesitamos tener la aplicación lista, entre otras cosas.

Lo que vas a aprender:

Directrices de ejecución de pruebas

Hagamos ahora una lista de todas las cosas que son importantes para comprender la fase de ejecución de la prueba:

#1) los construir (el código escrito por el equipo de desarrollo está empaquetado en lo que se refiere a una compilación; esto no es más que una pieza de software instalable (AUT), lista para ser implementada en el entorno de control de calidad) que se implementa (en otras palabras, se instala y puesto a disposición) para el entorno de control de calidad es uno de los aspectos más importantes que debe suceder para que comience la ejecución de la prueba.

#2) La ejecución de la prueba ocurre en el Entorno de control de calidad . Para asegurarse de que el trabajo del equipo de desarrollo en el código no esté en el mismo lugar, donde el equipo de QA está probando, la práctica general es tener un entorno de QA y Dev dedicado. (También hay un entorno de producción para alojar la aplicación en vivo).

Esto es básicamente para preservar la integridad de la aplicación en varias etapas del ciclo de vida de SDLC. De lo contrario, lo ideal es que los 3 entornos sean de naturaleza idéntica.

#3) Tamaño del equipo de prueba no es constante desde el inicio del proyecto. Cuando se inicia el plan de prueba, es posible que el equipo solo tenga un líder de equipo. Durante la fase de diseño de la prueba, se incorporan algunos probadores. La ejecución de la prueba es la fase en la que el equipo alcanza su tamaño máximo.

#4) La ejecución de prueba también ocurre en al menos 2 ciclos (3 en algunos proyectos). Normalmente, en cada ciclo, se ejecutarán todos los casos de prueba (todo el conjunto de pruebas). El objetivo del primer ciclo es identificar cualquier bloqueo, defectos críticos y la mayoría de los defectos altos.

El objetivo del segundo ciclo es identificar los defectos remanentes altos y medios, corregir los huecos en los guiones y obtener resultados.

#5) La fase de ejecución de la prueba consta de: Ejecución de los scripts de prueba + Mantenimiento del script de prueba (corregir huecos en los scripts) + Reporting (defectos, estado, métricas, etc.) Por lo tanto, al planificar los horarios de esta fase y los esfuerzos deben ser estimados teniendo en cuenta todos estos aspectos y no solo la ejecución del script.

#6) Después de que se realiza el script de prueba y se implementa la AUT, y antes de que comience la ejecución de la prueba, hay un paso intermedio. Esto se llama 'Revisión de preparación de la prueba (TRR)' . Esta es una especie de paso de transición que finalizará la fase de diseño de la prueba y nos facilitará la ejecución de la prueba.

Para obtener información sobre este paso y una muestra de 'Lista de verificación de revisión de preparación para la prueba', consulte este enlace: Lista de comprobación de pruebas de software

#7) Además del TRR, hay algunas verificaciones adicionales antes de asegurarnos de que podemos seguir adelante con la aceptación de la compilación actual que se implementa en el entorno de control de calidad para la ejecución de la prueba.

Esos son los Pruebas de humo y cordura . Información detallada sobre cuáles son estos en: ¿Qué es la prueba de humo y cordura?

#8) Después de completar con éxito las pruebas TRR, Smoke y Sanity, el ciclo de prueba comienza oficialmente.

#9) Prueba exploratoria se llevaría a cabo una vez que la compilación esté lista para la prueba. El propósito de esta prueba es asegurarse de que se eliminen los defectos críticos antes de que puedan comenzar los siguientes niveles de prueba. Esta prueba exploratoria se lleva a cabo en la aplicación sin ningún script de prueba ni documentación. También ayuda a familiarizarse con AUT.

convertidor de youtube a mp4 para android

#10) Al igual que las otras fases del STLC, el trabajo también se divide entre los miembros del equipo en la fase de ejecución de la prueba. La división puede basarse en módulos o casos de prueba contados o en cualquier otra cosa que tenga sentido.

#11) El resultado principal de la fase de ejecución de la prueba es principalmente en forma de informes, es decir, Informe de defectos y Informe de estado de ejecución de la prueba. El proceso detallado para informar se puede encontrar en Informes de ejecuciones de prueba.

Documento de nuevas columnas en casos de prueba

El documento del caso de prueba ahora se amplía con las siguientes dos columnas: Estado y resultado real .

( Nota : Para la ejecución de pruebas de proyectos en vivo, hemos agregado y actualizado estas columnas con los resultados de la ejecución de pruebas en la hoja de cálculo de casos de prueba que se proporciona para descargar a continuación)

# 1) Columna de estado

La ejecución de la prueba no es más que utilizar los pasos de la prueba en el AUT, proporcionar los datos de prueba (como se identifica en el documento del caso de prueba) y observar el comportamiento del AUT para ver si satisface el resultado esperado o no.

Si no se cumple el resultado esperado, se puede interpretar como un defecto. Y el estado del caso de prueba se convierte en 'Fallo' y si se cumple el resultado esperado, el estado es 'Aprobado'. Si el caso de prueba no se puede ejecutar debido a alguna razón (un defecto existente o un entorno no compatible), el estado será 'Bloqueado'.

El estado de un caso de prueba que aún no se ha ejecutado se puede establecer en No ejecutado / no ejecutado o se puede dejar vacío.

  • Para un caso de prueba con varios pasos, si no se cumple el resultado esperado de un determinado paso (en medio de los pasos del caso de prueba), el estado del caso de prueba se puede establecer en 'Fallo' allí mismo y no es necesario ejecutar los siguientes pasos.
  • El estado 'Fallo' se puede indicar en color rojo, si desea llamar la atención sobre él inmediatamente.

# 2) Columna de resultado real

Este es un espacio donde los probadores podemos registrar cuál es la desviación en el resultado esperado. Cuando se cumple el resultado esperado (o un caso de prueba cuyo estado es 'Aprobado'), este campo se puede dejar vacío. Porque, si se cumple el resultado esperado, significa que el resultado real = resultado esperado, lo que significa que volver a escribirlo en la columna de resultado real será una repetición y una redundancia.

Se puede adjuntar una captura de pantalla de la desviación a esta columna para una mayor claridad de cuál es el problema.

Resultados de ejecución de prueba para OrangeHRM Live Project

Consigamos ahora OrangeHRM y llevemos a cabo la ejecución de la prueba según las pautas mencionadas anteriormente.

Aquí hay algunos puntos a tener en cuenta:

  • La plantilla de caso de prueba ampliada.
  • Las pruebas exploratorias indicadas deben realizarse sin guiones de prueba. Así que no dude en probar la aplicación en paralelo como mejor le parezca.
  • Debido a las limitaciones que tenemos para presentar el proyecto en vivo en forma de contenido legible, solo se muestra una cantidad limitada de casos de prueba / funcionalidad de la aplicación OrangeHRM en la plantilla de ejecución de prueba de muestra. Nuevamente, siéntase en trabajar más para obtener la experiencia más práctica.
  • Los conjuntos de pruebas de Cordura y Humo también se agregan al documento para darle una idea de qué tipo de casos de prueba se consideran para estas etapas.
  • Los defectos aún no se registran, a pesar de que el estado de algunos casos de prueba está configurado como 'Fallo'. Esto se debe a que registrar los defectos es el siguiente aspecto más importante / comúnmente trabajado en un aspecto de nuestra vida como probadores. Entonces, queremos tratarlo en detalle en el próximo artículo.

Casos de prueba con resultados de ejecución:

=> Haga clic aquí para descargar el documento de ejecución de casos de prueba.

Contiene - Resultado de ejecución de casos de prueba, pruebas de humo, pruebas de cordura, prueba exploratoria - hojas de cálculo

cómo abrir un archivo .json

Por último, si se utilizó una herramienta de gestión de pruebas para crear y mantener el caso de prueba, también se puede utilizar para la ejecución de la prueba. El uso de una herramienta facilita los informes, pero por lo demás, el proceso de ejecución de los casos de prueba es el mismo. Consulte este artículo para tener una idea de cómo utilizar HP ALM para la ejecución de casos de prueba .

(Haga clic en la imagen para ampliarla)

ALM para el resultado de la excitación de la prueba

Esto nos lleva al final de otro segmento interesante del proceso de prueba. En el siguiente y último artículo de este minicurso gratuito en línea de formación sobre control de calidad de pruebas de software , analizaremos los defectos en detalle; resumir temas como 'cuándo dejar de realizar pruebas', métricas y aprobación de control de calidad.

=> Capacitación de control de calidad, día 6: Seguimiento de errores, métricas de prueba y aprobación de la prueba

Háganos saber cómo lo estamos haciendo y esté atento al próximo artículo.

Lectura recomendada

^