Burnout en Pruebas de Software: 6 Causas y Cómo Solucionarlo
¿Es posible fabricar una situación en un equipo de desarrollo de software para que un tester tenga muchas probabilidades de quemarse?
Si la respuesta es sí, ¿qué pueden aprender los testers de este experimento mental?
Resulta que el burnout entre los profesionales del testing de software no es solo un experimento mental en la industria del testing de software: es un problema real y generalizado que afecta a muchos desarrolladores, ingenieros y testers.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Profundicé en el tema del burnout en el testing de software, preguntando:
- ¿Cómo se ve el burnout en esta industria?
- ¿Qué tan grande es el problema?
- ¿Qué crea sistemas en los que los testers de software se queman?
- ¿Cómo podemos descomponer el tema del burnout y solucionarlo?
Las respuestas —o al menos el comienzo de ellas— están aquí en este artículo.
Burnout entre profesionales del testing de software en TI
El estrés relacionado con el trabajo es algo que muchos de nosotros en la industria de TI experimentamos. Estoy seguro de que también tienes tu parte de estrés. En mi contexto, por desgracia, el burnout se ha convertido en un tema más presente en los últimos años.
¿Es un problema el burnout?
Cuando le pregunté a Jonathon Wright, “¿Qué tan grande crees que es el problema del burnout entre los profesionales de QA?”, esto fue lo que respondió:
“Es un problema enorme. Frase famosa: No se puede correr una maratón todo el tiempo.”
Jonathon Wright, presentador de The QA Lead Podcast
Y continuó explicando,
“Metodologías como Agile y DevOps fomentan la idea de hacer todo incluso ‘más rápido’. ¿Cómo puede un profesional de QA aportar valor medible en un entorno de fracasa-rápido-aprende-rápido?
En un podcast reciente en el QALead surgió el término ‘ralentiza para acelerar’. A menos que las empresas celebren el fracaso (algo que muy pocas hacen), cada vez que fallas no ayudas al resto de la velocidad del equipo.
El consejo está en el título de la sobreutilizada gráfica Burndown. La gamificación de comprometerse con una cantidad de story points genera una competencia poco saludable.
"Te ves forzado a hacer más con menos, trabajando bajo la expectativa poco realista de que el trabajo puede entregarse en sprints de dos semanas."
Jonathon Wright, presentador de The QA Lead Podcast
¿Cómo se manifiesta el burnout en QA?
El burnout no es un caso aislado en la industria del software—pero ¿cómo se manifiesta?
Aquí hay respuestas de profesionales del testing de software que muestran las distintas formas en que el burnout aparece en QA.
“Tenemos que demostrar nuestro valor. Los equipos me dicen que son ágiles, que no necesitan testers.”
“Ansiedad. Es difícil para los profesionales de QA no preocuparse antes de un gran lanzamiento o sentirse responsables de los resultados.”
“Presión de tiempo. Los testers siempre somos los últimos. Y nunca tengo el tiempo que necesito. Y se reduce a la mitad porque los desarrolladores se sobrepasan.”
“Expectativas poco realistas. Podría testear por siempre y aun así no podría testearlo todo. Díselo a un líder de proyecto. ¿De qué sirve un tester que no encuentra los bugs?”
“Descifrar a partir de los ítems del backlog qué debe ser probado es casi imposible. Y nadie menciona los casos límite.”
“El desperdicio es frustrante. Los desarrolladores no pueden reproducir un bug, el ítem de backlog está desactualizado, o ya lo arreglaron.”
“Muchos no quieren un informe honesto y especialmente no malas noticias. Cuando insistes, puede volverse algo personal.”
¿Por qué ocurre el burnout?
La literatura enumera muchos factores que causan estrés y aumentan la probabilidad de burnout. Hay factores individuales, por ejemplo, impulsos personales como ser perfecto, darse prisa, esforzarse mucho, ser fuerte o complacer a los demás. Busca análisis transaccional para más detalles.
Y hay factores estresantes provenientes del entorno laboral. Alta carga de trabajo, presión de tiempo, metas y expectativas inalcanzables, falta de control, conflictos acalorados, miedo a perder el empleo, insatisfacción laboral, bullying y mobbing, entre otros. Los conocemos.
Hace algún tiempo empecé a observar el agotamiento profesional desde un punto de vista sistémico y creé un juego de simulación donde los jugadores pueden influir en la fortuna de un equipo de desarrollo de software. Pueden llevar a los miembros del equipo al agotamiento o crear el proyecto más gratificante de todos.
El corazón de la simulación es un sistema de agotamiento, es decir, un sistema configurado de modo que algunos miembros de un equipo acabarán inevitablemente quemados. Puedes ver un adelanto del juego en mi blog.
Este enfoque sistémico también funciona con diferentes roles dentro de un equipo. He hecho esto con profesionales de experiencia de usuario y me sorprendió lo fácil que es llevar a estas personas al foco de un sistema de agotamiento. En especial, cuando se preocupan por los usuarios, están dispuestos a luchar más y arriesgarse a hundirse.
A continuación, me sumergiré en la historia de Alan, un profesional de QA, para entender mejor e ilustrar el problema del agotamiento en la industria del software.
Luego, hablaré de cómo se crean los sistemas de agotamiento y qué podemos hacer para mejorar estos sistemas.
Una historia personal sobre el agotamiento
Ahora que tengo claro que puedo fabricar un sistema de agotamiento para profesionales de QA, permíteme presentarte a Alan y su historia.
Alan tiene casi una década de experiencia en pruebas de software y especialmente en pruebas de rendimiento. Está a punto de unirse a un equipo de desarrollo. El equipo ha estado trabajando durante diez sprints y quedan otros cuatro para el primer lanzamiento.
¿Cómo fue el primer día de Alan en el proyecto?
Alan: Hay mucho que hacer para mí. El software es de baja calidad. Espero encontrar muchos errores no detectados y temo problemas si no los encuentro antes del lanzamiento.
Markus: ¿Entonces identificar los errores es tu principal prioridad para mejorar la calidad?
Alan: Esa es una parte. También esperamos muchos usuarios. El rendimiento del software es de suma importancia una vez que lo lancemos al público en general. El equipo está ansioso por sacarle provecho a mi experiencia en eso.
Hasta aquí, Alan es bastante optimista en que las medidas acordadas con el equipo mejorarán la calidad del software. Sin embargo, un sprint después, cuando faltan tres, Alan ya no se muestra tan animado.
¿Cuál es el problema?
Alan: Estas dos semanas han sido intensas. No estoy contento con mi progreso. Quería tener una primera prueba de rendimiento simple, pero estoy lejos de lograrlo.
Markus: ¿Qué te lo impide?
Alan: Necesito apoyo de los desarrolladores, pero están saturados. También necesité mucho más tiempo del esperado para familiarizarme con el software y reportar los errores que encontré.
Markus: ¿Pudiste probar las nuevas historias entregadas por el equipo?
Alan: No realmente, el equipo estuvo ocupado puliéndolas. De los dos días reservados para pruebas al final del sprint, solo me quedó medio día. Me quedé más tiempo y trabajé el sábado, pero estoy lejos de terminar.
En la retrospectiva del sprint doce, cuando quedan solo dos sprints, las pruebas son el tema principal: el product owner se quejó del número de errores que Alan encontró.
Desarrollador: La mayoría de los errores que encontró Alan son insignificantes o ni siquiera son errores. Revisémoslos primero antes de sacar conclusiones.
Alan: Bueno, me costó entender qué debía hacer el software con los ítems del backlog. Una especificación realmente ayudaría.
Desarrollador: ¡Por encima de mi cadáver! No queremos Waterfall. Es sobre todo sentido común. Solo ven y pregúntanos. ¿Cómo va la prueba de rendimiento?
Alan: Estoy estancado. No logro poner en marcha la herramienta contra la capa de servicio con toda esa seguridad. Necesito ayuda.
Desarrollador: Usamos otra herramienta en el último proyecto. Funcionó de maravilla. Te pasaré el enlace.
Como resultado, el PO organiza una ágil reunión de dos horas en el siguiente sprint. El objetivo es revisar los errores y discutir qué anotar en los ítems del backlog para facilitarle las cosas al novato Alan. ¿Sientes la frustración de Alan aumentando?
La posición fatal de Alan como chivo expiatorio se hace más evidente tras el sprint trece, con un sprint restante. Aquí tienes las decisiones de esa retrospectiva:
- Muchos errores encontrados en historias que Alan debería haber probado el sprint anterior. Ninguna historia se cerrará sin que Alan la haya probado.
- Sigue sin haber pruebas de rendimiento. Tendremos a un experto revisándolo. Alan debe informarle.
- No se pudieron completar dos historias. Perdimos dos días descartando informes de errores inútiles. Alan marca cada error con su relevancia. En caso de duda, pregunta al product owner.
¿Te has dado cuenta? El equipo no terminó dos historias y ¡logró echarle la culpa a Alan!
Imagina la siguiente iteración, cuando las historias no se cierren porque Alan no tuvo tiempo de probarlas. No es de extrañar que Alan se vea agotado.
Alan: Solo faltan dos semanas para la entrega y la calidad es una pesadilla. ¡Díselo al product owner! Y además quitaron las pruebas de rendimiento. Esa fue la razón principal por la que me uní al proyecto. Mi jefe está descontento. Quería que diera el ejemplo sobre cómo incluir testers en equipos ágiles. Sin embargo, tendré que luchar por ello, mi reputación en la empresa está en juego.
Cuatro semanas después, dos semanas tras la primera entrega a una audiencia selecta, el sistema de agotamiento está plenamente operativo.
Resumen de Alan sobre sus logros hasta el momento:
- Pruebas de rendimiento: fallido
- Ser reconocido como experto en pruebas de rendimiento: fallido
- Poder probar exhaustivamente lo recién desarrollado: fallido
- Poder re-probar exhaustivamente lo ya construido: fallido
- Incorporar testers en equipos ágiles: fallido
- No tener bugs críticos en la entrega: fallido
- Ser recomendado: fallido
- Trabajar duro y recibir la culpa: logrado
- Miedo a perder el trabajo: logrado
- Agotamiento: encaminado a toda velocidad
Este es un caso clásico de un sistema de agotamiento. Entonces, ¿qué crea este sistema y cómo podemos mitigarlo?
¿Qué Crea un Sistema de Agotamiento?
Para Alan, podrías decir que es una causa perdida desde el principio. Y tendrías razón. Alan está en un sistema de agotamiento que ha estado funcionando en el equipo desde hace tiempo. El sistema de agotamiento señala a Alan como un depredador lo hace con su presa. Pero ¿qué es este sistema de agotamiento y cómo lo consigue?
Un sistema de agotamiento es una constelación de personas, motores y conflictos. A través de un ciclo reforzado, crea una situación tan llena de factores estresantes que algunas personas terminarán quemándose. Es especialmente poderoso cuando logra activar la lógica de supervivencia de las personas.
1. La Energía Sigue a los Motores
En la historia de Alan, podemos identificar algunos motores:
- La ambición y fascinación por el tema de las pruebas de rendimiento hacen que Alan quiera realizarlas.
- La ansiedad de ser responsable de una entrega fallida lleva a Alan a buscar bugs.
- Algo hace que los miembros del equipo construyan características antes que todo lo demás.
Los motores cambian el rumbo de las acciones. A la gente le cuesta mucho pensar claramente sobre qué lograr y cómo lograrlo. La energía que invierten sigue el motor, no donde más se necesita. El equipo de Alan nunca se pregunta si construir todas las características es lo correcto. Alan tampoco se pregunta si buscar bugs es lo más apropiado.
Lo difícil para la mayoría de nosotros es darnos cuenta de que un motor ha tomado el control. Por suerte, los psicólogos los han estudiado. En cuanto a motores personales, puedes comenzar con el análisis transaccional. A nivel de equipo, el groupthink es un buen punto de partida. Puedes encontrar muchos consejos al respecto.
En relación con la ansiedad antes de una entrega, uno de los profesionales de QA con experiencia aconsejó: “Solo tienes que dejarlo ir y estar tranquilo”. Con una mentalidad así desde el principio, probablemente Alan habría perseguido otro objetivo diferente de buscar todos los bugs y realizar pruebas de rendimiento. Las prioridades principales podrían ser que el equipo elimine los bugs críticos y entregue una calidad general más alta. Una manera de reducir el estrés asociado con tareas repetitivas es aprovechar herramientas de primer nivel diseñadas para pruebas de software.
2. Los Conflictos Lo Calientan y Se Vuelven Personales
Junto con los motores, los conflictos se encienden en el equipo. Por ejemplo, Alan necesita más tiempo de los desarrolladores del que ellos están dispuestos a dar. Resultado: Alan hace mucho ruido y los desarrolladores intentan quitárselo de encima. Con poca ayuda, Alan no puede cumplir las expectativas. Teme por su reputación, redobla esfuerzos y genera aún más ruido.
Lo realmente negativo es que los conflictos se vuelven personales. Tras diez años trabajando como tester, probablemente Alan sea todo un experto. Aun así, el equipo lo ve como un incompetente y actúa en consecuencia. Cuanto más tiempo dura esta situación, más profunda se vuelve. Incluso afecta a Alan: él empieza a cuestionar su propia competencia.
¿Cuántas veces has culpado a alguien? ¿Cuántas personas a tu alrededor no hacen bien su trabajo? Cada uno de esos pensamientos señala un conflicto que se ha tornado personal.
La mayoría de los equipos son incapaces de resolver conflictos. No es fácil. Gestión de conflictos es la palabra clave para buscar orientación. El mensaje básico: los equipos necesitan una cultura donde las ideas se intercambien abiertamente, se den la bienvenida a puntos de vista divergentes como oportunidades para crear cosas nuevas y se aprecie la ayuda mutua. Algo difícil de lograr, si lo comparas con la cultura de velocidad que describe uno de los entrevistados: “A menos que las empresas celebren el fracaso, cada vez que fallas no estás ayudando a la velocidad del equipo”.
3. La Estructura del Equipo Impacta en la Dinámica del Equipo
El equipo de Alan reservó los dos últimos días del sprint para pruebas, cierre del sprint y preparación del siguiente sprint. El equipo simplemente asumía que Alan seguía esta estructura. Él probaba las funciones implementadas al final del sprint y hacía algunas re-pruebas en el siguiente sprint, además de mejorar las pruebas en general. No suena mal, ¿verdad?
La realidad cuenta una historia diferente. El software está disponible solo en el último día del sprint. Los elementos del backlog ofrecen poca ayuda sobre cómo debería funcionar exactamente. Mientras el equipo discute los detalles de lo que harán en el siguiente sprint, Alan intenta averiguar qué probar del sprint actual. Luego realiza preguntas justo antes de que los desarrolladores se vayan y hace pruebas durante el fin de semana. Qué bien que el equipo discute qué anotar. Así Alan puede probar sin molestar a los desarrolladores. Bingo.
La estructura del equipo aísla cada vez más a Alan. El equipo no ve sus dificultades. Solo notan preguntas tontas y resultados tardíos con poco valor. Qué patético.
La especificación por ejemplo muestra claramente cómo las pruebas y los testers pueden ser parte integral de un equipo ágil. Los testers participan en los refinamientos, ayudan a crear una especificación comprobable, enfocan los esfuerzos de prueba donde realmente importa, mejoran los procesos del equipo, las habilidades individuales y las herramientas, e incluso realizan algunas de las pruebas. Las pruebas se realizan de manera continua, no solo al final del sprint.
4. Ignorar reglas fundamentales y dirigirse al problema
El equipo de Alan ignora reglas fundamentales de la ingeniería de software.
Aquí tienes cinco de ellas:
- Suceden cosas inesperadas. No dejar suficiente espacio para ellas conduce a prisas, atajos, errores tontos, conflictos acalorados, y por lo tanto a un avance más lento a largo plazo.
- La presión retrasa. La presión reduce el espacio para lo inesperado.
- La calidad es emergente. El equipo debe tener una cultura de calidad. Las pruebas son solo una pieza del rompecabezas. Y un miembro solo contra todos los demás usualmente falla.
- Cambiar el equipo lo vuelve más lento. Construir confianza, adaptar procesos, resolver más conflictos: El equipo necesita tiempo y energía para integrar a nuevos miembros. Añadir personas a un proyecto retrasado lo retrasa aún más.
- Los defectos son para aprender. Cuando un proceso genera demasiados defectos, deténlo, arréglalo y aprende de él. No culpes y, sobre todo, no lo aceleres.
Existen más reglas como estas y, siempre que la gente las ignora, las cosas empeoran. Y eso fue lo que ocurrió a Alan.
5. Una situación percibida como ajustada lo desencadena
¿Por qué el equipo ignora cosas tan fundamentales? Es sencillo. Suele ocurrir en una situación ajustada donde las condiciones (entregables, tiempo disponible y el equipo) no dejan suficiente flexibilidad para manejar lo inesperado. He estado ahí, lo he vivido, es un caso claro. Los sistemas de desgaste explotan la única variable en una constelación ajustada: cuán duro trabaja el equipo, es decir, cuánta energía consumen los miembros del equipo de sus reservas.
La pregunta clave: ¿el equipo de Alan está realmente en una situación ajustada y entregar todas las funcionalidades es realmente el mejor camino? Solo podemos asumirlo. El equipo hizo lo mismo y se apresuró tratando de construir todas las funcionalidades.
Es la percepción de una situación ajustada lo que importa. El detonante de esa percepción puede ser una cláusula contractual, un incentivo, una gran oportunidad de mercado, una fuerte demanda de un jefe, una promesa realizada, el deseo de un cliente, una regulación gubernamental.
Alan espera una gran cantidad de errores y la ansiedad le hace cazarlos. La pregunta clave para él: ¿es realmente tan importante encontrar los errores en este caso? Solo podemos especular y Alan hizo lo mismo. Él asumió que sí.
La percepción de una situación ajustada es una palanca importante para romper un sistema de desgaste. Detrás de esto hay otra regla fundamental de la ingeniería de software:
- Expectativas demasiado altas. Las partes interesadas –incluidos los propios desarrolladores– esperan, desean o exigen más de lo que un equipo de software puede entregar realísticamente.
Mirando los últimos 25 años de mi experiencia en proyectos, no recuerdo ninguno en el que esto no haya sido así. El conflicto entre lo esperado y lo que se puede entregar es el punto más caliente. El éxito de un proyecto depende de qué tan bien pueden resolver este conflicto las personas involucradas. Recomendaría revisar buenas prácticas sobre gestión de partes interesadas y gestión de expectativas, gestión de conflictos, ingeniería de requisitos, agilidad y similares.
En cualquier caso, lo que hay que hacer es entender la naturaleza exacta del conflicto. ¿Qué tan fuerte es? ¿Qué lo impulsa? ¿Con quién necesitas trabajar? O como lo expresó uno de los profesionales de QA entrevistados: “Creo que toda empresa debe tomar una decisión consciente respecto a calidad, costo y velocidad”. Cada empresa necesita trabajar en sus expectativas.
Los profesionales de QA generalmente no están en posición de liderar esta discusión. Pueden intentar contribuir. Tal vez sea más fructífero gestionar las expectativas personales que enfrentan. Una entrevistada me contó su receta: “Es imposible probarlo todo. Lo mejor es definir un tiempo límite y las prioridades junto al product owner. Las prioridades reflejan el riesgo de no probar. Si no estás satisfecha, renegocia el tiempo y las prioridades”.
6. Trampa ágil
Un equipo sólido que se adapta continuamente a las necesidades cambiantes, una forma no burocrática de abordar el cambio, medios simples de planificación y control de progreso: el movimiento ágil ha traído una gran cantidad de innovaciones de las que los equipos de desarrollo harían bien en beneficiarse. Aun así, lo ágil parece ir más allá de lo necesario.
Todo empieza con los nombres: Sprint significa rápido, velocity significa rápido, uno falla rápido. Los principios ágiles ponen el código en primer lugar, pensar por adelantado se descarta fácilmente como desperdicio. Incluso el término scrum viene del rugby, un deporte en el que los atletas se embisten a toda velocidad. Así, la agilidad, incluso en contra de su propia convicción, fomenta la velocidad sobre la calidad. “Metodologías como Agile y DevOps fomentan la idea de hacer todo aún más rápido”, es lo que se quejó un profesional de QA.
La mecánica de, por ejemplo, scrum es incluso peor que los nombres. No es que quienes crearon Scrum quisieran fomentar el burnout. Pero scrum lleva a los equipos por el camino equivocado.
Por un lado, centra la atención del equipo en el backlog. La tarea del product owner es poner cosas en el backlog. La tarea de los miembros del equipo es tomarlas y hacerlas una a una. El trabajo del scrum master es asegurarse de que esto vaya más rápido. Además, el control ágil del progreso necesita pequeños elementos en el backlog, realizables en pocos días. Los gurús también recomiendan criterios de aceptación muy bien definidos antes del sprint. Los miembros del equipo reciben pequeñas partes y definidas con precisión para entregar. Informan diariamente cuánto tiempo necesitarán aún para terminarlo. La velocidad (velocity) le dice a todos qué tan bien están trabajando. Los micromanagers están eufóricos, controlando cada minuto: falta de control, sin espacio creativo, presión para ir más rápido: una carrera de ratas.
Dado esto, en una situación aparentemente apretada, ¿importa si el producto es excelente para los usuarios? Por supuesto que no, ese es el trabajo del equipo UX. ¿Importa si tiene sentido? Del product owner. ¿Importa si los criterios de aceptación están completos? Otra vez, el trabajo del product owner. ¿Es importante estar libre de errores? Trabajo del tester, una vez pasados los criterios de aceptación. ¿Qué importa entonces? Que termine mi elemento del backlog a tiempo. ¿Ves la posición de Alan? Scrum lleva a los equipos a hacer todas las funcionalidades. La calidad es tarea de Alan. Se viola la regla fundamental y las cosas empeoran.
El equipo de Alan también obedece el compromiso. Llenan el sprint con tantos elementos del backlog como indica la velocidad. Luego hacen un juramento de entregarlo. La siguiente ley fundamental los golpea: ocurren imprevistos. En vez de romper el juramento, el equipo toma atajos y recorta algo en las pruebas. ¡Terminado a tiempo, bien hecho! Uno de los entrevistados lo resumió claramente: “La gamificación de comprometerse con un número de puntos de historia crea una competencia poco sana.”
El equipo de Alan ha caído en la trampa ágil. Aplican Scrum sin ser ágiles. Compara las siguientes dos imágenes, la primera es de lo que trata Scrum, la segunda de lo que trata la agilidad.
Scrum trata sobre el proceso para convertir elementos del backlog en un producto.
La agilidad trata de crear impacto con un producto y sobre la interacción de las personas involucradas: quienes piden un producto, quienes lo usan y quienes lo crean.
Mientras que Scrum es una gran herramienta para equipos ágiles motivados intrínsecamente, ¡es fatal en una jerarquía de mando de arriba hacia abajo!
Conclusiones
En la industria del software, es importante desarrollar mecanismos de defensa contra el estrés y el burnout entre los profesionales de pruebas de software. En algunas empresas más que en otras. Algunas situaciones son realmente apretadas, otras se hacen apretadas a propósito. Pero la mayoría de las situaciones parecen mucho más apretadas de lo que son. Y esto nos lleva a seguir nuestros impulsos, dejar de trabajar sobre los conflictos e ignorar reglas fundamentales.
La siguiente tabla resume los engranajes de un sistema de burnout.
Elementos clave de un sistema de burnout
- La tensión percibida es la brecha entre lo que vemos como nuestra tarea y lo que podemos entregar. Descubrir qué es realmente lo mejor que podemos lograr puede desmontar el sistema de burnout.
- Impulsores determinan hacia dónde fluye la energía y evitan que actuemos sabiamente en una situación tensa. Descubrir nuestros impulsores puede ayudarnos a gastar menos energía y a usarla mejor.
- Conflictos intensifican la situación, hacen que el equipo sea menos efectivo y drenan la energía. Creemos una cultura de equipo donde demos la bienvenida a los conflictos y nos ayudemos mutuamente.
- Las reglas fundamentales son fáciles de ignorar. Verlas ignoradas es una señal clara de que las cosas empeorarán. ¡Debemos actuar!
- Estructura del equipo congela buenas y malas prácticas. Cambiar la estructura del equipo puede cambiar fundamentalmente quién hace qué y cómo interactúan las personas. Puede cambiar completamente las reglas del juego.
- Círculos viciosos surgen de la interacción entre los actores dentro y alrededor del equipo y empeoran cada vez más la situación. ¿Podemos identificar los círculos viciosos que nos atraparon? ¡Necesitamos detenerlos y arreglarlos!
- La trampa ágil es adoptar marcos ágiles sin ser ágil. El resultado es una carrera de ratas. Centrémonos en los usuarios, en crear un gran producto y en cómo interactuamos, en vez de quemar elementos del backlog.
Como profesional de QA, puede que no estés en posición de cambiar la situación general para mejor. Pero probablemente sí puedas reducir algo de estrés.
Le pregunté a Jonathon Wright: "¿Dónde ha visto que empresas o equipos tomen medidas para promover la salud mental entre los profesionales de QA? ¿Qué funciona?"
Él respondió,
«Después de pasar el último año ayudando al Gobierno del Reino Unido a prepararse para el Brexit, quedé sumamente impresionado con la ética de trabajo. Asistí a mi primer curso obligatorio de mindfulness, que fue sumamente útil, tenían especialistas en salud mental en el lugar e incluso grupos de apoyo que se reunían semanalmente.»
También señaló que los QA pueden hacer mucho para gestionar su estrés y ansiedad a nivel personal:
«La vida es demasiado corta para preocuparse por las pequeñas cosas. Es difícil para los profesionales de QA no preocuparse previo al lanzamiento importante de un nuevo producto o sentirse responsables de cualquier resultado. Pero como en el Episodio II con Parveen, a veces solo necesitas 'déjalo ir, déjalo ir' y no 'mantener la calma'.»
Jonathon Wright, presentador del pódcast The QA Lead
«Como alguien que ha gestionado la ansiedad durante toda mi carrera profesional, ha tenido sus obstáculos y desafíos, pero siempre he salido fortalecido y en una mejor posición para gestionar mi ansiedad—aprendiendo más de mí mismo cada vez. La industria sí atrae a personas que están en distintos puntos del espectro (en el que me incluyo). Sin embargo, las personas más talentosas con las que he tenido la oportunidad de trabajar han sufrido de enfermedades mentales, por lo que trato mi enfermedad mental como un superpoder.»
Como señaló Jonathon, con un poco de suerte y la actitud adecuada, puedes convertir un trabajo estresante en uno gratificante. Te animo a adoptar la perspectiva que ofrece el concepto de un sistema de prevención del agotamiento. Deja ir la ansiedad, mantén la calma. Luego mira más allá de los mandamientos, procesos y herramientas. Concéntrate en lo que realmente importa: cómo tú y tus compañeros se ayudan unos a otros a crear grandes productos.
