Atualizado em agosto 28, 2019
O teste tem sido amplamente adotado como parte do desenvolvimento de software, desde que o software foi desenvolvido. Business Intelligence (BI), no entanto, tem demorado a adotar o teste como uma parte integrada do desenvolvimento de software de BI, como o IBM Cognos. Vamos explorar por que o BI tem demorado mais para adotar práticas de teste e as consequências de NÃO teste.
Por que as organizações não testam BI ...
- Limitações de tempo. Os projetos de BI estão sob constante pressão para serem entregues com mais rapidez. O que algumas organizações podem não perceber é que a fase mais fácil para reduzir o tempo é o teste.
- Restrições de orçamento. O pensamento é que o teste é muito caro e não pode dedicar uma equipe de teste.
- Mais rápido é melhor. Esta não é necessariamente uma abordagem “ágil” e pode apenas levá-lo ao lugar errado mais rápido.
- A mentalidade de "fazer certo da primeira vez". Essa abordagem ingênua insiste que a presença de controle de qualidade deve reduzir a necessidade de testes.
- Falta de propriedade. Isso é semelhante ao marcador anterior. O pensamento é que “nossos usuários irão testá-lo”. Essa abordagem pode levar a usuários insatisfeitos e muitos tíquetes de suporte.
- Falta de ferramentas. O equívoco de que eles não têm a tecnologia certa para teste.
- Falta de compreensão dos testes. Por exemplo,
- O teste deve avaliar a precisão e validade dos dados, consistência dos dados, oportunidade dos dados, desempenho da entrega e facilidade de uso do mecanismo de entrega.
- O teste durante um projeto de BI pode incluir teste de regressão, teste de unidade, teste de fumaça, teste de integração, teste de aceitação do usuário, teste ad hoc, teste de estresse / escalabilidade, teste de desempenho do sistema.
Quais são os custos de NÃO testar o BI?
- Projetos ineficientes. Uma arquitetura ruim pode não ser descoberta se o teste for ignorado. Problemas de design podem contribuir para a usabilidade, desempenho, reutilização, bem como manutenção e conservação.
- Problemas de integridade de dados. A corrupção de dados ou os desafios da linhagem de dados podem levar à falta de confiança nos números.
- Problemas de validação de dados. As decisões tomadas com base em dados incorretos podem ser devastadoras para os negócios. Não há nada pior do que tentar gerenciar por métricas baseadas em informações incorretas.
- Diminuição da adoção do usuário. Se os números não estiverem certos ou se o aplicativo não for amigável, sua comunidade de usuários simplesmente não usará seu novíssimo software de BI corporativo.
- Aumento de custos devido à falta de padronização.
- Aumento dos custos para reparar defeitos em estágios posteriores do ciclo de vida de desenvolvimento de BI. Quaisquer problemas descobertos além da fase de requisitos custarão exponencialmente mais do que se descobertos anteriormente.
Agora que explicamos por que as organizações podem não estar testando e as armadilhas que ocorrem quando você não testa o BI, vamos dar uma olhada em alguns estudos sobre teste no desenvolvimento de software.
Estudos mostram que testar sua plataforma de BI economiza dinheiro!
Um estudo de 139 empresas norte-americanas variando em tamanho de 250 a 10,000 funcionários, relatou custos de depuração anuais de US $ 5.2 milhões a US $ 22 milhões. Esta faixa de custo reflete organizações que não possuem testes de unidade automatizados. Separadamente, pesquisas da IBM e da Microsoft descobriram que de teste de unidade automatizado no local, o número de defeitos pode ser reduzido entre 62% e 91%. Isso significa que os dólares gastos na depuração podem ser reduzidos da faixa de $ 5 milhões - $ 22 milhões para a faixa de $ 0.5 milhões a $ 8.4 milhões. Isso é uma grande economia!
Os custos para corrigir erros aumentam rapidamente.
Um artigo sobre táticas de desenvolvimento de software de sucesso demonstra que a maioria dos erros são cometidos no início do ciclo de desenvolvimento e que quanto mais você espera para detectar e corrigir, maior será o custo para corrigi-los. Portanto, não é preciso ser um cientista espacial para chegar à conclusão óbvia de que quanto mais cedo os erros forem descobertos e corrigidos, melhor. Falando em ciência de foguetes, acontece que a NASA publicou um artigo exatamente sobre isso - “Escalada de custo de erro ao longo do ciclo de vida do projeto.”
É intuitivo que os custos para corrigir erros aumentem à medida que o ciclo de vida do desenvolvimento avança. O estudo da NASA foi realizado para determinar a rapidez com que avança o custo relativo de corrigir os erros descobertos. Este estudo usou três abordagens para determinar os custos relativos: o método de custo ascendente, o método de decomposição do custo total e o método de projeto hipotético descendente. As abordagens e resultados descritos neste artigo presumem o desenvolvimento de um sistema de hardware / software com características de projeto semelhantes às usadas no desenvolvimento de uma grande e complexa espaçonave, uma aeronave militar ou um pequeno satélite de comunicações. Os resultados mostram o grau em que os custos aumentam, conforme os erros são descobertos e corrigidos em fases posteriores e posteriores do ciclo de vida do projeto. Este estudo é representativo de outras pesquisas realizadas.
No gráfico acima, pesquisas da TRW, IBM, GTE, Bell Labs, TDC e outros mostram o custo de corrigir erros durante as diferentes fases de desenvolvimento:
- O custo de corrigir um erro descoberto durante a fase de requisitos é definido como Unidade 1
- O custo para corrigir esse erro, se encontrado durante a fase de design, é duplo que
- Na fase de código e depuração, o custo para corrigir o erro é unidades 3
- Na fase de teste de unidade e integração, o custo para corrigir o erro torna-se 5
- Na fase de teste de sistemas, o custo para corrigir o erro salta para 20
- E uma vez que o sistema está na fase de operação, o custo relativo para corrigir o erro aumentou para 98, quase 100 vezes o custo de corrigir o erro se encontrado na fase de requisitos!
O resultado final é que é muito mais caro reparar defeitos se eles não forem detectados logo no início.
Conclusões
Foi realizada uma pesquisa significativa que demonstra o valor dos testes iniciais e contínuos no desenvolvimento de software. Nós, na comunidade de BI, podemos aprender com nossos amigos no desenvolvimento de software. Embora a maioria das pesquisas formais tenha sido feita relacionada ao desenvolvimento de software, conclusões semelhantes podem ser tiradas sobre o desenvolvimento de BI. O valor do teste é indiscutível, mas muitas organizações têm demorado para tirar proveito dos testes formais de seu ambiente de BI e integrar os testes em seus processos de desenvolvimento de BI. Os custos de não os testes são reais. Os riscos associados a não os testes são reais.
Quer ver alguns testes automatizados do Cognos em ação? Assista aos vídeos em nossa lista de reprodução por clicando aqui!
