6 min read

10 pontos essenciais para testes técnicos

10 pontos essenciais para testes técnicos

Teste técnico

Este artigo apresenta os principais pontos que podem afetar a qualidade dos testes técnicos.

1.  Linguagem

Hoje, as empresas que usam apenas uma linguagem estão extintas. Eu mesmo trabalho com uma variedade de linguagens com diferentes frequências de uso e contexto, incluindo JavaScript/TypeScript, Ruby, Python, Elixir, Lua e Scala/Java.

Desde de a era mainframe ūü¶Ė, onde COBOL, BASIC e CLIPPER escreviam arquivos e armazenavam em bancos de dados, podemos dizer que j√° trabalh√°vamos com duas linguagens, a stack era formada por SQL + alguma linguagem de programa√ß√£o.

Novos contextos e linguagens foram introduzidos e surgiram aplica√ß√Ķes desktop, web e mobile, aumentando a variedade de linguagens usadas.

Entretanto mesmo com essa variedade eramos reféns do servidores HTTP, havia perguntas como?

Como hospedar uma aplicação node no IIS? O apache suporta uma aplicação Rails?

Os servi√ßos de hospedagem ainda existem, e essas quest√Ķes ainda existem nesse contexto, mas gra√ßas aos containers e √† evolu√ß√£o de como os aplica√ß√Ķes s√£o hospedadas e mantidas, esses problemas se tornaram menos importantes e n√£o afetam mais as escolhas de linguagem de programa√ß√£o. Podemos dizer que os container impulsionaram essa variedade de linguagens.

De volta ao conte√ļdo, a escolha da linguagem define sua entrega. Algumas empresas exigem a entrega do teste t√©nico em uma stack espec√≠fica. J√° vesti essa capa algumas vezes e consegui entregar o teste, tive uma semana bem movimentada. Tenho um perfil generalista, e posso garantir que apenas a viv√™ncia com uma linguagem pode melhorar a produtividade e refinar sua entrega. A entrega foi feita, mas certamente poderia ter sido melhor em uma linguagem com qual tenho maior viv√™ncia.

Wearing a new cover

Não recomendaria usar uma linguagem apenas para causar uma boa impressão em uma entrevista. Se a linguagem não é um pré-requisito, recomendo escolher uma linguagem que faça você escrever um código de alto nível. Erros, quem nunca? Eles existem independentemente da linguagem, porém quanto maior o domínio da linguagem, menor o risco de erros conceituais.

2. Testes

Criar testes √© uma pr√°tica de longe obrigat√≥ria, quando voc√™ escreve seu c√≥digo e produz testes ao mesmo tempo sua produtividade aumenta e muito! Mas sei que como programador temos a tend√™ncia de sair escrevendo c√≥digo e depois testar, pela simples ansiedade de ver tudo funcionando, "quick and dirty" ūü§™. Independente da forma como voc√™ cria seus testes eles devem cobrir todas as unidades da sua aplica√ß√£o, todos os cen√°rios e se poss√≠vel todos os comportamentos.

Ufa! No meu contexto de desenvolvedor, os cart√Ķes perfurados n√£o ser√£o descartados quando o teste falha e muito menos pe√ßas ou mat√©ria prima. N√≥s, desenvolvedores, temos o privil√©gio de testar todas as coisas de forma virtualizada, mas √© inevit√°vel que alguns problemas ocorram em produ√ß√£o. At√© hoje n√£o encontrei nenhum ūüėá anjo programador, que escreva c√≥digos com zero problemas em produ√ß√£o, por√©m a experi√™ncia ajuda a mitigar problemas, o "fail fast", seja com feature flag, teste A/B ou rollback r√°pido.

3. Complexidade "over-engineering"

Sei que n√£o √© f√°cil identificar excessos arquitet√īnicos. Pois ca√≠mos em fal√°cias como: ¬†"Ficou verboso, por√©m muito coeso" ou "Vai facilitar futuras refatora√ß√Ķes". Ouvi uma frase que faz muito sentido:

Devemos evitar o reuso antes do uso

Produzir c√≥digos somente pensando no reuso voc√™ pode facilmente encontrar n√≠veis complexos, in√ļmeras interfaces de marca√ß√£o e m√≥dulos com uma √ļnica fun√ß√£o. Os sintomas tendem a piorar dependendo da mentalidade da equipe.

O tema excesso de abstra√ß√£o me faz lembrar de um momento da minha carreira em que utilizei um "framework" adquirido pela Empresa X para implementar um worker que lia uma fila. Este framework possu√≠a diversas classes e interfaces para implementa√ß√£o de workers que processam mensagens em filas, pois foram criadas v√°rias abstra√ß√Ķes para permitir a leitura de filas, arquivos, bancos de dados, ftp, etc... boa ideia! No entanto, a natureza imperativa do framework com abstra√ß√Ķes desnecess√°rias levou a um aumento consider√°vel no desenvolvimento de um worker que apenas l√™ filas, gra√ßas ao vi√©s "talvez eu precise ler uma pasta ou FTP algum dia".

Devemos sempre revisitar c√≥digos que escrevemos. As vezes olho para meus c√≥digos e penso: "Uau, por que voc√™ fez isso!" Resumindo, n√£o sobrecarregue seu c√≥digo com arquitetura e conceitos hypados. O c√≥digo escrito por programadores deve ser limpo e claro em todos os n√≠veis. O que est√° claro para voc√™ pode n√£o estar claro para sua equipe. Somente revis√Ķes de c√≥digo podem nos ajudar a encontrar esse equil√≠brio.

4. Padr√Ķes

Entre nós programadores, temos muitas sopas de letrinhas, (DDD, BDD, CQRS, SOLID, etc.). Gostaria de compartilhar uma experiência que tive, já avaliei testes onde as classes que utilizavam a nomenclatura DDD (aplicativo, repositório, domínio, etc.) não seguiam os princípio. Boom! Ficou claro que alguém estava tentando usar algo para impressionar e isso acontece com certa frequência.

Resumindo, ao escolher um modelo arquitet√īnico, certifique-se de seguir os princ√≠pios. Seu reposit√≥rio n√£o √© um controlador, seu servi√ßo n√£o √© um reposit√≥rio e assim por diante.

5. Execução

√Č importante que seus testes sejam executados sem problemas. Recentemente, tenho tido problemas com pacotes Ruby (gem) que n√£o funcionam devido a incompatibilidade entre os pacotes do sistema operacional. Os containers podem resolver esse tipo de problema de incompatibilidade com o sistema operacional e evitar o famoso "funciona na minha m√°quina". Entregar os testes usando containers podem facilitar a execu√ß√£o e avali√ß√£o do seu teste t√©cnico.

Escrevi alguns artigos sobre Docker, segue uma introdução.

Criando o seu primeiro Docker Container
Docker é uma plataforma de código aberto que permite aos desenvolvedores criar, publicar e executar facilmente aplicativos de forma isolada.

6. Documentação

O tema √© pol√™mico e o Manifesto √Āgil afirma sucintamente: "software em funcionamento mais que documenta√ß√£o", mas isso n√£o significa que a documenta√ß√£o deva ser abolida no seu projeto. N√£o queremos documenta√ß√Ķes padr√£o PMBOK, mas √© importante ter um README em nosso reposit√≥rio e um diagrama de neg√≥cios ou t√©cnico com explica√ß√Ķes na WIKI.

Existe algum programador que não goste daquela documentação básica para executar um projeto?

7. Requisitos incoerentes

Existem requisitos b√°sicos que devem ser assegurados por testes. Se for um teste algor√≠tmico, existe um valor de entrada "input" e um resultado "output". O requisito m√≠nimo √© garantir que o algoritmo forne√ßa os resultados esperados. J√° ouvi uma frase que se traduz bem o que deve ser feito. "Esta m√°quina, entra o porco ūüźĖ e sai a lingui√ßa ūüĆ≠".

Existem requisitos espec√≠ficos para framework, bibliotecas, banco de dados e at√© mesmo linguagens. Portanto, n√£o entregue em React, se requisito for Angular ou Vue, acredite j√° recebi um teste em Vue e foi solicitado React ūüėē.

Lembre-se, √© um requisito que voc√™ deve cumprir, mesmo que n√£o seja seu melhor amigo. √Č bom demonstrar apetid√Ķes no teste, mas n√£o se esque√ßa de manter seus requisitos em mente. Essa decora√ß√£o afeta o desempenho? Isso atrapalha a coes√£o? Adiciona mais complexidade? Pequenas decis√Ķes podem influenciam as decis√Ķes dos avaliadores.

8. Teste atualizado

Certifique-se de que os artefatos usados ‚Äč‚Äčem seus testes estejam atualizados corretamente. Hoje, as releases nascem a cada minuto e nem sempre conseguimos acompanhar. Pode ser que voc√™ use uma vers√£o que foi obsoleta meses ou dias atr√°s, ou um recurso de linguagem que n√£o √© considerado uma boa pr√°tica pela comunidade. Ao adicionar refer√™ncias a testes, verifique se o pacote est√° atualizado, quais s√£o as alternativas, quantas pessoas est√£o envolvidas e quem est√° por tr√°s do pacote.

9. Prazo

N√£o espere at√© o √ļltimo minuto para terminar o teste t√©cnico. Porque provavelmente voc√™ acabar√° criando algo de baixa qualidade que n√£o se encaixa na sua forma de trabalhar. E o mais importante √© cumprir a data de entrega acordada.

10. Perguntas! Esteja preparado

A preparação para uma entrevista de emprego é uma tarefa essencial, precisamos considerar todos os prós e contras da solução aplicada para não nos surpreender ou passar uma impressão errada do nosso trabalho.

Lembre-se de que as opini√Ķes dos testes s√£o isoladas e podem n√£o refletir seu modo de trabalhar. Muitas vezes as pessoas avaliam a entrega sem considerar alguns pontos.

  • N√≠vel de vaga (est√°gio, j√ļnior, pleno e s√™nior);
  • O tempo de experi√™ncia nos requisitos exigidos;
  • Prazo de entrega do teste;

Conclus√£o

Este √© um guia para ajud√°-lo a concluir seu teste t√©cnico. N√≥s, programadores, sabemos que os requisitos est√£o aumentando constantemente. Antes de enviar seu teste, use ferramentas √ļteis como formatadores, linters e verificadores que melhoram a qualidade do c√≥digo.

Mesmo depois de seguir essas e outras dicas e entregando o seu melhor. Você pode obter resultados negativos, mas não se preocupe, fique em paz. Não deixe que o "feedback" individual de um entrevistador dite sua carreira ou o desencoraje a continuar. Esteja preparado para muitos "nãos"!

Deus aben√ßoe seu kernel ūü߆!