Estimación en Testing con vista al Bosque

La Estimación de Alto Nivel

  • ¿Les ha pasado que les piden estimar pruebas para un proyecto o servicio de pruebas y solo tienen un correo con una breve explicación?
  • ¿Y solo cuentan con un par de reunión de aclaratoria de dudas?
  • ¿Y un corto tiempo para la entrega de una primera propuesta?

1.-  Herramienta apropiada para estos casos

Por que con Vista al Bosque?

Sucede que al igual que con los diferentes tipos de bosque, por ejemplo,  bosques de Pinos, al verlos desde arriba, de alto nivel, los expertos en la material podrían estimar la cantidad de madera que se podría sacar de allí y en cuanto tiempo podrida ser esto, también indagando en alguna reunión con las personas que habitan en las zonas cercanas  se podría conocer el tipo de flora y de fauna que allí se puede conseguir y lo productivo que pudieran ser, sin necesidad de ingresar a dicho bosque. 

Pensando fuera da la caja, pensando en la vista desde lo alto del Bosque, haciendo las preguntas adecuadas, como qué tipo de árbol observamos, que tipo de fauna o flora somos capaces de ver desde esa altura. Podemos obtener una estimación que permita establecer planes de trabajo con premisas y riesgos que nos ayuden a definir un alcance adecuado.

Haciendo la analogía cuando se trata de pruebas Podemos a partir de un correo con el detalle del Proyecto o servicio y plantearnos:

1.- ¿Es un Desarrollo de MVP, es algo que desarrollara desde 0?

2.- Se nos está solicitando un servicio de fábrica de pruebas?

3.- ¿Es un aplicativo Web, Móvil o de alguna Plataforma particular?  (Ejemplo USSD, SMS, POS)

4.- El aplicativo en que contexto será utilizado? Recordemos que uno de los principios de las pruebas es que dependen del contexto, no es igual probar un aplicativo para un Banco que para un Aplicativo web para el intercambio de imágenes.

5.- ¿Es un aplicativo Multicapas, de ser así, tiene más de dos, tres capas? Tiene FrontEnd (UI), BackEnd (Servicios) y BD 

6.- Tiene servicios legados? Exista alguna conexión a servicios que por su antigüedad ya no permiten hacer actualizaciones y aportan un cierto nivel de inestabilidad o dificultad en la ejecución de las pruebas

7.- Por cuanto tiempo se estiman los desarrollos?

9.- A la hora de la ejecución de las pruebas existe alguna limitante en el acceso a los ambientes de pruebas y/o servicios. Con esta interrogante queremos identificar los puntos de posible validación a los que se tendría acceso

10.- Existe alguna dependencia en la ejecución de las pruebas de algún otro proveedor o área de la empresa?  Siempre que el equipo de pruebas depende de un tercero, dentro de la empresa o en algún otro proveedor

Preguntas como estas nos ayudaran a modelar los tipos de caso de prueba promedio que estimamos pudiera tener el servicio de pruebas para el Proyecto o servicio pruebas software.

Estimación

  • La Estimación es un proceso predice la duración de una actividad
  • Lo fundamental en una estimación es lograr la mayor precisión posible, de ese modo minimizaremos la desviación
  • Se posee menor precisión para estimar al comienzo de nuestro proyecto
  • Tener documentación sobre procesos aprendidos con anterioridad, nos va a permitir mejorar la precisión de nuestra estimación

Tipos de Estimación

Tipos de Estimación de Proyectos

1.- Estimacion Experta

  • Identificar todas las tareas a ejecutar (normalmente utilizando un enfoque descendente (“top down”))
  • Obtener estimaciones para cada tarea de los responsables (de su ejecución) o por expertos
  • Sumar todos los valores de las tareas. Incluir los factores de corrección (si hay experiencias respecto de la exactitud de ciertos estimadores)
  • Incluir elementos amortiguadores (buffers)/elementos adicionales con el objeto de cubrir tareas omitidas o subestimadas

2.- Estimación basado en Analogías

  • Clasificar las tareas de prueba requeridas
  • Buscar un proyecto que se haya desarrollado en el pasado que contenga una tarea similar a una específica
  • Utilizar el esfuerzo real de esta tarea como base para la estimación
  • A través del uso de métricas (líneas de código, número de módulos, número de casos de prueba, etc.) como base, calcular el valor de la estimación total
  • Considerar factores de corrección

3.- Basado en porcentajes

  • El esfuerzo para las actividades de prueba se estima sobre la base de la totalidad de las actividades del proyecto
  • El valor del porcentaje (fracción) requiere ser determinado basándose en la experiencia
  • Este método también puede ser utilizado para parte del trabajo (por ejemplo, estimación para los costes de gestión de proyecto, estimación del esfuerzo de pruebas para las pruebas de sistema)
  • La estimación basada en porcentajes no tiene en cuenta el esfuerzo de la prueba de regresión, que pueden ser una parte sustancial de las pruebas de mantenimiento y asociadas al cambio
Ejemplo:

Spillner/Linz habla de un porcentaje del 50% de actividades de pruebas respecto de la totalidad de las actividades del proyecto

Las Premisas y El Riesgo

Premisas

1.- Establecer la complejidad de los casos Promedio

2.- También se debe establecer el tamaño del proyecto o servicio, pudiera ser identificando la cantidad de módulos o requerimientos y el tiempo de duración del proyecto.

3.- Se debe establecer a través de que canales se realizaran las pruebas, como por ejemplo si aplicara a dispositivos móviles o si existe algún equipo especializado que se requiera para las pruebas, para lo cual se deberá establecer responsables, determinando quien aportara dichos equipos.

4.- Los ambientes de pruebas y su administración serán responsabilidad del cliente o del área de Pruebas

Riesgo

Posibles riesgos que se deben establecer a la hora de usar un método de estimación de alto nivel y que presenta un nivel de incertidumbre alto:

1.- Que no se tenga acceso a los sistemas o servicios

2.- Que el cliente omita información importante y que cambie el alcance

3.- Que se requiera un nivel de experticia para algunas pruebas especializadas que no se indicaron

4.- Cambio de la persona responsable de establecer el alcance por parte del cliente lo que pudiera hacer que se cambie algunas características del proyecto

Nivel de Complejidad 4

Características Casos de prueba según el nivel de complejidad 4:

  • No se requiere datos o se preparan sumamente rápidos.
  • Pocas reglas de Negocio.
  • De 3 a 5 imágenes por evidencia.
  • El Tester requiere poco o nada de entrenamiento.

Descripción del Nivel 4

Se ejecutan de 16 a 30 casos de pruebas

Esto da un promedio de 23 casos por jornada de trabajo

Nivel de Complejidad 3

Características Casos de prueba según el nivel de complejidad 3:

  • No se requiere datos o se preparan sin mayor contratiempo.
  • Reglas de Negocio de baja complejidad.
  • De 3 a 5 imágenes por evidencia.
  • El Tester requiere poco entrenamiento.

Descripción del Nivel 3

Se ejecutan de 10 a 15 casos de pruebas

Esto da un promedio de 23 casos por jornada de trabajo

15 minutos en promedio por caso

Nivel de Complejidad 2

Características del nivel de complejidad 2:

  • Múltiples Actualizaciones para preparar los Datos de Prueba.
  • Múltiples Consultas a BD.
  • Evidencia de Múltiples Pantallas o páginas que conforman el Proceso.
  • Reglas de Negocio de complejidad Media.
  • Poca o nula dependencia de otras áreas, clientes y/o proveedores.

Descripción Nivel 2

Se ejecutan de 4 a 9 casos de pruebas

Esto da un promedio de 7 casos por jornada de trabajo.

48 minutos en promedio por caso

Nivel de Complejidad 1

Características del nivel de complejidad 1

  • Múltiples Actualizaciones para preparar los Datos de Prueba.
  • Múltiples Consultas a BD.
  • Evidencia de Múltiples Pantallas o páginas que conforman el Proceso.
  • Dependencia de terceros, otros proveedores o Áreas Clientes con poca disponibilidad.
  • Dependencia en la ejecución de procesos complejos para la ejecución del caso

Descripción Nivel 1

Se ejecutan de 0 a 3 casos de pruebas

Esto da un promedio de 1 casos por jornada de trabajo

480 minutos como promedio de ejecución por caso

Modelo de estimación con Vista al Bosque

Modelo de Estimación en Testing con Vista al Bosque
  • Esta estimación con vista al Bosque permite establecer el tamaño del equipo de pruebas y así como el posible  WIP (Work In Progres) del equipo de pruebas, basado en la complejidad de los casos de pruebas
  • También permite dar una respuesta oportuna, en corto tiempo orientado al Time To Market, basado información con alto grado de incertidumbre, pero con una técnica a la que se le puede ir aplicando la mejora continua y refinando según nuestra área de experticia en pruebas.
  • Esta Matriz de estimación se basa únicamente en la cantidad de casos promedio que un equipo pudiera ejecutar, sin embargo, hay otra dimensión de esta matriz que implicaría la asignación de recursos según el nivel de experiencia y capacidad de detectar bug’s de ciertas características,  porque he notado, que hay personas que consiguen defectos de software  por ejemplo de Look And Feel, mientras que otros son más Orientados a las fallas funcionales, esta otra dimensión de este método de estimación aun lo estoy desarrollando, sin embargo, estoy Seguro que cada líder conoce a sus colaboradores y los asigna según la velocidad que requiere para el Proyecto que tiene

Visualiza el video en el canal de Youtube de Mega Testing Week: https://www.youtube.com/watch?v=C2ems6Zl4HQ

También te puede interesar...

Artículos populares