QA Tester. Dudas

1mP #1 21 Dic

Actualmente me encuentro trabajando como Técnico de Soporte pero en mi empresa me están empezando a enseñar a hacer tests de las aplicaciones que están desarrollando, que a esto creo que se le llama QA Tester, si no me equivoco.

La cosa es que creo que me está gustando y me gustaría saber cómo de valorado esta este puesto en IT, ya que donde estoy ahora mismo es añadirme trabajo extra, aunque se esperaba desde el principio que hiciera estas tareas. Yo estoy conforme con esto porque son más cosas que puedo aprender y puedo acabar decidiendome a enfocarme en una cosa en concreto.

Así que quiero aprovechar esta experiencia laboral para ahondar un poco en cómo es este puesto realmente. Además me gustaría mirar formación relacionada y me gustaría que me recomendarías si vale la pena certificarte como QA Tester si eso va a repercutir en empleos mejores pagados.ñ en un futuro.

Recomendáis certificaciones?

Muchas gracias !

Kaledros #2 21 Dic

#11mP:
me gustaría saber cómo de valorado esta este puesto en IT

Te lo diré de esta manera: en ninguna empresa que tenga los procesos en su sitio tienen QA. Salvo en videojuegos y demás aplicaciones que sean intesteables con tests automáticos.

Ser QA no tiene futuro, hay muy pocos, cada vez habrá menos, cobran poco y son el último mono en cualquier equipo donde estén.

1 2 respuestas

tirutu #3 21 Dic

#2 Supongo que hablas de tests manuales. Mi empresa está expandiendo su equipo de QA automation porque los clientes lo demandan. Claro que ya empieza a haber algo de programación en esto de la automatización, pero no es algo que puedan hacer los devs sin más. Se usan frameworks especializados para testing y, seamos honestos, a nadie le divierte escribir tests a menos que seas de QA y no tengas más remedio xD

1 respuesta

Kaledros #4 21 Dic

#3tirutu:
Supongo que hablas de tests manuales

Hablo de tests manuales, sí, porque el resto de tests (unitarios, integración, aceptación, contrato, etc) se hacen al tiempo que desarrollas. Y en la gran mayoría de proyectos los tests manuales no son necesarios porque con los automáticos cubres todas las casuísticas.

2 respuestas

1mP #5 21 Dic

#4 he escuchado que con saber algo de Python y MySQL por ejemplo, "bastaría". Cómo de cierto es esto?

Gracias por el feedback!

2 respuestas

Apo_powa #6 21 Dic :psyduck:

#5 llegaras lejos con esta actitud ajajaj

boselecta #7 21 Dic :psyduck:

#5 Puedes empezar por sacarte un Istqb foundation y así , aparte de coger una base del testing, ya tienes una certificación que están pidiendo si o si en los trabajos de QA.

Luego si que es verdad que ser QA solo de manual no es muy demandado y no tiene tanto sueldo como un dev pero si te lo montas bien, puedes trabajar sin tanto estrés que un dev y ser parte importante en un equipo.

Yo soy QA y he de decir que haber empezado en manual y seguir como auto me está dando bastante valor ya que últimamente son necesarios estos roles "híbridos". Yo hago toda la parte de los planes de prueba, ejecuciones, pruebas de confirmación, exploratorias...

Y también hago automatización con Selenium Java y he tocado Tosca y ATF. Postman lo piden mucho y no está mal conocerlo también.

1

Lan0s #8 21 Dic

#4 no has dado ni una, tío. Soy QA desde hace más de 7 años y el testing manual es igual de necesario que el automático. No es que uno sea mejor que otro, es que ambos se complementan porque tienen un propósito distinto.

La gente pensaba que el rol de tester manual desaparecería por la automatización de pruebas, pero fíjate qué cosa que hoy en día puedes delegar la creación de pruebas automáticas a la IA (o incluso usar recorders, que han evolucionado mucho y no tienen nada que ver con el Selenium IDE de antaño), sin embargo aún no hay nada que pueda recrear de forma autónoma una sesión de testing exploratorio basado en la experiencia y el conocimiento empírico.

#1 mi consejo es que si te gusta el trabajo, lo aceptes, ya que te abrirá más puertas de las que tienes ahora mismo. Y dentro de unos años sigas creciendo horizontalmente, ya que los roles generalistas son muy apreciados en las empresas competitivas (las cuales tienen un impacto considerable en el mundo y ofrecen muy buenas condiciones).

En cuanto a certificaciones, la típica es la ISTQB Foundation level, que normalmente la suelen pagar las empresas. Te da algo de currículum para empezar pero realmente es un engañabobos. El único valor que veo que realmente ofrece es que establece un vocabulario común que facilita la comunicación en el mundillo. Algo así como conocer el lenguaje musical en la música, no es necesario pero ayuda. Puedes vivir perfectamente sin ella, pero si se te presenta la oportunidad de sacártela pagándolo la empresa, pues eso que te llevas.

2 2 respuestas

Kaledros #9 21 Dic

#8Lan0s:
Soy QA desde hace más de 7 años y el testing manual es igual de necesario que el automático

Y yo soy backend dev desde hace 9 y no he visto a un QA manual en mi vida, pero igual es cosa mía.

1 respuesta

Wei-Yu #10 21 Dic

#8 Yo creo que el comentario de #2 es bastante acertado en términos generales. En equipos de desarrollo con buenos procesos, las cosas con buen scope y bien definidas es muy poco común ver QAs manuales. Aunque no es un rol que vaya a desaparecer imho (y mucho menos por la automatización de pruebas), sí es un rol anclado a un tipo de empresa y relacionado con procesos poco ágiles.

Vaya me parece algo muy muy difícil de discutir porque cualquier estudio o análisis sobre velocidad de desarrollo y robustez van todos en la misma línea.

Dicho esto, creo que QA es un nicho perfectamente válido para crecer como profesional y te puede ofrecer la oportunidad de crecer en distintos ámbitos. Si entrar o no ahí ya es un tema personal de objetivos a medio/largo plazo. Yo personalmente no optimizaría mi carrera profesional a corto sacrificando el medio y largo plazo; si quieres otra cosa no uses QA como punto intermedio a menos que no encuentres oportunidades.

1 respuesta

Lan0s #11 21 Dic

#9 porque normalmente ambas actividades de testing las hace el QA como tal, no es que solo haya QAs manuales o de automatización.

#10 es lo mismo que puse en el párrafo anterior. Hoy en día me parece errado hablar de QA manual y automatización como rol. Hay ingenieros o analistas de calidad y ellos hacen tareas manuales o para la automatización. Generalmente se busca QA Automation para todo tipo de tareas, involucrando diseño de procesos y testing manual (como actividad en el desarrollo, ojo, no como rol), el cual no va a desaparecer.

1 respuesta

Wei-Yu #12 21 Dic

#11 es parte del ciclo de vida del desarrollo de software y son los desarrolladores los que tienen que llevar esa carga de trabajo, porque se realiza durante el trabajo en sí y este no se completa hasta que se pasan por esas fases. En industrias con mucha regulación existe ese nicho, fuera de ahí me parece propio de sitios con techos salariales bajos.

Load testing, perf testing, semantic monitoring, e2e, integración, regresión. Todo eso es mi responsabilidad como dev, no la del QA.

1 respuesta

Lan0s #13 21 Dic

#12 bueno, eso ya depende de cada empresa, cada una define sus roles y las expectativas de cada uno. En tu caso, como desarrollador, hace muchas tareas que en otras empresas haría un QA (lo he vivido en primera persona). También como QA he hecho tareas que en otras empresas haría un DevOps (otro rol mal llamado).

Yo de hecho estoy a favor de los roles generalistas, así que me parece bien tú cómo dev hagas esas tareas. En cuanto a lo de que tengas que hacerlas un dev porque forma parte del SDLC, generalmente el QA suele estar integrado dentro de los equipos de desarrollo y trabaja en paralelo al dev. Pero es que el también puede haber business analysts integrados en el proceso de desarrollo sin desarrolladores. Así que no solo porque seas dev tienes que realizar todas las tareas del SDLC, ni tienes que ser únicamente tú el que lo haga obligatoriamente. Cada equipo y empresa es un mundo

1 respuesta

Wei-Yu #14 21 Dic

#13 por eso digo que no es un rol que vaya a desaparecer, ni mucho menos. Es algo que se da "bastante" pero una realidad objetiva es que ese paradigma de trabajo es menos ágil. Pierdes productividad, entregas menos por más y es algo que se nota cuando comparas equipos y empresas.

Pero vuelvo decir, me parece una profesión perfectamente válida y hasta me parece algo entretenido, además de que puedes exponerte a un montón de cosas distintas (la parte de infra o la parte de negocio/producto dependiendo de las necesidades o hueco que haya). Estás en una intersección que te permite aprender y crecer en distintos ámbitos.

1

Lan0s #15 21 Dic

Estoy de acuerdo en todo menos en lo de que es menos ágil, todo depende de las estrategias de pruebas que se sigan. Después de trabajar en muchos equipos y liderar algunos de ellos, la que mejor me ha funcionado hasta la fecha es ignorar el testing manual “clásico” (test plans, test cases, etc), invertir gran parte de los recursos en automatización de pruebas y programar sesiones periódicas de testing exploratorio (lee sobre SBTM - Session Based Test Management, hay un PDF muy completo de James Bach rulando por ahí que explica muy bien este enfoque). Esta estrategia es súper compatible con metodologías ágiles y testing continuo.

QA Tester. Dudas

Usuarios habituales

Tags