Introdução
Em muitos projetos nos quais trabalhei, as pessoas não configuravam o TestRail de forma personalizada e usavam as configurações padrão. Portanto, neste artigo, vou tentar descrever um exemplo de configurações individuais que podem ajudá-lo a aumentar a eficiência do seu trabalho. Para exemplificar, vamos considerar um projeto de desenvolvimento de aplicativo móvel.
Um pequeno disclaimer. Este artigo não descreve as funcionalidades básicas do TestRail (há muitos guias para isso) nem contém expressões de vendas que descrevem coloridamente por que você deve escolher este fornecedor para criar um repositório de testes.
Plano de justificativa (o que será implementado)
Requisitos gerais
Qualquer pessoa deve ser capaz de passar pelo caso
Os casos devem manter sua relevância pelo maior tempo possível
Os casos devem cobrir o máximo possível a funcionalidade do aplicativo móvel, na medida em que isso não contradiga os dois primeiros pontos
Divisão entre TestCase e TestScenario
Geração rápida de TestRun de diferentes tipos
Smoke
Regressão
Teste de impacto, etc.
Otimização do suporte aos casos
Abandono de capturas de tela 'mortas' codificadas e transição para 'dados móveis'
Requisitos
Para editar os campos, você precisará de acesso administrativo
Seleção do tipo de projeto
Três tipos de projeto podem ser escolhidos:
Vamos escolher o tipo padrão. Nele, todos os casos estarão disponíveis ao mesmo tempo. Usaremos filtragem inteligente e gerenciaremos todos os casos ao mesmo tempo de forma dinâmica.
Adicionando campos para visualizar a lista de casos de teste
Vamos adicionar um campo para exibir a prioridade dos casos de teste:
Outros campos também podem ser adicionados.
Configuração de campos e tags do caso de teste
Abrindo o menu de configuração:
Precisaremos dos seguintes campos:
Campo 'Resumo' (cabeçalho do caso de teste)
Este campo já existe, apenas sistematizaremos seu uso. Vamos dividir os casos em TestCase e TestScenario. Para melhor legibilidade de uma longa lista de casos, é melhor acordar um regulamento sobre como escrever o resumo.
TestScenario:
Exemplo: TestScenario — Cenário principal de uso do aplicativo móvel
TestCase:
Exemplo: MainScreen — Seção de login — Entrada do nome de usuário
Assim, vemos no resumo do caso a compreensão clássica: “o que, onde, quando”. Também visualmente, dividimos os cenários de teste de alto nível dos casos de teste de baixo nível da forma mais adequada para automação.
A tag "StartScreen" (the screen from which the TestScenario begins, and many test cases may affect neighboring screens)
Purpose: we will remove from the text of the test cases standard steps that lead the user to the screen of the current test case. (standard steps to create a specific testing situation) All standard steps for all test cases will be written in one file. I will write more about it separately.
Creating a new field:
Filling in the components of the new field:
In this case, we are creating a selection field from a list of values. We enter the values for this field:
Note that the IDs of the values do not start from one and do not go sequentially. Why was this done? The reason is that if we have test cases recorded with the entered IDs,
and after that, we need to create a third screen between two existing ones,
we will have to rewrite the IDs, and since the existing test cases are already linked to these IDs, they will simply be deleted. This would be very unpleasant.
A tag "Screen" (the name of the screen affected by the TestCase)
Purpose: one of the anchors for impact testing. For example, developers created a new cool feature. We need to test it, but in order to do so we need to understand what exactly this feature could have affected. By default, we can rely on the paradigm that different screens (Activities) of the application have different classes and therefore make up different components of the application. Of course, in this case, an individual approach is needed.
Example: home_screen, MapScreen, PayScreen, etc.
Field "MovableData" (link to a proxy database with variable test data)
Next, we will try to solve the problem of maintaining the relevance of data in test cases:
Links to current layouts (this is much better than doing dead screenshots)
Standard steps to the screen with the test situation
SQL queries
Links to external data and other data
Em vez de inserir dados de teste dentro de cada caso de teste, criaremos um único arquivo externo e faremos referência a ele em todos os casos de teste. Ao atualizar esses dados, não precisaremos percorrer todos os casos de teste para modificá-los, pois poderemos alterar esses dados apenas em um lugar. Se alguém não familiarizado abrir um caso de teste, verá no corpo do caso de teste um link para o arquivo e uma dica para consultá-lo em busca de dados de teste.
Todos esses dados serão organizados em um único arquivo externo, que estará disponível para todos os interessados no projeto. Por exemplo, pode-se usar Google Sheet ou Excel e configurar uma pesquisa dentro do arquivo. Por que esses fornecedores em particular? O fato é que partimos do princípio de que qualquer membro da equipe deve ser capaz de abrir e passar pelo caso de teste sem a necessidade de instalar ferramentas previamente.
Para Google Sheet é possível usar consultas SQL. Exemplo:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"Para Excel é possível configurar macros de busca instantânea convenientes. (filtragem) Exemplo .
A ideia em si não é nova e está descrita no primeiro livro do testador 'Testando dot com'. (autor Roman Savin) Nós apenas integramos as metodologias sugeridas por Roman Savin no TestRail. Para isso, criaremos um campo com um link para o arquivo criado:
preenchemos o valor padrão do link, para que em cada novo caso de teste já haja um link:
Se a localização do arquivo externo mudar (prevemos qualquer força maior), podemos facilmente alterar um ou mais campos em todos os casos de teste de uma só vez:
Campo 'Descriptions' (descrição ou ideia do caso de teste, instruções típicas)
Para que pode ser necessário: Neste campo de texto, colocaremos uma breve descrição do caso de teste e instruções típicas.
Exemplo: Todos os dados de teste (modelos atuais, uso de ferramentas e outros dados) deste caso de teste estão designados por links {…} e estão no arquivo MovableData. O link para o MovableData está no campo correspondente na parte superior.
Tag 'Component' (componente do aplicativo móvel)
Para que pode ser necessário: para testes de impacto. Se o aplicativo móvel pode ser dividido em componentes (que afetam o mínimo uns aos outros), então as alterações em um componente serão suficientes (com alguns riscos) para serem verificadas dentro desse mesmo componente, reduzindo a necessidade de realizar testes de regressão gerais. Se houver informações de que um componente pode afetar outro, é elaborada uma matriz de testes de impacto.
Exemplo de componentes: GooglePay, Pedido, Usuários, Mapa, Autorização, etc.
Tag "TAG" (Outras tags para filtragem)
Marcação de casos de teste com etiquetas para filtragem arbitrária.
Muito útil para:
criação rápida de TestRuns para várias tarefas típicas: smoke, regressão, etc.
se os testes serão automatizados ou já estão automatizados
qualquer outra tag
Exemplo: Smoke, Automatizado, WhiteLabel, ParaExcluir, etc.
Configurando a ordem de exibição dos campos no caso de teste
Criamos muitos novos campos, chegou a hora de organizá-los de forma conveniente:
Criação de TestRun
Agora criaremos um novo test run com os casos atualizados para realizar testes de smoke em três cliques:
Outras dicas úteis
Se houver vários projetos no TestRail, não se esqueça de criar novos campos apenas para seu projeto, caso contrário, os colegas de equipes vizinhas ficarão muito surpresos com a adição de novos campos incomuns. Possíveis desmaios locais.
2. Casos com um grande número de campos são mais fáceis de copiar de um grupo similar do que criar novos:
3. É possível usar contas em conjunto. Por exemplo: uma conta de administrador e várias contas de usuário.
Conclusão
Os exemplos descritos acima foram implementados em vários projetos e mostraram sua eficácia. Espero que ajudem a melhorar sua compreensão dessas ferramentas e ajudem a criar "test storages" eficazes e convenientes. Fico muito grato se você compartilhar sua experiência de uso do TestRail e dicas úteis nos comentários.
Links:
Livro:
Muito obrigado pela atenção!
Fonte: habr.com
