Getting Technical I: Três Passos pra Começar

Esse é o primeiro de pelo menos cinco posts sobre tecnologias, ferramentas ou práticas de viés técnico para aumentar produtividade e diferenciar o seu currículo. Esses posts vão reunir quinze, dos muitos elementos que fazem parte do dia a dia de um QA.

Em alguns casos vamos falar de uma ferramenta em particular, como o Jenkins ou o Rake. Escolhi as ferramentas com base no que eu trabalho, mas sinta-se a vontade para escolher uma ferramenta alternativa. O importante é conseguir o benefício. Se esta usando Java provavelmente vai ser melhor usar o Gradle do que o Rake por exemplo.

Eu não fiz nenhuma pesquisa profunda, com formulários ou monografia, mas estou no mercado a algum tempo e converso bastante com pessoas em foruns e listas, além é claro de ser um recrutador de novos QAs para times em diferentes empresas desde de 2007. Juntei um pouco do que eu sinto que está faltando, especialmente nos QAs do Brasil. Sinta-se a vontade para comentar outras necessidades ou se acha que algum dos itens não deveria estar aqui. Fazendo isso me ajuda a melhorar a minha percepção.

1 – Mude para o Linux

Terminal do Linux
Terminal do Linux

O básico de qualquer engenheiro, desenvolvedor ou tester é saber operar Linux. A maioria das applicações web hoje em dia (e sempre) são suportadas por Linux. A maioria dos testes automatizados, rodam mais rápido ou são mais fáceis de executar em Linux. Não existem contra argumentos. Em algum momento da sua vida você vai ter que trabalhar com Linux. Porque adiar o inevitável?  Abrace a mudança e aprenda antes que lhe seja cobrado ou antes de perder aquela oportunidade de entrar em uma empresa mais legal.

Substituir Windows por Linux ou mesmo MacOS em casa pode ser o primeiro passo. Ganhando confiança e ficando basicamente produtivo, pode substituir o sistema que usa no trabalho também. Se ja trabalha em um ambiente que usa Linux, mas usa Windows para ter Internet Explorer, use uma maquina virtual com Windows e trabalhe no Linux. A curva de aprendizado usando todos os dias, para ficar minimamente produtivo, no meu caso foi de três meses.

O linux te permite fazer instalações de ferramentas modernas em segundos. O Linux também tem todas as IDEs mais famosas (exceto Visual Studio e percursores), o que torna a adaptação ainda mais fácil no caso de ambiente desenvolvimento.

Além de todas as vantagens listadas acima, por ter um terminal muito mais amigável e o fantástico apt-get, o Linux também vai facilitar e potencializar o uso das próximas ferramentas. Download Ubuntu

2 – Controle tudo com Git

Github, Social Coding
Github, Social Coding

Ninguem trabalha sozinho em sua máquina. Código e outros “artefatos” do desenvolvimento de software hoje em dia tem sido amplamente compartilhados inclusive em redes sociais. Infelizmente, encontrar testers e QAs que dominem Git, mesmo que de maneira básica, ainda é uma tarefa relativamente complicada. Em parte pela baixa quantidade de testers que trabalhem com código. Saia na frente!

Git é um elemento tão básico, que raramente encontra-se uma vaga dizendo “Dominar Git”. Git transformou gestão de configuração, que chegava a ser um risco para o projeto, além de uma atividade complexa e cansativa, em uma atividade simples para o nosso cotidiano.

Ainda me lembro que na primeira empresa que eu trabalhei, onde bloqueavamos os arquivos que estavamos trabalhando no Source Safe para evitar conflitos. Na segunda, tinhamos um “gestor de configuração” encarregado de fazer merge em SVN ou CSV. Cenários impensáveis para quem começou com git.

Aprender git é muito simples. Existem toneladas de materiais, guias e video aulas gratuitas na internet. Existem ferramentas com interface gráfica para iniciantes, plugins para todas as IDEs e até uma “rede social”, pra aprender compartilhando.

Depois de aprender Git, além de estar preparado para trabalhar em projetos distribuídos e em empresas modernas, você ainda vai poder colaborar com projetos abertos no GitHub :).

3 – Tire uma folga e deixe o Jenkins testar por você

Jenkins CI
Jenkins CI

O Jenkins é melhor QA que eu já conheci. Ele testa em todas as linguagens, de Erlang até Javascipt. Ele testa todas as plataformas e browsers, até IE. Ele sabe operar todos os bancos de dados, e se ele estiver devagar, você pode dar mais computadores e ele trabalha mais rápido. Ele também adora escrever relatórios e o melhor de tudo, ele faz a parte chata do seu trabalho todos os dias e noites sem reclamar.

O Jenkins é um dos melhores amigos do testador inteligente. Obviamente ele não faz mágica, e tudo deve ser automatizado. Mas toda a parte de execução automatizada, relatórios e claro, burocracia de guardar evidências de testes e dados utilizados é feita por ele. O time tem que desenvolver os scripts, mas muitas vezes isso não da muito trabalho, visto que alguns scripts são reaproveitados, como os de execução de testes automatizados, de execução de cucumber, deploy da aplicação e assim por diante.

Quando se aprende a configurar o Jenkins, você e seu time passam a ter controle sobre o processo de desenvolvimento de uma maneira muito mais completa do que qualquer CMMi. Você controla o produto, o número de testes, a pipeline de desenvolvimento até a entrega. Muitas das novidades de hoje, como a entrega continua, só são possíveis graças a ferramentas como o Jenkins.

Além do Jenkins, existem outras ferramentas com a mesma finalidade. Entre as que eu já trabalhei estão o Hudson (versão da Oracle para o Jenkins), o open-source ThoughtWorks Go (desenvolvido para pipeline de continuous delivery) e Electric Commander.

No próximo post “Getting Technical II: Três Maneiras de Criar seu Ambiente” vamos falar de Vagrant, Puppet, Chef e Cloud, e sobre os benefícios de ter ambiêntes controláveis, reproduzíveis, automatizados e prontos para serem criados/escalados a qualquer hora.

Comente e envie o seu feedback. Muito obrigado pela visita e bons testes :)

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

25 thoughts on “Getting Technical I: Três Passos pra Começar

  1. Demais camilo, essas suas dicas sao valiosas demais para um aprendiz na area de programacao/qualidade. Continue com os posts, isso da um UP na galera :)

  2. Valeu pelo post, bem legal e estou esperando a continuação!
    Eu tenho uma dúvida em relação ao Jenkins:
    Nas equipes que você já trabalhou todos tinham acesso adm no Jenkins ou ferramenta similar?
    Estou perguntando porque na equipe que trabalho hoje, todos tem acesso full e ajudaram a construir o pipeline. Mas, fico imaginando num momento de pressão / hot-fix tem um teste que está falhando e não está relacionado com o que a pessoa fez…alguém pode dar um skip nos testes para gerar o build. Depois de consolidado o pipeline, é comum todos ainda terem acesso adm?
    Começamos com IC há pouco tempo, por isso a pergunta. Valeu, abraço.

  3. Eu acho que usar linux em casa pode ser doloroso e um pouco traumatizante… pelo menos alguns anos atras era mais…. Se é para usar GNU de linux.. eu prefiro usar windows..rsrs agora… vc pode tirar 5 dolares da sua carteira e ter uma maquina virtual na digital ocean e pode rodar a distro que você quiser….
    Monte um blog.. coloque um wordpress ou um ghost rodando do zero… acho isso mais produtivo do que se forçar a usar linux em casa ;0)

    Da pra viver bem com os 2 eco sistemas.. :)

  4. Como o Rafael disse aí, essas suas dicas são fantásticas, muito agradecido pelos bizus!

  5. Excelente dicas, ótima linguagem e tudo muito sucinto!
    Estarei sempre por aqui acompanhando os post, parabéns pela sua visão!

  6. Excelente!

    Teslink e Selenium IDE não são o suficiente! Siga o caminho técnico com as dicas do Camilo e você estará no caminho para se tornar um profissional mais qualificado!

  7. Mais uma vez parabéns Camilo!
    Visto que este post e os demais que estão por vir, atendem a maioria das dúvidas atuais que estão sendo enviadas nas listas de testes, pessoas que querem iniciar e não sabem por onde ou ainda não tem condições financeiras para investir em qualquer tipo de treinamento.

  8. Bom post Camilo, o SO Windows não é tão ruim quanto você cita, há sim muitas ferramentas open source tão boas quanto as disponíveis para linux. Há contra argumentos sim no uso de linux em preferência ao Windows, acho que seria mais benéfico o aprendizado conhecendo a diferença entre os dois tendo assim a capacidade de fazer opção entre eles.
    A ferramenta apt (apt-get como cita) é mais comum em distribuições debian, outras distribuições podem usar outras ferramentas de package management como o yum.
    Uma nota sobre o Jenkins ou CI é que eles não são testadores e sim meros gerenciadores de tarefas podendo ou não ser automatizadas. Pela sua usabilidade e flexibilidade o mesmo é usado atualmente com diferentes escopos, desde testes automatizados à deployments.
    Por fim abrace é com C. Obrigado pelo continua a quest.

  9. Olá Eduardo.

    Sim, normalmente todo mundo tem acesso e pode manter o pipeline e os slaves. Embora eu entenda a sua preocupação, eu acho muito improvável que isso aconteça. Ainda porque o teste roda no código, logo ninguem precisa de acesso ao jenkins para desativar um teste ou colocar um “assert true” e fazer com que ele passe.

    O que você pode fazer, é colocar o login como obrigatório para mudar configurações ou disparar builds de maneira manual, sem evitar que as pessoas tenham acesso para ler e acompanhar as pipelines.

    O mais importante é que todos entendam que se está ruim com IC, é muito provável que seja pior sem ela :)

    Boa sorte e obrigado pela visita e comentário :)

  10. Grande Galani,

    Você tem razão. Pode ser traumatizante. Mas o desconforto faz parte do dia a dia, e uma das melhores skills que podemos aprender (na minha opinião) é saber lidar com esse desconforto e aprender a superá-lo o mais rápido possível, afinal, todos os dias tem uma versão nova de alguma coisa, um novo plugin pra isso ou aquilo e etc.

    Sabendo disso, ter algo no seu dia a dia vai te ajudar e muito a dominar esse algo e a te especializar em aprender e conviver com o desconforto tecnologico. Com o linux não é diferente. Mas sim, uma outra estratégia é ter algo que pode usar a qualquer momento, como uma máquina virtual ou uma Digital Ocean/Amazon cloud da vida.

    Obrigado pela visita e pelo comentário :)

  11. Fico muito feliz de ouvir isso Luciana. Por favor, sinta-se a vontade para comentar e criticar os posts, assim como para questionar ou perguntar sobre dúvidas. Obrigado pela visita.

  12. Muito obrigado Frederico,

    Eu vejo muito disso também, e eu por exemplo apdendi (e aprende) a maioria das coisas lendo posts na interenet, livros relativamente baratos e também ao trabalhar com pessoas que tem toneladas de experiência. Eu tento passar um pouco disso pra frente e saber que estou ajudando de alguma maneira, me deixa profundamente feliz.

    Obrigado pelo comentário e pela visita!

  13. Muito obrigado pela visita Trecenti,

    Obrigado pelos pontos, (bug fixed).

    Não sei se me expressei de forma errada ou dúbia, mas não critiquei o Windows e sei que ele tem muitas ferramentas boas. O fato é que crescemos usando o Windows, logo aprendemos desde cedo como operá-lo, o que não acontece com o Linux. Logo mudar para o Linux não quer dizer “queime seu windows e levante a bandeira nazi dos pinguins”, mas sim “saia do conforto e aprenda algo novo que pode te ajudar e muito no futuro”. Por isso eu falei que não existem contra-indicações. É algo que, muito provavelmente, você vai precisar usar ou aprender (cedo ou tarde).

    Sobre o jenkins, usei essa analogia pois na nossa comunidade temos dezenas de nomes para “testers” (não que eu concorde com todos eles), e um deles é o “testador”, que simplesmente segue um script elaborado por um analista. O trabalho é bem manual, e nesse caso o jenkins opera substituindo esse testador de uma forma bem mais eficiente.

    Obviamente, ponderei que o Jenkins em si não faz mágica, mas obrigado por enfatizar isso.

    Muito obrigado pela visita e pelo feedback.

  14. “Eu não fiz nenhuma pesquisa profunda, com formulários ou monografia, mas estou no mercado HÁ algum tempo e converso bastante com pessoas em foruns e listas!”

    Eu acrescentaria domínio do português e inglês (apesar de isso já ser uma regra), mas isso é fundamental pra um QA.

    Excelente post!

  15. Camilo, muito bom teu post. Eu sou fã de dicas passo-a-passo, especialmente quando se trata de orientar pessoas para o melhor caminho. Vc conseguiu sintetizar em um post com poucas palavras dicas importantes, coisas que normalmente levam horas pra explicar.

    Continua esse trabalho, cara! Tenho certeza que será um material de grande utilidade pública.

  16. Camilo, mais uma vez você mandou muito bem no seu posts, me sinto seguro no caminho que estou traçando para me tornar um QA Técnico graças a você. Só tenho a agradecer por tudo..

  17. Muito obrigado. O post é uma otima dica para os testers levarem novidades para suas empresas e clientes alem de valorizar o profissional no mercado.

  18. Ótimo post! Já faz um tempo que venho tentando me aprofundar na área técnica do teste de software e ajudou bastante a esclarecer alguns pontos. Porém, gostaria de sugerir a você Camilo, um post um pouco mais alto nível sobre as oportunidades que existem para esse perfil profissional e o que elas exigem. Vejo que as empresas “legais” tem investido muito tempo e dinheiro na contratação de “Software Engineers in Test”, ou programadores de testes. Isso me amedronta ou pouco pois sinto que estou ficando para trás no mercado. Às vezes eu penso que só experiência prática no dia-a-dia de trabalho pode ajudar-nos a desenvolver esse tipo de competência, uma vez que temos produtos e casos reais para exercitar. Porém, já tive oportunidade de participar de processos seletivos para esse tipo de perfil e não me aceitaram justamente por falta de experiência. Enfim, estou meio perdidão! Abs, e obrigado pelo belo trabalho!

Leave a Reply