Usa esta plantilla
La documentación de pruebas sólida es la base de cualquier práctica de ingeniería de calidad. Con Trupeer, puedes ahorrar horas en la redacción de documentación de pruebas empezando con plantillas de documentación de pruebas gratuitas, personalizándolas con tus directrices de marca y convirtiendo los planes de prueba en recorridos en vídeo que alinean ingeniería, producto y QA.
¿Qué son las plantillas de documentación de pruebas gratuitas?
Las plantillas gratuitas de documentación de pruebas son estructuras reutilizables para los documentos que produce un esfuerzo de pruebas: la estrategia, el plan, los casos de prueba, los datos, los resultados y los informes de defectos.
La mayoría de las búsquedas en realidad buscan un solo documento. Los casos de prueba son en lo que los testers invierten su tiempo escribiendo, y una plantilla de caso de prueba es una tabla con pasos, lo cual no es difícil.
Las plantillas no son el problema. Cada plantilla de caso de prueba publicada tiene las mismas columnas: identificador, título, precondiciones, pasos, resultado esperado, resultado real, estado. Esa estructura es correcta y se ha mantenido estable durante décadas.
Lo que está mal en la mayoría de los conjuntos de pruebas es el equilibrio del esfuerzo dentro de esa estructura, y eso produce casos de prueba que pueden pasar aunque el sistema esté roto.
El formato sigue al uso. Una descarga gratuita de Excel con plantilla de casos de prueba es el formato de trabajo más común y se adapta bien a la tabla de casos. Un archivo Word con plantilla de caso de prueba se adapta a planes de prueba y estrategias, que son prosa. Un ejemplo de documento de prueba en PDF es lo que se adjunta a un registro de lanzamiento como evidencia.
Los documentos de un conjunto de pruebas
Seis documentos, cada uno responde a una pregunta distinta, y vale la pena saber cuáles necesitas realmente antes de adoptar cualquier cosa.
Estrategia de pruebas. Cómo prueba esta organización, en general. Se escribe una vez, se revisa rara vez y se aplica en proyectos.
Plan de pruebas. Qué se va a probar en este lanzamiento o proyecto, en qué entornos, por quién, con qué criterios de entrada y salida y con qué calendario.
Casos de prueba. Las comprobaciones individuales. Pasos y, crucialmente, resultados esperados.
Scripts de prueba. El equivalente automatizado, donde un caso se ha codificado en lugar de ejecutarse por una persona.
Datos de prueba. Qué datos usan los casos, que es documentación por derecho propio y que con frecuencia es la parte menos controlada de todo el conjunto.
Resultados de pruebas e informes de defectos. Qué ocurrió y qué se reportó. Esto es lo que normalmente termina siendo un ejemplo de documento de caso de prueba en PDF cuando encuentras uno publicado, ya que los resultados son la parte que las organizaciones conservan.
Cualquier pack de plantillas de documentación de pruebas debería cubrir los seis, y la mayoría cubren dos. La mayoría de las organizaciones tienen el tercero y el sexto y se improvisa el resto. Eso es sostenible. Lo que no es sostenible es que el tercero se escriba mal, porque todo lo que viene después depende de ello.
Cómo personalizar esta plantilla en Trupeer
Paso 1: Abre la sección de plantillas
Ve a la sección de Plantillas desde la navegación principal.
Paso 2: Selecciona y abre una plantilla
Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.
Paso 3: Amplía la vista de la plantilla
Si es necesario, amplía la vista de la plantilla para ver el diseño completo y los detalles con claridad.
Paso 4: Edita la plantilla
Haz clic en Editar para empezar a modificar la plantilla seleccionada.
Dentro del editor, puedes:
Añadir nuevas secciones
Definir o actualizar reglas de formato
Añadir un logotipo y ajustar su posición y la configuración relacionada
Paso 5: Guarda tu plantilla personalizada
Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.
Paso 6: Previsualiza y ajusta la plantilla
Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.
Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurando que la plantilla aparezca exactamente como la quieres.
Con plantillas de documentación de pruebas puedes:
Ahorra horas en la redacción: Omite la página en blanco con estructuras usadas por equipos de QA experimentados.
Mejora la cobertura de pruebas: Las secciones integradas garantizan que no se pase por alto nada importante.
Mantén la coherencia con tu marca: Aplica tu logotipo, fuentes y colores usando el kit de marca de Trupeer.
Estandariza en todos los productos: Usa las mismas plantillas para cada lanzamiento y equipo.
Listo para auditorías: Alineado con IEEE 829, ISO 29119 y estándares similares.
Llega a equipos globales: Traduce la documentación de pruebas a 65+ idiomas con un solo clic.
El resultado esperado es el caso de prueba
Lee cualquier conjunto de pruebas y fíjate en dónde están las palabras.
Los pasos serán detallados. Abre la aplicación. Ve a la pantalla de pagos. Selecciona la transacción. Haz clic en Reembolso. Introduce el importe. Confirma. Siete instrucciones precisas, cada una sin ambigüedad.
Luego mira el resultado esperado. Dirá algo como: el reembolso se procesa correctamente.
Esa línea es toda la prueba. Todo lo que está arriba es configuración. Y es la línea que recibió menos reflexión, porque escribir pasos precisos es fácil y definir qué significa “correcto” es difícil.
La consecuencia es que un tester sigue siete instrucciones exactas, ve algo que parece éxito y marca “aprobado”. No han hecho nada mal. El documento preguntaba si el reembolso se procesó correctamente; vieron un mensaje de éxito y así fue.
Lo que el documento nunca preguntó fue si se creó exactamente un reembolso, si el libro contable se movió exactamente por el importe correcto o si algo de lo que ocurre después recibió un duplicado.
Un caso de prueba cuyo resultado esperado puede cumplirse con una lectura optimista de la interfaz es un caso de prueba que pasará siempre que el tester tenga prisa, algo que ocurre la mayor parte del tiempo cerca de un lanzamiento.
Escribir un resultado esperado que pueda fallar
Tres propiedades, y son fáciles de comprobar en un conjunto existente.
Indica un estado, no una impresión. No “el registro se guarda correctamente”, sino “el registro aparece en la lista con estado Activo y una marca de tiempo de modificación dentro del último minuto”.
Se puede comprobar fuera de lo que ejecutó la acción. Esta es la propiedad que detecta los defectos costosos. Si la acción ocurrió en la interfaz de usuario, el resultado esperado más sólido es uno verificado en otro lugar: en la base de datos, en un informe, en el sistema posterior, en un extracto. Las interfaces son buenas para informar del éxito y malas para informar de lo que realmente ocurrió debajo.
Podría fallar sin que el sistema parezca roto. Si la única forma de que falle la prueba es un error visible, la prueba solo detecta errores que se anuncian. La incorrección silenciosa es lo que los casos de prueba existen para detectar y lo que los resultados esperados vagos suelen pasar por alto de forma fiable.
Una auditoría práctica, que tarda una tarde en un conjunto de unos cientos. Lee solo los resultados esperados, ignorando los pasos. Cuenta cuántos podrían cumplirse mirando únicamente la pantalla y cuántos usan palabras como correctamente, exitosamente, como se esperaba o sin error, que en realidad no son resultados. En la mayoría de los conjuntos, ambos recuentos son altos.
Qué debe contener una plantilla de caso de prueba
Nueve campos. La plantilla no es el problema y la guía contra dos de estos campos es.
Campo | Qué hace |
|---|---|
Identificador | Estable, nunca se reutiliza, para que los casos puedan referenciarse en informes de defectos y debates sobre cobertura. |
Título | Qué se está probando, en una frase que alguien podría buscar. |
Prioridad | Porque nadie ejecuta nunca el conjunto completo, y si no eliges tú, lo hará quien esté bajo presión. |
Precondiciones | Estado, datos y acceso necesarios antes del primer paso. |
Pasos | Una acción cada uno. La parte fácil. |
Resultado esperado | Qué debe ser cierto, dónde comprobarlo y expresado de forma que pueda fallar. Toda la prueba. |
Resultado real | Qué se observó, completado durante la ejecución, no una marca. |
Estado | Aprobado, fallido, bloqueado, no ejecutado. Bloqueado y no ejecutado son diferentes y colapsarlos oculta brechas de cobertura. |
Evidencia | Captura de pantalla, salida de consulta, referencia. Lo que muestre el resultado real en lugar de afirmarlo. |
La diferencia entre bloqueado y no ejecutado importa más de lo que parece. Un conjunto que informa un 90% de aprobados puede haber ejecutado solo el 60% de sus casos, y la diferencia es invisible si todo lo que no pasó se registra de la misma manera.
Plantillas de documentación de pruebas gratuitas: la estructura para copiar
Rellenas con un ejemplo real en lugar de marcadores de posición. El sistema es una plataforma de procesamiento de pagos.
Copia desde aquí.
Plan de pruebas, en esquema. Alcance: procesamiento de reembolsos para el lanzamiento 4.9. Dentro del alcance: reembolsos completos, reembolsos parciales, reembolsos contra transacciones liquidadas y no liquidadas. Fuera del alcance: contracargos, que no cambian. Entornos: staging con volúmenes de datos similares a producción. Criterios de entrada: despliegue realizado, prueba smoke superada, datos de prueba cargados. Criterios de salida: todos los casos de prioridad uno aprobados, sin defectos abiertos de prioridad uno o dos, conciliación del libro contable limpia en toda la ejecución.
Caso de prueba.
Identificador: TC-118. Título: El reembolso completo contra una transacción liquidada crea exactamente una entrada de reembolso.
Prioridad: Uno.
Precondiciones: Existe la cuenta de comerciante M-4471 con una transacción liquidada T-88210 de 240.00. El saldo del libro contable para M-4471 se registró antes de empezar. El tester tiene permisos de reembolso.
Pasos.
Abre la pantalla de pagos y busca T-88210.
Selecciona la transacción y elige Reembolso.
Introduce 240.00 y confirma.
Resultado esperado. Cuatro condiciones, todas las cuales deben cumplirse.
Existe un único registro de reembolso contra T-88210, y solo uno. Comprobado en la tabla de reembolsos, no en la interfaz.
El saldo del libro contable del comerciante para M-4471 ha disminuido exactamente 240.00 desde el valor inicial registrado. Comprobado en el informe del libro contable.
El extracto del comerciante para el periodo muestra una única línea de reembolso de 240.00.
El estado de la transacción muestra Reembolsado en la interfaz.
Nota: la comprobación en la interfaz es la última y es la más débil de las cuatro. Se incluye porque los usuarios la ven, no porque verifique nada.
Resultado real: registrado durante la ejecución, con las cifras del libro contable observadas en lugar de asumidas.
Estado: aprobado, fallido, bloqueado o no ejecutado.
Evidencia: salida de consulta de la tabla de reembolsos y una copia de la línea del informe del libro contable.
Informe de defecto, si falla. Identificador del caso, qué se esperaba, qué se observó, entorno, versión del build, datos usados, pasos para reproducir, severidad. El campo de datos usados es el que más a menudo se omite y el que más a menudo impide la reproducción.
Copia hasta aquí.
Ejemplo de documentación de pruebas: trescientos treinta y ocho aprobados
Brayford Payments procesa pagos con tarjeta para pequeños comercios y emplea a unas doscientas personas. Publicó un flujo de reembolso revisado.
El módulo de pagos tenía trescientos cuarenta casos de prueba. Las pruebas de aceptación de usuario ejecutaron el conjunto completo. Trescientos treinta y ocho aprobaron. Dos fallaron, se corrigieron y se volvieron a probar.
En producción, los reembolsos por encima de cierto valor se aplicaron dos veces bajo una condición de temporización concreta. Se ejecutó durante nueve días antes de que alguien lo notara, generando unos catorce cientos de reembolsos duplicados por valor de cuatrocientos doce mil libras. Recuperar dinero ya pagado a los comercios fue lento y complicado, y aproximadamente el 60% se devolvió.
El caso TC-118 cubría los reembolsos. Tenía siete pasos detallados y un resultado esperado que decía: el reembolso se procesa correctamente.
El tester siguió los siete pasos, vio un mensaje de confirmación y un estado de Reembolsado, y registró un aprobado. Esa fue una aplicación correcta del documento que tenían delante.
Nadie miró el libro contable. Nada en el caso les pedía hacerlo. Un único reembolso y un doble reembolso se ven idénticos en la pantalla de confirmación, que es exactamente por eso que la comprobación tenía que ocurrir en otro lugar.
La auditoría posterior leyó los trescientos cuarenta resultados esperados, ignorando los pasos.
Doscientos once pudieron cumplirse observando solo la interfaz de usuario. Cuarenta y siete no contenían ninguna afirmación comprobable, usando frases como funciona como se esperaba, se comporta correctamente o se completa sin error.
La solución fue tres semanas de reescritura, no de nuevas pruebas. Cada resultado esperado tenía que indicar un estado, decir dónde se comprobaba y poder fallar sin un error visible. Cuando la comprobación natural estaba fuera de la interfaz, ahí era donde se hacía. Algunos casos se fusionaron y el conjunto se redujo a doscientos noventa.
Dos lanzamientos después, los defectos encontrados durante las pruebas de aceptación de usuario habían pasado de un promedio de cuatro por lanzamiento a diecinueve.
Ese aumento es el resultado. Los defectos en producción durante los seis meses siguientes pasaron de once a dos.
El conjunto no era demasiado pequeño. Estaba haciendo trescientos cuarenta preguntas que el sistema podía responder de forma optimista.
Cómo escribir casos de prueba en seis pasos
Escribe el resultado esperado antes que los pasos. Invierte el orden habitual y te obliga a decidir qué significa “correcto” antes de describir cómo llegar a ello. Los pasos escritos después son más cortos y más relevantes.
Indica dónde se comprueba el resultado. Interfaz, base de datos, informe, sistema posterior. Nombrar la ubicación es lo que hace que un resultado sea verificable por otra persona.
Pregunta cómo podría pasar estando mal. Si puedes responder, el resultado esperado necesita otra condición.
Luego escribe los pasos, una acción cada uno. Son la parte fácil y deberían llevar el menor tiempo.
Registra las precondiciones incluyendo los datos. La mayoría de los fallos para reproducir un defecto se deben a datos distintos, más que a pasos distintos.
Prioriza con honestidad. Nadie ejecuta el conjunto completo antes de un lanzamiento. Decidir con antelación qué casos importan es mejor que decidir a las nueve de la noche el día anterior.
El paso uno es todo el método. Los pasos dos y tres son lo que detecta los defectos que llegan a producción.
Casos de prueba frente a escenarios de prueba
Ambos se usan indistintamente y la diferencia es el nivel.
Un escenario de prueba es qué probar, descrito a un nivel que cualquiera pueda entender. Verifica que los reembolsos funcionen correctamente para transacciones liquidadas. Es una afirmación de cobertura.
Un caso de prueba es cómo probarlo, con datos específicos, pasos específicos y un resultado esperado específico. Un escenario suele producir varios casos.
La disciplina útil es escribir escenarios primero, acordar la cobertura con personas que entienden el negocio y, después, escribir casos debajo. Hacerlo al revés produce un conjunto que cubre lo que la persona que lo escribió se le ocurrió.
Un escenario que produce solo un caso suele ser un escenario que no se ha pensado correctamente. Los reembolsos para transacciones liquidadas deberían producir casos para el importe total, un importe parcial, un importe que supere el original, un segundo intento de reembolso sobre la misma transacción y un reembolso sobre una transacción que ya había sido reembolsada. Cuatro de esos cinco son donde viven los defectos.
Estrategia de pruebas, plan de pruebas y plan de QA
Tres documentos por encima de los casos de prueba, y las distinciones tienen un peso práctico.
Una estrategia de pruebas es organizativa y de larga duración. Cómo probamos, qué tipos de pruebas usamos, cuáles son nuestros estándares. Se aplica en proyectos y se revisa rara vez.
Un plan de pruebas es específico para un lanzamiento o proyecto. Alcance, entornos, criterios de entrada y salida, calendario, recursos, riesgos. Una descarga gratuita de Excel con plantilla de plan de pruebas te dará un calendario y una matriz, y las secciones en prosa pertenecen en un documento.
Un plan de QA es más amplio que ambos, porque el aseguramiento de la calidad incluye todo lo que se hace para prevenir defectos en lugar de encontrarlos: revisión de requisitos, definición de “hecho”, estándares de revisión de código, paridad de entornos. La plantilla de plan de QA cubre esa distinción, y aquí importa porque un documento titulado plan de QA que contiene solo fases de prueba se ha convertido silenciosamente en un plan de pruebas.
La prueba práctica es el momento. Las actividades que ocurren antes de que se termine el trabajo son aseguramiento. Las actividades que ocurren después son control, y las pruebas son control.
Qué no pueden arreglar las plantillas gratuitas de documentación de pruebas
Requisitos sobre los que nadie se puso de acuerdo. Un caso de prueba verifica el comportamiento frente a una expectativa, y si esa expectativa nunca se cerró, los testers escriben casos basados en su propia suposición.
Un conjunto demasiado grande para ejecutarlo. Cada organización llega al punto en el que el conjunto completo de regresión no cabe en la ventana. Priorizar deliberadamente gana a priorizar bajo presión, y ninguna descarga gratuita de Excel con plantilla de casos de prueba lo hará por ti.
Un resultado esperado vago. Ninguna plantilla de caso de prueba: descarga gratuita y ninguna plantilla simple de Excel para casos de prueba escribirá eso por ti, y es el único campo que decide si el caso funciona.
Datos de prueba que no representan producción. El defecto de Brayford requería una condición de temporización concreta y un volumen de datos realista. Ninguno existía en el entorno de pruebas, y ninguna plantilla aborda eso.
Testers sin autoridad para bloquear. Los criterios de salida que puede omitir quien quiera enviar son criterios, no criterios.
Muestra la prueba en lugar de describirla
Dos problemas en esta área son el mismo problema, y ambos tratan sobre la evidencia.
La evidencia de prueba normalmente es una marca en una columna de estado. Alguien ejecutó el caso y dice que pasó. Si más tarde aparece un defecto en esa área, no hay forma de establecer qué se observó realmente, así que no se puede responder a la pregunta de si el caso se ejecutó correctamente y normalmente se convierte en un debate.
El segundo problema es que un tester nuevo que se incorpora aprende qué significa comprobar correctamente observando a alguien, y si nadie tiene tiempo, lo aprende de los documentos, que es de donde proviene la lectura optimista.
Trupeer AI aborda ambos. Registrar una ejecución de pruebas genera un recorrido en texto con capturas de pantalla ya capturadas y colocadas, junto con el vídeo, en tu propia marca. Lo que se observó realmente en cada paso se captura en lugar de afirmarse, que es la evidencia que necesita un registro de lanzamiento y el material del que aprende un tester nuevo.
Regístralo. Ponle marca. Tradúcelo. Hazlo con Trupeer.
Siguen dos puntos. Registrar a un tester experimentado ejecutando un caso complejo muestra las comprobaciones que realiza fuera de la interfaz, que es exactamente el hábito que los casos escritos no logran transmitir. Y cuando las pruebas se realizan en varios sitios o por un equipo subcontratado, la misma grabación define el mismo estándar de comprobación en lugar de dejarlo a la interpretación.
El material está en tu base de conocimiento y también sirve como formación para testers nuevos. Si el lanzamiento puede enviarse o no es una pregunta aparte, cubierta en la plantilla de requisitos de lanzamiento. La consistencia entre tus documentos es cuestión de configurar el kit de marca una vez, y la configuración se cubre en la guía de configuración de la plantilla de documento.
Preguntas frecuentes
¿Hay una descarga gratuita de Excel con plantilla de casos de prueba?
Excel es el formato de trabajo estándar para los casos de prueba y se adapta bien a ellos, porque un conjunto es una tabla que filtras por módulo, prioridad y estado. Una descarga gratuita de Excel con plantilla de casos de prueba te dará las columnas estándar y es realmente un buen punto de partida.
Dos adiciones merecen la pena. Una columna para registrar dónde se comprueba el resultado esperado, es decir, interfaz, base de datos, informe o sistema posterior. Y valores de estado separados para bloqueado y no ejecutado, ya que colapsarlos oculta cuánto del conjunto se ejecutó realmente.
¿Hay una versión simple de Excel para la plantilla de caso de prueba?
Sí, y lo simple suele ser lo correcto. Un diseño simple de Excel con plantilla de caso de prueba con identificador, título, prioridad, precondiciones, pasos, resultado esperado, resultado real y estado cubre casi todo.
Evita añadir columnas. Las plantillas de casos de prueba acumulan campos que parecen útiles en el momento del diseño y se dejan en blanco en la práctica, y un conjunto con ocho columnas rellenadas es más útil que uno con veinte de las cuales doce están vacías.
¿Hay una versión de Word para la plantilla de caso de prueba?
Word se adapta a los documentos que rodean a los casos, no a los casos en sí. Un archivo Word con plantilla de caso de prueba funciona para un plan de pruebas, una estrategia de pruebas o un informe resumen, los cuales son prosa.
Para los casos en sí, un documento no encaja bien. No puedes filtrarlo, no puedes ordenarlo por prioridad y actualizar el estado en doscientos casos en una tabla de Word durante una ejecución de pruebas es lo bastante lento como para que la gente deje de hacerlo con precisión.
¿Hay una plantilla de caso de prueba: vale la pena una descarga gratuita?
Las columnas se han mantenido estables durante décadas, así que una plantilla de caso de prueba: una descarga gratuita te ahorra muy poco y cada versión publicada es, en general, la misma.
Juzga cualquiera de ellas con una sola pregunta. ¿La columna de resultado esperado tiene alguna guía adjunta o es solo una celda en blanco? La celda en blanco es donde la mayoría de los conjuntos de pruebas se equivocan, y ninguna plantilla lo resuelve, pero una plantilla que te pide dónde se comprueba el resultado mejorará lo que se escribe en ella.
¿Hay una descarga gratuita de Excel con plantilla de plan de pruebas?
Excel se adapta al calendario, la matriz de cobertura y el plan de recursos dentro de un plan de pruebas. Una descarga gratuita de Excel con plantilla de plan de pruebas normalmente te dará eso.
La mitad narrativa pertenece en un documento: alcance, criterios de entrada y salida, entornos, supuestos y riesgos. Eso se lee y se negocia, y negociar en celdas de una hoja de cálculo sale mal. Mantén ambos y referencia uno desde el otro.
¿Dónde puedo encontrar un ejemplo de PDF de documento de prueba?
Los registros de contratación del sector público, los proyectos universitarios y algunos organismos de estándares publican documentación real de pruebas, y un ejemplo de PDF de documento de prueba de una de esas fuentes es más instructivo que una plantilla comercial porque se produjo bajo restricciones reales.
Lee un ejemplo de PDF de documento de caso de prueba por sus resultados esperados, no por su estructura. La estructura se puede copiar desde cualquier sitio. Cómo un equipo real redactó cómo se ve “correcto” y si sus comprobaciones estaban fuera de la interfaz es la parte que merece aprenderse.
¿Dónde puedo encontrar un ejemplo de PDF de documento de caso de prueba?
Se aplican las mismas fuentes, y las industrias reguladas son las más ricas, ya que allí la evidencia de prueba tiene que sobrevivir a auditorías y tiende a estar escrita con más precisión como resultado.
Al leer un ejemplo de PDF de documento de caso de prueba, mira si la columna de resultado real contiene observaciones o marcas. Las marcas te dicen que el conjunto se ejecutó. Las observaciones te dicen qué se vio y solo la segunda es evidencia.
¿Hay un conjunto de plantillas de documentación de pruebas de software?
Sí, y el conjunto son seis documentos: estrategia, plan, casos, scripts, datos y resultados con informes de defectos. Un pack de plantillas de documentación de pruebas de software normalmente cubre el plan y los casos y deja el resto.
Los datos de prueba son lo que más a menudo falta y lo que más a menudo impide que un defecto se reproduzca. Documentar contra qué datos se ejecuta el conjunto y cómo se actualizan vale tanto como otros cincuenta casos de prueba.
