Especial: TestLink 1.9

Várias pessoas me pediram para falar sobre o potencial do TestLink, para demonstrar como acho que ele pode ser bem usado, integrado com outras ferramentas e etc. Esse momento chegou.

Aqui vou demonstrar as principais funcionalidades do TestLink, desde a instalação limpa usando o WAMP até os conceitos do teste de software demonstrados em uma atividade prática, com screenshots.

Primeiramente, para quem não conhece, o TestLink é uma ferramenta de gerência de teste. Ele não registra defeitos, não automatiza casos de teste e nem gerencia builds do software. Para isso temos outras ferramentas. O TestLink faz o trabalho de organizar a elaboração, planejamento e execução dos casos de teste. Isso inclui referenciar projetos, builds e até defeitos, mas não diretamente.

Se precisar de ferramentas para outras funcionalidades consulte a publicação brilhante do Cristiano Caetano:  http://testexpert.com.br/?q=node/795

Para quem já conhece o TestLink, foi disponibilizada uma página com informações sobre a nova versão, um overview das features em http://teamst.org/index.php/news-mainmenu-2/1-latest/102-testlink-190-released-2010-11-14

ESPECIAL TESTLINK – Aprendendo passo a passo

Iniciando: Baixando, Instalando, Configurando e Integrando:

Baixando:
Wamp 2.1*: http://www.wampserver.com/en/download.php
TestLink 1.9: http://sourceforge.net/projects/testlink/files/
*Wamp é um acrônimo para o conjunto de sistemas Windows, Apache, MySql e Php.

*Dica: Para facilitar a leitura de arquivos php, eu recomento usar o Notepad++ que pode ser baixado no link http://notepad-plus-plus.org/download

Lembre-se de consultar as versões mais novas do wamp e do TestLink. O TestLink é um sistema desenvolvido pelo TeamST (http://www.teamst.org) e mantido no SourceForge (http://sourceforge.net/projects/testlink/files), por isso, independente da versão apresentada nesse tutorial, é muito importante baixar a versão mais recente.

Instalando:

Após baixar o Wamp, instale-o com as opções default.
Configuração usada nesse tutorial: WampServer 2.1i (Apache 2.2.17, PHP 5.3.3, MySQL 5.5.8, PHPMyAdmin 3.2.0.1 e SqlBuddy 1.3.2) e Windows Seven Ultimate.

A instalação vai criar um diretório chamado wamp na sua raiz (ou no local que indicar para instalação), dessa forma terá “C:\wamp” (Vamos usar “C:\wamp” como padrão neste tutorial). Dentro de todos os diretórios dentro dessa pasta, apenas o “c:\wamp\www” nos importa temporariamente.

Verifique se o wamp está funcionando, para isso, verifique se ele está ativo (mesmo que off line) na sua barra de processos junto do relógio (canto inferior direito). Pode também acessar o phpMyAdmin, normalmente em http://localhost/phpmyadmin/. Este será o nosso gerência dor de bancos de dados durante o tutorial.

*Muito importante: caso tenha algum outro ambiente configurado, possivelmente terá que resolver problemas relacionados a portas e redes, o que não trataremos nesse tutorial. Aqui vamos seguir o “caminho feliz”, deixando eventuais problemas para os comentários deste post ou referências que serão anexadas durante a evolução deste blog ou em outros blogs do mesmo assunto. Vários programas podem causar interferencia, por exemplo o Skype, o VSTS 2010 e até mesmo o jogo WoW, por isso, tente usar um pc limpo ou uma máquina virtual caso tenha algum problema com a instalação.

Sabendo agora que ele está funcionando, vá até o PHPMyAdmin citado anteriormente e solicite “Criar novo Banco de Dados”. Informe o nome do banco de dados, neste tutorial, chamaremos de “testlink”. Outra opção é, na sua ferramenta de gerência mento, executar a seguinte query “CREATE DATABASE  `testlink` ;”.

Agora vá até a guia de “privilégios” e solicite criar um novo usuário com todos os acessos. Neste tutorial chamaremos esse usuário de “testlink” também.

Extraia o conteúdo do zip do TestLink e renomeie a pasta extraída para “testlink”, ficando assim “C:\wamp\www\testlink”.
Versão do TestLink usada nesse tutorial: TestLink 1.9.0.

Vá até o browser e acesse a página do TestLink, neste tutorial representada por http://localhost/testlink”. Neste momento o sistema o questionará sobre instalar uma nova versão ou atualizar uma versão já existente, solicite criar uma nova versão clicando no link “New Installation“. (Em breve vou disponibilizar um post com um roteiro sobre a atualização da 1.8 para a 1.9).

A instalação é dividida em cinco passos:

Acceptance of License (Aceite da Licença)

Basicamente ler e aceitar a licença marcando o checkbox “I agree to the terms set out in this license.

Verification of System and configuration requirements (Verificação do sistema e configurações requeridas)

O sistema avalia as configurações do computador em que o TestLink será instalado. Caso tenha algum problema, ele será apresentado para correções. Quando a mensagem “Your system is prepared for TestLink configuration (no fatal problem found).” for apresentada, basta solicitar “Continue”.

Definition of DB access (Definição do acesso ao Banco de Dados)

Neste tutorial só apresentaremos a instalação usando a máquina local e o MySql como banco de dados.

Informe o nome do banco de dados criado, neste caso “testlink”, usuário e senha do “root” do banco de dados.

Inclua também o usuário que criamos e a senha escolhida, logo após solicite “Progress TestLink Setup”.

Create DB, testlink DB user, structures and default data & create configuration file. (Criação do usuário do Banco de dados, estruturas e dados padrões e criação do arquivo de configuração)

Ação sistêmica, precedida pelas configurações logo acima.

Verify the procedure result (Verificação dos resultados do procedimento) and continue to TestLink login. (Continue para o login do TestLink)

Caso tudo ocorra normalmente, o sistema apresenta a mensagem abaixo:

Clique no link ou vá até o link http://localhost/testlink/login.php e veja a primeira tela do seu TestLink instalado:

O usuário do seu novo TestLink é “Admin” e a senha é “Admin”.

*Não é necessário o wamp. Caso deseje usar linux por exemplo, pode usar o lamp ou instalar os itens separadamente. Aqui ofereço a solução mais simples e não a mais profissional.

Configurando:

Abaixo vamos listar várias configurações. Todas são opcionais.

No TestLink:

Mudando o idioma para português: Ao logar, vá até “My Settings” e solicite o “Locale” para “Portuguese (Brazil)”.

No arquivo “C:\wamp\www\testlink\config.inc.php”

A intenção dessas modificações não é apresentar todas as opções de configurações que podemos realizar no arquivo de configurações do TesLink, mas apenas fomentar a customização deste arquivo para potencializar esta ferramenta para ser mais confortável, produtiva e atrativa para seus usuários e desenvolvedores. Ao aprender algumas das configurações que eu acho mais interessantes, você vai aprender a criar suas próprias configurações e passará a conhecer mais da estrutura interna da ferramenta. Boa sorte :)

Ocultando Avisos de segurança: Vá até a linha “$tlCfg->config_check_warning_mode = ‘FILE';” e modifique o “File” por “SILENT”.

Removendo o registro de novos usuários: Vá até a linha “$tlCfg-

>user_self_signup = TRUE;” e modifique o “TRUE” por “FALSE”.

Mudando o Idioma padrão para português:  Vá até a linha “$tlCfg->default_language = ‘en_GB';” e modifique o “en_GB” por “pt_br”.

Criando padrão de login: Mude o valor da expressão regular na linha “$tlCfg->validation_cfg->user_login_valid_regex=’/^[\w \- .]+$/';”. por exemplo, para ter um login com “nome.sobrenome”, mude a regex para “/^[\w \-]+\.+[\w \-]+$/”.

Incluindo o logotipo da sua empresa no Sistema: Salve o logotipo da empresa no formato PNG, preferencialmente nas dimensões “115/53″. Salve esse arquivo no diretório “C:\wamp\www\testlink\gui\themes\default\images”. Vá até a linha “$tlCfg->company_logo = ‘company_logo.png';”  e modifique o texto “company_logo.png” para o nome do arquivo que salvou no diretório citado acima.

Mensagens de boas vindas, aviso ou emergência: Vá até a linha “$tlCfg->login_info = ”; ” e inclua o texto entre as aspas simples. Esse texto será apresentado na tela de login. Na imagem abaixo podem ser vistas algumas das mudanças, ressaltando esta.

Ordenação alfabética dos projetos: Vá até a linha “$tlCfg->gui->tprojects_combo_order_by = ‘ORDER BY nodes_hierarchy.id DESC';” e modifique o conteúdo entre as aspas por “ORDER BY name”.

Integrando:

LDAP do Windows: verifiquei a nova versão e ela mantém as mesmas configurações de antigamente, para isso, acesse o post deste blog “Integrando TestLink ao Active Directory via Open LDAP“.

Mantis  (por Elias Nogueira): Um dos melhores tutoriais que tive o prazer de ler e usar no dia a dia, por isso coloco aqui o link para consulta: http://sembugs.blogspot.com/2008/06/integrao-do-testlink-com-o.html

Bugzilla(por Francisco Mancardi)http://www.teamst.org/_tldoc/1.7/tl-bts-howto.pdf

Meu Primeiro projeto: Definindo minha arquitetura de testeware e cadastrando os requisitos:

Sobre Projetos e produtos:

IMPORTANTE: Aqui serão abordados alguns conceitos e técnicas que aprendi através de estudo e experiência. Possivelmente alguns conceitos apresentados podem não ser os mesmos usados na sua organização ou mesmo no TestLink, sofrendo algumas adaptações.

Antes de usar a ferramenta, vou expor alguns conceitos importantes. Primeiramente a diferença entre produto e projeto.

Projeto: Segundo o PMBoK, “Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”, ou seja, um projeto atua sobre um ou mais produtos.

Produto: Um produto é o resultado do esforço de um ou mais projetos, operações, serviços ou outra forma de execução de trabalho. O Produto é algo tangível, no nosso caso, na maioria das vezes Software, mas para empresas especializadas em Teste de Software, possivelmente relatórios, registros de defeitos e evidências de teste entre outros artefatos.

Entendendo isso, vamos criar um projeto chamado “Projeto”.

New: Na imagem acima já podemos ver uma das funcionalidades interessantes do TL1.9. Na versão anterior, em uma empresa que trabalhei tivemos que mudar o acesso de todos os usuários do TestLink para “Sem Direitos”. Isso era uma artimanha para evitar que todos os usuários tivessem acesso a todos os projetos. Na nova versão, podemos deixar alguns projetos como público, o que o deixa como a versão anterior, acessíveis a todos os usuários, enquanto quando não os marcamos, apenas os usuários definidos no projeto terão disponibilidade aos artefatos. Esse recurso já existia no Mantis.

O TestLink nos possibilita gerência r os testes de duas formas. Uma é a tradicional, como é usado na maioria das empresas, como foi usada acima. Um “projeto” para cada projeto de teste, onde vamos inserir os casos de teste, gerência r planos e etc. Essa forma apresenta muitas vantagens quando tratamos de projetos gigantescos, que exigem vários Planos de teste diferentes. Mas quando trabalhamos com vários projetos pequenos de software para um produto maior, podemos usar uma abordagem diferente. O que o TestLink chama de projeto, podemos considerar como Produto e o que o TestLink chama de Plano de teste, podemos chamar de projeto de teste.

A adaptação sugerida acima é muito interessante, pois, se pensarmos bem, na maioria das vezes, temos um plano de teste para cada projeto de teste. São raros os projetos em que eu participei em que eu tinha mais de um plano de teste, que era evoluído com o tempo. Essa adaptação conceitual não chega a ser uma “gambiarra”, pois, efetivamente, os casos de teste assim como os casos de uso não são artefatos do projeto, mas sim do produto. O projeto concentra itens como plano de riscos, plano de escopo, plano de comunicação, evidências de teste, relatórios de acompanhamento e etc., deixando itens como casos de uso, requisitos, casos de teste, matriz de rastreabilidade, código fonte, defeitos  e etc. para o produto.

Um exemplo interessante de como a segunda abordagem pode ser mais interessante:

Temos o produto “Blog Bug Bang Theory”. Para ele, foram elaboradas 5 fases, denominadas Fase A, Fase B, Fase C, Fase D e Fase E. Cada fase, por sua vez, acaba virando um projeto, com seus próprios riscos, necessidades, recursos e etc. Na abordagem “Criando um Projeto do TestLink para cada Projeto de Teste”, vamos criar o testware dos casos de uso 1, 2, 3,  4, 5 e 6. Imagine que criamos 60 (sessenta) casos de teste para esses casos de uso, testamos e encerramos o projeto. Agora vamos para a Fase 2 e . . ., não temos os casos de teste se precisarmos reexecutá-los. Temos que reabrir o projeto e poluir as informações sobre a execução dele, ou usar a funcionalidade de exportação e importação.

Se usarmos um plano de teste do TestLink para cada Produto, e um plano de teste para cada projeto, perdemos a capacidade de criar diferentes planos para cada projeto, mas ganhamos o reuso dos casos de teste elaborados para todos os projetos, isso sem perder os históricos sobre execução de teste de todos os projetos, que ficam vinculados aos builds e aos planos de teste. Confuso? Termine de ler esse tutorial que vai entender tudo :).

Enfim, cada um pode usar a ferramenta da forma que for mais conveniente para sua organização. Aqui eu estou apresentando a forma com que o TestLink realmente foi desenhado para atender, indicando a forma que eu acredito que podemos extrair mais benefícios e aumentar a produtividade dos testadores e analistas e melhorar a coleta e análise para os gerentes e coordenadores.

Para esse tutorial não vamos abordar a gestão da automação.

Requisitos:

Aqui estão várias melhorias interessantes. Agora os requisitos podem ser gerência dos em forma de árvore, ou seja, podemos ter vários níveis de especificações de requisitos. Como cada organização trabalha de uma forma, podemos dar o exemplo de separação por módulos.  Por exemplo: Um sistema X contém três módulos, onde cada módulo contém vários casos de uso.

Além disso, ele possui um workflow simples para controle dos requisitos, o que reflete nos relatórios. Nesse workflow temos desde rascunho, passando por revisado, validado, obsoleto e completo.

Mas o mais bacana da nova versão nessa área de requisitos é a elaboração automática de um documento de requisitos. Se aplicarmos algumas regras de detalhamento do caso de uso, extraindo dele os requisitos de negócio e os fluxos do sistema, podemos criar um documento gerenciável, que facilita e muito a nossa visualização sobre os casos de uso.

Para isso, vamos usar a técnica apresentada no post “Um modelo para elaboração de cenários e casos de teste” deste mesmo blog, e como matéria prima para esse exemplo, vamos usar o caso de uso “ManterAvisos” desenvolvido para essa finalidade.

O caso de uso acima não é perfeito, como qualquer artefato que não tenha passado por um processo rigoroso de qualidade ele possui falhas, mas espero que atenda ao nosso objetivo aqui, que é demonstrar o processo de extração dos cenários e a elaboração dos casos de teste no TL1.9.

Se aplicarmos a técnica (detalhada mais à frente neste post), teremos os seguintes diagramas para cada fluxo:

Pra cada caso de uso, vamos realizar a análise detalhada acima, e no TestLink vamos criar uma “Especificação de requisitos”. Para cada Especificação de Requisitos, vamos criar uma estrutura de pacotes para cada um com três seções: Regras de Negócio, Fluxos do Sistema e Exceções.

Em regras de negócios, vamos criar uma Constrain (restrição) para cada requisito. As constrains são requisitos testáveis, por isso vamos usá-las para representar as regras do caso de uso.

Em Fluxos do sistema e Exceções, vamos criar requisitos informacionais, respectivamente para Fluxos alternativos e fluxos de exceção. Os requisitos informacionais são abstratos, apenas uma informação e não testáveis. Vamos usá-los pra representar os fluxos, pois eles realmente não são requisitos, mas sim uma abstração do uso do sistema, podendo ser apenas uma informação para o testador. Eles ganharão “vida” mais tarde, cada um virando um cenário de teste.

Após cadastrar todos os requisitos, fluxos e exceções, vamos realizar as ligações entre eles. É interessante vincular todas as regras e exceções como “relacionado a”  em cada um dos fluxos alternativos e ao principal e as regras como filhas do caso de uso.

A nomenclatura adotada neste tutorial é composta, tendo o padrão “UC” para casos de uso, “E” para exceções, “FP” para fluxo principal, “R” para regras de negócio e “FA” para fluxos alternativos. Para cada novo requisito escrito, seja ele informacional ou constraint, deverá ter o prefixo do caso de uso ao qual ele pertence. Por exemplo, “UC01FA03″ que representa o Fluxo Alternativo número 03 do caso de uso 01.

O cadastro dos requisitos é muito simples e intuitivo. Após cadastrar cada um dos casos de uso e criar os relacionamentos necessários, o sistema gera um documento automaticamente, com informações unificadas sobre cada requisito, semelhante a este exemplo:

A vantagem de usar uma abordagem organizada, baseada em rastreablidade de requisitos, pode  gastar um pouco mais de tempo durante esta fase, mas nos fornece maior confiança na cobertura adequada dos testes, maior efetividade nos testes, identificação de defeitos nos casos de uso, análise detalhada de cada regra e substitui o checklist de revisão de  casos de uso em organizações que não tem esse documento. O Ideal é que neste ponto o documento de caso de uso já esteja verificado e validado.

Elaborando Casos testes:

Aqui está, sem dúvidas, o maior avanço da versão 1.8.x para a versão 1.9. Apesar de o TestLink ainda não usar o conceito de cenários e casos de teste da forma mais correta, ele apresentou melhoras significativas para o executor e principalmente para o coordenador da equipe.

Os conceitos comentados acima já foram explicados no post citado anteriormente (Um modelo para elaboração de cenários e casos de teste), mas vale a pena explicar como ficou na ferramenta. Agora, criamos uma suíte que representa os fluxos do sistema (nossos requisitos informativos) e para cada uma, criamos um conjunto de casos de teste baseados em técnicas, nas regras e em outras informações fornecidas pelos requisitos.

Simples assim.

Uma publicação que serve de orientação e inspiração para o conteúdo descrito abaixo pode ser acessada no link http://www.ibm.com/developerworks/rational/library/04/r-3217/.

Na prática, vamos continuar com o nosso caso de uso. Para ele criamos um diagrama de atividades, ou um rascunho como o desenhado abaixo:

Como a imagem acima fica muito complexa para entendermos, vamos separar como no post mencionado anteriormente.

Para cada possível fluxo vamos dar um nome e um ID e chamaremos de “cenário de teste”, como na imagem abaixo:

Uma vez desenhados e conferidos, vamos criar uma estrutura para agrupá-los no TestLink.

Importante comentar que aqui estamos com uma cobertura parcial, que nos dá segurança de executar todos os passos e todas as combinações simples entre os diversos conjuntos de passos, mas não temos todas as combinações possíveis. Um exemplo disso é que a partir do final do CN12 poderíamos seguir por para o passo cinco do fluxo principal, para o passo um do fluxo alternativo dois ou mesmo voltar a exercitar o passo um do fluxo alternativo três, e cada um desses exercícios seria um cenário diferente. Mas é conhecido que é praticamente impossível exercitar todas as possibilidades de uma operação de média complexidade, logo devemos priorizar a melhor cobertura dentro dos recursos disponíveis, o que para sistemas de informação, muitos consideram executar todos os passos e todas as combinações simples entre diferentes conjuntos de passos (Cenários).

A estrutura sugerida neste post é a seguinte:

Agora que temos a estrutura completa, podemos criar os nossos casos de teste. Para criar bons casos de teste temos vários livros, guias e sugestões de amigos da área. Eu já comentei sobre no post “Um modelo para elaboração de cenários e casos de teste” ,  se pesquisarmos a tag “Caso de teste” no blog QualidadeBr (https://qualidadebr.wordpress.com/tag/caso-de-teste/)  ou no blog SemBugs encontraremos ótimas referências, portanto aqui vou passar um pouco do que aprendi no dia a dia, do que nossos colegas compartilham em seus blogs e do que é dito na literatura, mas, como vem sendo dito em todo o tutorial, este passo deve ser executado da forma que a organização se beneficie mais.

A anatomia de um caso de teste comum é constituída por:

  • Id: Identificação única de cada caso de teste
  • Título: Descrição sucinta e simples do objetivo do caso de teste
  • Pré-condições: Condição esperada para que o caso de teste seja executado.
  • Procedimentos de teste ou passos: Instruções textuais normalmente descritas no imperativo.
  • Pontos de verificação: Questionamentos usados para garantir a validade de regras ou necessidades específicas.
  • Dados de entrada e dados de saída: Informações usadas para garantir que o teste não está vulnerável a erros de dados.
  • Pós-condições: Condição esperada ao término da execução do teste.
  • Rastreabilidade:  Indicadores da fonte de informações para criação e execução do teste.
  • Observações gerais: Qualquer recomendação adicional que o analista acredita que seja necessária ao executor, assim como arquivos ou figuras.

No TestLink o Id é gerência do automaticamente, baseado na sigla do projeto. No nosso caso os ids serão sempre prd-<número sequencial>

O título permite um texto com até 100 caracteres alfanuméricos, é interessante colocar uma descrição bem simples e padronizada para que mesmo um testador menos experiente ou com pouco conhecimento do produto consiga identificar o objetivo do caso de teste.

O TestLink oferece um campo chamado “Sumário” como campo livre durante a elaboração dos casos de teste. Neste campo podem ser incluídas quaisquer informações sobre o caso de teste, tais como detalhes sobre dados, instruções de testes exploratórios que podem ajudar a encontrar defeitos ou informações relevantes sobre o negócio ou sobre a tecnologia. Enfim, qualquer informação que possa ajudar a identificar mais defeitos é bem vinda neste campo. Outra opção é usar esse campo como um roteiro simples de execução do teste, para em casos críticos de tempo restrito, o teste possa ser realizado com menos procedimentos e maior objetividade. Claro que nesses casos perderemos a maior parte da eficácia do caso de teste em prol de uma maior eficiência.

O TestLink oferece também um espaço reservado para pré-condições. Na prática, a maioria das pré-condições descritas em casos de teste e em casos de uso são “O administrador deve estar logado” ou o “O Médico deve possuir acesso ao prontuário do paciente”. Esse tipo de informação não agrega nenhum valor. Esta sessão do documento deve oferecer um recurso que diga exatamente as condições do sistema para execução do teste, inclusive podendo conter roteiros para restauração de bases de dados, informações sobre um processamento necessário ou sobre a execução de outros testes ou rotinas. O importante é não preencher campos apenas para preencher. Informações desnecessárias só geram esforços desnecessários.

Os procedimentos de teste ou passos de teste como normalmente são chamados, são as instruções que damos ao executor. Dessa forma, sempre devemos nos expressar no infinitivo e com imparcialidade a interface ou elementos gráficos, usando verbos como “Informe” ao invés de “digite” e “Selecione” ao invés de “Click”. Essa é uma maneira de não tornar nossos casos de teste viciados em telas de sistema, não sendo necessárias atualizações e atualizações se o css da página mudar e o que parecia um botão agora parecer um label. No TestLink até a versão anterior, era usado um textarea para essa finalidade, onde até podíamos formatar usando html, mas realmente não parecia muito apropriado para casos de teste. Na nova versão, temos um cadastro de ação e reação para cadastrar essas instruções. Normalmente, junto  dos passos, podemos informar os dados de entrada e saída, o que o sistema tornou muito mais fácil de ser compreendido agora. Para cada ação do usuário, normalmente, existe uma reação do sistema. Por exemplo, quando informamos “Solicite salvar” O sistema gera algumas instruções internas e exiba mensagem “Registro XPTO salvo com sucesso”. Na versão anterior, isso ficava parecendo um passo único. Agora, o TL oferece o recurso de cadastrar um passo e um contrapasso, chamados de “Ações do passo” e “Resultado esperado”. Essa foi a principal mudança do sistema, pelo menos na minha opinião. Muito boa, diga-se de passagem, mas ainda peca por não permitir criar “variáveis” para cada caso de teste, onde informamos quais os dados que vamos usar para executar um teste X e outros valores para executar testes Y e Z, reaproveitando os passos já cadastrados. Para quem não conhece, esse é o conceito de testes dirigidos a dados (Falaremos no futuro aqui), que já é usado em ferramentas como o IBM Rational Quality Manager e o Visual Studio Team System 2010 (Testing Center). Um ótimo exemplo da aplicação do conceito está descrita no posts Data Driven com Selenium IDE? Sim, é possível!!! do Elias Nogueira quanto no post Criando uma arquitetura de testes com o selenium para testes dirigidos a dados do Jailton Júnior. Usando os posts deles como exemplo, o que eu realmente adoraria ver no TestLink 1.9 seria uma forma de usar um arquivo XML, uma variável usando @ (como no VSTS2010), ou qualquer outro recurso que possibilitasse a existência de um conjunto de passos, e dezenas de conjuntos de dados. Se o TL implementar isso, se torna uma ferramenta Open Source com altíssima produtividade para testes manuais, inclusive, ficando muito próxima, se não empatada com o VSTS2010 (não considerando automação).

Assim como as pré-condições, as pós-condições representam um estado que deve ser atingido pelo sistema, e também não deve ser algo desnecessário como “registro cadastrado” ou “caso de uso completado com sucesso”, mas sim informações que agreguem valor e confiabilidade aos resultados gerados pela execução dos testes, porem, o testlink não possui um campo exclusivo para essa funcionalidade, logo, o uso do sumário ou do anexo para essa sessão é muito bem vindo.  Se a rotina usada gera um log, informe os logs que serão gerados, se gera um valor numérico derivado de um cálculo complexo, informe o valor ou crie um arquivo de planilha eletrônica ou de outro software confiavel para ter mais certeza que o cálculo esteja correto, se gerar um relatório anexe um relatório exemplo de como o relatório será gerado, se um xml, informe um validador para esse xml. Pense sempre  que as informações dos testes desenvolvidos devem ser sempre precisas e enxutas. Preencher campos para atender requisitos sem necessidade, sejam eles da gerência, do cliente ou de modelos como o CMMi não agregam valor. Questione qual a necessidade dessas informações e explique que isso toma tempo e gera confusões. Chegue a um consenso e demonstre o quanto os testes podem melhorar sem as informações redundantes, desnecessárias ou de preenchimento aleatório.

A rastreabilidade dos casos de teste nesse exemplo é feita para o caso de uso e seus requisitos, que definimos no início do tutorial. Para quem já conhecia a antiga versão continua basicamente a mesma coisa. Você seleciona a opção “Atribuir requisitos” que fica na tela de edição do caso de teste e seleciona os requisitos que deseja atribuir a este “cenário de teste”.  A diferença é que nesta versão mais recente, o mecanismo de requisitos em diferentes níveis nos ajuda a encontrar os registros com maior facilidade.

O objetivo aqui não é ensinar como criar casos de teste fabulosos e extremamente efetivos, por isso vou resumir muito a criação dos casos de teste, deixando apenas uma amostra do que pode ser feito. Não vou cobrir todos os requisitos, pois gastaria muito tempo e não é o foco do post. Aqui queremos mostrar como a ferramenta funciona e alguns exemplos de como podemos aplicar algumas das técnicas de teste.

De qualquer forma, tem algumas coisas que eu acho fundamentais “passar para frente”, que ajudam nossos profissionais a demostrar mais valor e profissionalismo ao criar casos de teste. Um desses fatores é o uso correto da técnica de valores limites. Durante muito tempo usei esse exemplo nas entrevistas que eu passava para os candidatos.

Eu perguntava se existia alguma regra complexa, que eles não saberiam testar, então após uma breve análise (de menos de cinco minutos) sobre o caso de uso (este do post com algumas adaptações), me falavam que “não, não teriam problemas para testar”.

Então eu perguntava novamente, dessa vez pedia que focasse na regra 07, aquela pequenininha e bem mal especificada. Perguntava se existia alguma técnica que podia ser usada para testar aquela regra, e eventualmente alguém comentava que valores limites podia ser usado, mas na maioria das vezes, inclusive alguns certificados, não sabiam responder. Então eu comentava sobre a técnica e solicitava que a aplicassem. A maioria das vezes, a nossa tendência é pensar na implementação, pensar em forma de texto e tentar criar uma série de artifícios textuais ou ferramentais para resolver os problemas que nos são passados. Raramente pensamos pegar uma folha de rascunho e desenhar o que estamos pensando. Dessa mesma forma, quase todos escreviam cinco ou seis testes possíveis, mas nunca todos. Raros os casos que desenhavam alguma coisa. Então eu mostrava no quadro o leque de possibilidades a mais que podemos ter usando essa técnica.

Regra 07
Um mesmo usuário não pode cadastrar dois avisos que ocupem o mesmo período de tempo.

A – Cadastrar um período normalmente;
B – Cadastrar um período anterior ao período cadastrado (e deletá-lo em seguida);
C – Cadastrar um período posterior ao período cadastrado (e deletá-lo em seguida);
D – Cadastrar um período exatamente anterior ao período cadastrado (e deletá-lo em seguida);
E – Cadastrar um período exatamente posterior ao período cadastrado (e deletá-lo em seguida);
F – Cadastrar um período com data final igual a data inicial do período já cadastrado;
G – Cadastrar um período com data inicial igual a data final do período já cadastrado;
H – Cadastrar um período com data final dentro do período já cadastrado;
I – Cadastrar um período com data inicial e final dentro do período já cadastrado;
J – Cadastrar um período com data inicial dentro do período já cadastrado;
K – Cadastrar um período que contenha o período já cadastrado;
L – Cadastrar um período que contenha o período já cadastrado do usuário A, usando um outro usuário qualquer;
M – Cadastrar um período exatamente igual ao período já cadastrado
N – Deletar um período e cadastrá-lo novamente;
. . . – Várias outras possibilidades.

Isso não considerando que o campo é de data / hora, ou seja, eliminando a complexidade realizar todos esses testes no mesmo dia, usando os limites apenas das horas, não considerando também os testes negativos, como por exemplo casos de teste usando datas invertidas (inicial > final), valores diferentes de datas, usando datas anteriores  a 00/00/0000 e posteriores a 99/99/9999, data início e fim iguais (inicial = final), ano bissexto etc., o que já estamos acostumados a testar de datas inválidas. Desconsiderando também a regra 04, que fala que apenas a data de publicação é um campo requerido, o que nos dá a possibilidade de intervalo aberto. (Nessas horas que agente gosta de ouvir que testar é fácil né?)

Para cada uma das possibilidades acima, vamos criar um caso de teste diferente.
Ps: Agora fica bem claro o porquê eu adoraria que o TL1.9 implementasse DDT (Teste dirigido a dados).

Outro ponto importante, é que cada um dos campos obrigatórios da regra 04 deve possuir um caso de teste diferente. Assim como cada um deles, em um mundo perfeito com analistas de requisitos treinados e prontos para escrever sempre com o máximo de detalhes, deveria possuir um fluxo de exceção diferente no caso de uso.

Regra 04:
Definir campos obrigatórios:
•                      Página;
•                      Título;
•                      Autor;
•                      Resumo;
•                      Tag;
•                      Publicar em (data hora).

Dessa forma, teríamos um caso de teste para cada um dos campos obrigatórios.

Para exemplificarmos, abaixo a figura de um caso de teste cadastrado:

Podemos notar que várias regras foram acionadas. É importante que cada regra seja testada, quanto mais isolada, melhor, mas em vários casos podemos usar pair wise e sintetizar várias validações em um mesmo caso de teste. Isso depende do quão o sistema é crítico. Em um sistema de aviões ou que envolvam vidas é claro que não devemos economizar com testes, mas em sistemas de informação podemos usar um mesmo caso de teste para validar várias regras ao mesmo tempo.

Observe que no exemplo anterior temos a rastreabilidade de cada regra, temos uma pré-condição válida, nada de “Usuário deve estar logado” e temos um conjunto de passos e resultados justados uns com os outros (novo recurso).

Agora cadastramos vários outros casos de teste, de forma a cobrir os cenários, aplicando técnicas e desenhando mais do que escrevendo, contando com ajuda dos demais amigos que estão do lado e pensando muito nas possibilidades disponíveis e nos dados que podem ser usados para exercitá-la. Se essa etapa for concluída com sucesso, dificilmente os testes não serão completados com sucesso também.

Mais algumas dicas de como criar casos de teste:

Para atribuir um requisito ou fluxos, edite o caso de teste, solicite “Atribuir requisitos“ e selecione  na árvore do dropdown, a folha que deseja.

Como aqui é só um exemplo, criei um caso de teste para cada cenário. Atribuí regras aleatórias e cadastrei alguns erros de propósito (outros nem tanto rs), que serão vistos no próximo  bloco.

Planejando testes: O dia a dia otimizado do coordenador de testes:

Agora sim. Casos de teste cadastrados e vinculados aos requisitos. Agora é só executar e . . . ops! Cadê a qualidade?

Antes de qualquer coisa, o nosso novo papel, o coordenador vai criar um plano de teste. Para isso ele vai no menu a direita “Gerência r Plano de Teste”. Ao fazer isso, serão habilitados dois novos links no menu. “Executar Testes” e “Resultados”. Também serão exibidas novas opções como gerência r baselines e releases, gerência mento de marcos etc., veremos mais a frente quando for necessário.

Vamos conhecer algumas das ferramentas que ajudam o coordenador de teste ou de projeto, a controlar melhor o que será feito e como será feito.

O arquiteto de testes define as plataformas e inventários.

A plataforma é qualquer tipo de informação referente ao ambiente cliente.

Enquanto o inventário relaciona links e serviços:

O ideal para o cadastro de plataformas, é associar esse cadastro a um ambiente de virtualização, como por exemplo Hyper V, para evitar que esse ambiente seja poluído. Normalmente, os testadores só consideram ambiente de teste como a parte server (que é o normal da equipe inteira).

O coordenador informa os que serão usados no plano de teste através do link  “Adicionar / Remover Plataformas”.

Agora também usa o link “Adicionar / Remover Casos de Teste”. Nesse ponto, os casos de teste que serão executados nesse plano de teste (ou projeto de teste) devem ser selecionados com muito cuidado. O sistema permite adicionar em lote, ou selecionando apenas uma suíte.  O importante é ter atenção para evitar problemas durante essa fase. Um novo recurso muito bacana do testlink, é que em um mesmo plano, podemos definir quais casos de teste serão executados em quais plataformas.  Além disso, nesse momento ainda podemos definir uma ordem de execução, para garantir que os testes sejam executados sequencialmente.

Existe também a opção de priorização dos testes. Aqui podemos selecionar testes de uma mesma suíte e mudar a urgência em lote.

Agora sim, o Coordenador vai criar uma baseline ou release.

Podemos dizer que release é uma versão do software, o estado final após todo o processo de desenvolvimento, enquanto baseline é uma “fotografia” de todos os artefatos de um produto em um determinado marco. Ou seja, uma baseline contem além da release do software, um conjunto de artefatos que correspondem a um determinado momento no processo de desenvolvimento.

Mas no TestLink, ambos são a mesma coisa, que pode ser definida como .

De qualquer forma, vamos cadastrar uma nova release no “Baselines/Releases”.

Importante comentar que ativo e aberto são coisas diferentes.

Ativo / Inativo Define se a baseline está ou não disponível para funcionalidade do TestLink. Baseline inativa não é listado nas páginas de execução e relatórios.
Fechado / Aberto Define se os Resultados do Teste podem ser modificados para a baseline.

Ultima funcionalidade que devemos comentar é “Atribuir casos de teste para execução”. O legal dessa funcionalidade é que os filtros que ela oferece nessa nova versão estão melhores. Com eles podemos selecionar, por exemplo, o “testador A” para executar todos os casos de teste da “plataforma A”, ou somente os casos de sucesso, ou somente os caso de um projeto ou de uma release e ele ainda envia um e-mail informando ao testador, o que facilita quando estamos distantes geograficamente. O Coordenador se preocupa em orquestrar, a ferramenta garante o controle e ajuda no processo e na comunicação.

Ainda antes de deixar o testador usar os recursos novos, podemos avaliar alguns relatórios que nos ajudam a identificar se estamos realmente com cobertura de testes satisfatória e se o nosso planejamento tem riscos de furar.

Entre eles:

O “Relatório baseado em Requisitos” se destaca, pois nele podemos pegar casos de requisitos que não foram cobertos, que nessa versão veio com muitas novas informações, desde  um filtro para indicar que só queremos validar requisitos finalizados até um sumário informando naquela suíte de requisitos quantos requisitos tem cobertura e quantos não tem.

“Casos de teste não atribuídos a testadores” que nos informa a prioridade, as plataformas que devem ser testadas e que não possuem testador vinculados a elas (por projeto, release e plataforma).

Os relatórios descritos acima podem ser usados durante todo o projeto, mas é altamente recomendável que seja usado antes de designar as tarefas para os testadores, pois esses relatórios garantem que não terão casos de teste sem um responsável e que não existem requisitos ou fluxos não cobertos pelos casos de teste.

Lembre-se também de atribuir acessos aos seus testadores. Pode ser dado em projetos privados, através do “Atribuir papéis do plano de teste”

Um último relatório que pode ser impresso aqui para demostrar valor, é o relatório de Plano de Teste, que imprime os casos de teste com todas as informações. Ele está do mesmo jeito, só mudou que agora temos uma funcionalidade para marcar e desmarcar todas as opções na hora de imprimir (uma das maiores reclamações do TL1.8 rs) e que a disposição dos procedimentos fica parecida com a nova versão. Para quem acompanha o BugBang, deve ter visto que na versão anterior eu tinha montado uma customização para mostrar o conteúdo das regas de negócio, isso foi documentado no post “Exibindo corpo dos requisitos nos relatórios do TestLink”, em breve devo lançar essa customização para essa nova versão. Abaixo tem um exemplo de como ficam os casos de teste nessa nova versão:

Executando na prática: O dia a dia otimizado do testador:

Agora logamos com o José, aquele que atribuímos alguns testes. Vamos ver como o testador se comporta agora.

Em primeiro lugar, o “Casos de teste atribuídos pra mim” ficou melhor. Agora é possível  ter em uma tela, um conjunto de “tarefas”, considerando plataforma, status e prioridade.

Outra forma de ver essas informações é o uso do painel de métricas, que agora usa plataforma como fator de decisão para testes, ou seja, caso o coordenador tenha incluído no plano de testes que cada um dos 10 casos de teste deve ser executado nas 3 plataformas, o sistema solicitará pelo menos 30 execuções para ficar com 100% de completude.

No novo painel de execução são mantidos o layout e os filtros da versão anterior, mesma simplicidade. A única novidade é que agora a plataforma passou a ser um novo campo para filtro e que os casos de teste que não estão atribuídos para o usuário não aparecem para ele no filtro default, mas ele ainda marcar o “Incluir CT’s não atribuídos” para pegar eventuais casos de teste que não estejam associados a nenhum outro testador. Ou seja, agora o coordenador ganha a responsabilidade de ser mais organizado com a distribuição dos casos de teste, pois pode acontecer de testes não serem feitos se a funcionalidade de atribuição for usada com falta de atenção ou negligência, o que não acontecia na versão anterior, pois era só um campo de filtro, mas todos os testes apareciam para todos que tem acesso ao plano de teste.

A maneira de executar o teste não mudou. Você executa os testes, fica atento às regras, informa o resultado, cadastra uma nota do teste, caso deseje atribuir uma evidência de teste, solicite “salvar execução”, caso não, pode usar a nova funcionalidade de “Salvar e ir para o próximo”.  Eu acho o uso de evidências de teste fundamental hoje em dia. Mesmo que seja um print, mesmo que seja um arquivo ou um código qualquer. Incluir a evidência de teste não só te resguarda de quaisquer eventuais problemas, como é uma grande demonstração de valor para os gerentes de projeto. Muitos gerentes chamam os profissionais da qualidade de “testes” com um tom pejorativo, porque nós mesmos não demonstramos a quantidade de valor que podemos trazer para a organização. Claro que isso demora um pouco, todas as empresas aprendem a “gostar” de teste de software pelo amor ou pela dor, só uma questão de tempo, mas se puder fazer com que sua empresa goste de teste pelo amor não é melhor? Um relatório de evidências de teste como o demonstrado no post ”Exibindo evidências de teste no TestLink” (que será atualizado para versão 1.9 em breve) ao final de uma iteração, de um Sprint ou até de um projeto, pode dar mais segurança para os gerentes e até mesmo pra você, além de quantificar seu trabalho pra equipe em número de casos de teste elaborados, executados, re-executados, etc.

O painel de execução continua sendo o “tchan” do TestLink na minha opinião. Sem ter que consultar e fazer relatórios, apenas observando quatro números, você consegue saber quantos testes passaram, quantos estão bloqueados, quantos falharam e quantos ainda não foram executados. Você ainda pode escolher em qual nível você quer ver.

Relatórios: Extraindo informações e não dados:

Mesmo no perfil do nosso tester José, podemos extrair as mesmas métricas daqui, porém, somente com os casos de teste dele, mas vamos mudar para o nosso coordenador para ter métricas do projeto inteiro.

O relatório mais usado é o relatório de “Metricas gerais do plano de teste”, que eu também gosto de chamar de “Sumário de testes”.

Através dela podemos avaliar a evolução do projeto em execução de teste pelas baselines. Se da versão Beta 00.001 para a Beta 00.002 tivermos menos porcentagem de execução de teste com sucesso, indica que o sistema regrediu. Nesse caso, é muito importante tentar entender porque o sistema apresentou resultados piores que os da execução anterior.  Também mostra a execução de testes por plataforma, o que pode ajudar a tomar decisões como mudar algo na estrutura, design ou arquitetura do sistema para melhorar o atendimento de uma determinada plataforma. As prioridades podem ser usadas para saber se o mínimo necessário foi testado, por exemplo, deixando o fundamental na prioridade alta e os testes menos importantes nas mais baixas.

Esse relatório tem um poder incrível para os coordenadores e gerentes. Claro que cada caso é um caso, e essas visões demonstradas acima podem não se aplicar a um ou mais determinados projetos, mas com certeza alguma informação importante esse relatório vai te passar. Quando eu era coordenador em uma empresa com vários testadores, eu costumava pedir que enviassem para o coordenador de projetos com uma análise simples, como uma fotografia do teste agora e o ponto de vista do testador sobre essa fotografia.

O relatório de teste, que eu também gosto de chamar de relatório de evidências é o relatório que eu acho que encerra uma fase de execução de testes de sucesso. Com ele demonstramos as evidências para cada um dos testes executados e mostramos que realmente trabalhamos e geramos artefatos. Como falei anteriormente, evitar gerar entregáveis pode acarretar em diminuição do prestígio dos profissionais da área. No link apresentado anteriormente (Exibindo evidências de teste no TestLink) existe umexemplo das evidências e nessa nova versão não tiveram mudanças. Os casos de teste apresentados aqui continuam sendo os mesmos do relatório do plano de teste, com a informação do resultado da execução (último status).

Quando temos duas plataformas, deveríamos ter um relatório de evidência com mais de um caso resultado. Deveria ser um resultado para cada plataforma. Porém, aqui ele pega apenas as informações da primeira plataforma (alfabeticamente) no banco, e apresenta o resultado dela. No nosso exemplo acima, o caso de teste Consultar aviso acabou sendo executado somente na plataforma XPIE07, mas o relatório só carregou as informações da plataforma XPFF35, onde ele sequer foi executado. Nenhuma ferramenta é perfeita.

Results by Tester per Build é um novo relatório que carrega as informações de cada build e quem executou o que em quantidades absolutas e procentagem.
Importante: Esse relatório pode enganar. Ele não mostra números de casos de teste não associados. Dessa forma, pode ser que um relatório indique 100% de execução com sucesso, mas vários testes não terem sido executados.

Test Case Assignment Overview é outra novidade legal do TL1.9, aqui o sistema exibe uma lista com detalhes sobre quem pegou o que pra testar. Também faltam casos de teste não atribuídos.

Métricas de consulta é o relatório “SQL” do TestLink. Nele você consegue pesquisar combinações “loucas” que só fazem sentido para sua organização. Esse pra mim é um relatório que pode ser chamado de relatório coringa.

Matriz de resultados de teste mostra de maneira detalhada o status da execução dos casos de teste nas últimas versões. No exemplo abaixo não parece muito útil, mas quando temos uma dezena de releases esse relatório pode nos ajudar a identificar casos de teste que oscilam muito, por exemplo, funcionando em versões releases ímpares e falhando ou bloqueando em releases pares.

Ainda existem três relatórios que listam os casos de teste com falha, os casos de teste bloqueados e casos de teste não executados no formato abaixo. Considero importante destacar a necessidade de um quarto relatório com o mesmo conteúdo, porém para casos de teste não atribuídos a testadores. Esse mostra o que não será testado e requer muita atenção e pelo menos uma visualização por iteração.

Os gráficos do TestLink continuam pouco atrativos e pouco úteis na minha opinião. Eles trazem basicamente as informações de total de testes executados, não executados, com  falha e bloqueados, tanto por plataforma, por testador e por suíte quanto geral. Eu sempre uso Excel para consultar o banco e criar meus próprios relatórios, que são mais apresentáveis e com dados mais interessantes do que os atuais.

Já comentamos do relatório baseado em requisitos, mas acho legal falar mais um pouco e mostrar como podemos inverter o paradigma e falar de requisitos falhos ou requisitos com sucesso ao invés de casos de teste. Em eventuais situações, uma quantidade muito pequena de casos de teste pode conter até 90% dos requisitos. Dessa forma, uma análise falando que 85% dos casos de teste foram aprovados e o restante está com falha pode ser uma linda fachada para não informar que 90% dos requisitos não foram plenamente atendidos. Nesses casos é muito importante usar esse relatório ao invés dos demais baseados em casos de teste. Dessa forma evitamos entregar um produto “bem testado” e parcialmente “aprovado” com baixa qualidade. O ideal é usar os dois relatórios. Se a proporção estiver muito discrepante, fique com o pior cenário.

Um último relatório essencial é o relatório “Casos de Teste não atribuídos para qualquer Plano de Teste”.  Criei um caso de teste especialmente para isso. Ele não aparece em nenhuma das métricas acima, pois não está vinculado para ser apresentado em relatórios, mas isso é um grande risco, pois podemos esquecer um ou mais casos de teste que podem ser importantes para o negócio. Dessa forma, esse relatório lista em detalhes os casos de teste que não estão em nenhum plano de teste, ou seja, que não tem nenhuma probabilidade de serem executados.

Existem relatórios que usam campos personalizados, mas não vamos abordá-los aqui. Em um post futuro devo gastar mais tempo falando sobre como customizar o seu TestLink, o que vai incluir esse tópico.

Exercício proposto 1: Siga o tutorial do TestLink passo a passo de acordo com o descrito acima. Modifique algumas configurações. Conheça também o mantis. O processo de instalação dele é muito parecido com o do TestLink. Tente usar o post do SemBugs para integrar com o Mantis.

Exercício proposto 2: Quer saber se entendeu como é elaborar casos  e cenários de teste baseados em um caso de uso? Recomendo baixar o caso de uso presente neste post e tentar extrair os cenários. Comparar com o que estamos mostrando aqui. Após extrair esses cenários, tente gerar os casos de teste para todos eles.

Exercício proposto 3: Tente descobrir mais alguns casos de teste usando a técnica de valores limites discutida acima. Dessa vez, considere a possibilidade de a data final não ser cadastrada. Use a representação matemática de intervalos para te ajudar. Desenhe mais.

Nota: A versão que eu usei nesse tutorial, a 1.9 Plague está com um grande problema de performance. Recomendo que utilise a versão 1.9.1, disponível no site da TeamST, em que eles informam que o problema foi solucionado.

Agradecimento:
Agradeço primeiramente a todos os leitores que divulgam esse e outros posts do Blog The Bug Bang Theory, que me incentivam e sempre gastam um tempinho para comentar aqui em baixo. Agradeço especialmente também a equipe da TeamST, que disponibiliza o TestLink gratuitamente, sempre com muita qualidade e com muita democracia.

Muito obrigado aos meus amigos  Fabíola Lara e Vanessa Vaz que revisaram todo o conteúdo e são meus cúmplices nos erros de português e possíveis bugs nas ilustrações rsrs, além de me ajudar com partes dos textos e testes do que eu escrevo aqui.

Agradeço também aos meus colegas, como o Elias Nogueira, o Fabrício Campos, o José Correia e a Iterasys, as especialistas Eliza e Vivian entre vários outros blogueiros e apoiadores da mesma causa que eu, com quem eu aprendo tanto :)

Referências sobre o TestLink:

Como último presente, deixo aqui alguns blogs que falam sobre testlink e gestão de teste:

www.teamst.org – Site da equipe que mantém o TestLink.
www.bugbang.com.br – Meu blog, que contém muitas coisas bacanas sobre customizações e gambiarras conceituais para o TestLink.
www.sembugs.blogspot.com – Blog do Elias Nogueira que contém várias publicações até referidas aqui.
www.testexpert.com.br – Vários artigos legais e alguns deles sobre ferramentas opensource.
Vários links na barra de links deste blog.

http://www.zezologs.org/blog/ferramentas-de-teste-testlink/

Fico aberto para correções, dúvidas, críticas e sugestões sobre esse ou qualquer outro conteúdo usado aqui.

Bons testes :)

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

67 thoughts on “Especial: TestLink 1.9

  1. Olá! Estou com um problema no horário do testlink. Já verifiquei no BD e o horário está correto, no server também. Sabem me dizer como configurar os horários? Já segui o manual e mesmo assim não funcionou.

  2. Prezado,

    Estou com problemas na instalação do Testlink. Será que pode ajudar?

    No passo dois da instalação reporta:
    Warning: require_once(C:\wamp\www\testlink\lib\functions/../../third_party/phpmailer\class.phpmailer.php): failed to open stream: No such file or directory in C:\wamp\www\testlink\lib\functions\email_api.php on line 25

    e em seguida:
    Fatal error: require_once(): Failed opening required ‘C:\wamp\www\testlink\lib\functions/../../third_party/phpmailer\class.phpmailer.php’ (include_path=’.;C:\php\pear;.;C:\wamp\www\testlink\lib\functions\;C:\wamp\www\testlink\lib\issuetrackerintegration\;C:\wamp\www\testlink\lib\reqmgrsystemintegration\;C:\wamp\www\testlink\third_party\’) in C:\wamp\www\testlink\lib\functions\email_api.php on line 25

    como posso corrigir corretamente?

    Grato
    Rodrigo Hagstrom

  3. Olá Cristiano,

    Faz algum tempo que não trabalho mais com testlink, logo não sei te informar. Mas eu daria uma olhada nas configurações de administrador ou preferências.

    Boa sorte.

  4. Bom dia.
    Estou com três coisas para verificar se o Testlink permite, vc poderia em ajudar?
    1 – Testlink permite incluir botão imprimir ou exportar resultado para excel na tela Casos de teste criados por usuário na especificação de testes?
    2 – Testlink não exibe o relatório de Métricas de Consulta, você sabe informar como faço para exibir esta tela?
    3 – Você sabe se existe uma planilha de excel com macro para enviar os casos de testes para o Testlink?
    Versão do Testlink 1.9.9.
    Obrigada.

  5. Boa tarde, na versão do Test Link 1.9.9 não aparece mais o relatório métricas de consulta. Como faço para o mesmo apareça novamente?

  6. Olá, a versão do Testlink 1.9.9 não tem disponível “relatório de Métricas de Consulta”. Existe alguma forma de fazer o mesmo ser exibido novamente?

  7. Boa tarde ! Estou pesquisando algumas possíveis funcionalidades do testlink, como o uso para ferramenta de QA, Gostaria de saber se existem outras funcionalidades em que podemos utilizar a ferramenta testlink ?

    Muito obrigada.

  8. Amigo quando clico em PHPMyAdmin nao abre o localhost da erro e por isso nao consigo instalar o testlink

  9. Bom dia Camilo.
    OLhei hoje teu material sobre a release 1.9 do testlink que diga-se de passagem está excelente.
    Vi um comentario sobre umpost que ias fazer (ou fez e não achei) da mrigração do 1.8 para 1.9.. Que é meu problema.
    Sou analista de testes e estou dentro de um cliente, onde usamos a release 1.8.4, e gostaria de atualizar. Não serei eu o executor, mas se possivel,gostaria de todo o material possivel, para não perder, meus “velhos casos de Testes”, que não são poucos… e sei que tem incompatibilidade nesta exportação.
    Agradeço sua atenção,
    Um abraço fraterno
    Clid Carvalho
    Analista de Testes
    Porto Alegre
    Rio Grande do Sul
    Brasil

  10. Perfeito, documento igual a esse não se encontra na internet.

    Cara, achei importante quando mencionou o ambiente de teste. Algumas empresas onde se tem um produto e várias versões diferentes, realizar os testes destas versões na mesma máquina compromete os testes completamente.

    Para resolver este problema, criei uma estrutura em Hyper-V (vejo que utiliza a mesma tecnologia) e para cada versão do sistema temos uma VM. Esta estrutura eu denominei de Laboratório Virtual. Através desta estrutura, além de realizar os testes manuais, é possível realizar testes automatizados de forma distribuída (no meu caso, estou usando o TestComplete e TestExecute) e funciona de forma fantástica.

    Ainda estou terminando de ler o seu texto, mas até onde eu li, é muito conhecimento para absorver.

    Parabéns!
    Luciano

  11. Boa tarde Camilo, tudo bem?

    Estou com um problema pós instalação do TestLink v.1.9.11. Ao criar um novo projeto de teste, o campo “Descrição do Projeto” é exibido sem a possibilidade de edição, ou seja, o label “Descrição do Projeto” é exibido, porém o Edit, onde as informações contendo a descrição, não está habilitada para o mesmo. Você já se deparou com um cenario desses? Teria como me ajudar?

    Agradeço a atenção.

  12. Respondendo o Rodrigo Hagstrom, verifica se teu php é compatível com a versão do testlink, geralmente o problema é uma função do php que não é mais usada na versão nova, ou uma verão antiga que não tem suporte a função usada.

  13. Boa tarde, gostaria de saber como faço pra configurar para um servidor que mais de uma pessoa possa acessar simultaneamente de máquinas diferentes. Ambiente empresarial mesmo. Obrigado.

  14. Boa tarde, como faço para disponibilizar apenas a aba de resultados?. Não é possivel que esta ferramenta nãodeixa fazer isto!!!.. Já não chega ela não te dar a opção de atachar uma imagem sem a necessidade de salvar!!!!.. Ela deveria no minimo permitir isto para maximizar as atividades tendo em vista que o CMMI exige evidencias dos testes.. O fato de ficar capturando, salvando, e depois anexando uma imagem é terrivel!!!..

  15. Ola Silvio,

    Obrigado pela visita e pelo comentário.

    Infelizmente eu não posso ajudá-la com essa questão, dado que eu não trabalho com o testlink a vários anos.

    Camilo,

  16. Brother, vê se você pode me dar uma mão, estou locado em um novo cliente, e eles estão utilizando a versão 1.9.12, e não encontro o relatório “Métricas de consulta”, utilizei por muito tempo a versão 1.8 e sempre utilizava esse relatório , na minha opinião o melhor para dar um feedback para a equipe, sabe algo a respeito? se ele não tem realmente nessa versão, desde já agradeço.

Leave a Reply