The Bug Bang Theory

(9 votes, average: 9,33 out of 10)

 Loading ...

Testes de unidade são uma realidade cada vez mais próxima das nossas fábricas de software, porem, é uma das coisas que tanto os profissionais de teste quando os profissionais de desenvolvimento desconhecem em sua maioria. Melhor dizendo, conhecer todos conhecem, mas ver funcionando, saber fazer e principalmente acreditar no benefício, não.

É um pouco difícil achar exemplos em blogs, sites ou comunidades de desenvolvimento e/ou testes, principalmente em português, mas um ótimo exemplo da aplicação de testes de unidade usando a ferramenta Visual Studio, para a plataforma .Net, está no excelente post “VSTS – Visual Studio Team System para Testadores – Unit Test” do Gustavo Quezada. No post ele descreve muito bem um resumo sobre o momento dos testes de unidade e também como aplicá-los tecnicamente.

Vou tentar elaborar aqui uma visão baseada em TDD (Test-driven development) usando a solução mais usada para Java, o Framework de testes de unidade JUnit, Desenvolvido por Kent Beck (XP) e Erich Gamma (GoF).

Primeiramente vamos pensar em como deve ser o micro processo para a implementação de TDD em alto nível:
1 – Escrever os Testes
2 – Executar os testes e verificar as falhas
3 – Escrever o código
4 – Rodar os testes para identificar sucesso
5 – Refatorar o código para corrigir defeitos e efetuar melhorias

Agora vamos ver isso funcionando:

1 – Escrever os Testes:
É premissa para a escrita dos testes termos todos os requisitos especificados e detalhados de forma a podemos avaliar os dados de entrada e os resultados esperados. Se você é um analista de teste já deve ter notado uma semelhança. A composição básica do nosso teste de unidade é a mesma dos nossos casos de teste, porem, ao escrever testesde unidade não nos preocupamos com as pré condições, procedimentos de teste e outros detalhes. Nosso objetivo aqui é claro: Fornecer o que a classe que será escrita precisará e receber o que ela nos fornecerá.

Vamos supor que a lista de requisitos da nossa classe é a seguinte:
“O programa deve ler 3 números inteiros. Os três valores serão  interpretados como os comprimentos dos lados de um triângulo. O programa imprime uma mensagem sobre o tipo do triângulo”

Vamos pensar em algumas opções de respostas que podemos ter:
a – Se for isósceles
b – Se for equilátero
c – Se for Escaleno
d – Se a soma de dois lados for igual a do terceiro
e – Se a soma de dois lados for menor a do terceiro

Podemos listar também algumas opções de exceções:
a – Se algum lado for negativo ;
b – Se todos os comprimentos do triânngulo forem zero;
c – Se algum comprimento do triângulo for zero;

Enfim, para isso podemos criar inúmeros casos de teste, mas para esse exercício vamos escrever apenas 14 (quatorze) considerando que o usuário sempre vá entrar com valores numéricos.

Abaixo os “casos de teste” ainda em formato texto:
1 – Triângulo Escaleno
2 – Triângulo Equilátero
3 – Triângulo Isósceles
4 – Triângulo Isósceles
5 – Triângulo Isósceles
6 – Triângulo com Lado Nulo
7 – Triângulo com Lado Negativo
8 – Triângulo cuja soma dos lados A e B é igual a C
9 – Triângulo cuja soma dos lados A e C igual a B
10 – Triângulo cuja soma dos lados C e B igual a A
11 – Triângulo cuja soma dos dois lados menor que a terceiro”}
12 – Triângulo onde todos os lados são Nulos
13 – Triângulo cuja soma dos lados A e B é menor que C
14 – Triângulo cuja soma dos lados B e C é menor que B

Abaixo vamos escrever os dados de entrada o que esperamos com eles usando a seguinte sintax
(entradaA, entradaB, entradaC, resultadoEsperado), sendo que as entradas devem ser inteiros e o resultado uma String
1 – {2, 9, 10,”Escaleno”}
2 – {20, 20, 20, “Equilátero”}
3 – {20, 20, 30, “Isósceles”}
4 – {20, 30, 20, “Isósceles”}
5 – {30, 20, 20, “Isósceles”},
6 – {0, 2, 9, “Lado Nulo”}
7 – {3, -2, 9, “Lado Negativo”}
8 – {5, 6, 11, “Soma dos dois lados igual a terceiro”}
9 – {5, 11, 6, “Soma dos dois lados igual a terceiro”}
10 – {11, 6, 5, “Soma dos dois lados igual a terceiro”}
11 – {5, 6, 12, “Soma dos dois lados menor que a terceiro”}
12 – {0, 0, 0, “Todos os lados Nulos”}
13 – {5, 12, 6, “Soma dos dois lados menor que a terceiro”}
14 – {12, 5, 6, “Soma dos dois lados menor que a terceiro”}

É muito importante entender que o teste de unidade tem menos valor se aplicado após a classe estar escrita, principalmente porque a sua principal finalidade, economizar tempo na implementação da classe deixa de ser aproveitada, ficando somente os testes “de unidade de regressão” para modificações da classe. Portanto, é fundamental escrever os casos de teste antes mesmo que a classe que será testada, para essa atividade, é muito recomendável que o analista de teste e programador trabalhem juntos, pensando em caminhos e entradas que poderão ser usados na futura implementação.

Para escrever o teste vamos precisar do Eclipse e do JUnit.
O JUnit pode ser baixado no link:  http://sourceforge.net/projects/junit/files/junit/ e incluído nas libraries do Java Build Path do projeto do eclipse.

Agora vamos entender o básico dos métodos (notation ) do JUnit:
@RunWith: Quando uma classe tem a notation @RunWith ou estende uma classe com o predecessor com @RunWith, JUnit irá chamar a classe que faz referência para executar os testes em que a classe em vez de o corredor construído em JUnit. Podemos implementar uma Suite de Testes com o parâmetro Suite.class ou uma lista de parâmetros com o parâmetro Parameterized.class (que será usada no nosso exemplo).

@Parameters: A notation de um método que cria uma coleção, array, lista ou outra estrutura de dados, de forma a garantir que não precisemos de vários métodos para executar uma sequencia ordenada de testes, através de uma sequencia de parâmetros que serão enviados, um a um, para o construtor da classe ao instânciar um objeto (teste).

@Test: A notation do método que realiza o teste. Normalmente esse método instância o objeto da classe que será testado e realiza comparações.

org.junit.Assert.*: Os métodos de comparação. realizam várias comparações como mostrado abaixo:
assertTrue : Verifica se o valor de retorno é true
assertFalse : Verifica se o valor de retorno é false
assertEquals : Compara dois valores de retorno
assertNotNull : Verifica se o valor de retorno não é null
assertNull : Verifica se o valor de retorno é null
assertSame : Confere se dois objetos referenciam o mesmo objeto
assertNotSame : Confere se dois objetos referenciam objetos diferentes
fail : usado para criar falha no teste via programação do teste

Para a lista completa dos métodos assert: http://www.junit.org/apidocs/org/junit/Assert.html
API completa do JUnit: http://www.junit.org/apidocs/

Agora vamos ver a classe de teste desenvolvida com base nos nossos dados de entrada e devidamente comentada para facilitar o entendimento:

// Importamos as classes que precisamos para usar os métodos citados

// Importante importar essa como static, pois usamos os métodos estáticos para realizar as comparações.
import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

/* Usar o RunWith informando que vamos usar uma classe parametrizada.
*  Isso fará com que ao ser instanciada como JUnit Test, a classe crie um objeto usando os parâmetros informados
*  no método Parameters para realizar cada teste, economizando dezenas de linhas de código.
*/
@RunWith(Parameterized.class)

//Declaramos uma classe normal
public class TesteExemplo {

// Declaramos os inteiros que representarão os lados do triângulo
private int a;
private int b;
private int c;

// Declaramos a string que representará o resultado esperado
private String tipo;

// Criamos o construtor que receberá os parâmetros para execução do teste
public TesteExemplo(int a, int b, int c, String trianguloEsperado) {
super();

// Cada lado do triângulo recebe um valor que vem dos parâmetros da classe
this.a = a;
this.b = b;
this.c = c;

// O resultado esperado recebe o ultimo parâmetro
this.tipo = trianguloEsperado;
}

// Método que retorna uma coleção com os parâmetros que serão usados no construtor instânciado para os testes
@Parameters
public static Collection carregaTriangulosDeTeste(){
return Arrays.asList(
new Object [][]{

// Como array em Java começa no 0, vamos incluir o teste 1 na posição 0 do array e assim por diante

//Test0
{2, 9, 10,"Escaleno"},

//Test1
{20, 20, 20, "Equilátero"},

//Test2
{20, 20, 30, "Isósceles"},

//Test3
{20, 30, 20, "Isósceles"},

//Test4
{30, 20, 20, "Isósceles"},

//Test5
{0, 2, 9, "Lado Nulo"},

//Test6
{3, -2, 9, "Lado Negatívo"},

//Test7
{5, 6, 11, "Soma dos dois lados igual a terceiro"},

//Test8
{5, 11, 6, "Soma dos dois lados igual a terceiro"},

//Test9
{11, 6, 5, "Soma dos dois lados igual a terceiro"},

//Test10
{5, 6, 12, "Soma dos dois lados menor que a terceiro"},

//Test11
{0, 0, 0, "Todos os lados Nulos"},

//Test12
{5, 12, 6, "Soma dos dois lados menor que a terceiro"},

//Test13
{12, 5, 6, "Soma dos dois lados menor que a terceiro"},
}
);

}

// Método que executa o teste a cada instanciação do objeto da classe teste
@Test
public void validaTriangulo() {
// Vamos criar um objeto do tipo Trianglulo (nossa futura classe que ainda vai existir) e passar os parâmetros do seu construtor
Triangulo escalenoValido = new Triangulo(a, b, c);

// Realizamos a comparação entre o valor que foi retornado e o valor que é esperado
assertEquals(escalenoValido.retornarTipo(), tipo);
}
}

2 – Executar os testes e verificar as falhas

Agora vamos executar a primeira vez e verificar o que o JUnit nos retorna:

É importante que todos os testes falhem, para termos certeza que estão corretos (irônico não?). Isso porque os resultados esperados não podem existir, já que nem a classe do objeto que vamos testar existe.

3 – Escrever o código

Agora vou escrever uma classe com alguns erros de lógica e outros no conteúdo da resposta:

public class Triangulo {

private int a, b, c;

public Triangulo(int a, int b, int c) {
this.a = a;
this.b = b;
this.c = c;
}

public String retornarTipo() {

// erro de lógica
if((this.a == 0) || (this.b == 0) || (this.c == 0))
return "Todos os lados Nulos";

if((this.a == 0) || (this.b == 0) || (this.c == 0))
// Erro no retorno
return "Lado Núlo";

if((this.a < 0) || (this.b < 0) || (this.c < 0))
return "Lado Negatívo";

if((this.a == this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b == this.c))
return "Equilátero";

if(
((this.a != this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b == this.c))||
((this.a == this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b != this.c))||
((this.a == this.c) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.b != this.c))
)
// Erro no retorno
return "Isóceles";

if( (this.a + this.b == this.c)||
(this.b + this.c == this.a)||
(this.c + this.a == this.b)
)
return "Soma dos dois lados igual a terceiro";

if( (this.a + this.b < this.c)||
(this.b + this.c < this.a)||
(this.c + this.a < this.b)
)
return "Soma dos dois lados menor que a terceiro";

if((this.a != this.b) &amp;amp;amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp;amp;amp; (this.a != this.c))
return "Escaleno";

return null;
}
}

4 – Rodar os testes para identificar sucesso

Agora vamos verificar a nova execução do testede unidade:

Na imágem acima  podemos ver que o teste nos retorna três informações muito importantes:
1 – Quantos casos de teste de unidade passaram;
2 – Quais casos de teste de unidade passaram;
3 – Qual a diferença entre o resultado esperado e o resultado recebido

Essa ultima informação em especial é que dá o “caminho das pedras” para o desenvolvedor corrigir com maior facilidade.

5 – Refatorar o código para corrigir defeitos e efetuar melhorias

Efetuamos as melhorias:

import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)

public class TesteExemplo {

private int a;
private int b;
private int c;

private String tipo;

public TesteExemplo(int a, int b, int c, String trianguloEsperado) {
super();
this.a = a;
this.b = b;
this.c = c;
this.tipo = trianguloEsperado;
}

@Parameters
public static Collection carregaTriangulosDeTeste(){
return Arrays.asList(
new Object [][]{
//Test0
{2, 9, 10,"Escaleno"},

//Test1
{20, 20, 20, "Equilátero"},

//Test2
{20, 20, 30, "Isósceles"},

//Test3
{20, 30, 20, "Isósceles"},

//Test4
{30, 20, 20, "Isósceles"},

//Test5
{0, 2, 9, "Lado Nulo"},

//Test6
{3, -2, 9, "Lado Negatívo"},

//Test7
{5, 6, 11, "Soma dos dois lados igual a terceiro"},

//Test8
{5, 11, 6, "Soma dos dois lados igual a terceiro"},

//Test9
{11, 6, 5, "Soma dos dois lados igual a terceiro"},

//Test10
{5, 6, 12, "Soma dos dois lados menor que a terceiro"},

//Test11
{0, 0, 0, "Todos os lados Nulos"},

//Test12
{5, 12, 6, "Soma dos dois lados menor que a terceiro"},

//Test13
{12, 5, 6, "Soma dos dois lados menor que a terceiro"},
}
);

}
@Test
public void validaTriangulo() {
Triangulo escalenoValido = new Triangulo(a, b, c);
assertEquals(escalenoValido.retornarTipo(), tipo);
}
}

Agora efetuamos as melhorias necessárias e re-executamos os casos de teste até que todos passem:

Esse foi um exemplo de implementação de teste de unidade ou teste de unidade inspirados em TDD, prática ágil muito eficaz na identificação de defeitos. Nem todas as implementações são tão fáceis, ou gastam pouco tempo, mas, com o tempo e alguma prática, esse tipo de atividade pode se tornar menos custosa e mais eficiente.

Peço desculpas se algum conceito apresentado acima está divergente das melhores práticas ou de algum padrão ou conceito, e me prontifico a efetuar quaisquer correções. O exemplo citado aqui é ilustrativo.

TDD, testesde unidade, automação de testes funcionais e de performance, entre outras áreas das disciplinas de Teste de Software e Arquitetura de Software ainda são muito misteriosas e discutidas, mas pouco implementadas, principalmente aqui no Brasil. Porem, é muito importante que nossos analistas de teste busquem essa capacitação técnica para melhorar a nossa posição no mercado, melhorar a qualidade do software e da mão de obra brasileira e acabar com mitos como “o desenvolvedor é um profissional mais estudioso ou mais técnico do que o teste” ou “teste é uma atividade simples de clicar e executar alguns fluxos”.

Mantenho-me disponível para quaisquer esclarecimentos

Essa atividade é baseada em um exercício em sala no curso de Especialização em Ciência da Computação com Ênfase em Engenharia de Software da Universidade Federal de Minas Gerais (UFMG) .

Bons Testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(2 votes, average: 10,00 out of 10)

 Loading ...

A alguns dias recebi um e-mail de uma amiga da comunidade de testes DFTestes (Fabiana Maronez), perguntando como usar o TestLink para gerenciar o QA (Garantia de Qualidade).
A maioria de nós certamente pensaria que é uma idéia um pouco distorcida. Usar uma ferramenta de gerência de testes para realizar QA? Mas com um pouco de criatividade e vontade de eliminar as planilhas, pensei em uma solução que pode atender o que a nossa colega solicita.

Para quem ainda não está habituado, podemos dizer que Quality Assurance (ou simplesmente QA) são atividades de auditoria que os processos baseados em modelos de melhoria como o CMMi e as ISO possuem para garantir que o processo está sendo seguido adequadamente. Para isso, normalmente são usadas planilhas e mais planilhas, com vários critérios. Essas planilhas são usadas de várias formas diferentes, desde uma para cada artefato até uma para cada projeto, mas a dificuldade de gerar relatórios e coletar indicadores quase sempre é surreal.

Obs: Para perfeita compreensão desse post, é necessário conhecimento básico em QA e na ferramenta TestLink. Recomendável também um conhecimento básico sobre CMMi.
Termos usados entre parênteses na cor verde ” (exemplo) “ simbolizam o que seria feito no TestLink em um projeto de teste.

Abaixo vou demonstrar uma forma de gerenciamento das auditorias com redução significativa do esforço:

1 – Criar um produto do TestLink para o QA.
(Criar um produto do TestLink)

É importante usar a opção  “Gerenciar Requisitos”, para futuramente usarmos rastreabilidade das práticas para os Casos de Auditoria*.
*Casos de auditoria é um nome improvisado que eu arrumei para classificar casos de teste voltados para o processo, substituindo os tradicionais critérios.

2 – Cadastrar as práticas.

(Cadastrar especificações de requisitos e requisitos)

O cadastro das práticas é opcional, mas agrega muito valor, pois facilita a compreensão do fundamento da existência de cada”caso de auditoria” . Não existe uma forma definitiva de inserir as praticas, mas no caso do CMMi, uma forma que eu achei muito interessante é criar Especificações de requisitos para cada PA (Process Area) e um requisitos para cada SG (Specific Goal) e SP (Specific Practice), como ilustrado acima.

3 – Criar os casos de auditoria
(Especificar casos de teste)
Ao criar os casos de auditoria, é importante usar o nosso conhecimento em casos de teste para definir pré-condições, procedimentos e resultados esperados, muito próximo do que fazemos com os casos de teste para nossos softwares.
Normalmente, os QAs são realizados somente com critérios, o que torna o processo de auditoria muito custoso, pois qualquer pessoa que precise realizar o QA deve antes ser muito treinada no processo e no modelo de melhoria de processos adotado. A ultilização de casos de auditoria, além de gerenciar e simplificar métricas do QA, torna o processo menos dependente de treinamento, e possivelmente adaptável para testadores ou analistas de teste, porque uma pessoa com muito conhecimento do processo e do modelo pode definir um conjunto de casos de auditoria e pessoas com menos conhecimento podem executá-los, assim como analistas de teste e testadores.

4 – Atribuindo práticas ao caso de auditoria
(Vincular requisitos aos casos de teste)
Nesse momento vinculamos as práticas que devem ser cobertas pelo caso de auditoria, de forma a criar uma rastreabilidade por prática. Isso será importante para verificar quando cada prática é coberta e quais os casos de auditoria são mais críticos.

Quando cadastramos podemos ver o caso de auditoria como a imagem abaixo:
Acima podemos ver como cada caso de auditoria fica no final de sua especificação. Com pré-condição, passos descrevendo a sequencia de ações para executá-lo, resultado esperado e práticas vinculadas.

Assim devem ser feitos todos os “critérios” usados para a auditoria. Uma vez cadastrados, podem ser editados e modificados livremente, da mesma forma que os casos de teste de projetos de software.

5 – Definindo projetos
(Criar um Plano de Teste e adicionar Casos de Teste a esse plano)
Todo o trabalho até aqui, é realizado somente uma vez, e modificado sempre que um critério ou caso de auditoria precisa fica desatualizado. De agora em diante, apenas criamos “projetos” (planos de teste do TestLink) e releases para suas auditorias. O trabalho de armazenar as informações e controlar os artefatos e evidências, fica totalmente a cargo da ferramenta.
Criamos para cada projeto que será auditado, um novo “plano de teste”, que podemos chamar de “plano de auditoria”.
Aqui “começa a mágica”. Podemos definir para cada plano de auditoria um conjunto de casos de auditoria, de forma a permitir a customização do processo.
Para isso, basta selecionar os casos de auditoria no momento de vinculá-los a cada um dos projetos, de acordo com a demonstração abaixo. No exemplo acima podemos selecionar apenas os casos de auditoria que o “Projeto para auditoria 02″ irá usar.

6 – Preparando para executar uma auditoria.
(Criar uma nova release para o plano)
Na demostração acima, ao criar uma release do TestLink estamos criando uma instancia do QA planejado para aquele projeto, ou seja, estamos permitindo a execução dos casos de auditoria para o “Projeto para auditoria 02″.

7 – Executando a auditoria.
(Executar a release)
Agora executamos cada um dos casos de auditoria. A execução é semelhante a tradicional (caso de teste). O resultado pode ser positivo (aprovado), negativo (não-conformidade) ou bloqueado (indisponível), em qualquer caso podemos tomar ações para evidenciar ou complementar a nossa execução.
Evidência de auditoria: Uma evidência como um print do documento, do registro ou qualquer tipo de arquivo que possa comprovar a auditoria pode ser vinculado ao resultado “Passou” da execução.
(Salvar um anexo a execução do caso de teste)
Não conformidade encontrada: Para as não-conformidades encontradas, normalmente é cadastrado um “bug” no bugzilla ou no mantis, de forma a não conformidade adotar o mesmo workflow dos defeitos. Se esse for o caso, podemos usar a integração Defect Tracking System/TestLink para gerenciar as não conformidades.
(Cadastrar um bug no Bugzilla, Mantis, Eventum ou qualquer outra ferramenta integrada ao TestLink)

Caso o resultado do caso de auditoria tenha sido Bloqueado, o Analista de QA deve informar o motivo do bloqueio nas notas.

8 – Visualizando sumário de auditorias.
(Resultados)
Agora temos todos os relatórios do TestLink, usados para gerenciar nossos casos de teste, aplicáveis aos casos de auditoria usados anteriormente.

Alguns relatórios interessantes:
a – Relatório baseado em requisitos:
Nesse contexto ele nos permite avaliar cada uma das práticas que devem ser atendidas pelo CMMi ou outro modelo de melhoria como ISO ou MPS.BR, do ponto de vista de cobertura por auditoria.

b – Métricas gerais do plano de auditoria:
Aqui podemos acompanhar a evolução das execuções de várias “auditorias” (releases) de uma forma simples.

Esse post foi motivado por uma não existência de uma ferramenta própria para a execução de auditorias para processos baseados em modelos de qualidade (pelo menos ao meu conhecimento), como a ISO e CMMi, em fábricas de software, onde, normalmente são usados critério difíceis de compreender, em planilhas controladas manualmente, o que causa um desperdício de produtividade e perda da qualidade.

Importante ressaltar que o TestLink não é uma ferramenta própria para essa finalidade, mas podemos aproveitar o conhecimento do TestLink para adaptar um pouco alguns conceitos, desde que seja para melhor.

Em breve devo disponibilizar os pacotes para importação com todas as PAs do CMMi Dev1.2 em CSV e outro com uma tradução especial em português usando os termos citados acima.

Estou disponível para questionamentos, críticas e sugestões.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(3 votes, average: 10,00 out of 10)

 Loading ...

Como todos sabem, o TestLink é uma ferramenta OpenSource para gerencia de Testes de Software com inúmeras funcionalidades já desenvolvidas e homologadas, mas como todas as ferramentas do mundo, não atende, por si só, todas as necessidades de uma empresa ou de um processo, por isso, a algum tempo vendo estudando os padrões dessa ferramenta e as oportunidades de melhoria.

Uma das melhorias, foi a inclusão do escopo dos requisitos no plano de teste, que já documentei no post “Exibindo corpo dos requisitos nos relatórios do TestLink“, para a versão 1.8.3, inclusive essa modificação está presente nos fontes que estão disponíveis no final desse post atualizadas para a versão 1.8.4 (incluindo as modificações descritas abaixo).

Outra razão me levou modificar a estrutura do testlink, e essa modificação eu acredito ser mais interessante que a anterior.

O testlink possui duas funcionalidades que não são integradas. Uma é o relatório de execução de teste ou simplesmente “Relatório de Teste” e a outra é o anexo de arquivos após a execução dos testes.

Para exemplificar eu criei um projeto chamado “Favorite series” e algumas suítes de teste com nomes de alguns seriados que eu assisto como The Big Bang Theory, Dexter, Flash Foward etc. Optei por usar esses casos de teste para esquecermos um pouco a implementação dos casos de teste e observarmos a nova funcionalidade sem distrações.

“Executei os testes” desse projeto e tentei cobrir as 3 condições:
-Execução sem evidência: Quando não temos evidências anexadas a execução do caso de teste
-Evidência no formato de imagem: Quando anexamos por exemplo, “o print da tela”
-Evidência em formato diferente de Imagem: Quando anexamos um arquivo qualquer como xml, rar etc.

Outras hipóteses também demonstradas:
-Quando temos múltiplas evidências
-Quando temos múltiplas evidências de tipos diferentes
-Quando temos Título na evidência
-Quando não temos Título na evidência

Primeiramente, vamos entender como é o relatório:
O TestLink nos disponibiliza a opção de emitir o relatório para execução dos testes com as seguintes  sessões:
-Mostrar índice: Exibe o índice por suítes de teste
-Descrição da Suíte de Teste: Exibe a descrição que cadastramos na criação das Suítes
-Mostrar Pré-condição: Exibe as pré-condições dos casos de teste
-Mostrar corpo do caso de teste: Exibe o passo a passo dos casos de teste
-Palavras-Chave relacionadas ao CT: Exibe as palavras chave que estão vinculadas ao caso de teste
-Campos personalizados do caso de teste: Exibe os campos customizados dos casos de teste
-Requisitos Relacionados ao CT: Exibe o título requisitos vinculados a cada caso de teste
-Corpo dos requisitos do caso de teste(*): Exibe o escopo dos requisitos vinculados aos casos de teste
-Resultado testes: Exibe o status da ultima execução do caso de teste
(*)  - Essa funcionalidade não é nativa do TestLink, para mais informações clique aqui.

Abaixo um exemplo que está descrito acima:

Se imprimirmos a suíte de teste “The Big Bang Theory” nesse modelo temos o seguinte relatório:
* A cor vermelha no Último Status “Com falha” é outra melhoria que ainda estou terminando.

As informações acima são suficientes para sabermos quem executou o caso de teste, se ele foi ou não aprovado e em qual release ele foi executado, mas para ser mais completo poderia exibir a evidência para facilitar a identificação do defeito ou para provar a execução do teste já nesse relatório.

Por esse motivo, incluí uma nova opção chamada “Evidências de teste” de acordo com a imagem abaixo:

O mesmo relatório apresentado acima, agora exibindo as evidências de teste:
Exibição da evidência sem título:
Exibição da evidência de teste com título:

*Dividi em duas imagens para facilitar a visualização e exemplificar duas situações.

Agora vou mostrar outros exemplos atendendo a nossas situações acima:
-Quando não temos evidências anexadas a execução do caso de teste

-Quando anexamos um arquivo qualquer como xml, rar etc. / Quando temos múltiplas evidências

A customização acima pode ser implementada em qualquer TestLink com algumas adaptações, ou na versão 1.8.4 apenas usando os arquivos abaixo:

Arquivos modificados:
.\testlink\lib\functions\print.inc.php
.\testlink\lib\results\printDocument.php
.\testlink\lib\results\printDocOptions.php
.\testlink\locale\pt_BR\strings.txt
.\testlink\gui\javascript\testlink_library.js

Os arquivos cima estão disponíveis para downloado no pacote Evidence.zip disponível no final do post.

Modificações:

print.inc.php
Nesse arquivo é que fazemos a maior parte das modificações, na verdade, aqui é que estão as verdadeiras modificações.
Vou separar as modificações desse arquivo em três partes:

Parte 1 :  Inclusão da Label “test_evidence”, “without_evidence” e “not_img”
Incluímos a label “test_evidence” para que a modificação fique no padrão mult-language do TestLink.

Parte 2 :  Inclusão da dos filds typeEvidence, FilePath, file_name, atttitle e de multiple touples
Incluímos os seguintes campos:

typeEvidence: tupla que indica qual o tipo da evidência (anexo).
FilePath: caminho da evidência (anexo)
file_name: nome da evidência (anexo)
atttitle: Título da evidência (anexo)
Também mudamos o terceiro parâmetro do “get_recordset” para 999 para que exiba mais de uma evidência.

Parte 3 : lógica de exibição
Aqui informamos quando as evidências que serão exibidas , os títulos e a formatação apresentada.

Também usamos uma comparação para determinar quais são as evidências que devem ser apresentadas na linha 608.
Note que hoje, a customização aceita 3 tipos de imagens, PNG, JPG e BMP.
-Sugiro usar somente png, pois ocupa menos espaço que bmp e tem mais qualidade que jpg.

printDocument.php
Nesse arquivo vamos tornar a implementação disponível de acordo com a necessidade, incluindo no array uma nova posição chamada evidence.

printDocOptions.php
Nesse arquivo vamos tornar a implementação disponível de acordo com a necessidade, incluindo uma opção de exibir ou não as evidências de teste.

strings.txt
Nesse arquivo incluímos a string “test_evidence” para atender ao padrão multilanguage do TestLink

testlink_library.js
Nesse arquivo incluímos a opção de Evidência de teste para funcionamento do extJS

release 1.0
Versão inicial.
Arquivos Fontes: Evidence.zip

release 1.1 (bug fixed)
Funcionando com FireFox
Exportando para MS Word – Writer.
Arquivos Fontes: Evidence.zip (Release Corrente)

ATENÇÃO: O implementado acima foi testado e homologado por mim e algumas pessoas da minha equipe, ainda existem bugs conhecidos, mas nenhum que tenhamos considerado crítico. Algumas das funcionalidades implementadas ainda não estão de acordo com o padrão do TestLink e futuramente uma nova implementação para corrigir esses problemas. Caso tenha deseje essas melhorias, sugiro que me encaminhe um e-mail (camilo@camiloribeiro.com) solicitando ou e acompanhe a publicação no meu blog (blog.camiloribeiro.com). Caso encontre algum defeito ou tenha uma sugestão de como essa “melhoria pode ser melhorada” pode ser encaminhada também. Antes de qualquer modificação, eu sugiro fortemente que sejam feitos os backups, testes em um ambiente diferente do de produção e que a melhoria/atualização seja feita por uma pessoa com conhecimentos em PHP, MySQL e preferencialmente do próprio TestLink. Não me responsabilizo pelas modificações, mas fico disponível a ajudar em eventuais problemas ou mesmo a prestação de consultoria acordada em todo o Brasil.

Outras observações:
-Funciona somente para versão do relatório HTML. (não para Word, Writer, etc) (Corrigido na versão 1.1)
-Homologada somente para pt_br.
-Versões 1.8.3 e 1.8.4

Gostaria de avaliar essa melhoria ou experimentar o testlink antes de gastar tempo estudando a ferramenta?
Acesse: http://testlink.camiloribeiro.com
Usuário: visitante
Senha: visitante*2009

Obrigado por experimentar com responsabilidade!
Aproveite para me indicar defeitos encontrados e sugerir melhorias. Obrigado!

Caso tenha interesse em implementar essa funcionalidade ou outra qualquer nos sistemas TestLink, Bugzilla ou Mantis, eu ficarei disponível para ajudar ou colaborar em qualquer aspecto

Bons Testes

Agradecimento especial:
Vanessa Vaz pela revisão do post.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(1 votes, average: 10,00 out of 10)

 Loading ...

Uma tarefa que parece fácil (e efetivamente é) pode se tornar um problema que dura quase um mês. Foi exatamente isso que aconteceu quando eu comecei a pesquisar sobre como integrar o TestLink, ferramenta Open Source de gerencia de testes ao Active Directory.

Alguns motivos que dificultaram a configuração:
-Falta de conhecimento técnico do LDAP (Lightweight Directory Access Protocol) e sua estrutura;
-Má documentação do TestLink com relação a integração;
-Pouco tratamento de falhas desta configuração no TestLink;
-Pouco suporte a esta integração;

Gostaria de pedir para desconsiderarem se algum termo referente as tecnologias abaixo relacionadas estiver confuso ou até mesmo errado. Essa não é minha área de especialização, e como já foi citado anteriormente, precisei de algum tempo para compreender os problemas envolvidos e as soluções que deveriam ser adotadas, que, possivelmente para um profissional desse setor, seriam facilmente identificadas.

Os motivos acima me motivaram a ajudar as pessoas que pesquisarem no Google sobre esse problema, que na verdade é simples, mas pelos fatores apresentados acima, tornaram-se um problema de um mês, muitas horas de configuração, várias tentativas e inúmeras descobertas.

Abaixo um “tutorial” de como integrar o LDAP passo a passo, e todas as configurações que são necessárias e as que não são necessárias:

Requisitos:
-TestLink instalado;
-Um servidor com Windows com Active Directory;
-Usuário ativo do Active Directory (preferencialmente desvinculado de qualquer colaborador, ex: tl@empresa.com);
-Uma classe de acesso ao LDAP (por exemplo php_ldap);
-Uma tabela com a estrutura do LDAP da organização;

1º Passo:
No arquivo do php.ini, descomentar (habilitar) a extensão “extension=php_ldap.dll”

O procedimento acima garante que o servidor PHP possa usar o protocolo LDAP. Sem essa configuração, o sistema não vai funcionar corretamente.
No exemplo acima, estou usando o WAMP em minha estação local.

2º Passo:
No arquivo config.inc.php, informar as seguintes configurações:
*['method'] = ‘LDAP’;
-O método deve ser informado como LDAP para que ele use a rotina de autenticação do Active Directory
*['ldap_server'] = ‘192.168.0.xxx’;
-O servidor de LDAP da organização. Pode ser o IP ou o DNS (nome) como ldap.empresa.com
*['ldap_port'] = ‘389′;
-Para Windows utilizar a porta 389
*['ldap_version'] = ‘0′;
-a versão deve ser informada como zero, caso seja diferente pode ter incompatibilidade
*['ldap_root_dn'] = ‘OU=Empresa LTDA,DC=empresa,DC=com’;
-Informar OU para os diretórios da empresa e DC para os identificadores
*['ldap_organization'] = ”;
-Deixar o organization em branco
*['ldap_uid_field'] = ’sAMAccountName’;
-Para Windows usar sAMAccountName
*['ldap_bind_dn'] = ‘CN=usuario,OU=*Usuarios,OU=Organização Empresa,DC=empresa,DC=com’;
-Informar o usuário ativo do Active Directory
*['ldap_bind_passwd'] = ’senha’;
-Informar a senha do usuário selecionado
*Para facilitar a leitura estou ocultando o array ($tlCfg->authentication)

Recomendo que essas informações sejam requeridas e alinhadas com departamento de administração de rede e infraestrutura.

Salvar as modificações.

3º Passo:
Para quem já usa o TestLink com controle interno de senha (MD5), é necessário atualizar os usuários já existentes para os nomes do LDAP, por exemplo, se o e-mail é “nome@empresa.com” o usuário do TestLink deve ser “nome”, caso seja nome.sobrenome@empresa o usuário do TestLink deve ser “nome.sobrenome”.

Isso causa um problema também, pois o TestLink tem uma regra que permite somente o cadastro de um nome sem caracteres especiais exceto pelo sublinhado “_”, mas para que ele passe a aceitar pontos basta mudar a expressão regular presente no arquivo de configuração (config.inc.php).
A expressão padrão é:  /^[\w \-]+$/
Para aceitar um ponto entre dois nomes*: /^[\w \-]+\.+[\w \-]+$/
* Minha sugestão, pode ser modificada de acordo com o padrão de cada empresa.

4º Passo:
Reiniciar o servidor do PHP para aceitar as novas modificações
Não é necessário excluir as senhas já cadastradas. Recomendo na verdade deixar as senhas para uma situação emergencial, já que agora, se o servidor de Active Directory da empresa cair, a utilização do TestLink será comprometida.

Uma outra sugestão off topic para esse post é desativar a “auto criação” de usuários, para evitar “penetras” e spammers no TestLink. Para isso basta mudar a opção de user_self_signup para FALSE

Espero que esse post possa ajudar as pessoas que como eu estiveram procurando por algum tutorial que não fale a velha “língua técnica” dos administradores de redes e infraestrutura.

PS: As informações acima são baseadas em um case de implantação da funcionalidade em uma empresa privada a qual eu presto consultoria. Não representa que funcione em qualquer outra empresa, que sejam as únicas ou melhores configurações possíveis para essa funcionalidade.

Outras referencias que podem te ajudar:
-Conhecer um pouco mais sobre LDAP http://en.wikipedia.org/wiki/LDAP
-Fórum do TestLink http://www.teamst.org/phpBB2/
-Outro tutorial sobre esse mesmo assunto http://blog.loftninjas.org/2008/02/07/using-active-directory-ldap-authentication-with-testlink/

Bons testes

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(1 votes, average: 10,00 out of 10)

 Loading ...

Apesar de trabalhar muito com a “mega suíte” de ferramentas de engenharia de software da IBM Rational, acredito que o open-source TestLink é uma ferramenta sob medida para nós analistas de teste coordenarmos os nossos projetos.

O TestLink tem recursos muito interessantes e pouquíssimos problemas e inconformidades com os padrões e nomenclatura do ISTQB .

Bom, como toda ferramenta, o TestLink não é perfeito, e possui alguns problemas pontuais que podem ser corrigidos com menos ou mais esforço, um pouco de dedicação e conhecimento básico sobre PHP e MySQL.

Na empresa onde eu trabalho, estou ajudando a implantar e customizar o TestLink e durante essa customização um dos problemas foi identificado.

Não existe uma maneira de exibir os requisitos, escopo, nos documentos “Plano de teste” e “Relatório de teste”, apenas o seu título e identificação. Um dos nossos clientes tem uma exigência contratual que obriga a presença desse conteúdo nos casos de teste, o que tornaria o TestLink uma ferramenta incompleta para os projetos desse cliente.

Como podemos ver abaixo, as opções de impressão e o relatório exibido:

Figura1-Painel de opções para impressão do Plano de teste

Alem disse problema , outra coisa que eu sempre me questionei porque não funcionava muito bem no TestLink era a formatação do conteúdo da precondição, passos e resultados esperados. Mesmo cadastrando com cuidado, colocando uma quebra de linha entre um e outro, o sistema sempre exibi tudo na mesma linha.

Com esses dois problemas para resolver, estudei um pouco do código do TestLink e da documentação presente no próprio manual e realizei as duas correções:

A primeira coisa a fazer foi pensar em como isso seria implementado. Substituir a opção atual? Criar novos relatóriospara preservar a opção anterior?

Eram inúmeras opções, porem dentre as várias opções, decidi por manter configuração original do sistema, e adicionar um checkbox novo, com a funcionalidade adicional.

Dessa forma podemos ver:

Figura2-Opção Corpo dos requisitos do caso de teste

Com a opção acima, o sistema exibe o corpo do requisito abaixo de cada título, caso não seja marcada o sistema apenas exibe o ID e o Titulo como nas versões que estamos acostumados.

Exemplo:

Antes:

Depois:

No meu caso, a opção de quebra de linha é permanente, dessa forma apliquei a todos os projetos e a opção de exibir o corpo da regra está como opção na página de seleção das informações.

Implementando

Para implementar tive que modificar alguns arquivos do próprio TestLink, esses são:
…\testlink\locale\pt_BR\strings.txt
…\testlink\lib\results\printDocOptions.php
…\testlink\lib\results\printDocument.php
…\testlink\lib\results\resultsReqs.php
…\testlink\lib\function\requirement_mgr.class.php
…\testlink\lib\function\print.inc.php

Arquivo requirement_mgr.class.php:
Modificamos a Query selecionar o fild scope.

Arquivo printDocOptions.php:
Nesse arquivo incluímos a opção que aparecerá no menu:

Arquivo printDocument.php:
Nesse arquivos incluímos a opção no array de definição da impressão.

Arquivo resultsReqs.php:
Incluído para receber o valor do conteúdo do requisito.

Arquivo print.inc.php:
Aqui exibimos os valores em quebra de linha:

Aqui exibimos o conteúdo do requisito (scope):

Arquivo strings.txt:
Incluímos duas nova String chamadas: $TLS_opt_show_tc_body e $TLS_opt_show_tc_reqs_body

As modificações acima funcionam para todos os browsers (Crhome, FireFox, IE, safari etc) e para todas as formas de saída dos relatórios (Word, Writer, HTML etc).

Para facilitar a implementação segue abaixo o link de um arquivo .zip com todos os arquivos usados para essas implementação e já no formato da estrutura de pastas, basta extrair na raiz do seu Testlink e mandar sobescrever tudo.
Download: requirementBody

ATENÇÃO: Cuidado, se existir alguma customozação em algum desses documentos ela será perdida, e é altamente recomendável fazer backup de tudo antes de qualquer modificação. Caso não use o testlink em português terá que criar as strings no arquivo strings.txt do idioma utilizado.

Assim termina a implementação e a explicação sobre como implementar desse arteigo.

mas se quiser experimentar sem mudar nada no seu ambiente acesse:

HTTP://testlink.camiloribeiro.com

usuário: visitante
senha: visitante*2009

Obrigado por experimentar com responsabilidade!

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.