archivo

Archivos diarios: agosto 16, 2011

¿Cuánto tiempo dedica tu equipo de proyecto a realizar testing?, ¿cuál es la proporción respecto al esfuerzo dedicado netamente a desarrollar?, ¿se utilizan estrategias que automaticen determinados tipos de test como por ejemplo las pruebas unitarias?, ¿vas más allá y aplicas TDD?, ¿usas integración continua?, ¿en qué etapas realizas pruebas?, ¿comienzan desde el mismo proceso de análisis?, ¿cuál es la participación del usuario (o el cliente en general) en las mismas?, ¿en qué proporción es explotaratoria y en qué proporción se basa estrictamente en casos de prueba?, ¿participan personas distintas al equipo de proyecto en pruebas de tipo funcional?, ¿se realiza testing de seguridad, usabilidad, rendimiento?, dicho testing, ¿cuánto es manual y cuánto está asistido por herramientas?, ¿no se realizan pruebas de la aplicación en un entorno de integración del cliente?, ¿realizas análisis estático de código?, en dicho análisis, ¿tienes definidos unos umbrales mínimos de calidad exigibles a las distintas métricas?, cuando vas a entregar una nueva versión de un producto software, ¿haces pruebas de regresión?.

Aunque tal vez todo lo anterior se pueda resumir en par de preguntas, ¿qué nivel de importancia le das al testing en las aplicaciones que desarrollas?, ¿tienes mecanismos para comprobar si se realiza testing y para evaluar la efectividad del mismo?.

El testing se infravalora de manera muy injusta. Bien realizado ahorra muchos problemas y por encima de eso, permite conservar tu imagen y tu dinero.

Hay muchos que piensan que el testing no es ágil y yo respeto las opiniones de cada uno, independientemente de que las comparta o no. Como he dicho muchas veces, lo que no es ágil es tener que repetir trabajo no por evolucionar una funcionalidad o un componente software, sino para corregir errores que perfectamente detectables en etapas anteriores.

Es más ágil (y menos arriesgado) prevenir un incendio que intentar sofocarlo después.

Hace poco expuse en un artículo lo que eran las pruebas de aceptación. En muchos casos, se utiliza indistantemente un término u otro para referirse a lo mismo, en otros, su alcance está solapado. Respeto a quien maneja dichos conceptos como crea conveniente. Tanto en este artículo como en el anterior, les voy a dar el sentido (acertado o no) que creo más adecuado para cada uno.

Para empezar, ¿por qué la confusión entre un término y otro? Pues principalmente porque suelen venir en el mismo plan de pruebas y ejecutado por las mismas personas, sin embargo la orientación de un tipo de pruebas y la otra es distinta.

Las pruebas de implantación están orientadas a una revisión de requisitos no funcionales del producto en un entorno de preproducción de calidad. ¿Por qué de calidad? Un entorno de estas características que sea muy distinto al de producción o cuyos resultados no sean extrapolables al mismo provocará en muchos casos conclusiones erróneas y en otro generará muchas dudas sobre el cumplimiento o no de las especificaciones no funcionales.

De esta forma, se considerarán pruebas de implantación por ejemplo, las pruebas de carga o stress, las relacionadas con la seguridad del sistema, etc…

Si un producto no supera las pruebas de implantación establecidas (para ello se requiere la definición de umbrales de cada métrica cualitativa o cuantitativa que se decida medir) no debería pasarse a producción aunque supere las pruebas de aceptación (que se podrían desarrollar en paralelo a las pruebas de sistema), de las cuales también se podría obtener un feedback interesante para las pruebas de implantación, ya que las acciones de los usuarios en las aplicaciones son imprevisibles y el valor de su testing (adicional a la propia validación de requisitos) puede ser muy importante.