← Voltar ao blog

O teste vale pelo que elimina

A prova pericial em litígio de sistema raramente demonstra a causa de forma direta: ela elimina alternativas até restar o verificável.

O teste vale pelo que elimina

Litígios sobre implantação de sistemas corporativos têm uma estrutura argumentativa previsível. De um lado, a contratante afirma que o produto não funcionou. De outro, a fornecedora responde que o ambiente era inadequado, a parametrização foi alterada pelo cliente ou o uso excedeu o previsto. As duas narrativas costumam ser apresentadas sem qualquer elemento que permita ao juízo decidir entre elas. É nesse vácuo que a prova pericial precisa operar — e ela opera melhor eliminando hipóteses do que tentando demonstrar a causa diretamente.

Um ambiente corporativo integrado é uma cadeia. Há o produto de software, com seus defeitos próprios; a parametrização, definida durante a implantação; a infraestrutura, dimensionada segundo especificações; o serviço de sustentação, contratado para responder a incidentes; e a conduta dos usuários. Uma falha observada — lentidão, indisponibilidade, resultado incorreto — pode originar-se de qualquer desses planos, e frequentemente de mais de um simultaneamente.

Registre-se de saída uma distinção que o processo costuma apagar: lentidão não é indisponibilidade. São frentes com causas, evidências e consequências distintas. Degradação de desempenho é um sistema que responde mal; indisponibilidade é um sistema que não responde. Tratá-las como um bloco impede qualquer individualização de causa e produz laudos que concluem tudo e demonstram nada.

O método de exclusão consiste em produzir condições em que algumas hipóteses se tornam logicamente insustentáveis. No episódio examinado, o procedimento foi executado em etapas, cada uma removendo uma variável. Desativou-se o componente de integração — se a causa fosse a integração, a utilização cairia; não caiu. Desativou-se o processo automático — mesma lógica, mesmo resultado. Desconectaram-se todos os usuários e todas as aplicações — e a utilização de processador permaneceu em cem por cento.

O resultado é uma condição rara e valiosa: saturação sob demanda funcional nula. Ela não diz qual é a causa. Diz, com segurança lógica, quais causas não são. Volume de acessos exige acessos. Conduta de usuário exige usuário. Credencial compartilhada exige sessão ativa. Nenhuma dessas condições estava presente.

Dois atributos tornam esse elemento particularmente robusto no processo. O primeiro é a reprodutibilidade: o procedimento pode ser repetido em diligência, com as partes presentes, e conferido pelo juízo. Prova que se repete é prova que se examina. O segundo é a origem: a constatação está registrada em documento produzido pela parte contrária, no curso normal do projeto. Isso a torna independente de corroboração e dificilmente impugnável como relato unilateral — e aponta um princípio de método que vale para qualquer litígio de tecnologia: dar primazia às fontes produzidas pela outra parte, quando existirem.

O limite precisa ser enunciado com o mesmo rigor. O teste exclui; não conclui. Não demonstra a causa remanescente, apenas reduz o campo. Não autoriza estender a conclusão aos demais episódios da série — generalizar de um evento para uma sequência é tratar correlação como causa, e é exatamente a crítica que se costuma dirigir ao laudo adversário. E não define responsabilidade contratual: individualizar a causa técnica é um passo; a imputação é juízo jurídico, apoiado no que o contrato atribuiu a cada parte.

Para o advogado que sustenta a inadequação do produto, o caminho é pedir o registro dos testes de isolamento, se houver, e requerer a sua realização, se não houver. Um quesito bem formulado descreve o que se quer: a sequência de exclusões executada, a condição de carga em cada etapa, a fonte da métrica de utilização e o instante de cada medição. Para quem defende o fornecedor, o mesmo raciocínio funciona na direção oposta — se a causa é de fato o ambiente, o teste sob carga controlada tende a demonstrá-lo. Para o juízo, a vantagem é de verificabilidade: uma conclusão obtida por exclusão pode ser conferida, o que raramente ocorre com conclusões obtidas por impressão técnica.

Perícia de sistemas não costuma produzir a revelação da causa. Produz, quando bem conduzida, a redução disciplinada do campo do possível, com registro do que foi eliminado e de como. É menos espetacular e muito mais sólido. A pergunta que o advogado deveria fazer antes de discutir o mérito da falha não é "o que causou o problema?", mas "o que já sabemos que não o causou — e com base em qual teste?".

7 min de leitura
← Voltar ao blog Ir para a página inicial