ISTQB CTAL Test Manager

Anmerkungen:

• - Planificación y control de pruebas - Análisis de pruebas - Diseño de pruebas - Implementación de pruebas - Ejecución de pruebas - Evaluación de los criterios de salida y generación de informes - Actividades de cierre de pruebas

1. Consta de los procesos mencionados en la nota, estos fueron separados para dar mayor detalle a la información a diferencia de CTFL
   1. 1.2) El control: es transversal durante todo el proceso de prueba y permite generar información para involucrados, ayuda a determinar tiempo, recursos, alcance objetivos y actividades (los cuales deben estar planteados en el Plan de pruebas)

      Anmerkungen:

      • Durante el seguimiento se debe comprobar: - Avance real VS mediciones - Consecuencias También se debe: - Iniciar medidas correctivas con la toma de decisiones
      1. Puntos a considerar para planificar: Estrategia y alcance, riesgos, claridad de bases, productos de trabajo, necesidades, y tipo de organización

         Anmerkungen:

         • Sería ideal utilizar una de las siguientes estrategias para cada nivel: - Preventiva - Reactiva - Analítica (orientada al riesgo) - Orientada a modelo (modelo de datos) - Basada en métodos (atributos de calidad) - Conforme a procesos (ISO, IEEE) - Dinámica heurística (conocimiento propio) - Asesoramiento (con usuario)
         1. ¿Qué se debe comprobar durante el seguimiento de las pruebas?

            Anmerkungen:

            • - Avance real VS Mediciones - Consecuencias  Con los resultados se deben tomar decisiones y medidas correctivas
            1. 1.3) ¿Qué se debe hacer durante el Análisis de prueba?

               Anmerkungen:

               • - Identificar condiciones de prueba - Validar las bases de prueba disponibles - Validar que el presupuesto y calendario sean acordes - Si no existen bases de pruebas se deben programar entrevistas y talleres - Comenzar con definición a un alto nivel e ir profundizando  - Pruebas de componente e integración deben ser mas técnicas - Pruebas de sistema y aceptación deben ser dinámicas y orientadas a negocio (Idealmente se debe definir nivel de desarrollo y validar madurez de la organización)
               1. 1.4) Consideraciones del Diseño de pruebas
                  1. A partir de las bases de pruebas y el nivel donde se ejecutarán se debe seleccionar la técnica de diseño, se deben considerar pruebas sin guión y enfocar casos faciles de comprender, estos deben cubrir todas las interacciones de interfaces y tener criterios de paso o fallo bien definidos

                     Anmerkungen:

                     • Caso de prueba según IEEE 829 - id - Elementos de pruebas - Precondiciones - Valores de entrada - Resultados esperados - Pos condiciones - Relación a otros casos - Referencia al requisito que lo origina - Condiciones de entorno
                     • - Los casos se definen con las bases de prueba, si no esta claro se debe aclarar, nada debe quedar supuesto.  - Tener en cuenta el testware necesario  - A los casos se les debería agregar prioridad y riesgo.
                     1. Técnicas de diseño de pruebas (Caja blanca, Caja negra)

                        Anmerkungen:

                        • Caja Blanca: - Sentencia - Rama - Condición - Bucle  - Camino
                        • Caja Negra: - Partición de equivalencia - Valores limites - Tabla de decisión - Diagrama de transición de estado - Arreglos ortogonales - Casos de uso - Causa y efecto - Árbol de clasificación - Tablas de todos los pares
                        1. 1.5) Lista de pasos para la completitud de la Implementación de pruebas

                           Anmerkungen:

                           • - Registrar pasos, resultado y ejecutor (testlog) - Ordenar casos según dependencia - Generar pruebas de regresión - Validar ambiente (escenario) - Validar Testware - Completar datos de pruebas - Cerrar calendario y estrategia - Revisar criterios de entrada y salida - Asegurarse que el equipo este preparado - Casos de prueba deben ser aprobados por el negocio - Validar el conocimiento de los estandares
                           1. 1.6) Ejecución de las pruebas, esta etapa comienza al recibir el objeto de pruebas, se deben ejecutar las pruebas anteriormente diseñadas registrando los resultados (pasado, fallado)
                              1. ¿Que debe hacer un TM durante esta etapa del proceso?

                                 Anmerkungen:

                                 • Debe: - Declarar el inicio - Monitorizar avance - Reaccionar a resultados - Reaccionar a cambios externos (El TM debe gestionar las incidencias) Es necesario asegurarse que: - El entorno sea lo mas parecido a producción - La versión debe ser la correcta - Haya asignado las tareas y sean entendidas por el equipo
                                 1. Estrategias de equipo

                                    Anmerkungen:

                                    • - Familiarizar a los probadores En este caso los probadores conocen todos los niveles desde análisis hasta automatización - Equipos especializados Cada miembro tiene un Rol definido Lo ideal es familiarizar al equipo con todas las tareas para ser un equipo integral
                                 2. Control de avance, gestión

                                    Anmerkungen:

                                    • - Validar si se ejecutaron los casos críticos - Validar si el ambiente esta correcto - Verificar que los datos fueron entregados - Registrar cuando se recibió la entrega
                                    • - Verificar si no están bien definidos - Tiempo de tomaría la corrección - Definir el problema del caso - Definir si es necesario y rentable automatizar  Equipos de prueba grandes necesitan apoyo de herramientas, de esta forma es mas fácil reaccionar cambiando prioridad, reasignando, solicitando recursos, etc. El TM debe poder reaccionar a cambios externos y solicitar cambios en la planificación
                                 3. Los Posibles estados de los casos son:

                                    Anmerkungen:

                                    • - Planificado - Especificado - Automatizado - Ejecutado - Descontiniuado
                                 4. Cobertura y Métricas

                                    Anmerkungen:

                                    • - Cantidad de casos ejecutados - ¿Qué falta por probar? - ¿Qué se necesita para culminar de cubrir las pruebas?
                                    • Posibles métricas - Defectos VS casos ejecutados - Defectos por tiempo de ejecución - Defectos por estado Nota: - Las zonas que contienen errores pueden contener mas y las zonas que no contengan errores posiblemente deban ser mejor revisadas.
                                 5. 1.7) Evaluación de los criterios de salida y generación de informes, el registro de informes ayuda a la revisión de las pruebas, en las revisiones se deben poder obtener los resultados individuales; dichos informes deben ser claros por que son dirigidos a todos los niveles del equipo, los informes pueden ser generados a diario, semanal o cuando sea necesario

                                    Anmerkungen:

                                    • - Los informes deben ser gráficos preferiblemente con colores (semáforo) - Se deben incluir métricas - Los criterios de salida deben ser claros (se puede acordar cierta flexibilidad en los criterios)
                                    1. Evidencia que debe contener

                                       Anmerkungen:

                                       • - Versión de software utilizado - Casos de prueba ejecutados - Componentes probados - Resultados
                                    2. Contenido de fallas

                                       Anmerkungen:

                                       • Defectos identificados por: - Mala especificación de requisitos - Data errada - Entorno defectuoso - Uso inadecuado de las herramientas - Error en la automatización
                                    3. Contenido del informe

                                       Anmerkungen:

                                       • - Contexto - Avance - Calidad del producto - Recursos y medidas correctivas - Riesgos - Presupuesto - Tiempo - Planificación adicional
                                    4. 1.8) Actividades de cierre de pruebas, se realizan para comprobar la completitud del proyecto, las actividades completadas deben ser informadas y las que fueron omitidas deben contener una explicación clara.

                                       Anmerkungen:

                                       • ¿Qué mas se debe hacer? - Informar defectos conocidos - Revisar completitud de la repetición de pruebas - Archivar el entorno para posibles mentenimientos  - Dar información en una retrospectiva sobre:  * Métricas * Estimación  * Tendencias * Puntos de mejora

1. Posibles implicados en el proceso tienen diferentes intereses, estos deben ser definidos

   Anmerkungen:

   • - Desarrolladores - Arquitectos - Analistas de negocio - Dirección - Soporte - Usuarios - JP
   1. 2.3) Pruebas basadas en riesgo y priorización
      1. ¿Qué se debe saber sobre los riesgos?

         Anmerkungen:

         • - Un riesgo es un problema que aún no ocurre - El valor del riesgo se calcula (Riesgo = Probabilidad X Impacto) - Los riesgos se deben documentar en el plan de pruebas - Existen 2 tipos de riesgo: De proyecto, los cuales afectan a los interesados, los mas típicos pueden ser: recursos, conocimiento, mala planificación, incumplimiento de plazos, baja calidad de entrega De producto, afectan a los clientes y usuarios, los mas típicos pueden ser: Fallos en el sistema, funcionalidad faltante, desviación de estandaresLos riesgos se evaluan cualitativa y cuantitativamente
         • Factores a tener en cuenta: - Los riesgos pueden deberse a la tecnología - Educación y conflictos en el equipo - Problemas contractuales - Distribución del equipo - Sistemas antiguos o nuevos - Mala organización o presión - Área QA inexistente - Frecuentes fallos y cambios
      2. ¿Cómo identificar un riesgo?

         Anmerkungen:

         • - En entrevistas con usuarios - Plantillas de riesgo - Lecciones aprendidas -  Talleres - Tormenta de ideas - Listas de comprobación
         • Una vez identificado el riesgo se debe:  - Identificar - Evaluar - Mitigar - Gestionar
      3. Principios básicos

         Anmerkungen:

         • - Las pruebas pueden tener una prioridad definida por riesgos. - Mientras mas personas se encuentren durante la revisión mas riesgos serán identificados - La probabilidad es mas alta donde ya se han encontrado defectos - Los riesgos pueden causar perdida de la reputación, procesamiento legal, perdida financiera, ecológica, social  - DO-178BD prescribe técnicas de cobertura basadas en el riesgo
         • Para evaluar los riesgos se debe tener en cuenta: - Prioridad - Impacto estimado - Clasificación (Alto,medio, bajo (ISO 9126-25000))
         1. Enfoques ligeros y pesados

            Anmerkungen:

            • Ligeros: - PRAM - PRIsMA - SST Si la percepción del riesgo varía un moderador se encarga de llegar a un acuerdo Los riesgos se pueden abordar con amplitud primero o profundidad primero
            • Pesados: - Análisis de peligro - Exposición al costo - AMFE (AMFEC - AFMSEC) - DFC
            1. Entradas y salidas de las técnicas basadas en riesgo

               Anmerkungen:

               • Entradas: - Percepción de implicados - Especificación - Experiencias - Listas de comprobación
               • Salidas: - Listas de riesgo (con niveles definidos) - Defectos y puntos débiles No deben quedar requisitos ambiguos, incompletos, implícitos o no testeables
               1. 2.4) Documentación de pruebas

                  Anmerkungen:

                  • La documentación esta compuesta por: - Política de prueba - Estrategia general - Plan maestro - Plan de nivel Niveles de prueba según POL 2000 (modelo anterior a ISTQB) -  Planificación y administración - Preparación - Especificación - Ejecución - Cierre
                  1. Estrategias de prueba

                     Anmerkungen:

                     • - Analítica - Basada en modelo - Metódica - Conforme a proceso - Reactiva - Adversa a regresión
                  2. Información por nivel

                     Anmerkungen:

                     • Planificación:  - Entorno de pruebas - Nivel de automatización - Recursos reutilizables - Estandares - Métricas - Roles
                     • Análisis y diseño: - Criterios de entrada y salida -  Técnicas de diseño a utilizar - Criterios de completitud
                     • Ejecución y documentación: - Grado de independencia - Enfoque para la repetición y regresión - Niveles de pruebas, documentación y gestión de incidentes
                  3. Plan de pruebas

                     Anmerkungen:

                     • Maestro: - 16 Aspectos ISTQB CTFL - ¿Qué elementos se probaran y cuales no? - Alcance y responsabilidades - Características a probar - Calendario y presupuesto - Implementación y ciclos planificados - Criterios de entrada y salida - Resultado de pruebas y métricas 
                     • Nivel: - Secuencia y acciones - Desviaciones - Orden de las actividades - Calendario, tareas e hitos - Interacción con actividades del proyecto
                     • Opciones para gestionar riesgos: - Reducir posibilidad de ocurrencia - Hacer planes de contingencia - Transferir el riesgo a terceros  - Aceptar o ignorar el riesgo
                     1. 2.5) Estimación de las pruebas

                        Anmerkungen:

                        • - Las estimaciones de prueba deben estimarse con % - Costos, esfuerzo y duración son lo mas importante a estimar - Las suposiciones no son confiables, en caso de permitir una se debe documentar
                        • Factores que influyen: - Nivel de calidad - Tamaño, complejidad del producto - Factores del proceso (madurez, mantenimiento, exactitud) - Factores materiales (Automatización, herramientas, bases de prueba) - Estandares - Complejidad de las entregas - Datos volátiles
                        1. Técnicas de estimación

                           Anmerkungen:

                           • - Intuición - Experiencias anteriores - EDT - Estimación de 2 ptos - Estimación de 3 ptos - Análisis de puntos de función - Sondeo de equipo - Métricas - Análisis de ramas, lineas de código Las estimaciones solo se perfeccionan con la experiencia
                           1. 2.6) Definición y uso de métricas, estas sirven para informar resultados, realizar seguimiento, informar de forma medible y validar el éxito de un proyecto, la información contenida en las métricas debe ser verificable

                              Anmerkungen:

                              • Según ISO 14598 - Métrica: es una escala de medición - Medida: Número o categoría a asignar
                              • - Las métricas se deben usar a lo largo de todo el proyecto y deben estar pautadas en la planificación
                              1. 5 áreas principales a medir

                                 Anmerkungen:

                                 • - Riesgos - Defectos - Pruebas - Cobertura - Confianza (medida subjetiva)
                                 1. 2.7) Valor de negocio de las pruebas, probar mucho o muy poco no aporta valor a las pruebas el TM debe acordar un punto intermedio, como TM debe saber "vender" a la directiva el valor cuantificable y cualificable de las pruebas

                                    Anmerkungen:

                                    • Cuantificable: - Defectos descubiertos y corregidos antes de la entrega - Riesgos reducidos - Información del avance
                                    • Cualificable: - Incremento en la calidad - Mejor previsión de fechas - Mejora en la calidad -  Mas confianza - Mayor seguridad laboral - Menor riesgo ambiental o perdida de vidas
                                    1. 2.8) Pruebas distribuidas, externalizadas o internalizadas

                                       Anmerkungen:

                                       • - Distribuidas: Pruebas realizadas con equipos en diferentes localizaciones - Externalizadas: Contratación de un equipo externo en otras dependencia - Internalizadas: Recurso o equipo ejerce en las dependencias de la empresa
                                       • Para estas pruebas se debe: - Definir comunicaciones claras y efectivas - Definir roles, tareas y objetivos   - Definir 1 metodología - Permitir confianza entre los involucrados Debilidades: - Diferencia de horario - Mala comunicación - No sentirse responsable - Derroche de recursos - Ataques por la espalda del equipo
                                       1. 2.9) Gestión de estandares

                                          Anmerkungen:

                                          • Existen estandares: - Internacionales (ISO) - Nacionales (DIN Alemania) - Específicos (US Federal aviation) - CMMI - ITIL - PMBOK - PRINCE 2 El TM debe conocer los estandares para validar cual necesita utilizar, algunas veces pueden existir inconvenientes al usar mas de uno, algunas veces es obligatorio usar cierto estandar.
                              2. Ejemplos de métricas

                                 Anmerkungen:

                                 • Riesgos: - Riesgos cubiertos en pruebas ejecutadas - Riesgos que presentaron fallas - Riesgos no probables
                                 • Defectos: - Número de defectos acumulados VS resueltos - Tiempo entre fallos - Cantidad de defectos por categorías  - Soluciones que generaron nuevos defectos
                                 • Pruebas: - Total de pruebas por estado - Tiempo previsto VS utilizado - Disponibilidad de entorno de pruebas
                                 • Cobertura: - Cobertura de riegos - Cobertura de código - Cobertura de requisitos
         2. Mitigación

            Anmerkungen:

            • - Preparar mitigación - Preparar contingencia - Transferir a terceros la responsabilidad - Aceptar o ignorar el riesgo
2. Para poder medir la calidad del producto durante el proceso de pruebas el TM debe comprender las actividades de otros implicados

   Anmerkungen:

   • - Gestión de los requisitos - Gestión de proyectos - Gestión de la configuración - Desarrollo - Soporte - Documentadores
3. Sin importar el modelos de desarrollo se deberían implementar pruebas, ejemplos:

   Anmerkungen:

   • - Secuenciales (V o Cascada) - Iterativos incrementales (RAD y RUP) - Ágil (SCRUM y XP) - Espiral
4. 2.2) ¿Qué se debe definir para cada nivel de pruebas?

   Anmerkungen:

   • - Objetivos y propósitos - Alcance - Bases de prueba - Criterios de entrada/salida - Entregables e informes - Métricas - Herramientas - Recursos - Responsabilidades
   • - Pruebas no funcionales: Las pruebas no funcionales normalmente son costosas, estas se pueden delegar a un analista de pruebas que por su conocimiento defina cuales se pueden hacer, no realizar este tipo de pruebas puede traer grandes problemas, dichas pruebas deberían realizarse en etapas tempranas - Las pruebas basadas en la experiencia:Tienen tanto ventajas como desventadas, los probadores deberían tener la posibilidad de hacer pruebas de este tipo en cada nivel, preferiblemente en bloques de 30 a 120 min, en caso de detectar errores se deben modificar los casos de prueba

Anmerkungen:

• - Revisiones en CTFL: Inspección formal, revisión guiada, revisión técnica, revisión. - Revisiones CTAL TM Revisión de gestión, auditoria
• Algunas revisiones normalmente realizadas. - Contractuales - Requisitos - Diseño - Código - Productos de trabajo

1. 3.2) Revisiones de Gestión y auditoría

   Anmerkungen:

   • Gestión, esta se usan para: - Monitorizar el avance - Evaluar por estado - Decidir futuras acciones Con esto se puede: - Adaptar nivel de recursos - Implementar correcciones  - Modificar alcance Estas tareas son llevadas por el TM quien debe tomar decisiones, comprobando adecuaciones, considerando riesgos, impacto y desviaciones. Debe generar listas de acciones a seguir y problemas a resolver
   • Las auditorias se utlizan para:  - Demostrar el uso de estandares - Proponer regulaciones - Cumplir obligaciones contractuales Estas son realizadas por un auditor en jefe para: - Generar documentación de resultados - Recopilar evidencia
   1. 3.3) Gestión de las revisiones

      Anmerkungen:

      • ¿Qué se debe definir? Estas se pueden realizar después de tener las especificaciones, se pueden hacer desde nivel de negocio hasta niveles mas detallados. ¿Qué debe ser revisado? ¿Quién debe estar involucrado? ¿Qué riesgos deben cubrirse?
      • Posibles causas de malas revisiones - Criterios de entrada/salida pobres - Mala composición del equipo  - Herramienta inadecuada - Experiencia insuficiente - Poca preparación individual
      • Para elaborar un de presupuesto de revisión se debe: - Determinar que se va a revisar y que tipo de revisión será - Incluir formación para futuras revisiones - Determinar un ROI  Puntos a considerar para una revisión: - Identificar revisores con conocimiento técnico - Identificar revisores de respaldo - Tener un equipo comprometido en la revisión - Crear listas de comprobación
      1. 3.4) Métricas para las revisiones

         Anmerkungen:

         • Se usan para validar ROI ejemplos: - Tamaño del producto a revisar - Tiempo de preparación - Tiempo de revisión - Tiempo de corrección - Número de revisores - Tiempo estimado ahorrado - Tiempo total de la revisión y número de defectos encontrados
         1. 3.5) Gestión de revisiones formales (5 fases)

            Anmerkungen:

            • Fases: - Planificación - Lanzamiento  - Kick Off - Preparación individual - Ejecución - Reconstrucción y seguimiento
            • Entregables: - Informes - Hojas de evaluación - Hojas de resumen de revisión Antes de iniciar la revisión se debe revisar que se cumplan los requisitos de no ser así se debe aplazar e informar Las revisiones deben generar métricas para entregar al alto nivel

Anmerkungen:

• - El TM debe planificar, verificar y ordenar defectos - Un defecto es un problema real que puede ser detectado con pruebas estáticas - Un fallo es un problema que se detecta con pruebas dinámicas 

1. 4.2) Ciclo de vida de un defecto

   Anmerkungen:

   • - Nuevo - Abierto - Análisis - Rechazado - Corrección - Resuelto - Reabierto - Cerrado
   • - Los defectos importantes se detectan primero gracias a la asignación de prioridades - En general estos informes son generados por herramientas - Los estados terminales como rechazado o duplicado no tienen responsable asignado pero deben ser medidos - Algunos defectos deben ser presentados a comité
   1. 4.3) Información del informe de defecto
      1. ¿Qué debe tener un defecto?

         Anmerkungen:

         • - ¿Quién lo descubrió? - Rol de la persona - Tipo de prueba - Resumen - Descripción detallada - Pasos para reproducir con resultado esperado vs obtenido y evidencias (capturas) - Severidad - Prioridad - Tipo de defecto - Entorno - Persona que debe revisar
      2. ¿Para que sirven los datos recopilados?

         Anmerkungen:

         • - Aportar información y decidir si es necesario corregir - Gestionar informes - Evaluar estado del proyecto - Evaluar la calidad del proceso - Medir avance de las pruebas - Controlar las pruebas - Evaluar criterios de salida - Analizar densidad de errores - Analizar el estado de las correcciones - Analizar la raíz del defecto - Identificar tendencia a futuros errores
         1. 4.4) Evaluación de la capacidad de un proceso, el uso de la información obtenida en cada fase se puede adaptar para mejorar la detección de defectos, agrupamiento de defectos, análisis de pareto y análisis de causa raiz aportan a la evaluación, si no se realiza esta es difícil mejorar por no tener datos confiables.
      3. Estandares

         Anmerkungen:

         • - ISO 9126 - 25000 - IEEE 1044 - IEEE 829 - Clasificación ortogonal de defectos El uso de estandares es voluntario pero aporta mucho al proyecto
         • IEEE 1044 (ciclo de vida del defecto) - Reconocimiento - Investigación  - Acción - Disposición Actividades para cada paso: - Registro - Clasificación - Identificación del impacto

1. 5.2) Proceso de mejora de pruebas

   Anmerkungen:

   • Principales procesos de mejora: - TMMI - TPI Next - CTP - STEP Otros: - ITIL - TIM - TMAP - SQR
   • El proceso genérico indica: - Iniciar - Medir - Planificar - Definir/Redefinir  - Operar - Validar - Evolucionar
   • Enfoques para mejora: - Kaizen - TQM - Six Sigma - SQM - Ciclo Deming También es posible mejorar sin proceso utilizando análisis y retrospectiva
2. 5.3) Mejoras del proceso de pruebas, los modelos basados en niveles permiten comparaciones entre distintas empresas sin embargo son rígidos, en cambio los modelos continuos son mas flexibles de implementar

   Anmerkungen:

   • Una vez tomada la decisión de que modelo usar el modelo IDEAL indica los siguientes pasos para el uso: - Iniciar - Diagnosticar - Establecer - Activar - Aprender
3. 5.4) Mejora del proceso con TMMI

   Anmerkungen:

   • Creado en 2004 basado en TMM del modelo CMM, este define objetivos y sub objetivos: - Inicial (demostrar que el software funciona) - Gestionado (Validar que cumple las especificaciones) - Definido (Equipo de pruebas es independiente y realiza revisiones) - Medido (Pruebas definidas y medibles) - Optimizado (utiliza todos los anteriores y se agrega prevensión de errores)
4. 5.5) Mejora del proceso con TPI Next, técnica que utiliza 16 áreas claves para medir la madurez

   Anmerkungen:

   • Intereses de las áreas claves: - Ciclo de vida - Organización - Infraestructura / Herramientas - Métodos
   • Niveles de madurez: - Inicial - Controlado - Eficiente - Optimizado
   • Sin embargo este modelo carece de estrategias, comunmente se realizan casos intuitivos sin cobertura definida, para avanzar en los niveles se usan puntos de comprobación 
5. 5.6) Mejora del proceso con CTP, desarrollado por Rex Black, consta de 12 procesos críticos, es un modelo sencíble y adaptable al contexto; utiliza tablas de evaluación y plantea las pruebas como vitales para un proyecto
6. 5.7) Mejora del proceso con STEP, desarrollado en 1986 fue el primer modelo en plantear todo un modelo de pruebas, indica que las pruebas y el desarrollo se deben realizar en paralelo, ademas de considerar los riesgos en el proceso

   Anmerkungen:

   • 3 objetivos principales: - Evitar errores - Detectar defectos - Demostrar las capacidades del software No es necesario que las mejoras sean por etapas
   • Las premisas básicas que utiliza: - Estrategias basadas en requisitos - Pruebas al inicio del ciclo - Pruebas como modelo de uso - El diseño de pruebas conduce el diseño de software - Detectar defectos temprano - Analizar defectos con proceso - Probadores y desarrolladores trabajan juntos Algunas veces se combina con TPI Next

1. 6.2) Selección de la herramienta

   Anmerkungen:

   • Antes de obtener una herramienta con licencia el TM debe tomar en cuenta las herramientas de código abierto y las hechas a medida. Se debe hacer un análisis para calcular la vida útil de la herramienta.
   • Herramientas de código abierto: - Las herramientas de código abierto normalmente no tienen soporte pero si comunidades de usuarios que apoyan ante cualquier necesidad - Muchas veces estas herramientas necesitan modificaciones por que fueron desarrolladas con un solo fin - Algunas tienen licencia GNU la cual indica que las mejoras deben ser entregadas a la comunidad - No están certificadas por estándares como ocurre con la mayoría de las pagas (DO-178B)
   • Herramientas a medida: - Para el desarrollo de estas herramientas es necesario conocimiento técnico  - Las herramientas deben ser apuestas a largo plazo Ventajas: - Pueden cumplir necesidades específicas - Pueden interactuar con otras herramientas  - Se pueden utilizar para múltiples proyectos Desventajas: - Dependen del creador - Se debe crear documentación - Puede no funcionar como se planeó - Puede caer en desuso 
   1. Ventajas

      Anmerkungen:

      • - Menos intervención manual - Menos tiempo por ciclo - Menor costo por ejecución - Capacidad para aumentar las pruebas de regresión - Ejecutar pruebas imposibles sin herramientas - Reducción de error humano - Mas fácil obtención de informes
   2. Costos

      Anmerkungen:

      • Recurrentes: - Costo licencia - Costo mantenimiento - Portabilidad de la herramienta - Mejora de la calidad - Tiempo de selección de la herramienta
      • No recurrentes: - Definición de requisitos o necesidades - Evaluación de la calidad del proveedor - Formación del equipo - Adquisición de software  - Hardware necesario
   3. ROI

      Anmerkungen:

      • Para el negocio siempre es necesario un retorno de la inversión, sin embargo no todas las herramientas lo ofrecen, por lo cual es necesario hacer un análisis costo-beneficio En el análisis se debe considerar:  - Curva de aprendizaje  - Madurez de la empresa  - Necesidades reales  - Evaluación de varias herramientas  - Evaluar el soporte  - Evaluar la capacitación
      • Interrogastes para cada tipo de herramienta: - Análisis (¿Es la herramienta adecuada?) - Diseño (¿Puede diseñar automáticamente? ¿Puede generar soportes? ¿Puede generar datos de prueba?) - Selección de datos  y pruebas (¿Como se seleccionan los datos? ¿Puede leer datos manuales? ¿Puede "expurgar" varias datos de producción? ¿Puede seleccionar prueba según requisitos?) - Ejecución (¿Es automática o necesita apoyo manual? ¿Como se detiene o reinicia? ¿Actualiza automáticamente los datos del caso?) - Evaluación (¿Como determina el resultado correcto? ¿Es capaz de registrar errores? ¿Elabora informes?)
2. 6.3) 4 etapas del Ciclo de vida de las herramientas

   Anmerkungen:

   • - Adquisición - Soporte - Evolución - Retirada Es tarea del TM garantizar el funcionamiento
3. 6.4) Métricas de las herramientas, el TM debe generarlas y deseñarlas de manera objetiva a partir de las herramientas y el equipo de pruebas, verificar que herramientas se tienen para recopilar datos

   Anmerkungen:

   • Métricas: - Trazabilidad desde requisito hasta la automatización - Pruebas planificadas y sus estados - - - - -

1. 7.2) Habilidades individuales para cada miembro

   Anmerkungen:

   • Habilidades de todos los miembros: - Inteligentes y curioso - Flexibles y adaptables  - Dispuestos a trabajar  - Adaptables a equipos - Capaces de trabajar bajo presión 
   • ¿Cómo mejorar las habilidades? - Generar una lista y puntuar - Identificar fortalezas y debilidades - Generar un plan de formación - Crear metas individuales - Mejorar con cursos - Auto estudio - Tutorias - Presentaciones de expertos
   1. Probador:

      Anmerkungen:

      • - Experiencia en sistemas de software - conocimiento procesos de negocio - Análisis, diseño, codificación, soporte técnico - Experiencia en pruebas de software
   2. TM:

      Anmerkungen:

      • - Experiencia en pruebas y gestión de proyectos - Estar capacitado, en estrategia, diseño y planificación de pruebas - Poder realizar control, seguimiento, correcciones - Redactar informes  - Capacidades interpersonales, escritas,diplomacia  - Atento a detalles y organizado
   3. Usuario, JP:

      Anmerkungen:

      • - Conocimiento del negocio - Conocimiento del sistema y donde puede fallas - Conocimiento de resultados esperados y datos realistas - Puede ayudar a formular requisitos no funcionales y datos del negocio
   4. Desarrollador, Técnico soporte:

      Anmerkungen:

      • - Utiliza lenguaje técnico - Tiene conocimiento sobre requisitos (rendimiendo, usabilidad, etc) - Código, automatización, revisíón de código
   5. Probador, diseñador, automatizador:

      Anmerkungen:

      • - Conocer métodos y herramientas de prueba - Examinar, analizas y comentar especificaciones - Capacidad de evaluar riesgos - Ejecutar casos y registrar resultados - Clasificar defectos, detectar la raíz - Tener sentido de detalle, visión, trabajo en equipo
   6. 7.3) Dinámica del equipo de pruebas, lo ideal sería tener un equipo de pruebas con diferentes conocimientos, que actúen como socios y puedan completar tareas personales, con respeto mutuo y excelentes relaciones interpersonales

      Anmerkungen:

      • Equipos de éxito deben tener: - Baja fluctuación - Identificación con el equipo - Deleite en el trabajo - Cociente de ser parte de un equipo de elite
      • Inventario de equipo según BELBIN: - Orientados a la acción  - Orientados a la comunicación - Orientados al campo
      1. 7.4) Interacción del proceso de pruebas con la organización, según POL 2000, el equipo de pruebas interactua con todas las áreas involucradas por lo cual se debe entender en que tipo de organización se está ya que cada es distinta, además cada integrante debe comprender que la calidad es tarea de todos

         Anmerkungen:

         • Niveles de prueba: - El desarrollador prueba su código - Otro desarrollador prueba el código  - Un equipo ajeno a desarrollo prueba el código - Externos (Near shore / Off shore)
         • Retos off shore: - Comunicación - Diferencias culturales - Estimación de costos - Expectativas de calidad - Supervisión de uso de recursos
         1. 7.5) Motivación, tenemos la motivación primaria como lo es comer, tener calor, tener agua y la secundaria como es el entorno, la seguridad, comodidad; Maslow ofrece una pirámide con 5 niveles (ver nota)

            Anmerkungen:

            • - Necesidades biológicas - Seguridad y protección - Afiliación y permanencia - Reconocimiento - Autorrealización 
            1. 7.6) Comunicación, esta debe ser capaz y eficiente, objetiva, profesional y diplomática, cada comunicación debe estar basada en hecho y orientada a objetivos

               Anmerkungen:

               • La comunicación puede ser mediante:  - Documentos - Resultados de productos - Recopilación y distribución