COMPARTILHE
Share on Facebook
Facebook
Share on LinkedIn
Linkedin

 

Vamos a uma breve reflexão sobre se de fato podemos ter processos de desenvolvimento ágil, como o Scrum, sem uma adequada Gestão de Dados para Teste. Conforme o título espero nas breves linhas abaixo demonstrar que sem a devida atenção com esta disciplina não temos de fato um desenvolvimento ágil (para quem não estiver familiarizado SQN é abreviação da expressão “Só que não”, que remete a negação da afirmação ou expressão anterior, neste caso, a quando acreditamos que temos desenvolvimento ágil mas de fato não temos).

Bem resumidamente, no desenvolvimento ágil temos entregas mais rápidas e de valor reconhecido pelo cliente. Pense em, por exemplo, se tivesse que desenvolver um sistema para um loja, na forma tradicional você desenvolveria todo o sistema e então entregaria ao cliente. Com desenvolvimento ágil você efetua diversas entregas parciais e complementares, onde cada entrega deve obrigatoriamente ter um valor reconhecido pelo cliente. Em nosso exemplo, é como se primeiro você entregasse a função de emissão de nota fiscal eletrônica, em uma outra entrega (que vamos agora chamar de “Sprint”) você entrega a funções de controle de caixa, em outra o controle de estoque, e assim sucessivamente até completar a entrega do sistema ao seu cliente. Dentre as métodos e práticas do desenvolvimento ágil essas Sprints devem durar de 2 a 4 semanas, e dentro dela você tem todo um ciclo de desenvolvimento com análise, codificação, teste unitário, teste integrado, homologação e entrega (deploy).

Agora o que acontece se em uma Sprint seu desenvolvedor no momento de testar uma funcionalidade percebe que não possui os dados necessários para o teste? Aqui temos algumas possibilidades: é aberta uma solicitação de dados para á área de DBA solicitando extração de dados de produção para um ambiente não produtivo, ou um analista é deslocado para produzir estes dados manualmente de forma fictícia (dados sintéticos), ou alguns testes deixam de ser realizados por falta de dados. Em todas as possibilidades haverá uma grande possibilidade de sua Sprint perder o prazo e atrasar. Ou pior, de testes deixarem de ser realizados agregando risco de problemas em produção.

Antes de solicitar a uma área de DBA extração de dados de produção para os ambientes de testes, considere que no processo padrão o DBA irá extrair um percentual de dados da tabela de produção, o que pode ou não atender as necessidades do seu teste. Ainda, quando o foco está em extrair dados de produção você deve se preocupar em mascarar dados sensíveis, evitando expor ou tornar frágil informações confidenciais e sensíveis de seus clientes e de seu negócio. Considere ainda que normalmente extrações de produção são realizadas em janelas, assim fatalmente você terá um tempo de espera enquanto sua Sprint corre e terá que conviver com a possibilidade de descobrir após este tempo que os dados extraídos não cobrem adequadamente a necessidade de seus testes. E normalmente, dados de produção cobrem a menor parte dos testes, pois são dados válidos, de fato úteis para testes funcionais, mas que só cobrem o chamado “caminho feliz” do teste (ou seja, não cobre nenhuma das possibilidades de erro).

Vamos agora pensar em deslocar um analista para manualmente preparar a massa de dados para cobrir seus testes. Aqui a questão é a produtividade de alguém manualmente realizar tal tarefa, e ainda o perfil desta pessoa. O que ocorre normalmente quando não temos uma adequada gestão de dados para teste é que um analista de teste é deslocado para gerar esta massa de dados. A princípio você pode achar que este é o melhor perfil já que se tratam de dados para teste, mas perceba que antes de tudo, se tratam de dados. Assim, o perfil mais adequado é um administrador de dados que terá uma visão mais analítica, por exemplo, com a integridade e dependências existentes entre as tabelas em seu banco de dados. Outra questão é que há uma diferença entre gerar 20 registros para uma tabela, e gerar 2000 mil registros envolvendo 10 tabelas.

Há ainda a pressão por prazo nas Sprints, e não tão raramente, testes deixam de ser realizados por falta de massa de dados, dando o chamado “by pass” em uma parte dos testes, ou mesmo postergando quase sua totalidade para o ambiente de homologação. Assim, testes que deveriam ser realizados em tempo desenvolvimento ou em ambiente de integração, passam a ser executados em tempo de homologação, quando são executados. Este é o pior dos cenários, pois agrega um risco de erros em produção que podem afetar a imagem do produto, ou até da empresa como um todo.

Desta forma, temos uma disciplina para resolver este gargalo, a qual chamamos pela sigla em inglês: TDM (Test Data Management). Há porém um risco mesmo quando tomamos consciência da necessidade de ter atenção com os dados de teste para garantir a agilidade que pretendemos com Scrum ou outros métodos ágeis. É o fato que sem uma ferramenta adequada, podemos ter um processo que até busca atender a esta necessidade, mas terá uma forte possibilidade de não obter a agilidade que se pede. Porém, a compra de uma ferramenta por si só não resolve a questão, por melhor que seja a ferramenta.

Ao implantar a Gestão de Dados para Teste temos que considerar a aquisição de uma ferramenta de TDM adequada à necessidade e ao tamanho do desenvolvimento de software, além de prever a implantação dos processos que garantam a devida gestão dos dados.

Estes processos devem considerar a análise da necessidade de dados junto com a análise dos requisitos do sistema a ser desenvolvido, validando inclusive a viabilidade dos casos de testes propostos. Deve ainda prever qual o nível de cobertura dos testes que se deseja, e qual a melhor estratégia para atingir esta cobertura, se com dados sintéticos ou com extrações de dados de produção.

Ainda prever o provisionamento destes dados já no início de cada Sprint, nos ambientes adequados, garantindo o chamado “Shift-Left”, que busca realizar testes já desde a fase de programação. A ferramenta deve permitir uma espécie de self-service de dados, diminuindo a dependência dos desenvolvedores e das áreas de teste em relação aos administradores de dados da Célula de TDM.

Sim, devemos considerar uma Célula de Gestão de Dados para Teste que possa administrar a ferramenta, treinar o time para utilização, prover massa de dados com maior complexidade e garantir que o processo está agregando agilidade e cobertura dos testes dentro das Sprints.

O perfil adequado para esta Célula de TDM remete a administradores de dados, pois estes profissionais possuem uma visão para dados que os capacitam olhar para requisitos dos sistemas e os casos de testes e abstrair a real necessidade de dados, resguardando a integridade do dado e as dependências existentes dentro de seu Banco de Dados. Desta forma, você pode atingir uma maior cobertura dos testes com o menor volume de dados, no tempo adequado do desenvolvimento. E seu desenvolvimento será Ágil de fato!

 

Por *Warner Silva – Gerente de TDM e Big Data