¿Qué es ISTQB®? Organización sin ánimo de lucro. Encontrar tantos fallos como sea posible para que los defectos subyacentes se identifiquen y se solucionen de forma temprana. Está compuesta por voluntarios internacionales expertos en pruebas. El proceso que incluye todas las actividades, tanto estáticas como dinámicas, del ciclo de vida .
Las pruebas de nivel fundamentos y avanzado abarcan cuatro niveles-K distintos (K1 a K4):
¿Cuál es el nivel en el que el candidato debe elegir una explicación para un extracto relacionado con el tema de la pregunta? K1 K2 K3 K4.
¿Qué actividades se realizan con la prueba de software? La ejecución de la prueba. Las prioridades de negocio. Informar del avance y los resultados de la prueba. Los riesgos de producto y de proyecto identificados.
Las pruebas que implican la ejecución del componente o sistema que está probando ¿se denominan? Prueba Dinámica Pruebas Estáticas.
Objetivos Característicos de la Prueba Prevenir defectos. Evaluar productos de trabajo tales como requisitos, historias de usuario, diseño y código. Dominio del negocio. Generar confianza en el nivel de calidad del objeto de prueba.
¿Por qué es Necesario Probar? Se reduce el riesgo de alcanzar fallos durante la operación Para decirle al Developer que su trabajo no es bueno Para cumplir con los requisitos contractuales o legales Para utilizar el Modelo en cascada el mejor de todos.
Causas de los defectos de software Errores humanos: Presupuestos y recursos. Errores técnicos Errores ambientales o de entorno Generar confianza en el nivel de calidad del objeto de prueba.
Siete Principios de la Prueba: Niveles y tipos de prueba considerados. Las pruebas muestran la presencia de defectos Paradoja del pesticida Presupuestos y recursos. Las pruebas exhaustivas no existen Cumplir los objetivos definidos. .
Siete Principios de la Prueba: Principio 1 – Las pruebas muestran la presencia de defectos Principio 2 – Las pruebas exhaustivas no existen Principio 3 – Pruebas tempranas Principio 4 – Agrupación de defectos Principio 5 – Paradoja del pesticida Principio 6 – Las pruebas dependen del contexto Principio 7 – Falacia de ausencia de errores.
¿La planificación de la prueba define los objetivos de las pruebas? Verdadero Falso.
Los factores de contexto que influyen en el proceso de prueba de una organización incluyen pero no están limitados a: Niveles y tipos de prueba considerados. Análisis de la prueba. Restricciones operativas Políticas y prácticas de la organización.
La evaluación de los criterios de salida para la ejecución incluye la información de diseño e implementación. Verdadero Falso.
El análisis de la prueba determina: "cómo probar". "qué probar" . " ¿está todo preparado para realizar la prueba?”.
Análisis de la Prueba.
- Actividades principales: Informes de análisis de riesgos La implementación del componente o sistema en sí Diseñar el entorno de prueba e identificar la infraestructura y las herramientas necesarias. Especificaciones de requisitos.
La monitorización es un seguimiento continuo con cualquier métrica. La monitorización y el control de la prueba se apoyan en la evaluación de los criterios de salida. Verdadero Falso.
Diseño de la Prueba.
Incluye las siguientes actividades principales: Finalizar, implementar y priorizar los casos de prueba Identificar los datos de prueba necesarios para apoyar las condiciones de prueba y los casos de prueba. Captura de la trazabilidad bidireccional Información de diseño e implementación.
En el diseño de prueba las condiciones se transforman en conjuntos de casos de prueba de bajo nivel y otros productos de prueba. Verdadero Falso.
Durante la implementación de la prueba, se crean y/o se completan los productos de prueba necesarios para la ejecución de la prueba Verdadero Falso.
La implementación de la prueba incluye las siguientes actividades principales: Capturar la trazabilidad bidireccional entre la base de prueba, las condiciones de prueba, los casos de prueba y los procedimientos de prueba. Crear juegos de prueba a partir de los procedimientos de prueba y (si los hubiera) guiones de prueba automatizados. Finalizar, implementar y priorizar los casos de prueba Construir el entorno de prueba .
A menudo se combinan las tareas de diseño y ejecución de la prueba. Verdadero Falso.
La prueba exploratoria:
¿Se ejecuta inmediatamente, a medida que se diseña e implementa? Verdadero Falso.
Durante la ejecución de la prueba, los juegos de prueba se ejecutan de acuerdo al calendario de ejecución de la prueba. Verdadero Falso.
Comparar los resultados reales con los resultados esperados.
¿Forma parte de la ejecución de la prueba? Si No.
Compleción de la Prueba
Recopilan datos de las actividades de prueba completadas para consolidar la experiencia Verdadero Falso.
Las actividades de compleción de la prueba ocurren: Cuando finaliza una iteración de un proyecto Ágil. Hitos, cuando un software es liberado. Verificar el entorno de pruebas Cuando se completa un nivel de prueba. Verificar y actualizar trazabilidad entre base de pruebas y casos de pruebas.
Una buena trazabilidad permite: Analizar el impacto de cambios. Comenzar con colaboración en lugar de batallas. Recordar a todos que el objetivo común es lograr sistemas de mejor calidad. Confirmar que el interlocutor ha entendido lo que se ha dicho y viceversa. Relacionar los aspectos técnicos de la prueba con los implicados en términos que éstos puedan entender. Un proyecto de prueba es completado o cancelado.
La Psicología del Proceso de Prueba:
Es correcto:
- Comunicar los resultados de las pruebas y otros hallazgos de
manera subjetiva, criticando a la persona que creó el elemento defectuoso para que se ponga las pilas. Verdadero Falso.
Modelos de Ciclo de Vida del Desarrollo de Software Modelo en cascada. Modelo de desarrollo iterativo-incremental. Diseño detallado. Modelo de datos.
Modelos de Ciclo de Vida del Desarrollo de Software, describe los tipos de actividad que se realizan en cada etapa de un proyecto de desarrollo de software, y cómo las actividades se relacionan entre sí de forma lógica y cronológica
Verdadero Falso.
Hay diferentes modelos de ciclo de vida de desarrollo de software si no.
¿Qué modelo de Ciclo de Vida del Desarrollo de Software es este? Modelo de desarrollo iterativo-incremental. Modelo cascada Modelo de desarrollo secuencial (Modelo V).
Metodologías. Kanban Rational Unified Process Espiral (o prototipado) Scrum.
Se debe seleccionar un Modelo de vida apropiado en función de: Objetivo del proyecto Tipo de proyecto Los riesgos de producto y de proyecto identificados. Defectos y fallos característicos.
Niveles de Prueba: Prueba de componente. Prueba y fallos característicos. Prueba de aceptación. Prueba y responsabilidades específicos. Prueba de sistema. Prueba de integración Prueba Objetivos específicos.
Los niveles de prueba se caracterizan por los siguientes atributos: Objetivo del componente. Bases de prueba, referenciadas para generar casos de prueba. Defectos y fallos característicos. Objetivo del sistema de aceptación.
Prueba de Componente:
Los objetivos de la prueba de componente incluyen: Enfoques y responsabilidades específicos. Tipo de proyecto. Reducir el riesgo. Prevenir la propagación de defectos a niveles de prueba superiores. Generar confianza en la calidad del componente.
Prueba de Componente (Unitaria o de módulo):
se centra en los componentes que no se pueden probar por separado. Verdadero Falso.
Prueba de Componente.
Algunos ejemplos de productos de trabajo que se pueden utilizar como base de prueba para la prueba de componente incluyen: Diseño detallado. Clases. Modelo de datos. Módulos de base de datos.
Prueba de Componente.
Los objetos de prueba característicos para la prueba de componente incluyen: Módulos de base de datos. Componentes, unidades o módulos. Diseño detallado. Código. Modelo de datos.
Prueba de Componente.
Ejemplos de defectos y fallos característicos de la prueba de componente incluyen: Código y estructuras de datos Problemas de flujo de datos. Se elaboran los casos de prueba antes de codificarlos. Código y lógica incorrectos.
Prueba de Componente.
Enfoques y Responsabilidades Específicos Pueden incluir pruebas de funcionalidad y características no funcionales específicas o pruebas de robustez. Se elaboran los casos de prueba antes de codificarlos. Se llevan a cabo mediante el acceso al código objeto de las pruebas y con un soporte de entorno de desarrollo. Verificar que los comportamientos funcionales y no funcionales del componente son los diseñados y especificados.
Prueba de Integración.
¿Hay dos niveles de prueba de integración diferentes? Si No.
La prueba de integración de componentes: El entorno de pruebas debe coincidir en la máxima medida al entorno de producción final Los probadores estarán capacitados para enfrentarse a requisitos incompletos o mal documentados Cuanto más amplios sea el alcance de la integración, más difícil será aislar los fallos de una componente o sistema específico Los probadores deben entender la arquitectura y modificar la planificación de la integración si procede En cada fase de integración, los probadores deben centrarse en la propia integración.
La prueba de integración de sistemas: Normalmente la integración será incremental En cada fase de integración, los probadores deben centrarse en la propia integración El entorno de pruebas debe coincidir en la máxima medida al entorno de producción final Las pruebas de sistemas se refieren al comportamiento de todo un sistema/producto.
Prueba de Integración.
Algunos ejemplos de productos de trabajo que pueden utilizarse como base de prueba para la prueba de integración incluyen: Bases de datos. Diseño de software y sistemas. Interfaces. Especificaciones de interfaz y protocolos de comunicación. Flujos de trabajo.
Prueba de Integración.
Los objetos de prueba característicos para la prueba de integración incluyen: Bases de datos. Casos de uso. Diagramas de secuencia. Infraestructura. Microservicios.
Prueba de Integración.
Entre los ejemplos de defectos y fallos característicos de la prueba de integración de componentes se incluyen los siguientes: Fallos en la comunicación entre componentes. Problemas de flujo de datos. Suposiciones incorrectas sobre el significado, las unidades o las fronteras de los datos que se transmiten entre componentes. Código y lógica incorrectos.
Prueba de Integración.
Entre los ejemplos de defectos y fallos característicos de la prueba de integración de sistemas se incluyen los siguientes: Estructuras de mensajes inconsistentes entre sistemas. Fallos en la comunicación entre sistemas. Secuenciación o sincronización incorrecta de las llamadas a la interfaz. Datos incorrectos, datos faltantes o codificación incorrecta de datos. Incumplimiento de las normas de seguridad obligatorias.
¿Quién realiza la prueba de integración de componentes? Desarrolladores Probadores QA.
¿Quién realiza la prueba de integración de sistemas ? Desarrolladores Probadores QA.
Cuanto más amplios sea el alcance de la integración, más difícil será aislar los fallos de una componente o sistema específico. Verdadero Falso.
Prueba de Sistema.
Los objetos de prueba característicos para la prueba de sistema incluyen: Sistemas operativos. Configuración del sistema y datos de configuración. Control y/o flujos de datos incorrectos dentro del sistema. Cálculos correctos del sistema Sistema sujeto a prueba (SSP).
Prueba de Sistema.
Entre los ejemplos de defectos y fallos característicos de la prueba de sistema se incluyen los siguientes: Fallo en el sistema hardware Fallo del sistema para funcionar como se describe en los manuales del sistema y de usuario. Cálculos incorrectos. Fallo de aplicaciones del sistema Configuraciones de software capadas.
Prueba de Sistema.
Enfoques y Responsabilidades Específicos:
Los probadores deben entender la arquitectura y modificar la planificación de la integración si procede. Deben estudiar requisitos funcionales y no funcionales Se llevan a cabo mediante el acceso al código objeto de las pruebas y con un soporte de entorno de desarrollo Los riesgos de producto y de proyecto deben ser identificados.
Prueba de Aceptación.
Los objetivos de la prueba de aceptación incluyen: Validar que el sistema está completo y que funcionará como se espera. Establecer confianza en la calidad del sistema en su conjunto. No constituyen necesariamente el último nivel de prueba Configuración del sistema y datos de configuración.
Las pruebas de aceptación constituyen necesariamente el último nivel de prueba Verdadero Falso.
Las formas comunes de prueba de aceptación incluyen las siguientes: Prueba de aceptación de usuario. Prueba de aceptación contractual y de regulación. Prueba de copia de seguridad y restauración. Prueba de casos de uso. Prueba de aceptación operativa. Prueba de procedimientos de instalación. Prueba alfa y beta.
¿Qué significa UAT por sus siglas en inglés?.
Definición:
Validación para el uso del sistema por parte de los usuarios previstos en un entorno operativo real o simulado. Prueba de Aceptación de Usuario Prueba de Aceptación Operativa Prueba de Aceptación Contractual y Normativa.
Definición:
La prueba de aceptación de sistema por parte del personal de operaciones o de la administración del sistema se realiza, por lo general, en un entorno de producción (simulado). Pruebas Alfa y Beta Prueba de Aceptación Contractual y Normativa Prueba de Aceptación Operativa Prueba de Aceptación de Usuario .
Definición:
se realiza en función de los criterios de aceptación del contrato para el desarrollo de software a medida. Pruebas Alfa y Beta Prueba de Aceptación Contractual y Normativa Prueba de Aceptación Operativa.
Definición:
suelen ser utilizadas para la distribución masiva para los usuarios, clientes y/u operadores potenciales o existentes antes de que el producto de software sea puesto en el mercado. Prueba de Aceptación Operativa Pruebas Alfa y Beta Prueba de Aceptación de Usuario Prueba de Aceptación Contractual y Normativa.
Tipos de Prueba Pruebas de funciones (funcionales). Pruebas de estructura/arquitectura del software caja negra Pruebas de mantenimiento. Pruebas de características no funcionales del software (no funcionales). Pruebas asociadas al código Pruebas de estructura/arquitectura del software (estructurales, Caja Blanca). Pruebas asociadas a cambios (repetición y regresión).
Prueba Funcional.
Las funciones son todo lo que hace el sistema, subsistema o componente. Verdadero Falso.
Prueba Funcional. Caja negra Prueba de Componentes. Caja Blanca Pruebas de mantenimiento.
Prueba Funcional.
Los requisitos funcionales pueden estar descritos en productos de trabajo tales como: Casos de uso. Épicas Pueden no estar documentados. Se realiza sobre las funciones internas de un módulo.
¿Con que se puede medir la intensidad de la prueba funcional? .
Prueba No Funcional
Pruebas de características no funcionales del software (no funcionales) Incluyen: Pruebas de compatibilidad y portabilidad. Pruebas de portabilidad. Pruebas mantenido la trazabilidad bidireccional Pruebas de usabilidad. Pruebas de rendimiento.
La prueba de caja blanca obtiene pruebas basadas en la estructura interna del sistema o en su implementación. La estructura interna puede incluir código, arquitectura, flujos de trabajo y/o flujos de datos dentro del sistema Verdadero Falso.
Prueba de Caja Blanca.
• Son las menos adecuadas para medir la exhaustividad de las pruebas Verdadero Falso.
Prueba de Caja Blanca.
Pueden realizarse en todos los niveles de pruebas
Verdadero Falso.
Prueba Asociada al Cambio.
Elige la definición correcta:
Una vez detectado y corregido el defecto, el software debe volver a probarse para confirmar que el defecto ha sido corregido con éxito Hay que mantener el software ya sea para corregir defectos descubiertos en el uso operativo, para añadir nuevas funcionalidades o para eliminar o alterar funcionalidades ya entregadas. Obtiene pruebas basadas en la estructura interna del sistema o en su implementación. La estructura interna puede incluir código, arquitectura, flujos de trabajo y/o flujos de datos dentro del sistema.
Prueba de Mantenimiento.
Las características de calidad no funcionales del componente o sistema a lo largo de su vida útil: Eficiencia de desempeño. Pruebas de usabilidad. Pueden no estar documentados.
|
