Test Management Domain Model

Se algum dia você precisou acessar dados sobre testes no TFS ou VSTS para montar um relatório ou para acessar via API, seja através de Client Object Model ou Rest API, com certeza demorou algum tempo para entender o conceito e o relacionamento das entidades envolvidas.

Mesmo já tendo feito isso algumas vezes, toda vez que preciso acessar essas informações gasto algum tempo para lembrar de todos os detalhes. Por esse motivo, resolvi desenhar um modelo de domino, baseado nas informações que temos na API Rest para facilitar as próximas vezes que eu precisar fazer isso. Espero que seja útil para vocês também.

Quando pensamos na disciplina de teste para desenvolvimento de software, independente de framework ou processo específico, algumas entidades sempre estão presentes:

  • Caso de Teste: é a descrição e/ou especificação do teste. O passo a passo necessário para se executar um teste;
  • Suite de Teste: é um agrupamento de casos de testes, normalmente relacionados a algo que faça sentido para organização de um Plano de Teste;
  • Plano de Teste: é um planejamento de execução de Casos de Testes em um determinado período (iteração, sprint, etc);
  • Execução de Testes: é a execução de algum Caso de Teste, ou de todo um Plano de Testes. Dentro de um Plano, um mesmo Caso de Teste pode ser executado diversas vezes, normalmente tantas vezes quanto necessário para que o teste "passe" com sucesso;
  • Resultado de Teste: é o resultado da execução de um caso de teste (Falha, Sucesso, etc).

Dessas definições é preciso perceber algo importante: o Caso de Teste é uma especificação independente de qualquer outra dessas entidades. Ele é um "documento" assim como um Requisito, uma User Story ou Item de Backlog, etc... O Caso de Teste é a definição de como executar um teste, mas ele não é o teste em si. Pensando como um desenvolvedor, o Caso de Teste é a classe, e o teste é uma instância dessa classe.

Por que estou ressaltando tanto isso??? Porque isso implica que um Caso de Teste existe independente de Suite de Teste e, principalmente, independente de Plano de Teste, e na interface web do TFS/VSTS isso não fica tão claro, pois ela está direcionada a um processo que se inicia no planejamento. Se você procurar na documentação verá que ela direciona você a criar um Caso de Teste de dentro de um Plano ou Suite. Mesmo na opção de criar o Caso de Teste a partir do kanban board ele cria o Caso de Teste dentro de um Plano.

Tudo bem que para executar um Caso de Teste, é preciso criar um Plano e tudo mais... Mas para criar o Caso de Teste, você não precisa do Plano, nem da Suite. No TFS/VSTS é possível criar um Caso de Teste "descolado", basta criar um workitem do tipo Caso de Teste, em qualquer lugar que permita criar workitems:

Enfim, existem processos e frameworks de qualidade/testes que vão dizer a melhor maneira/momento de se criar os Casos de Testes... não estou entrando nesse mérito, estou apenas tentando entender como essas entidades se relacionam para poder montar relatórios :-). Entender essa natureza independente do Caso de Teste, é a chave para o entendimento de todo o relacionamento.

Entendido de maneira geral quais entidades estão envolvidas na disciplina de testes, vamos ver agora como o TFS/VSTS implementa essas entidades.

Já vimos por alto como a interface web trata algumas dessas entidades, e se fôssemos nos guiar exclusivamente por ela iríamos nos confundir um pouco, principalmente em relação ao Caso de Teste. Vamos então recorrer a algumas documentações.

Para quem trabalha com o TFS, existe a alternativa de utilizar as bases relacional de relatórios (TFS_Warehouse) e analítica. A documentação dessas duas bases explica bem os relacionamentos pré-definidos entre as entidades que elas expõem (métricas e dimensões relacionadas a testes). Porém se você quiser fazer algo diferente ao que está pronto (nova métrica, dimensão, ou uma query diferente entre as tabelas...), vai começar a ver nos relacionamentos das tabelas algumas chaves estrangeiras que referenciam entidades como "Points" que não estão descritas na documentação.

Vamos então recorrer a documentação da API REST, já que a documentação da Client Object Model é basicamente uma referência de classes sem relacionamento entre si. Considerando a API de testes, vemos na documentação uma descrição bem melhor das entidades que envolvem a parte de testes:

  • Test Cases (Casos de Teste): descreve os passos necessários para se executar um teste;
  • Test Suite (Suite de Teste): são grupos de casos de teste;
  • Test Plan (Plano de Teste): são coleções de Suites de Teste que precisam ser executadas em uma específica iteração;
  • Test Point (Pontos de Teste): é o pareamento entre casos de teste com suas configurações, que precisam ser executados para um plano (??);
  • Test Run (Execução de Teste): consiste de um conjunto de pontos de teste.
  • Test Result (Resultado de Teste): é o resultado de executar um teste dentro de uma execução de teste.

E seu relacionamento está expresso no seguinte diagrama:

Porém, ao navegar pela API, encontramos outras entidades como Suite Entries (que não está no diagrama) e Configuration, que são essenciais para melhor entender o relacionamento entre essas entidades.

Navegando pelo Test Hub, analisando os dados de request e response da API REST, e olhando por alto a base de dados relacional da Collection e também de relatorios (TFS_Warehouse), cheguei ao seguinte diagrama:

Baseado nesse modelo podemos chegar as seguintes conclusões:

  • Casos de Testes existem independente de Suites e Planos (como já foi dito), e elas se associam a Suites através da entidade Suite Entries, que é simplestemente uma entidade de relacionamento;
  • Ao executar um Caso de Teste, posso executá-lo em diferentes configurações de ambiente (sistema operacional, web browser, hardware, rede, etc). Essas configurações poderiam ser pré-condições dentro do próprio Caso de Teste, mas o TFS/VSTS normaliza essas informações na entidade Configuration, uma entidade que registra as configurações de ambiente para as quais um teste foi/será executado;
  • Points ou Test Points (Pontos de Testes) são de fato as instâncias dos Casos de Testes. Eles associam o Caso de Teste a uma Suite, uma Configuração (Configuration) e ao último Resultado de Teste (se houver). O que visualizamos organizados dentro do Plano e das Suites na interface Web do TFS/VSTS são Test Points, e não Casos de Teste. Note que quando um teste é executado seu último resultado aparece nessa tela, o Caso de Teste não possui o resultado, apenas o Test Point. Quando atribuímos configurações diferentes a um Caso de Teste, o mesmo é exibido "replicado", um para cada configuração. Na verdade, são Test Points que foram criados, instanciando um Caso de Teste para cada uma das configurações.
  • Por último, as Execuções de Teste existem sempre no contexto de um Plano de Testes. E o produto delas são os Resultados de Teste para cada Caso de Teste executado. Não existe uma ligação direta entre Execução de Teste e Caso de Teste. Eles estão relacionados através de um Resultado de Teste.

Apesar de estar bem próximo aos dados exposto pela API REST, este modelo está longe de ser um modelo de dados. Basta consultar a base de dados do TFS que você irá entender o que estou falando. O propósito é ser apenas um modelo de domínio com a intenção de facilitar o entendimento das entidades e seu relacionamento. Espero que realmente o ajude a entender melhor os dados relativos a testes no TFS/VSTS. Se você perceber alguma falha nesse modelo, ou tiver alguma crítica a fazer, por favor faça seu comentário.

Para finalizar gostaria de fazer uma observação: quem trabalha no VSTS e quer fazer algum relatório customizado envolvendo dados de Teste (além desses), a única alternativa no momento é consultar/exportar os dados via API REST e criar os relatórios em alguma ferramenta como Excel ou PowerBi.

Porém, existe um serviço de dados analíticos que está atualmente em preview interno, o Analytics Services, que irá suprir toda a carência de dados para relatórios dos usuários do VSTS. Apesar de, por enquanto, os dados de testes ainda não fazerem parte das entidades disponíveis, provavelmente estarão disponíveis quando o serviço for liberado para todos.