Reporte de Pruebas
Reporte de pruebas
Un
reporte de pruebas es un documento formal que resume los resultados de todos
los esfuerzos de prueba para un ciclo de prueba particular de un proyecto u módulo
o un sub-módulo. Generalmente, los conductores de prueba o los encargados de la
prueba preparan este documento al final del ciclo de prueba. Algunos gerentes
de prueba lo preparan al final del proyecto. Además, según Software Testing
Help, define un reporte como “Informe de
resumen de prueba es un producto importante que se prepara al final de un
proyecto de prueba, o más bien después de completar la prueba. El principal
objetivo de este documento es explicar varios detalles y actividades sobre las
pruebas realizadas para el proyecto, a los respectivos actores como la Alta
Dirección, el Cliente, etc.”
Estas
pruebas de documentación incluyen los planes, resultados y pruebas de un
sistema o componente del sistema. Incluye especificaciones de casos de prueba,
planes de prueba, procedimientos de prueba, informes de prueba y registros de
prueba. Se trata de la comprobación de todos los documentos que establecen,
definen, explican y notifican o validan los requisitos, los procedimientos
seguidos y los resultados. Estas pruebas incluyen verificar la ortografía y la
gramática para revisar cualquier ambigüedad o inconsistencia entre qué
funcionalidad realiza y qué se supone que debe hacer. Existen cuatro áreas
clave para probar un documento estas incluyen: instrucciones, ejemplos, mensajes y muestras. Se necesitarán
instrucciones para ejecutar paso a paso los escenarios de prueba para buscar
errores o su omisión. Se pueden proporcionar otros ejemplos para elaborar los
componentes GUI, sintaxis, comandos e interfaces para mostrar salidas
ejecutadas o puntos de pin. Las incoherencias también necesitaban ser atendidas
con errores, ya que pueden confundir a los usuarios y estas ambigüedades
causarán mucho daño si el usuario del sistema será un usuario novato. Los ejemplos
serán necesarios en caso de cualquier problema que ocurra al usuario, en
particular los usuarios principiantes que los usuarios principiantes
comprobarán la documentación para cualquier confusión.
La
documentación para las pruebas de software ayuda a estimar el esfuerzo de
prueba requerido, la cobertura de la prueba, el rastreo de los requisitos, etc.
Esta sección describe algunos de los artefactos documentados de uso común
relacionados con pruebas de software como:
- Plan de prueba.
- Escenario de prueba.
- Caso de prueba.
- Matriz de trazabilidad.
Plan de prueba:
Un plan de prueba describe la estrategia que se utilizará
para probar una aplicación, los recursos que se utilizarán, el entorno de
prueba en el que se realizarán las pruebas y las limitaciones de las pruebas y
el calendario de las actividades de prueba. Normalmente, el jefe del equipo de garantía de calidad será responsable de escribir un plan de prueba. Un plan de prueba incluye lo siguiente:
- Introducción al documento del Plan de Prueba.
- Suposiciones durante la prueba de la aplicación.
- Lista de casos de prueba incluidos en la prueba de la aplicación.
- Lista de características a probar.
- ¿Qué tipo de enfoque utilizar al probar el software.
- Lista de entregas que deben ser probadas.
- Los recursos asignados para probar la aplicación.
- Cualquier riesgo involucrado durante el proceso de prueba.
- Un calendario de tareas e hitos a lograr.
Escenario de prueba:
Los términos "escenario de prueba" y "casos
de prueba" se usan indistintamente, sin embargo, un escenario de prueba
tiene varias etapas, mientras que un caso de prueba tiene un solo paso. Desde
esta perspectiva, los escenarios de prueba son casos de prueba, pero incluyen
varios casos de prueba y la secuencia en la que deben ejecutarse. Aparte de
esto, cada prueba depende de la salida de la prueba anterior.
Caso de prueba:
Los casos de prueba implican un conjunto de pasos,
condiciones e insumos que se pueden utilizar durante la realización de las
tareas de prueba. El objetivo principal de esta actividad es asegurar que un
software pase o no en términos de funcionalidad y otros aspectos. Hay muchos
tipos de casos de prueba tales como funcional, negativo, error, casos de prueba
lógica, casos de prueba física, casos de prueba de UI, etc. Además, los casos
de prueba se escriben para realizar un seguimiento de la cobertura de pruebas
de un software. Generalmente, no hay plantillas formales que se puedan utilizar
durante la escritura del caso de prueba. Sin embargo, los siguientes
componentes están siempre disponibles e incluidos en cada caso de prueba:
- Identificación del caso de prueba.
- Módulo de producto.
- Versión del producto.
- Revisión histórica.
- Propósito.
- Suposiciones.
- Condiciones previas.
- Pasos.
- Gastos esperados.
- Resultado real.
- Post condiciones.
Muchos casos de prueba pueden derivarse de un único
escenario de prueba. Además, a veces se escriben varios casos de prueba para un
solo software que se conocen colectivamente como suites de prueba.
Matriz de trazabilidad:
Matriz de Trazabilidad (también conocida como Matriz de
Trazabilidad de Requisitos - RTM) es una tabla que se utiliza para rastrear los
requisitos durante el Ciclo de Vida de Desarrollo de Software. Puede usarse
para el rastreo directo (es decir, desde Requisitos para diseño o codificación)
o hacia atrás (es decir, desde la codificación a los requisitos). Hay muchas
plantillas definidas por el usuario para RTM. Cada requisito en el documento
RTM está vinculado con su caso de prueba asociado de modo que las pruebas se
pueden hacer según los requisitos mencionados. Además, Bug ID también está
incluido y enlazado con sus requisitos asociados y caso de prueba. Los
objetivos principales de esta matriz son:
- Asegúrese de que el software se ha desarrollado según los requisitos mencionados.
- Ayuda a encontrar la raíz de cualquier error.
- Ayuda a rastrear los documentos desarrollados durante las diferentes fases del SDLC (“Systems Development Life Cycle”, también conocido como “System Design Life Cycle”).
¿Qué es la prueba?
La prueba es el proceso de evaluar un sistema o sus
componentes con la intención de determinar si satisface o no los requisitos
especificados. En palabras simples, la prueba está ejecutando un sistema para
identificar cualquier laguna, error o requisito faltante en contra de los
requerimientos reales. De acuerdo con la norma ANSI / IEEE 1059, Testing se
puede definir como: - “Un proceso de
análisis de un elemento de software para detectar las diferencias entre las
condiciones existentes y las requeridas (defectos / errores / errores) y
evaluar las características del elemento de software.”
¿Quién hace la prueba?
Depende del proceso y de las partes asociadas del (de los)
proyecto (s). En la industria de TI, las grandes empresas tienen un equipo con
responsabilidades para evaluar el software desarrollado en el contexto de los
requisitos dados. Además, los desarrolladores también llevan a cabo las pruebas
que se denomina Pruebas unitarias. En la mayoría de los casos, los siguientes
profesionales están involucrados en probar un sistema dentro de sus respectivas
capacidades:
- Probador de software.
- Desarrollador de software.
- Jefe de Proyecto / Gerente.
- Usuario final.
Diferentes empresas tienen diferentes designaciones para las
personas que prueban el software sobre la base de su experiencia y
conocimiento, tales como Software Tester, Software Quality Assurance Engineer,
QA Analyst, etc.
¿Cuándo comenzar la prueba?
Un comienzo temprano de la prueba reduce el costo y el
tiempo para volver a trabajar y producir software libre de errores que se
entrega al cliente. Sin embargo, en el ciclo de vida de desarrollo de software
(SDLC), las pruebas se pueden iniciar desde la fase de recopilación de requisitos
y continuar hasta el despliegue del software. También depende del modelo de
desarrollo que se está utilizando. La prueba se realiza en diferentes formas en
cada fase de SDLC:
- Durante la fase de recopilación de requisitos, el análisis y la verificación de los requisitos también se consideran como pruebas.
- La revisión del diseño en la fase de diseño con la intención de mejorar el diseño también se considera como una prueba.
- Las pruebas realizadas por un desarrollador al finalizar el código también se clasifican como pruebas.
¿Cuándo dejar de probar?
Es difícil determinar cuándo parar las pruebas, ya que la
prueba es un proceso interminable y nadie puede afirmar que un software es
probado al 100%. Los siguientes aspectos deben ser considerados para detener el
proceso de prueba:
- Plazos de prueba.
- Finalización de la ejecución del caso de prueba.
- Completar la cobertura funcional y de código hasta cierto punto.
- La tasa de errores cae por debajo de un cierto nivel y no se identifican errores de alta prioridad.
- Decisión de gestión.
¿Qué contiene un informe de resumen de prueba contiene?
Una plantilla de Informe de Prueba típica contendrá la
siguiente información, sin embargo, según el formato y la práctica de cada
empresa, el contenido puede variar. También he proporcionado ejemplos reales
para una mejor comprensión. Al final de este artículo, puede descargar un
ejemplo de informe de resumen de prueba.
1. Propósito del documento: Breve descripción del objetivo de la preparación del
documento.
2. Descripción general de la aplicación: Breve descripción de la aplicación probada.
3. Ámbito de prueba:
3.1 En Alcance: Pruebas funcionales para los siguientes módulos
están en el ámbito de la prueba.
3.2 Fuera de alcance: No se realizaron pruebas de rendimiento
para esta aplicación.
3.3 Artículos no probados: Verificación de la conectividad con
el sistema de terceros, Esto se puede verificar durante UAT (User Acceptance
Testing) donde la conectividad está disponible o se puede establecer.
Esta sección explica las funciones / módulos en el alcance y
fuera del alcance para la prueba; Cualquier elemento que no se pruebe debido a
limitaciones, dependencias, restricciones.
4. Métricas: Las métricas ayudarán a entender los resultados de la
ejecución de la prueba, el estado de los casos de prueba y defectos, etc. Las
métricas requeridas se pueden agregar según sea necesario. Gráficos / gráficos
se pueden adjuntar para una mejor representación visual.
5. Tipos de pruebas realizadas:
5.1 Pruebas de humo: Esta prueba se realizó cada vez que se
recibe una compilación (desplegada en el entorno de prueba) para probar para
asegurarse de que la funcionalidad principal está funcionando bien, se puede
aceptar la compilación y se puede iniciar la prueba.
5.2 Pruebas de integración del sistema:
- Esta es la Prueba realizada en la Aplicación bajo prueba, para verificar que la aplicación entera funciona según los requisitos.
- Los escenarios de negocio críticos se probaron para asegurarse de que la funcionalidad importante en la aplicación funciona como se pretende sin errores.
5.3 Prueba de Regresión:
- Se realizaron pruebas de regresión cada vez que se implementa una nueva compilación para pruebas que contiene correcciones de defectos y nuevas mejoras, si las hubiera.
- La prueba de regresión se está realizando en toda la aplicación y no sólo en la nueva funcionalidad y correcciones de defectos.
- Esta prueba garantiza que la funcionalidad existente funciona bien después de la corrección de defectos y se añaden nuevas mejoras a la aplicación existente.
- Los casos de prueba para la nueva funcionalidad se añaden a los casos de prueba existentes y se ejecutan.
6. Ambiente de prueba y herramientas: Proporcione detalles sobre el entorno de prueba en el que se
realiza la prueba. Servidor, Base de datos, URL de la aplicación, etc. Si se
utilizaron Herramientas como Quality Center (ahora HP ALM) para registrar
defectos.
7. Lecciones aprendidas: Esta sección se utiliza para describir los problemas
críticos enfrentados y sus soluciones (cómo se resolvieron durante la prueba).
Las lecciones aprendidas ayudarán a tomar decisiones proactivas durante la
próxima prueba, evitando estos errores o encontrando una solución adecuada.
8. Recomendaciones: Cualquier solución o sugerencias pueden mencionarse aquí.
9. Mejores Prácticas: Habrá muchas actividades realizadas por el equipo de pruebas
durante el proyecto. Algunos de ellos podrían haber ahorrado tiempo, algunos
han demostrado ser una buena y eficiente manera de trabajar, etc. Estos pueden
ser documentados como un 'Valor Agregado' para mostrar el caso a los
Stakeholders.
10. Criterios de Salida: Criterios de salida se define como una finalización de la
prueba cumpliendo ciertas condiciones, como Todos los casos de prueba
planificados se ejecutan; Todos los defectos críticos están cerrados, etc.
11.Conclusión / Cerrar sesión: Esta sección indicará si el equipo de pruebas está de
acuerdo y da una señal verde para la aplicación a "Go Live" o no, una
vez que se cumplieron los criterios de salida. Si la aplicación no cumple con
los criterios de salida, entonces se puede mencionar como - "La aplicación
no se sugiere a 'Go Live'. Se quedará con la decisión de la alta dirección y el
cliente y otras partes interesadas involucradas para tomar la llamada sobre si
la aplicación puede 'Go Live' o no.
12. Definiciones, Siglas y Abreviaturas: Esta sección menciona los significados de los términos
abreviados usados en este documento y cualquier otra nueva definición.
Conclusión
Las pruebas de software son
documentos que son muy importantes, estos mismos siempre juegan un papel
importante en la fase de desarrollo y pruebas del proyecto. Por lo tanto, siempre
mantener las cosas documentadas de la mejor manera, siempre que sea posible
realizar este tipo de documentación. No confiar en la comunicación verbal es
algo que se tiene que tener en cuenta todo el tiempo, las casa habladas son
solo eso, cosas habladas, así que, a la hora de la comunicación, se tiene
siempre que tomar nota de todos los detalles y hacer constar que lo conversado
por las partes es correcto. También algo interesante sobre la importancia es
que debemos estar siempre en el lado seguro, no hay que desconfiar acerca de lo
que se está haciendo y como se está haciendo, ya que si tanto el trabajo como
los reportes que se están realizando cumplen con todas los requerimientos, la
documentación no sólo ahorrará, sino también ayudara a la organización(es) a
largo plazo a ahorrar miles de dólares en formación y sobre todo; en la
fijación de problemas causados debido a la falta de desarrollo y pruebas de
documentos. Por lo tanto, hay que tener algo muy claro lo cual es que no se
tienen que documentar sólo para evitar problemas en los cuales se apunte a su
persona.
Además, tenemos que tener en
cuenta siempre que las fallas de software pueden ocurrir en cualquier momento,
estas pueden ocasionar perdidas económicas que van a afectar el desarrollo del
proyecto, estas pérdidas pueden ser de 100 a 1000 veces más costosas de
encontrar y reparar después de la implementación del proyecto. Por lo tanto,
debemos tener presenta los reportes de pruebas, cada caso de prueba debe
definir el resultado de la salida esperada, de lo contrario se detectará una
anomalía, y es aquí donde se da la relevancia de los reportes.
Referencias Bibliográficas
NA. (17 de abril de 2017). Software Testing Help.
Obtenido de A Simple 12 Steps Guide to Write an Effective Test Summary Report:
http://www.softwaretestinghelp.com/test-summary-report-template-download-sample/
NA. (17 de abril de
2017). Software Testing Help. Obtenido de Why Documentation is
Important in Software Testing:
http://www.softwaretestinghelp.com/why-documentation-is-important-in-software-testing/
NA. (s.f.). tutorialspoint.
Obtenido de Software Testing - Quick Guide: https://www.tutorialspoint.com/software_testing/software_testing_quick_guide.htm
Software Testing Stuff. (s.f.). Obtenido de
Test Summary Report:
http://www.softwaretestingstuff.com/2013/08/test-summary-report.html
Comentarios
Publicar un comentario