Cuando vamos a entregar un producto de software, se suele luchar entre un equilibrio entre la calidad y la fecha de lanzamiento prevista. Todos sabemos, y lo comentamos, prácticamente a diario, que probar el software es un paso crucial para garantizar que todo funcione tal y como fue diseñado.
Si no se siguen una serie de técnicas de estimación del tiempo de prueba, nos podemos encontrar con que los plazos previstos se incumplan y no se realicen todas las pruebas que quisiéramos para garantizar nuestro software.
Si esto ocurre, el presupuesto se dispara y comienza la tensión, ya sabemos que cuando el dinero está por medio, no puede pasar nada bueno. El presupuesto viene de un cliente, y si este, no recibe lo que a pagado en los plazos y fechas que se han estipulado, lo más seguro es que los nervios afloren y se pidan explicaciones. Aunque esto suceda, jamás podemos dejar atrás el proceso esencial de probar y garantizar la calidad del producto que queremos poner en producción.
Vamos a revisar como poder planificar el proceso de pruebas de manera adecuada.
En primer lugar, tenemos que leer y analizar la documentación del proyecto como tal, realizando reuniones, discusiones o debates con directores, gerentes o jefes de proyecto. Debemos de pasar varios días en esta situación para aclarar detalles, dudas, responder a cualquier tipo de pregunta y, sobre todo, no dejarnos nada en el tintero.
En este caso debemos de tener claras las pruebas que se van a realizar, que tipos de perfiles se van a necesitar, si son más enfocados en la automatización o no y, sobre todo, cuantas personas serán necesarias para poder garantizar la calidad con la mejor garantía.
Una vez que ya tenemos clara la planificación, los perfiles y hemos podido detectar y resolver todas las preguntas y cuestiones con todos los actores del proyecto, podemos hablar sobre las pruebas como tal y sus tareas.
Uno de los principales errores que se comenten a la hora de planificar y estimar proyectos de pruebas es el de solo pensar en la ejecución. Esto suele ocurrir con perfiles más enfocados en la dirección, que no saben exactamente que es lo que hay que hacer y no tienen mucho contexto del trabajo que realizamos. Pero, en una lista rápida, las tareas habituales que deben de tenerse en cuenta para estimar:
- Plan de pruebas
- Casos de prueba
- Ejecución de pruebas
- Gestión del defecto
- Verificación completa
- Regresión
- Pruebas exploratorias
- Informe y resultado
Estas tareas básicas son las que se deben de tener en cuenta, aunque pueden cambiar según el proyecto y la organización. Para ello, es muy importante estimar el tiempo de pruebas e incluir todas las tareas que pensemos de manera integral, esto nos dará un tiempo adecuado para cubrir todas las tareas o labores que se deben de hacer y no pillarnos los dedos.
Para realizar estas estimaciones, podemos utilizar 4 o 5 técnicas habituales que nos ayudarán a acercarnos lo mejor posible a la realidad y no llevarnos sustos de última hora.
1. Análisis de puntos funcionales: Cuando trabajamos con esta medida, lo que realizamos es el de añadir una serie de tallas o clasificaciones basadas en la dificultad de probar. Por ejemplo, del 1 al 5, siendo 1 lo más sencillo y 5 lo más complicado. Una vez que hemos “puntuado” las funcionalidades, tenemos que realizar la siguiente ecuación: (persona-horas)*puntos función.
2. Desglose de trabajo: si utilizamos este método, lo que realizamos es la deconstrucción del proyecto en elementos muy básicos (o elementales) y realizaremos una estimación de cada uno de ellos, que hará que esta labor sea mucho más sencilla.
3. Planificación Póker: es un método gamificado para estimar el tiempo de nuestro trabajo. Lo que haremos es dividir el proyecto en tareas muy individuales y una vez que se realiza esto, se sacan las cartas y se estiman con la numeración de cada una entre todas las personas del equipo sin revelar su resultado hasta después de la discusión.
4. Método Delphi: esta técnica se centra en realizar encuestas de especialistas en control de calidad para determinar una estimación “promedio” por cada una de las tareas.
5. Tres puntos: Dividimos el proyecto en tareas pequeñas, más en concreto en componentes básicos o lo más atómicos posibles. Una vez se realiza esto, se asignan los datos según estas tres propuestas:
- Optimista (A)
- Pesimista (B)
- Realista (R)
Tras ello, se puede saber el tiempo estimado (E) con la siguiente fórmula:
E = (A + 4xR + B) / 6.
Estas técnicas de planificación, son una parte muy importante de la estimación que queremos hacer para nuestros tiempos de pruebas.
Sobre todo, tenemos que tener muy claro, que existen muchas labores o tareas alrededor de lo que son la ejecución de pruebas y que tenemos que contabilizarlas y hacerlas ver a todas las personas que forman el proyecto o incluso la organización. En mi trayectoria en el mundo de la calidad, me he encontrado con tijeretazos y cortes sustanciales al proceso de pruebas, dejando únicamente un tiempo acotado para probar sin, ni siquiera, el poder permitir la realización de un plan de pruebas adecuado o que se pueda entregar a cliente o incluso, el ver como cualquier tipo de problema es achacado al equipo de pruebas tras haber recortado de manera sustancial su tiempo y dedicación y no permitiendo hacer su trabajo de manera correcta.
Es realmente importante hacer ver este tipo de situaciones, ya que, son más habituales de lo que pensamos y pueden hacer que se demonice nuestra situación y que toda la responsabilidad y problemáticas encontradas nos lleguen directamente sin tan siquiera permitirnos ni defendernos.
Este panorama está cambiando y solo ocurre en “des-organizaciones” (como me gusta llamarlas) que no trabajan de una manera adecuada, ordenada y entregan a cliente proyectos inacabados, fuera de tiempo o con fueras de alcance que intentan repercutir a cliente sin que ni siquiera se den cuenta de ello. Nosotros, con nuestro conocimiento y experiencia, tenemos que cambiar las cosas, luchando contra viento y marea para que la calidad esté por encima de cualquier otra cosa y que nuestra satisfacción sea el trabajo bien hecho.
0 Comentarios