Doing beta tests in Brazil

Seiiti Arata*

Investidores estrangeiros podem encontrar muitas informações para a realização de negócios no mercado brasileiro: inúmeros guias "Doing business in Brazil" foram e continuam sendo oferecidos por bancas de advogados, associações e câmaras de comércio. Porém, uma importante fase que precede o negócio final no mercado de TI não tem recebido suficiente atenção: o beta test.

Método de administração e marketing aplicável a diversos setores produtivos, em uma abordagem clássica o beta test é o teste de qualidade de um sistema que já passou pelo alpha test, que compreende testes de laboratório.

No caso da indústria de software, os beta testers procuram bugs de programação e dão sugestões gerais de aperfeiçoamento. Além de aperfeiçoamento técnico, o beta testing é uma interessante forma de divulgação, pois os beta testers se sentem parte do projeto e geralmente são estrategicamente escolhidos entre connaisseurs formadores de opinião.

Semelhante à indústria automobilística, as empresas de software possuem um grupo de produção que continuamente busca aperfeiçoar o produto e adaptá-lo às expectativas do mercado, seguindo e criando tendências.

Porém, o software não segue a estrutura de model year de automóveis. Como a programação é atividade contínua, na ausência de uma adequada coordenação de metas, pode ser caracterizado o "beta perpétuo": diversos modestos lançamentos sem nunca chegar ao primeiro release: a versão 1.0.

Com a chegada da Sociedade da Informação, o potencial para angariar beta testers é proporcional à base de usuários da internet. Esse fato, aliado a uma recente mudança de paradigma que hoje fala em projetos beta com duração de anos¹ , traz questionamentos jurídicos quanto à responsabilidade.

O antigo relacionamento intimista entre o desenvolvedor de produtos e seus beta testers deixava claro o papel desse último como parceiro, e não consumidor, justificando cláusulas contratuais de limitação de responsabilidade por defeitos do produto. No teste, não há responsabilidade quando o produto simplesmente não funciona, ou apresenta baixa eficiência. Por outro lado, danos decorrentes do teste implicam em responsabilidade que não pode ser afastada contratualmente no direito brasileiro.

No exemplo dos automóveis, uma montadora não é responsável perante os pilotos de teste quando o motor não dá partida, ou morre no meio do percurso. Porém, acidentes e danos decorrentes desse teste podem afastar as cláusulas de limitação de responsabilidade.

Entretanto, uma área cinzenta desperta agora atenção com a expansão do conceito clássico de beta testing, que sai do ambiente restrito e privilegiado do time de desenvolvimento: os serviços beta podem ser disponibilizados a todos os usuários da internet.

É como se o lançamento fosse feito oficialmente, mas com um disclaimer de que, por ser beta, não há garantia de suporte quanto à funcionalidade ou continuidade seja do produto como um todo ou de determinadas características ou funções.

Se por um lado essa tendência está em harmonia com as mais recentes e intrigantes teorias de descentralização, colaboração, emergência e inteligência coletiva, o "beta perpétuo" pode configurar um problema jurídico se caracterizado abuso na busca de imunização contra responsabilidade pelo produto ou serviço, considerando o consumidor como um eterno piloto de testes.

O novo beta test não se limita à caça de bugs mas inclui testes de projetos, gerenciando também o problema da demanda excessiva: determinados serviços somente podem ser liberados na internet na medida em que a empresa adquire maquinário suficiente para comportar o número de adesões. O sistema de convites para beta testing é também uma forma de controlar o crescimento do serviço.

Um contra-argumento deve ser colocado para os que pretendem dessas colocações desenvolver uma "teoria da desconsideração do beta status". Para usuários mais rigorosos, mesmo o release 1.0 é considerado um produto ainda de baixa qualidade, com defeitos a serem corrigidos em versões posteriores.

A popularização pode mudar o sentido original de certos termos. Alguns programadores ficam criticam o uso popular de "hacker" como sinônimo de criminoso tecnológico. Para eles, o termo correto é cracker, sendo que o sentido original de hacker vem de "hack", cortar caminho dentro de um sistema teoricamente hermético sem intenção maligna, mas sim testando as defesas de modo crítico.

Igualmente, certos puristas tecnológicos pedem um resgate do sentido original de beta, aquela fase anterior ao produto final. Teriam razão? A tendência é que cada vez mais a produção não fique limitada ao laboratório da empresa. As tecnologias de informação e comunicação atraem consumidores para a produção e os limites ficam incertos. Isso é válido mesmo em modelos produtivos do tipo "catedral", com alta hierarquia e centralização, que também incluem mecanismos para que os usuários de produtos finais enviem relatórios de erros para a empresa.

Apesar de criar a terminologia, os puristas não são os donos da evolução semântica. Não é necessário ler O Código Da Vinci para reconhecer que relação de signos e significados é dinâmica, e a mesma palavra tem diferentes sentidos conforme o público.

Para o jurista, não é selo de release ou beta que caracterizará o nível de responsabilidade. No direito brasileiro, limitações de responsabilidade em relações de consumo são freqüentemente nulas.

A análise de riscos deve se concentrar na eventual caracterização de relação de consumo. Caso o beta tester seja considerado um parceiro desenvolvedor, as limitações contratuais de responsabilidade terão maior respaldo. Caso o beta tester seja considerado um consumidor, os riscos oriundos de ações indenizatórias por danos sofridos devem ser assumidos no plano estratégico da empresa. Nesse último caso, a boa governança pede total divulgação aos seus acionistas desses riscos.

Esses conselhos valem não apenas a investidores estrangeiros, mas também aos brasileiros que participam da vanguarda de mudança de paradigmas, doing beta tests in Brazil.

__________________