<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=160269078105920&amp;ev=PageView&amp;noscript=1">
This service has been removed!
Service successfully added!
Sign up for our blog, talk to a specialist, or just send us an email

4 Claves para la estimación del esfuerzo de QA

Lunes 19 de Noviembre 2018./ Tiempo de Lectura: 4 minutos./ Por Adriana Chavarria

Actualmente existen diversas técnicas y herramientas que ayudan a la estimación de esfuerzo y costos en los proyectos de software, éstas van desde complejos modelos como COCOMO hasta prácticas sencillas de Agile como el Planning Poker. Sea cual sea la técnica que se use, surge la pregunta: ¿Esa estimación incluye el esfuerzo de QA?

En este punto, es necesario estar claros respecto al alcance que queremos de nuestro equipo de QA.


¿Hablamos de aseguramiento de la calidad donde el equipo de pruebas es parte del análisis de requerimientos, diseño, revisión de artefactos, del proceso, de testing y análisis de resultados, o hablamos de un rol meramente de testing donde el esfuerzo solicitado se basa en la construcción de casos de prueba y su ejecución?


Otra variable aparece al hablar de ejecución de pruebas, como  ¿qué tipos de pruebas vamos a realizar? Definir si serán manuales o automatizadas, funcionales, exploratorias, de regresión, verificación de bugs. Además ver ¿qué complejidad tienen los scripts?

Dicho lo anterior, el primer paso para acercarnos a una estimación efectiva es el conocimiento preciso del contexto y alcance de la prueba.


Contexto

Algunas veces se nos piden estimaciones en etapas donde los requerimientos no están bien definidos, para estas etapas pueden realizarse estimaciones generales, que deberán contar con las observaciones y suposiciones necesarias para fundamentar el esfuerzo descrito, es necesario no perder de vista que una estimación ballpark puede traer consigo riesgos, por lo que una vez que haya una definición más cercana a la realidad del producto de software a realizar es recomendable revisar los números.


El contexto del software, es decir, sus requerimientos, entorno, necesidad, historial, tecnología y equipo humano; nos ayuda a definir un alcance adecuado para las pruebas, y por ende una base para la estimación del esfuerzo a realizar.

Alcance de la prueba

Teniendo claro el contexto, la definición del alcance de la prueba será un paso natural en la estimación del esfuerzo.


Algunos aspectos importantes que comprende el alcance son:

  • Objetivo de la prueba, aunque este es un punto que puede parecer obvio, la identificación de lo que queremos lograr con la prueba es el primer paso para ayudar a que todo el equipo esté alineado.
  • Tipos de prueba a realizar: qué tipos de pruebas funcionales  o especiales serán cubiertas.
  • Ambientes donde se realizará la prueba: a tomar en cuenta plataformas, sistemas operativos, navegadores o devices.
  • Componentes a probar: módulos donde se estará realizando la prueba.
  • Limitaciones o ítems fuera del alcance: ¿Qué debe ser excluído de la prueba?     Riesgos: problemas que pueden impactar la estimación negativamente.

 

Estimación

Al tener un contexto y un marco bien definido para la prueba, es más sencillo listar las tareas comunes dentro la prueba, por ejemplo:

  • Revisión de documentación, así como consultas y aclaraciones.
  • Capacitación.
  • Estimación y creación de casos de prueba.
  • Documentación del proceso a realizar por equipo de QA, por ejemplo estrategias, planes, alcances, resultados, checklists y cualquier otro artefacto que sea parte del proceso de pruebas.
  • Scripting.
  • Ejecución de pruebas(automatizadas, funcionales, verificación de bugs, etc).
  • Reuniones del equipo.
  • Cualquier otra tarea planificada para el equipo de pruebas.


Es importante el manejo de holguras para cada una de las tareas, así como el factor humano, es decir si estimamos un día laboral de 8 hrs, tener en cuenta que estas no son horas 100% efectivas.


La asignación de esfuerzo a estas tareas debe hacerse en una unidad estandarizada, por ejemplo, minutos, horas o días.


Para efectos de cronograma, indicar tareas que pueden ser llevadas a cabo en paralelo.

Identificación de riesgos

Algunos de los más frecuentes incluyen los siguientes:

Inexactitud por omisión

Cuando alguna funcionalidad es omitida del esfuerzo, se tiene una subestimación, que afectará proporcionalmente los tiempos de entrega o cobertura de pruebas, de tal manera que a mayor el tamaño o cantidad de características omitidas, mayor la brecha con el esfuerzo real.

Falta de claridad en requerimientos

Puede llevar a interpretaciones erróneas, que hagan que el estimador imagine funcionalidades inexistentes o módulos escuetos.

Definición de ambientes

El trabajo de QA puede incrementarse en más de 100% dependiendo de la definición de ambientes de prueba. Es necesario tener claro cuáles son los ambientes de prueba.

Recurso humano

El esfuerzo de un equipo varía según el perfil y número de sus miembros, es decir un equipo con ingenieros experimentados tendrá tiempos más cortos que uno con poca experiencia o con desconocimiento del sistema.

Recomendaciones finales

Debemos ser capaces de defender con veracidad y argumentos las estimaciones realizadas, es decir la estimación de tiempos para una tarea deberá ser un cálculo basado en la experiencia, en métricas existentes o en algún parámetro comparativo con la industria u otro proyecto semejante.

Al pensar en una estimación efectiva de esfuerzo para QA, viene a la mente una estimación de tiempos acertados (con una variación leve respecto a la real), con pruebas suficientes para una cobertura aceptable y que contemple riesgos e imprevistos que puedan alterar los esfuerzos del equipo de calidad, por tanto, al tomar en cuenta todas las variables, lograremos una estimación más efectiva.

Acerca Avantica

En Avantica trabajamos como un socio de Software que le ayuda a cumplir sus objetivos comerciales y dar solución a cada reto que se le presente.

Ofrecemos equipos dedicados y buscamos constantemente las mejores metodologías para brindarle los mejores resultados.

Iniciemos un proyecto

ANTERIOR
Conociendo el tvOS Focus Engine
SIGUIENTE
Pruebas de Regresión: 6 Recomendaciones para una buena planificación