Uma exposição de arte me fez pensar sobre duas formas diferentes de excelência profissional: dominar muito bem a técnica e desenvolver um olhar capaz de perceber aquilo que não é óbvio. No Software Testing, precisamos das duas.
No último domingo, 6 de setembro, fui a uma exposição de arte visual aqui em Amsterdam. Havia fotografias, pinturas e trabalhos com estilos bastante diferentes, o que naturalmente acabou gerando algumas conversas sobre técnica, interpretação, intenção e sobre o que faz uma determinada obra chamar nossa atenção.
Em uma dessas conversas, compartilhei uma maneira pela qual costumo observar artistas. Não se trata de separar artistas bons de ruins, nem de dizer que existe uma forma superior de produzir arte. O que percebo são duas razões diferentes pelas quais uma obra pode me impressionar.
Existem artistas que chamam minha atenção principalmente pela criatividade. São aqueles que parecem enxergar algo que outras pessoas não enxergaram, encontram uma perspectiva inesperada ou transformam uma ideia aparentemente simples em alguma coisa surpreendente. Às vezes, nem é a execução técnica da obra que mais impressiona. É a pergunta que fica: como alguém pensou nisso?
Por outro lado, existem artistas cuja principal força está no domínio da execução. Talvez o tema não seja particularmente original e talvez a obra represente algo que já vimos muitas vezes. Ainda assim, há precisão, domínio do material, composição, acabamento, consistência e enorme cuidado na apresentação. Nesse caso, minha reação costuma ser diferente: como alguém conseguiu fazer isso tão bem?
As duas coisas têm valor. E, enquanto conversava sobre isso na exposição, percebi que faço uma distinção muito parecida quando observo profissionais de Quality Assurance e Software Testing.
Dominar a técnica de QA é uma competência real
Existem profissionais de QA tecnicamente muito bons. Eles conhecem técnicas de teste, sabem estruturar uma estratégia, compreendem níveis e tipos de teste, trabalham bem com APIs, bancos de dados, logs, ferramentas, automação e pipelines. Sabem documentar, reportar defeitos com clareza, manter rastreabilidade e participar adequadamente das diversas etapas do ciclo de desenvolvimento.
Quando recebem um problema relativamente bem definido, sabem abordá-lo de maneira profissional. Há método, disciplina e consistência no trabalho. Assim como no artista extremamente competente tecnicamente, existe um domínio claro do craft.
Às vezes, porém, cometemos o erro de considerar que esse domínio técnico é sinônimo de saber testar. Não é exatamente a mesma coisa.
Conhecer técnicas de projeto de testes é importante. Saber automação é importante. Conhecer ferramentas, processos, padrões e práticas também é importante. Mas Software Testing envolve algo adicional: a capacidade de olhar para um sistema e formular perguntas que talvez ainda não tenham sido formuladas.
É aí que aparece um segundo tipo de profissional.
Algumas pessoas parecem enxergar o software de maneira diferente
Quem trabalha há algum tempo com testes provavelmente já encontrou alguém assim. O time está discutindo uma funcionalidade aparentemente simples, todos parecem compreender o que precisa ser feito e, de repente, essa pessoa pergunta: “E se acontecer isso?”
Por alguns segundos, ninguém responde. Não porque a pergunta seja extraordinariamente complexa, mas porque ninguém havia considerado aquela possibilidade.
Esse tipo de profissional percebe contradições entre requisitos, combina regras que estavam sendo analisadas isoladamente, altera a ordem das operações, abandona um fluxo no meio, repete ações, mistura estados ou utiliza dados que aparentemente não fariam sentido naquele contexto. Muitas vezes também percebe problemas menos objetivos: uma interface funciona conforme a especificação, mas alguma coisa naquela experiência simplesmente não parece correta.
Há uma curiosidade bastante característica nesse comportamento. Em vez de utilizar o software apenas da forma como ele deveria ser utilizado, o tester começa a investigar como ele poderia ser utilizado, mal utilizado, interpretado ou combinado de maneiras que o processo formal não previu.
Essa habilidade costuma ser chamada, em diferentes contextos, de test thinking. Ela envolve pensamento crítico, formulação de hipóteses, sensibilidade a riscos, reconhecimento de padrões, compreensão de comportamento humano e, sobretudo, disposição para questionar aquilo que aparentemente já está resolvido.
Foi exatamente aí que a comparação com arte começou a fazer mais sentido para mim.
Na exposição, uma determinada cena estava disponível para qualquer pessoa observar. Ainda assim, apenas um artista decidiu registrá-la daquela maneira específica. O objeto estava diante de todos; o que mudava era o olhar.
No Software Testing ocorre algo semelhante. Requisitos, interfaces e regras de negócio podem estar disponíveis para todo o time. Product, Development, Business e QA podem ter acesso praticamente às mesmas informações. Mesmo assim, alguém consegue encontrar uma pergunta que muda completamente a discussão.
Isso não significa que testar seja um “dom”
Existe uma armadilha nessa analogia. É fácil concluir que algumas pessoas simplesmente “nascem para testar” e outras não. Não acho que essa seja uma visão particularmente útil.
Algumas características individuais ajudam muito. Curiosidade, atenção a detalhes, pensamento analítico, capacidade de comunicação e certa dose de ceticismo são naturalmente favoráveis ao trabalho de testing. Mas uma grande parte desse olhar pode ser desenvolvida.
Experiência aumenta nossa capacidade de reconhecer padrões. Exploratory Testing melhora nossa capacidade de investigar. Heurísticas ampliam o repertório de perguntas. Conhecimento de negócio melhora nossa percepção de risco. Trabalhar com bons testers nos expõe a maneiras diferentes de pensar. Analisar falhas que aconteceram no passado nos ajuda a imaginar falhas que podem acontecer no futuro.
Até mesmo conversar com usuários modifica profundamente a maneira como testamos, porque começamos a perceber que aquilo que consideramos tecnicamente lógico nem sempre corresponde à maneira como uma pessoa real compreende o produto.
Portanto, pode existir uma predisposição maior em algumas pessoas, assim como em qualquer atividade criativa ou analítica. Mas test thinking também é uma competência que pode ser treinada.
Técnica sem curiosidade e curiosidade sem técnica
O mais interessante é perceber que nenhuma dessas duas dimensões é suficiente isoladamente.
Um tester extremamente criativo, mas com pouco domínio técnico, pode encontrar problemas interessantes e ainda assim ter dificuldade para organizar sua investigação, priorizar riscos, comunicar suas descobertas ou transformar aquilo em informação útil para o restante do time. Pode depender demais da intuição e ter dificuldade para construir uma abordagem reproduzível.
No outro extremo, um profissional tecnicamente impecável pode executar exatamente aquilo que foi especificado sem nunca questionar se a especificação fazia sentido. Pode automatizar centenas de cenários, produzir documentação excelente, ter alta cobertura e deixar todos os pipelines verdes. Ainda assim, pode deixar passar justamente aquilo que ninguém havia pensado em transformar em teste.
É nesse ponto que a analogia com os dois artistas se completa. Um pode surpreender pela ideia; outro, pela execução. Em QA, também podemos encontrar profissionais que se destacam pelo rigor técnico e profissionais que se destacam pela capacidade investigativa.
Os melhores, porém, tendem a combinar os dois.
A IA torna essa diferença ainda mais relevante
Essa discussão também ganha uma dimensão nova quando pensamos em inteligência artificial.
Hoje, agentes de IA já conseguem apoiar uma parcela significativa das atividades tradicionalmente associadas ao trabalho técnico de QA. Eles podem analisar requisitos, identificar lacunas, sugerir critérios de aceite, gerar cenários, criar casos de teste, produzir dados, escrever automação, executar verificações e analisar resultados.
Isso significa que algumas atividades que antes consumiam bastante tempo humano estão se tornando cada vez mais assistidas ou automatizáveis.
Não vejo isso como uma redução da importância do profissional de QA. Vejo como uma mudança no local em que esse profissional pode gerar mais valor.
Se uma ferramenta consegue gerar vinte cenários razoáveis para uma user story em alguns segundos, o diferencial humano não está em competir para ver quem escreve vinte e cinco. O diferencial está em avaliar se esses cenários representam os riscos importantes, identificar o que ficou de fora e, principalmente, perceber se a própria user story descreve o problema correto.
Um agente pode gerar combinações com enorme eficiência. Mas talvez exista uma combinação que se torne relevante apenas depois que alguém utiliza o produto, observa um comportamento inesperado e formula uma nova hipótese.
É por isso que continuo vendo tanto valor em Exploratory Testing, UX, análise de fluxos alternativos, edge cases, border cases e na investigação de comportamentos não previstos. Não porque a IA seja incapaz de contribuir nessas atividades, mas porque elas dependem fortemente de contexto, interpretação e da capacidade de aprender durante a própria exploração.
Os melhores profissionais combinam craft e insight
Saí da exposição pensando que talvez essa comparação seja menos sobre dois tipos diferentes de profissionais e mais sobre duas dimensões da excelência.
Uma delas é o craft: técnica, disciplina, repertório, método, consistência e qualidade de execução.
A outra é o insight: curiosidade, sensibilidade, criatividade, interpretação, questionamento e capacidade de perceber algo que ainda não estava explícito.
É possível construir uma carreira sólida sendo muito forte em uma dessas dimensões. Mas os profissionais que mais me impressionam em Software Testing normalmente conseguem aproximar as duas.
Eles dominam técnicas, mas não são prisioneiros delas. Sabem criar casos de teste, mas não confundem um conjunto de casos com toda a realidade possível do produto. Utilizam automação, mas entendem que uma verificação automatizada responde apenas à pergunta que alguém conseguiu formular. Conhecem processos e padrões, mas também sabem quando é preciso abandonar o roteiro e investigar.
Talvez seja exatamente essa combinação que diferencie alguém que apenas sabe executar atividades de QA de alguém que desenvolveu verdadeiramente um olhar de tester.
Na arte, algumas obras nos impressionam pelo domínio da execução. Outras nos fazem admirar a perspectiva de quem as criou. As melhores conseguem reunir os dois.
No Software Testing, acredito que acontece algo muito parecido: excelência está tanto em saber como testar quanto em perceber o que ainda precisa ser questionado.
Comentários
Postar um comentário