Como é trabalhar como QA, por Úrsula Junque

Esse post é parte de uma série de entrevistas para o Training Center sobre o que um profissional pode dizer sobre sua área de atuação visando mostrar para outras pessoas como é trabalhar no que fazem, esclarecendo para algumas pessoas se elas se dariam bem trabalhando na área ou mesmo só para mostrar para outras pessoas como é trabalhar com isso.

Essa entrevista foi enviada para a Úrsula Junque, Engenheira de QA na Canonical muito ativa nas comunidades open source.

Introdução

Oi gente! Meu nome é Úrsula Junque, mais conhecida como Ursinha, e sou formada em Ciência da Computação pela UNICAMP. Já me adianto e digo: Engenheiro de QA é igual DevOps, a definição do escopo de trabalho varia muito! Aqui vou falar sobre a minha experiência. Se quiser falar mais comigo e saber mais causos, eu sou a @ursinha em todo lugar, só me chamar. :)

Trabalho na área de software desde 2002 (!), e desde pelo menos 2005 estou envolvida com software livre e open source. Trabalho há quase nove anos na empresa Canonical — a que patrocina aquela distribuição linda que é o Ubuntu — e fiz parte da comunidade por muitos anos.

Nesses muitos anos de computação fui e voltei da função de QA, mas estou trabalhando ~firme~ como QA* já há dois anos e meio no time do Landscape.

*Por QA entenda-se: tester, desenvolvedora de automação de infra, desenvolvedora de suites de testes, Scrum Master, Product Owner, e mais um monte de coisas pra conseguir qualidade.

Engenheiro de QA é igual DevOps, a definição do escopo de trabalho varia muito

Como você conheceu a área de QA?

Quando entrei pra computação em 2002, qualidade de software, testes automatizados e frameworks eram all the rage. Todo mundo jurava que testes e automação iriam salvar o mundo das cáries, e por esse motivo esse assunto era bem discutido.

Não me interessei pela área pois tudo era muito ligado a java e essa nunca foi minha linguagem favorita, mas não dava pra ignorar a existência dessa tal de qualidade de software. Se dependesse da faculdade eu nunca teria trabalhado com isso, pois tudo que eu via era unit tests em java, UML, waterfall. O inferno! Eu só não concordava com a implementação, mas a ideia era boa. :)

Por que você escolheu ser QA?

Não foi algo que eu escolhi. Honestamente, eu não queria ser QA! Primeiro porque na minha época — *cof* — QA era sinônimo de testador que executa planos de teste, e isso eu não queria fazer. Eu queria poder evoluir as coisas, os processos, trazer mudança, e o tradicional QA não parecia permitir isso. Segundo porque sempre gostei muito de desenvolver ferramentas de automação, aí era mais óbvio pensar em ser sysadmin do que QA.

Mas aí, com o passar dos anos, eu sempre acabava nessa posição de QA, quando me dava conta estava quebrando as coisas que os outros faziam, querendo automatizar os processos, enchendo a paciência do gerente pedindo requisito que faltava. Depois de um tempo eu percebi que o QA que eu fazia era o QA ágil, ~moderno~, com uma perna em DevOps, e que havia espaço pra usar minhas habilidades dessa forma.

Como foi o seu primeiro trampo?

Meu primeiro trabalho oficial como QA foi na própria Canonical. Quando entrei em 2008, entrei como engenheira de QA no time do Launchpad. Eu já tinha trabalhado no Linux Technology Center da IBM, e lá conheci as pessoas com quem depois passei a trabalhar na Canonical. Linux FTW!

O maior desafio pra mim ao entrar foi a barreira da língua. Empresa com gente do mundo inteiro, inglês com todo tipo de sotaque imaginável. Eu sabia inglês mas a fluência mesmo conquistei ao longo dos anos, até chegar lá eu fui passando vergonha. — brincadeira gente :)

Uma dica de ouro: o pessoal de fora se preocupa menos com a nossa pronúncia do que a gente pensa, o importante pra eles é você conseguir se comunicar, então não priemos cânico! #ficadica

Felizmente, o time no qual entrei na Canonical era feito de muitas pessoas brilhantes, com as quais aprendi muito e que valorizavam muito a qualidade do software que estavam desenvolvendo. Em empresas sérias, a palavra do engenheiro de QA tem um peso enorme, e nesse time pude amadurecer a ideia de ser QA ativamente e desenvolver formas de atingir qualidade de software. Ao contrário do que tentaram me convencer na faculdade, testes unitários e automação de testes não são as únicas formas de obter qualidade. As vezes eles nem são adequados! (Polêmica!!!)

Ao contrário do que tentaram me convencer na faculdade, testes unitários e automação de testes não são as únicas formas de obter qualidade. As vezes eles nem são adequados!

Quais são as skills de quem trabalha nesta área?

As tecnologias utilizadas são substituíveis e substituídas com frequência, novos frameworks e linguagens surgem a cada dia, e com isso os testes mudam. Então é bom ser adaptável e pragmático — que é uma boa qualidade de se ter em qualquer área na computação. E talvez saber um pouco de Jenkins, que parece ser uma ferramenta que não morre nunca.

QA é uma área vasta. Você pode ser tanto a pessoa que implementa testes quando a pessoa que faz testes exploratórios manuais, assim como a pessoa que pensa em como testar continuamente um sistema (você já deve ter ouvido falar em Continuous Integration) — afinal isso significa menos trabalho manual pra você e você pode focar no não-automatizável.

Em todos casos, o que faz diferença num bom engenheiro de QA é a atenção ao detalhe e a preocupação com o resultado final. Aquela pessoa que se tiver que escolher entre um código de arquitetura linda e um sistema simples mas que executa sua função com maestria, vai escolher o último.

Muito importante é conseguir se colocar no lugar de quem vai usar seu sistema, sempre tentando abordá-lo também sob esse ponto de vista, e não só como um desenvolvedor faria. Garanto que isso aumenta muito a chance de você achar problemas que nem foram pensados na implementação.

Seja como for que você vá testar seu sistema, na minha opinião esse é um grande valor que você pode oferecer: diferentes e dinâmicos pontos de vista.

E ah, ajuda ser preguiçoso também, pra querer automatizar tudo que der. :)

Quais são os principais desafios da área?

O maior desafio é quando a empresa não valoriza o trabalho de QA. Empresas antigas frequentemente não dão atenção aos problemas que o engenheiro de QA encontra, e tem desenvolvedores que sentem prazer em marcar os bugs como WON’TFIX. Isso quando o desenvolvedor não trata o código como se fosse um braço ou uma perna, tornando cada bug report um incidente diplomático. :)

Essas coisas podem fazer do trabalho de QA uma coisa desgastante e um exercício de futilidade. Fazer QA direito implica em ter que falar pro seu chefe que a release de amanhã não pode sair porque tem um bug crítico e vai ficar feio, ou em chegar pro coleguinha que passou duas semanas em um branch e dizer que o código dele introduziu regressão e vai ter que ser revertido. As vezes não é divertido!

s/jenkins/QA/ :)

Pra dar certo, o time tem que abraçar a causa e dar peso pro que o engenheiro de QA trouxer, e fazer algo a respeito. Pode ser desafiador encontrar empresas que estejam dispostas a considerar QA uma parte importante do desenvolvimento, mas a boa notícia é que com o aparecimento da cultura ágil e de DevOps, que fez tudo ficar mais dinâmico, QA deixou de ser “caçador de bugs” e passou a trabalhar com evitar que esses bugs cheguem tão longe.

Por experiência, as empresas que usam ou se interessam por metodologias ágeis são as melhores candidatas a boas empresas pra engenheiros de QA, já que nesses ambientes QA não é visto como a última etapa do desenvolvimento, mas parte integrante dele.

Quais são as principais recompensas da área?

Pra mim, a maior recompensa é ter orgulho e confiança em algo que fiz parte do desenvolvimento e que está público, com pessoas usando. Nem sempre isto é possível alcançar, mas pra mim esse é o maior prazer: trabalhar com pessoas que se importam com qualidade assim como eu e poder fazer as coisas direito, sem precisar ter vergonha de hack maligno que mandaram pra produção.

Eu trabalho remotamente já há 9 anos, então dá pra trabalhar remoto e pode ser divertido. Como o conceito de QA parece ter evoluído ao longo dos anos, e agora QA é um desenvolvedor com foco em qualidade, a faixa salarial hoje em dia não deve estar longe dos demais profissionais da área. — Por favor me corrijam se eu estiver errada. :)

Você pensa em mudar de área?

Não é algo que eu busque. Hoje em dia eu reconheço que tenho certas habilidades e poder usá-las de forma útil é muito gratificante! O que eu gosto mesmo é de trabalhar em equipe por um objetivo maior, e QA permite isso.

Mas se um dia eu for mudar de área vai ser pra fazer alguma outra coisa que tenha o mesmo objetivo, sabendo que o espírito de QA nunca vai sair de mim. :)

Por que alguém deveria se tornar um engenheiro de QA?

Engenheiro de Quality Assurance (como o nome diz) é aquele que está ali pra garantir a qualidade, e em software a gente pode alcançar isso de várias formas: com automação de processos, ajudando a implementar infraestrutura de testes, discutindo com os desenvolvedores como introduzir testes no desenvolvimento, e assim vai.

Se você gosta de quaisquer dessas coisas e gosta de colaborar com os demais pra atingir esse objetivo, QA pode ser legal pra você. :) Eu tenho esperança que qualidade em geral continue crescendo em importância pras empresas, e com isso seja mais fácil encontrar esse tipo de trabalho pra quem gosta.

Este foi um post sobre como é trabalhar como Quality Analyst, porém também temos sobre como é trabalhar como Consultor de TI, por André Baltieri, Coordenador de Sistemas, por Jhonathan Souza Soares, Analista de Qualidade, por Érik Patekoski, Full-Stack Developer, por Ana Eliza, Líder Técnico, por Elton Minetto, Back-End Developer, por Giovanni Cruz e Front-End Developer, por Matheus Lima.

Continue acompanhando nossos posts sobre como é trabalhar nas áreas relacionadas a desenvolvimento de software.

Siga o Training Center no Twitter para se manter atualizado(a) sobre nossas novidades: trainingcentr

Entre no nosso Slack para participar das decisões desse projeto e também para ver gifs engraçados!

Conheça nossas iniciativas.