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.

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

 Loading ...

Muita gente que me conhece sabe como sou um evangelista dos processos tradicionais como RUP, EUP, UP e MBASE e de modelos de qualidade e otimização dos processos organizacionais como CMM, CMMi, das ISOs entre vários outros modelos, metodologias e normas, que às vezes são conhecidas como pesadas, burocráticas, com pouco valor e pouca aplicabilidade, mas, como sou evangelista sempre digo que ir contra RUP/MBASE é ir contra Engenharia de Software.

Não existe verdade absoluta, falar que RUP é burocrático é imaturidade, assim como falar que SCRUM ou XP é desorganizado também é.

Mas hoje vou falar um pouco sobre como vejo o potencial dos princípios ágeis e como podemos usar algumas das técnicas inspiradas no XP para nosso dia a dia, aumentando a efetividade dos nossos testes sem perder tempo ou sair dos processos das nossas fábricas.

Eu vejo o XP (assim como o SCRUM) como um conjunto de práticas, princípios e orientações que seguem uma quase “doutrina” chamada de Manifesto Ágil (Manifesto for Agile Software Development) ou Manifesto para desenvolvimento Ágil de Software.

Prezado leitor apaixonado pelo Agile, não me crucifique pelo que vou dizer, mas eu, no meu “maravilhoso mundo da Engenharia de Software”, considero o XP uma biblioteca de boas práticas para engenharia e o SCRUM uma biblioteca de boas práticas para gestão e acompanhamento de projetos, sendo que o próprio RUP também agrega essa mesma titulação no meu ponto de vista. Isso porque, um projeto é uma entidade vida,  e precisa de um sistema (processo), com caracteristicas únicas para atender as  suas necessidades.

Como toda biblioteca, podemos livremente usar e deixar de usar essas práticas em qualquer projeto, mas qualquer projeto deve ter um processo definido, caso não tenha, a chance de fracasso é muito alta.

Abaixo, um resumo de alguns princípios e regras que são aplicáveis para melhorar o teste de software. Abaixo, algumas práticas interessantes baseadas nas práticas e regras do XP:

•When a bug is found, tests are created to guard against it coming back
Para todo defeito que não for encontrado por um caso de teste, deve ser criado um caso de teste em uma suíte especial para evitar que esse defeito volte a acontecer futuramente. Essa prática ajuda a aumentar a cobertura e efetividade dos testes, além de criar um conjunto de casos de teste orientados a defeito de forma preventiva. Não gasta mais tempo do que é normalmente gasto, pois essa prática substitui a descrição do defeito pelos procedimentos de teste (passo a passo) do caso de teste, substituindo o teste de confirmação e aumentando a quantidade de testes de regressão.

•All code must have unit tests.
Sim. Se o compilador já faz a cobertura de testes sintáticos de todo o código fonte, por que não deve existir uma cobertura de todos os testes semânticos (de unidade)? Os testes de unidade são o primeiro filtro no teste do software, mas não é por isso que não são importantes. Para cada classe é interessante ter um conjunto de testes que pode ser escrito antes da própria classe e se possível pela mesma pessoa que vai implementá-la. Quando isso acontece, o desenvolvedor consegue ver detalhes semânticos que antes ele não podia ver, consegue ver possíveis erros e existe uma probabilidade maior de atender a todos os requisitos da funcionalidade. Para ajudar nessa tarefa, é interessante o analista de teste participar com o desenvolvedor da criação desses testes de unidade.

•Acceptance tests are run often and the score
Toda release que passe por todos os casos de teste Alpha devem ser encaminhadas para os testes de aceite. Diferente do XP, os testes de aceite que eu proponho nesse post não são baseados em Histórias de Usuários, são baseados em requisitos funcionais do usuário (os mesmos que dão origem aos casos de uso). São escritos testes baseados em cenários de negócio do sistema, de forma a validar os fluxos de trabalho que o sistema deve prover. Sugiro que sejam poucos testes, na linguagem do usuário, cada teste cobrindo o máximo dos requisitos do usuário, sem focar nos detalhes. Após a execução desses testes, é importante coletar o ponto de vista do usuário para futuras melhorias e examinar os defeitos registrados pelos testes, pois eles refletem as principais preocupações dos usuários, e a partir de cada uma dessas iterações dos testes de aceite, temos que repensar na forma como estamos desenvolvendo nossos casos de teste, para que fiquem mais próximos dos detalhes que causam os defeitos que os clientes reportaram. Recomendação: A regra de um caso de teste para cada defeito continua valendo aqui.

•Testing Cicle Velocity (Project Velocity)
Registrar o tempo gasto para executar cada ciclo de teste. Isso é importante para que a gerência sempre deixe um tempo inflacionado dessa base histórica, de forma a prover testes de regressão de todos os casos de teste do sistema e não somente aos casos de teste das novas funcionalidades e das funcionalidades com defeitos corrigidos. Recomendação: Aplicar também aos testes de aceite do usuário.

•All code must pass all unit tests before be released
Existe uma “cascatinha” importante relacionada a esse princípio. Para que um código seja integrado ao repositório, ele jamais pode estar com algum problema sintático, deve estar completo (totalmente implementado) e deve ter passado por todos os seus testes de unidade. Dessa forma garantimos que todos os testes de unidade tenham sido executados e que defeitos em módulos sejam minimizados. Após todos os códigos da release serem integrados, é recomendado que ao gerar a release seja executado um teste de fumaça para validar se o sistema está realmente funcionando sem problemas grosseiros nos seus fluxos principais. Somente após essas duas validações (teste de unidade e teste de fumaça do desenvolvedor) a release alpha deve ser gerada e enviada para que o analista de teste execute um ciclo de teste com todos os casos de teste. Executado esse ciclo com todos os casos de teste, são executados os testes dos cenários de negócios que serão enviados para o cliente e vários testes exploratórios. Se todos os testes até aqui passarem sem problemas ou defeitos, o cliente recebe uma release beta para avaliação.

•Integrate testing often (Integrate Often)
Não adianta testar sempre os casos de teste se os cenários de negócio do sistema não forem testados também, principalmente em sistemas orientados a processos como pregão eletrônico, loja virtual, logística etc. Para o cliente um sistema que funcione sem defeitos mas não atenda às suas necessidades de negócios não é melhor que um sistema cheio de defeitos funcionais. Os casos de teste, após executados individualmente, devem ser dispostos em sequências a atender um cenário de negócio ou os requisitos do usuário. Essa prática permite que sejam testados detalhes de cada funcionalidade do sistema em paralelo aos cenários de negócio do cliente (objetivo estratégico do sistema para a organização).

•Refactor whenever and wherever possible.
Assim como os requisitos, os casos de uso e as histórias de usuário mudam constantemente, os casos de teste também mudam, e esses são os artefatos que devem aceitar a mudança com mais facilidade. Vários eventos contribuem para mudança dos casos de teste, ou testing refactoring. Mudanças nos requisitos, mudanças nos casos de uso, melhoria identificada durante a execução etc. Qualquer evento que contribua para uma melhoria do caso de teste ou de qualquer artefato de teste deve ser aceito sem questionar. Os casos de teste devem refletir o “estado da arte” do sistema sob avaliação e devem ser sempre completos, objetivos, claros e o mais simples possível, permitindo a execução correta daquele teste. Refatoração não é um indicador de imaturidade, muito pelo contrário, para o teste de software, aceitar mudanças de braços abertos é uma demonstração de preocupação com o resultado que será recebido pelo cliente e se esse resultado está exatamente como ele espera. Outro indicador importante para mudar o caso de teste é a quantidade de defeitos que ele detecta. Quando o caso de teste não detecta defeitos a muito tempo, é interessante investigar se ele está com um nível de detalhe muito superficial ou mesmo incompleto.

•Dedicated Integration Computer
Dedicar um ambiente de testes para a implantação contínua do produto, sempre validando esse ambiente com o cliente, que deve sempre fornecer informações sobre o que acha do ambiente, sobre os recursos, características especiais etc., para que além do produto, o ambiente de teste esteja em melhoria contínua e mais próximo do ambiente real do cliente. Caso o sistema seja web e para usuários da internet, é importante que o ambiente cliente mude constantemente, exatamente ao contrário do ambiente de teste do servidor. Nesse caso a regra deve ser chamada de “undedicated Integration Computers”. Se for um portal até vale a pena pedir a várias pessoas na fábrica, com seus preferidos browsers para dar uma “navegada crítica” e enviar um feedback por um formulário no próprio portal, com as críticas e defeitos encontrados. Esse formulário deve conter um mecanismo coletando as informações de browser, sistema operacional, resolução etc., de modo transparente para o usuário. Com base nesses defeitos devem ser feitos casos de teste.

•The business analyst is always available.
Sem dúvida isso é fundamental. Penso que a pessoa mais importante para o analista de teste em um projeto é o analista de negócios / requisitos. Ele sim, pode estar no lugar do cliente e deve estar sempre disponível. Acredito que todo mundo, com exceção do Kent Beck e sua turma, sabe que cliente sempre disponível é um sonho distante na maioria absoluta dos casos, mas para suprir essa ausência, o analista de negócios deve estar sempre disponível para o analista de teste e suas dúvidas, assim como o arquiteto também deve estar disponível para testes de requisitos não-funcionais e o analista de teste para o desenvolvedor durante a correção de defeitos e testes de unidade.

Essas são práticas inspiradas no XP para melhorar nossas atividades de teste de software, sem gastar muito tempo com processos, análise de processos etc.

Outros princípios interessantes semelhantes, inspirados no agile:
Testar mais que o necessário sobre deixar dúvida na cobertura dos testes;
Cadastrar um defeito inválido sobre deixar de cadastrar um possível defeito;
Testes de regressão sobre testes de confirmação;
Ciclo de teste completo sobre testar novas funcionalidades;
Perseguir o zero erro sobre aceitar que o projeto terá defeitos.

Outras boas práticas:
•Automatizar o controle da execução dos testes e da cobertura dos requisitos pelos testes.
•Manter rastreabilidade dos defeitos para os casos de teste.
•Priorizar os fluxos com maior número de defeitos para testes de regressão.
•Modificar constantemente os casos de teste que não apresentem defeitos.

O mais mágico dessa onda chamada Agile é que qualquer uma das práticas e princípios acima pode ser aplicados em qualquer projeto, em qualquer fase do projeto, com qualquer equipe, individualmente ou acompanhadas de outras práticas, em qualquer metodologia de desenvolvimento de software, e com certeza vão mostrar resultados interessantes se usadas adequadamente.

São baratas, simples, fáceis de implementar e com um retorno muito alto na relação custo/benefício.

Fico aberto para críticas, sugestões e comentários de todas as naturezas. Obrigado

Inspiração e fontes:
Manifesto ágil: http://agilemanifesto.org/
Os doze princípios: http://agilemanifesto.org/principles.html

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

(No Ratings Yet)

 Loading ...

Acabamos de ganhar mais uma revista “for-free” do José Díaz, dessa vez com o tema “Agile“.

Em uma união do Días, Alessandro Collino, Lisa Crispin entre outros grandes nomes da engenharia de software no mundo, a primeira edição da Agile Record – The magazine for Agile developers & Agile Testers (http://www.agilerecord.com/)  foi publicada em Janeiro de 2010.

Estão previstas 4 edições por ano, acompanhando a Testing Experience e a Security Acts que já conhecemos.

A primeira edição da revista conta com inúmeros autores renomados na área de teste de software como Rex Black, Lisa Crispin e Dawn Cannan e o mais impressionante, dos quinze artigos, dez são direcionados a teste de software.

Nessa edição temos os seguintes artigos:

Be the Worst
by Dawn Cannan (with a commentary by Lisa Crispin)

Are All Pigs Equal? – or are some more equal than others?
by Stuard Reid

7 Steps to effcient GUI test automation using Selenium RC with Java
by Lars Trachsler and Ulrich Freyer-Hirtz

How Agile Methodologies Challenge Testing
by Rex Black

Testing in an organisation going agile
by Eric Jimmink

Is there such a thing as an Agile tester?
by Jeroen van Berkel

Guerrilla Scrum: How to force organizational change
by Marc Bless

Quality – An agile point of view
by Lior Friedman

Testability: Investment, not Overhead
by David Evans

The Future of Testing – How Testing and Technology will Change
by Joachim Herschmann

Agile and Performance testing? “A Contradiction of terms?”
by Mieke Gevers

Software Testing Craft
by Markus Gärtner

Five tips for successful retrospectives
by Tomi Juhola

Still playing planning poker? Stop gambling with your project budget.
by Rob van Kerkwijk

Scrum and RUP – A Comparison Doesn’t Go on All Fours
by Remi-Armand Collaris and Eef Dekker

Para ter acesso a revista: http://www.agilerecord.com/

Bons testes e boa leitura