Por Wesley Ribeiro
Introdução
A garantia de qualidade de software depende mais dos dados de teste do que todos nós
gostaríamos. Não é mais possível escapar: você precisa fazer algo a respeito do
gerenciamento de dados de teste. Por quê? Porque sem um gerenciamento de dados de teste
adequado, você perde um tempo valioso que já é escasso e compromete a eficácia dos seus
ciclos de teste.
Os tempos de espera para a atualização de dados de teste são longos; em média, as equipes
de QA precisam esperar 6 dias antes de terem seu conjunto de testes atualizado. Outro
problema que surge na ausência do gerenciamento de dados de teste é que, em muitas
organizações, várias equipes trabalham no mesmo banco de dados de teste. Uma equipe faz
ajustes nos dados, o que muitas vezes resulta em dados de teste corrompidos para a outra
equipe. E não vamos esquecer os dados de privacidade sensível, que ainda são usados (sem
proteção) com muita frequência. Embora esteja claro que não é permitido usar informações
de identificação pessoal para fins de teste, muitas organizações não fazem nada a respeito
da proteção de dados. É hora de virar o jogo. Vamos resolver os problemas com os dados de
teste para que eles possam trabalhar a nosso favor, em vez de contra nós.
Proteção de dados
O primeiro passo é garantir que não haja informações de identificação pessoal em seus
ambientes de teste. A qualidade e segurança dos dados utilizados impactam diretamente a
confiabilidade dos resultados de testes gerenciados em plataformas como o TestRail. Para
resolver isso, uma prática comum é copiar e mascarar os dados de produção. Com o auxílio
de regras de mascaramento e geradores de dados sintéticos, você cria um conjunto de dados
de teste confiável e reconhecível, que não leva a uma pessoa física. Ter dados de teste
semelhantes aos de produção é essencial na garantia de qualidade de software. Quando sua
aplicação funciona com dados de teste muito similares aos de produção, você pode presumir
que ela também funcionará perfeitamente em produção, tornando os resultados registrados
em seus ciclos de teste muito mais precisos.
Cada equipe com seu próprio conjunto de dados de teste
Um dos maiores gargalos na garantia de qualidade é o tamanho de um banco de dados de
teste. Em geral, vemos que uma cópia da produção é feita para testes, apenas para garantir
que todos os casos extremos sejam cobertos. Mas dar a cada equipe de teste sua própria
cópia causa rapidamente problemas de capacidade de armazenamento. Assim, em muitos
casos, várias equipes são obrigadas a trabalhar com o mesmo banco de dados de teste. Não
é exceção que os dados sejam ajustados por uma equipe, resultando em dados que não são
mais utilizáveis para as outras equipes. A solução aqui é criar subconjuntos funcional e
tecnicamente intactos, um para cada equipe. Contendo apenas os casos que você precisa
para testar, nada mais, nada menos.
Automatize o provisionamento de dados de teste
Uma solicitação para uma atualização de dados de teste (mascarados ou em subconjunto)
pode levar dias ou até semanas da maneira tradicional. Uma equipe precisa de um conjunto
de dados de teste e faz sua solicitação ao administrador do banco de dados (DBA). Ele/ela às
vezes precisa da aprovação do gerente de TI. Para o DBA e o gerente de TI, isso não faz parte
de suas funções normais de trabalho, então muitas vezes não é uma prioridade. Isso resulta
em longos tempos de espera e muita frustração. Ao automatizar o provisionamento de dados
de teste, os DBAs não são mais incomodados e os testadores podem começar a trabalhar de
forma rápida e satisfeita.
Conclusão
É essencial ter controle sobre seus dados de teste. Saiba o que há neles e certifique-se de
que as informações de privacidade sensível estejam protegidas. Os subconjuntos permitem
que você dê a cada equipe de teste seu próprio conjunto de dados. E quando as equipes
podem atualizar seus próprios conjuntos de dados, os dados de teste não irão mais atrasar
seus processos de qualidade de software.
