10 Buenas prácticas de Testing

Probar un sistema implica simular ese sistema, asegurarnos de que tal sistema hace lo que debe y no hace lo que no debe. Implica un análisis con el propósito de encontrar problemas y errores, medir la funcionalidad y la calidad, capacidades, etc.

Una cuestión muy importante a considerar es que no se puede probar todo. No existe el producto perfecto, siempre tenemos que hablar en términos relativos o porcentuales, como por ejemplo, tasas de error. El proceso de pruebas es un proceso creativo y difícil; es importante planificar qué se va a probar, definir qué escenarios se va a probar. Finalmente, es importante dedicar tiempo y recursos suficientes a dicha tarea.

Diez buenas prácticas:

1.- Haz de la autoevaluación del trabajo de cada uno una responsabilidad de equipo. Insiste en que Test y Evaluación (T&E) forme parte del trabajo diario de cada uno (utiliza smoke tests para apoyarte en ello). Es necesario garantizar la producción de trabajo de calidad todo el tiempo.

2.- Establece cuanto antes un plan integral de pruebas y evaluación. Establece pautas, objetivos y entregables de cada tipo de test. Puede establecerse en sesiones RAD (Rapid Application Development) al comienzo o en sesiones de tormenta de ideas.

3.- Realiza un parte preventivo de pruebas de todo el trabajo especificado. No dejes nada sin cubrir; haz escenarios de todo; esto también te ayudará a entender mejor los requisitos. Inspecciona periódicamente los test y su adecuación al comento de desarrollo actual. Desarrollo y pruebas van de la mano: crea los casos de prueba antes de desarrollar.

4.- Utiliza las pruebas como indicadores de progreso. Que las pruebas te sirvan como indicador seguro de que algo está hecho y funciona.

5.- Haz un inventario de los objetivos de las pruebas y diseña para “testabilidad“. Diseña una lista de qué debe ser probado antes de diseñar o implementar otra cosa.

6.- Prueba desde el principio y a menudo. Así retroalimentas el desarrollo y detectas problemas en el momento en que ocurren.

7.- Diseña y desarrolla test como si fueran entregables. Con la misma disciplina y método. Desarrolla test en paralelo con el código, actualiza los test cuando el producto cambia. Si escribes los test demasiado pronto, luego habrá que redefinirlos, así que tampoco es bueno adelantarse demasiado. La ingeniería de desarrollo de test es igual que la ingeniería de cualquier producto software.

8.- Provee herramientas y soporte adecuados para el testing.

9.- Mide costes, cobertura, resultados y efectividad de los test. Así entenderás mejor el proceso de testing y podrás controlarlo y gestionarlo.

10.- Entrena y gestiona al equipo. Así se tomarán el testing como algo serio y conocerán qué se espera obtener de dicha tarea. El gestor indica guías, la dirección a seguir, qué pasos dar, etc.


Referencias:

The Little Book of Testing, Vol I, varios autores.

Errores comunes en desarrollo software (IV y final)

Por parte del producto como objetivo final nos encontramos con los siguientes problemas:

Requisitos de “placa dorada”. Requisitos no tan importantes para el usuario como nosotros pensamos, obsesión por el desempeño y otros factores que como informáticos puedan parecernos clave pero que un usuario no valorará tanto. Alargan la calendarización, y si les damos demasiada importancia, restaremos valor a otros requerimientos clave para el cliente.

Inestabilidad de los requisitos. Algo presente siempre, por lo tanto es fundamental vigilar y controlar los cambios en los requisitos. Alarga la calendarización.

Desarrolladores de “placa dorada”. Los programadores suelen estar ansiosos por utilizar una nueva tecnología, herramienta o técnica que ha aparecido en el mercado, aunque no sea necesaria para el proyecto. La investigación en nuevos campos conlleva gran incertidumbre, y esto alarga la calendarización, además de aumentar riesgos.

Negociaciones de tira y afloja. Es extraño que cuando se negocia un deslizamiento en la estimación de un producto automáticamente alguien añade nuevas funcionalidades, lo cual invalida la nueva estimación…

Desarrollo orientado a investigación. Si quieres desarrollar proyectos, no te sumerjas demasiado en investigar nuevos algoritmos, técnicas, etc. El riesgo de fracasar o ralentizar el proyecto es muy elevado. Desde luego que, si no te queda más remedio hazlo, pero cuenta con el riesgo que ello conlleva y desde luego no esperes terminar el proyecto en un tiempo récord, precisamente.

Finalmente, en cuanto al factor tecnológico:

Síndrome de la bala de plata. No dejes que los equipos confíen demasiado en una nueva técnica, herramienta, etc. como si fuera la solución de todos los problemas. Las balas de plata no existen en informática; no creas lo que te venden los comerciales… 😛

Ahorros sobreestimados de nuevas herramientas o métodos. Las organizaciones no mejoran su productividad a grandes saltos, sino en pequeños avances; entre los inconvenientes de utilizar nuevas tecnologías están: riesgos de utilizar algo tan novedoso que pueda no tener soporte para el cliente, adecuación, curva de aprendizaje, etc. Otro ejemplo de esto podría considerarse el reutilizar software. Nuevamente, el ahorro no es tan grande como se podría prever en un primer momento.

Cambiar las herramientas a mitad de proyecto. Casi nunca funciona bien. La curva de aprendizaje, rehacer el trabajo ya hecho, errores inevitables cometidos por el desconocimiento de la herramienta… ralentizan el proyecto.

Falta de control automático del código fuente. Expone al proyecto a riesgos innecesarios. Es fundamental utilizar un buen software de control de versiones, junto con una buena política de gestión de configuraciones. Muchas empresas se conforman con adquirir buenas herramientas de control, pero se olvidan de que sin una buena política de gestión de configuraciones la herramienta no es más que un soporte, algo que puede considerarse incluso como un elemento lelo si se utiliza sin cabeza.

Es posible que redacte en próximas entregas lo que bajo mi punto de vista sería una solución a todos estos problemas. No quiero decir con ello que tenga la solución a todos los problemas, que sea un gran consultor ni nada parecido; simplemente reflejaré lo que los autores aconsejan sobre esto y expondré qué cosas se podrían hacer para paliar estas situaciones. Y desde luego que exponer una solución no es el final de todo. No existen balas de plata, recordemos, y la aplicación de tales soluciones será unas veces más sencillo y otras más complicado, requiriendo en algunos casos de la implicacion de todo el equipo para alcanzar el éxito. Tampoco existen garantías absolutas, pero sí podemos aumentar nuestras posibilidades, y  por esto bien puede merecer la pena el esfuerzo.

Errores comunes en desarrollo software (III)

Actividades fundamentales acortadas. En cierto modo, una consecuencia del error anterior. Cuando hay prisa, se recortan las tareas que no producen código directamente. Habitualmente las candidatas son: análisis de requisitos, diseño y elección de la arquitectura, curiosamente las fases con mayor riesgo y más claves del proyecto.

Diseño inadecuado. Viene un poco en consonancia con lo que acabamos de anotar: diseños realizados con prisa, no atendiendo debidamente al tiempo requerido conducen a malos productos. Un diseño completo requiere varios ciclos.

Acortar tareas de calidad. Cuando hay prisa, tratan de acortarse tareas de revisión de código y testing. Eliminar un sólo día de tareas de calidad puede alargar el proyecto entre 3 y 10 días más.

Controles de gestión insuficientes. Antes de tratar de mantener un proyecto en el buen camino, pregúntate si el proyecto está en dicho momento en el buen camino.

Convergencia prematura o demasiado frecuente. Cuando se acercan fechas de entrega del producto, es necesario realizar tareas de mejora de desempeño, documentación, preparación de la instalación del producto, etc. Se suele tender a converger demasiado pronto en el sentido de empezar a preparar la release demasiado pronto, lo cual es contraproducente porque luego habrá que volver a converger alguna vez más con nuevas mejoras producidas y además condiciona negativamente al proyecto. Realmente es complicado cómo decidir cuándo converger: no puede ser demasiado tarde porque hay un buen número de tareas propias de fase de release, como las que hemos apuntado antes, que deben ser realizadas, pero si se trata de integrar el trabajo demasiado pronto luego habrá que integrar nuevas funcionalidades y bug fixing realizado.

Omitir tareas necesarias de las estimaciones. Es fácil olvidar tareas menos visibles pero necesarias, que luego añaden tiempo a la calendarización. Una buena medida sería guardar información histórica de anteriores proyectos para tener algo más de información acerca de qué se necesitó realizar y poder estimar con más conocimiento de causa.

Planear ponerse al día más adelante. Si una estimación resulta no ser adecuada en la realidad, las estimaciones de las tareas dependientes de ella deben ser reajustadas en consonancia, y no esperar que el proyecto avance más deprisa a partir de tal momento. Es razonable fallar una estimación: uno aprende del proyecto a medida que éste avanza. Es necesario reajustar estimaciones también cuando cambian los requisitos.

Programar a lo loco. Olvidarse de realizar un diseño bien trabajado. Sin razonar. Al más puro estilo ensayo y error. Esto conduce a tirar mucho trabajo que no vale, a perder mucho tiempo en experimentación poco productiva. Esto, que parece un error de novato, es a lo que conducen las calendarizaciones ambiciosas, cosa que está a la orden del día en muchas empresas.


Referencias:

Steve McConnell: Rapid Development, Taming Wild Schedules