test plan tutorial guide write software test plan document from scratch
Una guía definitiva para el documento del plan de prueba de software:
Este tutorial le explicará todo sobre el documento del plan de prueba de software y lo guiará con las formas de escribir / crear un plan de prueba de software detallado desde cero junto con el diferencias entre la planificación de pruebas y la ejecución de pruebas.
Día 3 de capacitación en control de calidad del proyecto en vivo - Después de presentarles a nuestros lectores la aplicación en vivo de nuestro Formación gratuita en línea sobre pruebas de software , llegamos a conocer cómo revisar SRS y escribir escenarios de prueba . Y ahora es el momento adecuado para profundizar en la parte más importante del ciclo de vida de las pruebas de software, es decir, Planificación de pruebas .
Lista de TODOS los tutoriales de esta serie:
Documento de planificación de pruebas:
Tutorial #1: Cómo escribir un documento de plan de prueba (Este tutorial)
Tutorial #2: Contenido de la plantilla del plan de prueba simple
Tutorial #3: Ejemplo de plan de prueba de software
Tutorial #4: Diferencia entre el plan de prueba y la estrategia de prueba
Tutorial #5: Cómo escribir un documento de estrategia de prueba
Consejos para la planificación de pruebas:
Tutorial #6: Gestión de riesgos durante la planificación de pruebas
Tutorial #7: Qué hacer cuando no hay tiempo suficiente para probar
Tutorial #8: Cómo planificar y gestionar proyectos de prueba de forma eficaz
Planificación de pruebas en diferentes etapas de STLC:
Tutorial #9: Planificación de pruebas de regresión
Tutorial #10: Plan de pruebas UAT
Tutorial #11: Plan de prueba de aceptación
Planificación de la automatización de pruebas:
Tutorial #12: Plan de prueba de automatización
Tutorial #13: Planificación de pruebas de aplicaciones ERP
Tutorial #14: Planificación de pruebas de HP ALM
Tutorial #15: Planificación de pruebas de mapa mental
Tutorial #16: Plan de prueba y banco de trabajo de JMeter
Lo que vas a aprender:
- Creación del plan de prueba: la fase más importante de la prueba
- Planificación de pruebas frente a ejecución de pruebas
Creación del plan de prueba: la fase más importante de la prueba
Este tutorial informativo le explicará las formas y procedimientos involucrados en la redacción de un documento de plan de prueba.
Al final de este tutorial, hemos compartido un Documento de plan de prueba completo de 19 páginas que fue creado específicamente para el proyecto en vivo OrangeHRM, que estamos usando para este Serie de formación de control de calidad
¿Qué es un plan de prueba?
El plan de prueba es un documento dinámico . El éxito de un proyecto de prueba depende de un documento de plan de prueba bien redactado que esté actualizado en todo momento. El plan de prueba es más o menos como un plano de cómo va la actividad de prueba tener lugar en un proyecto.
A continuación se presentan algunos consejos sobre un plan de prueba:
#1) Test Plan es un documento que actúa como punto de referencia y solo en base a que las pruebas se llevan a cabo dentro del equipo de QA.
#2) También es un documento que compartimos con los analistas de negocios, los gerentes de proyectos, el equipo de desarrollo y los demás equipos. Esto ayuda a mejorar el nivel de transparencia del trabajo del equipo de control de calidad para los equipos externos.
#3) Está documentado por el gerente de garantía de calidad / líder de garantía de calidad basándose en las aportaciones de los miembros del equipo de garantía de calidad.
#4) La planificación de pruebas se suele asignar con 1/3rddel tiempo que lleva todo el compromiso de control de calidad. El otro 1/3rdes para Diseño de pruebas y el resto es para Ejecución de pruebas.
#5) Este plan no es estático y se actualiza a pedido.
#6) Cuanto más detallado y completo sea el plan, más exitosa será la actividad de prueba.
Proceso STLC
Ahora estamos a la mitad de nuestra serie de proyectos en vivo. Por lo tanto, retrocedamos un paso de la aplicación y echemos un vistazo al proceso del ciclo de vida de las pruebas de software (STLC).
STLC se puede dividir aproximadamente en 3 partes:
- Planificación de pruebas
- Diseño de prueba
- Ejecución de pruebas
En nuestro tutorial anterior, supimos que en un proyecto de control de calidad práctico, comenzamos con la revisión de SRS y la redacción del escenario de prueba, que en realidad es el segundo paso en el proceso STLC. El diseño de la prueba incluye los detalles sobre qué probar y cómo probar.
¿Por qué no empezamos con la planificación de pruebas?
De hecho, la planificación es la primera y más importante actividad que ocurre en cualquier proyecto de prueba.
Planificación de pruebas en las fases SDLC
Fase SDLC | Actividad de planificación de pruebas |
---|---|
Horarios => | Preparación del escenario de prueba |
Iniciado | Idealmente, el equipo de control de calidad debería involucrarse mientras el alcance del proyecto se recopila del cliente / cliente en forma de requisitos comerciales. Pero en el mundo real, ese no es el caso. Desde un punto de vista práctico, la participación del equipo de QA es NULA. Al final de esta fase, se finaliza el BRD y se crea un plan de proyecto básico. |
Define | SRS se crea a partir del BRD. Se crea el borrador inicial del plan de prueba. En este punto, dado que el equipo de control de calidad no ha terminado con la revisión del SRS, el alcance de las pruebas no está claro. Entonces, el TP en esta fase solo contendrá información sobre cuándo se realizarán las pruebas, información del proyecto y la información del equipo (si la tenemos). |
Diseño | Se lleva a cabo la revisión del SRS y se identifica el alcance de las pruebas. Tenemos mucha más información sobre qué probar y una buena estimación de cuántos casos de prueba podríamos obtener, etc. Se crea una segunda versión del plan de prueba incorporando toda esta información. |
De la tabla anterior, está muy claro que un plan de prueba no es solo un documento que puede crear de una vez y usarlo a partir de ese momento.
Componentes de un documento de plan
Elementos en una plantilla de plan de prueba | ¿Qué contienen? |
---|---|
Alcance => | Escenarios de prueba / Objetivos de prueba que serán validados. |
Fuera de alcance => | Mayor claridad sobre lo que no vamos a cubrir |
Supuestos => | Todas las condiciones que deben cumplirse para que podamos proceder con éxito. |
Documentación de prueba: casos de prueba / datos de prueba / entorno de configuración | |
Ejecución de pruebas | |
Ciclo de prueba: cuántos ciclos | |
Fecha de inicio y finalización de los ciclos | |
Roles y responsabilidades => | Los miembros del equipo se enumeran |
Quien va a hacer que | |
los propietarios del módulo se enumeran y su información de contacto | |
Entregables => | ¿Qué documentos (artefactos de prueba) se van a producir en qué plazos? |
¿Qué se puede esperar de cada documento? | |
Medio Ambiente => | ¿Qué tipo de requisitos ambientales existen? |
¿Quién va a estar a cargo? | |
¿Qué hacer en caso de problemas? | |
Herramientas => | Por ejemplo, JIRA para seguimiento de errores |
Acceso | |
¿Cómo usar JIRA? | |
Gestión de defectos => | ¿A quién vamos a informar de los defectos? |
¿Cómo vamos a informar? | |
¿Qué se espera? ¿Proporcionamos una captura de pantalla? | |
Riesgos y gestión de riesgos => | Los riesgos se enumeran |
Se analizan los riesgos, se documenta la probabilidad y el impacto | |
Se elaboran planes de mitigación de riesgos | |
Criterios de salida => | ¿Cuándo dejar de probar? |
Como toda la información mencionada anteriormente es la más crítica para la el trabajo diario de un proyecto de control de calidad , es importante mantener actualizado el documento del plan de vez en cuando.
Ejemplo de documento de plan de prueba para un proyecto en vivo
Se crea un documento de modelo de plan de prueba de muestra para nuestro ' VERSIÓN ORANGEHRM 3.0 - MI MÓDULO DE INFORMACIÓN ” Proyecto y adjunto a continuación. Por favor échale un vistazo. Se han agregado comentarios adicionales al documento en rojo para explicar las secciones.
Este plan de pruebas es para las fases Funcional y UAT. También explica el proceso de gestión de pruebas mediante la herramienta HP ALM.
Descargar muestra del plan de prueba:
Formato de documento => Haga clic aquí para descargar el plan de prueba en formato Doc este es el que creamos para el proyecto en vivo OragngeHRM y también lo estamos usando para nuestro curso intensivo de pruebas de software.
Formato PDF => Haga clic aquí para descargar el plan de prueba en formato de archivo pdf .
Archivos de hoja de trabajo (.xls) a los que se hace referencia en las versiones de documento / pdf anteriores => Descargar el Archivos XLS referidos en el plan de prueba anterior
Cuál es el mejor servicio de correo electrónico gratuito
La plantilla anterior es muy completa y detallada también. Por lo tanto, lea detenidamente para obtener los mejores resultados.
Como el plan también se crea y explica bien, pasemos a la siguiente fase tanto en SDLC como en STLC.
Código de SDLC:
Mientras que el resto del proyecto dedicaba su tiempo a la creación de TDD, nosotros los QA identificamos el alcance de prueba (escenarios de prueba) y creamos el primer borrador del plan de prueba confiable. La siguiente fase de SDLC es verificar cuándo ocurre la codificación.
Los desarrolladores son el principal punto de enfoque de todo el equipo en esta fase. El equipo de control de calidad también se entrega a la tarea más importante, que no es más que 'Creación de casos de prueba' .
Si los escenarios de prueba eran 'Qué probar', entonces los casos de prueba tratan con 'Cómo probar'. La creación de casos de prueba es una parte predominante de la fase de diseño de prueba del STLC. La entrada para la actividad de creación de casos de prueba son los escenarios de prueba y el documento SRS.
Para probadores como nosotros, Casos de prueba son el verdadero negocio - es la materia en la que pasamos la mayor parte de nuestro tiempo. Los creamos, los revisamos, los ejecutamos, los mantenemos, los automatizamos, y bueno, te haces una idea. Independientemente de la experiencia que tengamos y del papel que desempeñemos en un proyecto, seguiríamos trabajando con los casos de prueba.
Planificación de pruebas frente a ejecución de pruebas
La planificación de pruebas de software reserva un alcance mucho mejor comparativamente en el Fase STLC . La entrega de software de calidad está garantizada por el equipo de pruebas. Y lo que se debe hacer en las pruebas se decide realmente en la fase de planificación de la prueba.
Esta sección proporcionará una descripción general completa e incluirá ilustraciones sobre la importancia de la planificación de la prueba y la fase de ejecución . Después de leer esto, comprenderá la importancia significativa de la fase de planificación en comparación con la fase de ejecución con más ejemplos en vivo y estudios de casos para ilustraciones .
Planificación de pruebas
A continuación, se indican algunas cosas esenciales que se deben tener en cuenta durante la planificación:
La planificación de una prueba es la sección más importante del ciclo de pruebas. El resultado de la fase de prueba estará determinado por la calidad y el alcance de la planificación que se haya realizado para la prueba.
La planificación de la prueba generalmente ocurre durante la fase de desarrollo con el fin de ahorrar el tiempo de espera para la ejecución de la prueba con el acuerdo mutuo de todas las partes involucradas.
Algunos hechos importantes que deben tenerse en cuenta incluyen:
- La planificación debe iniciarse en paralelo al desarrollo, siempre que se hayan congelado los requisitos.
- Todas las partes interesadas, como diseñadores, desarrolladores, clientes y evaluadores, deben participar al finalizar el plan.
- La planificación no se puede elaborar para necesidades comerciales no confirmadas o no aprobadas.
- Se aplicarán planes de prueba similares a los nuevos requisitos que requerirá la empresa.
Ejemplo 1
El equipo de desarrollo está trabajando en un software XYZ después de recibir algunos requisitos de los clientes. El equipo de pruebas casi ha comenzado su preparación para la fase de definición o planificación de la prueba. La planificación de la prueba debe diseñarse para abordar los requisitos iniciales citados por los clientes. Esto ha sido realizado por el equipo de pruebas.
Ninguna de las otras partes interesadas participó durante esta fase y la planificación se ha congelado.
lugares para ver anime gratis
El equipo de desarrollo ahora ha realizado algunos cambios en el flujo comercial para abordar algunos problemas en su trabajo con la aprobación del cliente. Ahora el software ha llegado al equipo de pruebas para realizar una prueba. Con el plan de pruebas según el flujo comercial anterior, el equipo de pruebas ha comenzado su ronda de pruebas. Esto afectó los entregables de las pruebas con muchos retrasos, ya que el flujo comercial modificado no se compartió con el equipo de pruebas.
Observación del ejemplo 1:
Hay ciertas observaciones del ejemplo anterior.
Son:
- Comprender el nuevo flujo de negocios consumió mucho tiempo.
- Retrasos en los entregables del proyecto.
- Reelaboración de la planificación y otras tareas de la fase.
Todas estas observaciones deben convertirse en necesidades esenciales para un producto de prueba eficaz.
Componentes principales en la fase de planificación
A continuación se presentan los componentes principales que participan en la fase de planificación.
- Estrategia de prueba: Esta es una de las secciones más importantes que puede explicar la estrategia que se utilizará durante las pruebas.
- Cobertura de prueba: Esto es esencialmente necesario y hará un mapeo de conformidad de las necesidades comerciales y los casos de prueba para que uno pueda asegurar si todo el software ha sido probado o no.
- Ciclos de prueba y duraciones: Esto puede volverse muy crítico dependiendo de las rondas de desarrollo y su tiempo para completar cada ronda.
- Criterios de aprobación / reprobación: Es muy necesario uno en el que se definen los criterios de aprobación y reprobación. Algunas veces esto también será definido por los clientes.
- Requisitos comerciales y técnicos: La necesidad de tener el software y los propósitos a los que sirven estarán claramente definidos junto con las explicaciones de bajo nivel.
Limitaciones
Hay pocas cosas que realmente puedan controlar la fase de prueba del software, especialmente la fase de planificación.
Las siguientes son algunas áreas:
- Características para ser probado y no probado: Esto señalará claramente qué se debe probar y qué no.
- Criterios de suspensión y requisitos de reanudación: Este es el tomador de decisiones sobre el software desarrollado y los criterios definidos para suspender la prueba o reanudar la prueba.
- Responsabilidades: Un evaluador tendrá múltiples responsabilidades para garantizar los problemas, errores y defectos en el software bajo prueba. Además, los errores deben validarse con los desarrolladores para que los corrijan.
- Riesgos y contingencias: Los riesgos asociados durante las pruebas deben mencionarse claramente y las contingencias adecuadas durante el tiempo deben definirse con mucha claridad.
Estudio de caso # 1
El equipo de desarrollo de Ejemplo 1 tiene previsto lanzar el software XYZ en 2 fases. La fase 1 tiene muchas características que deben probarse y pocas no. Una vez más, el software se ha lanzado para realizar pruebas sin mantener informado al equipo de pruebas sobre las funciones que aún no se han desarrollado.
Ahora el equipo de pruebas comienza su ejecución basándose en los planes de prueba que ya han elaborado. Vienen con una gran cantidad de errores. Y después de la validación del equipo de desarrollo, la mayoría de ellos se vuelven inválidos.
Observaciones del estudio de caso anterior:
- El equipo de desarrollo entregará el software al equipo de pruebas con notas de la versión y notas de cobertura de requisitos (notas de la versión).
- Las funciones que se van a probar y que no se deben probar deben factorizarse en función del software publicado antes de la prueba.
- Los criterios de suspensión y reanudación de las pruebas deben definirse adecuadamente.
- Los riesgos y los planes de contingencia por la indisponibilidad del software deben representarse perfectamente.
También leer=> Cómo gestionar los riesgos durante la fase de planificación de pruebas
Plan de ejecución de pruebas
La ejecución de casos de prueba es uno de los pasos de la fase STLC. Esto tendrá que realizarse de acuerdo con los planes que se elaboraron anteriormente. Por lo tanto, la planificación siempre sigue dominando toda la fase de prueba. A continuación se muestra un ejemplo en el que el equipo de prueba se ve afectado por los cambios en los planes de prueba.
Ejemplo # 2
La prueba del software A se inició según el plan 1 elaborado por el equipo. Posteriormente, debido a las necesidades del negocio y los cambios, el plan de pruebas tuvo que sufrir algunos cambios. Esto, a su vez, ha obligado a cambiar los casos de prueba o la ejecución.
Observaciones:
- El plan de prueba determinará la ejecución del caso de prueba.
- La parte de ejecución varía según el plan.
- Siempre que el plan y los requisitos sean válidos, los casos de prueba también lo son.
Formas de superar los problemas durante la ejecución
Los probadores se encontrarán más a menudo con varios escenarios mientras realizan la ejecución de la prueba. Aquí es cuando los evaluadores deberán comprender y conocer las formas de resolver el problema o al menos encontrar una solución para el problema.
Ejemplo # 3
Durante la ejecución del caso de prueba del software B, el equipo de pruebas se encuentra con varios problemas. Pocos son tapones de espectáculos. Requieren que los desarrolladores los ayuden a superar el problema. Esto ha sucedido varias veces y el resultado es un retraso en la prueba de los entregables.
Observaciones:
- Existe una dependencia para superar los problemas y problemas ambientales.
- Los evaluadores requieren una comprensión adecuada del entorno.
- Los problemas conocidos y que ocurren con frecuencia deben documentarse para superarlos en el futuro.
Control y gestión de versiones
Control de versiones y la gestión de los planes de prueba y los casos de prueba son realmente importantes para mostrar los entregables oportunos. Esto es más significativo y, a menudo, se hace con la ayuda de una herramienta de control de versiones.
Una herramienta de control de versiones no solo les ayuda a controlar los planes de prueba, sino que también ayuda en la gestión de defectos. Cuando hay proyectos de prueba con varios ciclos y versiones, estas herramientas pueden ayudar mucho a reducir las métricas para respaldar los entregables de prueba.
Además, lea=> Gestión de riesgos en la fase de ejecución de la prueba
Diferencia entre planificación y ejecución de pruebas
Las siguientes son algunas áreas importantes que señalarán cómo la planificación diferirá de la fase de ejecución de la prueba.
Área de comparación | Planificación de pruebas | Ejecución de pruebas |
---|---|---|
Posicionamiento entregable | El plan de prueba se considerará como un resultado importante para la actividad de prueba. Esto se hará como el primer paso del proceso de prueba. | Este vendrá como último miembro del banco en la fase de prueba. Después de la ejecución, el estado de defectos / errores junto con el estado de ejecución del caso de prueba se compartirán como uno de los entregables de prueba. |
Persona responsable | El administrador de la prueba preparará el plan de prueba y lo compartirá con todas las partes interesadas para su revisión. | Normalmente, esto lo hará el probador teniendo en cuenta que los casos de prueba preparados han sido aprobados y firmados. |
Enfoque principal | Las áreas de enfoque del plan de prueba son cómo se deben realizar las pruebas, qué se debe considerar y qué no, entorno que se puede usar, programas de prueba, etc. | La ejecución de la prueba se centra principalmente en la ejecución de los casos de prueba proporcionados para ser probados en el software. |
Modo recurrente o iterativo | Esta es una actividad de una sola vez. Dicho esto, puede que requiera o no modificaciones para las futuras versiones del software. | Hay 3 partes en esta área cuando hablamos de iteración. 1. Pruebas funcionales. 2. Prueba de regresión. 3. Nueva prueba. |
Entradas | Las entradas para la creación de un plan de prueba son realmente necesarias y deben ser proporcionadas por analistas de negocios, arquitectos, clientes, etc. | El documento del caso de prueba es la entrada principal. |
Período en el que se puede iniciar | Debe iniciarse junto con el ciclo de desarrollo para obtener resultados efectivos y ahorrar tiempo. Pero hay pocos modelos como el modelo de caída de agua en los que la fase de prueba comenzará solo después de que se haya completado la fase de desarrollo. | La ejecución debe iniciarse estrictamente después de que se haya realizado el desarrollo del software. |
Periodo de cierre | El plan de prueba no tendrá tal período de cierre. Generalmente, se proporcionará una firma de todas las partes interesadas para el software. | La ejecución de una versión o ciclo específico se considerará cerrada cuando todos los casos de prueba se hayan ejecutado contra el software. |
Uso de herramientas | No se utilizarán muchas herramientas ya que la actividad de planificación será más de discusión y documentación. Para realizar un seguimiento de cualquier cambio en el plan, los administradores de pruebas normalmente usarán cualquier herramienta de control de versiones como VSS u otra cosa. | Dependerá del modo de ejecución. En caso de manual no se utilizará ninguna herramienta para la ejecución. Pero para registrar los defectos y gestionarlos, se utilizarán algunas herramientas. En caso de pruebas de automatización, la ejecución se realizará con la ayuda de herramientas como QTP, SELENIUM, etc. |
Impactos en los entregables | Esto afectará todas las fases de prueba de una manera más amplia. | Esto afectará el ciclo posterior o la versión que se probará. |
Las ilustraciones anteriores podrían haber explicado mejor la importancia de las actividades de planificación de pruebas que la de la ejecución de pruebas. De alguna manera, la fase de ejecución es una especie de subconjunto del plan de prueba.
Según la estrategia de prueba, el enfoque y otras cosas, el plan de prueba tiene una mayor probabilidad de ser modificado para dar cabida a los cambios. Definitivamente, la ejecución de la prueba depende de los casos de prueba. Los casos de prueba se basan en los planes. Por lo tanto, los cambios en los planes garantizarán cambios en los casos de prueba.
Pero, a la inversa, los cambios en los casos de prueba no necesitan buscar cambios obligatoriamente. Esta es una de las principales razones por las que la planificación se mantiene en comparación con la fase de ejecución de la prueba.
Nuestro próximo tutorial le explicará más sobre cómo crear casos de prueba. ¿Qué son? Y cómo podemos hacer que nos funcionen junto con los otros aspectos relacionados con los casos de prueba.
SIGUIENTE Tutorial=> Capacitación de control de calidad, día 4: Redacción de casos de prueba a partir del documento SRS
¿Es usted un experto en redactar un documento de plan de prueba? Entonces este es el lugar adecuado para compartir sus valiosos consejos de mejora para los próximos probadores. ¡¡No dude en expresar sus pensamientos con nosotros en la sección de comentarios a continuación !!
Lectura recomendada
- Plantilla de plan de prueba de software de muestra con formato y contenido
- Guía de documentación de pruebas de software (por qué es importante)
- Recursos y descargas de pruebas de software de control de calidad
- Ejemplo de documento de plan de prueba (ejemplo de plan de prueba con detalles de cada campo)
- Ejecución de pruebas en pruebas de software: proceso exacto y plan con ejemplo
- Cómo escribir un documento de estrategia de prueba (con una plantilla de estrategia de prueba de muestra)
- Redacción de casos de prueba desde el documento SRS (DESCARGAR casos de prueba de muestra de proyectos en vivo)
- Programa del curso de pruebas de software: plan de formación detallado del curso en línea