O International Software Testing Qualifications Board fornece uma excelente definição preliminar de qualidade: “O grau em que um produto de trabalho satisfaz as necessidades declaradas e implícitas dos seus intervenientes.” No entanto, apesar de todas as suas virtudes, esta definição ainda requer mais esclarecimentos para compreender plenamente todas as suas ramificações comerciais. É aqui que a noção de valor se torna útil.
O Valor é Subjectivo
Aprendemos com a praxeologia que os indivíduos decidem o que querem ou precisam (fins) e como esperam atingir esses objectivos (meios). Por outras palavras, tanto os “fins” como os “meios” são decididos subjectivamente, o que significa que são escolhidos por seres humanos individuais que têm diferentes origens, necessidades, desejos e preferências.
Desde a revolução marginal do século XIX, todos os economistas sérios concordam que o “valor” dos bens e serviços é subjetivo. Jesús Huerta de Soto explica na sua obra introdutória “The Austrian School: Market Order and Entrepreneurial Creativity”, que, em termos correctos, o “valor” corresponde à forma como o indivíduo que age avalia os seus fins, ao passo que a “utilidade” diz respeito ao grau em que os meios satisfazem os seus fins, mais uma vez de acordo com juízos individuais.
A Qualidade É Utilidade Subjectiva
Tendo em conta este quadro teórico, podemos afirmar com segurança que a qualidade é uma noção subjectiva. As partes interessadas escolhem um produto em vez de outro com a expectativa de que ficarão em melhor situação se escolherem esse produto alternativo. A escolha não é, no entanto, um mero “capricho” porque, em última análise, cada peça de software deve satisfazer uma necessidade comercial efectiva. No entanto, verifica-se que existem várias formas de satisfazer as mesmas necessidades com bens e serviços diferentes, tal como a sede pode ser saciada com água ou refrigerante, e é aqui que entram em jogo as preferências e os desejos individuais.
Uma vez que o desenvolvimento de software é um empreendimento muito humano, não pode escapar à lógica da acção humana. Mais precisamente, a análise económica da qualidade do software não pode evitar tocar na actividade das pessoas envolvidas na criação do software. Como tal, as partes interessadas seguem o axioma da acção: os indivíduos adoptam um comportamento intencional quando conseguem imaginar uma situação futura melhor do que a actual e fazem as suas escolhas em conformidade. É evidente, portanto, que a qualidade está intimamente relacionada com a noção microeconómica de utilidade, uma vez que está relacionada com os meios. Como sabemos pela teoria da utilidade marginal, esta existe em graus: há produtos que nos ajudam a atingir os nossos objectivos melhor do que outros, porque simplesmente preferimos umas coisas a outras (ou “Utilidade Ordinal”)
Neste cenário, encontramos uma camada extra de complexidade que já está a ser tratada pela nossa definição inicial: “necessidades declaradas e implícitas dos stakeholders”.
“Declaradas” significa basicamente o que o cliente diz que precisa, seguindo a sua imagem mental do produto ou a expectativa de como ele será. Embora estes julgamentos possam ocasionalmente ser imprecisos, ficar aquém ou exceder o que realmente necessitam, as declarações resultantes informam a própria base dos requisitos do sistema que servirão de documentação de referência para os programadores e testadores ao longo de todo o ciclo de vida do desenvolvimento de software.
Por outro lado, “implícitas” é o que deriva natural ou logicamente das necessidades declaradas, o que significa que há algumas necessidades que ainda não foram descobertas.
Aspecto Empresarial dos Testes
Os engenheiros de qualidade (QA), também designados por “testers”, são aquilo a que Israel Kirzner chama “empreendedores”, embora num sentido impróprio. O empreendedorismo, na sua opinião, é a descoberta criativa das necessidades e desejos humanos e a sua satisfação através de bens e serviços.
Pode parecer estranho à primeira vista que eu esteja a aplicar este conceito a um campo tão estranho como o dos testes de software. Afinal, são os empresários que fazem avançar a economia. São eles que coordenam os processos de produção, em vez de simplesmente participarem nesses processos, como os engenheiros de qualidade quase sempre fazem. No entanto, da mesma forma que os empresários, os engenheiros de qualidade descobrem informações implícitas que nunca foram explicitamente declaradas pelo cliente nem pela equipa de desenvolvimento, uma vez que estes engenheiros se envolvem num processo criativo de descoberta.
Como disse o proeminente especialista em qualidade James Bach, os testes são “inerentemente exploratórios”. Os engenheiros de QA descobrem conhecimento tácito que não é dito, não é escrito e não pode ser formalizado, e é também por isso que os testes não podem ser totalmente automatizados, uma vez que se relacionam com um know-how prático e não com um know-how científico. Para além dos testes unitários e dos testes da interface do utilizador, os engenheiros de qualidade concentram-se principalmente nos testes de integração, que é outra forma de dizer testes de transmissão de dados. Os engenheiros certificam-se de que existe uma troca de dados correcta entre componentes e sistemas e, por conseguinte, desempenham um papel de coordenação crucial.
Não se esqueça de que todos os sistemas de software são, no fundo, sistemas de informação. Estes sistemas tratam da forma como as pessoas relevantes obtêm a informação de que necessitam nos momentos certos. No entanto, não se pode simplesmente reduzir as aplicações de software a um procedimento matemático – em que a entrada é processada para devolver uma saída – como se os únicos pontos relevantes de análise e crítica fossem as entradas e as saídas. Pelo contrário, descobrem-se muitas informações sobre o próprio processo, uma vez que os testadores criam novas informações através da descoberta de defeitos anteriormente desconhecidos (bugs), fornecendo informações úteis sobre o estado do sistema e melhorando a comunicação entre os sistemas.
Testes, Qualidade dos Dados e Conhecimento
Os conjuntos de dados são informação e a informação interpretada é conhecimento. O “problema do conhecimento”, tal como foi definido por Friedrich Hayek na sua obra seminal “The Use of Knowledge in Society”, indica que o principal problema económico não é simplesmente a melhor forma de utilizar a informação já disponível (como diz a economia neoclássica), mas sim a forma de obter a informação relevante para o processo de tomada de decisão. Nas palavras do próprio Hayek: “É um problema de utilização do conhecimento que não é dado a ninguém na sua totalidade.”
Mesmo que ninguém numa empresa saiba tudo sobre ela, continuam a ser necessários dados abrangentes, porque nenhuma empresa pode ser bem-sucedida com maus dados, e o software existe precisamente para colmatar essa lacuna. As empresas bem-sucedidas são aquelas que se destacam na previsão do futuro, e a qualidade dos dados é essencial para atingir este objectivo. Aqui, obviamente, a ciência e a análise de dados modernas têm um enorme papel a desempenhar, informando as previsões empresariais qualitativas com dados quantitativos reais, mas históricos. Ao mesmo tempo, a actividade do cientista de dados é limitada pela própria qualidade dos dados. Como diz o ditado, “lixo dentro, lixo fora”.
De certa forma, toda a garantia de qualidade sempre foi – em parte, se não totalmente – garantia de qualidade dos dados. Como os sistemas de software existem para resolver um problema de informação empresarial, a garantia da qualidade consiste principalmente em assegurar que os dados são criados, actualizados, acedidos, armazenados, transmitidos e eliminados de forma correcta e segura. É certo que também estão envolvidos aspectos não funcionais – como o desempenho ou a segurança – mas o objectivo principal é sempre a qualidade da informação, e tudo o resto gira à sua volta.
Dado que a qualidade do software é a utilidade que as partes interessadas obtêm do produto de software, uma vez que este resolve as suas necessidades de informação explícitas ou implícitas, a função dos engenheiros de qualidade é garantir a qualidade do produto, mas não a definir – ao fim do dia, isso é deixado para o cliente e o mercado decidirem.
Artigo publicado originalmente no Mises Institute.
