Como é trabalhar como Analista de Qualidade (QA), por Érik Patekoski

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 o Érik Patekoski, um de nossos Mentores no projeto Mentoria, membro extremamente ativo do nosso Slack, sempre ajudando quem pede e um Analista de Qualidade com boas experiências no assunto.

Introdução

Fala galera, beleza? Me chamo Érik, vulgo Patota.

Tenho 28 anos sou casado a 4 anos.

Tenho um filho que completou 2 anos recentemente.

Estou na área de T.I desde os 14 anos e trabalho focado com Qualidade de Software a 10 anos. E hoje estou trabalhando dentro de uma célula de Arquitetura de Software e responsável pela Arquitetura de Testes Automatizados.

Atualmente trabalho em uma consultoria chamada BRQ e fico alocado no cliente CCEE (Câmara de Comercialização de Energia Elétrica).

Como você conheceu a área de Qualidade de Software?

O começo foi meio bizarro.

Tem um amigo meu que trabalhava comigo em uma loja de informática na Santa Efigênia (se você é um millenium, não deve saber o que era esse lugar na Golden Era) e lembro como se fosse ontem dele me falando que iria sair de lá para “testar programa”.

De cara fiquei bolado, afinal, porque você vai testar o pacote da MS Office? Ou o Nero? Isso foi muito difícil de entender.

Dois anos após a saída dele mantivemos contato, inclusive até hoje temos contato.

Eu entrei na faculdade e comecei a ter uma visão bem diferente além de formatar PC’s, cabeamento de rede e servidores.

Foi lá que comecei a entender um pouco sobre desenvolvimento de software. Na verdade não entendia nada, apenas achava que estava entendendo. Bom, conforme os bate-papos na faculdade foi levantado o quesito testes. Ai eu me liguei porque meu brother tinha saído, ele não tinha ido validar os pacotes office instalados nos PC’s e sim garantir que algum sistema funcionasse da maneira que ele cumpra o que foi prometido.

No outro dia falei com ele e tirei outras dúvidas a respeito.

Onde ele estava trabalhando precisava de um estagiário de Testes e bom… Ganhava mais e teria a oportunidade de largar o suporte, redes, formatações e PRINCIPALMENTE AS IMPRESSORAS!!!

Fiz a entrevista onde ele trabalhava e passei. Afinal, naquela época não procuravam por Estagiários nível Sênior. — hahahah.

Na verdade não entendia nada, apenas achava que estava entendendo

Por você escolheu ser QA?

Não foi algo que “eu escolhi ser QA” na real, acho que fui escolhido pela área.

Vivi diversos conflitos a respeito do meu cargo.

Pensava muito em ir para Desenvolvimento, DBA até cogitei Infra de novo.

Mas isso eu conto mais a frente.

Como foi o primeiro trampo?

O primeiro trampo como dito acima foi o bom e velho Q.I (quem indica, isso ajuda, mano… não vem meter o loko que aqui não cola).

Meu maior desafio sempre foi entender bem o que eu estava fazendo.

Sempre tive receio em iniciar um projeto do zero e estruturar bem ele para que outras pessoas pudessem olhar e entender o que estava acontecendo.

Ainda mais se tratando de automação de testes que algumas pessoas que vem para a área às vezes não tem muita XP. Então sempre me preocupei em criar algo que seja de conhecimento universal dentro da empresa que eu estou atuando.

Uma pessoa que sempre me ajudou e me ajuda até hoje é o Cassio Kenij.

Nos conhecemos já tem uns 15 anos. Estamos na área quase o mesmo tempo e ele sempre foi um cara a frente do tempo que estávamos.

Aprendi e continuo aprendendo muito com ele. ❤

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

Eu costumo dizer que para ser um QA, Tester, Automatizador, Analista de Teste você tem que ter em mente que você sempre, sempre vai ser o meio termo. O cara que ficou em cima do muro.

Ai você me pergunta porque e eu te respondo…

Você não é Dev e nem Analista de Negócios. Você sempre vai validar o trabalho de ambos e criar meios (automação de testes) para agilizar seu trabalho repetitivo.

Então os primeiros skills fundamentais são: ter bom senso e paciência.

Após isso, é fundamental conhecer uma linguagem Orientada a Objetos. Não precisa ser a fundo, mas, saiba fazer o básico para automação de testes.

Conhecer o básico de SQL para consultar massa de dados para validar seu teste.

Conhecer o básico de infra para conseguir se virar bem no ambiente de teste.

Conhecer bem Selenium Webdriver. Todos esses frameworks de testes e2e utilizam Selenium como core. Então, se você conhecer bem Selenium, os outros frameworks ficaram bem mais claros.

Quais são os principais desafios da área?

Pelo menos pra mim, é entender o que cada um do projeto quer.

Fazer com que o usuário, o analista de negócios, o dev e o GP falem a mesma língua é maior dificuldade e impacta diretamente no seu trabalho. Pois a probabilidade das informações se perderem e o mal entendimento é enorme.

Você é o último cara do ciclo como um todo.

Se você errar em algum passo toda a culpa cairá sobre você.

Você deve se manter atento a tudo que acontece no projeto para que você consiga prever.

Caso você deixe passar um bug para produção. Cara, isso vai ser um problema e não importa o tamanho do bug. Afinal você é pago “para que não haja bugs em produção”.

As etapas mais trabalhosas são:

• Entendimento do negócio (caso seja algo novo pra você)
• Entendimento das regras criadas ou alteradas

Fazer o re-teste é complexo. Pois na maioria das vezes o tempo já estourou e você está sendo pressionado.

Muita coisa pode dar errado... Desde a aplicação não funcionar devido esquecer de documentar um script de banco de dados como não finalizar a compra devido um teste que só dava pra ser feito em produção.

Quais são as principais recompensas da área?

É muito bom quando a aplicação sobe e não apresenta erro nenhum.

Isso é de fato um bypass para que você possa dormir tranquilamente e ter a sensação de dever cumprido.

Pelo menos isso, pra mim, é o suficiente. Às vezes rolou alguns parabéns quando eu me desdobrei, mas até aí, acredito que qualquer área reaja da mesma forma.

Da para trabalhar remoto, inclusive já fiz algumas vezes.

É melhor ainda quando você não precisa falar com ninguém. Somente desenvolver os scripts automatizados.

Sempre achei que é uma área que paga razoavelmente bem. Ainda mais quando falamos de pessoas lendo documentos, fazendo interpretação disso e escrevendo em passos e executando depois. Mas se quer dar um up, aprenda a automatizar. Isso faz muita diferença e te deixa como um destaque no meio de tantos analistas que não tem ideia de como iniciar um projeto.

Tem uma comunidade ativa. — mas eu particularmente não gosto muito.

Você pensa em mudar de área?

A uns 3 anos atrás pensei em ir para dev. Estava estudando fortemente para isso.

Mas na época meu custo de vida estava bem alto e não conseguiria manter a casa saindo do meu cargo para um dev jr. E eu queria mudar devido o sedentarismo da área e da empresa que eu estava também. Enfim, ainda bem que não me arrisquei.

Hoje estou bem feliz com o cargo que tenho e o que eu venho fazendo. Me dando gás para escrever isso aqui e ajudar a galera do Training Center da forma que consigo e vendo que faz sentido o que eu faço hoje.

O restante do conhecimento eu aplico nas minhas outras coisas e em freelas :).

Por que alguém deveria se tornar um(a) QA?

Se você gosta de analisar documentos mas não gosta de escrever um caso de uso. Ser um analista de teste vai ser bacana porém com uma certa limitação. Tendo em vista o mercado de hoje (2017).

Se você gosta de codar mas tem receio do seu código ser ruim, você pode ir para automação de testes e aprender a desenvolver mais. Eu, no começo, sempre tive dificuldade e com o passar do tempo estou bem mais seguro e aplicando o meu conhecimento em projetos de desenvolvimento também.

Então, se arrisque.

Hoje a área de testes, mais especificamente Automação de Testes, está em alta no mercado.

Pouca gente que tenha uma XP considerável. E Muitos que dizem que sabem mas infelizmente não sabem por onde começar.

E cada vez mais ela está se expandindo. Principalmente quando falamos de metodologias como BDD. Que pode ser aplicada até para ajudar o dev a escrever TDD, ajudar a área de negócios falar a mesma língua que o dev e o QA em questão.

Até mesmo batendo em UX.

Vamos ter que validar com funciona ioT, Machine Learning e por ai vai.

Poderia escrever muito mais sobre meu ponto de vista para a área, mas, se quiser saber mais pode me procurar no Slack do Training Center ou pelo meu blog https://patota.github.io/patekoskiblog/

É isso galera. Um abraço e espero ter te ajudado de alguma maneira :).

Este foi um post sobre como é trabalhar como Front-End Developer, porém também temos sobre como é trabalhar como Consultor de TI, por André Baltieri, Coordenador de Sistemas, por Jhonathan Souza Soares, Quality Analyst Engineer, por Úrsula Junque, Full-Stack Developer, por Ana Eliza, Líder Técnico, por Elton Minetto, Back-End Developer, por Giovanni Cruz e Front-End Developer, por Clara Battesini.

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.