Testeo, cerdos y gallinas
¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...
Mi Twitter
Creo, aun así, que es interesante tener un especialista en testado, alguien que va más allá de validar los casos de test y que disfruta probando cosas inverosímiles para llevar al límite las aplicaciones.
ResponderEliminarEso sí, por ejemplo donde yo trabajo no hay suficiente cantidad de trabajo ni de personal para tener un equipo dedicado, como en otras muchas empresas pequeñas de desarrollo.
Bingo, "las causas" es el secreto de la calidad. Aunque el mejor departamento de la calidad es el que no existe, supongo que se debe de probar sobre varias plataformas y para las plataforma si debe de haber especialistas formados en plataformas actualizados, que deben de realizar las pruebas de validación.
ResponderEliminar¡Saludos!
Dependiendo del tipo de testeo se puede argumentar lo contrario.
ResponderEliminarEn mi opinión en el caso ideal tendríamos:
- pruebas unitarias: desarrolladores
- pruebas de integración: desarrolladores + QA
- pruebas de rendimiento: performance analysts
- pruebas funcionales: QA
Como se puede ver, separo asigno roles de análisis de rendimiento y funcional a gente completamente ajena a los desarrolladores. ¿Por qué? Pues porque añade diferentes puntos de vista a la aplicación. El punto de vista de un desarrollador a la hora de testear funcionalmente una aplicación está sesgado. Es decir, por inercia va a probar la aplicación de la forma que él la ha concebido.
Por el contrario, introducir nuevas personas y equipos que no asumen ningún tipo de precondición, ni conocen internamente las aplicaciones, añade un grado de objetividad muy importante. El testeo estará mucho más cercano a lo que el usuario final hará, y eso es algo muy importante. Por eso en muchas empresas (como en mi anterior) que tienen equipos de QA no contratan desarrolladores para estos equipos, sino personas con conocimientos de informática pero no de tecnologías concretas.
Lo mismo, aunque en menor grado ya que aquí necesitas gente realmente especializada, pasa con respecto al rendimiento.
climens, la falta de cantidad de trabajo... ¿no es por qué no planificamos que necesitamos ese equipo de testeo para realizar el proyecto? Así podemos bajar los precios... ¿a que coste?
ResponderEliminaralyce, la primera vez que juego al bingo, e alegro de acertar :) las causas es lo que debe arreglar la mejora continua.
martin, totalmente de acuerdo con tus orientaciones de perfiles.
Antes que nada, felicidades por tu blog y la comunidad que habeis formado. Por lo que yo te puedo contar, en nuestra división contamos con un experto en testeo de software pero la política de la empresa hace que no vaya más allá de su labor, es decir, que no se implique en el desarrollo, cosa que debido a su experiencia puede ser un beneficio a partir del primer momento.
ResponderEliminarPor otra parte, la vida laboral de estas personas, según dicen ellos, es muy estática y necesitarían algún tipo de incentivo/cambio para no quedarse atrapados en un callejón sin salida.
¡Saludos!
Me parece clara la rentabilidad de una persona dedicada al testeo integral fuera del equipo de desarrollo. Tiene una pega: que a los demás no les parece tan clara y por tanto es difícil disponer. Sin embargo, pienso que el ahorro que supone la detección temprana de errores y las mejoras que puede aportar (no sólo al desarrollo, sino también a la visión de la empresa de desarrollo) justifican con creces la inversión de gente para un equipo de test.
ResponderEliminarHay un problema: si la aplicación se utiliza en un proceso complejo, es difícil probarlo todo, porque quieres emular a un usuario que lleva años haciendo lo mismo y se conoce todos los trucos del negocio. No puedes imaginar por dónde te va a salir. Esto implica documentar casos de prueba muy extensamente, pero resulta caro y no tengo claro que el cliente te cuente todos los trucos.
Hay una opción mixta: involucrar a gente de tu empresa en las pruebas que hace el cliente. Pienso que se puede aprovecha mucho: ves lo que hace, ves cómo se quema, lo que le irrita, lo que no ve.
[Adivina con quién he estado sentado dos horas esta mañana mirando lo que hacía. Hubiese aguantado más de no ser por el hilo musical. Por cierto, que os ha defendido]
Completamente de acuerdo con Climens, un especialista en testado sería interesante y importante tener en muchos equipos...
ResponderEliminar