Especial_ TestLink 1

2/2/2014

Especi al : TestLi nk 1.9 | The Bug Bang Theor y

The Bug Bang Theory

Especial: TestLink 1.9 Posted 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 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: Caetano : http://testexpert.com.br/?q=node/795 Para quem já conhece o T estLink, 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, Baixando, Instalando, Configurando e Integr ando: Baixando:

Wamp 2.1*: http://ww http://www.w w.wampserver.com/en/download.php ampserver.com/en/download.php TestLink 1.9: 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 a s versões mais novas do wamp e do TestLink. O TestLink é um sistema desenvolvido pelo TeamST (http://www.teamst.org (http://www.teamst.org)) e mantido no SourceForge (http://sourceforge.net/projects/testlink/files ( 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 baixar o Wamp, instale-o com as opções default . Configuração usada nesse tutorial: WampServer 2.1i (Apache 2.1i (Apache 2.2.17, PHP 5.3.3, MySQL 5.5.8 , PHPMyAdmin PHPMyAdmin 3.2.0.1 e SqlBuddy 1.3.2) e Windows Seven Ultimate. Ultimate. A instalação vai criar um diretório chamado wamp wamp na sua raiz (ou no local que indicar para instalação), dessa forma terá “C:\wamp” (Vamos usar “C:\wamp” “C:\wamp” como padrão neste tutoria l). 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 ta mbé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”, feliz”, deixando eventuais problemas para os comentários deste post ou r eferências que serã o anexadas durante a evolução deste blog ou em outros blogs do mesmo assunto. Vários progr amas podem causar interferencia, p or exemplo o Skype, o VSTS 2010 e até mesmo o jogo WoW, por isso, tente u sar 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 PHPMyAdmin citado anteriormente e solicite “Criar n ovo 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 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.

http://www.bug bang .com.br /especi al - testl i nk- 1- 9/

1/28

2/2/2014

Especi al : TestLi nk 1.9 | The Bug Bang Theor y

Extraia o con teúdo do zip do TestLink e renomeie a pasta extraída para “te stlink”, ficando assim “C:\wamp\www Extraia “C:\wamp\www\testlink”. \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 atu aliz alizar ar uma versão já e xis xistente, tente, 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 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 u sando a máquina local e o MySql como como banco de da dos. 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”.

http://www.bug bang .com.br /especi al - testl i nk- 1- 9/

2/28

2/2/2014

Especial: TestLink 1.9 | The Bug Bang Theory

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:

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

3/28

2/2/2014


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 se gurança : Vá até a linha “ $tlCfg->config_check_warning_mode = ‘FILE’;” e modifique o “F ile” 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 e mpresa 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 a spas simples. Esse texto será apr esentado

na tela de login. Na imagem abaixo podem ser vistas algumas das mudanças, ressaltando esta.


4/28

2/2/2014


Ordenação alfabética dos projetos : Vá até a linha “ $tlCfg->gui->tprojects_combo_order_by = ‘O RDER 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 M ancardi) : 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 pr ojeto. Projeto: Segundo o PMBoK, “Um projeto é um esforço temporár io empreendido para criar um produto, ser viç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”.


5/28

2/2/2014


New : Na imagem acima já podemos ver uma das fu ncionalidades interessantes do T L1.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 recur so 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 produt o 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 rar os 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 .


6/28

2/2/2014


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 org anizaçã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 re lató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 u so, 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 d e 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 Te stLink 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. http://www.bugbang.com.br/especial-testlink-1-9/

7/28

2/2/2014


Em Fluxos do sistema e Exceções, vamos criar re quisitos informacionais, respectivamente para Fluxos alternativos e fluxos de exceção. Os r equisitos informacionais são abstratos, apena s 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 regr as e exceções como “relacionado a” em cada um dos fluxos alternativos e ao principal e as regr as 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 regr as 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 elabor ação de cenários e casos de teste ), mas vale a pena explicar como ficou na fer ramenta. Agora, criamos uma suíte que r epresenta 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:


8/28

2/2/2014



9/28

2/2/2014


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 pa rtir 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 u m desses exercícios seria um cenário diferente. Mas é conhecido qu e é 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 segu inte:

Agora que temos a estrutura completa, podemos criar os nossos casos de teste. Para criar bons casos de teste te mos 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 or ganizaçã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- O título permite um texto com até 100 caracteres alfanuméricos, é interessante colocar uma descrição be m 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 ofere ce 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 te mpo restrito, o teste p ossa 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. http://www.bugbang.com.br/especial-testlink-1-9/

10/28

2/2/2014


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 tor nar nossos casos de teste viciados em telas de sistema, não sendo n ecessá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 e xiba 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, reapr oveitando os passos já cadastr ados. Para quem não conhe ce, 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 de zenas de conjuntos de dados. Se o T L implementar isso, se torna uma ferr amenta Open Source com altíssima produtividade para testes manuais, inclusive, ficando muito próxima, se não empatada com o VSTS2010 (não consider ando 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 soft ware confiavel para ter mais certeza que o cálculo esteja correto, se ge rar um relatório a nexe um relatório exemplo de como o relatório será gerad o, 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, d o 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.


11/28

2/2/2014


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 cor reto da técnica de valores limites. Durante muito tempo usei esse exemplo nas entrevistas que eu pa ssava 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) sobr e 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 r egra 07, a quela 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 é p ensar 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 lequ e de possibilidades a mais que pode mos 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.


12/28

2/2/2014


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 posterior es 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 requ isitos treinados e pront os para escrever sempre com o máximo de detalhes, deveria po ssuir um fluxo de exceção diferente n o 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:


13/28

2/2/2014


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ár ios, 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 dr opdown, a folha que deseja.


14/28

2/2/2014


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 te stes:

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 coorde nador 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:


15/28

2/2/2014


O ideal para o cadastro de p lataformas, é 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 par a evitar problemas durante essa fase. Um novo recurso muito bacana do testlink, é qu e 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 te stes 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”.


16/28

2/2/2014


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.


17/28

2/2/2014


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


18/28

2/2/2014


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 agor a temos uma funcionalidade para marcar e desmarcar todas as o pçõ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 r equisitos 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 n essa nova versão:

Executando na prática: O dia a dia otimizado do te stador:

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 a tribuídos pra mim” ficou melhor. Agora é possível ter em uma tela, um conjunto de “tarefas”, considerando plata forma, 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.


19/28

2/2/2014


No novo painel de execução são mantidos o layout e os filtro s da versão anter ior, 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.


20/28

2/2/2014


A maneira de executar o teste não mudou. Você executa os testes, fica atento às regras, informa o resultado, cada stra 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 te ste não só te r esguarda 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ê http://www.bugbang.com.br/especial-testlink-1-9/

21/28

2/2/2014


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 d ele, 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 p ode 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 na s 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. Quand o 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 t estes executados e mostramos que realmente trabalhamos e geramos arte fatos. 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).


22/28

2/2/2014


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, aq ui 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 r elatório “SQL” do TestLink. Nele você consegue pesquisar combinações “loucas” que só fazem sentido para sua org anização. Esse pra mim é um relatório que pode ser chamado de relatório coringa.


23/28

2/2/2014


Matriz de resultados de teste mostra de maneira de talhada o status da execução dos casos de teste nas últimas versões. No exemplo abaixo não par ece muito útil, mas quando temos uma dezena de releases esse relatór io pode nos ajudar a identificar casos de te ste 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.


24/28

2/2/2014


Os gráficos do T estLink continuam pouco atrativos e p ouco úteis na minha opinião. Eles trazem basicamente as informações de total de te stes 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ór io baseado em requisitos, mas acho legal fa lar 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 r equisitos 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 de vo 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 pa sso de acordo com o de scrito 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 ent endeu 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 de scobrir mais alguns casos de teste u sando a técnica de valores limites discutida acima. Dessa vez, considere a p ossibilidade de a

data final não ser cadastrada. Use a representação matemática de intervalos para te ajudar. Desenhe mais. http://www.bugbang.com.br/especial-testlink-1-9/

25/28

2/2/2014


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 T eamST, 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 t este: 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 par a 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 Curtir

Tags:

10

Ferramentas

3

Share

Gerência de Teste

Tweetar

Técnicas de Teste

4

TestLink

54 Responses to “Especial: TestLink 1.9” 1.

Cristiano September 25, 2013 Olá! Estou com um problema no ho rário do testlink. Já verifiquei no BD e o horário está correto, no server também. Sabem me dizer como configurar o s 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/php mailer\class.phpmailer.php): failed to open stream: No such file or d irectory 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 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.

← Older comments

Comente :) Nome (requir ed)

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

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

26/28

2/2/2014


Comentario

Postar Comentário Spam Protection by WP-SpamFree

Bem vindo ao The Bug Bang Theory! Meu nome é Camilo Ribe iro e eu tr abalho com teste e desenvolvimento de software desde 2 005, 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, ajudandoo(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

Agile

"Bugs" da Atualidade

Automação de Testes Base2 BDD Belo Horizonte Blog Action Day BRATESTE Bug Bang BugBang

Agile Record ALATS Arquitetura

Camilo Ribeiro

Carreira

Certificação CMMI Cucumber DDT Dimmunix Engenharia de Requisitos Engenharia de Software Eventos 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 Responde Bugs

Ferramentas ThoughtWorks

Caso de Teste

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 http://www.bugbang.com.br/especial-testlink-1-9/

27/28

2/2/2014


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 Te st 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


28/28

Especial_ TestLink 1

Recommend Documents