Seleccionar página

¿Qué piensa el Desarrollador del Tester?

Insights -> Tendencias y Actualidad

Hay cosas que nunca cambiarán.

Si alguien verificase constantemente tu trabajo, devolviéndote lo que «no has hecho correctamente» para que lo corrijas, seguro que estarías «a la gresca» con él. Constantemente mantendríamos una actitud defensiva, cuando no algo más. ¿Por qué entre los equipos de Desarrollo y los de Pruebas va a ser diferente?.

A estas alturas, sobra decir que las Pruebas de Software deben ser una fase obligatoria dentro de todos los modelos de Ciclo de Vida del software, y que el Plan de Pruebas debe ser un elemento esencial en la entrega del Desarrollo. Pero normalmente esta actividad se deja para el final, es decir, cuando ya hemos producido un software de mala calidad que hay que corregir. Los problemas son de sobra conocidos: en esta fase, o no hay dinero, o no hay tiempo, o el coste de corregir estos errores se multiplica exponencialmente. Y empiezan los clásicos problemas de entendimiento entre los distintos equipos: ¡pues en nuestro entorno funcionaba perfectamente!, ¡no habéis entendido cómo tiene que funcionar!, ¡esto no es una incidencia!...

Hoy en día, queda demostrado que el 80% de los errores del software provienen de las primeras fases del ciclo de vida (definición, diseño, modelado de entornos, criterios de aceptación…). Y por esta razón (una de muchas) surge el concepto de QA, Aseguramiento de la Calidad del Software. Mientras que las pruebas se realizan en una de las fases del ciclo de vida del software, normalmente al final, las actividades de Aseguramiento de la Calidad del software se ejecutan en todas las fases (que incluye la verificación y validación de la fase de Pruebas). Es decir, ambas actividades (Desarrollo y Pruebas) permiten verificar y afirmar la calidad del producto final.

Para conseguir esta acción coordinada, es necesario definir estándares y establecer procedimientos que permitan medir primero, y comparar después, lo alcanzado durante cada una de las fases, cumpliendo así con este aseguramiento.  Nos obligamos a que los procesos de calidad del software no sean algo aislado del proyecto, sino parte del mismo, gracias a un proceso metodológico aplicado desde las fases iniciales.

En resumen, un proyecto de desarrollo software sin actividades de QA en cada una de sus fases, desde el inicio hasta el final, disparará considerablemente su coste, exigirá un esfuerzo mayor en la fase de Pruebas. El 76% de los proyectos que fracasan es debido a una baja calidad de los requisitos iniciales del software y a una falta de procedimientos de QA.

Esto no elimina la necesidad de que exista un área de Pruebas (o testing). Simplemente la integra con el área de Desarrollo en un proceso cuya única finalidad es la  S A T I S F A C C I Ó N   D E L   C L I E N T E.

En Panel somos defensores de la necesidad de independencia del equipo de Pruebas, ajeno al equipo de Desarrollo, pero está claro que ambos tienen que relacionarse de una forma «amigable» desde el principio. La actividad de QA no puede formar parte exclusiva de la Unidad de Desarrollo, y tampoco puede formar parte de la Unidad de Producción. Debe ser una unidad independiente con la habilidad de no generar conflictos, para que sean vistos como facilitadores del trabajo de Desarrollo desde el comienzo del proyecto, como aliados, de tal forma que se garanticen equilibrios de fuerzas como este:

Que-tiene-Desarrollo-a-favor-y-en-contra-de-las-pruebas

Y por supuesto, esta concepción de la Calidad del software es imprescindible para la adopción de nuevas metodologías de producción como SCRUM o Lean Management.

Javier López-Camacho

Javier López-Camacho

Javier es co-fundador de Panel Sistemas y Director del Área de Aseguramiento de la Calidad Software y Testing. Puedes seguirle en Twitter , visitar su perfil en Linkedin o contactar con él vía e-mail en esta dirección.

Comentarios

4 Comentarios

  1. Alvaro

    Las pruebas son las primeras que desaparecen cuando el margen peligra o la facturación baja. Y, como bien dices, deberían ser obligatorias en todo proyecto.
    Supongo que las personas que deberían integrar el equipo de pruebas serían del tipo verde según los modernos patrones conductuales. O búhos, que sería lo mismo. Con un perfil procedimental, indirecto, observador y poco agresivo.
    Así el conflicto se hace más «amigable».

    Responder
  2. Javi Pérez

    ¡Buen artículo!, esto va en línea con tratar el testing como un proceso transversal dentro del proyecto, y no como se ha venido haciendo tradicionalmente, que era simplemente una fase más del ciclo de vida de un desarrollo software.

    Responder
  3. Javier López

    Gracias Javi!

    Habría que preguntar a los que llevan el día a día, los que se lo curran, a ver si se ven en color naranja o azul.

    Responder
  4. MNicolao11

    Ni tener un «censor» en la chepa y ni tener un «aliado» al otro lado del muro (de la entrega). El objetivo global está clavado (satisfacción / valor para el cliente), creo que el arte está en conseguir que esto se refleje en un interés mutuo para desarrollo y pruebas, del tipo: pago por valor entregado. Cada especialista tiene sus intereses y capacidades, que las aplique de forma proactiva (buscando generar valor), no de forma reactiva (buscando defender un castillo), ese es el nudo gordiano de la cadena de valor extremo a extremo. Buen articulo.

    Responder

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This