Herramientas para gestionar pruebas de software | Parte I

  • Autor de la entrada:
  • Categoría de la entrada:ISTQB

Intro

El programa de estudios de #ISTQB® CTFL tanto en su v2018 como en la v4.0, trata el tema de las «Herramientas» en su capítulo 6 presentando algunas diferencias en cuanto a su foco y a la cantidad de contenido relacionado.

Acerca de los objetivos de aprendizaje

A modo de síntesis podemos decir que si bien ambas versiones definen dos objetivos de aprendizaje y los mismos tipos de niveles de conocimiento (K1: Recordar y K2: Comprender), la v4.0 es más reducida ya que sus dos objetivos de aprendizaje se corresponden a dos tipos de niveles de conocimiento que se encontraban en uno de los objetivos de aprendizaje de la v2018. Por otra parte, en la v4.0 no se está considerado uno de los objetivos de aprendizaje presentados en la v2018.

En detalle, ésto es así:

ISTQB CTFL v4.0 Capítulo 6 Herramientas

El nivel de conocimiento del objetivo de aprendizaje 6.1. de la v4.0 contiene los niveles de conocimiento del objetivo de aprendizaje 6.1.1. y 6.1.3.

El objetivo de aprendizaje 6.2. de la v4.0 se corresponde con el nivel de conocimiento 6.1.2. del objetivo de aprendizaje 6.1. de la v2018.

El objetivo de aprendizaje 6.2. de la v2018 no está considerado en la v4.0, se eliminó contenido relacionado con: los principios básicos para poder seleccionar herramientas, los objetivos de utilizar proyectos piloto y los factores de éxito para evaluar, implementar, desplegar y dar soporte continuo de herramientas.

Acerca de (6.1.) Herramientas para el soporte de las pruebas

Son todas aquellas familias de herramientas que dan soporte a determinados tipos de pruebas o para gestionar ciertas actividades de prueba durante nuestros sprints en caso de estar trabajando en marcos ágiles, o durante las correspondientes fases en caso de estar trabajando en modelos de desarrollo del tipo cascada o waterfall.

Hay varios ejemplos de los tipos de herramientas que soportan pruebas aunque como indica el programa de estudios, no hay que limitarse sólo a los descriptos y esta mención hace pensar y reflexionar en las herramientas impulsadas con inteligencia artificial que ya tenemos a nuestra disposición y que nos proponen explorarlas para seguir evolucionando.

Sobre la expresión «no hay que limitarse…»

El programa de estudios en esta parte cita la siguiente frase: «Los ejemplos incluyen, pero no se limitan a: …» y a continuación, lista los tipos de herramientas.

En mi opinión, y es discutible por supuesto, refiere a los otros tipos de herramientas que están surgiendo como por ejemplo aquellas impulsadas por inteligencia artificial.

Respecto de las #aitools estoy investigando un poco las herramientas existentes a partir de todo lo que voy aprendiendo en la formación que estoy tomando en UBA IALAB más otro curso que en paralelo estoy estudiando con el objeto de aplicar a futuro en nuestra práctica de #testing, sabiendo que además esta la certificación que propone ISTQB® – International Software Testing Qualifications Board con su programa de estudios Pruebas de IA de probador certificado (CT-AI)

Volviendo al foco

Los siguientes son ejemplos de tipos de herramientas:

  1. para la gestión
  2. para pruebas estáticas
  3. para el diseño e implementación de pruebas
  4. para la ejecución y cobertura de pruebas
  5. para pruebas funcionales
  6. para devops
  7. para la colaboración
  8. para la escalabilidad y estandarización de la implementación
  9. para ayudar con las pruebas

(1) Herramientas para la gestión de pruebas

Las Herramientas de gestión permiten que el equipo de testers incremente su eficiencia dentro del proceso de prueba facilitando la gestión del ciclo de vida del desarrollo de software (SDLC) a todo el equipo, controlando la calidad en los requisitos, permitiendo que el equipo de testers pueda organizarse y administrar los workflows de testing, es decir, el diseño de los casos de prueba, la gestión de datos asociados a usar, la ejecución de los casos de prueba, la registración de los resultados de las pruebas y la registración y comunicación de los defectos que se hayan identificado, y consecuentemente las respectivas métricas.

La eficiencia en relación con los procesos de software testing se puede entender como la capacidad de realizar las pruebas de manera efectiva, utilizando los recursos de manera óptima, por ejemplo tener la capacidad de encontrar la mayor cantidad de defectos con el menor esfuerzo posible.

Para aclarar aún más el tema de la eficiencia y su diferencia con la eficacia que muchas veces nos encontramos con este interrogante, comparto una definición liviana. La eficiencia se refiere a la relación entre los recursos utilizados y los resultados que hayamos obtenido. Desde el punto de vista del software testing, la eficiencia se puede medir en términos de:

  • Tiempo: ¿Cuánto tiempo tardamos en realizar las pruebas?
  • Costo: ¿Cuál es el costo de realizar las pruebas? (dependiendo de tu rol podrás gestionar este punto)
  • Recursos humanos: ¿Cuántos testers se necesitan para realizar las pruebas? Aquí podemos incluso necesitar un seniority de tester en particular debiendo considerar el presupuesto que tengamos asignado para el proyecto. 

La eficacia se refiere a la capacidad de lograr los objetivos que requiere el proyecto para dar respuesta a la necesidad del negocio. En el contexto del software testing, la eficacia se puede medir en términos de:

  • Cobertura: ¿Qué porcentaje del software desarrollado se ha testeado?
  • Precisión: ¿Qué porcentaje de los defectos se han detectado?
  • Tiempo de detección: ¿Cuánto tiempo tardamos en detectar un defecto?

Herramientas de este tipo

Tenemos a nuestra disposición herramientas open source y aranceladas como:

Xray by Xblend / #Zephyr / TestLodge / TestRail / TestMonitor / PractiTest – Test Management / #TestComplete y muchas más que se integran con #JIRA Software Atlassian Jira, como así también tenemos ALM QC, IBM Rational Test Manager, y Microsoft Azure DevOps módulo de #Testing, entre tantas otras.

Nota al lector: En estos días estaré actualizando contenidos relacionados con algunas de estas herramientas descriptas arriba y publicaré una síntesis por aquí y el detalle en mi blog.

Acerca de la historia de una herramienta y no tanto

No quiero olvidarme en mencionar a #Testlink como una de las herramientas que aún hoy se sigue usando en áreas de testing por diversas razones: áreas no tan maduras, áreas con poco presupuesto, áreas que no cuentan con la conducción de un líder de testing que tenga conocimiento y experiencia en herramientas como las mencionadas antes, y que se encuentran en el proceso de evolucionar a una herramienta con más prestaciones.

Un capítulo aparte son aquellas áreas de testing que usan herramientas como #Redmine o #Jira Software únicamente para conducir sus procesos de prueba.

Por lo general los motivos que han llevado a dichas áreas a administrar la calidad de esa forma son las mencionadas antes, y dará para otro artículo anexo.

Para lograr más entendimiento

Para lograr un mayor entendimiento y profundizar en aquellos temas que sean de nuestro interés, ciertos conceptos como: gestión del SLDC, requisitos, defectos y métricas, entre otros, están ligados con “las herramientas para gestionar pruebas” y que se encuentran en el programa de estudios distribuidos a lo largo de sus capítulos. 

Los siguientes puntos corresponden a dichas referencias. A modo de ejemplo, podemos ir a la referencia 1.1.1 Objetivos de la prueba y buscar el concepto ‘gestión del SLDC’ e interpretar a partir de la definición de su alcance, la relación que tiene con las herramientas para gestionar pruebas.

Gestión del SLDC 

  • 1.1.1. Objetivos de la Prueba
  • 1.3. Principios de la Prueba
  • 2.1. Pruebas en el Contexto de un SDLC
  • 2.1.1. Impacto del SLDC en las pruebas
  • 2.1.2. SDLC y buenas prácticas de prueba
  • 2.1.5. Enfoque de desplazamiento hacia la izquierda
  • 2.1.6. Retrospectiva y mejora de procesos
  • 2.2. Niveles de Prueba y tipos de prueba
  • 3.1.2. Valor de las pruebas estáticas
  • 3.2.1. Beneficios de la retroalimentación temprana y frecuente de las partes interesadas
  • 3.2.4. Tipos de revisiones
  • 5.1.2. Contribución del tester a la planificación de la iteración y entrega
  • 5.1.7. Cuadrantes de Prueba
  • 5.2.3. Análisis de riesgos de producto
  • 5.5. Gestión de defectos
  • 6.1. Soporte de herramientas para las pruebas

Requisitos

  • 1.1. ¿Qué es probar?
  • 1.1.1. Objetivos de la prueba
  • 1.2.2. Pruebas y aseguramiento de la calidad (QA)
  • 1.3. Principios de la prueba
  • 1.4.1. Actividades y tareas de prueba
  • 1.4.2. El proceso de la prueba en contexto
  • 1.4.3. Testware
  • 1.4.4. Trazabilidad entre la base de prueba y el testware
  • 2.1.1. Impacto del SDLC 
  • 2.1.6. Retrospectiva y mejora de procesos
  • 3.1.1. Productos de trabajo evaluables mediante pruebas estáticas
  • 3.1.2. Valor de las pruebas estáticas
  • 3.1.3. Diferencias entre pruebas estáticas y pruebas dinámicas
  • 3.2.1. Beneficios de la retroalimentación temprana y frecuente de las partes interesadas
  • 3.2.4. Tipos de revisiones
  • 4.2.3. Pruebas de tabla de decisión
  • 4.3.3. El valor de las pruebas de caja blanca
  • 4.4.3. Pruebas basadas en listas de comprobación
  • 5.1.1. Propósito y contenido de un plan de prueba
  • 5.1.3. Criterios de entrada y criterios de salida
  • 5.1.5. Priorización de casos de prueba
  • 5.3. Monitoreo de prueba, control de pruebas y finalización de pruebas
  • 5.3.1. Métricas utilizadas en la pruebas
  • 5.5. Gestión de defectos
  • 6.1. Soporte de herramientas para las pruebas
  • 6.2. Beneficios y riesgos de la automatización de pruebas

Defectos

  • 1.1. ¿Qué es probar?
  • 1.1.1. Objetivos de la prueba
  • 1.1.2. Pruebas y depuración
  • 1.2. ¿Porqué es necesario probar?
  • 1.2.1. Contribuciones de las pruebas al éxito
  • 1.2.2. Pruebas y aseguramiento de calidad (QA)
  • 1.2.3. Errores, defectos, fallas y causas raíz
  • 1.3. Principios de la prueba
  • 1.4.1. Actividades y tareas de la prueba
  • 1.4.3. Testware
  • 1.4.4. Trazabilidad entre la base de prueba  el testware
  • 1.5.1. Habilidades genéricas requeridas para las pruebas
  • 1.5.3. Independencia de las pruebas
  • 2.1.5. Enfoque de desplazamiento hacia la izquierda
  • 2.2.1. Niveles de prueba
  • 2.2.2. Tipos de prueba
  • 2.2.3. Pruebas de confirmación y pruebas de regresión
  • 3.1. Conceptos básicos de las pruebas estáticas
  • 3.1.2. Valor de las pruebas estáticas
  • 3.1.3. Diferencia entre pruebas estáticas y pruebas dinámicas
  • 3.2.2. Actividades del proceso de revisión
  • 4.1. Descripción general de las técnicas de prueba
  • 4.2.2. Análisis de valores límite
  • 4.2.4. Pruebas de transición de estado
  • 4.3.1. Pruebas de sentencias y cobertura de sentencias
  • 4.3.2. Pruebas de ramas y cobertura de ramas
  • 4.3.3. El valor de las pruebas de caja blanca
  • 4.4.1. Predicción de errores
  • 4.4.3. Pruebas basadas en listas de comprobación
  • 4.5. Enfoques de prueba basadas en la colaboración
  • 4.5.3. Desarrollo guiado por pruebas de aceptación
  • 5. Gestión de las actividades de prueba
  • 5.1.3. Criterios de entrada y criterios de salida
  • 5.2.3. Análisis de riesgos de producto
  • 5.3.1. Métricas utilizadas en las pruebas
  • 5.3.2. Propósito, contenido y audiencia de los informes de prueba
  • 5.5. Gestión de defectos
  • 6.1. Soporte de herramientas para las pruebas
  • 6.2. Beneficios y riesgos de la automatización de pruebas

Métricas

  • 3.2.4. Tipos de revisiones
  • 5.1.1. Propósito y contenido de un plan de prueba
  • 5.1.3. Criterios de entrada y criterios de salida
  • 5.1.4. Técnicas de estimación
  • 5.3.1. Métricas utilizadas en las pruebas
  • 5.3.2. Propósito, contenido y audiencia de los informes de prueba

Pruebas

[ aparece en 699 ubicaciones ]

Cambios que trae la v4.0

ISTQB® ha reducido el tamaño del Programa de Estudio general (v2018).

ISTQB® ha excluido en varias de las secciones de los capítulos, los ejemplos que presentaba la v2018 ya que entiende que es una tarea de cada proveedor de la capacitación proveer de ejemplos y práctica.

ISTQB® estableció la «Lista de comprobación de escritura del Programa de Estudio», que define el tamaño máximo de texto para las LOs (Objetivos de aprendizaje) en cada nivel K (K1 = máx. 10 líneas, K2 = máx. 15 líneas, K3 = máx. 25 líneas).

ISTQB® ha reducido el número de LOs en comparación con los Programas de Estudio Nivel Básico v3.1.1 (v2018) y Ágil v2014.

ISTQB® proporciona referencias más extensas a libros y artículos clásicos.

ISTQB® ha establecido importantes cambios en sus capítulos respecto de la v2018 y en próximas publicaciones lo explicaré.

Comentario final

Si el contenido de este artículo te ha servido, te agradecería que me sigas en LinkedIn donde también publico los contenidos y podrás dejarme likes, comentarios y compartr con tus contactos. Muchas gracias.

Gus Terrera

Apasionado por el agile testing y la ia.