Introdução
Em muitos projetos com os quais trabalhei, as pessoas não personalizaram o TestRail para si mesmas e se contentaram com configurações padrão. Portanto, neste artigo tentarei descrever um exemplo de configurações individuais que podem ajudá-lo a melhorar a eficiência do seu trabalho. Por exemplo, vamos pegar um projeto de desenvolvimento de aplicativo móvel.
Um pequeno aviso. Este artigo não contém uma descrição da funcionalidade básica do TestRail (há muitos guias sobre isso) e expressões de vendas que descrevem de forma colorida por que você precisa escolher esse fornecedor específico para criar um repositório com testes.
Plano de justificação (o que será implementado)
Requisitos gerais
Absolutamente qualquer um deveria ser capaz de passar no caso.
Os casos devem permanecer relevantes pelo maior tempo possível
Os casos devem abranger a funcionalidade da aplicação móvel tão detalhadamente quanto possível, na medida em que isso não contradiga os dois primeiros pontos
Dividir em TestCase e TestScenario
Geração rápida de TestRun de vários tipos
Fumo
Regressar
Testes de impacto, etc.
Otimização de suporte de caso
Abandonando capturas de tela codificadas “mortas” e mudando para “dados móveis”
Requisitos
Para editar campos você precisará de acesso de administrador
Selecionando um tipo de projeto
Existem três tipos de projetos para escolher:
Selecionaremos o tipo padrão. Todos os casos estarão disponíveis nele ao mesmo tempo. Usaremos filtragem inteligente e gerenciaremos dinamicamente todos os casos de uma só vez.
Adicionando campos para visualizar uma lista de casos de teste
Vamos adicionar um campo para exibir casos de teste prioritários:
Você também pode adicionar outros campos.
Configurando campos e tags de caso de teste
Abra o menu de configurações:
Precisaremos dos seguintes campos:
Campo “Resumo” (cabeçalho do caso de teste)
Esse campo já existe, estamos apenas sistematizando seu uso. Dividiremos os casos em TestCase e TestScenario. Para melhor legibilidade de uma grande lista de casos, é melhor combinar antecipadamente as regras para redigir um resumo.
Cenário de teste:
Exemplo: TestScenario – Cenário básico para usar um aplicativo móvel
Caso de teste:
Exemplo: MainScreen - Seção de autorização - Insira o login
No total, vemos no resumo do caso o entendimento clássico: “o quê, onde, quando”. Também separamos visualmente os scripts de teste de alto nível e os casos de teste de baixo nível na forma mais adequada para automação.
Tag “StartScreen” (a tela na qual TestScenario começa; além disso, muitos casos de teste podem tocar em telas adjacentes)
Para o que pode ser necessário: retiraremos do texto o texto dos passos típicos dos casos que levam o usuário à tela do caso de teste atual. (etapas típicas para criar uma situação de teste específica) Todas as etapas típicas para todos os casos de teste serão gravadas em um arquivo. Escreverei sobre isso com mais detalhes separadamente.
Crie um novo campo:
Preencha os componentes do novo campo:
Neste caso, estamos criando um campo de seleção a partir de uma lista de valores. Insira os valores deste campo:
Observe que os valores de id não começam com um e não são consecutivos. Por que isso é feito? A questão é que se tivermos casos de teste com o ID inserido registrado,
e depois precisaremos criar uma terceira tela entre as duas existentes,
então teremos que reescrever o id e, como as tags dos casos de texto existentes já estão anexadas a ele, elas serão simplesmente excluídas. Será muito desagradável.
Tag “Tela” (nome da tela que afeta o TestCase)
O que você pode precisar: uma das âncoras para testes de impacto. Por exemplo, os desenvolvedores criaram um novo recurso interessante. Precisamos testá-lo, mas para isso precisamos entender o que exatamente esse recurso pode afetar. Por padrão, podemos partir do paradigma de que diferentes telas (Atividades) de uma aplicação possuem classes diferentes e portanto constituem diferentes componentes da aplicação. Claro, neste caso é necessária uma abordagem individual.
Exemplo: home_screen, MapScreen, PayScreen, etc.
Campo “MovableData” (link para um banco de dados proxy com dados de teste alteráveis)
A seguir, tentaremos resolver o problema de manutenção da relevância dos dados nos casos de teste:
Links para layouts atuais (isso é muito melhor do que tirar capturas de tela mortas)
Etapas típicas para chegar à tela com uma situação de teste
Consultas SQL
Links para dados externos e outros dados
Em vez de escrever dados de teste dentro de cada caso de teste, criaremos um arquivo externo e vincularemos a ele todos os casos de teste. Ao atualizar esses dados, não teremos que passar por todos os casos de teste e alterá-los, mas será possível alterar esses dados em apenas um local. Se alguém despreparado abrir um caso de teste, ele verá no corpo do caso de teste um link para um arquivo e uma dica de que precisa acessá-lo para obter dados de teste.
Compactaremos todos esses dados em um arquivo externo, que estará disponível para todos no projeto. Por exemplo, você pode usar o Planilhas Google ou Excel e configurar uma pesquisa dentro do arquivo. Por que esses fornecedores específicos? O fato é que partimos do paradigma de que qualquer pessoa da equipe deve ser capaz de abrir e passar em um caso de teste sem precisar primeiro instalar nenhuma ferramenta.
Para Folha do Google você pode usar consultas SQL. Exemplo:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Para Excel Você pode configurar macros de pesquisa instantânea convenientes. (filtragem) Exemplo .
Na verdade, a ideia não é nova e está descrita no livro do primeiro testador “Testing dot com”. (autor Savin Roman) Estamos apenas integrando os métodos propostos por Roman Savin no TestRail. Para isso, crie um campo com um link para o arquivo criado:
preencha o valor padrão do link para que cada novo caso de teste já possua um link:
Se a localização do arquivo externo for alterada (fornecemos para qualquer caso de força maior), você poderá alterar convenientemente um ou mais campos de uma só vez em todos os casos de teste:
Campo “Descrições” (descrição ou ideia de um caso de teste, instruções padrão)
O que você pode precisar: Neste campo de texto colocaremos uma breve descrição do caso de teste e instruções padrão.
Exemplo: Todos os dados de teste (layouts atuais, uso de ferramentas e outros dados) deste caso de teste são indicados por links {...} e estão localizados no arquivo MovableData. Link para MovableData no campo correspondente na parte superior.
Tag “Componente” (componente de aplicativo móvel)
Para que pode ser necessário: para testes de impacto. Se um aplicativo móvel puder ser dividido em componentes (que afetam uns aos outros o mínimo possível), então as alterações em um componente serão suficientes (com alguns riscos) para serem verificadas dentro do mesmo componente, e haverá menos motivos para realizar regressões gerais de tudo. Se houver informações de que um componente pode afetar outro, uma matriz de testes de impacto será compilada.
Componentes de exemplo: GooglePay, Pedido, Usuários, Mapa, Autorização, etc.
Tag "TAG" (outras tags para filtragem)
Marcando um caso de teste com tags para filtragem arbitrária.
Muito útil para:
compilar rapidamente TestRun para várias tarefas típicas: fumaça, regressão, etc.
os testes serão automatizados ou já automatizados?
quaisquer outras tags
Exemplo: Smoke, Automated, WhiteLabel, ForDelete, etc.
Configurando a ordem de exibição dos campos no caso de teste
Criamos muitos campos novos, é hora de organizá-los em uma ordem conveniente:
Criando TestRun
Agora criaremos um novo teste com casos atuais para a realização de testes de fumaça em três cliques:
Outras dicas
Se TestRail tiver vários projetos, não se esqueça de criar novos campos apenas para o seu projeto, caso contrário, colegas de equipes vizinhas ficarão muito surpresos com o surgimento de novos campos incomuns. O desmaio local é possível.
2. Casos com um grande número de campos são mais fáceis de copiar de um tipo de grupo semelhante do que criar novos:
3. As contas podem ser compartilhadas. Por exemplo: um administrador, vários usuários.
Conclusão
Os exemplos descritos acima foram implementados em vários projetos e demonstraram a sua eficácia. Espero que eles ajudem a melhorar sua compreensão desta ferramenta e a criar “armazenamentos de teste” eficazes e convenientes. Ficaria muito grato se você descrevesse sua experiência de uso do TestRail e dicas úteis nos comentários.
Links:
Livro:
Muito obrigado pela sua atenção!
Fonte: habr.com
