A Evolução do “Tester” por Nuno Raposo da Noesis
Nos últimos anos, temos assistido no mercado da tecnologia a uma evolução da função do tester e do seu papel no ciclo de desenvolvimento de software.
Durante muitos anos e com as metodologias existentes na altura, os ciclos de desenvolvimento eram longos e testes eram enquadrados na fase final desses ciclos, com testes a todos os cenários possíveis. Qual tem sido a Evolução do software “Tester”?
O profissional de testes era visto como alguém que só estava a procurar defeitos e a criar bottlenecks, para a equipa de desenvolvimento, sendo, muitas vezes responsabilizado pelos atrasos no projeto. Este processo era lento, demorado, doloroso e pouco eficiente.
O objetivo é o mesmo, mitigar ao máximo a entrega de soluções com defeitos ao cliente final. Tão importante como garantir a entrega de novos desenvolvimentos num menor espaço de tempo, é também necessário assegurar a correção rápida de algo que tenha chegado ao cliente de forma incorreta.
Torna-se assim, cada vez mais, indispensável existência de especialistas em Quality Assurance (QA) com visão e experiência, capazes de avaliar a criticidade e a severidade da melhor forma e perceber o que realmente impacta a jornada do cliente final. Saber o que pode passar para produção, e ser corrigido rapidamente na próxima entrada, por exemplo. Muitas vezes é mais benéfico ter a nova versão em ambiente produtivo e corrigirmos esse defeito à posteriori - faz parte do processo e dos tempos atuais.
O próprio nome da função tem vindo a evoluir, naturalmente, de “Tester” para “QA”, retirando-se, até uma certa perceção negativa da função. Deixou de ser uma pessoa que “apenas encontra defeitos”, para alguém com uma visão da Qualidade, que consegue ajudar na evolução do produto e que evita que os defeitos cheguem ao ambiente produtivo.
O perfil do QA atual caracteriza-se por juntar vários skills de Engenharia, cuja capacidade principal é a de se conseguir adaptar às novas exigências do mercado. Esta é uma competência basilar numa área em que tudo está em constante mudança e rápida evolução (os ciclos de engenharia geralmente duram cinco anos e depois mudam e muda o mindset).
Para além da evolução natural de alguns hard skills requeridos no perfil de um QA, como alguns conhecimentos mais técnicos, a comunicação e a colaboração passaram a ser competências cada vez mais presentes. O grande objetivo é influenciar a qualidade ainda antes de o software ser desenvolvido.
O QA é alguém que tem que ter um conhecimento transversal do produto e cujo trabalho de comunicação é essencial junto dos diferentes stakeholders. Seja com a equipa de desenvolvimento, com o Product Owner / Scrum Master / Gestor de Projeto (dependendo das metodologias), com os Business Analysts ou com as equipas de Operações que suportam os produtos em Produção.
O mesmo se passa com a capacidade de aprender. Com tantas mudanças, o “fast learning” passa a ser também crucial - torna-se decisivo aprender rapidamente o negócio e a área onde nos encontramos. Há sempre alterações de prioridades de projetos e novas necessidades imediatas de mercado. Neste sentido, esta capacidade de adaptação passou a ser um fator-chave.
Tem sido uma evolução natural do perfil do QA e dos skills associados, sempre adaptados às novas realidades e contextos que vão surgindo.
O QA passou a ser um orquestrador na equipa e por isso a ser um perfil muito valorizado nas organizações - passou a ser uma função “sexy” nas equipas.
Este artigo tem mais de um ano
Boas Nuno Raposo.
Sem duvida que qualquer projecto deveria ser fortemente testado, o que por experiência própria sei que é a parte realmente inferior de qualquer projecto desenvolvido por tantas e tantas consultoras aqui em Portugal.
Uns simples testes unitários, são vistos como apenas “artefactos” que atrasam a entrega de soluções… Se bem que na realidade até concordo, não servem para nada os testes unitários, apenas pessoal de POO conseguia ver alguma utilidade naquilo.
Mas o meu ponto é o de que, testes consomem recursos que se traduzem em despesa que se traduzem em menos ganho por projecto, isto na perspectiva de tanta e tanta empresa que conheci.
Houve uma consultora, por sinal multinacional, em que até brincavam como assunto dizendo, ainda bem que tem erros, para se poder estender o contrato e fazer render mais ganhos.
Portanto, acho até normal quando se sabe que hackers afectam a empresa A, sabendo eu que muitas das vezes é por péssimo software, e pior, péssima configuração.
Mas como o texto já vai longo, tenho algo para si, o site da sua empresa, carece de QA.
https://www.noesis.pt/pt/join-us/Opportunities <— a caixa de input da pesquisa, não testei se valida/higieniza o mesmo input, mas a expressão regular que usam para procurar nas vossas ofertas, está errada.
Pronto, mande lá os tipos/as do QA da noesis de prestarem atenção a tudo o que seja input, principalmente tendo expressões regulares, é que foi facílimo perceber o erro.
Cumprimentos
Muito bom!
Noesis a ser Noesis…
O que é que os testes unitários tem a ver os “artefactos” ?
https://en.wikipedia.org/wiki/Artifact_(software_development)
Talvez uma forma de dizer irrelevante, já que muitos dos artefactos são de facto irrelevantes e consumidores de tempo.
O que entendes por “ter a ver”?
É uma relação causal?
É uma relação de pertencer a uma designação?
Um paço essencial entre o dev e prod e cada vez mais vaporizado.