O teste unitário é adequado para o desenvolvimento de BPM?

Question

Atualmente estou trabalhando em um grande projeto de BPM que usa o conjunto de ferramentas Global 360 BPM chamado Process 360.Apenas para dar algumas informações básicas;este produto funciona como muitas outras soluções de BPM, pois você projeta vários "mapas de processos" que definem o fluxo de um processo de negócios específico que você está tentando modelar, e cada mapa de processos consiste em vários nós de tarefas conectados entre si que executam funções específicas (chamando serviços da web, etc.).

Atualmente estamos enfrentando alguns problemas bastante sérios durante as fases de controle de qualidade de nossos lançamentos porque não há nenhuma maneira fornecida pelo conjunto de ferramentas para automatizar os testes das rotas do mapa de processos.Portanto, quando um processo grande e complexo é desenvolvido e entregue à nossa equipe de testes, muitas vezes surge um grande número de problemas.Embora obviamente você esperaria alguns problemas decorrentes do controle de qualidade, não posso evitar a sensação de que muitos bugs, etc., poderiam ter sido detectados durante o desenvolvimento se tivéssemos algum tipo de estrutura de teste automatizado que pudéssemos usar para construir um conjunto de testes de unidade que provaram as diversas rotas no(s) mapa(s) de processo.

No momento, o único teste de desenvolvimento real que ocorre é mais parecido com o teste funcional realizado pelos desenvolvedores, que é documentado como um conjunto de etapas manuais por caso de teste.O problema com essa abordagem é que ela consome muito tempo para os desenvolvedores executá-la manualmente e, por causa disso, também é relativamente propensa a erros.Também;como geralmente temos um cronograma bastante apertado, os testes muitas vezes não são executados com frequência suficiente para detectar problemas antecipadamente.

Como mencionei anteriormente;não há uma maneira fornecida pelo conjunto de ferramentas atual para realizar esse tipo de teste automatizado.O que realmente me fez pensar por quê?Sendo muito novo em todo o cenário BPM, minha suposição era que esse era apenas um recurso que faltava no produto, mas também me pergunto se o "teste unitário" simplesmente não é feito tradicionalmente no mundo BPM.Talvez simplesmente não seja adequado para esse tipo de trabalho?

Eu estaria interessado em saber se alguém já encontrou esse tipo de problema e também o que - se houver - pode ser feito para melhorar as coisas.

Answer 1

Fiz testes "unitários" com o K2.net 2003, outro BPM comercial.Eu realmente chamaria isso de teste de integração, porque requer um servidor de teste e é relativamente lento.No entanto, é automatizado.

Há uma boa discussão sobre isso no livro Pérola negra profissional K2 (também se aplica ao K2.net 2003).

Para aplicá-lo em sua plataforma, o conjunto de ferramentas deve possuir uma API que permita iniciar instâncias de processos, obter itens de trabalho, concluir itens de trabalho, etc.Você escreve testes usando qualquer linguagem suportada (usei C#) e uma estrutura de teste (usei NUnit).Se a API suportar chamadas síncronas, isso será mais fácil de fazer.Para cada teste:

1. Inicie o processo em teste
2. Progredir o item de trabalho até um ponto de decisão
3. Defina os dados da instância de processo adequadamente
4. Conclua o item de trabalho
5. Afirme que o item de trabalho está agora na atividade esperada
6. Excluir ou concluir a instância do processo

Classes de teste básicas ou métodos auxiliares podem tornar isso mais fácil.Você poderia até escrever um DSL para testar mapas.

Essencialmente, você deseja uma "cobertura de teste" completa do processo/mapa - teste cada ponto de decisão e garanta que a ramificação correta seja tomada.

Answer 2

Eu vi algo sobre isso, embora não relacionado ao Global 360: usando bpelunit para processos de teste

Eu desenvolvo uma ferramenta de fluxo de trabalho e há uma demanda crescente para abrir as ferramentas de teste usadas para testar o mecanismo para os usuários finais.

Answer 3

Existem dois aspectos do BPM que estão relacionados, mas não são idênticos.

Existe o BPM que os fornecedores de ferramentas e tecnologia defendem e que tem tudo a ver com recursos.

Há também o BPM que os arquitetos corporativos defendem, que tem tudo a ver com o estabelecimento de Centros de Excelência.

O primeiro é onde uma empresa compra algum software.

Este último é onde uma empresa faz mudanças sistémicas e inerentes ao comportamento dos seus trabalhadores de TI.

Supõe-se que o primeiro esteja a serviço do segundo, mas não é necessariamente assim.Adquirir o primeiro é necessário, mas não suficiente para alcançar o segundo.

Não sei até que ponto o Global 360 suporta o que é conhecido como Test Driven Development, mas o JBoss jBPM fornece alguns suporte de ferramenta para escrever facilmente testes JUnit.

No entanto, a ferramenta não pode e não forçará os desenvolvedores a escrevê-los ou a adotar os princípios do TDD.