A indústria de qualidade software está estagnada. Precisamos mudar isso!
Aqui vai um exercício de pensamento.
Imagine um mundo onde:
Em vez de você filtrar candidatos(as) por terem (ou não) a certificação CTFL, você os/as filtra por terem (ou não) projetos públicos no GitHub (ou GitLab, etc), os quais podem ser usados para demonstrar suas habilidades.
Ao usar uma certificação como filtro para eliminar candidatos(as) da participação no processo seletivo, você elimina a chance de empresas conhecerem possíveis excelentes profissionais.
Imagine uma QA que estudou a literatura recomendada para tal certificação, fez cursos a respeito do assunto, e na hora da prova, não passou. Digamos que a nota mínima para passar era 7.5 e a QA atingiu 7.4.
Agora, imagine um QA que estudou a mesma literatura, fez os mesmos cursos e passou na prova com a nota 7.6.
Você segue o processo seletivo com o QA que tirou 7.6 e elimina a QA que atingiu 7.4.
No entanto, na próxima fase do processo seletivo, você tem um exercício de codificação para analisar se tal QA sabe automatizar testes.
Tal QA não possui experiência prévia em codificação, pede ajuda pro ChatGPT, entrega algo que ele nem mesmo entende e submete seu exercício para análise.
Agora, alguém da empresa contratante tem que revisar tal código, que nem mesmo foi criado pela pessoa aplicando para a vaga, mas por uma IA Generativa. Neste caso, não seria melhor contratar o ChatGPT em vez desse QA? :D
Agora, imagine que você soubesse o seguinte sobre a QA que atingiu 7.4 na prova do CTFL, a qual não conseguiu a certificação.
Ela possuía vasta experiência prática em garantir a qualidade de diferentes softwares por meio de scripts de testes automatizados de alto-nível.
Quando digo alto-nível, me refiro a testes automatizados que, além de testarem as partes mais importantes do sistema, também:
- Usam as melhores práticas do mercado
- Seguem as convenções definidas pela comunidade
- São fáceis de manter, entender e extender
- São rápidos, robustos e confiáveis
Agora, imagine que seu filtro fosse diferente.
De agora em diante, seu filtro é: projetos públicos no GitHub (ou qualquer outro lugar onde seja possível compartilhar código publicamente).
Voltamos aos mesmos QAs.
O QA que tirou 7.6 na prova da CTFL nem mesmo tem um perfil no GitHub, no entanto, como "campo" perfil no GitHub é um pré-requisito para aplicação para a vaga, o QA cria uma conta na hora e coloca lá o link.
Ao abrir o link de perfil de tal QA, você não só consegue ver que ele acabou de criar a conta, como não possui nenhum projeto para demonstrar seu conhecimento de forma prática.
No entanto, a QA tem conta no GitHub desde 2012, tem diversos repositórios públicos, tem uma evolução de commits de ano em ano, e mais importante, tem um histórico de sua evolução, assim como diversos projetos que possam ser avaliados de antemão pelo possível contratante.
A partir daí, o processo poderia ser algo como o seguinte.
O QA, foi eliminado.
Já a QA, passou para a próxima fase.
Agora, uma pessoa sênior da empresa contratante seleciona 3 projetos públicos aleatórios na conta do GitHub dessa QA, de preferência de momentos distintos de sua carreira (para avaliar sua evolução) e analisa:
- Como ela codifica
- Quão abrangentes e efetivas são suas suítes testes
- Suas habilidades de escrita de documentações
- Etc.
Passando nesse filtro, ou seja, seguindo os padrões técnicos mínimos exigidos para a vaga, ela passa para a próxima fase, com uma entrevista comportamental/de fit cultural, e por fim, uma entrevista com alguém da gestão, para alinhamento de expectativas.
Pergunte-se agora.
"Qual dessas abordagens parece mais efetiva para seguir adiante (ou eliminar) o/a candidato(a)?"
Pense antes de responder!
Venho dizendo isso faz algum tempo, mas vou repetir.
A indústria de qualidade software está estagnada. Precisamos mudar isso!
E pra mudar isso, é preciso re-pensar processos que atrasam nossa indústria.
Você já parou para pensar em quanto dinheiro empresas que emitem certificações (e empresa que treinam pessoas para passarem em tais certificações) ganham?
Agora, imagine uma pessoa que estudou para a certificação, passaria com 10, mas decidiu não gastar o dinheiro com tal certificação.
O conhecimento que ela adquiriu você não tira dela, independente se ela tem (ou não) a certificação.
Ou seja, a certificação não prova nada.
No entanto, a experiência prática, seja através cursos práticos, contribuições com projetos open-source, hackathons, bootcamps, etc, isso pode ser avaliado (tanto tecnicamente, como subjetivamente).
Nos dias de hoje, automação de testes é o mínimo esperado de profissionais de QA.
Fazer trabalho que pode ser automatizado de forma manual é simplesmente um desperdício.
No entanto, não adianta fazer testes de qualquer jeito.
Não adianta escrever scripts de testes que passam na primeira vez, mas com o passar do tempo, se mostram frágeis e não-confiáveis.
Não adianta escrever testes que quando falham, não tem nada errado com a aplicação sendo testada.
Além disso, não adiante escrever os testes errados, ou seja, testes que apesar de existirem, deixam bugs importantes passarem.
A tecnologia está toda à nossa disposição.
Lembre-se! Escrever scritps de testes é codificar, e se exigimos que times de desenvolvimento escrevam códigos de alta qualidade, por qual motivo não exigimos o mesmo de times de QA?
Contratamos QAs para encontrarem bugs nas aplicações sendo construídas, mas quem encontra os "bugs" nos scripts de testes escritos por esses/essas QAs?
Tá na hora de subir a régua!
Esse papo de "basta conhecer o básico de programação para começar a automatizar" não pode mais ser aceito.
É simplesmente contraditório contratar pessoas para garantirem a qualidade dos softwares sendo construídos se elas nem mesmo sabem o básico de como softwares são construídos.
E se você não concorda com o que está lendo, fico feliz que ao menos chegou até aqui. Se não quiser, não precisa mais ler.
Já se você concorda com essas idéias, continua comigo.
Ao conhecer com profundidade uma linguagem de programação; ou uma ferramenta; ou um framework de automação de testes, você saberá como fazer bom uso destes para garantir a qualidade dos softwares sendo construídos. Você saberá escrever testes com um bom design.
Você vai focar na simplicidade em vez da complexidade.
Você vai focar na legibilidade do código em vez de somente no princípio DRY (Don't Repeat Yourself).
Você vai focar nas abstrações extremamente necessárias, em vez de abstrações superficiais.
Você vai se preocupar em testes desacoplados de detalhes de implementação da aplicação em teste.
Você vai se preocupar em escrever testes rápidos, efetivos e que gerem confiança nos times. Testes que quando estão verdes (passando), a nova versão pode ir pra produção. E que quando estão vermelhos (falhando), é por que uma problema real foi encontrado, a tempo de correção, antes de chegar no usuário final.
Quer aprender como chegar nesse próximo nível?
Te convido a começar com os cursos de automação de testes da Escola Talking About Testing.
Depois, venha participar da Assinatura Talking About Testing e apromirar seus conhecimentos, com conteúdos exclusivos e mentoria em grupo junto com o Walmyr.
Ou então, venha fazer uma mentoria individual, focada em suas necessidades específicas.
Gostou desse conteúdo? Me diga o que achou nos comentários.
👋
Top comments (0)