Desde jummp traigo esta parte del artículo publicado porque merece que lo tengamos en cuenta ya que hay muchos testers que tienen a su cargo la tarea de Estimar Esfuerzo del Testing, con o sin la suficiente información que estaríamos esperando.
No cualquier tester puede lograr hacer una estimación ya que depende de muchos factores, fundamentalmente de su experiencia en el área, en proyectos, y de un cierto nivel de conocimientos técnicos, ya que se puede tratar de proyectos manuales o automatizados, para lo cual la misma es distinta.
Muchos, actualmente, estiman de distinta forma, por ejemplo basándose en una planilla de cálculos, en su experiencia o en la experiencia de un tester más antiguo, con puntos de función, con modelos matemáticos, o con el famoso «masomenometro».
No obstante, la estimación es una práctica que se consigue ir puliéndola, tras varias ejercicios consiguiendo modificar parámetros, fórmulas internas, atributos y otros aspectos relacionados.
Lo importante en ésto es saber que la estimación sirve para muchas cosas, por ejemplo como herramienta para sostener una posición frente a otros pares en una mesa de negociación, como herramienta para armar o rearmar una estrategia de pruebas, como herramienta para ayudar al analista funcional o persona encargada de armar la propuesta, a acercarse a un número que le permita negociar con el cliente, entre otros beneficios.
Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).
Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.
Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).
- ¿Te ocupas de armar las estimaciones o es otra persona que lo hace por tí dentro del área de testing?
- ¿Cuáles son las primeras dificultades que encuentras al tener que estimar el esfuerzo de pruebas?
- ¿Utilizas alguna herramienta en particular para estimar las pruebas o solo con una planilla de cálculos te basta?
- ¿Qué experiencia tienes al respecto?
