Estefanía Fernandez Muñoz no necesita presentación, es una de las caras visibles en QA especializado en automatización a nivel nacional. Actualmente lidera el área de QA dentro de SDOS y publica asiduamente en su blog: Una QA en Apuros
Su experiencia le ha llevado a ser especialista en herramientas como Appium y Selenium. Hablar con ella, es siempre aprender algo nuevo. Hoy, nos hace el honor de participar en el tercer QATalk de la Comunidad.
Llevas muchos años involucrada en ámbitos de automatización de pruebas funcionales, a día de hoy, ¿cómo ves este tipo de pruebas?
Creo que este tipo de pruebas cada vez son más importantes y cada día aparecen nuevas herramientas para desarrollarlas, sobre todo en el ámbito automático. He de decir que a lo largo de mi trayectoria profesional he aprendido mucho sobre este tema, sobre todo con Selenium y Appium y eso me ha hecho tener una visión muy amplia tanto de pruebas funcionales web como de movilidad (y es algo que intento plasmar en mi blog para que la gente que me sigue pueda aprender de ello). También es cierto que ha sido el tipo de prueba en la que más me he especializado y a veces también he echado de menos el tener más experiencia en pruebas de integración, seguridad o rendimiento que no suelen ser demasiado comunes en muchas empresas.
Uno de los puntos que suele tratar la gente, es la falta de comunidad, al final hay muchas herramientas y cada día salen nuevas, pero no se afianzan en el mercado, ¿Qué pautas deberíamos de seguir para centralizar todo esto?
Pienso que eso depende un poco de la moda o la tendencia que haya en una herramienta u otra y que la organización en la que estés te deje desarrollarte con esa herramienta o no. Yo siempre he intentado mantenerme al día de todas las herramientas que van saliendo y al menos hacer alguna prueba básica, un “Hola Mundo” con ellas para saber cómo funcionan, pero es cierto que al final cuando tienes que seleccionar qué herramienta escoger, como ha sido el caso en el que me he enfrentado en SDOS para elegir herramienta para pruebas automáticas en movilidad, tiendes a coger una herramienta que lleve tiempo en el mercado, que tenga releases constantes, que tenga una comunidad detrás que dé soporte y que haya información sobre ella.
Todo esto no se consigue por arte de magia, sino que todos tenemos que ser conscientes de que si estamos apostando por una herramienta, igual que nos estamos nutriendo de la comunidad debemos aportar todo lo que podamos a ella: crear issues en proyectos, responder a dudas o a problemas de usuarios en foros, crear post de información sobre esas herramientas…todo eso es muy importante para mantener viva la comunidad y seguir contribuyendo a ser cada día más grandes y mejores.
En tu caso, ¿cómo viviste esa transición de la realización de pruebas manuales a las automáticas?
Siempre he tenido bastante claro el valor que aporta la automatización, desde mi Trabajo Fin de Máster en el que me dediqué a aprender sobre todos los tipos de pruebas existentes que había y qué herramientas te podían ayudar a automatizar ese tipo de pruebas. He de decir que las pruebas manuales son muy importantes en todos los procesos y son la base inicial que siempre hay que tener en un proyecto antes de ponerte a automatizar, y eso es algo que intento transmitir a todo mi equipo. Sin definir qué pruebas tenemos que hacer de forma manual no deberíamos empezar a automatizar, y una vez que se tengan definidas no se puede empezar a automatizar a lo loco, sino que hay que analizar qué casos de prueba manuales son los más repetitivos o nos van a aportar más valor al tenerlos automatizados y, entonces, en ese caso, es cuando se automatizan.
Esta es la filosofía que he intentado seguir y que me han ido enseñando en las empresas en las que he pasado y es la que intento cada día transmitir a mi equipo. Como último apunte, la automatización es muy buena pero nunca va a ser capaz de sustituir a las pruebas manuales y al valor que aporta una persona haciéndolas y eso es algo muy importante que hay que tener interiorizado.
Parece, que desde hace unos años, se está incrementando el presupuesto de las empresas en pruebas, ¿qué te parece?, ¿desde el sur se percibe esta afirmación?
Coincido con tu afirmación, parece que poco a poco va calando un poco que hay que hacer pruebas, que hacer pruebas es algo “rentable” a la larga y que un proyecto no debería ir a producción sin que antes un equipo de QA se haya asegurado que todo funcione correctamente. Esto parece que es así no sólo en la filosofía que se está creando en las empresas sino en los puestos de trabajo que cada día se van viendo en el mercado buscando nuevas personas para departamentos de QA, aun así, sigue habiendo clientes que siguen sin percibir la importancia y el valor que aporta tener QA y que te siguen preguntando para qué sirve esto y por qué tengo que tener una persona asignada en mi equipo haciendo pruebas, cosa que luego sigue con la pregunta de: “¿Es que los desarrolladores no saben programar bien y ya sabes que van a tener errores?” y no es ese el caso.
En esos momentos es cuando tiras de mano izquierda y le explicas de la mejor forma a los clientes que una persona que desarrolle no debe probar él mismo porque sabe cómo lo ha desarrollado y no va a probar otras formas de probar su desarrollo más que la que ha pensado en su cabeza. También está el caso contrario en el que el cliente sabe y conoce el valor que da QA y directamente lo pide y lo exige en sus equipos.
En SDOS creaste el departamento de QA desde cero, ¿qué pautas intentas inculcar en tu equipo? ¿Trabajáis más con automatización o hacéis pruebas mixtas? Cuéntanos tu experiencia inculcando cultura de calidad en una empresa.
En SDOS he tenido la suerte de poder crear el departamento de QA desde el principio y asentar las bases y eso me ha gustado mucho como experiencia tanto personal como laboral. Desde el principio me han dejado mucha libertad y me han ayudado mucho a entender la cultura de la empresa, los tipos de proyectos en los que trabajamos y las herramientas y tecnologías que tenemos en nuestro día a día. El entender bien todo eso ha sido la clave para saber cómo abordar y cómo empezar a asentar los cimientos del departamento.
Las pautas que siempre he intentado inculcar a todo el equipo es que QA no sólo tiene que hacer piña con el equipo del proyecto en el que trabaje, sino también entre nosotros, entre los “QAcitos” que estamos. He intentado asentar las bases tanto de la parte manual como de la automática para que todos trabajemos de la misma forma en todos los proyectos (con alguna excepción que siempre hay en algún cliente concreto que quiere algo diferente) para que, de esta forma, cuando alguna persona del departamento tenga un problema no sea problema de uno, sino de todos. Todos tenemos que ser los responsables de aportar, tanto al Stack tecnológico que tenemos como al centro de conocimiento que poseemos donde está toda la documentación necesaria para todos en la que se describen desde qué es QA hasta qué herramientas de seguridad o rendimiento hemos utilizado con algún ejemplo paso a paso de cómo utilizarlo.
También he intentado fomentar mucho las formaciones internas entre el equipo y que no sólo se centralicen en mí, sino que cada mes, una persona diferente del equipo tiene que dar una formación sobre un tema que le guste y que nos aporte a todos y la exponga delante de sus compañeros. Hemos tenido formaciones muy interesantes y creo que esto es algo que nos ha aportado mucho valor como equipo y para seguir nutriéndonos. Además de eso, muchas de estas formaciones han terminado como un artículo en el blog corporativo no sólo para nosotros sino para cualquier persona que tenga curiosidad sobre un tema que hemos tratado y quiera aprender al igual que nosotros.
En cuanto a la parte de las pruebas, solemos hacer pruebas mixtas, tanto automáticas como manuales, la mayoría de las veces funcionales y utilizamos Appium y Selenium como herramientas automáticas. Desde el primer día intentamos enseñarle al cliente lo importante que es la automatización y todo lo que le puede aportar.
Respecto a mi experiencia inculcando la cultura de calidad, al principio fue difícil porque fue un cambio de mentalidad, tanto en los equipos como en los jefes de proyecto para que lo entendieran y lo trasladaran a los clientes. Poco a podo hemos ido recopilando información, datos e informes para hacer ver que QA aporta mucho valor y se entienda y respete dentro de la organización.
En SDOS, ¿trabajáis con metodologías ágiles?
Sí, solemos trabajar con metodologías ágiles, principalmente Scrum. Lleva ya años implementado en la organización y nos hemos adaptado todos a la perfección.
Tu trabajo, es mano a mano con equipos de desarrollo. Hace unos años, nos veían con cierta “reticencia”, pero, cada vez más, tienen la visión de que les ayudamos a hacer mejor su trabajo, ¿cómo es tu día a día con ell@s?
Desde hace varios años, estoy centrada en la parte de ser QA dentro del equipo de desarrollo en lugar de ser una parte externa que se dedica a validar las entregas que les va haciendo un equipo de desarrollo al que no suelen conocer. La verdad es que, habiendo estado en las dos perspectivas, prefiero mucho más estar dentro del equipo que fuera porque se aporta mucho más valor, no sólo con el equipo sino con el producto y al final el objetivo común tanto del equipo de desarrollo como de QA es sacar el mejor producto posible que se pueda conseguir entre todos. Esta es la perspectiva que intento transmitir día a día con los equipos en los que participamos y que estaban acostumbrados a trabajar sin QA en la mayoría de los casos y que poco a poco se han ido haciendo a que tienen que trabajar con nosotros y que somos uno más.
Los primeros días en los que QA llega a un equipo que no está acostumbrado a trabajar con este perfil suelen ser difíciles, primero tienes que conocer a la gente del equipo, el producto, el proyecto, al cliente en muchos casos y el cómo se hacen las cosas dentro del equipo de desarrollo. Cuando conoces eso tienes que hacerle entender al equipo día a día que necesitas tiempo antes de hacer una entrega para validar, que cada historia de usuario o ticket que se desarrolle tiene que pasar por QA y cumplir una serie de requisitos mínimos, que hay que utilizar herramientas de integración continua para las entregas porque no nos vale con “he probado la aplicación que Fulanito me ha dado a las 12:03 generada en su equipo” sino que tenemos que saber qué build concreta estamos probando, la hora, los cambios que lleva, el entorno… inicialmente son muchos cambios pero en dos o tres sprints el equipo ya se suele acostumbrar a la nueva forma de trabajo y a considerarnos como uno más y ver cómo se consigue eso es muy gratificante.
Además, como algo personal, siempre intento ganarme al equipo de desarrolladores los primeros días trayendo chuches, chocolate y ese tipo de cosas para hacer más dulce la entrada de QA en un equipo y que no te vean como el malo de la película cuando encuentras un defecto sino como el que lo encuentra y encima para decírtelo te da chocolate :p
Hablando de tu blog, una QA en apuros, que cuenta con cientos de seguidores y está enfocado a la automatización, sobre todo con Appium, ¿qué te motiva para escribir esos magníficos artículos?
Pues la necesidad de crear este blog nació justamente porque me ofrecieron la posibilidad de crear el departamento de QA en SDOS y me gustó muchísimo la idea.
Mucho antes de saber siquiera que iba a entrar aquí, yo ya estaba pensando en cómo llevar ese proyecto a cabo y una de las cosas que siempre tenía en mente es crear como un espacio personal y público donde tener todo lo que siempre había ayudado a documentar por las empresas en las que he pasado y nunca me había llevado conmigo y el tener como una base de conocimiento donde estuvieran todas las cosas que alguien de QA iba a necesitar (ya que en SDOS, si me cogían, no iba a tener nada de eso).
Empecé a escribirlo como un mes y algo antes de incorporarme a SDOS y comencé a documentar desde los cimientos del QA más básico (qué es QA, qué tipos de pruebas existen, para qué sirven, etc) hasta las partes más técnicas que ya conocía (como por ejemplo de Selenium) incorporando también después las que he ido aprendiendo en mi paso por SDOS (que es más la parte de Appium).
La verdad es que es un proyecto personal que me gusta mucho ya que puedo dar un poco a la comunidad de todo lo que he aprendido de ella y creo que hay muchas personas que quieren aprender a ser QA y con una herramienta así y toda esa información pueden ser capaces de empezar a tener una base y conocer un poco qué es ser QA y cómo trabajamos, además de herramientas nuevas que conocer y probar.
Por último, en ámbitos de calidad, ¿Cuál es la evolución de perfiles como el nuestro en zonas como Sevilla?
Pues sobre evolución, creo que lo mejor es contar toda la que he tenido yo desde que empecé hasta ahora (para que se vea que todo es posible). Empecé a trabajar como Asistente de QA cuando estaba con el TFM, después seguí como QA Junior, luego QA Senior, después estuve de QA Lead de un proyecto con varios QA a mi cargo y por último he tenido la posibilidad de crear un departamento desde cero y gestionar todo el proceso, desde las bases en cuanto a proyectos, desarrollos, clientes.. como la parte del equipo: entrevistas, pruebas técnicas, formación a las personas que entran…
Creo que este tipo de evolución es posible ya que en Sevilla hay muchas y muy buenas empresas y que todo el mundo al que le guste la calidad puede tener acceso a este tipo de carrera profesional. También depende, eso sí, de como seas y de la actitud que tengas en cuanto al crecimiento que quieras tener, pero creo que, si crees en ti y le pones ganas, puedes llegar tan lejos como tú quieras.
Su experiencia le ha llevado a ser especialista en herramientas como Appium y Selenium. Hablar con ella, es siempre aprender algo nuevo. Hoy, nos hace el honor de participar en el tercer QATalk de la Comunidad.
Llevas muchos años involucrada en ámbitos de automatización de pruebas funcionales, a día de hoy, ¿cómo ves este tipo de pruebas?
Creo que este tipo de pruebas cada vez son más importantes y cada día aparecen nuevas herramientas para desarrollarlas, sobre todo en el ámbito automático. He de decir que a lo largo de mi trayectoria profesional he aprendido mucho sobre este tema, sobre todo con Selenium y Appium y eso me ha hecho tener una visión muy amplia tanto de pruebas funcionales web como de movilidad (y es algo que intento plasmar en mi blog para que la gente que me sigue pueda aprender de ello). También es cierto que ha sido el tipo de prueba en la que más me he especializado y a veces también he echado de menos el tener más experiencia en pruebas de integración, seguridad o rendimiento que no suelen ser demasiado comunes en muchas empresas.
Uno de los puntos que suele tratar la gente, es la falta de comunidad, al final hay muchas herramientas y cada día salen nuevas, pero no se afianzan en el mercado, ¿Qué pautas deberíamos de seguir para centralizar todo esto?
Pienso que eso depende un poco de la moda o la tendencia que haya en una herramienta u otra y que la organización en la que estés te deje desarrollarte con esa herramienta o no. Yo siempre he intentado mantenerme al día de todas las herramientas que van saliendo y al menos hacer alguna prueba básica, un “Hola Mundo” con ellas para saber cómo funcionan, pero es cierto que al final cuando tienes que seleccionar qué herramienta escoger, como ha sido el caso en el que me he enfrentado en SDOS para elegir herramienta para pruebas automáticas en movilidad, tiendes a coger una herramienta que lleve tiempo en el mercado, que tenga releases constantes, que tenga una comunidad detrás que dé soporte y que haya información sobre ella.
Todo esto no se consigue por arte de magia, sino que todos tenemos que ser conscientes de que si estamos apostando por una herramienta, igual que nos estamos nutriendo de la comunidad debemos aportar todo lo que podamos a ella: crear issues en proyectos, responder a dudas o a problemas de usuarios en foros, crear post de información sobre esas herramientas…todo eso es muy importante para mantener viva la comunidad y seguir contribuyendo a ser cada día más grandes y mejores.
En tu caso, ¿cómo viviste esa transición de la realización de pruebas manuales a las automáticas?
Siempre he tenido bastante claro el valor que aporta la automatización, desde mi Trabajo Fin de Máster en el que me dediqué a aprender sobre todos los tipos de pruebas existentes que había y qué herramientas te podían ayudar a automatizar ese tipo de pruebas. He de decir que las pruebas manuales son muy importantes en todos los procesos y son la base inicial que siempre hay que tener en un proyecto antes de ponerte a automatizar, y eso es algo que intento transmitir a todo mi equipo. Sin definir qué pruebas tenemos que hacer de forma manual no deberíamos empezar a automatizar, y una vez que se tengan definidas no se puede empezar a automatizar a lo loco, sino que hay que analizar qué casos de prueba manuales son los más repetitivos o nos van a aportar más valor al tenerlos automatizados y, entonces, en ese caso, es cuando se automatizan.
Esta es la filosofía que he intentado seguir y que me han ido enseñando en las empresas en las que he pasado y es la que intento cada día transmitir a mi equipo. Como último apunte, la automatización es muy buena pero nunca va a ser capaz de sustituir a las pruebas manuales y al valor que aporta una persona haciéndolas y eso es algo muy importante que hay que tener interiorizado.
Parece, que desde hace unos años, se está incrementando el presupuesto de las empresas en pruebas, ¿qué te parece?, ¿desde el sur se percibe esta afirmación?
Coincido con tu afirmación, parece que poco a poco va calando un poco que hay que hacer pruebas, que hacer pruebas es algo “rentable” a la larga y que un proyecto no debería ir a producción sin que antes un equipo de QA se haya asegurado que todo funcione correctamente. Esto parece que es así no sólo en la filosofía que se está creando en las empresas sino en los puestos de trabajo que cada día se van viendo en el mercado buscando nuevas personas para departamentos de QA, aun así, sigue habiendo clientes que siguen sin percibir la importancia y el valor que aporta tener QA y que te siguen preguntando para qué sirve esto y por qué tengo que tener una persona asignada en mi equipo haciendo pruebas, cosa que luego sigue con la pregunta de: “¿Es que los desarrolladores no saben programar bien y ya sabes que van a tener errores?” y no es ese el caso.
En esos momentos es cuando tiras de mano izquierda y le explicas de la mejor forma a los clientes que una persona que desarrolle no debe probar él mismo porque sabe cómo lo ha desarrollado y no va a probar otras formas de probar su desarrollo más que la que ha pensado en su cabeza. También está el caso contrario en el que el cliente sabe y conoce el valor que da QA y directamente lo pide y lo exige en sus equipos.
En SDOS creaste el departamento de QA desde cero, ¿qué pautas intentas inculcar en tu equipo? ¿Trabajáis más con automatización o hacéis pruebas mixtas? Cuéntanos tu experiencia inculcando cultura de calidad en una empresa.
En SDOS he tenido la suerte de poder crear el departamento de QA desde el principio y asentar las bases y eso me ha gustado mucho como experiencia tanto personal como laboral. Desde el principio me han dejado mucha libertad y me han ayudado mucho a entender la cultura de la empresa, los tipos de proyectos en los que trabajamos y las herramientas y tecnologías que tenemos en nuestro día a día. El entender bien todo eso ha sido la clave para saber cómo abordar y cómo empezar a asentar los cimientos del departamento.
Las pautas que siempre he intentado inculcar a todo el equipo es que QA no sólo tiene que hacer piña con el equipo del proyecto en el que trabaje, sino también entre nosotros, entre los “QAcitos” que estamos. He intentado asentar las bases tanto de la parte manual como de la automática para que todos trabajemos de la misma forma en todos los proyectos (con alguna excepción que siempre hay en algún cliente concreto que quiere algo diferente) para que, de esta forma, cuando alguna persona del departamento tenga un problema no sea problema de uno, sino de todos. Todos tenemos que ser los responsables de aportar, tanto al Stack tecnológico que tenemos como al centro de conocimiento que poseemos donde está toda la documentación necesaria para todos en la que se describen desde qué es QA hasta qué herramientas de seguridad o rendimiento hemos utilizado con algún ejemplo paso a paso de cómo utilizarlo.
También he intentado fomentar mucho las formaciones internas entre el equipo y que no sólo se centralicen en mí, sino que cada mes, una persona diferente del equipo tiene que dar una formación sobre un tema que le guste y que nos aporte a todos y la exponga delante de sus compañeros. Hemos tenido formaciones muy interesantes y creo que esto es algo que nos ha aportado mucho valor como equipo y para seguir nutriéndonos. Además de eso, muchas de estas formaciones han terminado como un artículo en el blog corporativo no sólo para nosotros sino para cualquier persona que tenga curiosidad sobre un tema que hemos tratado y quiera aprender al igual que nosotros.
En cuanto a la parte de las pruebas, solemos hacer pruebas mixtas, tanto automáticas como manuales, la mayoría de las veces funcionales y utilizamos Appium y Selenium como herramientas automáticas. Desde el primer día intentamos enseñarle al cliente lo importante que es la automatización y todo lo que le puede aportar.
Respecto a mi experiencia inculcando la cultura de calidad, al principio fue difícil porque fue un cambio de mentalidad, tanto en los equipos como en los jefes de proyecto para que lo entendieran y lo trasladaran a los clientes. Poco a podo hemos ido recopilando información, datos e informes para hacer ver que QA aporta mucho valor y se entienda y respete dentro de la organización.
En SDOS, ¿trabajáis con metodologías ágiles?
Sí, solemos trabajar con metodologías ágiles, principalmente Scrum. Lleva ya años implementado en la organización y nos hemos adaptado todos a la perfección.
Tu trabajo, es mano a mano con equipos de desarrollo. Hace unos años, nos veían con cierta “reticencia”, pero, cada vez más, tienen la visión de que les ayudamos a hacer mejor su trabajo, ¿cómo es tu día a día con ell@s?
Desde hace varios años, estoy centrada en la parte de ser QA dentro del equipo de desarrollo en lugar de ser una parte externa que se dedica a validar las entregas que les va haciendo un equipo de desarrollo al que no suelen conocer. La verdad es que, habiendo estado en las dos perspectivas, prefiero mucho más estar dentro del equipo que fuera porque se aporta mucho más valor, no sólo con el equipo sino con el producto y al final el objetivo común tanto del equipo de desarrollo como de QA es sacar el mejor producto posible que se pueda conseguir entre todos. Esta es la perspectiva que intento transmitir día a día con los equipos en los que participamos y que estaban acostumbrados a trabajar sin QA en la mayoría de los casos y que poco a poco se han ido haciendo a que tienen que trabajar con nosotros y que somos uno más.
Los primeros días en los que QA llega a un equipo que no está acostumbrado a trabajar con este perfil suelen ser difíciles, primero tienes que conocer a la gente del equipo, el producto, el proyecto, al cliente en muchos casos y el cómo se hacen las cosas dentro del equipo de desarrollo. Cuando conoces eso tienes que hacerle entender al equipo día a día que necesitas tiempo antes de hacer una entrega para validar, que cada historia de usuario o ticket que se desarrolle tiene que pasar por QA y cumplir una serie de requisitos mínimos, que hay que utilizar herramientas de integración continua para las entregas porque no nos vale con “he probado la aplicación que Fulanito me ha dado a las 12:03 generada en su equipo” sino que tenemos que saber qué build concreta estamos probando, la hora, los cambios que lleva, el entorno… inicialmente son muchos cambios pero en dos o tres sprints el equipo ya se suele acostumbrar a la nueva forma de trabajo y a considerarnos como uno más y ver cómo se consigue eso es muy gratificante.
Además, como algo personal, siempre intento ganarme al equipo de desarrolladores los primeros días trayendo chuches, chocolate y ese tipo de cosas para hacer más dulce la entrada de QA en un equipo y que no te vean como el malo de la película cuando encuentras un defecto sino como el que lo encuentra y encima para decírtelo te da chocolate :p
Hablando de tu blog, una QA en apuros, que cuenta con cientos de seguidores y está enfocado a la automatización, sobre todo con Appium, ¿qué te motiva para escribir esos magníficos artículos?
Pues la necesidad de crear este blog nació justamente porque me ofrecieron la posibilidad de crear el departamento de QA en SDOS y me gustó muchísimo la idea.
Mucho antes de saber siquiera que iba a entrar aquí, yo ya estaba pensando en cómo llevar ese proyecto a cabo y una de las cosas que siempre tenía en mente es crear como un espacio personal y público donde tener todo lo que siempre había ayudado a documentar por las empresas en las que he pasado y nunca me había llevado conmigo y el tener como una base de conocimiento donde estuvieran todas las cosas que alguien de QA iba a necesitar (ya que en SDOS, si me cogían, no iba a tener nada de eso).
Empecé a escribirlo como un mes y algo antes de incorporarme a SDOS y comencé a documentar desde los cimientos del QA más básico (qué es QA, qué tipos de pruebas existen, para qué sirven, etc) hasta las partes más técnicas que ya conocía (como por ejemplo de Selenium) incorporando también después las que he ido aprendiendo en mi paso por SDOS (que es más la parte de Appium).
La verdad es que es un proyecto personal que me gusta mucho ya que puedo dar un poco a la comunidad de todo lo que he aprendido de ella y creo que hay muchas personas que quieren aprender a ser QA y con una herramienta así y toda esa información pueden ser capaces de empezar a tener una base y conocer un poco qué es ser QA y cómo trabajamos, además de herramientas nuevas que conocer y probar.
Por último, en ámbitos de calidad, ¿Cuál es la evolución de perfiles como el nuestro en zonas como Sevilla?
Pues sobre evolución, creo que lo mejor es contar toda la que he tenido yo desde que empecé hasta ahora (para que se vea que todo es posible). Empecé a trabajar como Asistente de QA cuando estaba con el TFM, después seguí como QA Junior, luego QA Senior, después estuve de QA Lead de un proyecto con varios QA a mi cargo y por último he tenido la posibilidad de crear un departamento desde cero y gestionar todo el proceso, desde las bases en cuanto a proyectos, desarrollos, clientes.. como la parte del equipo: entrevistas, pruebas técnicas, formación a las personas que entran…
Creo que este tipo de evolución es posible ya que en Sevilla hay muchas y muy buenas empresas y que todo el mundo al que le guste la calidad puede tener acceso a este tipo de carrera profesional. También depende, eso sí, de como seas y de la actitud que tengas en cuanto al crecimiento que quieras tener, pero creo que, si crees en ti y le pones ganas, puedes llegar tan lejos como tú quieras.
Comentarios
Publicar un comentario