Chegámos aos dois últimos artigos da série Liderança nos Testes. Até agora, abordámos como planear e gerir um projeto de testes do início ao fim, bem como muitas das ferramentas e dos processos envolvidos.
Neste artigo, quero abordar a Garantia dos Processos Empresariais (EBPA) — o que é e como a implementar. Iremos abordar:
- O que é a Garantia dos Processos Empresariais?
- Compreender a integração e os testes de sistemas
- Testes horizontais: a abordagem de testes E2E
- Riscos de integração e testes E2E
Há muito para abordar, por isso, vamos começar.
O que é a Garantia dos Processos Empresariais?
Todas as organizações que implementam novos sistemas já tiveram problemas ao utilizá-los pela primeira vez. Os sistemas que não correspondem, ainda que ligeiramente, à infraestrutura e aos processos empresariais existentes podem causar o caos e ser difíceis de reparar.
As práticas iterativas, ágeis e mais colaborativas ajudam, mas os desafios da integração em toda a empresa só podem ser resolvidos através de uma fase final de testes.
Chamamos a esta fase final Garantia dos Processos Empresariais (EBPA). O sucesso depende de uma ou mais fases de testes que demonstrem que os sistemas, os processos empresariais e os dados estão integrados e disponibilizam os serviços prometidos.
Existem poucos artigos académicos sobre este tema, apesar de as fases finais de todos os projetos de grande escala serem dominadas por esta atividade. Para definir a nossa estratégia de EBPA, iremos primeiro analisar mais atentamente os tipos de integração e testes de sistemas com que terá de lidar.
Nos projetos de nível empresarial, a complexidade aumenta exponencialmente. É por isso que escolher um software de gestão de bases de dados de nível empresarial pode transformar os seus esforços de engenharia da qualidade.
Compreender a integração e os testes de sistemas
Integração vertical
De uma perspetiva técnica, a integração representa a ligação entre as várias camadas da arquitetura técnica. Para os programadores, os testes de integração consistem sobretudo em verificar se os dados aceites através da interface do utilizador numa transação de atualização são armazenados corretamente na base de dados.
No sentido inverso, os dados armazenados são verificados para garantir que podem ser apresentados corretamente na interface do utilizador quando solicitados. As ligações e os caminhos através da arquitetura técnica podem ser vistos como caminhos verticais ou testes de integração vertical.
Integração horizontal
Os utilizadores finais não veem a arquitetura técnica nem toda a sua complexidade. Veem o sistema como uma série de funcionalidades, utilizadas por diferentes utilizadores naquilo a que poderemos chamar uma jornada do utilizador.
Estas jornadas percorrem caminhos nos processos empresariais dos utilizadores e acedem a diferentes sistemas e funcionalidades em cada etapa do percurso, através da interface do utilizador.
As equipas ágeis trabalham em histórias de menor escala e não veem o épico mais abrangente. Normalmente, os programadores não conseguem acompanhar nem testar jornadas de utilizador mais longas, porque não dispõem dos ambientes ou dos dados necessários. Por isso, as organizações dependem geralmente de testes de maior escala e de equipas de testadores para os validar.
Os percursos do utilizador abrangem naturalmente o processo empresarial e as funcionalidades do sistema em conjunto. Desta forma, os testes horizontais exercitam a integração entre os sistemas e o processo empresarial.
Os testes de integração vertical adotam uma perspetiva mais técnica; os testes horizontais adotam uma perspetiva do utilizador ou do processo empresarial.
Utilizemos agora estes conceitos para construir um modelo que nos ajudará a compreender e planear a EBPA. Faremos referência às abordagens de integração horizontal e vertical no modelo.
Have an account? Log In
Um modelo para a integração e os testes
A integração é um conceito frequentemente mal compreendido. O processo de integração começa, na realidade, quase assim que a codificação é iniciada. Poder-se-ia dizer que a integração começa quando temos duas linhas de código — a segunda linha de código tem de ser integrada com a primeira. A integração termina quando todos os testes funcionais terminam na aceitação pelo utilizador.
Vamos concentrar-nos num exemplo que utiliza módulos comerciais prontos a utilizar (COTS) e módulos de planeamento de recursos empresariais (ERP).
A empresa de software que cria módulos COTS ou ERP realizou testes unitários e funcionais. Quando estes componentes chegam, pode normalmente assumir-se que funcionam e que se integram tecnicamente. No entanto, existe sempre o risco de os componentes integrados de diferentes fornecedores interagirem de formas imprevistas.
Além disso, se os componentes forem personalizados, o seu comportamento irá alterar-se e, mais uma vez, é provável que isto provoque efeitos secundários subtis (e outros nem tão subtis) noutros pontos. Continua a ser necessário realizar uma integração vertical para verificar a troca de controlo e de dados na pilha tecnológica, bem como uma integração horizontal entre os componentes e o processo empresarial.
Representamos as quatro atividades de integração num modelo de quatro quadrantes com dois eixos. No eixo X, temos a escala do sistema em teste — um único componente ou subsistema isolado, ou os sistemas integrados no contexto do processo empresarial.
O lado direito do modelo está sombreado a azul e representa a EBPA. Testar o nosso sistema no contexto de outros sistemas (SIT) e do processo empresarial (BIT) é aquilo a que chamamos Garantia do Processo Empresarial da Empresa.
Vejamos os quatro quadrantes por ordem.
Testes de módulos, funcionalidades ou componentes
O módulo tem de ser testado funcionalmente, quer tenha sido desenvolvido à medida, quer seja um componente COTS. A experiência do utilizador é sempre importante e tem de se integrar com algum passo ou atividade do processo empresarial.
Testes de integração de subsistemas
A integração é incremental. À medida que os componentes e as funcionalidades de baixo nível ficam disponíveis, são integrados no sistema, cada vez maior, e testados até que o sistema completo e coerente esteja pronto. Chamamos a isto testes de integração de subsistemas.
Testes de integração de sistemas (SIT)
Nenhum sistema existe isoladamente, pelo que, quando o nosso sistema estiver concluído, precisamos de o integrar com outros sistemas. Instalamos o nosso sistema num ambiente com os sistemas com os quais faz interface e testamos esses sistemas a funcionar como um “sistema de sistemas” através dessas interfaces. O nosso objetivo nesta fase é abordar os riscos técnicos da integração, e chamamos a isto testes de integração de sistemas.
Testes de integração empresarial (BIT)
Existe uma fase final de integração que visa garantir que os sistemas construídos se integram nos processos empresariais e nos procedimentos (frequentemente manuais) dos utilizadores desses sistemas. Incluindo as interfaces externas do sistema (caso ainda não tenham sido testadas), validamos que os sistemas e os processos empresariais, ao trabalharem em colaboração, proporcionam percursos do utilizador coerentes e eficientes, e que gerem e transferem os dados de forma correta e consistente. Normalmente, chamamos a isto testes de integração empresarial.
Durante o restante artigo, iremos concentrar-nos bastante no lado horizontal do modelo, a EBPA.
Leitura relacionada: AS 10 MELHORES FERRAMENTAS DE GESTÃO DE DADOS DE TESTE
Testes horizontais: a abordagem de testes E2E
A integração horizontal depende sobretudo do que é frequentemente designado por testes de ponta a ponta (E2E).
Os testes E2E são uma técnica de conceção de testes que invoca uma série de transações interligadas, normalmente abrangendo vários sistemas, incluindo o(s) nosso(s) sistema(s) em teste. Estes testes tendem a seguir os percursos dos utilizadores ao longo dos seus processos empresariais.
Dado um modelo de um processo empresarial, são traçados percursos através do processo para criar uma série útil de transações que simula a forma como os utilizadores utilizarão o sistema em produção.
Estes modelos podem ser diagramas familiares, como fluxogramas ou diagramas de raias, ou podem ser representações mais técnicas, como diagramas de sequência ou de colaboração UML. (UML é a Linguagem de Modelação Unificada utilizada por muitas organizações de TI).
Os testes E2E abordam riscos específicos que não podem ser facilmente tratados por testes anteriores em subsistemas ou ambientes que dependem fortemente de interfaces simuladas e de dados puramente sintéticos.
No âmbito dos testes horizontais, a abordagem de testes E2E é frequentemente complementada por software especializado. Para consultar uma lista selecionada de software que pode simplificar este processo, veja estas soluções de gestão de testes mais bem avaliadas
Aceitação
A noção de «adequação» é apropriada para a integração componente-componente, a integração sistema-sistema e a integração sistemas-processos empresariais.
A aceitação baseia-se normalmente nos resultados de testes E2E horizontais, porque as partes interessadas do negócio podem confiar que estes testes mostram de que forma o novo sistema se adequa e apoia as suas formas de trabalhar. Os testes E2E horizontais dão-lhes confiança de que o serviço disponibilizado funcionará.
O processo de aceitação dos sistemas depende normalmente, pelo menos em parte, da realização bem-sucedida de testes E2E horizontais. Isto deve-se ao facto de apenas os testes E2E exercitarem o sistema num ambiente realista e simularem uma atividade de utilizador realista.
Em muitas organizações, só é possível demonstrar, nas fases finais dos testes, que os sistemas funcionam, o que dá às partes interessadas confiança de que o sistema funcionará conforme necessário.
Se lhe for pedido que planeie um teste de aceitação, esperamos que a técnica de teste E2E desempenhe um papel importante no seu planeamento.
Riscos de integração e testes E2E
Como referido, os riscos de integração estão relacionados com a integração sistema-sistema ou com a integração sistema-processo empresarial.
Algumas organizações optam por dividir os testes que abordam estes dois tipos de risco em Testes de Integração de Sistemas (SIT) e Testes de Integração Empresarial (BIT). No entanto, frequentemente os riscos e os testes são combinados numa única fase de testes denominada E2E, Aceitação ou Testes Empresariais.
Independentemente da forma como os testes são estruturados, estes recorrem amplamente à abordagem de teste E2E explicada acima. No seu ambiente, os riscos que enfrenta podem ser variações destes temas e poderá ter de ajustar o objetivo do teste e a sua abordagem de teste em conformidade.
A lista de riscos apresentada aqui deve ser considerada apenas um ponto de partida e um lembrete dos aspetos nos quais deverá concentrar os seus testes. É provável que existam riscos específicos da sua organização, setor ou tecnologia que terá de acrescentar a esta lista inicial.
Na tabela abaixo, «sistemas» refere-se ao conjunto de sistemas integrados que compõem o novo sistema ou sistemas em desenvolvimento, outros sistemas antigos ou de infraestrutura e sistemas externos, por exemplo, bancos ou organizações parceiras.
| Risco | Objetivo do teste | Abordagem de teste |
| Os sistemas não estão integrados (transferência de dados). | Demonstrar que os sistemas estão integrados e realizam corretamente a transferência de dados. | Teste de Integração de Sistemas (SIT) |
| Os sistemas não estão integrados (transferência de controlo). | Demonstrar que os sistemas estão integrados (a transferência de controlo com os parâmetros necessários é realizada corretamente). | SIT |
| As interfaces falham quando são utilizadas durante um período prolongado. | Demonstrar que as interfaces podem ser utilizadas continuamente durante um período prolongado. | SIT (Estas verificações também podem ser realizadas como parte dos Testes de Fiabilidade e/ou de Comutação por Falha) |
| Os sistemas não estão integrados (os dados não são reconciliados entre interfaces). | Demonstrar que os sistemas estão integrados (os dados transferidos através da interface são utilizados de forma consistente, por exemplo, moeda, idioma, métricas, tempos, precisão e tolerâncias). | SIT |
| Os sistemas não estão sincronizados (as transferências de dados não são acionadas, são acionadas no momento errado ou várias vezes). | Demonstrar que as transferências de dados são acionadas corretamente. | SIT |
| Os objetos ou entidades existentes em vários sistemas não são reconciliados entre os sistemas. | Demonstrar que os estados dos objetos empresariais são representados com precisão nos sistemas que contêm dados sobre esses objetos. | Teste de Integração Empresarial (BIT) |
| Os sistemas não estão integrados com o processo empresarial (cadeia de abastecimento). | Demonstrar que os sistemas se integram com os processos empresariais e suportam o processo da cadeia de abastecimento. | BIT |
| Os processos empresariais de back-end não suportam os front-ends Web ou móveis. | Demonstrar que os processos da cadeia de abastecimento são viáveis e suportam o objetivo empresarial. | BIT |
| Os sistemas integrados utilizados pelo mesmo pessoal têm interfaces de utilizador ou comportamentos inconsistentes para tarefas semelhantes ou relacionadas. | Demonstrar que os utilizadores têm uma experiência consistente entre sistemas ao realizar tarefas semelhantes ou relacionadas. | BIT (Estas verificações também podem ser realizadas durante a verificação da UX) |
Notas sobre a tabela de riscos
Alguns dos riscos acima precisam de uma explicação adicional.
Problemas de transferência de dados
Frequentemente, os dados são transferidos entre sistemas através de redes. Se estas transferências forem executadas como processos em lote e falharem, ou falharem enquanto transferência em tempo real acionada por um utilizador, uma atividade empresarial ou um evento de outro sistema, faltarão dados no sistema de destino.
Transferência de controlo incorreta
Uma transferência de controlo ocorre quando uma atividade do utilizador ou um processo do sistema transfere o utilizador ou o processo para outra funcionalidade do sistema.
Normalmente, existe uma escolha da funcionalidade de destino e, dependendo da ação do utilizador ou do conteúdo dos dados de uma transação, é escolhido um percurso diferente através da aplicação.
Do ponto de vista do utilizador, este é encaminhado para o local errado na aplicação ou um processo do sistema tenta executar o processo errado e perde a sincronização.
Os dados não são reconciliados
Um sistema pode distribuir dados relativos, por exemplo, a dinheiro, à localização de ativos ou a alguma quantidade física que tenha de «totalizar» em todos os sistemas.
Por exemplo, quando são adquiridos e movimentados 100 artigos de inventário, vendidos, utilizados em processos de fabrico, considerados defeituosos e devolvidos ou eliminados, o número de artigos existentes em cada subsistema deve corresponder à contagem original de 100.
Uma variação deste problema é, por exemplo, as unidades utilizadas nos sistemas que armazenam dados. Os tamanhos dos lotes ou as agregações dos elementos contabilizados têm de ser tidos em conta, ou os sistemas têm de fazer corresponder as medidas métricas e imperiais, entre outros aspetos.
Sistemas não sincronizados
Relacionado com o problema de transferência de dados acima referido, os processos dos sistemas que efetuam transferências são agendados para serem executados na sequência correta, acionados por processos ou pessoas devidamente autorizados, e são iniciados atempadamente e pelo evento apropriado ou por uma combinação de eventos.
Alguns processos em lote têm de ser executados de hora a hora, diariamente, semanalmente, no final do mês, do trimestre ou do ano, entre outros períodos, e precisam de ser verificados. Grande parte do comportamento funcional depende da sincronização relativa das transações ou da antiguidade dos dados entre sistemas, pelo que também é necessário verificar estes aspetos.
Os objetos não correspondem
Em vez de contagens de objetos, dinheiro ou medições físicas, estes riscos estão relacionados com o estado dos objetos armazenados em sistemas distribuídos. Por exemplo, o estado de um funcionário num registo de pessoal deve ser consistente entre os sistemas que armazenam cópias desse objeto de dados. Os processos que distribuem alterações de estado entre os sistemas que armazenam cópias do mesmo objeto têm de ser acionados e as suas ações verificadas.
Sistemas não integrados com o negócio
O comportamento dos sistemas deve estar sincronizado com as intenções dos utilizadores. Os problemas típicos ocorrem quando o sistema apresenta informações incompletas, desatualizadas ou incorretas. A causa subjacente é o facto de as transferências ou sincronizações de dados não funcionarem corretamente, mas estes problemas manifestam-se através da interface do utilizador.
More Articles
Os processos de retaguarda não suportam a interface
Este tipo de problema manifesta-se como uma inconsistência entre os sistemas de registo e os sistemas de interação. Os processos em lote de retaguarda que não são executados com a frequência necessária, ou que não são executados de todo, não disponibilizam dados aos sistemas de interação da interface. Do mesmo modo, as transações dos utilizadores através dos sistemas de interação não são refletidas nos sistemas de registo.
Interfaces de utilizador inconsistentes
Quando uma empresa ou serviço é disponibilizado através de interfaces móveis, Web e baseadas em quiosques, a interface do utilizador comporta-se de forma diferente ou inconsistente. Todas podem ter sido testadas de forma independente, mas o seu comportamento é diferente. Por exemplo, são aplicadas regras de validação de dados diferentes, são capturados ou apresentados campos de dados diferentes, ou a sequência de introdução de dados é diferente.
Considerações finais
Apresentámos um modelo de integração e testes que dá destaque à integração em toda a empresa e ao processo empresarial. A abordagem E2E é a única que exige uma integração completa do sistema e baseia os testes em percursos completos dos utilizadores. Desta forma, as partes interessadas podem ver evidências de que os sistemas funcionam corretamente num contexto realista.
Muitas organizações dependem dos utilizadores para aplicarem uma forma de testes E2E nos seus testes de aceitação e para executarem esses testes manualmente. Com base na experiência, defendo uma abordagem mais sistemática e baseada no risco, que facilita a automatização de grande parte da execução de testes, que exige muito trabalho.
À medida que as organizações adotam abordagens de desenvolvimento ágil e de entrega contínua mais dinâmicas, atribuindo às equipas ágeis mais responsabilidade pelos testes dos seus subsistemas, é fácil negligenciar as fases posteriores de integração e testes de aceitação em toda a empresa.
A abordagem EBPA, especialmente quando automatizada, alarga o regime de integração contínua dos subsistemas à garantia dos processos empresariais em toda a organização.
Os pacotes COTS e ERP permitem implementar sistemas extremamente capazes, mas complexos, com menos esforço de desenvolvimento, mas os riscos de integração são tão relevantes como nos desenvolvimentos de software personalizado.
Em ambientes de maior dimensão, as abordagens ágeis e de entrega contínua são cada vez mais populares; por isso, à medida que a complexidade e a escala aumentam, aumentam também a frequência de entrega e o risco associado.
A solução é clara: as organizações têm de levar a EBPA a sério. Precisam de compreender os riscos de integração e a forma de estruturar os testes para os abordar. Os responsáveis pelos testes têm de avançar para a abordagem moderna baseada em modelos, abstrair os seus processos empresariais, sistemas e testes, e implementar a automatização de testes de forma sistemática.
Subscreva o boletim informativo The QA Lead para receber uma notificação quando forem publicados novos artigos da série. Estas publicações são excertos do curso Liderança em Testes de Paul, que recomendamos vivamente para aprofundar este e outros tópicos. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de $60 no preço total do curso!
Leitura sugerida: 10 MELHORES FERRAMENTAS DE GESTÃO DE TESTES DE CÓDIGO ABERTO
