Get best of the week

O que aprendemos ao testar o sistema de informações do estado

Olá a todos! 

Lidero o setor de testes no departamento de análise e teste de sistemas do departamento de sistemas corporativos da LANIT. Estou neste campo há 14 anos. Em 2009, pela primeira vez, fui confrontado com o teste do sistema de informações do estado. E para a LANIT e para o cliente - foi um projeto enorme e significativo. Está em operação comercial há mais de nove anos.

Fonte

Este texto apresentará a abordagem para testar o SIG, usada em nossa empresa. Em particular, você descobrirá (o link leva ao fragmento do artigo referido em um parágrafo específico):


Antes do LANIT, trabalhei em um grupo de teste de cinco pessoas, onde as tarefas foram atribuídas ao líder da equipe. Quando cheguei à LANIT, fui designado para gerenciar uma equipe de testes distribuídos geograficamente com quatro testadores, que estavam envolvidos no início do projeto para testar o sistema de informações do estado. À medida que o projeto se desenvolvia, o número de testadores no grupo aumentou proporcionalmente ao aumento da funcionalidade.

Capítulo 1. Início do primeiro projeto de teste GIS


Quando começamos a trabalhar com o GIS, tivemos que lidar com grandes volumes de funcionalidade (várias dezenas de subsistemas, cada um com até centenas de funções) que precisavam ser testados em pouco tempo. A equipe teve a tarefa de não se confundir no escopo das funções e minimizar os riscos de defeitos perdidos.

A documentação normativa, com base nas quais especificações técnicas foram desenvolvidas, estava em constante mudança e toda a equipe teve que se adaptar às inovações: revisamos as especificações técnicas para o desenvolvimento e as prioridades do projeto (como resultado, o plano de testes mudou). 

Foi difícil para os analistas adaptar-se à mudança frequente da documentação regulatória, o que levou a uma falta de entendimento de como manter as especificações técnicas atualizadas, como sempre ter um conjunto de especificações relevantes para cada versão do sistema, como e onde exibir o grau de influência de uma alteração em uma especificação em muitos outros documentos relacionados. . 

Como o resultado do trabalho dos analistas foi usado pelos desenvolvedores e testadores, as perguntas sobre a relevância das especificações técnicas, a compreensibilidade do histórico de especificações, a conformidade do conjunto de especificações técnicas da próxima versão do release foram agudas para todos os participantes da equipe do projeto. As consequências da confusão com a documentação, o versionamento das especificações técnicas afetaram o custo do projeto.

Às vezes a situação girava 180 graus. Concordo: quando um trem corre em alta velocidade, é impossível mudar de direção bruscamente, sem consequências.

Participei regularmente de reuniões e entendi o motivo das mudanças no projeto. A parte mais difícil é explicar aos testadores remotos por que testamos o novo registro por um mês e agora precisamos esquecer tudo e nos preparar para testar a funcionalidade completamente redesenhada desse registro. As pessoas começaram a se sentir como engrenagens em uma máquina gigante e seu trabalho foi considerado completamente inútil.

A princípio, essas mudanças irritaram a equipe e desmotivaram fortemente. Mas a equipe aceitou o fato de que é impossível influenciar a alteração nas especificações técnicas, mas você pode aprender a trabalhar com ela. Nesse período difícil para o projeto, a equipe de teste teve uma nova tarefa, que geralmente estava ausente em projetos menores - requisitos de teste. 

Como resultado, as desvantagens de alterar os requisitos se transformaram em vantagens para os testadores na forma de uma nova tarefa para teste e na capacidade de influenciar o resultado final do projeto. 

Além de interagir com analistas, a equipe de teste acabou dependendo de comunicações com sistemas externos aos quais eles deveriam se integrar. Nem todos estavam prontos para fornecer seu circuito de teste e informar os sistemas de terceiros sobre suas datas de lançamento e trocar informações sobre alterações nos serviços. Essa dessincronização nas comunicações ou uma atitude descuidada em relação à notificação da composição de alterações nos serviços da Web por sistemas externos levou a erros do produto e dificuldades na realização de testes de integração. Os testadores tiveram que estabelecer comunicação com sistemas externos, desenvolver a habilidade de testar a integração e atrair desenvolvedores para implementar stubs.

Toda a equipe de teste que participou do projeto foi confrontada com a necessidade de mergulhar a equipe de desenvolvimento no processo de produção. No início do projeto, a equipe de desenvolvimento começou a procurar novas abordagens para a organização do trabalho, introduziu os modelos de ramificação Feature Branch Workflow e o modelo Gitflow. O desenvolvimento de pequenos projetos anteriormente se deu sem muitos ramos, todos estavam à vontade. Mas, diante do problema da incapacidade de estabilizar a versão por alguns meses para a próxima demonstração do estágio intermediário do projeto ao cliente, analisando os motivos, o gerente de desenvolvimento e o arquiteto chegaram à conclusão de que o processo de criação de software precisa ser alterado. Então eles começaram a usar ativamente o Feature Branch Workflow e o Gitflow no projeto. Outra nova tarefa para teste apareceu - estudar os princípios de funcionamento dos modelos de desenvolvimento, a fim de se adaptar ao processo de criação de software.

O GIS envolve dividir um projeto em blocos funcionais, cada um dos quais inclui um conjunto de componentes intimamente relacionados entre si pelos negócios e / ou executando uma função técnica independente. Se no início do projeto todos os testadores verificassem os blocos funcionais recém-chegados, e todos na equipe fossem intercambiáveis, tivessem um nível igual de conhecimento de todos os blocos, então, à medida que o projeto se expandisse, o número de testadores também precisaria ser aumentado e dividido em grupos. O crescimento da equipe levou ao processo de separação em grupos de teste, à alocação das funções do projeto dentro de cada grupo.

À medida que o projeto se desenvolvia, os recursos dos sistemas de informação do estado começaram a aparecer. 

Capítulo 2. Recursos do GIS. Como os testadores vivem e trabalham com eles


Primeiro, o GIS grande está sujeito a requisitos maiores de confiabilidade e carga, operação do sistema - 24 horas por dia, 7 dias por semana, o mau funcionamento do sistema não deve levar à perda de dados, tempo de recuperação do sistema - não mais que 1 hora, tempo de resposta - não mais que 2 segundos e muito mais. 

Por se tratar de um portal da web, os testadores tiveram que mergulhar no processo de teste de portais da web para vários usuários e criar uma abordagem para o design e o processo de teste, levando em consideração as peculiaridades da interface da web.

Um aplicativo da web pode ser usado por um grande número de usuários ao mesmo tempo. Era necessário fornecer testes de carga da parte aberta do GIS usada por todos os usuários, prever o modelo de carga e realizar testes de carga.

O usuário pode ter seus próprios níveis de acesso. Foi necessário testar a matriz de funções de usuário no subsistema de administração de aplicativos usando técnicas de design de teste.

Os usuários podem acessar uma entidade, o que leva ao acesso competitivo. Para que os dados de entrada de um usuário não substituam os dados de outro, tivemos que realizar uma análise de teste de situações nas quais é possível alterar simultaneamente os dados nos painéis pessoais dos usuários, para incluir nos testes as verificações dos testes corretos com mensagens de diagnóstico.

Uma das características do sistema foi o uso do mecanismo de busca SphinxSearch.com o qual a equipe de teste não sabia trabalhar. Para entender os meandros dos testes, a Sphinx precisou consultar os desenvolvedores e entender como ocorre a indexação de dados.

Os testadores dominaram os recursos de testes de pesquisas por formas de palavras, fragmentos de palavras, sinônimos, pesquisando nos documentos anexados, e começaram a entender por que os dados de pesquisa recém-criados não apareciam no resultado da pesquisa e se isso era um erro. 

O projeto possuía um subsistema de administração aplicada, que incluía não apenas o registro do usuário, mas era complicado pela presença de uma matriz de funções do usuário. Foi configurado nas contas pessoais de administradores de organizações. O número de combinações de verificações da matriz de funções era enorme e o número de tipos de organizações também não era pequeno, ou seja, o número de combinações de verificações cresceu exponencialmente. Era necessário mudar a abordagem familiar para projetar testes usados ​​anteriormente em pequenos projetos. 

Como o sistema assumiu uma interface da web, era necessário fornecer testes entre navegadores, o que não foi planejado originalmente. Quando o projeto estava começando, o Internet Explorer 7.0 era o único navegador que suporta criptografia doméstica e a maioria dos usuários usa esse navegador. Portanto, no início do projeto, para testar a lógica e a funcionalidade do trabalho de contas pessoais, apenas o IE desta versão foi usado, mas para a parte aberta do portal, foi necessário suporte para todos os navegadores existentes naquele momento. No entanto, naquele momento, eles não pensaram em testes entre navegadores.

Quando eles me perguntaram: "Como o sistema se comporta em todas as versões conhecidas de navegadores?" - Eu estava em pânico, para dizer o mínimo, já que o volume do modelo de teste era enorme (cerca de 4.000 casos de teste), o conjunto de testes de regressão era de 1.500 casos de teste, e a equipe de teste verificou toda a multidão exclusivamente em um navegador selecionado por padrão. Este caso teve que ser resolvido muito rapidamente e utilizado engenhosamente, a fim de cumprir os prazos do primeiro lançamento e cobrir as principais versões do navegador com testes.

Na Internet, havia poucos artigos sobre teste, desenvolvimento de modelos de teste. Para nossa equipe, naquela época, uma tarefa incompreensível era como criar, onde armazenar e como manter um grande modelo de teste atualizado. Não ficou claro como se livrar dos testes de pesquisa, que poderiam se tornar infinitos, e não havia recursos para o teste sem fim: nem humano nem temporário.

Depois que o GIS foi colocado em operação de teste, e depois na industrial, uma nova tarefa apareceu - lidar com incidentes de usuários. 

Antes da criação de um serviço completo de suporte ao usuário GIS, a equipe de testes recebeu o primeiro êxito das solicitações do usuário, como o mais imerso nos detalhes do sistema, tentando combinar as principais tarefas de teste de novas melhorias, bem como os incidentes de entrada de processo oportunos sobrepostos pelo SLA.

A equipe de teste não encontrou essa tarefa antes. O fluxo de incidentes precisava ser processado, sistematizado, localizado, corrigido, verificado e incorporado ao novo ciclo de liberação. 

O nível de entendimento e maturidade do processo operacional aumentou e melhorou à medida que o próprio sistema cresceu. 

Listei apenas parte dos recursos que a equipe de teste encontrou ao trabalhar com o GIS.

Capítulo 3. Problemas de Teste de SIG e Métodos para Resolvê-los. Recomendações para testar gerentes de equipes.


No processo da equipe de teste trabalhando em vários grandes GIS, criamos recomendações para os gerentes de teste. Posteriormente, eles foram transformados na metodologia do processo de teste de tais sistemas em nosso departamento e continuam a melhorar na solução de novos problemas em projetos de escala semelhante.

O que fazer quando muita funcionalidade?


Não entre em pânico e quebre o funcional em blocos / módulos / funções, conecte o analista à auditoria do resultado, verifique se a visão dos blocos funcionais está correta. 

Recomendamos fazer:

  1. .

    , , , , production. , .
  2. //.

    , , — ,   ///. , , , - , , , / // , , « » , .

O que fazer com matrizes de conhecimento e cobertura de requisitos funcionais?


A funcionalidade não se torna menor. Agora ainda há muito, mas está em uma nova representação (na forma de uma matriz). É necessário determinar quais funções são as mais importantes do ponto de vista comercial e quais não podem ser fornecidas aos usuários em formato bruto. Assim começa a priorização da funcionalidade. Idealmente, se o analista ajudar o testador nisso. No mínimo, ele apreciará a correção das prioridades colocadas pelos testes.

As funções / blocos / módulos mais importantes receberão uma alta prioridade para o teste, os menos importantes serão cobertos pelos testes de segunda prioridade, o restante será o terceiro, ou, se os "prazos chegarem", você poderá adiar o teste por um tempo mais silencioso. 

Assim, temos a oportunidade de testar a funcionalidade que é realmente importante para o cliente. Colocamos as coisas em ordem em um grande número de funções, entendemos o que é coberto pelos testes e o que resta a ser coberto, sabemos que por dentro é necessário fortalecer os testes, em caso de doença / dispensa de testadores responsáveis, entendemos para qual dos testadores as equipes devem passar melhorias no teste (em correspondência com a matriz do conhecimento), que novas funções / módulos / subsistemas interessantes posso oferecer à Vasya, Pete e Lisa condicionais quando estão cansadas de testar a mesma coisa. Ou seja, eu tenho uma ferramenta visual para motivar os testadores que desejam aprender algo novo no projeto.

O que fazer quando os requisitos não suportam o histórico, são confusos, duplicados, como os testadores trabalham com isso?


Recomendamos a implementação do processo de teste de requisitos no projeto. Quanto mais cedo um defeito é descoberto, menor é o seu custo.

Os testadores distribuídos pela matriz do conhecimento, mediante a prontidão das especificações técnicas para o desenvolvimento, começam imediatamente a estudá-las e verificá-las. Para deixar claro para todos que erros existem nos requisitos, foi desenvolvido um conjunto de regras para os analistas “Receita para Requisitos de Qualidade”, segundo as quais eles tentavam escrever requisitos, e modelos de especificações técnicas foram criados para descrevê-los de maneira uniforme. Regras para o formato das especificações técnicas e recomendações para a descrição dos requisitos foram emitidas aos testadores para entender quais erros procurar nos requisitos.

Obviamente, a principal tarefa do testador era encontrar inconsistências lógicas ou momentos inexplicáveis ​​de influência em funções / subsistemas / módulos relacionados que o analista poderia perder. Após detectar defeitos, eles foram corrigidos no bugtracker, atribuído ao autor do requisito, o analista interrompeu o desenvolvimento e / ou conversou com o testador e o desenvolvedor informou que a condição seria alterada de acordo com o defeito (para não desacelerar o desenvolvimento), fazer correções e publicar a versão corrigida requisitos. O testador verificou e fechou o trabalho sobre o defeito, de acordo com os requisitos. Esse procedimento deu à equipe a confiança de que, após algumas semanas de desenvolvimento, o problema detectado definitivamente não surgiria no teste.

Além da detecção precoce de defeitos, recebemos uma ferramenta poderosa para coletar métricas sobre a qualidade do trabalho dos analistas. Tendo estatísticas sobre o número de erros nos requisitos, o analista líder do projeto pode tomar medidas para melhorar a qualidade do trabalho em seu grupo. 

O que fazer quando é necessário realizar testes de carga?


É necessário estudar os requisitos para a carga, apresentar seu modelo, desenvolver casos de teste, coordenar o modelo de teste da carga com o analista e desenvolver scripts de carga com o envolvimento de especialistas competentes no teste de carga. 

Obviamente, você não pode adivinhar a carga com o modelo de teste, mas, para um acerto mais preciso, além do analista, você pode atrair um arquiteto ou especialista em DevOps que, depois de analisar as informações, estatísticas, métricas, possa dizer quais outros casos são necessários no modelo de carga proposto.

Também vale a pena implementar o processo de execução de testes de carga, obtendo os resultados da carga e transmitindo-os aos desenvolvedores para eliminar gargalos.

O processo de carregamento deve ser realizado regularmente antes do lançamento de cada lançamento, altere periodicamente o modelo de carregamento para identificar novos gargalos.

O que fazer quando é necessário realizar testes de integração nos quais não há experiência?


Existem maneiras básicas: por exemplo, você pode fazer cursos avançados de treinamento sobre o assunto dos testes da API Rest, ler artigos na Internet, obter uma troca de experiências com colegas via Skype, com uma demonstração do processo, contratar um especialista que seja bem versado nos testes da API Rest para o grupo de testes. 

Existem muitas maneiras de mergulhar nesse tipo de teste. Um especialista experiente foi contratado em minha equipe, que no futuro treinou a mim e a toda a equipe de testes, desenvolveu manuais: o que procurar ao testar a API Rest, como elaborar um design de teste para verificar a integração, realizou webinars com uma demonstração do processo de teste para toda a equipe. 

Criamos tarefas de teste nas quais todos tiveram a oportunidade de praticar e mergulhar nesse processo. Agora, o material que já foi desenvolvido ao longo dos anos está apenas melhorando, e o processo de aprendizado e mergulho nos testes da API Rest leva de uma a duas semanas, enquanto anteriormente levava um mês ou mais para mergulhar, dependendo da complexidade do projeto e do volume do modelo de teste. 

Fonte

Como não se confundir em ramificações, suportes, implantações de código e testar o código necessário?


Enquanto o GIS está no estágio inicial de desenvolvimento, existem apenas duas ramificações de código: master e release. O segundo é separado no estágio de estabilização para a realização de testes finais de regressão e correção de defeitos pontuais da regressão.

Quando o ramo de release foi enviado para produção e a próxima iteração de desenvolvimento começou, em algum momento decidimos paralelizar o desenvolvimento de novas tarefas para que a tarefa maior planejada através do release pudesse ser concluída a tempo. Em algum momento, havia 3-4 ou mais desses ramos. Existem mais de três postos de teste implantados com o objetivo de iniciar o teste de versões futuras o mais rápido possível.

Os testadores têm certeza de que o especialista em infraestrutura instalado, por exemplo, a revisão nº 10001 em uma das bancadas de teste, executou tudo corretamente e pode iniciar o teste. O especialista em infraestrutura executou a implantação a partir da ramificação do código, informou que o suporte foi implantado, o código foi instalado e pode ser testado.

Iniciamos o teste e entendemos que:

  • existem erros que já foram corrigidos;
  • a funcionalidade do bloco existente difere significativamente da funcionalidade semelhante que fica em outro banco de testes e está se preparando para a próxima liberação planejada, embora não deva haver modificações nele na ramificação do código transferido;
  • começamos a registrar defeitos, os desenvolvedores os devolvem, o holivar começa nos chats de design e descobre o que realmente instalamos e por que não o que esperávamos.

Realizamos uma análise e descobrimos que os desenvolvedores não forneceram ao especialista em infraestrutura instruções sobre a ramificação da qual implantar, o funcionário coletado na ramificação de desenvolvimento e o desenvolvedor conseguiu mesclar apenas parte do código da ramificação de recursos na ramificação de desenvolvimento. 

O testador, que não entendia o gerenciamento da filial, conseguiu a tarefa e um link para o estande, correu para testar, passou algum tempo, teve muitos defeitos, a maioria deles era irrelevante devido a toda essa confusão.

O que fizemos para evitar situações semelhantes no futuro:

  • o desenvolvedor prepara instruções para o especialista em infraestrutura indicando de onde implantar a implantação, a instrução é passada pela tarefa para jira;
  • o especialista em infraestrutura não está confuso e faz o que recebeu;
  • GIT, , jira ;
  • jira : 

  • Gitflow , , hotfixes develop,  .


, ,   ?


Recomendamos que você elabore uma estratégia de teste com antecedência, mas como você perdeu esse ponto, minha experiência provavelmente será útil.

Primeiro, você precisa entender quais navegadores são especificados nos requisitos. Se você já decidiu isso, mas não há tempo, analisamos as estatísticas dos navegadores mais usados, por exemplo, aqui . Em seguida, tentamos acessar três ou cinco dos navegadores mais populares.

Como o projeto é grande e a equipe de testes grande, era fisicamente possível alocar um navegador popular de acordo com as estatísticas para cada testador. Ele conduz seus casos de regressão em uma versão de navegador dedicada; atenção especial deve ser dada ao layout, clicabilidade de botões e links. Esse processo se parece com o seguinte: por exemplo, existem 100 scripts para um teste de regressão, a equipe tem 5 testadores, cada um pode levar 20 scripts para trabalhar, cada um é atribuído a um navegador. Para uma execução de regressão, cada testador verificou seus casos em um dos navegadores. A cobertura no final não está completa, mas como muitos cenários ainda se repetem em um grau ou outro, o percentual de cobertura aumentou devido à passagem de parte dos scripts de regressão por diferentes navegadores. 

Obviamente, isso não forneceu 100% de cobertura de teste de toda a funcionalidade, mas permitiu reduzir significativamente os riscos de defeitos entre navegadores que entraram em produção de acordo com os principais cenários de negócios do sistema.

Além disso, não apenas na regressão, mas também no teste de melhorias e validação de defeitos, realizamos verificações em diferentes navegadores, expandindo a cobertura da compatibilidade entre navegadores.

No futuro, eles começaram a aplicar a abordagem com a distribuição de testadores por navegadores no teste de refinamento, sem aguardar o estágio de teste de regressão, aumentando ainda mais a porcentagem de testes que abrangem diferentes versões de navegadores.

O que temos:

  • custos de teste otimizados, tanto financeiros quanto de tempo, por um intervalo de tempo, verificamos o teste de regressão e o navegador cruzado;
  • , Severity;
  • , , .

?


Muito rapidamente, tivemos uma pergunta sobre a execução de testes em um único repositório, mantendo-os atualizados e sobre a capacidade de executar execuções de teste com marcas no resultado da execução.

A equipe incluiu funcionários com experiência no sistema de gerenciamento de testes TestLink . Este é o único sistema de gerenciamento de caso de teste de código aberto, por isso foi escolhido para funcionar. Em este sistema, uma interface gráfica muito simples e design sem frescuras desnecessárias. Enchemos rapidamente o programa com testes, surgiu a questão de como mantê-lo. Inicialmente, muitos recursos foram gastos na atualização dos casos para cada revisão; essa opção acabou sendo inoperante.

Após consultar o analista e a equipe de teste, decidimos que não era necessário manter sempre um modelo de teste tão grande atualizado devido aos custos de seu suporte. 

Todos os casos foram divididos de acordo com a matriz de requisitos funcionais em pastas, cada módulo / subsistema funcional armazenou um conjunto de casos em uma pasta separada. Isso nos permitiu estruturar visualmente os casos de teste. As palavras-chave foram criadas no TestLink, com a ajuda da qual o caso pertence a um grupo específico, por exemplo:

  • fumaça - usada para casos de teste incluídos no teste de fumaça ( executando um conjunto mínimo de testes para detectar defeitos óbvios de funcionalidade crítica );
  • teste automático - usado para casos de teste pelos quais os autotestes são desenvolvidos;
  • Prioridade 1 - usada para casos de teste relacionados a funções de negócios rotulados como Prioridade 1.

Como resultado, um design de teste é sempre projetado para novas melhorias, como resultado do qual um documento da lista de verificação aparece. Nele, as verificações são priorizadas e apenas parte das verificações se enquadra na “Prioridade 1” ou os casos de teste de fumaça e regressão já foram criados neles no sistema TestLink.

Como sempre ter um modelo de caso de regressão real para uma liberação planejada e um HotFix repentino na produção?


Antes do início do teste de regressão, todo o trabalho preparatório, incluindo a atualização ou adição de novos casos à regressão, foi concluído. E isso significa que, se você executar um caso de teste relevante para o novo release, eles poderão causar defeitos ao verificar o HotFix nesses casos de teste. 

As correções do HotFix foram feitas na ramificação de código antigo (última versão) e as alterações foram feitas no código por correções de defeitos, enquanto os casos de teste atuais poderiam ter sido modificados a partir das melhorias da versão futura. Ou seja, a execução de casos de teste relevantes para uma versão futura pode levar ao registro de defeitos falsos e atrasar a liberação do HotFix.

Para evitar o registro de defeitos falsos e a interrupção dos prazos de teste do HotFix, decidimos usar um mecanismo semelhante à manutenção de ramificações de código. Somente a mesclagem e atualização de casos entre ramificações (leia-se "pastas") do TestLink foram realizadas manualmente pelos testadores de acordo com um determinado algoritmo, enquanto no modelo Gitflow isso é feito automaticamente pelo Git.

Aqui está um conjunto de casos de teste no TestLink:


O processo de atualização de casos no TestLink foi inventado

  • O gerenciador de testes copia a pasta com os casos "Projeto de Teste 1.0.0" e cria um novo conjunto de testes, chamado o número da próxima liberação planejada. Acontece que a pasta com os casos "Projeto de teste 2.0.0".
  • Após estudar as melhorias para uma versão futura, os casos de teste da pasta "Test Project 2.0.0" são analisados ​​quanto à necessidade de atualizá-los para novas melhorias.

Se necessário, atualize os casos:

  • o testador responsável pela revisão faz alterações no caso de teste no conjunto "Projeto de teste 2.0.0";
  • se você precisar excluir um caso de teste, primeiro será necessário movê-lo para a pasta "Excluir", para poder recuperar algum caso de teste excluído acidentalmente ou se os requisitos forem retornados e o caso de teste estiver novamente em demanda (o teste casos apenas da pasta correspondente ao conjunto de testes da futura liberação planejada, na qual esse caso de teste não será relevante);
  • se adicionarmos um caso de teste, isso precisará ser feito apenas na pasta correspondente ao conjunto de testes da futura liberação planejada;
  • casos de teste que mudam são marcados com a palavra-chave "Modificado" (necessário para avaliar a métrica do grau de influência das melhorias na regressão funcional);
  • os casos adicionados são marcados com a palavra-chave "Adicionado" (necessário para avaliar a métrica pelo efeito de melhorias na regressão funcional).

Portanto, sempre temos um conjunto de testes real de casos correspondente à versão anterior do sistema e o usamos para o teste HotFix, além de trabalhar na atualização do novo conjunto de testes, na preparação para testes de regressão e no processo de estabilização da nova liberação planejada. Em algum momento, ao mesmo tempo, 3-4 ramificações de teste (leia-se "pastas") do TestLink, correspondentes a diferentes versões do sistema, podem ser obtidas de uma só vez, o que é especialmente importante ao testar melhorias nas ramificações de recursos.

Após cada release, podemos estimar quanto nosso modelo de regressão mudou, com base nos rótulos "adicionados" / "alterados". 

Se o modelo de regressão aumentar muito, embora o volume de melhorias no release não tenha mudado significativamente em comparação com o release anterior, esta é uma ocasião para pensar sobre a correção de definir prioridades na lista de verificação de verificações de revisão. Talvez o testador tenha feito a escolha errada de casos para recorrer e seja necessário tomar medidas: por exemplo, explique ao testador o princípio da priorização, envolva o analista na priorização, altere o modelo de regressão resultante removendo casos de teste redundantes.

Como o modelo de teste de regressão pode ser otimizado?


Começamos a trabalhar com um modelo de teste de regressão, otimizamos o processo de desenvolvimento de casos de teste de regressão, destacando prioridades e incluindo apenas casos de “Prioridade 1” na regressão. Diante do fato de que o modelo de teste, depois de um tempo, ficou grande, os custos de execução de seus casos aumentaram e paramos de cair no intervalo de tempo aceitável para a realização de um teste de regressão no projeto.

Chegou a hora de implementar a automação de testes, cujo objetivo era:

  • reduzir o tempo para concluir os casos de teste de regressão;
  • use testes automáticos para criar condições prévias para a realização de verificações subsequentes, otimizando o tempo e os custos humanos da criação de dados de teste;
  • melhorar a qualidade dos testes de regressão, eliminando a influência do fator humano nos resultados de um teste manual;
  • , .

Uma estrutura foi desenvolvida para automatizar testes de GUI em Java (o GIT foi usado como um sistema de versão de controle de origem).

Uma equipe de teste automatizada separada esteve envolvida no desenvolvimento de autotestes, que lidaram com êxito com a tarefa. Para projetos futuros de escala semelhante, no futuro, está planejado aplicar os desenvolvimentos existentes e lançar testes automatizados no início do projeto, a fim de se beneficiar do seu uso o mais rápido possível. Você pode ler mais sobre a automação do teste de GIS grande em um artigo de meus colegas diretamente envolvidos na organização e realização de testes automatizados.

Por parte do teste manual funcional, o modelo de regressão também foi otimizado. 

Usando dois SIGs grandes como exemplo, a equipe e eu propusemos e implementamos sessões de teste ou visitas de teste, cuja essência era a seguinte: era necessário analisar o processo de negócios em cada subsistema e refletir sobre a sessão (visita) das verificações que passavam por esse processo de negócios, simulando o máximo Ações do usuário executadas com frequência no processo. 

Em um projeto GIS, isso foi chamado de "sessão de teste"; em outro, foi chamado de "tour de teste". Mas a essência permaneceu a mesma - pensamos no cenário comercial chave de ponta a ponta (durante toda a revisão) que cobre completamente a ideia de negócio da revisão implementada (pode haver vários cenários desse tipo). 

O cenário do tour de teste foi acordado com o analista, foram desenvolvidos casos de teste de regressão detalhados e, nos casos em que eles não conseguiram realizar o teste de regressão em todo o modelo de teste, eles poderiam se limitar a realizar uma "sessão de regressão" ou "tour de teste de regressão", que, por regra, demorou menos tempo e tornou possível entender claramente se há problemas com os principais processos de negócios do sistema.

No futuro, os testes foram cobertos por auto-testes, e os testadores liberados das verificações de rotina passaram para as melhorias nos próximos lançamentos planejados. 
Um exemplo de um tour de teste: “criação, edição, publicação e anulação de uma entidade”. 

Um tour de teste pode ser complicado, por exemplo:

  • conceder direitos para criar, editar e anular,
  • crie uma entidade na "Conta pessoal" do usuário com a função de "Especialista",
  • ,
  • ,
  • ,
  • « » «»,
  • , .

SLA?


Eu recomendo não tratar o processo de localização de incidentes dos usuários como uma tarefa de baixo nível. Você deve considerar isso como parte do processo de teste. Além disso, esse é um processo muito mais criativo do que, por exemplo, verificar casos de teste. É necessário aplicar a lógica, a experiência dos técnicos de projeto de teste, para chegar ao fundo do erro, capturá-lo e transmiti-lo ao desenvolvimento.

Obviamente, é desejável organizar o processo de operação do GIS com três níveis de suporte (idealmente) e, como resultado, os incidentes mais óbvios que geralmente apenas os testadores são capazes de localizar falharão na equipe de teste, que já está filtrada nas duas primeiras linhas.

Para cumprir o SLA, recomendamostorne o processo de localização de incidentes um dever na equipe de teste com a maior prioridade e tente introduzir métodos de otimização para que a velocidade de reprodução do incidente seja a mais alta possível. 

Para otimizar o tempo gasto pelos testadores, você pode:

  • manter uma base de conhecimento do projeto com consultas SQL típicas ou frequentemente encontradas;
  • organizar o processo de classificação das tarefas recebidas no rastreador de erros, para que, no painel indicador, o testador veja imediatamente um incidente caído e o leve a funcionar na primeira prioridade;
  • adicione contadores de tempo de contagem regressiva no JIRA para tarefas que possuem SLAs;
  • configurar um sistema de alerta para incidentes;
  • production ( — ), , , , , , production;
  • « » « ». . 

Sobre a "matriz do conhecimento" foi escrito acima. Quanto à “matriz de responsabilidade”, esta é uma tabela na qual, por analogia com a “matriz de conhecimento”, são gravados blocos / módulos / subsistemas funcionais e qual do grupo de teste é responsável por testar o funcional, como regra, esse é o líder da equipe ou o testador sênior / líder num grupo.

E se o testador de um bloco / módulo / subsistema funcional não entender toda a imagem do processo de negócios no projeto?


Esse é um assunto delicado que encontramos em vários grandes projetos de GIS. A equipe fez uma “matriz de conhecimento”, os testadores realizaram uma autoavaliação do grau de imersão no funcional e se atribuíram à sua parte de funcionalidade. Mas em algum momento, testadores experientes que participaram desde o início do projeto deixaram o grupo e novos especialistas ainda não estavam imersos em todos os processos de negócios e não estavam vendo a imagem completa. Isso levou ao fato de que, ao testar casos em um módulo, os resultados desse caso deveriam ter sido usados ​​no próximo módulo e, como resultado, se resultados incorretos fossem fornecidos à entrada do segundo módulo (as condições prévias não eram ideais para a execução de casos do módulo anterior), era necessário analisar a situação e erros de log.

Mas os testadores não pensaram no motivo pelo qual esses números chegaram à sua contribuição e simplesmente resolveram seus casos. Formalmente, o teste foi realizado, está tudo bem, não foram encontrados defeitos e, quando o analista aceita o funcional ou ao se preparar para os testes de aceitação, são esclarecidos problemas significativos no trabalho de lógica de negócios que foram perdidos no teste. O motivo foi a falta de entendimento do processo de negócios de ponta a ponta executado pelo sistema.

Nessa situação, foi realizado o seguinte:

  • imerso no funcional com o envolvimento do analista;
  • foram realizados treinamentos no grupo de teste, troca de experiências, histórias em comícios sobre seu subsistema e o que está acontecendo nele, discussão de novas melhorias planejadas para o subsistema no próximo release planejado;
  • atrair analistas e introduzir modelos de informações nas especificações de especificação sobre o grau de impacto das melhorias nos módulos / subsistemas de terceiros;
  • a implementação do processo de teste para sessões de teste (tours), que são testadores e as coordena com analistas (ajuda a reduzir os riscos de entender mal o processo de negócios pela equipe e o número de erros de negócios no sistema).

Fuh! Tentei coletar os principais problemas e recomendações para sua eliminação, mas isso está longe de todas as informações úteis que quero compartilhar.

Capítulo 4. Métricas para determinar a qualidade do projeto e a metodologia para avaliar os custos de mão-de-obra para testes


Antes de introduzir a coleção de métricas no projeto, nos perguntamos: "Por que devemos fazer isso?" Os principais objetivos eram monitorar a qualidade da equipe de teste, a qualidade do release produzido em produção e monitorar os indicadores de desempenho dos participantes do grupo de teste para entender como desenvolver a equipe.

Foi realizada uma análise de quais métricas são necessárias para atingir os objetivos. Então eles foram divididos em grupos. Em seguida, eles pensaram sobre o que pode ser medido sem alterações adicionais no processo e onde será necessária a ajuda de outros membros da equipe do projeto.

Quando todas as etapas preparatórias foram concluídas, começou a montagem regular das métricas: uma vez por mês / release / sprint / trimestral - dependendo do projeto e das características do processo de produção.

Depois de coletar as primeiras métricas, foi necessário determinar os indicadores-alvo pelos quais queremos buscar neste estágio do desenvolvimento do projeto. Restou, então, realizar regularmente medições e analisar as razões de seu desvio em relação aos indicadores-alvo, tomar medidas destinadas a melhorar os indicadores, ou seja, otimizar não apenas o processo de teste, mas também todo o processo de produção do projeto.

Obviamente, não apenas os testadores se envolveram na melhoria da qualidade, mas também os analistas e o gerente de desenvolvimento e release na otimização do processo, os engenheiros do DevOps foram todos participantes-chave no processo, pois todos queriam melhorar a qualidade do release e melhorar seu trabalho. 

Um exemplo de como é a coleção de métricas e destinos em um dos projetos concluídos:


Metodologia para avaliar custos de mão-de-obra para testes


Para informar o gerente de projeto sobre prazos mais precisos para a conclusão do teste, com base na coleta de métricas de projetos semelhantes, foi desenvolvida uma metodologia para avaliar o esforço de teste, que permite o relatório mais preciso do tempo de conclusão do teste e notifica sobre os riscos do teste.

Essa técnica é usada em todos os projetos de implementação de GIS; as diferenças podem estar apenas em alguns valores de métricas, mas o princípio de cálculo é o mesmo.

Métricas usadas para executar uma avaliação detalhada dos custos de teste


As métricas de tempo são obtidas por medições repetidas dos custos reais dos testadores de diferentes níveis de competência em diferentes projetos; a média aritmética é obtida.

O tempo para registrar um erro é de 10 minutos (o tempo para registrar um erro no rastreador de erros).
O tempo para validar o erro / refinamento é de 15 minutos (o tempo para verificar a correção da correção de 1 erro / refinamento).
Tempo para escrever 1 TC (caso de teste) - 20 minutos (tempo para desenvolver um caso de teste no sistema TestLink).
Tempo para concluir 1 TC - 15 minutos (tempo para concluir as verificações em um caso de teste no sistema TestLink).
Hora de fazer um teste. O tempo total obtido adicionando os custos na lista de verificação para a coluna "Prazo de entrega, min."
Tempo do relatório de teste - 20 minutos (tempo para escrever um relatório de acordo com o modelo).
Hora de erros . Tempo planejado para registro de todos os erros / esclarecimentos (tempo para registro de 1 erro / esclarecimento * número possível de erros / esclarecimentos (10 erros para revisão - número estimado de erros por revisão)).
Tempo total em DV (validação de defeito) . Tempo planejado para validação de todos os erros / refinamentos encontrados e corrigidos (tempo para validação de 1 erro / refinamento * número estimado de erros / refinamentos).
Preparação de dados de teste. O tempo para preparar dados de teste é calculado subjetivamente com base na experiência de testar tarefas semelhantes no projeto atual, dependendo de vários parâmetros (o escopo da tarefa do ponto de vista do analista de teste, as competências da equipe de desenvolvimento de código (nova equipe desconhecida ou equipe testada para a qual existem estatísticas sobre a qualidade do trabalho) , integração entre diferentes módulos etc.).

Medindo os custos reais de um dos projetos, foi calculado o seguinte: 

  • não mais de 1 hora por tarefa até 60 horas de desenvolvimento,
  • não mais de 3 horas por tarefa até 150 horas de desenvolvimento,
  • não mais de 4 horas por tarefa até 300 horas de desenvolvimento.

Em casos especiais, os custos planejados para a preparação dos dados do teste podem mudar de acordo com o gerente do teste.
 
Hora de escrever o TC . O tempo para escrever o TC, estimado após a lista de verificação estar pronto para inspeção e priorização para teste. Para o teste de regressão, os TCs foram marcados com Prioridade 0 (o número de verificações de prioridade 0 * 20 minutos (tempo de gravação para 1 TC)).
Hora de regredir de acordo com o TC. Tempo para concluir uma iteração do teste de regressão de acordo com o TC no sistema TestLink (número de TC * tempo médio de execução de 1 TC (15 minutos)). 
Riscos 15% do tempo para o teste é estabelecido (riscos significam todas as operações manuais, quedas de suporte, problemas de bloqueio etc.). 
Tempo total para teste.O custo total do teste para um HL (preparação dos dados do teste + execução do teste + tempo para registrar erros / esclarecimentos + validação de erros / aperfeiçoamentos + tempo para regredir de acordo com a Prioridade TC 0 + riscos) em h / h.
Tempo total para a tarefa. Custos totais para toda a tarefa de teste, figura em h / h (tempo total para teste + tempo para relatório + tempo para escrever o TC).

Todas essas métricas são usadas no projeto para resolver várias tarefas relacionadas ao planejamento, avaliações de trabalho, temporárias e financeiras. Como a prática demonstrou, essa estimativa gera um erro mínimo (não superior a 10%), que é um indicador bastante alto da confiabilidade da estimativa.

Obviamente, você não pode usar nenhuma métrica ou suas métricas de acordo com as estatísticas podem diferir bastante, mas o princípio de estimar o custo do trabalho de teste pode ser aplicado a qualquer projeto e escolher a melhor fórmula de cálculo para seu projeto e equipe.

Capítulo 5. Receita para um processo bem-sucedido de teste de GIS


É importante mostrar aos gerentes de teste e testadores que, diante de dificuldades e novas tarefas, é possível encontrar soluções, otimizar o processo de teste e tentar aplicar a experiência acumulada para projetos futuros. 

Preparei surpresas para todos os leitores - uma receita para um processo de teste GIS bem-sucedido e modelos de documentos que você pode baixar e usar em seus projetos.
Portanto, a receita de como fazer com que o processo de teste de um grande sistema de informações seja bem-sucedido e o que recomendamos incluir nesse processo, tentarei indicá-lo de forma breve e concisa.

No processo de análise:

  • Implementar modelos de requisitos técnicos
  • implementar as regras para o desenvolvimento de requisitos técnicos em um grupo de analistas;
  • desenvolver um regulamento sobre a notificação da prontidão dos requisitos técnicos da equipe do projeto.

:

  • - ;
  • ;
  • ;
  • :

    ○ - ;
    ○ -;
    ○ ;
  • , , , , , ;
  • , , , , ;
  • ;
  • ;
  • ;
  • ;
  • (, , ..);
  • , , ;
  • use as recomendações de colegas mais experientes, desenvolvimentos de outros projetos, folhas de dicas prontas , realize sessões de brainstorming com a equipe e procure novos métodos para otimizar e melhorar o processo.

Agora estou me preparando para testar o novo GIS. É assim que minha Wiki de trabalho se parece, que já leva em consideração muitos pontos que recomendamos:


Surpresa para os pacientes.


Se você ler o artigo até o fim, você merece um presente. Quero compartilhar com você modelos úteis que você pode usar em seu trabalho:


Espero que nossas recomendações, exemplos, idéias, links e meus modelos ajudem muitas equipes a desenvolver com competência o processo de teste, otimizar seus custos e lidar com sucesso com as tarefas de um projeto responsável e complexo. 

Se você deseja ingressar na equipe de testes da LANIT e participar dos testes de SIG, aconselho que você veja as vagas de nossa empresa.

Venha para as nossas escolas de testes!
, , .


Desejo a todos os projetos interessantes e boa sorte!

PS Realmente implora para realizar uma pequena pesquisa. 

More articles:


All Articles