Tema 3: Pruebas Estáticas y Dinámicas

* De este tema saldrán unas 3 preguntas aprox.

---

---

Conceptos Básicos

• Introducción:
  
  • Revisiones ,evaluación manual de los productos de trabajo
  • Análisis Estático, evualuación basada en herramientas del código
• Productos de Trabajo que pueden ser evaluadas por pruebas estáticas:
  
  • Especificaciones, incluidos requisitos funcionales y requisitos de seguridad
  • Épicas , historias de usuarios y criterios de aceptación
  • Especificaciones de arquitectura y diseño
  • Código
  • Contratos , planes de proyecto calendarios y presupuestos
• Ventajas de la Prueba Estática
  
  • Detección y correción de defectos de forma más eficiente y antes de la ejecución de la prueba dinámica
  • Identificar defectos que no se encuentran fácilmente mediante prueba dinámica
  • Incrementar la productividad de desarrollo
  • Reducir el coste y el tiempo de la prueba
• Diferencias entre la Prueba Estática y Dinámica:
  
  
  • La Prueba Estática detecta defectos en los productos de trabajo directamente en lugar de identificar los fallos
  • Defectos típicos:
    
    • Defectos de los requisitos
    • Defectos de Diseño
    • Defectos de codificación
    • Desviaciones con respecto a los estándares
    • Vulnerabilidades de seguridad

• Pruebas dinámicas:, son aquellas que se realizan mientras el código está en ejecución. Tienen como objetivo asegurar que el software se comporte de acuerdo con los requerimientos del negocio mediante la realización de pruebas funcionales y no funcionales.
  Estas pruebas se enfocan en la detección y confirmación de la corrección de defectos en el software. Por lo general se realizan en una etapa más tardía que las pruebas estáticas, por lo cual, los defectos encontrados en estas son más costosos.
• Pruebas estáticas:, A diferencia de las pruebas dinámicas, estas no requieren de la ejecución de software para ser realizadas. Parte del objetivo de las pruebas estáticas es la revisión de productos de trabajo como documentos de requerimientos, casos de prueba, planes de prueba, código, guías de usuario.
  Estas pruebas se enfocan en la prevención de defectos y en la detección temprana de los mismos, ya que se pueden realizar en cualquier etapa del ciclo de vida de software según la información que se tenga disponible.

Técnicas que se utilizan: Revisión informal, Revisión técnica, Revisión guiada, Inspección, Revisión de código

---

Proceso de Revisión

• Proceso de revisión de Productos de Trabajo:
  
  • Planificación
  • Iniciar Revisión
  • Revisión Individual (es decir, preparación individual)
  • Comunicación y Análisis de Cuestiones
  • Corregir e Informar
• Roles y Responsabilidades en una revisión formal:
  
  • Autor
  • Dirección
  • Facilitador (a menudo llamado moderador)
  • Líder de Revisión
  • Revisores
• Tipos de Revisión:
  
  • Revisión Informal(revisión de pares, utilizado con mucha frecuencia en Desarrollo Agile)
  • Revisión Guiada, como objetivos principales tiene detectar defectos, mejorar el producto software, considerar implementaciones alternativas
  • Revisiones Técnicas, los revisores deben ser pares técnicos del autor y expertos técnicos en la misma u otra disciplina
  • Inspección
• Aplicación de Técnicas de revisión:
  
  • AD Hoc, los revisores reciben poca o ninguna orientación sobre como se debe realizar esta
  • Basada en la Lista de Comprobación
  • Escenarios y ensayos , los revisores reciben pautas estructuradas
  • Basada en Roles , los revisores evaluán el producto de trabajo desde la perspectiva de roles individuales
  • Basada en Perspectiva, los revisores adoptan los diferentes puintos de vista
• Factores de Éxito para las revisiones:
  
  • Cada revisión tiene objetivos claros, definidos durante la planificación de la revisión y utilizados como criterio de salida
  • Se involucra a las personas adecuadas para alcanzar los objetivos de la revisión
  • Los probadores son vistos como revisores valiosos que contribuyen a la revisión
  • Los participantes dedican tiempo ya atención adecuados a los detalles

Tema 4: Técnicas de prueba

* De este tema saldrán unas 14 preguntas aprox.

---

---

Categorías de Técnicas de Pruebas

• Elección de Técnicas de Prueba:
  
  • Factores:
    
    • Tipo de componente o sistema
    • Complejidad del componente
    • Estándares de regulación
    • Niveles de Riesgo
    • Documentación disponible
    • Herramientas disponibles
    • Modelo de ciclo de vida de desarrollo de software implementado
• Categorías de Técnicas de Prueba y sus características:
  
  • Técnicas de prueba de caja negra (pruebas funcionales):
    
    • Base de prueba: Especificaciones, Requisitos del Software, Casos de uso, Historias de usuario.
    • La cobertura se mide en función de los elementos probados en la base de prueba y de la técnica aplicada a la base de prueba.
  ,
  • Técnicas de prueba de caja blanca (pruebas no funcionales):
    
    • Base de Prueba : Código, La arquitectura de software, Cualquier otra fuente de información
    • La cobertura se mide en base a los elementos probados dentro de una estructura seleccionada
  ,
  • Técnicas de prueba basadas en la experiencia:
    
    • Serían los conocimientos , experiencia de los probadores , testers, usuarios, desarrolladores y otros implicados
  -

---

Técnicas de diseño de caso de pruebas de Caja Negra




TÉCNICA PARTICIÓN DE EQUIVALENCIA





Se trata de una técnica que prueba por particiones, (ver la imagen de arriba).



• Divide los datos en particiones
• Existen particiones de equivalencia tanto para valores válidos como no válidos
• La cobertura se mide como el número de particiones de equivalencia probadas por al menos un valor y dividido / número total de particiones de equivalencia



TÉCNICA DE ANÁLISIS EN VALORES FRONTERAS(AVF)




• Es una extensión de la partición de la equivalencia
• Sólo si la partición consiste en datos numéricos o secuenciales
• Los valores mínimo y máximo de una partición son sus valores frontera
• El comportamiento en las fronteras de las particiones de equivalencia es más probable que sea incorrecto que el comportamiento dentro de las particiones
• La cobertura de frontera para una partición se mide como el número de valores frontera probados, dividido por el número total de valores frontera de prueba identificados, normalmente expresado como un porcentaje



TÉCNICA DE TABLA DE DECISIÓN




• Útiles para probar la implementación de requisitos de sistema que especifican cómo diferentes combinaciones de condiciones generan diferentes resultados
• Buena manera de documentar reglas de negocio complejas que un sistema debe implementar
• El probador identifica las condiciones (a menudo entradas) y las acciones resultantes ( a menudo salidas)
• Una tabla de decisión completa tiene suficientes columnas para cubrir cada combinación de condiciones
• La tabla se puede colapsar
• Cobertura: % del 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



TÉCNICA DE TRANSICIÓN DE ESTADO (bastante usada)





• Elementos:
  
  • Estado: respuesta diferente de un componente o sistema a un evento
  • Transición: se inicia con un evento
  • Evento:ejemplo, la entrada de un valor por parte del usuario en un campo
  • Acción: ejemplo, emitir el resultado de un cálculo o un mensaje de error
• Es importante crear un diagrama de transición de estado (lo suelen hacer los Business Analyst, aunque tb lo pueden hacer los QA), muestra:
  
  • Los posibles estados del software
  • La forma en que el software entra, sale y realiza las transacciones entre estados
• También se crea una tabla de transición de estado, muestra:
  
  • Todas las transiciones válidas
  • Las transiciones potencialmente inválidas entre estados
  • Los eventos
  • Condiciones de guarda
  • Las acciones resultantes para las transiciones válidas
  
  Ejemplo tabla de transición de estado:
  
  
  
• Diseño de Pruebas:
  
  • Para cubrir una secuencia de estados típica
  • Para practicar todos los estados
  • Para practicar cada transición
  • Para practicar secuencias específicas de transiciones
  • Para probar transiciones inválidas
• Utilización:
  
  • Aplicaciones basadas en menús
  • Industria del software embebido
  • Modelar un escenario de negocio con estados específicos
  • Probar la navegación en pantalla
  • Cobertura: % del número de estados o transiciones identificados probados, dividido por el número total de estados o transiciones identificados en el objeto de prueba



TÉCNICA DE CASO DE USO






---

Técnicas de diseño de caso de pruebas de Caja Blanca




Recordar que son técnicas en las que se hace pruebas con el código (pruebas no funcionales)




TÉCNICA COBERTURA DE SENTENCIA




Se validan o se depuran las sentencias de código





TÉCNICA COBERTURA DE DECISIÓN




• Practica las decisiones en el código y prueba el código que se ejecuta basado en los resultados de la decisión
• Los casos de prueba siguen los flujos de control que se producen desde un punto de decisión, en este caso en el ejemplo sería validar esto:
  
  
• Cobertura : % del número de resultados de decisión ejecutados por las pruebas dividido por el número total de resultados de decisión en el objeto de prueba
  
  



Técnicas de prueba basadas en la Experiencia



• Predicción de Errores:
  
  • Utilizada para anticipar la ocurrencia de errores , defectos y fallos , basada en el conocimiento del probadores
  • Las pruebas se diseñan en base a una lista creada de posibles errores, defectos y fallos
• Prueba Exploratoria:
  
  • Se diseñan, ejecutan, registran y evalúan de forma dinámica pruebas informales (no predefinidas) durante la ejecución de la prueba.
  • Se utiliza la prueba basada en sesiones para estructurar la actividad.
  • Puede incorporar el uso de otras técnicas de caja negra, caja blanca y basadas en la experiencia.
• Prueba Basada en Listas de Comprobación:
  
  • Los probadores diseñan , implementan y ejecutan pruebas para cubrir las condiciones de prueba que se encuentran en una lista de comprobación.
  • Las listas de comprobación pueden elaborarse basándose en la experiencia.
  • Dan soporte pruebas funcionales y no funcionales.
  • Proporciona directrices y un cierto grado de consistencia a falta de casos de prueba. (se suele utilizar un checklist)



TIPOS DE PREGUNTAS

Tema 5: Gestión de la prueba

*De aquí saldrán unas 9 o 10 preguntas*

---

INDEPENDENCIA DE LAS PRUEBAS

La independencia de las pruebas dependerá del modelo de desarrollo que se esté usando en la empresa, Independencia de pruebas es la separación de responsabilidades, que fomenta la realización de pruebas objetivas.

Tipos de Testers o probadores:

1. Probadores independientes externos a la organización
2. Probadores no independientes
3. Desarrolladores independientes o probadores dentro de los equipos de desarrollo
4. Equipo o grupo de prueba independiente dentro de la organización
5. Equipos de prueba que están fuera de la organización:
   • Beneficios de los probadores independientes:
     • Los probadores independientes reconocen 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 las suposiciones hechas por los implicados durante la especificación e implementación del sistema.
   • Desventajas de los probadores independientes:
     • Los desarrolladores pueden perder el sentido de la responsabilidad con respecto a la calidad del producto.
     • Los probadores independientes pueden ser vistos como un cuello de botella o ser culpados por los retrasos del lanzamiento o liberación.

TAREAS DE UN TEST LEADER Y UN TESTER

Test Leader

• Desarrollar las competencias y las carreras profesionales de los probadores
• Apoyar la selección e implementación de herramientas para dar soporte al proceso de prueba, incluyendo la recomendación del presupuesto para la selección de herramientas, la asignación de tiempo y esfuerzo para los proyectos piloto y la provisión de un soporte continuo en el uso de la herramienta o herramientas.
• Introducir métricas adecuadas para medir el avance de la prueba y evaluar la calidad de la prueba y del producto.
• Preparar y entregar informes de avance de la prueba e informes de resumen de prueba.
• Redactar y actualizar el/los plan(es) de prueba
• Planificar las actividades de la prueba considerando el contexto y entendiendo los objetivos y riesgos de la prueba
• Desarrollar o revisar una política de prueba y una estrategia de prueba para la organización

Tester

• Revisar y contribuir a los planes de prueba.
• Analizar , revisar y evaluar la base de pruebas: los requisitos, historias de usuario y criterios de aceptación, especificaciones y modelos para la capacidad de ser probados.
• Identificar y documentar las condiciones de prueba y capturar la trazabilidad entre los casos de prueba , las condiciones de prueba y la base de prueba.
• Diseñar, preparar y verificar los entornos de prueba a menudo en coordinación con las áreas de administración de sistemas y gestión de redes.
• Preparar y obtener datos de prueba
• Ejecutar pruebas, evaluar los resultados y documentar los desviaciones de los resultados esperados.
• Automatizar las pruebas según sea necesario
• Evaluar características no funcionales tales como eficiencia de desempeño , fiabilidad , usabilidad , seguridad, compatibilidad y portabilidad

PLANIFICACIÓN Y ESTIMACIÓN DE LA PRUEBA

PROPÓSITO Y CONTENIDO DE UN PLAN DE PRUEBA

• Determinar el alcance, los objetivos y los riegos de la prueba
• Definir el enfoque general de la prueba
• Integrar y coordinar las actividades de prueba en las actividades del ciclo de vida del software
• Tomar decisiones sobre lo que se va a probar, las personas y otros recursos necesarios para realizar las diversas actividades de prueba y cómo se llevarán a cabo las actividades de prueba
• Establecer un calendario para las actividades de análisis , diseño, implementación, ejecución y evaluación de la prueba, ya sea en fechas particulares o en el contexto de cada iteración
• Selección de métricas para monitorizar y controlar la prueba
• Determinar el nivel de detalle y la estructura de la documentación de la prueba (por ejemplo, proporcionando plantillas o documentos de ejemplo

ESTRATEGIAS Y ENFOQUES DE LA PRUEBA

Analítica

Las pruebas se analizan en función de los requisitos o en función del nivel de riesgo

Basada en Modelos:

Las pruebas se diseñan basándose en algún modelo de algún aspecto requerido del producto:

• Modelo de Proceso de Negocio
• Modelo de Estado
• Modelo de Crecimiento de fiabilidad

Metódica:

Se basa en el uso sistemático de un cojunto predefinido de pruebas o condiciones de pruebas

---

LISTA DE CARACTERÍSTICAS DE CALIDAD IMPORTANTES:

Conforme a proceso

Implica el análisis , diseño e implementación de pruebas basadas en reglas y estándares externos:

• Estándares específicos de la industria
• Documentación de procesos
• Proceso, frameworks o estándar impuesto por la organización

Dirigida (o consultiva):

Se basa principalmente en el asesoramiento, la orientación o las instrucciones de implicados fuera del equipo de pruebas:

• Expertos en el dominio del negocio
• Expertos en tecnología

Adversa a la regresión:

• Adversa a la regresión, estrategia motivada por el deseo de evitar la regresión de las capacidades existentes
• Reutilización de productos de prueba existentes
• Automatización extensiva de las pruebas

Reactiva:

Las pruebas se diseñan en respuesta al conocimiento obtenido de los resultados de prueba anteriores, Uso de pruebas exploratorias.

---

CRITERIOS DE ENTRADA Y CRITERIOS DE SALIDA (DoD y DoR)

Criterios de entrada habituales:

• Disponibilidad de requisitos, historias de usuarios y/o modelos
• Disponibilidad de elementos de prueba que han cumplido los criterios de salida para cualquiera de los niveles de prueba anteriores
• Disponibilidad del entorno de pruebas
• Disponibilidad de las herramientas de prueba necesarias
• Disponibilidad de datos de prueba y otros recursos necesarios

Criterios de salida habituales:

• Las pruebas planificadas han sido ejecutadas
• Se ha logrado un nivel de cobertura definido
• El número de defectos no resueltos se encuentra dentro de un límite acordado

---

CALENDARIO DE EJECUCIÓN DE PRUEBA

• Los diversos casos de prueba y procedimientos de prueba han sido desarrollados y agrupados en juegos de prueba (test suites)
• Los juegos de prueba (test suites) pueden organizarse en un calendario de ejecución de prueba que define el orden en el que deben ejecutarse
• Factores a tener en cuenta :
  
  • Priorización
  • Dependencias
  • Pruebas de confirmación
  • Pruebas de regresión
  • Secuencia más eficaz para ejecutar las pruebas

FACTORES QUE INFLUYEN EN EL ESFUERZO DE LA PRUEBA

Características del Producto

• Los riesgos asociados al producto
• La calidad de la base de prueba
• El tamaño del productos
• La complejidad del dominio del productos
• Los requisitos para las características de calidad

Características del Proceso de Desarrollo:

• La estabilidad y madurez de la organización
• El modelo de desarrollo en uso
• El enfoque de la prueba
• Las herramientas utilizadas
• El proceso de prueba
• Presión con respecto al tiempo

Características de las personas:

• Las competencias y la experiencia de las personas involucradas, especialmente con proyectos y productos similares
• Cohesión y liderazgo de equipo

Resultados de la prueba:

• El número y la severidad de los defectos detectados
• La cantidad de reconstrucción necesaria

TÉCNICAS DE ESTIMACIÓN DE LA PRUEBA

• Técnica basada en métricas(Cascada): estimación del esfuerzo de prueba basada en métricas de proyectos similares, anteriores o en valores típicos.
• Técnica basada en expertos(Agile): estimación del esfuerzo de la prueba basándose en la experiencia de los propietarios de las tareas de prueba o por expertos.

MONITORIZACIÓN Y CONTROL DE LA PRUEBA

Métricas utilizadas en la prueba,¿Qué Evalúan?

• Avance con respecto al calendario y presupuesto previos
• Calidad actual del objeto de prueba
• Adecuación del enfoque de prueba
• Eficacia de las actividades de prueba con respecto a los objetivos

Métricas comunes

• Porcentaje de trabajo planificado realizado en la preparación de los casos de prueba
• Porcentaje de trabajo planificado realizado en la preparación del entorno de prueba
• Ejecución de casos de prueba
• Información sobre defectos
• Cobertura de prueba con respecto a requisitos, historias de usuarios , criterios de aceptación, riesgos o código
• El coste de la prueba

• Informe de Prueba
  • Objetivo:
  • Resumir y comunicar la información de la actividad de prueba, tanto durante como al final de un actividad de prueba
• Informe de Avance
  • El estado de las actividades de prueba y el avance con respecto al plan de prueba
  • Factores que impiden el avance
  • Pruebas previstas para el próximo periodo objeto de informes
  • La calidad del objeto de prueba
• Informe de Resumen
  • Resumen de la prueba realizada
  • Información sobre lo ocurrido durante un periodo de prueba
  • Desviaciones con respecto al plan
  • Estado de la prueba y calidad del producto con respecto a los criterios de salida o definición de hecho
  • Métricas de defectos, casos de prueba, cobertura de la prueba, avance de la actividad y consumo de recursos

GESTIÓN DE LA CONFIGURACIÓN

• Objetivo:

Establecer y mantener la integridad del componente o sistema, los productos de prueba y sus relaciones entre sí a lo largo del ciclo de vida del proyecto y del producto.

• Asegurarse de:

• Todos los elementos de prueba
• Todos los elementos de productos de prueba (testware)
• Todos los documentos y elementos software identificados están referenciados de forma inequívoca en la documentación de la prueba

GESTIÓN DE RIESGOS

Riesgos de Producto y de Proyecto

• Riesgos de producto

• Posibilidad de que un producto de trabajo pueda no satisfacer las necesidades legítimas de sus usuarios y/o implicados
• Ejemplos:
  • El software podría no realizar las funciones previstas de acuerdo con la especificación
  • El software puede no realizar las funciones previstas de acuerdo con las necesidades de los usuarios, clientes o implicados
  • Una arquitectura de sistema puede no soportar de forma adecuada algunos requisitos no funcionales
  • Tiempo de respuesta lentos para un sistema de alto rendimiento

• Riesgos de proyecto (Jefes de proyecto)

• Implica situaciones que en caso que ocurran pueden tener un efecto negativo en la capacidad de lograr los objetivos
• Ejemplos:
  • Retrasos en la entrega
  • Estimaciones inadecuadas
  • Personal no capacitado
  • Disponibilidad de recursos
  • Requisitos mal elaborados
  • Ambiente no listo
  • Mala gestión de defectos

---

• La prueba basada en el Riesgo y en la Calidad de Producto:

Basada en riesgos:

• Se usa para priorizar las pruebas, donde y cuando empezar
• Qué áreas necesitan más atención
• Determinar los niveles y tipos de pruebas a realizar

Mitigar los riesgos:

• Implementar acciones para mitigar los riesgos
• Elaborar planes de contingencia

---

GESTIÓN DE LOS DEFECTOS

• Objetivo:

• Proporcionar a los desarrolladores y otras partes información sobre cualquier evento adverso que haya ocurrido
• Proporcionar a los jefes de prueba un medio para hacer un seguimiento de la calidad del producto de trabajo y del impacto en la prueba
• Proporcionar ideas para la mejora de los procesos de desarrollo y prueba

• Contenido de un Informe de Defecto:

• Un identificador
• Un título y un breve resumen del defecto que se está informando
• Fecha del informe de defecto, organización emisora y autor
• La(s) fase(s) del ciclo de vida de desarrollo en la (s) que se observó el defecto
• Una descripción del defecto para permitir la reproducción y resolución
• Resultados esperados y reales
• Alcance o grado de impacto (severidad) del defecto
• Urgencia/prioridad de la corrección
• Estado del informe de defectos
• Conclusiones, recomendaciones y aprobaciones
• Cuestiones generales, tales como otras áreas que pueden verse afectadas por un cambio resultante del defecto.
• Referencias, incluyendo el caso de prueba que puso en evidencia el problema

Tema 6: Soporte de Herramientas en el proceso de pruebas

---

---

Clasificación de las Herramientas de Prueba

• Objetivos Posibles:
  
  • Mejorar la eficiencia de las actividades de prueba
  • Mejorar la calidad de las actividades de prueba
  • Automatizar actividades que no se pueden ejecutar manualmente
• Soporte de Herramientas para la Gestión de la Prueba y Productos de Prueba:
  
  • Herramientas de gestión de prueba y herramientas de gestión del ciclo de vida de las aplicaciones (JIRA, Azure DevOps)
  • Herramientas de gestión de requisitos
  • Herramientas de gestión de defectos (Mantis. BugZilla)
  • Herramientas de gestión de la configuración (parecidas a JIRA, Azure)
  • Herramientas de integración continua (Jenkins, Bamboo, Octopus, Azure DevOps...etc)
• Soporte de Herramientas para la Prueba Estática:
  
  • Herramienta de apoyo a las revisiones
  • Herramientas de análisis estático (SonarQube, Raxis,Embold, PVS..etc)
• Soporte de Herramientas para la Medición del Rendimiento y el Análisis Dinámico:
  
  • Herramientas para la prueba de rendimiento
  • Herramientas de monitorización(JMeter, SOAP UI, WebLoad..etc)
• Soporte de Herramientas para Necesidades de Prueba Especializadas:
  
  • Evaluación de la calidad de los datos
  • Conversión y migración de datos
  • Prueba de usabilidad (Userlytics, Lockback, Hotjar..etc)
  • Prueba de seguridad (Burp Suite, OWASP, NETSPARKER..etc)
  • Prueba de portabilidad

---

Uso eficaz de las Herramientas

• Principios Básicos para la Selección de Herramientas:
  
  • Evaluación de la madurez de la organización, sus fortalezas y debilidades
  • Identificar oportunidades para un proceso de prueba mejorado con el soporte de herramientas
  • Comprender las tecnologías utilizadas por el objeto u objetos de prueba con el fin de seleccionar una herramienta que sea compatible con dicha tecnología
  • Las herramientas de compilación e integración continua ya en uso dentro de la organización, con el fin de asegurar la compatibilidad e integración de las herramientas
  • Tener en cuenta si la herramienta está disponible durante un periodo de prueba gratuito
  • Evaluar al proveedor o soporte para herramientas no comerciales
  • Identificar los requisitos internos para el entrenamiento y asesoramiento en el uso de la herramienta
  • Evaluar las necesidades de formación, teniendo en cuenta las competencias en materia de prueba (y automatización de la prueba) de quienes trabajarán directamente con la(s) herramienta(s)
• Proyectos Piloto para introducir una Herramienta en una organización:
  
  • Objetivos:
    
    • Evaluar como encaja la herramienta con los procesos y prácticas existentes y determinar qué se necesita cambiar
    • Decidir sobre las formas estándar de usar, administrar, alamacenar y mantener la herramienta y los activos de prueba
    • Evaluar si los beneficios se lograrán a un coste razonable
    • Comprender las métricas que se desea que la herramienta recopile e informe
• Factores de Éxito para Herramientas:
  
  • Despliegue de la herramienta al resto de la organización de forma incremental
  • Adaptar y mejorar los procesos para que se ajusten al uso de la herramientas
  • Entrenamiento
  • Definición de directrices para el uso
  • Monitorear el uso
  • Proporcionar apoyo a usuarios