Vamos começar com o doce e dar exemplos da prática de teste.
Imagine uma loja online pronta para o lançamento. Nada é um problema. Os profissionais de marketing desenvolveram uma estratégia de promoção, os artigos foram escritos em recursos especializados da Internet e a publicidade, paga. A gerência esperava até 300 compras semanais. Na primeira semana, os gerentes registram 53 pagamentos. A gerência da loja está furiosa ...
O gerente de projeto corre em busca de razões: a falta de pensamento sobre usabilidade? tráfego inadequado? outra coisa? Começamos a entender, estudamos o sistema de análise de dados. Aconteceu que 247 pessoas chegaram ao caixa e apenas 53 pagaram.
A análise mostrou que o restante não pôde fazer uma compra por causa do endereço de email!
O teste do formulário de pedido foi entregue a um especialista iniciante. Ele tentou o seu melhor, inseriu nos campos "Nome", "E-mail", "Telefone" todas as opções possíveis e impossíveis que lhe deram geradores on-line. Uma semana depois, todos os erros foram encontrados e corrigidos. O lançamento ocorreu. Mas entre as opções consideradas, não havia um único endereço de e-mail contendo menos de 8 caracteres após @.
Portanto, os felizes proprietários de mails @ mail.ru, @ ya.ru (e similares) não puderam inserir seus e-mails e deixaram o site sem fazer compras. Os proprietários receberam menos de 600 mil rublos, todo o orçamento de publicidade foi drenado e a própria loja on-line recebeu várias críticas negativas.
Você acha que este é um caso isolado? Então aqui está outra história de horror para o cliente.
Na esteira do interesse geral em pagamentos sem dinheiro, a empresa de empréstimo decidiu introduzir uma nova maneira de transferir fundos - para o cartão bancário do mutuário. Implementamos o formulário apropriado na conta pessoal do gerente, testamos várias opções de erro nos campos para inserir dados do cartão, corrigimos e começamos a trabalhar. Um mês depois, a administração alcançou informações de que 24% dos potenciais tomadores de empréstimos que já haviam recebido aprovação não solicitaram um empréstimo até o final. Porque Eles forneceram um cartão bancário, cujo número continha 18 dígitos, em vez dos dados prometidos e testados 16. Nem o sistema nem os gerentes conseguiram registrar esses cartões, e os clientes ficaram com nada.
O projeto piloto foi implementado em 3 escritórios da cidade. O número médio de empréstimos mensais em três escritórios era 340. Resultado: a organização perdeu pelo menos 612 mil rublos. receita.
Estes são apenas alguns exemplos em que dados sintéticos podem causar sérias perdas em um projeto. Muitos testadores inserem dados sintéticos para testar vários projetos - de aplicativos móveis a software. Nesse caso, os próprios testadores criam situações de teste, tentando prever o comportamento do usuário.
No entanto, na maioria das vezes, eles veem o usuário não multidimensional, como em um cinema com óculos 3D, mas superficial, como se a criança pintasse um homenzinho em uma folha de álbum.
Isso leva ao fato de que o testador não cobre todas as possíveis situações de teste e não pode trabalhar com uma grande quantidade de dados. E, embora o teste possa ser realizado bem, não há garantias de que o sistema não cairá quando um usuário real (geralmente ilógico e até imprevisível) começar a interagir com o produto.
Hoje falaremos sobre quais dados dar preferência no processo de teste: sintético ou real.
Vamos entender em termos
Toda vez que fazemos um teste, decidimos quais dados de teste usaremos. Suas fontes podem ser:
- Cópias do banco de dados de produção na bancada de testes.
- Banco de dados de sistemas clientes de terceiros que podem ser usados no atual.
- Teste geradores de dados.
- Criação manual de dados de teste.
As duas primeiras fontes nos fornecem dados reais de teste. Eles são criados pelos processos existentes pelos usuários ou pelo sistema.
Por exemplo, quando ingressamos em um projeto para desenvolver um produto da Web para uma empresa de manufatura, podemos usar uma cópia do banco de dados 1C existente para testes, que por vários anos coletou e processou todos os dados sobre operações e clientes. Usando o módulo para gerar e exibir relatórios sobre pedidos concluídos, obtemos informações da 1C no formato necessário e trabalhamos com dados de teste reais.
Chamamos as fontes dos pontos 3 e 4 de "dados de testes sintéticos" (esse termo pode ser encontrado em testes estrangeiros, mas raramente é usado no segmento de idioma russo). Nós mesmos criamos esses dados para fins de desenvolvimento e teste.
Por exemplo, recebemos um pedido de uma nova plataforma de negociação eletrônica para compras por organizações estaduais e municipais de acordo com as 44 leis federais. Aqui, regras muito rígidas de proteção de informações são seguidas, para que a equipe não tenha acesso a dados reais. A única saída para o teste é criar um conjunto inteiro de dados de teste do zero. Até assinaturas digitais físicas destinadas apenas a testes.
Em nossa prática, um tipo de dados raramente é usado; geralmente trabalhamos com uma combinação deles, dependendo da tarefa.
Para verificar as limitações e exceções no mesmo sistema para a empresa de fabricação, também usamos dados sintéticos. Com a ajuda deles, verificamos como o relatório se comporta se não houver produtos em um dos pedidos. Em uma plataforma de negociação eletrônica, combinamos dados sintéticos com os livros de referência reais OKPD2 e OKVED2.
Recursos de dados sintéticos
Em algumas situações, os dados sintéticos simplesmente não podem ser dispensados! Vamos ver quais tarefas elas podem ser usadas no arsenal do testador:
1. Simplificação e padronização
Frequentemente, dados reais são matrizes de dados homogêneas: imagine que milhares de indivíduos com um conjunto de atributos, entidades legais de diferentes tipos, operações padrão e muitos outros tipos de entidades estejam registrados no sistema. Então, por que gastar horas testando a mesma entrada, se você pode combiná-las em grupos e nomear um "representante" para cada grupo?
Em um dos projetos do ano passado, o cliente decidiu fortalecer a equipe de testadores antes do próximo lançamento, para o qual uma equipe de nossos especialistas estava envolvida. O produto continha um formulário de registro modificado com muitos campos. Estabelecemos os formulários de teste por 30 minutos e passamos a mesma quantidade de tempo. Paralelamente, foi revelado que outro testador já havia testado esse formulário, tendo passado 7 horas nele. Porque Ele apenas decidiu executar o teste de acordo com os dados reais de 12 funcionários da lista de funcionários e não levou em conta que o teste para um funcionário abrange todos os atributos iguais para cada perfil registrado.
Lucro: 6 horas e 30 minutos e isso é apenas em um teste.
2. Combinatória e cobertura de teste
Apesar da grande quantidade de dados reais, eles podem não conter um número possível de casos. Para garantir a operacionalidade do sistema com várias combinações de dados de entrada, precisamos gerá-los nós mesmos.
Vamos voltar ao exemplo anterior. O formulário de registro no novo release foi finalizado por um motivo. A equipe do cliente, baseada nas normas da cultura corporativa, decidiu tornar obrigatório o nome do meio. Como resultado, todos os especialistas estrangeiros no estado de repente tiveram um pai - Ivan (alguém disse para escrever Ivanovich até que eles o consertem). O caso é engraçado, mas se você não levar em consideração a lista de desejos ou os parâmetros de seus clientes nos testes, não se ofenda se essas pessoas não o levarem em consideração em seus custos / avaliações.
3. Automação
Em testes automatizados, dados sintéticos são indispensáveis. Mesmo alterações aparentemente insignificantes nos dados podem afetar a operação de um conjunto inteiro de execuções de teste.
Um exemplo do setor bancário será ilustrativo aqui. Para verificar se o aplicativo registra corretamente os números da conta bancária nos documentos gerados, gastamos 120 pessoas / horas escrevendo autotestes. Não houve acesso ao banco de dados, porque o número da conta foi indicado no próprio autoteste. Os testes mostraram excelentes resultados e estávamos prontos para extrair 180% + ROI da automação no relatório. Mas uma semana depois, o banco de dados foi atualizado com uma alteração no número da conta. Todos os autotestes, bem como nossos esforços de automação, terminaram em segurança. Após revisar os autotestes, o ROI final caiu para 106%. Com o mesmo sucesso, poderíamos começar imediatamente a testar com nossas mãos.
4. Melhorando a gerenciabilidade
Usando dados sintéticos, sabemos (na pior das hipóteses, assumimos) que tipo de resposta esperar do sistema. Se forem feitas alterações na funcionalidade, entenderemos como a resposta aos mesmos dados será alterada. Ou podemos ajustar os dados para obter o resultado desejado.
Em um dos projetos, nossa equipe começou a testar usando dados reais do banco de dados de contrapartes do cliente. O banco de dados foi refinado ativamente, mas naquele momento foi compilado de maneira extremamente descuidada. Perdemos tempo tentando entender onde está o erro, na funcionalidade ou no banco de dados. A solução foi simples: compor um banco de dados sintético, que se tornou mais curto, porém mais adequado e mais informativo. O teste dessa funcionalidade foi concluído em 12 pessoas / hora.
Então, quais são as desvantagens?
Dados sintéticos podem parecer onipotentes. Assim é, até você encontrar o fator humano. Dados sintéticos são criados intencionalmente por pessoas e essa é sua principal desvantagem. Fisicamente, não podemos pensar em todos os cenários possíveis e combinações de fatores de entrada (e ninguém cancelou força maior). E aqui a vantagem permanece para os dados reais.
Os benefícios de trabalhar com dados reais
Que vantagens vemos ao trabalhar com dados reais? 4 provas da nossa experiência:
1. Trabalhe com grandes quantidades de informações
A operação real do sistema nos fornece milhões de operações. Repita o trabalho simultâneo de milhares de usuários ou a geração automática de dados não será capaz de nenhuma equipe de especialistas.
Prova: criamos um mini-banco de dados sintético que, como nos pareceu, atendeu a todos os critérios da base existente do cliente. Com uma base sintética, tudo funcionou muito bem, mas assim que você executou testes com uma base real, tudo caiu. Conclusão: se você não pode levar em consideração todas as nuances de uma amostra de dados real, não perca tempo gerando dados sintéticos.
2. Usando uma variedade de formatos de dados
Texto, som, vídeo, imagens, arquivos executáveis, arquivos - é impossível prever o que o usuário decide enviar para o campo do formulário. As dicas sobre os formatos aceitos podem ser ignoradas e a proibição de download pode não ser implementada pela equipe de desenvolvimento. Como resultado, os cenários desejados são testados. Por exemplo, no campo de download de som, é realmente possível baixar um arquivo mp3 e que o download de um arquivo executável não irá prejudicar o sistema. Dados reais nos ajudam a rastrear exceções.
Prova: testamos o campo de upload de fotos no perfil do usuário. Tentamos os formatos gráficos mais comuns do banco de dados, além de vários arquivos de vídeo e texto. Compilação sintética carregada perfeitamente. No uso real, verificou-se que qualquer tentativa de baixar um arquivo de som causa um erro. Todo o formulário de registro falhou sem a capacidade de substituir o arquivo. Mesmo uma atualização de página não foi salva.
3. Imprevisibilidade do comportamento do usuário
Embora muitos especialistas em controle de qualidade tenham conseguido criar e analisar situações excepcionais, sejamos honestos - nunca seremos capazes de prever com precisão como uma pessoa se comportará e os fatores que a cercam. E você pode começar desligando a Internet no momento da operação e terminar com as operações com o código do programa e os arquivos internos.
Prova: em nossa empresa, todos os anos, os funcionários passam por certificação, onde, entre outras coisas, avaliam suas habilidades em um questionário especial. As estimativas são acordadas com o chefe e, com base nelas, é calculada a nota (nível) do especialista. Antes do lançamento, o módulo era totalmente testado, tudo funcionava como um relógio. Porém, uma vez, no momento de salvar os resultados, um ataque de ddos foi feito no sistema, como resultado, do qual apenas parte dos dados foi salva e as tentativas subseqüentes de salvar apenas duplicaram os erros. Sem uma situação real, não teríamos encontrado um erro tão sério.
4. Atualizações do sistema
É muito importante entender como o sistema se comportará durante a atualização, quais são os possíveis riscos, o que pode "não decolar". Em programas como o 1C, onde um grande número de diretórios e links, a questão das atualizações é especialmente aguda. E aqui a melhor opção seria ter uma cópia nova da versão de produção, testar a atualização e somente então ser liberada.
Prova: o caso é bastante comum. Projeto na área de serviços de factoring. A criticidade da perda e distorção de dados é esmagadora, e qualquer suspeita de relevância dos dados reproduzidos pelo sistema pode parar todo o escritório. E aqui nosso especial lança de forma torta a próxima atualização imediatamente para o produto, sem capturar as últimas 10 versões das compilações.
Eles foram lançados às 18h00, horário fixo da manhã, às 11h. Devido à falha na conclusão e incompreensão das versões, o trabalho das divisões da empresa ficou completamente congelado por 2 horas. Os gerentes não puderam processar contratos atuais e registrar novos.
Desde então, trabalhamos com três estandes sem falhas:- Desenvolver. As melhorias são apresentadas aqui, a anarquia e a ilegalidade estão acontecendo, chamadas de teste de exceção. Os engenheiros de controle de qualidade trabalham principalmente com dados sintéticos, os reais são infundidos com pouca frequência.
- Pré-lançamento. Quando todas as melhorias são implementadas e testadas, elas estão indo para este ramo. Uma versão com uma venda também é lançada preliminarmente aqui. Assim, testamos a atualização e a operação de novas funções em condições de combate condicional.
- Produção. Esta é uma versão funcional e de combate do sistema com a qual os usuários finais trabalham.
Então, quais dados e quando trabalhar?
Compartilhamos três ideias do nosso trabalho com dados reais e sintéticos:
1. Lembre-se de que a escolha do tipo de dados depende dos objetivos e do estágio do teste. Assim, desenvolvendo um novo sistema, só podemos operar com dados sintéticos. Para cobrir várias combinações de condições de entrada, também, na maioria das vezes, nos voltamos para elas. Mas a reprodução de alguma exceção complicada relacionada ao comportamento do usuário exigirá logs reais. O mesmo se aplica ao trabalho com diretórios e registros geralmente aceitos.
2. Não se esqueça de otimizar seu trabalho com dados de teste. Sempre que possível, use geradores, crie registros comuns das principais entidades, salve e use backups do sistema a tempo, implantando-os no momento certo. A preparação para o próximo projeto não será uma fonte de melancolia e melancolia para você, mas uma das etapas do trabalho.
3. Não vá para o lado de sintéticos sólidos, mas não se concentre em dados reais. Use uma abordagem combinada para testar dados, a fim de não perder erros, economizar tempo e mostrar o máximo de resultados em seu trabalho.
Apesar de os sintéticos estarem profetizando um grande futuro, e os cientistas viram nos dados sintéticos uma nova esperança para a inteligência artificial, os sintéticos não são uma panacéia para testes. Essa é apenas outra abordagem para gerar dados de teste que podem ajudar a resolver seus problemas e podem levar a novos. Conhecer os pontos fortes e fracos dos dados reais / sintéticos, bem como a capacidade de aplicá-los no momento certo, é o que protege você contra perdas, tempo de inatividade ou ação legal. Espero que hoje tenhamos ajudado você a se tornar um pouco mais seguro. Ou não?
Vamos discutir. Conte-nos nos comentários sobre seus casos de trabalho com dados de teste sintéticos e reais. Vamos ver quem entre nós é mais: realistas ou sintéticos? ;)
Victoria Sokovikova.
Analista de Teste no Laboratório de Qualidade