2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 1/28

The Bug Bang Theory

Especial: TestLink 1.9Posted on February 27, 2011 at 12:14 AM.

Written by Camilo Ribeiro

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 2/28

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”.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 3/28

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:

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 4/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 5/28

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”.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 6/28

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 .

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 7/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 8/28

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:

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 9/28

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 10/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 11/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 12/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 13/28

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:

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 14/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 15/28

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:

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 16/28

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”.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 17/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 18/28

“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”

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 19/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 20/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 21/28

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ê

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 22/28

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).

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 23/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 24/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 25/28

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.

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 26/28

10Curtir 3 Tweetar 4

← Older comments

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

Tags: Ferramentas Gerência de Teste Técnicas de Teste TestLink

54 Responses to “Especial: TestLink 1.9”

1. Cristiano September 25, 2013

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. Rodrigo Hagstrom October 17, 2013

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. Camilo Ribeiro October 29, 2013

Olá Rodrigo,

Desculpe, mas não sei como te ajudar

Boa sorte.

4. Camilo Ribeiro October 29, 2013

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.

Comente :)

Nome (required)

Email (não será publicado) (required)

Website

Share

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 27/28

Comentario

Postar Comentário

Spam Protection by WP-SpamFree

Bem vindo ao The Bug Bang Theory!

Meu nome é Camilo Ribeiro e eu trabalho com teste e desenvolvimento de software desde 2005, atualmente como Software Test Engineer na

Klarna AB em Estocolmo, Suécia.

Eu acredito em testers técnicos, nos valores do desenvolvimento ágil, que automação de testes pode ser o melhor amigo do ou da tester, ajudando-

o(a) a ser mais criativo(a) e produtivo(a) e eu gosto muito de discutir (e implementar) as melhores soluções para problemas durante o desenvolvimento de

aplicações.

Obrigado pela visita!

Tags

"Bugs" da Atualidade Agile Agile Record ALATS Arquitetura Automação de Testes Base2 BDD Belo Horizonte Blog Action Day BRATESTE Bug Bang BugBang

Responde Bugs Camilo Ribeiro Carreira Caso de Teste Certificação CMMI Cucumber DDT Dimmunix Engenharia de Requisitos Engenharia de Software Eventos

Ferramentas Game Testing Gerência de Teste Gestão de Defeitos Google História IA IBM Rational ISTQB Java JMeter JUnit Linux Livros Notícias OFF TOPIC

Palestras Performance Praxis Processos Programação QA Ruby SCRUM Segurança Selenium Social Squadra Tecnologia TDD Tecnologias Microsoft TestExpert TestLink

ThoughtWorks Técnicas de Teste UFMG Watir Webdriver XP

Arquivo

2013 (4)

2012 (13)

2011 (14)

2010 (26)

2009 (13)

Mais lidos

Especial: TestLink 1.9 (15,926)

Um Modelo para Elaboração de Cenários e Casos de Teste (9,832)

Exibindo evidências de teste no TestLink (3,447)

Usando TestLink para Garantia de Qualidade (3,018)

Vocabulário básico para testadores ágeis (2,826)

Entendendo BDD com Cucumber – Parte I (2,774)

Teste de unidade para quem não sabe nada de programação (2,363)

Aprendendo automação sem cursos caros (2,149)

Destilando JMeter I: Introdução e Conceitos (2,098)

Penso, logo automatizo (1,999)

Lista de Links

Agile Tips – Paulo Caroli

Architecture Journal – Ricardo Ferreira

Artesanato de Software com Renan Reis

As Especialistas

ASP.NET, Flash, Flex, AS3 e Tecnologia por Lucas Lorentz

Base de Teste de Software

Blog da Iterasys

Blog do Gustavo Quezada

Blog do Jailton Alkimin Louzada

Blog do Thiago Ghisi

Code Between Lines

CrowdTest

2/2/2014 Especial: TestLink 1.9 | The Bug Bang Theory

http://www.bugbang.com.br/especial-testlink-1-9/ 28/28

Elemar DEV – Tecnologia e desenvolvimento .net

Ensaios de Qualidade

Essence of Testing

Finito – Paulo Vasconcellos

Google Testing Blog

GUTS-RS

Java, Selenium e Coca Cola

Leandro Moreira's Blog

Marcos Sousa' Blog

Nerds On

O Mundo pede novos líderes

Qualidade Manaus

QualidadeBR – Fabrício Ferrari

SemBugs – Elias Nogueira

Software Test and Performance Magazine

Test=>Next (Laís Berlatto)

Teste de Software e Métodos Ágeis

Teste de Software e Utilidades

TestExpert

Testing from below the tropics by Felipe Knorr Kuhn

The Lady Bug Blog

The Shaolin of testing

ThoughtWorks

ThoughtWorks Testing Blog

UFMG – Universidade Federal de Minas Gerais

Vinicius Sabadoti – Teste de Software

Zarro Boogs Found

Latest 20 posts

IceCream e a fábrica de testes inteligente

Destilando JMeter I: Introdução e Conceitos

12 Lições aprendidas em Testes de Performance Server Side

Hoje um Leitor, Amanhã um Líder

Livros Recomendados #2: How Google Tests Software

Testes Baseados em Riscos com Google Test Analytics

Aprendendo automação sem cursos caros

Agile Brazil 2012: Boas Práticas de Teste Automatizado

Voto Como Vamos: Ágil, Open-Source e One-Click Deploy sem custo

The Developers Conference: O Mundo Precisa de QAs Técnicos!

Livros recomendados #1: Agile Testing – A Practical Guide for Testers and Agile Teams

ThoughtWorks Brasil Tech Radar – O Test Radar

Porque bloggar não é fácil?

Vida de um Agile Tester – Parte I

BugBang Responde I: Horas x Qualidade (A eterna briga das empresas)

Porque eu voaria em um avião desenvolvido de forma ágil

Entendendo BDD com Cucumber – Parte I

Notas sobre o Curso Certified ScrumMaster (CSM)

Penso, logo automatizo

The Bug Bang Theory 2.0 – Agile and Technical Testing Rocks!

© 2014 The Bug Bang Theory