Como alcançar a colaboração como principal direcionador de testes contínuos

Um novo aumento no protecionismo

Neste ano, no Fórum Econômico Mundial em Davos, Suíça, o tema central foi um novo aumento do protecionismo e suas consequências negativas para a economia mundial. Angela Merkel, chanceler federal da Alemanha, emitiu um aviso; uma especificação clara do mais importante pré-requisito para a prosperidade e o crescimento em um mundo globalmente conectado e cada vez mais rápido: a colaboração.

A Colaboração e o mundo do DevOps, Ágil e testes contínuos

Não é só nos climas político e econômico que a colaboração está crescendo como o aspecto mais importante dos negócios. A colaboração também é o principal fator de sucesso para os líderes no espaço técnico - para entregar software e valor mais rapidamente aos clientes com uma abordagem ágil.

Com o ágil, começamos a transformar o antigo modelo de entrega de software dependente de fase, em uma abordagem centrada em valor e equipe, reduzindo os tamanhos de entrega/lote e automatizando as interações manuais para reduzir os custos de transação, aumentando simultaneamente a qualidade e a velocidade das entregas (ver figura 1). Normalmente, as dispendiosas interações manuais abrangem duas áreas - instalar, implantar e configurar aplicações de um lado e verificar as funcionalidades da aplicação do outro - desde o desenvolvimento, durante os estágios de teste, até a produção (teste contínuo). Entregamos com mais frequência, entregamos pacotes menores - e testamos continuamente o que entregamos.

(Clique na imagem para ampliá-la)

Figura 1: 

Lado Esquerdo: A configuração hierárquica da equipe tradicional para desenvolvimento, teste e operações - a qual normalmente leva a criação de unidades isoladas e com pouca comunicação, longos tempos de processamento devido às entregas, entregas atrasadas e grandes tamanhos de lotes.

Lado Direito: Configuração da equipe ágil - Minimiza a entrega, permite o compartilhamento de informações e melhora a colaboração entre os limites anteriores.

Parte inferior: Exemplo de um processo de negócios (= fluxo de valor) - As equipes baseadas em componentes geralmente se concentram em apenas um componente, em que equipes ágeis mais maduras são configuradas com base em funcionalidades, responsáveis ​​por uma combinação de componentes ao longo do fluxo de valor.

Colaboração dentro da equipe, entre equipes e entre estágios

Três tipos de colaboração provaram ser o caminho para o sucesso e refletem os passos típicos de maturidade que as empresas estão passando em sua estratégia de teste contínuo: colaboração dentro da equipe, colaboração entre equipes e colaboração entre estágios.

I: Colaboração dentro da equipe

O Desenvolvimento Orientado a Testes de Aceitação (ATDD), o Desenvolvimento Orientado a Comportamento (BDD) e o Desenvolvimento Orientado a Testes (TDD) têm provado ser magníficos direcionadores de qualidade e eficiência. Todas as possíveis situações iniciais, condições e resultados esperados são expostos e, pensando através do processo até o final, toda a equipe realmente entende o que é esperado para uma determinada estória de usuário.

Idealmente, a configuração de teste nas equipes ágeis (ver figura 2) segue a analogia da programação em pares. Como os programadores em pares executam revisões de código lado-a-lado, em uma configuração de teste colaborativa, os desenvolvedores e analistas de testes trabalham em paralelo na respectiva estória de usuário, suportam uns aos outros e, desta forma, fornecem artefatos de teste desde o primeiro dia, em um "modelo de teste self-service". Assim que um desenvolvedor pressiona o botão de compilação, um driver de teste já está disponível. Essa abordagem define um padrão de alta qualidade, de acordo com o princípio de verificações e balanceamentos, e também libera recursos do desenvolvedor.

Figura 2: Os times ágeis são multifuncionais e os analistas de testes fazem parte da equipe. As equipes ágeis são auto-organizadas, autogerenciadas e entregam incrementos funcionando, totalmente testados em cada sprint. As equipes ágeis operam com visão, arquitetura e orientação à UX. A configuração da equipe minimiza a entrega, permite o compartilhamento de informações e melhora a colaboração entre os limites pré-estabelecidos.

Configure a suíte de testes e o ambiente como se fosse uma programação em pares

À medida que as equipes ágeis amadurecem, elas obtêm um ganho de alta eficiência das abordagens de teste baseadas em modelo e orientação a objeto. Como o paradigma de desenvolvimento padrão evoluiu para princípios orientados a objeto, o teste baseado em modelo é a etapa evolucionária que adicionalmente nos permite abstrair as camadas de negócios das camadas técnicas. Desta forma, podemos apresentar a cada membro da equipe - técnico ou não-técnico - a melhor visão possível, permitindo que aqueles com diferentes habilidades participem do sucesso geral de teste do projeto.

Utilize artefatos de teste como uma ferramenta em colaboração

Os artefatos de teste (ver figura 3) representam e armazenam as informações necessárias para orientar o teste de uma aplicação - por exemplo, um formulário de UI e seus campos, uma definição de interface ou um formato de arquivo - de maneira não redundante e reutilizável, diminuindo drasticamente o esforço tanto na criação quanto na manutenção, permitindo que esses modelos sejam parte integral de todo o processo de negócio.

Esses artefatos de teste não estão limitados a drivers de teste de interface do usuário ou de API, mas consistem adicionalmente em:

• Rotinas de gerenciamento de dados de teste, que geram dados de teste sintéticos, pesquisas de dados de teste existentes ou snapshots e máscaras de dados
• Um repositório de desenho de teste, que contém:

• Variantes de teste necessárias e para cada pré-requisito de teste variante, os dados de entrada, as condições e o resultado esperado a ser verificado
• Drivers de teste não funcionais e parâmetros, como tempo de resposta, capacidade máxima de carga esperada ou diversas condições de rede
• Para cada variante, seu risco de negócio atribuído - para entender a implicação de cada caso de teste e atribuí-lo a várias listas de execução em cascata, como testes de fumaça, sanidade ou regressão.

(Clique na imagem para ampliá-la)

Figura 3: Os artefatos de teste consistem em um repositório holístico de casos de teste, priorizado pelo risco associado a cada caso de teste. O repositório define os parâmetros de entrada, as condições e os resultados esperados - em combinação com o gerenciamento de dados de teste - o qual fornece registros para execução de testes, cria dados de teste sintéticos ou snapshots e máscara de aplicações de bancos de dados. O repositório é composto de artefatos de teste baseados em modelo e em orientação a objetos, para testes de interface do usuário, testes de API ou outros drivers de teste que não sejam da interface do usuário, como um banco de dados de triggers de teste de arquivo, drivers de teste não funcionais como carga ou simulação das condições da rede. O serviço de virtualização simula aplicações dependentes e utiliza um repositório idêntico de dados de teste.

Transformar testes de progressão em testes de regressão

Frequentemente vemos equipes ágeis criando testes de progressão para uma nova funcionalidade com uma determinada ferramenta de teste e, por outro lado, equipes de implementação criando testes de regressão - trabalho redundante, o qual causa esforço e atrasos adicionais. Com uma abordagem baseada em modelo, cada caso de teste de progressão, que inicialmente verifica a nova funcionalidade, pode ser reutilizado e transformado em um portfólio completo de testes de regressão (ver figura 4).

Ao transformar os testes de progressão em testes de regressão, podemos alcançar um novo nível de precisão, que os testes de caixa preta nunca poderiam fornecer.

Outra vantagem inestimável dessa abordagem é que as equipes ágeis são o centro do conhecimento e estão muito bem equipadas para criar, manter e atualizar esses artefatos de teste - quase em tempo real, com o mínimo de esforço e o melhor conhecimento possível. Essa abordagem permite um novo nível de precisão nos testes.

Figura 4:Para uma estratégia de teste eficiente e precisa, os artefatos do teste de progressão (= Verificação de nova funcionalidade durante a iteração) precisam ser reutilizados como testes de regressão na próxima iteração após a entrega incremental (= Verificação das funcionalidades existentes do sistema todo).

É realmente necessário um analista de testes dedicado em cada equipe?

Ainda existe a dúvida em incluir um analista de testes dedicado nas equipes? Na jurisdição criminal, a separação de poderes e o sistema de verificações e equilíbrios foi introduzido há quase 200 anos. Como promotores, defensores e juízes não estão mais unidos em uma única pessoa, não vemos mais nenhum julgamento espetacular de bruxas. Um analista de testes dedicado auxilia o desenvolvedor - como mencionado anteriormente e a programação em pares ajuda a eliminar os erros.

II: Colaboração entre equipes

"Dois paralelos se cruzam no infinito!" - disse o professor de geometria descritiva de Alexander Mohr, quebrando sua confiança na ciência aos dezessete anos, enquanto estava ocupado apenas tentando entender como desenhar sombras de bola de perspectiva central. Entretanto, para Alexander, parecia que na ciência de software acontece exatamente o oposto: duas equipes paralelas, uma provedora de serviços e outra consumidora de serviço, convergem enquanto trabalham a partir de uma descrição de interface idêntica, após 1 ou 2 iterações já estão concluídos. De certo modo, não se poderia acreditar que ambos falam a mesma linguagem (de definição).

A solução: Testes de contrato provam a compatibilidade da interface, antes que ocorra a divergência

Os componentes interagem por meio de interfaces, as quais são a chave para a colaboração em equipe. Em vez de esperar por testes de integração para provar algum problema em um momento posterior, o uso de testes de contrato permite que cada equipe verifique seus componentes por completo e imediatamente quanto à correção desde o início, sem precisar ter o componente dependente disponível (ver figura 5).

Os testes de contrato desacoplam cada componente de suas dependências e interpretam a definição de interface entre cliente e consumidor de serviço como um "contrato". Por meio desse contrato, criamos drivers de teste de API contra o provedor de serviços, bem como testes de virtualização de serviço espelhados para o consumidor. Com essa abordagem, estes testes de contrato garantem interações de interface correspondentes em qualquer momento.

Figura 5: (1) "Contrato" é o sinônimo da definição de interface entre o serviço do cliente e do provedor. Com uma definição inicial de interface, (2) os artefatos do driver de teste da API e da virtualização de serviço podem ser criados e fornecidos para o teste do time ágil (abordagem test first). Os testes de contrato são a base para testes (simulados) de integração de sistema eficientes.

A virtualização de serviços permite testes de processos de negócios totalmente em sandbox

A virtualização de serviço é uma tecnologia de simulação que permite a execução de testes sem a disponibilidade dos componentes de sistema dependentes da aplicação em teste (do inglês Application Under Test - AUT). A virtualização de serviço garante que seus testes encontrem o comportamento de dependência e os dados apropriados toda vez que forem executados (veja a figura 6).

Depois que os dados de esquema e solicitação da aplicação em teste (AUT) forem verificados, os dados poderão ser armazenados, reutilizados ou modificados para etapas posteriores do cenário de virtualização de serviço. Pode-se incorporar funções string, matemáticas ou externas para tornar os cenários de teste mais realistas. Além disso, é possível acessar os sistemas de correspondência dinâmica de padrões para fornecer diferentes cenários de resposta, estruturas ou simulações de falhas. A virtualização de serviços permite testes de processos de negócios totalmente em área restrita - permitindo um feedback completo e inicial da qualidade no ciclo de vida do software. [veja também Virtualização de Serviço Orientada a Testes]

Figura 6: A virtualização de serviço ("teste de sandbox") permite que a equipe de Purchase-Order-Service recupere todos os resultados de testes de integração diariamente, incluindo cenários completos de negócios. A aplicação em teste (Purchase-Order-Service) é encapsulada em uma abordagem orientada a testes usando drivers de teste e artefatos de virtualização de serviço que simulam aplicações dependentes, sendo que ambos usam o mesmo repositório de dados de teste.

Testes de contrato (API reversa) são a chave para colaboração

No lado do provedor de serviços, as APIs são a chave para resolver o Gordian Knot para qualidade com velocidade. Ao reverter os cenários de virtualização de serviço para os drivers de teste da API, este pode agir como dois lados da mesma moeda: a virtualização de serviço para o consumidor do serviço e um driver de teste da API contra o provedor do serviço.

Também quebramos as barreiras do time ágil - permitindo que as equipes do provedor do serviço e do cliente executem e cubram testes de integração simulados na fase inicial de desenvolvimento, que normalmente só seriam possíveis em ambientes posteriores de teste de integração.

Rotinas de virtualização de serviço são artefatos de teste

Os testes de contrato contam como artefatos de teste; criados, mantidos e versionados da mesma forma que os testes de interface de usuário, os quais permitem que fornecedores locais, offshore ou mesmo externos executem testes de integração (simulados).

API first!

API first - a diretiva para focar nos testes de API first surge não somente como um produto dessa configuração mais eficiente e do desejo de reduzir os custos de manutenção, mas predominantemente de nós, permitindo testes de contrato progressivos entre as equipes.

Essas etapas são essencialmente as mesmas usadas por muitos anos em simuladores de Fórmula 1. A configuração e a interação de centenas de componentes são simulados (as equipes de F1 estão limitadas a usar menos de 25 Teraflops para simulação) e uma vez que a simulação identifica uma configuração apropriada, o piloto verifica e ajusta essa configuração em uma rápida volta de dois minutos a mais de 200 milhas por hora com o carro real na pista de corrida. Ou que tal nos programas de treinamento de pilotos - eles deixariam um novato bater um A380 real quando pegassem seu primeiro voo? Pode ser um pouco caro demais.

III: Colaboração entre estágios

Com as primeiras equipes da empresa transformadas em ágil, há um padrão repetido que mostra novamente um aumento do protecionismo.

"Com mais de 50% das organizações implementando o DevOps" (8), podemos ver um padrão semelhante e repetido - assim que algumas equipes ou mesmo linhas de negócios inteiras são transformadas, um tópico familiar está de volta no primeiro plano: o protecionismo.

Como evitar um surto de protecionismo sobre os limites da equipe e, portanto, a formação repetida de muros? Desta vez, não é entre Dev, Test, Ops e Negócios, mas entre as equipes ágeis e a linha de negócios que muitas vezes se tornou independente através da transformação digital. Como a colaboração deve ser incorporada ao processo para implementar com sucesso uma estratégia de teste contínuo para toda a empresa, de forma que os CEOs e membros do conselho administrativo não continuem enfrentando grandes atrasos nas iniciativas de produtos em larga escala?

Uma vez que o número de equipes ágeis cresce, forma-se um composto de times ágeis: tribos, Agile Release Train ou linha de negócios - podendo aplicar o modelo Spotify ou seguir o Scaled Agile Framework (ver figura 7), mas com o mecanismo de teste em estágios ainda presente, assumindo que os processos de teste já estão amadurecidos e que a primeira e abrangente verificação de qualidade ocorra dentro da equipe e, em seguida, seja coberta por meio do teste de contrato.

(Clique na imagem para ampliá-la)

Figura 7: Esquerda - O Scaled Agile Framework (2). Direita - O Modelo Spotify (3).

Os frameworks ágeis corporativos descrevem a hierarquia e a estrutura necessárias para escalar com sucesso o ágil na organização, como agrupar equipes ágeis, como distribuir software entre equipes e como criar e gerenciar um composto de equipes ("Agile Release Train", "Tribos") .

Ainda assim, testes eficientes são necessários nos estágios de teste - para impedir comportamentos desconhecidos ou não identificados - especialmente para casos de uso substanciais com alto risco de negócios associados. No primeiro estágio, normalmente a interação de componentes é verificada, no segundo estágio, casos de uso completos de ponta a ponta e testes finais de aceitação de negócios são cobertos.

Agora imagine os recursos adicionais, o tempo e o alinhamento necessários - e consequentemente o atraso - sobre os esforços dos membros da equipe ágil se precisarem recriar os artefatos de teste para esses estágios de teste, geralmente por uma equipe de implementação dedicada. Para não reconstruir outra parede, existe uma regra simples, mas que muda o jogo:

Artefatos de testes são entregáveis

Quanto mais tarde as alterações são feitas, geralmente mais frágil é a automação de testes, porém a reutilização dos artefatos de teste garante a colaboração e a transferência do conhecimento.

O teste contínuo exige um equilíbrio entre equipes ágeis e equipes de implementação (de sistema).

Após realizada uma transformação da estrutura hierárquica para equipes ágeis, em algumas empresas, as equipes ágeis podem ser responsáveis ​​por sua aplicação em todos os passos do desenvolvimento até a produção, mas a maioria terá equipes separadas de implementação (de sistema) para implantar, manter e testar o conjunto de todas as aplicações.

O Scaled Agile Framework afirma que "requer um senso de equilíbrio entre equipes ágeis e equipes de implementação (de sistema)", o que exige que essas equipes colaborem fortemente, compartilhando conhecimento e artefatos de teste.

Figura 8: A velocidade ótima (e o esforço) é uma responsabilidade (de teste) compartilhada entre equipes de ágeis e equipes de implementação (de sistema).

Como funciona um pipeline de entrega contínua?

O trio de um repositório de fontes, o sistema de controle de versão e a automação de entrega orquestram um pipeline de entrega contínua, em combinação com uma plataforma de teste contínuo, os quais instala, configura e implanta a aplicação em vários estágios de teste e para produção, observa regras de decisão, limites de qualidade, dependências de aplicações e - se necessário - executa cenários de reversão. Também acionam a execução do teste para cada estágio, com base na aplicação e na versão implementada.

Figura 9: Os estágios de teste da esquerda para a direita: (1) Dev: normalmente em uma máquina local, o teste é executado em um tipo de programação em pares. (2) QA: construção e testes acionados via CI, focando apenas no componente da equipe (teste de sandbox). (3) Teste de integração de componentes para o conjunto de componentes dos times ágeis (Tribo, Linha de Negócios, Agile Release Train). (4) E2E - Teste abrangendo a solução completa (Tribos de Tribos / composto de Linha de Negócios / Solution Train).

As ferramentas de automação de entrega de aplicação são a base da entrega contínua - instalando, implantando e configurando aplicações em cada estágio de teste e produção, com base em um versionamento de componente, um repositório para evitar que o código seja recompilado, acionando a execução de teste para cada estágio individualmente, seguindo para a próxima etapa com base em critérios de decisão predefinidos e na execução de cenários de reversão, se necessário.

Como esses estágios são construídos de forma altamente dinâmica, (criadas, versionadas e mantidas) inicialmente em equipes, os artefatos de teste são melhor equipados para atender à velocidade e à qualidade exigidas.

Eleve a automação de testes em verdadeiros processos de verificação, em vez de uma atividade de mudança downstream

Os testes de sistema geralmente possuem uma orientação diferente, os artefatos de teste como direcionadores de teste de interface do usuário, testes de interface, rotinas de teste de dados e um repositório de teste ainda podem ser aplicados a testes de ponta a ponta, enquanto seguem o foco nos processos de negócios.

Os casos de teste de ponta a ponta, once-in-place e baseados em modelo, combinam as peças das várias equipes. As modificações em cada componente e seus drivers de teste, executados pelas equipes ágeis depois de algumas iterações, são herdadas e mescladas nas cadeias do processo de teste de ponta a ponta. Os testes baseados em modelo permitem a execução de testes verticais para fluxos de valor completos, utilizando a versão correta para cada estágio de teste e elevando a execução de testes automatizados em verdadeiros processos de verificação, em vez de atividades de mudança downstream.

(Clique na imagem para ampliá-la)

Figura 10: Normalmente, uma equipe de sistema dedicada verifica a funcionalidade da aplicação no nível corporativo. A melhor velocidade, esforço e qualidade podem ser alcançadas quando os artefatos de teste são entregues das equipes para a linha de negócios para as equipes do sistema.

Os métodos como alternância de recursos ou o teste em produção mudam a maneira como realizamos testes críticos de negócios de ponta a ponta? O teste em produção normalmente é utilizado para casos de uso de menor risco, fornecidos a uma pequena base de clientes, usando implantação verde-azul e, se necessário, revertidos automaticamente em caso de erros. E o recurso alterna? Processos críticos, como mudanças no processo de pagamento do carrinho de compras, ainda serão testados o suficiente antes que os clientes vejam os dados do cartão de crédito de outro cliente.

Ainda acha que as equipes ágeis deveriam ser totalmente auto-organizadas (e apenas focadas em seus componentes)? Jamais se esqueça de W. Edwards Deming:

"Um sistema deve ser gerenciado. Não irá se auto-gerenciar. Se deixados por conta, os componentes tornam-se centros de lucro egoístas, competitivos e independentes, e assim destroem o sistema. O segredo é a cooperação entre componentes para o objetivo da organização."

Conclusão - O passado, o presente e o futuro

Nas últimas duas décadas, os centros de testes tiveram uma vida difícil concentrando-se de maneira dominante na verificação de processos de negócios de ponta a ponta. Existe um vasto campo de tensão onde, muitas vezes, mais de 50 fornecedores diferentes, externos, próximos ou internos, são confrontados com entregas atrasadas, insumos de qualidade inferior, em que os protocolos do teste de aceitação do desenvolvedor não são seguidos, verificações de qualidade são realizadas no final do processo, em ambientes de teste com pouca manutenção e em períodos de tempo cada vez mais curtos. É um emaranhado disfuncional.

Agora vemos o pêndulo balançando à extrema esquerda no mercado, onde agora é esperado que os desenvolvedores em suas equipes resolvam todos os problemas de qualidade.

Pense além do limite da sua equipe.

Como é frequente, o caso, a verdade está no meio - e requer equilíbrio e colaboração entre as equipes ágeis e as equipes de implementação - culturalmente, em processo, bem como na entrega de artefatos de teste.

De acordo com os três estágios mencionados acima, as equipes se concentram apenas em seus componentes no início, e o pensamento geral ocorre mais tarde, uma vez que a empresa amadureceu em sua transformação ágil.

Uma abordagem perfeita para escalar o ágil para a organização, requer mais que cada equipe ágil se auto-organize - requer que a equipe veja a colaboração entre fronteiras como uma parte crucial do paradigma ágil. Uma atitude de "pensar além das fronteiras da equipe" pode ser melhor alcançada ao envolver equipes em atividades de testes tradicionalmente separadas, mas agora coesas, que são conduzidas durante os vários estágios de testes contínuos, não somente no desenvolvimento. Com a livre escolha de ferramentas em cada equipe, os testes só podem funcionar se as ferramentas selecionadas, não servirem apenas ao propósito da equipe, mas também permitir integração e uso contínuo em etapas adicionais de teste, por uma variedade de diferentes olhos e funções.

Adendo

1. Cabeçalho: Fonte: 683014141/Shutterstock.com; World Economic Forum
2. Figura 7: © The Scaled Agile Framework
3. Figura 7: © Spotify
4. Figura 8: Shared Responsibility
5. W. Edwards Deming: Scaled Agile Framework - principle #2 Apply system thinking
6. Teste de automação baseado em modelo
7. Figura 9: Automação de entrega de aplicação
8. Forrester: 2018 - The Year of Enterprise DevOps

Sobre o autor

Alexander Mohr trabalha para a Tricentis desenvolvendo e fornecendo estratégias, melhores práticas e liderança intelectual em jornadas de testes contínuos nas organizações, configurando road-maps para transformação ágil, CI / CT / CD e supervisionando empresas durante sua jornada de transformação. Alexander tem mais de 19 anos de experiência em TI, iniciados no início de 2000 como desenvolvedor em uma empresa de cartão de crédito, criando um sistema de emissão e aquisição. Nos 15 anos seguintes, Alexander atuou em diversas funções como desenvolvedor, product owner, analista de negócios, gerente de teste, arquiteto e gerente de projetos, aprendendo muito sobre o que fazer e o que não fazer em projetos ágeis e cascata em organizações de médio e grande porte.