El siguiente debate esta publicado (y activo) dentro del grupo de discusión TESTING & QA en LinkedIn, y me pareció oportuno mostrarlo y plantearlo como para que los que se sientan con ganas, dejen sus comentarios para enriquecer aún más esta discusión profesional:
Tengo el siguiente dilema y quisiera saber que mecanismos me recomiendan para mitigar la situación, desde el punto de vista de Testing. Actualmente se tiene un ambiente compartido para probar diferentes proyectos, FIXes y mantenimientos. lo que implica que el recurso sea compartido y dependiente.
ya se esta trabajando en el tema de instancias adicionales, sin embargo incluso teniendo un numero cuantioso de recursos humanos y un numero elevado de recursos tecnológico. Hay un tema de priorización y planificación, estamos también considerando que no existe un rol de change management, y el dilema es que estos temas tienen diferentes dueños y como cualquier cliente esperan los resultados comprometidos, que pueden ser afectados por la misma integridad del ambiente. ¿Que mecanismo o que metodología se pudiera aplicar en estas condiciones?
Les agradecería muchísimo cualquier comentario referente al tema.
A continuación, les dejo dos comentarios, el primero de ellos por parte de un miembro del grupo y el último, lo acabo de dejar yo.
Comentario 1
Te resumiré básicamente como trabajo actualmente….
Creo que siempre se debe tener un ambiente espejo de producción, quizas por recursos muchas veces este no sea igual en infraestructura, pero si debe ser lógicamente iguales. Este ambiente debe ser administrado igual que producción, es decir que los desarrolladores no tengan acceso a el para meterle manos (cosa que les encanta), a este ambiente espejo llega todo lo que se va a instalar en producción relamente, se hacen las pruebas necesarias y se da el ok para ir a producción.
Segundo, se debe tener ambiente de desarrollo, el cual se le mete mano instalando e iterando cuanto sea necesario, pero sin hacerle cambios en caliente que «Luego se empaquetarán», es abierto pero tratado con responsabilidad para que no se rompa y siga siendo fiel a producción de todas maneras.
Basado en esto la cadena de como pasar a producción sería:
Ambiente desarrollo –OK QA –> Ambiente de pre producción o staging environment — OK QA –> producción
Nosotros tenemos 2 ambientes de desarrollo actualmente que caen en staging cuando se da el OK.
Puedes leer sobre trenes de releases, que es una forma de ir pasando todo lo que está OK para producción.
No se que más te puedo decir, no es un tema de metodologías es creo dependiendo de la cultura de la organización. Con respecto al tema del rol de change management, creo que lo puede tomar el área de QA sin problema en conjunto con los ingenieros de sistema.
Siemrpe comento esto, creo que tienes una oortunidad muy grande para empoderar a QA como debe ser, debe ser el área encargada de velar por la calidad de lo que se hace y no solo testear código.
Cualquier duda me comentas si algo no se entiende, pero dale que tienes una oportunidad de oro.
saludos
Mi comentario:
Hola Carlos/Sebastian
Muy bueno el comienzo para este debate.
Antes de expresar lo que pienso al respecto, me gustaría Carlos que nos comentaras algo en relación con los siguientes aspectos que me vinieron a la mente:
– ejecutan procesos de integración contínua?
– cómo participan los probadores/testers en este proceso de CI?
– cómo interactúan los probadores/testers con los desarrolladores en el proceso de CI?
– comparten alguna herramienta los equipos de desarrollo y de probadores/testers?
– los desarrollos son bajo modelo cascada/predictivo ó ágil?
Por excelencia, el proceso de pruebas debería ser independiente, a veces la organización lo permite y hasta facilita mecanismos para su evolución y mantenimiento, mientras que otras veces, hay que «compartir» con el área de desarrollo nuestro testing. Frente a esta situación, los dos responsables de área deben definir y establecer las políticas y procedimientos para el tratamiento de las diversas actividades que realizan ambas áreas con el objeto de «no pisarse», no generar conflictos de ejecución y mantenimientos de procesos, y ni hablar del tema «datos» y sus «propietarios».
Respecto del ambiente de «pre producción», tal como lo plantea Sebastian, es muy importante ya que a nivel estratégico, es ahí donde podemos comprometer al «usuario final» (key user) para que realice su UAT y nos ofrezca su conformidad. Si partimos de esta base, todo ésto puede servirnos de argumento al momento de solicitar la creación de este entorno.
-¿Pensaron en la posibilidad del outsourcing y hasta incluso con solución «cloud»?
Después que tu devolución, sigo debatiendo con Uds el tema, ¿les parece?
Abzo
.
¿Qué opinan?
¿Alguna experiencia similar?
Hola, como estan. Despues de leer sus comentarios quise compartir mi experiencia con los ambientes de QA y los desarrolladores.
Bueno les contare que donde actualmente trabajo el area de Calidad tiene sus propios ambientes de pruebas, no son una replica exacta de producción pero tratamos de mantenerlas lo mas actualizadas posible, el equipo de desarrollo tambien cuenta con sus ambientes propios, hasta aquí la historia suena bonita, pero debido a cambios en la gerencia y un analisis de satisfaccion a las demas areas respecto a TI se llegó a la conclución de que somos un «poco» lentos al momento de entregar los requerimientos o proyectos al usuaro, la nueva directiva decidio que la mejor manera de agilizar las cosas en TI era elimar la fase de pruebas de calidad de los requerimientos de menos impacto «Para muchos QA es un cuello de botella» aunque el equipo de QA mostro su descontento no pudimos hacer mucho, era orden directa del «Olimpo».
Dejenme decirles que no les resulto muy bien… ya que despues de hacer el cambio el nivel de incidencias post-pase aumentaron, por lo que despues de casi un año decidieron que nosotros, como Qa, deberiamos prestarles nuestros ambientes al ser estos una replica de producción donde los desarrolladores no han metido mano «aun», despues de darles nuestros ambientes hicieron lo que quisieron con ellos asi que no les sirvío de mucho.
Actualmente la premisa no ha cambiado, pero por lo menos nosotros volvimos a ser los unicos administradores de los abientes de QA, nos encargamos de los despliegue y hemos retringuido sus privilegios, por el momento estamos en el proceso de que entiendan «QA es tú Producción».
Bueno en fin, hay muchos cambios que se han realizado y aunque no estemos deacuerdo del todo, apoyamos y tratamos de mejorar en lo que se pueda.
PD: En una nueva encuesta de satisfacción nos han vuelto a calificar de lentos, pero esta vez fue por la rapidez en la atención de incidencias, como les dijes los errores post-pase aumentaron, asi que no se que se les ocurrira este año para ser mas «rapidos».
Muchísimas gracias por tu comentario.
En un rato lo estaré copiando dentro del debate y así generar más discusión.
Te mando un abrazo