Esgotamento nos testes de software: 6 causas e como o corrigir

É possível fabricar uma situação numa equipa de desenvolvimento de software de modo a que seja muito provável que um testador sofra de esgotamento? 

Se sim, o que podem os testadores aprender com esta experiência mental? 

Acontece que o esgotamento entre os profissionais de testes de software não é apenas uma experiência mental na indústria de testes de software — é um problema real e generalizado que afeta muitos programadores, engenheiros e testadores.

Analisei a fundo a questão do esgotamento nos testes de software, perguntando:

• Como se manifesta o esgotamento nesta indústria?
• Qual é a dimensão do problema?
• O que cria sistemas nos quais os testadores de software sofrem de esgotamento?
• Como podemos decompor a questão do esgotamento — e resolvê-la?

As respostas — ou, pelo menos, o início delas — encontram-se neste artigo.

Esgotamento entre os profissionais de testes de software em TI 

O stresse relacionado com o local de trabalho é algo que muitos de nós, na indústria das TI, experienciamos. Tenho a certeza de que também tem a sua dose de stresse. No meu contexto, infelizmente, o esgotamento tornou-se um tema cada vez mais relevante nos últimos anos.

O esgotamento é um problema?

Quando perguntei a Jonathon Wright: “Qual pensa ser a dimensão do problema do esgotamento entre os profissionais de QA?”, foi isto que respondeu:

“É um problema enorme. Palavras famosas: não se pode estar sempre a fazer sprints.”

Jonathon Wright, apresentador do podcast The QA Lead

Continuou, explicando:

“Metodologias como as metodologias ágeis e DevOps incentivam a ideia de fazer tudo ainda ‘mais depressa’. Como é que um profissional de QA pode proporcionar valor mensurável num contexto de falhar rapidamente e aprender depressa?

Num podcast recente do QALead, surgiu a expressão ‘abrandar para acelerar’. A menos que as empresas celebrem o fracasso (o que muito poucas fazem), sempre que falha não está a ajudar a velocidade do resto da equipa. 

A dica está no título do demasiado utilizado gráfico de trabalho restante. A gamificação do compromisso com um determinado número de pontos de história cria uma competição pouco saudável.

“É forçado a fazer mais com menos, trabalhando de acordo com uma expectativa irrealista de que o trabalho pode ser entregue em sprints de duas semanas.”

Jonathon Wright, apresentador do podcast The QA Lead

Como se manifesta o esgotamento em QA?

O esgotamento não é um caso isolado na indústria de software — mas como se manifesta?

Eis algumas respostas de profissionais de testes de software que mostram as formas como o esgotamento surge na QA.

“Temos de provar o nosso valor. As equipas dizem-me que são ágeis e que não precisam de testadores.”

“Ansiedade. É difícil para os profissionais de QA não se preocuparem antes de um lançamento importante ou não se sentirem responsáveis por quaisquer resultados.”

“Pressão do tempo. Os testadores estão sempre no fim da fila. E nunca tenho o tempo de que preciso. E esse tempo é reduzido para metade porque os programadores se atrasam.”

“Expectativas irrealistas. Poderia testar para sempre e não conseguiria testar tudo. Diga isto a um líder de projeto. Para que serve um testador que não encontra os erros?!”

“Perceber, a partir dos itens da lista de pendências, o que testar é quase impossível. E ninguém menciona os casos-limite.”

“O desperdício é frustrante. Os programadores não conseguem reproduzir um erro, o item da lista de pendências está desatualizado ou já o corrigiram.”

“Muitas pessoas não querem um relatório honesto e, sobretudo, não querem más notícias. Quando insiste, a situação pode tornar-se pessoal.”

Porque acontece o esgotamento?

A literatura enumera muitos fatores que causam stresse e aumentam a probabilidade de esgotamento. Existem fatores individuais, por exemplo, motivadores pessoais como ser perfeito, apressar-se, esforçar-se demasiado, ser forte ou agradar aos outros. Consulte a análise transacional para obter mais detalhes. 

E existem fatores de stresse provenientes do ambiente de trabalho. Uma carga de trabalho elevada, pressão do tempo, objetivos e expectativas inalcançáveis, falta de controlo, conflitos intensos, medo de perder o emprego, insatisfação com o trabalho, intimidação e assédio moral, entre outros. Conhecemo-los.

Há algum tempo comecei a analisar o burnout de um ponto de vista sistémico e criei um jogo de simulação em que os jogadores podem influenciar o destino de uma equipa de desenvolvimento de software. Podem levar os membros da equipa ao burnout ou criar o projeto mais gratificante de sempre. 

O coração da simulação é um sistema de burnout, ou seja, um sistema concebido de forma a que alguns membros de uma equipa acabem por sofrer de burnout. Pode ter um vislumbre do jogo no meu blogue.

Esta abordagem sistémica também funciona para diferentes funções numa equipa. Fiz isto para profissionais da experiência do utilizador e fiquei surpreendido com a facilidade com que se pode empurrar estas pessoas para o centro de um sistema de burnout. Especialmente quando cuidam dos utilizadores, estão dispostas a aceitar mais uma luta e a arriscar ficar esgotadas.

De seguida, vou mergulhar numa história de Alan, um profissional de garantia da qualidade, para compreender e ilustrar melhor o problema do burnout na indústria do software. 

Depois, falarei sobre como são criados os sistemas de burnout e o que podemos fazer para melhorar esses sistemas.

Uma história pessoal sobre burnout

Agora que tenho a certeza de que consigo criar um sistema de burnout para profissionais de garantia da qualidade, permitam-me apresentar-vos o Alan e a sua história. 

O Alan tem quase uma década de experiência em testes de software, especialmente em testes de desempenho. Está prestes a juntar-se a uma equipa de desenvolvimento. A equipa já trabalhou durante dez sprints e faltam mais quatro até à primeira versão. 

Como foi o primeiro dia do Alan no projeto?

Alan: Há muito para fazer da minha parte. O software tem baixa qualidade. Espero encontrar muitos erros não detetados e receio que haja problemas se não os conseguir encontrar antes do lançamento.

Markus: Identificar os erros é então a tua principal prioridade para melhorar a qualidade?

Alan: Isso é uma parte. Também esperamos muitos utilizadores. O desempenho do software é da máxima importância quando o disponibilizarmos ao público em geral. A equipa está ansiosa por beneficiar da minha experiência nessa área.

Até agora, o Alan está bastante otimista de que as medidas acordadas com a equipa irão melhorar a qualidade do software. Porém, um sprint mais tarde, com três sprints pela frente, o Alan já não parece tão animado. 

O que se passa?

Alan: As duas semanas foram intensas. Não estou satisfeito com o meu progresso. Queria fazer um primeiro teste de desempenho simples, mas estou muito longe de o conseguir.

Markus: O que te está a impedir?

Alan: Preciso do apoio dos programadores, mas eles estão sobrecarregados. Também precisei de muito mais tempo do que esperava para conhecer o software e comunicar os erros que encontrei.

Markus: Conseguiste testar as novas histórias entregues pela equipa?

Alan: Não propriamente, a equipa estava ocupada a aperfeiçoá-las. Dos dois dias reservados para testes no final do sprint, restou apenas meio dia. Fiquei mais tempo e trabalhei no sábado, mas ainda estou muito longe de terminar.

Na retrospetiva do sprint doze, com apenas dois sprints pela frente, os testes são o tema número um: o proprietário do produto queixou-se do número de erros encontrados pelo Alan.

Programador: A maioria dos erros encontrados pelo Alan é insignificante ou nem sequer corresponde a erros. Vamos analisá-los primeiro antes de tirar conclusões precipitadas.

Alan: Bem, foi difícil para mim perceber, a partir dos itens do backlog, o que o software deveria fazer. Uma especificação ajudaria bastante.

Programador: Só por cima do meu cadáver! Não queremos o modelo em cascata. É sobretudo uma questão de bom senso. Vem simplesmente perguntar-nos. Como estão a correr os testes de desempenho?

Alan: Estou num impasse. Não consigo fazer a ferramenta funcionar com a camada de serviços, por causa de toda essa segurança. Preciso de ajuda.

Programador: Usámos outra ferramenta no último projeto. Funcionou na perfeição. Envio-te o link.

Como resultado, o PO organiza uma reunião rápida de duas horas no sprint seguinte. O objetivo é rever os erros e discutir o que registar nos itens do backlog para facilitar as coisas ao novato Alan. Conseguem sentir a frustração do Alan a aumentar?

A posição fatal do Alan como bode expiatório torna-se mais evidente depois do sprint treze, com um sprint pela frente. Eis as decisões desta retrospetiva:

• Muitos erros foram encontrados nas histórias que o Alan deveria ter testado no sprint anterior. Nenhuma história deve ser encerrada sem que o Alan a tenha testado.
• Continuamos sem um teste de desempenho. Vamos pedir a um especialista para analisar a questão. O Alan deverá informá-lo sobre o assunto.
• Não foi possível concluir duas histórias. Perdemos dois dias a descartar relatórios de erros inúteis. O Alan assinala a relevância de cada erro. Em caso de dúvida, perguntar ao proprietário do produto.

Já reparou? A equipa não terminou duas histórias e conseguiu culpar o Alan! 

Imagine o próximo sprint, quando as histórias não forem fechadas porque o Alan não teve tempo para as testar! Não admira que o Alan pareça exausto.

Alan: Faltam apenas duas semanas para o lançamento e a qualidade é um pesadelo. Digam isso ao responsável pelo produto! E ainda por cima retiraram-me os testes de desempenho. Foi por isso que aceitei participar neste projeto. O meu chefe está descontente. Queria que eu desse o exemplo de como incluir testadores em equipas ágeis. No entanto, vou ter de levar isto até ao fim; a minha reputação na empresa está em jogo.

Quatro semanas mais tarde, duas semanas depois do primeiro lançamento para um público selecionado, o sistema de esgotamento está totalmente operacional. 

Resumo das conquistas do Alan até agora:

• Testes de desempenho: falhou
• Ser reconhecido como especialista em testes de desempenho: falhou
• Conseguir testar minuciosamente o que foi criado recentemente: falhou
• Conseguir testar novamente e minuciosamente o que já foi criado: falhou
• Incorporar testadores em equipas ágeis: falhou
• Não haver erros críticos no lançamento: falhou
• Ser recomendado: falhou
• Trabalhar arduamente e ser culpado: conseguido
• Medo de perder o emprego: conseguido
• Esgotamento: a caminho a toda a velocidade

Este é um caso clássico de um sistema de esgotamento. Então, o que cria este sistema e como podemos combatê-lo?

O que cria um sistema de esgotamento?

Poderia dizer-se que, para o Alan, é uma causa perdida desde o início. E teria razão. O Alan está num sistema de esgotamento que tem vindo a funcionar na equipa há já algum tempo. O sistema de esgotamento destaca o Alan como um predador destaca a sua vítima. Mas o que é este sistema de esgotamento e como funciona?

Um sistema de esgotamento é uma constelação de pessoas, impulsionadores e conflitos. Através de um ciclo de reforço, cria uma situação tão repleta de fatores de stress que algumas pessoas acabam por entrar em esgotamento. É especialmente poderoso quando consegue ativar a lógica de sobrevivência das pessoas.

1. A energia segue os impulsionadores

Na história do Alan, podemos identificar alguns impulsionadores:

• A ambição e o fascínio pelo tema de eleição dos testes de desempenho fazem com que o Alan queira realizá-los.
• A ansiedade de ser responsável por um lançamento falhado faz com que o Alan procure erros.
• Alguma coisa faz com que os membros da equipa deem prioridade à criação de funcionalidades.

Os impulsionadores alteram o curso da ação. As pessoas têm muita dificuldade em pensar claramente sobre o que alcançar e como alcançá-lo. A energia que as pessoas investem segue o impulsionador, e não aquilo que mais precisa dela. A equipa do Alan nunca questiona se criar todas as funcionalidades é a coisa certa a fazer. O Alan também não questiona se procurar erros é apropriado.

O difícil, para a maioria de nós, é tomar consciência de que um impulsionador assumiu o controlo. Felizmente, os psicólogos estudaram-nos. Para os impulsionadores pessoais, comece pela análise transacional. Ao nível da equipa, o pensamento de grupo é um bom ponto de partida. Encontrará muitos conselhos sobre o assunto.

Relativamente à ansiedade antes de um lançamento, um dos profissionais de QA mais experientes aconselhou: “Só precisa de deixar isso para trás e manter a calma”. Com esta atitude desde o início, provavelmente o Alan perseguiria um objetivo diferente de encontrar todos os erros e implementaria testes de desempenho. As prioridades principais poderiam ser a remoção dos erros críticos pela equipa e a entrega de uma qualidade geralmente superior. Uma forma de reduzir o stress associado a tarefas repetitivas é tirar partido de ferramentas de topo concebidas para testes de software.

2. Os conflitos intensificam-se e tornam-se pessoais

A par dos impulsionadores, surgem conflitos na equipa. Por exemplo, o Alan precisa de mais tempo dos programadores do que eles estão dispostos a disponibilizar. Resultado: o Alan cria muito ruído e os programadores tentam mantê-lo afastado. Com pouca ajuda, o Alan não consegue corresponder às expectativas. Teme pela sua reputação, redobra os esforços e gera ainda mais ruído.

O pior é que os conflitos se tornam pessoais. Tendo trabalhado como testador durante dez anos, o Alan é provavelmente um verdadeiro especialista. Ainda assim, a equipa vê-o como um incapaz e age como tal. Quanto mais tempo isto se prolonga, mais profundo se torna. Isto também afeta o Alan: começa a questionar a sua competência.

Quantas vezes culpou alguém? Quantas pessoas à sua volta não estão a fazer um bom trabalho? Cada pensamento deste tipo aponta para um conflito que se tornou pessoal.

A maioria das equipas é incapaz de resolver conflitos. Não é fácil. A gestão de conflitos é a palavra-chave para encontrar conselhos. A mensagem básica é: as equipas precisam de uma cultura onde as ideias possam ser trocadas abertamente, as opiniões divergentes sejam acolhidas como oportunidades para criar coisas novas e a entreajuda seja valorizada. Uma coisa difícil de alcançar, se compararmos isto com a cultura da velocidade descrita por um dos entrevistados: “A menos que as empresas celebrem o fracasso, cada vez que falha não está a ajudar a velocidade da equipa”.

3. A estrutura da equipa influencia a dinâmica da equipa

A equipa de Alan reservou os dois últimos dias do sprint para testar, fechar o sprint e preparar o sprint seguinte. A equipa simplesmente presumiu que Alan seguia esta estrutura. Ele testaria as funções recentemente implementadas no final do sprint e faria alguns novos testes no sprint seguinte, além de melhorar os testes em geral. Não parece assim tão mal, pois não?

A realidade conta uma história diferente. O software só fica disponível no último dia do sprint. Os itens do backlog pouco ajudam a perceber exatamente como deve funcionar. Enquanto a equipa discute os pormenores do que fará no sprint seguinte, Alan tenta perceber o que deve testar deste sprint. Depois, faz perguntas mesmo antes de os programadores saírem e testa durante o fim de semana. Ótimo que a equipa discuta o que deve ser escrito. Assim, Alan pode testar sem incomodar os programadores. Eureka.

A estrutura da equipa isola cada vez mais Alan. A equipa não o vê a debater-se. Apenas repara nas perguntas estúpidas e nos resultados tardios, de pouco valor. Que fracasso.

A especificação por exemplo mostra muito bem como os testes e os testadores podem ser parte integrante de uma equipa ágil. Os testadores participam nas sessões de refinamento, ajudam a criar uma especificação testável, concentram os esforços de teste onde são importantes, melhoram os processos da equipa, as competências individuais e as ferramentas, e até realizam alguns dos testes. Os testes são realizados continuamente, não apenas no final do sprint.

4. Ignorar regras fundamentais e arranjar problemas

A equipa de Alan ignora regras fundamentais da engenharia de software. 

Eis cinco delas:

1. Acontecem coisas inesperadas. Não deixar espaço suficiente para elas conduz à pressa, a atalhos, a erros estúpidos, a conflitos acalorados e, consequentemente, a um progresso mais lento a longo prazo.
2. A pressão causa atrasos. A pressão deixa menos espaço para as coisas inesperadas.
3. A qualidade é emergente. A equipa precisa de ter uma cultura de qualidade. Os testes são apenas uma peça do puzzle. E um único membro da equipa contra todos os outros costuma fracassar.
4. Mudar a equipa torna o trabalho mais lento. Criar confiança, adaptar processos, resolver mais conflitos: a equipa precisa de tempo e energia para integrar novos membros. Acrescentar pessoas a um projeto atrasado torna-o ainda mais atrasado.
5. Os defeitos servem para aprender. Quando um processo produz demasiados defeitos, pare-o, corrija-o e aprenda com ele. Não culpe ninguém e, acima de tudo, não o acelere.

Existem mais regras deste tipo e, sempre que as pessoas as ignoram, as coisas pioram. E foi isso que aconteceu a Alan.

5. Uma situação de aperto percecionada desencadeia o problema

Como é que a equipa ignora coisas tão fundamentais? É fácil. É típico numa situação de aperto, em que as condições dadas (entregáveis, tempo disponível e a equipa) não deixam flexibilidade suficiente para lidar com coisas inesperadas. Já passei por isso, está tudo dito, é um caso evidente. Os sistemas de esgotamento exploram a única variável numa configuração apertada: o grau de esforço da equipa, ou seja, a quantidade de energia que os membros da equipa consomem das suas baterias.

A questão crucial: a equipa de Alan está realmente numa situação de aperto e entregar todas as funcionalidades é a melhor opção? Só podemos presumir. A equipa fez o mesmo e apressou-se a tentar construir todas as funcionalidades.

É a perceção das situações de aperto que importa. O fator desencadeador dessa perceção pode ser uma cláusula contratual, um incentivo, uma grande oportunidade de mercado, uma forte exigência de um chefe, uma promessa feita, um desejo de um cliente ou uma regulamentação governamental.

Alan espera grandes quantidades de erros e a ansiedade faz com que os procure incansavelmente. A questão crucial para ele: encontrar os erros é realmente um passo tão importante neste caso? Só podemos especular, e foi isso que Alan fez. Presumiu que sim.

A perceção de uma situação de aperto é uma alavanca importante para romper um sistema de esgotamento. Por trás dela está outra regra fundamental da engenharia de software:

• Expectativas demasiado elevadas. As partes interessadas — incluindo os próprios programadores — esperam, acreditam ou exigem mais do que uma equipa de software consegue realisticamente entregar.

Ao olhar para os últimos 25 anos da minha experiência em projetos, não me consigo lembrar de um único caso em que isto não acontecesse. O conflito entre o que é esperado e o que pode ser entregue é o ponto crítico. O sucesso de um projeto depende de quão bem as pessoas envolvidas conseguem resolver este conflito. Recomendo a revisão de boas práticas sobre a gestão das partes interessadas e das expectativas, a gestão de conflitos, a engenharia de requisitos, a agilidade e temas semelhantes.

Em qualquer caso, é necessário compreender a natureza exata do conflito. Qual é a sua intensidade? O que o provoca? Com quem precisa de trabalhar? Ou, como afirmou um dos profissionais de QA entrevistados: “Acredito que todas as empresas precisam de tomar uma decisão consciente relativamente à qualidade, ao custo e à velocidade”. Todas as empresas precisam de trabalhar as suas expectativas.

Normalmente, os profissionais de QA não estão em posição de liderar esta discussão. Podem tentar contribuir. Poderá ser mais proveitoso gerir as expectativas que enfrentam pessoalmente. Uma entrevistada contou-me a sua receita: “É impossível testar tudo. O melhor é definir um período de tempo limitado e as prioridades com o responsável pelo produto. As prioridades refletem o risco de não testar. Quando não estiver satisfeito, renegocie o período de tempo limitado e as prioridades.”

6. Armadilha do ágil

Uma equipa forte que se adapta continuamente às necessidades em mudança, uma forma não burocrática de lidar com a mudança, meios simples de planeamento e controlo do progresso: o movimento ágil trouxe uma série de inovações das quais as equipas de desenvolvimento fazem bem em tirar partido. Ainda assim, o ágil parece estar a agravar a situação.

Começa pelo próprio vocabulário: Sprint significa rapidez, velocidade significa rapidez, falha-se rapidamente. Os princípios ágeis colocam o código em primeiro lugar, e pensar antecipadamente é facilmente descartado como desperdício. Até o termo scrum vem do râguebi, um desporto em que os atletas se enfrentam a toda a velocidade. Assim, a agilidade, mesmo contra as suas convicções, promove a velocidade em detrimento da qualidade. “Metodologias como Agile e DevOps incentivam a ideia de fazer tudo ainda mais depressa”, queixou-se um profissional de QA.

A mecânica do scrum, por exemplo, é ainda pior do que o vocabulário. Não é que aqueles que criaram o Scrum quisessem fomentar o esgotamento. Mas o scrum conduz as equipas pelo caminho errado.

Em primeiro lugar, centra a atenção da equipa no backlog. A função do proprietário do produto é colocar itens no backlog. A função de um membro da equipa é pegá-los e executá-los um a um. A função do mestre de scrum é garantir que isto acontece mais depressa. Depois, o controlo do progresso ágil precisa de itens pequenos no backlog, que possam ser concluídos em poucos dias. Os especialistas também recomendam critérios de aceitação detalhadamente definidos antes do sprint. Os membros da equipa recebem tarefas pequenas e precisamente definidas para entregar. Comunicam diariamente quanto tempo ainda precisam para as concluir. A velocidade indica a todos o seu desempenho. Os microgestores rejubilam e controlam cada minuto: falta de controlo, ausência de espaço criativo, pressão para acelerar: uma corrida desenfreada.

Dado isto, numa situação aparentemente apertada, importa saber se o produto é excelente para os utilizadores? Claro que não, essa é a função da equipa de UX. Importa saber se faz sentido? É a função do proprietário do produto. Importa saber se os critérios de aceitação estão completos? Mais uma vez, é a função do proprietário do produto. É importante não ter erros? É a função do testador, depois de os critérios de aceitação serem cumpridos. O que importa? Que eu conclua o meu item do backlog a tempo. Vê a posição de Alan? O Scrum conduz as equipas a implementar todas as funcionalidades. A qualidade é da responsabilidade de Alan. A regra fundamental é violada e as coisas estão a piorar.

A equipa de Alan também cumpre o compromisso assumido. Enchem o sprint com tantos itens do backlog quantos os indicados pela velocidade. Depois juram entregá-los. A próxima lei fundamental atinge-os: acontecem imprevistos. Em vez de quebrarem o juramento, a equipa toma atalhos e corta alguns elementos dos testes. Concluído a tempo, muito bem! Um dos entrevistados explicou-o de forma bastante clara: “A gamificação do compromisso com um determinado número de pontos de história cria uma competição pouco saudável.”

A equipa de Alan caiu na armadilha do ágil. Aplicam o Scrum sem serem ágeis. Compare as duas imagens seguintes: a primeira mostra aquilo de que trata o Scrum, a segunda mostra aquilo de que trata realmente o ágil.

O Scrum trata do processo de transformar itens do backlog num produto.

O ágil trata de criar impacto com um produto e das interações entre as pessoas envolvidas: as que encomendam um produto, as que o utilizam e as que o criam.

Embora o Scrum seja uma excelente ferramenta para equipas ágeis intrinsecamente motivadas, é fatal numa hierarquia de comando de cima para baixo!

Conclusões

Na indústria do software, é importante desenvolver mecanismos de defesa contra o stress e o esgotamento entre os profissionais de testes de software. Em algumas empresas mais do que noutras. Algumas situações são realmente apertadas, outras são deliberadamente tornadas apertadas. Mas a maioria das situações parece muito mais apertada do que é. E isto leva-nos a seguir os nossos impulsionadores, a deixar de trabalhar nos conflitos e a ignorar regras fundamentais. 

A tabela seguinte resume as engrenagens de um sistema de esgotamento.

Elementos-chave de um sistema de esgotamento

• A sensação de aperto é a diferença entre aquilo que consideramos ser a nossa tarefa e aquilo que conseguimos entregar. Descobrir qual é realmente o melhor resultado a alcançar pode desmantelar o sistema de esgotamento.
• Os impulsionadores definem para onde flui a energia e impedem-nos de agir sensatamente numa situação apertada. Descobrir os nossos impulsionadores pode ajudar-nos a gastar menos energia e a utilizá-la de forma mais inteligente.
• Os conflitos agravam a situação, tornam uma equipa menos eficaz e drenam energia. Criemos uma cultura de equipa em que acolhemos os conflitos e nos ajudamos uns aos outros.
• As regras fundamentais são facilmente ignoradas. Ver que são ignoradas é um sinal seguro de que as coisas vão piorar. Temos de agir!
• A estrutura da equipa fixa boas e más práticas. Alterar as estruturas das equipas pode mudar fundamentalmente quem faz o quê e como as pessoas interagem. Pode mudar completamente as regras do jogo.
• Os ciclos viciosos surgem da interação entre os intervenientes dentro e em redor da equipa e tornam a situação cada vez pior. Conseguimos identificar os ciclos viciosos que nos apanharam? Temos de parar e corrigi-los!
• A armadilha do ágil consiste em adotar estruturas ágeis sem ser ágil. O resultado é uma corrida desenfreada. Concentremo-nos nos utilizadores, na criação de um excelente produto e na forma como interagimos, em vez de eliminar itens do backlog.

Enquanto profissional de QA, talvez não esteja numa posição que lhe permita mudar a situação geral para melhor. Mas provavelmente pode reduzir algum stress. 

Perguntei a Jonathon Wright: “Onde viu empresas ou equipas a tomar medidas para promover a saúde mental entre os profissionais de QA? O que funciona?”

Ele respondeu, 

“Depois de passar o último ano a ajudar o Governo do Reino Unido a preparar-se para o Brexit, fiquei extremamente impressionado com a ética profissional. Frequentei o meu primeiro curso obrigatório de atenção plena, que foi extremamente útil; tinham especialistas em saúde mental no local e até grupos de apoio que se reuniam semanalmente.”

Também salientou que os profissionais de QA podem fazer muito para gerir o seu stress e ansiedade a nível pessoal:

“A vida é demasiado curta para nos preocuparmos com as pequenas coisas. É difícil para os profissionais de QA não se preocuparem antes do lançamento importante de um novo produto ou não se sentirem responsáveis por quaisquer resultados. Mas, tal como no Episódio II com Parveen, por vezes é preciso simplesmente ‘deixar andar, deixar andar’ e não ‘manter a calma’.”

Jonathon Wright, apresentador do podcast O Líder de QA

"Enquanto alguém que geriu a ansiedade ao longo de toda a minha carreira profissional, enfrentei dificuldades e desafios, mas saí sempre do outro lado mais forte e numa posição melhor para gerir melhor a minha ansiedade — aprendendo mais sobre mim próprio de cada vez. O setor atrai, de facto, pessoas que se encontram em vários graus do espetro (e eu incluo-me a mim próprio). No entanto, as pessoas mais talentosas com quem tive oportunidade de trabalhar sofreram de doença mental, razão pela qual trato a minha doença mental como um superpoder!”

Tal como Jonathon salientou, com um pouco de sorte e a atitude certa, é possível transformar um trabalho stressante num trabalho gratificante. Incentivo-o a adotar a perspetiva oferecida pelo conceito de um sistema de esgotamento. Deixe a ansiedade ir, mantenha a calma. Depois, olhe para além de mandamentos, processos e ferramentas. Concentre-se no que realmente importa: na forma como você e os seus colegas de equipa se ajudam mutuamente a criar excelentes produtos.