4 razones en contra, y 5 a favor ;-).

Todas las empresas relacionadas con el sector TIC percibimos multitud de señales en nuestro día a día que indican el profundo cambio que ya se ha producido en nuestra actividad, y en el valor que perciben nuestros clientes de ella. El software testing no ha sido ajeno a estos cambios.

Antes del año 2012, el mercado era muy distinto. El negocio del software testing estaba focalizado en el segmento de Gran Cliente. Fruto de una pobre planificación en muchos procesos de creación de SW, y la falta de metodologías ALM basadas en el Aseguramiento de la Calidad, se realizaban proyectos de testing de gran volumen, con continuidad en el tiempo y demanda estable, y con modelos clásicos de gestión de las pruebas, o sea, basados en modelos teórico- predictivos.

El escenario actual ha cambiado. Existe una enorme presión sobre los costes de las áreas de S.I. de las organizaciones, y la Calidad es un factor muy comprometido por esta presión, lo cual nos ha llevado a cuestionarnos si un proceso de verificación y validación independiente implicará un sobrecoste innecesario.

Asimismo, existen nuevos escenarios metodológicos ágiles, donde la filosofía de equipos multidisciplinares y actividades solapadas deja menos cabida al modelo de verificación y validación independiente (ISVV).

Nos encontramos, en definitiva, con proyectos de pequeño volumen, con planificaciones muy ajustadas, condicionados a una dependencia presupuestaria creciente y, por tanto, a una demanda variable más complicada de gestionar.

No es que ya no haya vocación por la Calidad Software. Simplemente, las menores inversiones, las mejores herramientas de creación de software, y las nuevas metodologías de testing ágil nos obligan a cambiar los planteamientos de cara a nuestros clientes. ¿Está fuera de juego la figura del tester?. ¿La verificación y validación independiente, con puntos de control externos al desarrollo, ha dejado de ser útil?. O, yendo más al grano: ¿merece la pena gastar dinero hoy en día en un Servicio de software testing?.

Veamos las 4 razones por las que, a priori, contestaríamos que NO a esta pregunta:

1.  El ajuste presupuestario que viven todos los departamentos de TI se cobra muchas veces una víctima: el software testing.

2.  En una época en que las inversiones se miran con lupa, sigue habiendo empresas que optan por procesos de creación de software sin controles de Calidad, o muy pocos y muy específicos. La justificación es sencilla: ¿por qué me tengo gastar dos veces el dinero? ¿por qué tengo que probar lo que ha hecho alguien que ya cobra por hacerlo bien?. En estos casos, se tiende a asumir mejor que haya más penalizaciones al área de desarrollo, hasta que el desarrollo sea de la calidad esperada. Especialmente en entornos poco complejos o no críticos para el Negocio, hay clientes y organizaciones que aún no han entendido la necesidad de trabajar su SW con Calidad.

3.  Cada vez hay más y mejores suites y ecosistemas de creación de Software, con una evolución constante cada año, que relativizan el valor de otro tipo de servicios de TI. Esto hace el SW cada vez más industrializable, menos personalizado. Y, por tanto, con un índice potencial de errores menor.

4.  Por último, la integración del testing en el propio proceso de desarrollo. Hay nuevas metodologías que exigen adaptaciones inmediatas en ciclos iterativos cortos (agile, lean management), muy efectivas en determinada tipología de proyectos (Véanse http://www.javiergarzas.com/metodologias-agiles) . Un ciclo de validación independiente en estos ciclos de desarrollo cortos sólo tiene cabida si se produce una integración total entre el tester y el equipo de desarrollo. Y esto no siempre es fácil…

Sin embargo, hay muchos argumentos a favor para estimar que el servicio de calidad y software testing sigue siendo relevante y necesario, en muchos casos, incluirlo en nuestros presupuestos.

1.  La primera razón reside en el usuario, en el Cliente. Todos los desarrollos actuales deben seguir de una forma u otra Modelos IPV de percepción inmediata de valor de nuestro SW. Esta agilidad en la percepción del valor por parte del usuario final es imprescindible hoy en día y condiciona cada vez más el proceso de desarrollo de aplicaciones. Ya no se mide si lo que hemos hecho está bien (Satisfacción), sino qué debemos hacer para que nuestro SW sea mejor (Fidelización). Para ello, hay que cuidar la experiencia del usuario, independientemente de las características técnicas o metodológicas del proceso de desarrollo. Es un área natural para el «validador” del software, que debe certificar la aplicación. En el ámbito de las aplicaciones móviles, este aspecto es especialmente importante.

2.  No debemos olvidar que el sector de las TIC avanza sobre algo ya consolidado, y los legacy systems siguen siendo en muchas compañías el gran garante del Negocio. Estos sistemas siguen funcionando en entornos de desarrollo tradicionales, y es difícil implantar nuevos modelos de desarrollo en la mayoría de los casos. En este caso, la figura del validador o certificador con su software testing en un modelo tradicional sigue siendo vital para estas grandes organizaciones, con grandes sistemas. Y con mucho negocio en juego.

3.  Por supuesto, hoy en día hay muchos más puntos de control y aseguramiento de la calidad (Quality Gates) en el proceso de desarrollo de una aplicación. Hay elementos nuevos en la cadena de producción que es necesario probar y que antes no existían. Por ejemplo, en una aplicación de movilidad, probar modelos de comportamiento de la red puede ser esencial para garantizar el rendimiento y funcionamiento de determinadas aplicaciones.

4.  La presión de las fechas en la puesta de producción de un software produce sin duda un mayor deterioro de la calidad del software. Y en la actualidad la presión en fechas, especialmente en el mercado Latinoamericano, es indiscutible. Es imprescindible por tanto la figura del “validador”, aún cuando se hayan definido unos mínimos indicadores de calidad, antes de la salida al mercado de una aplicación presionada por las fechas.

5.  Por último, en entornos M2M, el incremento en la variedad de dispositivos y Sistemas de Gestión (Véase http://www.tid.es/es/Tecnologia/Paginas/M2M.aspx ), y la evolución del mercado de apps móviles implica un crecimiento exponencial de las necesidades del software testing y certificar plataformas y aplicaciones.

En definitiva, creemos que hay escenarios en los que la actividad del software testing independiente es fundamental.

 

Pero hay que tener muy claro que el cambio de modelo de servicios TIC, implica necesariamente un cambio de modelo en los Servicios de Calidad y software testing. Y que este cambio supone a su vez nuevos procesos de Desarrollo de Software, realimentándose todo el modelo en su conjunto con mecanismos de validación y mejora continua.

Por ello, en base a todas estas premisas, hemos cambiado nuestro modelo en los servicios de calidad y software testing, y nuestra nueva respuesta al mercado se basa en 4 principios fundamentales:

1.agilidad

2. adaptación a la demanda

3. bajo coste, y

4 renovación tecnológica.

Sobre estos 4 principios construimos en 2011 nuestra nueva Testing Factory, bajo el lema: el Testing siempre es más barato que la No Calidad.

¿Por qué el Modelo de Testing Factory cumple nuestros 4 principios?. ¿Cómo conseguimos responder a los retos del sector con este Modelo?. Eso es algo que nos gustaría contaros en un siguiente post 😉