Barra Sup Mobile


La oficina de proyectos de informática
pmoinformatica.com

Páginas

lunes, 16 de junio de 2014

Plantilla de casos de prueba

Imagen de: pmoinformatica.com

Durante la fase de análisis de pruebas de un proyecto de desarrollo de software, el principal producto que se elabora es la especificación de diseño de casos de pruebas y sus respectivos datos de entrada, los cuales serán utilizados para evaluar la calidad del software y determinar si este cumple con los requisitos del software solicitados por el usuario.

Para elaborar el diseño de casos de prueba, el equipo de pruebas puede valerse de una plantilla de casos de prueba, la cual se las presentamos a continuación, como parte de la colección de plantillas que ofrecemos en PMOInformatica.com

Un diseño de casos de prueba bien elaborado debe especificar el área funcional sujeta de pruebas, la Funcionalidad que se está probando, el título y descripción del caso de prueba, los datos y acciones de entrada, resultados esperados (salidas), requerimientos específicos del ambiente de pruebas o de procedimiento, así como información para el seguimiento como el estatus actual, última fecha de cambio de estado y observaciones.

¿Listo para destacar en el campo de QA? El curso ISTQB Certified Tester Foundation Level 🔍 es tu clave para una certificación que te pondrá en el mapa profesional. 🚀🎯

PMOInformatica.com, “La Oficina de Proyectos de Informática”, presenta la plantilla del diseño de casos de pruebas de software, está libre de derechos de autor y puede ser usada libremente por nuestros lectores.

Contenido de la plantilla de casos de prueba:

  • Id: Cada caso de prueba debe tener un identificador (código) único.
  • Caso de Prueba: Título descriptivo del caso de prueba.
  • Descripción: Descripción del caso de prueba, indicando sus elementos, funcionalidades y acciones a ser ejercidas en el caso de prueba.
  • Fecha: Fecha en que fue creado el caso de prueba.
  • Área Funcional / Subproceso: Describe el área funcional, subproceso o modulo al que está asociado el caso de prueba. La intención es poder dividir los casos de prueba según la estructura jerárquica y casos de uso del sistema que se está probando y los procesos que este soporta.
  • Funcionalidad / Característica: Describe el título de la característica o funcionalidad que se está probando. Por ej. Suscripción al Servicio, Entrega de Orden, Selección de Producto, Consulta de Ordenes Pendientes.
  • Datos y acciones de entradas: Se especifica cada entrada que se requiere para ejecutar el caso de prueba. Etas entradas pueden ser valores o datos de entrada, y también acciones (por ejemplo presionar un botón). Deben identificarse los archivos o bases de datos involucrados.
  • Resultado esperado (Datos de Salida): Se especifica la salida que se espera de la ejecución de los casos de prueba con las entradas indicadas.
  • Requerimientos de ambiente de pruebas: Cualquier especificación del hardware y software especial requerido para ejecutar el caso de prueba, que no sea común a todos los casos. Las que sean comunes a todos los casos se deben especificar en la sección de entornos del Plan de Pruebas de Software.

Conviértete en experto en testing




Software Testing desde cero : MasterClass todo en 1 (2024)

Emprende tu viaje hacia una exitosa carrera en QA. Aprenderás desde cero sobre pruebas ágiles, APIs, y automatización con herramientas líderes en la industria como Selenium y Cypress. 

¡Prepárate para transformar tu futuro en el mundo del testing! 🚀🎯



También Visita nuestra página de Recursos en Pruebas de Software


¿Interesado en un método para levantar la información y elaborar el plan de pruebas de software?, sigue el enlace: Pruebas de software: 10 pasos para elaborar el plan de pruebas

  • Procedimientos especiales requeridos: Se describen cualquier restricción o condicionamiento en los procedimientos de prueba asociados a cada caso.
  • Dependencias con otros casos de prueba: Lista de los identificadores de los casos de prueba que deben ejecutarse antes de este caso. También puede incluir un sumario de la naturaleza de estas dependencias.

Información para el seguimiento



  • Resultado obtenido: Se describe el resultado real obtenido de la ejecución del caso de prueba (Este es una columna de seguimiento). Si esta difiere del resultado esperado, debería especificarse en un reporte de incidencia.
  • Estado: Estado actual del caso de prueba.
  • Última fecha de estado: Última fecha en que se ejecutó una acción referente al caso o que este cambio de estado.
  • Observaciones: Observaciones relacionadas con la ejecución de los casos y de los resultados que se obtuvieron.

Deben contemplarse las pruebas de verificación cuando se corrigen incidentes de software, pues el omitir estas pruebas o no considerar otros casos afectados es la falla más frecuente en la gestión de incidencias.

Ejemplos de como definir requerimientos funcionales y no funcionales

Requerimientos funcionales de un sistema de ventas

Ejemplos de requerimientos funcionales

Ejemplos de requerimientos no funcionales


¿Y tú? ¿Qué opinas?


¿Utilizas un Diseño de Casos de Prueba en tu organización?, ¿Qué información registras?, ¿Qué agregarías o quitarías de esta plantilla? Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web). Asimismo, te invitamos a suscribirse por los distintos canales.

Síguenos en Twitter, Facebook o Linkedin:

        

¿Buscas otras plantillas de desarrollo de software y metodologías ágiles?


1 comentario :

  1. Buen aporte para empezar.
    Para ser práctico, los campos textuales:
    Caso de Prueba
    Descripción
    Área Funcional / Sub proceso
    Funcionalidad / Característica
    deberían de estar conectado con la codificacion del Requisito Funcional y con el Caso de Uso referenciado en la documentacion y evitar repetir aqui informacion que ya esta en la documentacion.
    Por ultimo, creo importante enlazar cada prueba con la version/rev del software desplegado, para facilitar el seguimiento de versiones

    ResponderEliminar