Princípios para testes em SOA - Parte 1

No primeiro post sobre testes SOA coloquei que o principal problema para testar serviços de negócio é tratá-los como componente de software e não componentes de negócio. Não tenho nada contra testes unitários, pelo contrário, acho que são parte do processo de desenvolvimento, mas não podem ser a única forma de testes.

Ainda assim, os serviços de negócio trazem novos desafios para os testes, sejam de caixa-preta, cinza ou branca, eles exigem estratégias diferentes pois estão integrados, quanto maior a granularidade, mais complexa é essa integração e devem servir a muitos. Em um próximo post discutiremos uma das estratégias para minimizar esse acoplamento e permitir evoluir nos testes de serviços de granularidade grossa (composições e orquestrações).

Mas como disse no começo, o problema dos testes é mais de atitude do que técnico, sendo assim, seguir alguns princípios enquanto planejamos os testes pode ser útil. São eles:

1. Os consumidores não podem pagar pelos testes;
Esse acredito ser o princípio mais importante e o que mais é ignorado. O consumidor, seja ele quem for (principio 2), não pode arcar com todos os custos do teste do serviço consumido, seria como ao entrar em uma agência de carros e escolher um modelo econômico (grana curta, salvar o planeta, por esses motivos) e o vendedor lhe informasse que você é o primeiro a usar esse carro e por isso terá um custo adicional (seja em dinheiro, no preço do seguro ou na sua segurança). O que você diria ao vendedor? E a essa marca de carros?
Pois bem, freqüentemente os usuários dos serviços tem que responder a essa pergunta com um amargo "Tá bom" e ver seus cronogramas e custos esticarem.
Serviço é um ativo da empresa, independente de quem o descubra, o custo deveria ser rateado por todos, embora o prazo não possa ser feito da mesma forma, quem for o primeiro arcará com o custo de esperar, essa é a parte que ele terá que pagar.
Lembre-se do principio 1 quando estiver fazendo um cronograma, negociando orçamento adicional com as áreas ou justificando um atraso e principalmente calcule o tempo que você precisará para fazer cenários de testes, levantar massas de dados e corrigir os problemas do serviço antes de colocá-lo na vitrine da empresa.

2. Um serviço de negócio deve ser testado de forma agnóstica;
Pode parecer bobagem, mas vejo com freqüência serviços de negócio que funcionam especificamente para uma unica aplicação. Não vou me alongar nesse tema, você pode ler "SOA: Princípios de Design de Serviços" do Thomas Erl e entender em detalhes o que estou dizendo, mas o importante é, quando estiver escrevendo seus testes, você deve observar esse princípio e não incluir ou aceitar particularidades de um determinado sistemas, usuário ou situação.

3. O serviço de negócio é uma interface não-gráfica para os seus usuários;
Quando escrever testes para um serviço de negócio considere as questões do ponto de vista do consumidor, o "como chegar" na interface do serviço é muito importante, sendo assim verifique que ferramentas você está utilizando, se elas atendem todos os requisitos para acionamento do serviço (WS-*).

4. Testar um serviço de negócio deve ser barato;
O custo do teste é exponencial, e as vezes tende ao infinito, um serviço com cinco parâmetros simples, sendo qualquer um dele com domínio infinito (exemplo números inteiros) já eleva o número de casos de testes possíveis ao infinito.
A seleção criteriosa dos dados é fundamental, mas minimizar o número de testes também, porque isso economiza tempo, dinheiro e caras amarradas.
Outro ponto é a automação, uma vez que eu escrevo o caso de teste, executá-lo deveria custar algo em torno de nada.
Bem, unindo as duas coisas, precisamos de ferramentas que nos auxiliem a selecionar os dados e excluí-los estatisticamente, de obter uma boa cobertura que pode ser monitorada automaticamente, executar várias vezes os mesmos casos de testes de forma automatizada.
Perseguir a eficiência e a eficácia nos testes não é apenas uma questão de fazer bem é também uma excelente oportunidade de negócio.
Vou dedicar um post ao tema de seleção de dados e automação de testes, após finalizar os testes de laboratório de algumas ferramentas e métodos, nesse meio tempo, mandem links de ferramentas, metodologias, processos que você conhecem .

5. Desenvolvedores não são bons testando fora do seu domínio;
Os desenvolvedores não são muito bons para escrever casos de testes abrangentes com boa cobertura dos requisitos de negócio, por isso, não considere-os como recurso de testes nos cronogramas. Testar é uma ciência que exige dedicação, estudo, conhecimento e experimentação nesta área de conhecimento.

Testar software sempre será um grande desafio, quanto maiores eles se tornam, mais seu comportamento pode ser explicado pelas áreas de conhecimento dos sistemas complexos, sendo que garantir a qualidade destes sistemas exigirá cada vez mais pessoas qualificadas, redes sociais e o aproveitamento de todos os recursos disponíveis, sempre mantendo uma boa relação de custos x benefícios.

Talvez falte para área de qualidade de software um PMBOK, SWEBOK, CMBOK, um SQBOK (Software Quality Body of Knowledge), embora este tema seja um capítulo no SWEBOK. Pelos custos envolvidos, pela importância e abrangência que os softwares tem em nossas vidas, os testes, como parte do processo de qualidade de software, tem um papel fundamental e social, merecendo a atenção e o esforço de toda a comunidade.

Como sempre: Concorde, discorde, comente, corrija, ajude a ampliar nosso conhecimento.