Questão:
Ferramenta simples de gerenciamento de caso de teste com detalhes de execução de teste
The Godfather
2017-10-27 20:30:45 UTC
view on stackexchange narkive permalink

Em minha equipe, estamos tentando selecionar algum sistema de gerenciamento de caso de teste para usar. Nossos requisitos não são ciência de foguetes, eu acredito:

  • Simples o suficiente para armazenar casos de teste e resultados de execução. Não há necessidade de defeitos integrados e gerenciamento de requisitos.
  • Algumas APIs para importar resultados de execução de teste automatizado (seria ótimo, se houver plugin Jenkins)
  • Devido à segurança , é necessária a possibilidade de instalar em nosso próprio hardware, também conhecido como "local".
  • E a parte mais importante, estou ficando realmente desesperado com isso, pois já experimentei quase todos os TCMS "populares" e eles não têm realmente nada aqui. Campos personalizados para cada execução de teste . O que quero dizer - muitas vezes a ideia no TCMS existente é "Plano de teste com casos de teste - Execução de teste - Execução de caso de teste". Portanto, você tem alguma entidade chamada "Execução de teste", que é um grupo de testes a serem executados. Se você tiver sorte o suficiente, há suporte para algumas coisas personalizadas para execução de teste (ou seja, configurações de ambiente - sistema operacional, navegador, hardware). Portanto, parece que muitas equipes estão felizes com a criação de testes de "teste do Windows Chrome", "teste do Linux Firefox" e assim por diante. Mas em nossa equipe não é aceitável, porque preferimos ver "teste da versão A do produto" e uma tabela de execuções de teste com parâmetros diferentes. Portanto, cada "linha" na tabela - caso de teste + configurações de ambiente + status + links de bug. Obviamente, os casos de teste podem ser duplicados, porque podemos executar um caso de teste em 5 * 5 * 5 (ou seja, 5 sistemas operacionais, 5 navegadores e 5 versões de biblioteca externa que estamos usando) em ambientes diferentes. Não é viável criar 5 * 5 * 5 execuções de teste!

Veja a captura de tela com algumas coisas do Excel, provavelmente vai explicar mais facilmente do que meu texto longo: Existing systems Desired behavior

Apenas os sistemas que vi no último marcador são o TestPad (que é principalmente uma lista de verificação sem nenhuma funcionalidade inteligente) e o HP-ALM (que é antigo, feio e lento). Todo o resto permite que você tenha apenas os campos "comentário" e "bugs" para a entidade de execução de teste.

Então, minhas perguntas são:

  1. Você encontrou o mesmo problema em sua equipe? Como você finalmente conseguiu?
  2. Você poderia aconselhar a mim e a minha equipe algo que possamos usar?

P.S. Algumas das ferramentas que experimentei até agora: Zephyr for Jira, HP ALM, Kiwi, qTest, TestCaseLab, practiTest, TestPad

OK eu vejo. Atualizarei minha resposta quando voltar para casa no PC. Ou você não tem tantos testes ou deve ser horrível gerenciá-los assim no Excel. Acho que minha ferramenta de relatório tem os recursos de que você precisa.
@ThomasWeller é claro que não estamos fazendo isso no Excel, é apenas para mostrar o problema e minha visão de solução. Pode ser um site com bons relatórios da web 3.0 e Ajax e bla-bla, não importa. O que importa é a abordagem e mapeamento para a situação real.
Adicionei fotos da ferramenta de gerenciamento de teste.
Trzy respostas:
Scott
2017-11-02 16:19:29 UTC
view on stackexchange narkive permalink

Eu gostaria de sugerir TestLodge, que é uma ferramenta que ajudei a desenvolver.

Em termos de seus requisitos:

  1. A ferramenta foi projetada para ser simples e fácil de usar. Não temos uma grande quantidade de recursos como outras ferramentas antigas, apenas o essencial.
  2. Nossa API REST pode ser usada para integrações automatizadas, embora não tenhamos qualquer integração pré-construída com Jenkins. (Estamos mais focados em testes manuais.)
  3. Fornecemos a capacidade de criar configurações de teste, que é onde você definiria seus navegadores / sistemas operacionais. Todos os casos de teste selecionados para execução seriam incluídos várias vezes na mesma execução para cada configuração selecionada. Temos um vídeo de demonstração rápido de 3 minutos e a segunda parte mostra como criar uma corrida e definir essas configurações. Resumindo, você terminaria com uma execução, mas com todas as configurações de ambientes diferentes dentro dela.

Também recomendo dar uma olhada em nossas integrações de rastreador de problemas > que permitiria a você criar um tíquete automaticamente em uma ferramenta de gerenciamento de defeitos sempre que um teste falhar. Aqui está outro vídeo mostrando como funcionam as integrações mais recentes. Isso pode economizar muito tempo para o testador!

Você oferece suporte para instalação local? Esqueci de mencionar no começo ... Apesar de sua ferramenta também se fiar em "rodadas de teste" como base, a primeira impressão é boa, leve e fácil de usar, não há necessidade de duplicar execuções de teste manualmente com esse material de ambiente.
@TheGodfather TestLodge é apenas uma ferramenta hospedada e não oferecemos nenhuma opção de auto-hospedagem, desculpe.
Umair Altaf
2019-06-03 11:01:51 UTC
view on stackexchange narkive permalink

Portanto, trabalho para uma empresa que possui sua própria ferramenta de gerenciamento de testes chamada " Kualitee". Temos outras empresas que estão usando a ferramenta, como Emirates, Cox Enterprises, T-Mobile, etc. O que você mencionou é algo que também passamos ao fornecer serviços para nossa clientela, mas felizmente já percorremos um longo caminho.

Então, Kualitee é uma ferramenta baseada em nuvem que suporta testes manuais e automatizados. Você pode gerenciar seus requisitos, casos de teste, execuções e rastreamento de problemas, tudo sob o mesmo capô. Possui integrações com JIRA, Selenium, Jenkins e Bitbucket. As APIs também estão disponíveis para todos os módulos da ferramenta para qualquer tipo de integração customizada.

Também fazemos todos os nossos relatórios no Kualitee, onde você é capaz de gerar relatórios de teste, bug e execução personalizados (com defeitos associados, etc.). Você obtém rastreabilidade completa de seus casos de teste e defeitos para o requisito subjacente e para a construção.

A ferramenta em si é uma versão mais simples do HP ALM.

Espero que isso tenha sido útil para vocês experimentarem. Ele também tem um modelo freemium.

The Godfather
2019-06-03 23:51:18 UTC
view on stackexchange narkive permalink

Em 2017, verificamos as soluções existentes e acabamos usando o Kiwi TCMS, que é um aplicativo Django de código aberto baseado na solução Nitrate antiga.

As principais vantagens que gostamos:

  • Aplicativo Python / Django gratuito com código aberto, para que possamos estender e personalizar de acordo com nossas necessidades internas.
  • Atividades recentes no Github (isso foi no final de 2017, hoje, 1,5 anos depois vemos que está sendo desenvolvido muito rápido e faz muitas alterações)
  • API. Mesmo que XML-RPC não seja o mais sofisticado, ele ainda atende às nossas necessidades e permite fazer uploads e obter resultados por meio de scripts Python.
  • Interfaces extensíveis para suporte a novos rastreadores de bugs (melhoramos muito a integração do Jira ), back-ends de autorização (usamos ldap e Kerberos)
  • Suporte para ambiente . Mesmo que ainda tenha "execuções de teste" como em qualquer outro lugar, existe a possibilidade de definir algumas variáveis ​​por execução de teste. Nós o usamos para indicar versões de biblioteca de terceiros, sistema operacional, hardware que usamos e depois processamos em scripts automáticos.

UPD a partir do outono de 2018, upstream removeu todas as funcionalidades do ambiente em favor de "tags", que são muito menos adequadas para nós, portanto, continuamos com a versão upstream de meados de 2018.


Após 1,5 anos de uso do Kiwi, existem algumas desvantagens também:

  • Upstream se desenvolve muito rápido. Por um lado, é muito bom e indica que o projeto está "vivo", no entanto, é complicado permanecer no caminho, especialmente quando nossas mudanças começaram a aparecer em muitos lugares diferentes do código (a política da minha empresa torna difícil fazer upstream nas mudanças internas de volta para o GitHub público). Foi um pouco doloroso fazer o rebase sobre o upstream atualizado, onde eles fizeram uma enorme refatoração em todo o lugar. Tentei manter o controle, mas depois de meados de 2018, quando eles removeram a funcionalidade do ambiente, parei de seguir.
  • Apenas alguns dos meus problemas relatados foram corrigidos, alguns deles, que são críticos do nosso ponto de vista, ainda estão em aberto (corrigimos por nós mesmos em nossa instância)
  • A interface do usuário é um pouco antiga- escola, mas ainda ok (de novo, no master atual foi muito melhorado)
  • Algum código, especialmente JS era muito legado e não muito intuitivo de seguir (novamente, isso foi melhorado no master)

Então, eu realmente recomendo um para tentar se você estiver selecionando o sistema de gerenciamento de teste



Estas perguntas e respostas foram traduzidas automaticamente do idioma inglês.O conteúdo original está disponível em stackexchange, que agradecemos pela licença cc by-sa 3.0 sob a qual é distribuído.
Loading...