2P Teoría Flashcards
Plan de CM
Definiciones acerca de un plan de Configuration Management (Plan de CM)
- Define los procesos de Build y de releases
- Define cuándo y cómo se realizan las auditorías.
- Define las políticas de Branching y Merging.
Si en testing el resultado esperado es distinto del obtenido al menos hay un defecto en el sw. V o F
Si el resultado es distinto al esperado, los testers están frente a un incidente, el cual reportará al equipo de desarrollo.
El equipo de desarrollo investigara y determinara si se trata de falla efectivamente (puede que no sea asi, por ejemplo si el incidente NO es producido por el sw, si es producto del ambiente de prueba, no es una falla). En caso de ser así, una falla tiene que ver con por lo menos 1 o mas defectos.
——
Falso. Si el Resultado Esperado es distinto al Resultado Obtenido, se tiene una incidente, este puede deberse a un problema en el estado de prueba, en el caso de prueba, en el entorno y configuración del ambiente, un error en la prueba. Si nada de esto ocurre, entonces, al incidente lo produjo una falla, la falla es la manifestación del defecto y esta tiene que ver con una o más defectos.
Cuál es el objetivo del SCM.
Establecer y mantener la integridad de los productos del proyecto de software a lo largo del ciclo de vida del mismo. Involucra para una configuración:
- Identificarla en un momento dado (que compone el sw- todo lo que involucra).
- Controlar cambios sistemáticamente.
- Mantener su integridad y origen (mantener rastreabilidad).
Acompaña la actividad de cambio con actividades de control.
—-
- La gestión de configuración tiene relación con las actividades de testing.
- El proceso de gestión de configuración debe definir cuándo crear los tags en las herramientas de versionado.
- Identificar los propósitos de un cambio forma parte de las actividades del control de configuración.
Indique 5 pruebas no funcionales.
Pruebas de stress, pruebas de performance, pruebas de volumen, pruebas de seguridad, pruebas estructurales (caja blanca).
SCM - VoF? Las auditorías de proceso verifican consistencia entre código y lo especificado en los requerimientos definidos.
F. Las auditorías de proceso verifican se haya cumplido el proceso de SCM.
La consistencia entre código y requerimiento se realiza mediante la auditoría funcional.
Testing - VoF? Condición de borde hace referencia a llevar al límite de su capacidad al sistema como, por ejemplo, con una alta carga de transacciones.
F. Condiciones de Borde: del rango de valores se prueban casos válidos para los extremos del rango y casos inválidos para los valores siguientes a los extremos. Si la entrada o salida es un conjunto ordenado, enfocar la atención en el primero y en el último de los elementos del conjunto.
Testing - VoF? Las pruebas de aceptación de usuario deben asegurar la completitud de condiciones que se pueden derivar de las técnicas de caja negra y caja blanca.
F. La PAU es en esencia una prueba de caja negra. Es la prueba que realizan los usuarios para verificar que el sistema se ajuste a sus requerimientos.
Dada la siguiente afirmación, ¿La misma es verdadera o falsa? Las auditorías físicas de SCM pueden ser reemplazadas por la actividad de testing (“Quality Control”).
F, el testing intenta descubrir errores mientras que la auditoría física verifica la configuración de cada ítem para determinar si cumple con las especificaciones de configuración establecidas.
- Identificación de Configuración
- Configuration Status & Accounting
- Control de la configuración
Asocie las siguientes definiciones de áreas funcionales de SCM, de acuerdo a lo visto en clase.
- Reportar la de trazabilidad de todos los cambios efectuados al baseline -> Configuration Status & Accounting
- Establecer los mecanismos/procedimientos de autorización de cambios al software -> Control de la configuración
- Conocer qué elementos componen al producto Software y qué deben ser controlados por el proceso de SCM -> Identificación de Configuración
- Verificar que los procesos de SCM se siguen rigurosamente -> Auditoría de la configuración
Una forma de validar una auditoría funcional es mediante:
Una forma de validar una auditoría funcional es mediante: testing.
- Build & Release.
- Entrega Contínua (Continuous Delivery).
- Integración Contínua.
- Despliegue contínuo (Continuos Deployment).
TODO NEW: Agregar al resumen
Relacione cuál categoría de la derecha pertenece a la de la izquierda.
- Asegura la construcción exitosa del paquete de software para luego liberarlo en forma controlada en base a los ítems de configuración y los requerimientos -> Build & Release.
- Asegura que el software se puede desplegar rápidamente en entornos semiproductivos -> Entrega Contínua (Continuous Delivery).
- Ayuda a hacer más rápida la construcción de paquetes de software, integrando al menos una vez al día -> Integración Contínua.
- Asegura que el software pueda ser desplegado rápidamente en producción sin supervisión -> Despliegue contínuo (Continuos Deployment).
Ejemplos concretos de pruebas no funcionales.
- Si una aplicación debe soportar 1000 transacciones por minuto. Las pruebas relacionadas con ver el comportamiento de la aplicación a partir de 1100 o 1200 transacciones por minuto deberán ser incluídas en las pruebas de: Stress, ya que se somete al sistema excediendo los límites de capacidad de procesamiento y almacenamiento teniendo en cuenta situaciones no previstas originalmente.
- Qué tipo de prueba se debe realizar si quiero evaluar si un sistema procesa todas sus transacciones en menos de 4 seg? Prueba de performance.
- Definir 3 requerimientos no funcionales y con que prueba lo usaría.
● La aplicación está hecha para soportar 30 usuarios a la vez. Quiero saber que pasa cuando hay 40 → prueba de stress.
● La aplicación está hecha para x cantidad de consultas (INSERT, UPDATE, DELETE) en la base → pruebas de volumen - procesamiento.
● Que la aplicación sea fácil de usar → prueba de usabilidad.
● Un usuario que no tenga rol de administrador no puede cambiarle el precio a una prenda → prueba de seguridad. - El sistema soporta 1 millón de usuarios -> Pruebas de volumen.
- El sistema tiene que resolver una transacción en 3 segundos -> pruebas de eficiencia.
- Acepta hasta 4 dígitos -> sistema? clave de acceso - seguridad.
Ejemplos concretos de Status & accounting
- S&A es responsable de apoyarme en esa situación: Necesito identificar todos los cambios realizados por un developer en los últimos 5 meses.
- Necesito saber cuántos cambios tuvo un componente determinado durante el último año.
- Necesito saber quién fue el que introdujo el último cambio en un componente.
- Se eliminó el diagrama de clases del baseline de diseño.
- Conocer el alcance de un cambio en determinado componente.
- NO: Detectar la presencia de código que no corresponde a las reglas de negocio/requerimientos solicitados en una versión.
Ejemplo concreto de Software Configuration Change Control
- Necesito hacer un freeze o congelamiento de cambios en una fecha específica (día del padre, de la madre, fin de año).
Ejemplo concreto de Control de Versiones
- Un error viejo y ya corregido en el código vuelve a aparecer.
