Erróneamente, desde mi punto de vista, siempre se tiende a llamar "proceso de desarrollo" a la forma de trabajo que se implementa en un proyecto, pero si miramos más globalmente, desarrollo no es la palabra más exacta para definirlo, ya que hay muchos más departamentos o secciones que participan en él. Más bien lo llamaría, por ejemplo: "proceso de trabajo", "forma de trabajo" o "ciclo de trabajo".
Cuando pensamos en una nueva manera de implementar un proceso de trabajo en el proyecto, tanto si es desde cero como si ya está avanzado y simplemente tenemos que cambiarlo para que funcione mejor, tienen que convivir dos "subprocesos", que ahora si que llamarían "subproceso de desarrollo" y "subproceso de testing". Estos dos procesos tienen que ser independientes y a su vez dependientes, lo explico mejor:
Conceptualmente, los dos subprocesos son independientes ya que se tienen que gestionar y crear diferenciados. Cada uno dependerá de un departamento, cada uno se implementará con una serie de herramientas y cada uno tendrá prioridades diferentes, pero a su vez, los dos son dependientes entre ellos ya que en ciertos puntos se tienen que entrelazar.
Cuando se terminen ciertas fases del "subproceso de desarrollo", tendrán que ponerse en marcha ciertas fases del "subproceso de testing", como por ejemplo, en el caso de que un desarrollo de una determinada funcionalidad esté finalizado. En ese punto "acabará" una fase del "subproceso de desarrollo" y se activará la fase de pruebas de ella dentro del "subproceso de testing".
Uno de los "errores" (entre comillas) de muchas implantaciones es que solo cuentan con un "proceso de desarrollo" que con el tiempo, se acaban cayendo por su propio peso, ya que sin esa parte de testing, esta vendido. Por eso, opino, que hay que intentar buscar otra nomenclatura para este tipo de procesos que puedan ser menos equívocos y sobre todo, encontrar una coordinación perfecta entre los que yo, personalmente, llamo "subprocesos" (testing y desarrollo).
Las personas que nos dedicamos a la calidad del software tenemos que intentar entrelazar los dos subprocesos y buscar una afinidad entre ambos, para que todo vaya más fluido y no nos encontremos con puntos muertos, que frenen el ciclo de vida de la aplicación. Si esto ocurre, los primeros perjudicados seremos nosotros ya que un proceso fluido y coordinado hace que la calidad del software sea mucho más elevada, el trabajo de todo el proyecto sea más vistoso y sobre todo, más efectivo.
0 Comentarios