Introducción
¿Es importante conocer las palabras clave y sus relaciones? Mi respuesta definitivamente es sí. ¿Cuál puede ser uno de los argumentos que te puedo compartir para fundamentar la respuesta? Conociendo el alcance del concepto e identificando con cuántos otros está relacionado te permitirá dimensionar cómo se aplica nuestra práctica profesional en determinadas situaciones pudiendo tener un panorama más claro de todas las variables que se deben o pueden manejar. Este aspecto marca la diferencia entre un tester con conocimientos teóricos del que no lo tiene, brindándole mayores herramientas para poder desempeñarse mejor en su actividad laboral.
A continuación te comparto la definición de algunas palabras clave extraidas del Glosario oficial, la respuesta de algunos de los objetivos de aprendizaje y algunas referencias de las mismas que se encuentran en el correspondiente capítulo y en otros.
Palabras Claves
Las siguientes son las palabras clave definidas en el capítulo 2 – Prueba a lo largo del ciclo de vida de desarrollo de Software del Programa de Estudios de ISTQB CTFL v3.1 (2018)
En cada uno de los capítulos del Programa de Estudios encontrarás un conjunto de palabras clave que están ligadas a los principales conceptos teóricos para poder comprender su alcance con:
– el contenido propio del capítulo;
– los contenidos previos y posteriores;
– los objetivos de aprendizaje del capítulo;
En cuanto a los objetivos de aprendizaje hay que tener en cuenta que cada uno de los mismos tiene definido un determinado nivel de conocimiento.
K1: recordar.
K2: entender.
K3: aplicar.
Listado
- análisis de impacto («impact analysis»)
- base de prueba («test basis»)
- caso de prueba («test case»)
- entorno de prueba («test environment»)
- modelo de desarrollo secuencial («sequential development model»)
- nivel de prueba («test level»)
- objetivo de prueba («test objective»)
- objeto de prueba («test object»)
- prueba alfa («alpha testing»)
- prueba beta («beta testing»)
- prueba de aceptación («acceptance testing»)
- prueba de aceptación contractual («contractual acceptance testing»)
- prueba de aceptación de usuario («user acceptance testing»)
- prueba de aceptación operativa («operational acceptance testing»)
- prueba de aceptación regulatoria («regulatory acceptance testing»)
- prueba de caja blanca («white-box testing»)
- prueba de componente («component testing»)
- prueba de confirmación («confirmation testing»)
- prueba de integración («integration testing»)
- prueba de integración de componente («component integration testing»)
- prueba de integración de sistemas («system integration testing»)
- prueba de mantenimiento («maintenance testing»)
- prueba de regresión («regression testing»)
- prueba de sistema («system testing»)
- prueba funcional («functional testing»)
- prueba no funcional («non-functional testing»)
- software comercial de distribución masiva («commercial off-the-shelf (COTS)»)
- tipo de prueba («test type»)
análisis de impacto ("impact analysis")
Definición según Glosario
Identificación de todos los productos de trabajo afectados por un cambio, incluyendo una estimación de los recursos necesarios para llevar a cabo el cambio.
Referencias dentro del Programa de Estudios:
#1
El análisis de impacto evalúa los cambios que se hicieron para el lanzamiento de un mantenimiento con el objetivo de identificar las consecuencias previstas, así como los efectos secundarios esperados y posibles de un cambio, y para identificar las áreas del sistema que se verán afectadas por el cambio. El análisis de impacto también puede ayudar a identificar el impacto de un cambio en las pruebas existentes. Los efectos secundarios y las áreas afectadas en el sistema necesitan ser probados para las regresiones, posiblemente después de haber actualizado cualquier prueba existente afectada por el cambio.
[Referencia: 2.4.2 «Análisis de Impacto para el Mantenimiento»]
#2
El análisis de impacto puede ser difícil si:
– Las especificaciones (por ejemplo, requisitos de negocio, historias de usuario, arquitectura) están desactualizadas o no existen.
– Los casos de prueba no están documentados o están desactualizados.
– No se ha mantenido la trazabilidad bidireccional entre las pruebas y la base de prueba.
– El soporte de herramientas es débil o inexistente.
– Las personas involucradas no tienen conocimientos de dominio y/o sistema.
– No se ha prestado suficiente atención a la mantenibilidad del software durante el desarrollo
[Referencia: 2.4.2 «Análisis de Impacto para el Mantenimiento»]
Relación con los Objetivos de Aprendizaje
NB-2.4.2 (K2) Describir el papel del análisis de impacto en la prueba de mantenimiento.
El análisis de impacto es una actividad importante en la prueba de mantenimiento. Su papel es evaluar los cambios que se hicieron para el lanzamiento de un mantenimiento con el objetivo de identificar las consecuencias previstas, así como los efectos secundarios esperados y posibles de un cambio, y para identificar las áreas del sistema que se verán afectadas por el cambio. El análisis de impacto también puede ayudar a identificar el impacto de un cambio en las pruebas existentes. Los efectos secundarios y las áreas afectadas en el sistema necesitan ser probados para las regresiones, posiblemente después de haber actualizado cualquier prueba existente afectada por el cambio.
base de prueba ("test basis")
Definición según Glosario
Conjunto de conocimientos utilizados como base para el análisis y diseño de una prueba.
Referencias dentro del Programa de Estudios:
#1
Algunos ejemplos de productos de trabajo que se pueden utilizar como base de prueba para la prueba de componente incluyen:
-Diseño detallado.
-Código.
-Modelo de datos.
-Especificaciones de los componentes.
2.2.1. Prueba de Componente / Bases de Prueba
#2
Algunos ejemplos de productos de trabajo que pueden utilizarse como base de prueba para la prueba de integración incluyen:
-Diseño de software y sistemas.
-Diagramas de secuencia.
-Especificaciones de interfaz y protocolos de comunicación.
-Casos de uso.
-Arquitectura a nivel de componente o de sistema.
-Flujos de trabajo.
-Definiciones de interfaces externas.
2.2.2. Prueba de Integración / Bases de Prueba
#3
Algunos ejemplos de productos de trabajo que se pueden utilizar como base de prueba para la prueba de sistema incluyen:
-Especificaciones de requisitos del sistema y del software (funcionales y no funcionales).
-Informes de análisis de riesgo.
-Casos de uso.
-Épicas e historias de usuario.
-Modelos de comportamiento del sistema.
-Diagramas de estado.
-Manuales del sistema y del usuario.
2.2.3. Prueba de Sistema / Bases de Prueba
#4
Entre los ejemplos de productos de trabajo que se pueden utilizar como base de prueba para cualquier forma de prueba de aceptación se encuentran:
-Procesos de negocio.
-Requisitos de usuario o de negocio.
-Normativas, contratos legales y estándares.
-Casos de uso.
-Requisitos de sistema.
-Documentación del sistema o del usuario.
-Procedimientos de instalación.
-Informes de análisis de riesgo.
2.2.4. Prueba de Aceptación / Bases de Prueba
#5
No se ha mantenido la trazabilidad bidireccional entre las pruebas y la base de prueba.
2.4.2. Análisis de Impacto para el Mantenimiento
Relación con los Objetivos de Aprendizaje
NB-1.4.4 (K2) Explicar el valor de mantener la trazabilidad entre la base de prueba y los productos de trabajo de la prueba.
La trazabilidad entre la base de prueba y los productos de trabajo de la prueba es importante para implementar una monitorización y control efectivos de la prueba. Permite relacionar cada elemento de la base de prueba con los diversos productos de trabajo de la prueba asociados con ese elemento, lo que ayuda a mantener la coherencia y la integridad de la información de la prueba. Además, la trazabilidad permite analizar el impacto de los cambios, hacer que la prueba pueda ser auditada, cumplir con los criterios de gobernanza de TI, mejorar la comprensión de los informes de avance de la prueba y de los informes resumen de prueba, relacionar los aspectos técnicos de la prueba con los implicados en términos que éstos puedan entender, y aportar información para evaluar la calidad de los productos, la capacidad de los procesos y el avance de los proyectos en relación con los objetivos de negocio.
Relación con otros capítulos
#1
Trazabilidad entre la base de prueba y los productos de trabajo de la prueba.
Es muy útil si la base de prueba (para cualquier nivel o tipo de prueba que se esté considerando) tiene definidos criterios de cobertura medibles.
1.4.1. El Proceso de Prueba en Contexto
#2
Durante el análisis de la prueba, se analiza la base de prueba para identificar las prestaciones que presentan capacidad de ser probadas y definir las condiciones de prueba asociadas. En otras palabras, el análisis de la prueba determina «qué probar» en términos de criterios de cobertura medibles.
1.4.2. Actividades y Tareas de Prueba / Análisis de Prueba
#3
Analizar la base de prueba correspondiente al nivel de prueba considerado
Evaluar la base de prueba y los elementos de prueba para identificar defectos de distintos tipos
Definir y priorizar las condiciones de prueba para cada prestación basándose en el análisis de la base de prueba
Captura de la trazabilidad bidireccional entre cada elemento de la base de prueba y las condiciones de prueba asociadas
1.4.2. Actividades y Tareas de Prueba / Análisis de Prueba
#4
Capturar la trazabilidad bidireccional entre la base de prueba, las condiciones de prueba, los casos de prueba y los procedimientos de prueba (
1.4.2. Actividades y Tareas de Prueba / Diseño de Prueba
#5
Verificar y actualizar la trazabilidad bidireccional entre la base de prueba, las condiciones de prueba, los casos de prueba, los procedimientos de prueba y los juegos de prueba
1.4.2. Actividades y Tareas de Prueba / Implementación de Prueba
#6
El plan de prueba incluye información sobre la base de prueba, con la que se relacionarán los demás productos de trabajo de la prueba mediante información de trazabilidad
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo de la Planificación de la Prueba
#7
Los productos de trabajo del análisis de la prueba incluyen condiciones de prueba definidas y priorizadas, cada una de las cuales es, idealmente, trazable bidireccionalmente a los elementos específicos de la base de prueba que cubre. Para la prueba exploratoria, el análisis de la prueba puede implicar la creación de contratos de prueba. El análisis de la prueba también puede dar lugar al descubrimiento y notificación de defectos en la base de prueba.
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo del Análisis de la Prueba
#8
Idealmente, una vez finalizada la implementación de la prueba, el logro de los criterios de cobertura establecidos en el plan de prueba puede demostrarse mediante la trazabilidad bidireccional entre los procedimientos de prueba y los elementos específicos de la base de prueba, a través de los casos de prueba y las condiciones de prueba.
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo de la Implementación de la Prueba
caso de prueba ("test case")
Definición según Glosario
Conjunto de precondiciones, entradas, acciones (cuando proceda), resultados esperados y postcondiciones, desarrollado conforme a las condiciones de prueba.
Referencias dentro del Programa de Estudios:
#1
Bases de prueba, referenciadas para generar casos de prueba.
2.2. Niveles de Prueba / en relación con sus atributos
#2
En general, el desarrollador que escribió el código realiza la prueba de componente, pero al menos requiere acceso al código que se está probando. Los desarrolladores pueden alternar el desarrollo de componentes con la búsqueda y corrección de defectos. A menudo, los desarrolladores escriben y ejecutan pruebas después de haber escrito el código de un componente. Sin embargo, especialmente en el desarrollo Ágil, la redacción de casos de prueba de componente automatizados puede preceder a la redacción del código de la aplicación.
2.2.1. Prueba de Componente / Enfoques y Responsabilidades Específicos
#3
El desarrollo guiado por pruebas es altamente iterativo y se basa en ciclos de desarrollo de casos de prueba automatizados, luego se construyen e integran pequeños fragmentos de código, a continuación, se ejecuta la prueba de componente, se corrige cualquier cuestión y se refactoriza el código.
2.2.1. Prueba de Componente / Enfoques y Responsabilidades Específicos
#4
La prueba funcional observa el comportamiento del software, por lo que se pueden utilizar técnicas de caja negra para obtener las condiciones de prueba y los casos de prueba para la funcionalidad del componente o sistema (véase la sección 4.2).
2.3.1. Prueba Funcional
#5
Se pueden utilizar técnicas de caja negra (véase la sección 4.2) para obtener condiciones de prueba y casos de prueba para pruebas no funcionales. Por ejemplo, se puede utilizar el análisis de valores frontera para definir las condiciones de estrés para las pruebas de rendimiento.
2.3.2. Prueba No Funcional
#6
Los casos de prueba no están documentados o están desactualizados.
2.4.2. Análisis de Impacto para el Mantenimiento
Relación con otros capítulos
#1
Para una aplicación móvil, la base de prueba puede incluir una lista de requisitos y una lista de dispositivos móviles soportados. Cada requisito es un elemento de la base de prueba. Cada dispositivo soportado es también un elemento de la base de prueba. Es posible que los criterios de cobertura requieran, como mínimo, un caso de prueba para cada elemento de la base de prueba. Una vez ejecutadas, los resultados de estas pruebas indican a los implicados si se cumplen los requisitos especificados y si se observaron fallos en los dispositivos soportados.
1.4.1. El Proceso de Prueba en Contexto
#2
A menudo, es una buena práctica diseñar casos de prueba de alto nivel, sin valores concretos para los datos de entrada y los resultados esperados. Estos casos de prueba de alto nivel son reutilizables a lo largo de múltiples ciclos de prueba con diferentes datos concretos, sin dejar de documentar adecuadamente el alcance del caso de prueba. Lo ideal es que cada caso de prueba se pueda trazar bidireccionalmente hasta la(s) condición(es) de prueba que cubre.
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo del Diseño de la Prueba
#3
Los datos de prueba sirven para asignar valores concretos a las entradas y a los resultados esperados de los casos de prueba. Estos valores concretos, junto con instrucciones explícitas sobre el uso de los valores concretos, convierten los casos de prueba de alto nivel en casos de prueba ejecutables de bajo nivel. El mismo caso de prueba de alto nivel puede utilizar diferentes datos de prueba cuando se ejecuta en diferentes versiones del objeto de prueba.
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo de la Implementación de la Prueba
#4
Documentación sobre el estado de casos de prueba individuales o procedimientos de prueba (por ejemplo, listo para ejecutar, pasado, fallado, bloqueado, omitido de forma deliberada, etc.).
1.4.3. Productos de Trabajo de la Prueba / Productos de Trabajo de la Ejecución de la Prueba
#5
La cobertura estándar mínima habitual para la prueba de tabla de decisión es tener al menos un caso de prueba por regla de decisión en la tabla. Esto implica, normalmente, cubrir todas las combinaciones de condiciones. La cobertura se mide como el número de reglas de decisión probadas por, al menos, un caso de prueba, dividido por el número total de reglas de decisión, normalmente expresado como un porcentaje.
4.2.3. Prueba de Tabla de Decisión
#6
En condiciones ideales, los casos de prueba se ordenarían en función de sus niveles de prioridad, generalmente ejecutando primero los casos de prueba con mayor prioridad. Sin embargo, esta práctica puede no funcionar si los casos de prueba tienen dependencias o si las características que se están probando tienen dependencias. Si un caso de prueba con una prioridad más alta depende de un caso de prueba con una prioridad más baja, se debe ejecutar primero el caso de prueba con una prioridad más baja.
5.2.4. Calendario de Ejecución de Prueba
#7
Referencias, incluyendo el caso de prueba que puso en evidencia el problema.
5.6. Gestión de Defectos / Informe de Defecto
Resto del listado
entorno de prueba («test environment»)
Definición según Glosario
Entorno que contiene hardware, instrumentación, simuladores, herramientas software y otros elementos de apoyo necesarios para llevar a cabo una prueba.
modelo de desarrollo secuencial («sequential development model»)
Definición según Glosario
Un tipo de modelo de ciclo de vida de desarrollo del software en el que un sistema completo se desarrolla de forma lineal de una serie de fases discretas y sucesivas sin solapamiento entre ellas.
nivel de prueba («test level»)
Definición según Glosario
Instancia específica de un proceso de prueba.
objetivo de prueba («test objective»)
Definición según Glosario
Propósito de la prueba.
objeto de prueba («test object»)
Definición según Glosario
Producto de trabajo al que se va a someter a prueba.
prueba alfa («alpha testing»)
Definición según Glosario
Un tipo de prueba de aceptación realizada en el entorno de prueba del desarrollador por roles ajenos a la organización de desarrollo.
prueba beta («beta testing»)
Definición según Glosario
Tipo de prueba de aceptación realizada en un lugar externo al entorno de prueba del desarrollador por roles ajenos a la organización de desarrollo.
prueba de aceptación («acceptance testing»)
Definición según Glosario
Nivel de prueba que se concentra en determinar si se acepta el sistema.
prueba de aceptación contractual («contractual acceptance testing»)
Definición según Glosario
Tipo de prueba de aceptación realizada para verificar si un sistema satisface sus requisitos contractuales.
prueba de aceptación de usuario («user acceptance testing»)
Definición según Glosario
Tipo de prueba de aceptación que se realiza para determinar si los usuarios previstos aceptan el sistema.
prueba de aceptación operativa («operational acceptance testing»)
Definición según Glosario
Tipo de prueba de aceptación realizada para determinar si el personal de operaciones y/o administración de sistemas puede aceptar un sistema.
prueba de aceptación regulatoria («regulatory acceptance testing»)
Definición según Glosario
Tipo de prueba de aceptación realizada para determinar la conformidad del objeto de prueba.
prueba de caja blanca («white-box testing»)
Definición según Glosario
Prueba basada en el análisis de la estructura interna del componente o sistema.
prueba de componente («component testing»)
Definición según Glosario
Un nivel de prueba que se concentra en componentes hardware o software individuales.
prueba de confirmación («confirmation testing»)
Definición según Glosario
Tipo de prueba relacionada con el cambio que se realiza después de corregir un defecto para confirmar que no se vuelve a producir un fallo causado por ese defecto.
prueba de integración («integration testing»)
Definición según Glosario
Nivel de prueba que se concentra en las interacciones entre componentes o sistemas.
prueba de integración de componente («component integration testing»)
Definición según Glosario
La prueba de integración de componentes.
prueba de integración de sistemas («system integration testing»)
Definición según Glosario
La prueba de integración de sistemas.
prueba de mantenimiento («maintenance testing»)
Definición según Glosario
Prueba de los cambios en un sistema operativo o del impacto de un entorno modificado en un sistema operativo.
prueba de regresión («regression testing»)
Definición según Glosario
Tipo de prueba relacionada con el cambio para detectar si se han introducido o descubierto defectos en zonas no modificadas del software.
prueba de sistema («system testing»)
Definición según Glosario
Nivel de prueba que se concentra en verificar que un sistema como un todo cumple los requisitos especificados.
prueba funcional («functional testing»)
Definición según Glosario
Prueba realizada para evaluar si un componente o sistema satisface los requisitos funcionales.
prueba no funcional («non-functional testing»)
Definición según Glosario
Prueba realizada para evaluar si un componente o sistema cumple los requisitos no funcionales.
software comercial de distribución masiva («commercial off-the-shelf (COTS)»)
Definición según Glosario
Tipo de producto desarrollado en un formato idéntico para un gran número de clientes en el mercado general.
tipo de prueba («test type»)
Definición según Glosario
Grupo de actividades de prueba basadas en objetivos de prueba específicos dirigidos a características concretas de un componente o sistema.
Fuentes de inspiración
Comentario final
¿Te ha sido útil el contenido? Me ayudarías y mucho si consideras que vale compartir este artículo entre tus amigos y poder así enterarte cuando publique contenidos relacionados con las certificaciones, con las buenas prácticas, con herramientas y con testing aplicado en inteligencia artificial.
Buscame y seguime en LinkedIn para conocer las opiniones de colegas respecto de los contenidos que publico y por supuesto me ayudarías y mucho si consideras que vale dejar un like, dejar comentarios, compartirlo con tus amigos.
Muchas gracias
