Existir um colaborador em que faça os testes internos e que tenha a preocupação de verificar a qualidade do código através de execução e verificação do trace SQL para descobrir quebras de possíveis performance.
Os mais resistenstes vão dizer que isso deveria ser a preocupação de cada um, e que concordo em parte, mas ao longo do tempo verificamos que na realidade não é assim e mandamos “bastante” código mal feito.
Esta ideia poderá ser reajustada ao desenvolvimento do software de testes, embora o software de testes que vi na altura nunca irá verificar a qualidade do código.
Este colaborador, teria uma vantagem, uma vez que os testes passariam por ele, teria de perceber os processos muito mais rapidamente e era uma mais valia para futuros arranques uma vez que deveria estar dentro dos processos.
Função de “tester” e “optimizador”
4
One reply on “Função de “tester” e “optimizador””
O problema desta abordagem é que o EVE não é um software fechado. Sendo configurável cada processo poderá ter mil variantes espalhadas pelos clientes. Não é viável ter um sistema de testes que contenha todos os processos existentes em todos os clientes. Para isso ser possível o porduto teria que ser mais standard e sem tantos desenvolvimentos feitos para clientes mas integrados no standard.
Nem eu que sou fundador da empresa e passo grande parte do meu tempo a trabalhar no sistema como utilizador conheço todos os processos. Não estou a ver como viabilizar este tipo de testes. As software houses que têm uma equipa dedicada só a testes tem certamente tempos de disponibilização para o mercado muito mais longos. Para fazer isto teriamos que ter mais de 70% do código feito anualmente para os clientes em código local, tal como outras “casas” o fazem, fazendo uma separação muito clara entre o que é standard e o que é feito a pedido de clientes. Se retirassemos da aplicação tudo o que é feito a pedido dos clientes, têm ideia do que ficaria como código standard feito num ano?