Digo pregar pois que muitas vezes repete-se a cartilha tantas vezes às equipas de desenvolvimento que tenho a sensação de que fui até ao novo mundo levar a boa nova.
Os responsáveis dos projectos, pressionados pelas prestações fracas das equipas de desenvolvimento na matéria, pela hierarquia e outros factores externos ao projecto, dirigem-se a mim e pedem para eu aplicar “”aquela coisa da usabilidade””.
A resposta a este pedido deveria ser a pergunta: “”Quer que embrulhe?”
Pois a usabilidade não se vende aos bocadinhos, não se embrulha para desenbrulhar apenas quando queremos, não serve para oferecer às partes ou repartir, e mesmo que assim fosse todos os bocadinhos juntos não fariam um total, mas apenas um conjunto de bocadinhos.
Geralmente quando os testes são solicitados já é muito tarde no processo de desenvolvimento.
A intrevenção tardia provoca então o aparecimento de tarefas de correção que acrescem nos custos de desenvolvimento.
A resposta rápida do fornecedor a este tipo de correcções é que os requisitos ou as funcionalidades foram alterados, havendo assim lugar a alteração do orçamento, o que como consequência provoca a decisão do responsável do projecto em não efectuar as ditas alterações.
Então em que ficamos?
Cada projecto de tecnologias de informação deverá definir explicitamente que tarefas e em quanto tempo é pretendido que a aplicação facilite. Estes requisitos permitiram a exigência inicial dos respectivos testes, dado que a análise funcional deverá permitir dar resposta a essas exigências.
Então como podemos ajudar os Analistas que desenvolvem a análise funcional?
Muitas questões que se pretendem resolver foram antes resolvidas por outros de forma pioneira e normalizadas para poderem ser aplicadas em massa sem a necessidade de testar toda e qualquer funcionalidade.
A produção de um caderno de normas graficas, elaborado coerentemente e testado junto dos utilizadores, que especifique e normalize os desenvolvimentos dos interfaces poderá facilitar em muito a relação e aceitação dos utilizadores.
Mas muitas equipas de desenvolvimento, habituadas que estão a desenvolver sem quererem fazer recurso à normalização, pretendendo com isso produzir algo novo, esquecem-se que esta normalização permite que esforços de pesquisa sejam atribuidos a tarefas que resolverão problemas expecificos da aplicação.
Será responsabilidade dos técnicos ou dos gestores de projecto? De ambos. O gestor de projecto se acredita que tudo o que os seus colaboradores estão a efectuar é completamente novo apenas demonstra a sua ingenuidade, por outro lado o técnico que julga que pode re-inventar a roda só demonstra a sua mediocridade.
Em português currente, até parece que estou a tentar puxar a brasa à minha sardinha dado que estando os desenvolvimentos normalizados, haverão menos variáveis para controlar durante os testes de usabilidade e os testes funcionais.
Os argumentos para não testar as aplicações, em qualquer das suas vertentes, e desculpem-me a analogia mediocre, é igual ao dos construtores automóveis para não testarem as suas viaturas em cenários de desastre.
Mas há algo de errado com esta analogia, uma vez que os testes com viaturas estão lá para assegurar a vida do condutor e seus acompanhante, mas leiam atentamente os Acordos de utilização ou End User License Agreement de certos sistemas operativos e programas antes de os usarem num sistema electrónico de controlo fabril ou de suporte à vida.