Please enable JavaScript.

Coggle requires JavaScript to display documents.

Certificación ISTQB Foundations Certified Tester Foundation Level (CTFL) …

- - - - Planificación de la prueba. Se definen los objetivos y el enfoque para cumplir dichos objetivos, dentro de las restricciones del contexto (plan de pruebas, técnicas a utilizar).
      - Monitorización/seguimiento y control.
        
        Monitorización/seguimiento: Comparación continua del avance real con respecto al plan de prueba mediante métricas definidas en el plan de pruebas.
        
        Control: Tomar las medidas necesarias para el cumplimiento del plan de prueba.
        Criterios de salida:
        
        Comprobar los resultados y los registros de la prueba.
        
        Evaluar el nivel de calidad con base en los resultados y registros.
        
        Determinar si se necesitan mas pruebas.
        El avance de la prueba con respecto al plan se comunica a los implicados por medio de informes de avance de prueba, incluyendo desviaciones.
      - Análisis de la prueba. Se analiza la base prueba para identificar los features y las condiciones de prueba, es decir, "Qué probar" en términos de cobertura medibles.
        Actividades principales:
        
        Analizar la base de prueba: Especificación de requisitos, diseño como esquemas, diagramas, modelado.
        
        Implementación: código, metadatos, servicios.
        
        Informe de análisis de riesgos: Aspectos funcionales, no funcionales y estructurales.
        
        Evaluar la base de prueba para identificar defectos como: Ambigüedades, omisiones, contradicciones,etc.
        
        Identificar features a probar
        
        Definir y priorizar las condiciones de prueba.
        
        Trazabilidad bidireccional entre el elemento de prueba y las condiciones de prueba.
        Se aplican técnicas de prueba para evitar omitir condiciones de prueba importantes u objetivos de prueba.
        
        Identificación de defectos antes de la codificación.
      - Diseño de la prueba. Se definen casos de prueba y se responde a la pregunta "Cómo probar".
        Actividades principales:
        
        Diseñar y priorizar casos de prueba
        
        Identificar datos de prueba necesarios
        
        Diseñar entorno de prueba e identificar infraestructura y herramientas.
        
        Capturar trazabilidad bidireccional entre: base de prueba, condiciones de prueba, casos y procedimientos de prueba.
        Posible identificación de defectos antes de la codificación.
      - Implementación de la prueba. Se define la secuenciación de los casos de prueba. Se responde a la pregunta ¿Está todo preparado para realizar la prueba?
        
        Desarrollar y priorizar procedimientos de prueba, scripts de pruebas automatizadas.
        
        Crear suites de pruebas.
        
        Agendar los suites de pruebas.
        
        Construir entorno de prueba (simuladores, arneses, virtualización de servicios,etc.)
        
        Preparar datos de prueba ya en el ambiente de pruebas.
        
        Verificar trazabilidad bidireccional entre elementos.
        A menudo se combinan las tareas de diseño y ejecución d ela prueba.
      - Ejecución de la prueba. Se ejecutan los suites de prueba de acuerdo al calendario de ejecución.
        
        Identificar y registrar: Versiones de los elementos de prueba, herramientas y productos de prueba.
        
        Ejecutar pruebas manuales o automatizadas
        
        Comparar resultados reales vs esperados
        
        Analizar anomalías para establecer causas probables
        
        Informar sobre defectos con respecto a fallos observados
        
        Registrar resultados
        
        Repetir actividades: Por regresiones o depuraciones.
        
        Verificar la trazabilidad bidireccional con todos los elementos inlcuyendo los resultados de la prueba.
      - Compleción de la prueba (Cierre o finalización)
        Consolidar la experiencia obtenida.
        Hitos:
        
        Liberación del sistema
        
        Proyecto de pruebas completado o cancelado
        
        Finaliza una iteración (proyecto ágil)
        
        Término de nivel de prueba
        
        Liberación de un mantenimiento
        Actividades:
        
        Verificar todos los defectos reportados estén cerrados
        
        Finalizar, archivar y almacenar los productos de prueba
        
        Traspaso de los productos de prueba a mantenimiento u otros equipos implicados.
        
        Analizar lecciones aprendidas para la mejora continua
        
        Utilizar la información para mejorar la madurez del proceso de prueba.
        
        Informe de resumen de las pruebas.
    - - Productos de trabajo de la planificación de la prueba:
        
        1 o mas planes de prueba (información de la base de prueba y los criterios de salida).
        Productos de trabajo de monitorización y control.
        
        Varios tipos de informes: Informes de avance, informes de resumen, resultados de la ejecución, compleción de tareas, asignación y uso de recursos y esfuerzo).
        Productos de trabajo de Análisis de la prueba
        
        Condiciones de prueba definidas y priorizadas
        
        Contratos de prueba (para exploratorias)
        
        Descubrimiento y notificación de defectos
        Productos de trabajo del diseño de la prueba
        
        Casos de prueba y suites de casos.
        
        Diseño y/o identificación de datos de prueba
        
        Diseño del entorno de prueba
        
        Identificación de la infraestructura y herramientas.
        Las condiciones de prueba definidas en el análisis pueden refinarse aún más en la implementación.
        Productos de trabajo de Implementación de la prueba
        
        Secuencia de procedimientos de prueba
        
        Suites de prueba
        
        Calendario de ejecución de pruebas
        Las condiciones de prueba definidas en el análisis pueden refinarse aún más en la implementación.
        Productos de trabajo de la ejecución de la prueba
        
        Documentación sobre el estado de casos de prueba individuales o procedimientos.
        -- Qué requisitos pasaron las pruebas planificadas
        -- Qué requisitos han fallado y tienen defectos asociados
        -- Requisitos a la espera
        Productos de trabajo de la compleción de la prueba
        
        Informes de resumen de la prueba
        
        Elementos de acción para la mejora continua
    - - 1.5.1 Psicología Humana y el Proceso de Prueba.
        
        Crítica al producto y a su autor
        
        Sesgo de confirmación (impide ver los errores en el propio trabajo)
        
        Información sobre defectos y fallos debe darse de manera constructiva tanto para pruebas estáticas como dinámicas.
        Buenas prácticas
        
        Comenzar con colaboración en lugar de batallas
        
        Enfatizar los beneficios de la prueba:
        -- Para autores: Mejorar su productos de trabajo y sus competencias.
        -- Para la empresa: Ahorro de tiempo y dinero por errores detectados corregidos durante la prueba.
        
        Comunicar resultados de las pruebas de forma neutral y centrada en los hechos
        
        Entender ls razones por las que podría molestar la información generada de las pruebas
        
        Confirmar que el mensaje ha sido entendido para facilitar la comunicación.
        Establecer en equipo los objetivos de las pruebas
      - 1.5.2 Formas de pensar del probador (tester) y del desarrollador
        
        Mentalidad del desarrollador: Diseño y construcción de soluciones.
        - Mentalidad del tester: Curiosidad, pesimismo profesional, sentido crítico, atención al detalle, motivación para una comunicación y relaciones buenas y positivas.
        - Con la mentalidad correcta los desarrolladores pueden probar su propio código.
        
        Los testers externos aumenta la eficacia de detección de defectos. Tienen diferentes sesgos cognitivos que los autores.
  - - - Ejemplo:
        -Fallo: Pago de interés incorrecto
        - Defecto: Cálculo incorrecto del interés
        - Error: Ambigüedad en la historia de usuario
        - Causa raíz: Falta de conocimiento del propietario del producto
- - - - Características que hacen que las pruebas sean adecuadas:
        
        Para cada actividad de desarrollo, una actividad de prueba asociada.
        
        Cada nivel de prueba tiene objetivos específicos de ese nivel.
        
        El análisis y diseño de la prueba (en cualquier nivel) comienza durante la actividad de desarrollo.
        
        Involucramiento en la revisión de productos de trabajo desde etapas tempranas, adhiriéndose al principio de "prueba temprana".
      - Modelos de desarrollo secuencial
        
        Modelo en cascada: Las actividades de desarrollo se completan una tras otra, las actividades de prueba sólo ocurren al final del desarrollo.
        
        Modelo en V: Integra al proceso de prueba a lo largo de todo el proceso de desarrollo (se adhiere al principio de prueba temprana) diferentes niveles de prueba en cada fase de desarrollo. Pruebas secuenciales y solapadas.
      - Modelos de desarrollo iterativos e incrementales
        Características:
        
        Se establecen requisitos, se diseña, se construye y se prueba por fragmentos, las prestaciones (features) del software crecen de forma incremental.
        
        Se construye por ciclos y cada iteración entrega software operativo.
        
        Implican niveles de prueba que se solapan e iteran en todo el desarrollo.
        
        Cada prestación probarse a diferentes niveles. Despliegue continuo, automatización significativa de varios niveles de prueba.
        
        La prueba de regresión más importante a medida que el sistema crece.
        
        Relational Unified Process: Iteraciones largas (2 ó 3 meses) incrementos grandes, cambios y de 2 o más prestaciones (features).
        
        Scrum: Iteraciones cortas (horas, días o pocas semanas) incrementos pequeños, pocas mejoras y 2 ó 3 features nuevas.
        
        Kanban: Con o sin iteraciones de longitud fija, una o varias features a la vez.
        
        Espiral (prototipado): Incrementos experimentales que pueden ser reelaborados a profundidad o abandonados.
    - - Combinar o reorganizar los niveles de prueba y/o las actividades de prueba
        Ejemplo:
        Modelo en V para pruebas de back-end y modelo scrum para pruebas front-end y el prototipado en etapas tempranas en el diseño.
        Los sistemas de internet de las cosas (IoT) pueden aplicar un modelo por cada objeto y dar mayo énfasis a las etapas posteriores del ciclo (operación, actualización y retirada).
  - - - Base de prueba: Procesos de negocio, requisitos de usuario y de negocio, normativas, contratos legales, casos de uso, documentación del sistema o del usuario, procedimientos de instalación, informes de análisis de riesgos.
        Base de prueba para la aceptación operativa: Procedimientos de copia de seguridad y restauración, de recuperación de desastres, requisitos no funcionales, documentación de operaciones, instrucciones de despliegue e instalación.
        Objetos de prueba: Sistema, configuración, procesos operativos, formularios, informes, etc.
        Defectos y fallos característicos: Flujos de trabajo del sistema no cumplen con los requisitos de negocio o de usuario, reglas de negocio no implementadas, el sistema no satisface requisitos contractuales o reglamentarios, fallos no funcionales como vulnerabilidades de seguridad, eficiencia de rendimiento inadecuada bajo cargas elevadas.
        Enfoques y responsabilidades: La prueba de aceptación es responsabilidad de los clientes, usuarios de negocio, propietarios del producto u operadores del sistema.
        En desarrollo secuencial se considera el último nivel de prueba. La prueba de aceptación en un COTS se hace cuando se instala o integra el sistema. La prueba de aceptación de una mejora funcional, puede tener lugar antes de la prueba de sistema.
        En desarrollo iterativo se pueden emplear varias formas de pruebas de aceptación (durante y al final de cada iteración, pruebas alfa y beta al final de cada iteración, después de cada iteración o al final de varias iteraciones, etc.)
    - - 2.3.1 Prueba funcional: Se incluyen pruebas que evalúan las funciones y comportamientos del sistema con base en los requisitos funcionales (Qué debe hacer el sistema).
        Los requisitos pueden estar descritos en especificaciones de requisitos del negocio, épicas, historias, casos de uso, especificaciones funcionales o pueden no estar documentadas.
        Las pruebas funcionales pueden aplicarse en todos los niveles de prueba, y en cada nivel será diferente el enfoque.
        Las técnicas de prueba que se usan son las de caja negra para obtener las condiciones y casos de prueba.
        La cobertura de pruebas se puede expresar como un porcentaje de los elementos cubiertos por las pruebas (trazabilidad entre pruebas y requisitos).
        El diseño y ejecución de las pruebas funcionales implican conocimiento especializado del tester sobre el negocio y sus problemáticas.
      - 2.3.2 Prueba no funcional:Evalúa las características de sistemas y software como: Usabilidad, eficiencia del desempeño y la seguridad. También pueden considerarse las pruebas de carga/estrés, mantenibilidad, fiabilidad, portabilidad.
        Se pueden realizar pruebas no funcionales en todos los niveles de prueba. Se pueden utilizar las técnicas de caja negra para la definición de condiciones y casos de prueba (p.e. valores frontera para definir condiciones de estrés para pruebas de rendimiento).
        La cobertura de pruebas se puede expresar como un porcentaje de los elementos cubiertos por las pruebas (trazabilidad entre pruebas y requisitos).
        El diseño y ejecución de las pruebas no funcionales implican conocimiento especializado del tester sobre debilidades iherentes a un diseño o tecnología.
      - 2.3.3 Prueba de caja blanca: Pruebas basadas en la estructura interna del sistema o en su implementación (código, arquitectura, flujos de trabajo, flujos de datos dentro del sistema).
        Cobertura estructural es la medida en que algún tipo de elemento estructural ha sido practicado mediante pruebas y porcentaje del tipo de elemento cubierto.
        Prueba de componente: % de código (sentencias y decisiones) que ha sido probado.
        Prueba integración de componentes: Arquitectura e interfaces de componentes, % de interfaces practicadas en las pruebas.
        Diseño y ejecución implica competencias especializadas sobre la forma en que se construye el código.
      - 2.3.4 Prueba asociada al cambio: Cambios de sistemas (corrección de defectos o funcionalidad nueva o modificada).
        Se confirman los cambios con pruebas de confirmación y pruebas de regresión. Se realizan en todos los niveles de prueba.
        En ambientes ágiles en donde el código cambia constantemente, las pruebas de confirmación y de regresión son muy importantes.
        
        Pruebas de confirmación: Al corregir defectos, se ejecutan nuevamente los casos fallidos o nuevos para confirmar que se han corregido los defectos.
        
        Pruebas de regresión: La prueba de regresión implica la realización de pruebas para detectar efectos secundarios no deseados en componentes, el sistema o el entorno.
        Estas pruebas son candidatas a la automatización.
      - 2.3.5 Tipos de prueba y niveles de prueba
        Es posible realizar cualquiera de los tipos de prueba mencionado en cualquiera de los niveles de prueba.
        1 tipo de prueba - n niveles.
- - - - Lo que incluyen las pruebas estáticas
        
        Defectos en los requisitos (p.e. inconsistencias, ambigüedades)
        
        Defectos de diseño (p.e. algoritmos o estructuras de BD ineficientes)
        
        Defectos de codificación (variables con valores no definidos, variables que no se usan, código duplicado)
        
        Desviaciones con respecto a estándares (p.e. estándares de codificación)
        
        Especificaciones de interfaz incorrectas
        
        Vulnerabilidades de seguridad
        
        Deficiencias en la trazabilidad o cobertura de la base de prueba
        La mayoría de los tipos de defectos de mantenibilidad solo son detectables por pruebas estáticas.
- - - - Proceso de aplicación de la técnica:
        
        Identificar la variable (Ejemplo: Edad de un empleado "E")
        
        Identificar la partición de equivalencia:
        a. Clases válidas: rangos permitidos (>=18 E <=60)
        b. Clases no válidas: rangos no permitidos (E<=17 y E >60)
        c. Crear un caso de prueba para cada CE
        (Se generan un caso válido y 2 casos inválidos)
        d. Identificar un representante por cada CE
        Caso inválido 1: 16
        Caso válido: 25
        Caso inválido 2: 65
        Nota: Armar tabla de casos con estos datos
        La cobertura se determina:
        (Núm. de particiones de equivalencia probadas x al menos un valor/ Total de particiones de equivalencia identificadas) *100
    - - Proceso de aplicación de la técnica:
        
        Identificar la variable (Ejemplo: Campo de entrada con valor entero)
        
        Identificar la partición válida (Valor comprendido entre 1 y 5)
        2.1. Valor límite inferior (1)
        2.1.1 Valor menor al límite inferior (0)
        2.1.2 Valor mayor al límite inferior (2)
        2.2 Valor límite superior (5)
        2.2.1 Valor menor al límite superior (4)
        2.2.2 Valor mayor al límite superior (6)
        
        Crear un caso de prueba por cada valor
        
        Identificar el valor representante de cada caso
        Nota: Por default siempre saldrán 6 casos de prueba de cada partición válida, pero se pueden agrupar omitiendo los valores válidos intermedios.
      - Versión ISTQB 2011, 2 valores
        Versión ISTQB 2018, 3 valores
        
        Valores Frontera (2018):
        
        En el límite
        
        Por debajo del límite
        
        Por encima del límite
    - - Componentes de la tabla de decisión:
        
        Condiciones (entradas)
        
        Acciones (salidas)
        
        Reglas (combinación de condiciones)
      - Proceso de aplicación de la técnica:
        
        Identificar condiciones y los posibles valores (Ejemplo: un login de un sistema web)
        Valores: Usuario (correcto, incorrecto) contraseña (correcta, incorrecta)
        
        Identificar acciones de salida (Mensaje del sistema, Ingresar al sistema, recuperar contraseña, no acceso al sistema)
        
        Realizar las combinaciones viables de condiciones (1.Usuario correcto, 2.contraseña incorrecta, 3.contraseña correcta, usuario incorrecto, 4. contraseña y usuario correctos, 5. contraseña y usuarios incorrectos)
        
        Definir los valores de acciones de acuerdo
        con las condiciones de entrada (para la salida mensaje del sistema, clave incorrecta, para ingreso al sistema, si condición 4=OK, la acción ingreso al sistema=SI, etc.)
        
        Identificar cada columna como una regla diferente (R1 y R2)
        
        Diseñar los casos de prueba
        6.1 Cada regla es un caso de prueba
        6.2 Eliminar reglas imposibles (irreales, sin condiciones en ambiente de prueba)
        6.3 Combinar con otras técnicas de CE y VF
        6.4 Identificar qué reglas pueden unificarse, combinarse o eliminarse.
    - - Elementos del diagrama de transición de estados:
        
        Nodo: Estados
        --Nodo terminal (un punto o raya doble)
        
        Transición: un evento y una acción. Ir de un estado 1 a un estado 2.
        Representarlo como un grafo
        Proceso de aplicación de la técnica:
        
        Identificar los nodos (estados) del objeto. (Ejemplo: Estado de una tarea: Estado 1: creada, Estado 2: asignada, Estado 3: cancelada)
        1.1 Nodos, verbo en participio (rechazado, postergado)
        
        Identificar las transiciones entre los estados (línea del estado 1 al 2 y del 1 al 3)
        2.1 Evento y acción que se dispara (En el ejemplo el estado 2, lleva a un estado 4: en proceso y el estado 3 es una acción terminal)
        
        Diseñar casos de prueba
        3.1 Casos positivos (transiciones válidas) Ejemplo: Caso 1: Estado 1, estado 2. Caso 2: Estado 1, estado 3 (en forma de tabla)
        3.2 Casos negativos (transiciones no válidas) Ejemplo: Caso 3: Estado 1, Estado 4, no es válido porque no puede pasar de creada o en proceso directamente.
  - - - % de las sentencias que realmente se están ejecutando.
        Objetivo de esta técnica: Lograr una cobertura específica de todas las sentencias.
        Cuántos casos de prueba se requieren para lograr la cobertura del 100% de las sentencias.
        Cobertura Cs=(Número de sentencias visitadas/número total de sentencias)*100
    - - Pruebas las decisiones en el código y el código que se ejecuta basado en los resultados de la decisión.
        Objetivo: Lograr una cobertura de todas las decisiones.
        Se concentra en los flujos de control (las aristas en el grafo del flujo de control)
        un caso de prueba para un if-verdadero y otro para un if-falso
        Cobertura Cr=(Número de ramas visitadas/número total de ramas)*100
- - - - Grados de independencia
        
        No hay independientes, el desarrollador prueba su código.
        
        Probadores dentro del equipo de desarrollo
        
        Equipo de prueba independiente dentro de la organización (reporta a la Dir. del proyecto o a la Dir. Ejecutiva)
        
        Probadores especialistas en tipos de pruebas específicos dentro de la organización.
        
        Probadores independientes externos a la organización ya sea por internalización o por externalización (p.e. pruebas de intrusión para la seguridad informática)
      - Beneficios
        
        Los probadores externos pueden reconocer diferentes tipos de fallos en comparación con los desarrolladores, debido a sus diferentes contextos, perspectivas técnicas y sesgos.
        
        Un probador independiente puede verificar, cuestionar o refutar suposiciones hechas durante la especificación e implementación del sistema.
      - Desventajas
        
        Aislamiento con respecto al equipo de desarrollo, falta de colaboración, relaciones de confrontación con desarrollo.
        
        Desarrollo puede perder el sentido de responsabilidad con respecto a la calidad.
        
        Los probadores independientes pueden verse como cuellos de botella en el proceso.
        
        Los probadores independientes pueden carecer de información importante.
    - - Jefe de pruebas: Asume la responsabilidad general del proceso de prueba.
        Tareas habituales:
        
        Política de prueba y estrategia de prueba
        
        Planificar las actividades de prueba: enfoque, estimación de tiempos, esfuerzo y costos, gestión de recursos, definición de niveles y ciclos de prueba, planificación y gestión de defectos.
        
        Política de prueba y estrategia de prueba.
        
        Planificar las actividades de prueba: enfoque, estimación de tiempos, esfuerzo y costos, gestión de recursos, definición de niveles y ciclos de prueba, planificación y gestión de defectos.
        
        Elaborar planes de prueba
        
        Coordinar los planes de prueba con los jefes de proyecto.
        
        Compartir perspectivas con respecto a las pruebas con otras actividades del proyecto.
        
        Iniciar el análisis, diseño, implementación y ejecución de pruebas.
        
        Monitorización de los avances y los resultados de la prueba y comprobar el estado de los criterios de salida.
        
        Preparar y entregar informes de avance de la prueba
      - Probador (tester)
        Tareas habituales
        
        Revisar y contribuir con los planes de prueba
        
        Analizar, revisar y evaluar la base de prueba.
        
        Identificar y documentar las condiciones de prueba y capturar la trazabilidad entre los casos de prueba, las condiciones y la base de prueba.
        
        Diseñar, preparar y verificar los entornos de prueba.
        
        Diseñar e implementar casos de prueba y procedimientos de prueba.
        
        Preparar y obtener datos de prueba.
        
        Crear calendario de ejecución de pruebas detallado.
        
        Ejecutar pruebas, evaluar resultados y documentar desviaciones de los resultados esperados.
        
        Utilizar herramientas apropiadas para facilitar el proceso de prueba.
        
        Automatizar las pruebas según sea necesario.
        
        Evaluar características no funcionales (eficiencia de desempeño, fiabilidad, usabilidad, seguridad, compatibilidad y portabilidad).
        
        Revisar pruebas desarrolladas por otros.
        Existe especialización de analistas de pruebas en tipos específicos de pruebas (automatizadores, p.e.)
        Pruebas de componente e integración de componente: Desarrolladores.
        Pruebas de aceptación: Analistas de negocio y expertos en la materia y usuarios finales.
        Pruebas de sistema y de integración: Equipo de prueba independiente.
        Prueba de aceptación operativa: Personal de operaciones o administración de sistemas.
- - - - 6.2.1 Principios básicos para la selección de herramientas:
        
        Evaluación de la madurez de los procesos de la organización
        
        Identificar oportunidades de mejora del proceso
        
        Comprender tecnologías actuales para seleccionar una herramienta compatible.
        
        Asegurar compatibilidad con herramientas de compilación e integración continua actuales.
        
        Requisitos claros y criterios objetivos.
        
        Herramientas con periodos de prueba gratuitos
        
        Evaluar al proveedor
        
        Requisitos internos de entrenamiento y asesoramiento
        
        Pros y contras de diferentes modelos de licenciamiento
        
        Relación costo-beneficio
        
        Considerar una prueba de concepto y compatibilidad con la infraestructura actual
      - 6.2.2 Proyecto piloto para introducir la herramienta a la organización
        Objetivos:
        
        Conocimiento profundo de la herramienta
        
        Compatibilidad de la herramienta con los procesos y prácticas existentes.
        
        Establecer las formas estándar de uso, administración y mantenimiento.
        
        Definir métricas que se desea que la herramienta recopile e informe.
      - 6.2.3 Factores de éxito para herramientas
        
        Despliegue de forma incremental
        
        Adaptar y mejorar procesos a la herramienta
        
        Formación, entrenamiento y asesoramiento para los usuarios
        
        Definir directrices de uso de la herramienta
        
        Definir forma de recopilar información del uso real de la herramienta
        
        Monitorizar el uso y los beneficios de la herramienta
        
        Apoyo a los usuarios
        
        Recopilar lecciones aprendidas de los usuarios
        
        Que la herramienta se integre en el ciclo de vida del desarrollo del software, implicando participación de terceros.