Desarrollo de software. Testing, un instrumento infravalorado

¿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.

4 comentarios
  1. Johann dijo:

    ¿Por qué no se hacen test?
    1. No se valora por el cliente: No se asume dicho coste, ya que es responsabilidad del proveedor.
    2. El proveedor: los programadores deben hacerlo bien a la primera
    3. El proveedor: si hay cambios hay que repasar los funcionales (atualizados siempre claro).
    4. El analista: ¿Cómo se hacen los test?

    Creo que lo mejor para esto es empezar por poco, e ir creciendo poco a poco para ir viendo sus ventajas e inconvenientes. Para poder analizar hasta que nivel se hacen las pruebas en cada módulo o parte de la aplicación.

    Yo he usado testing en algunos proyectos (en partes), y el resultado es increiblemente bueno. Incluimos pocos test. Fue un testing algo manual, y nada de frameworks, pero el cliente se quedó maravillado. Ese módulo nunca tuvo una incidencia en los evolutivos (bueno, tenía sólo el 10% de incidencias q el resto de módulo).

    Moraleja: invierte tu tiempo y dinero en algo que puedas reutlizar (tests) y cuando tienes tiempo (al principio). Porque al final del proyecto, tanto las fuerzas como el dinero, flaquea.

    • jummp dijo:

      Es totalmente cierto que los clientes no tienen en cuenta el coste que tiene un desarrollo para ser bien testeado desde las fases iniciales, si bien también hay que indicar que los proveedores no suelen poner encima de la mesa esa necesidad cuando están negociando y da lugar a que se sobreentienda (y con razón) de que si no indican nada es que ya tienen asumido que en su forma de trabajar tienen mecanismos de aseguramiento de la calidad del software que se desarrolla tanto desde el punto de vista funcional, como no funcional, de deuda técnica, para reducir los efectos colaterales en los mantenimientos, etc…

      Yo estoy de acuerdo con pagar porque el software que se desarrolle se haga con un nivel de calidad adecuado, mejor pagarlo ahora que cuando se tengan que estar apagando fuegos.

      Sin embargo y desgraciadamente ni existe cultura de tener en cuenta ese coste en los presupuestos (tanto por cliente como por proveedores), ni existe esa cultura en la mayor parte de las organizaciones que se dedican al desarrollo de software y todo eso pese a que una y otra vez les cuesta muchísimo dinero no aplicar este tipo de técnicas. Desde mi punto de vista es necesario dar formación al personal en materia de testing y tener, por qué no, determinados especialistas que se encarguen de revisar el software y productos que se están desarrollando o dedicar parte del tiempo de desarrolladores a revisar proyectos realizados por otros equipos de trabajo (Google funciona así y no les va muy mal que digamos).

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: