quarta-feira, 6 de janeiro de 2010

VSTS – Visual Studio Team System para Testadores – Unit Test

Após o primeiro post sobre o VSTS – Visual Studio Team System para Testadores – Introdução vamos dar continuidade falando um pouco sobre teste unitário no VSTS.

O título desse post fala que é para Testadores, mas se você é um Desenvolvedor de software e não faz Unit Test, está mais do que na hora de começar a fazê-los. Dizem que propaganda é a alma do negócio, certo? Eu digo que Qualidade é o coração do sistema. Não pense que testar é responsabilidade única e exclusiva dos testadores.

O teste unitário (Unit Test) ou de unidade é um tipo de teste que foca na verificação da menor unidade do projeto de software. É realizado o teste de uma unidade lógica, com uso de dados suficientes para se testar apenas a lógica da unidade em questão. Um exemplo em sistemas desenvolvidos em linguagens orientadas a objetos, como C# e Java, essa unidade pode ser identificada como um método, uma classe ou mesmo um objeto.

Podemos dizer que este tipo de teste foca na arquitetura do sistema e é de responsabilidade do próprio desenvolvedor criar esses testes em tempo de implementação do sistema, isto é, após codificar uma classe, por exemplo, ele planeja, codifica e executa o teste de unidade.

Em resumo, um teste unitário executa um método individualmente e compara uma saída conhecida após o processamento da mesma.

Considero o teste unitário o principal teste na cadeia de teste e que vai garantir que o código que foi desenvolvido para o sistema em questão tenha “qualidade”. Claro que todos os outros testes da cadeia são extremamente importante, mas como o teste unitário está no início da cadeia, devemos fazer a coisa certa desde o início.

Para vocês verificarem como o teste unitário é importante, basta olhar no Modelo V de desenvolvimento, esse teste é o primeiro da cadeia.

Modelo V

Se observamos o Agile Testing Quadrants [1] iremos constatar que o Q1, ou seja, primeiro quadrante tem o nosso bom e velho amigo Teste Unitário.

Agile Testing Quadrants

  • Q1 – São os testes que focam na arquitetura. A responsabilidade é dos desenvolvedores e os analistas de teste auxiliam na elaboração dos testes unitários automáticos
  • Q2 – São os testes que focam no negócio. A responsabilidade é dos analistas de teste em conjunto com outros envolvidos no projeto(clientes, usuários, etc..). Ajuda no entendimento das funcionalidades
  • Q3 – São os testes que focam no negócio e encontrar defeitos. A responsabilidade é dos analistas de teste
  • Q4 – São os testes que focam na arquitetura, estrutura do software. A responsabilidade é dos analistas de teste

Bem, agora que já falamos um pouco sobre teste unitário vamos colocar a mão na massa. Para isso, vamos criar um novo projeto Class Library como exemplo chamado Text Validation na nossa Solution. Para fazer isso bastar clicar com o botão direito na Solution, acessar o menu Add / New Project. Na parte esquerda da tela selecionar a opção Visual C# como Project types e na parte direita da tela selecionar Class Library como Template. Feito isso, basta digitar o nome Text Validation no campo Name e confirmar a operação pressionando o botão OK.

A idéia é utilizar essa Class Library como o projeto que será aplicado o teste unitário.

Add New Class Library

Após a criação com sucesso, a Solution é apresentada com a Class Library criada da seguinte forma:

Class Library Text Validation Created

Agora vamos alterar o nome do arquivo Class1.cs para Text_Validation.cs. Neste caso, selecione o arquivo Class1.cs e pressione F2 que o mesmo entrará em modo de edição do nome do arquivo e digite Text_Validation.cs. Pronto, já estamos preparados para inserir o código da nossa Classe.

Nessa classe teremos 2 métodos:

  • GetDelimitator(): Retorna o delimitador de string utilizado na aplicação;
  • isEmail(string pStrEmail): Retorna sucesso (true) se o email informado para validação for um email com o formato válido.

Abaixo segue o código da classe que iremos utilizar como exemplo para o nosso teste unitário.

using System.Text.RegularExpressions;

namespace Text_Validation

{

    public class Text

    {

        /// <summary>

        /// Retorna o delimitador de string utilizado na aplicação

        /// </summary>

        public char GetDelimitator()

        {

            return ';';

        }

 

        /// <summary>

        /// Retorna sucesso (true) se o email informado para validação for um email com o formato válido

        /// </summary>

        /// <param name="pStrEmail">Email alvo para validação de formato</param>

        public bool isEmail(string pStrEmail)

        {

            string strRegex = @"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}" +

                  @"\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\" +

                  @".)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";

            Regex re = new Regex(strRegex);

            if (re.IsMatch(pStrEmail))

            {

                return true;

            }

            return false;

        }

    }

}

O próximo passo após a criação da nossa classe de exemplo para os testes unitários é criar o projeto de Teste. A forma mais fácil que recomendo para criar o projeto de teste é a seguinte:

  • Abrir a classe que deseja criar os testes unitários;
  • Clicar com o botão direito em qualquer lugar do código, aparecerá um menu;
  • Clicar na opção Create Unit Tests…;
  • A tela abaixo será aberta com a lista de todos os métodos da classe;

Create Unit Test Current Selection

  • Selecione os métodos que deseja criar os testes unitários. No nosso exemplo iremos habilitar todas as checkboxes;
  • No campo Output project, selecione a opção Create a new Visual C# test project… e confirme a operação selecionando o botão OK;
  • Após confirmar a operação, uma dialog será mostrada para o usuário inserir o nome do projeto no campo Enter a name for your new project. Neste campo entre com o nome Unit Test Text Validation e confirme a operação selecionando o botão Create;
  • Pronto, agora sua solution tem 2 projetos como mostrado abaixo.

Unit Test Project Created

O código gerado pelo Visual Studio deve ser alterado de acordo com a sua necessidade e cada teste que você deseja realizar. Se você abrir o arquivo TextTest.cs encontrará o seguinte código:

using Text_Validation;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Unit_Test_Text_Validation

{

    /// <summary>

    ///This is a test class for TextTest and is intended

    ///to contain all TextTest Unit Tests

    ///</summary>

    [TestClass()]

    public class TextTest

    {

        private TestContext testContextInstance;

        /// <summary>

        ///Gets or sets the test context which provides

        ///information about and functionality for the current test run.

        ///</summary>

        public TestContext TestContext

        {

            get

            {

                return testContextInstance;

            }

            set

            {

                testContextInstance = value;

            }

        }

 

        /// <summary>

        ///A test for isEmail

        ///</summary>

        [TestMethod()]

        public void isEmailTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            string pStrEmail = string.Empty; // TODO: Initialize to an appropriate value

            bool expected = false; // TODO: Initialize to an appropriate value

            bool actual;

            actual = target.isEmail(pStrEmail);

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

 

        /// <summary>

        ///A test for GetDelimitator

        ///</summary>

        [TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            char expected = '\0'; // TODO: Initialize to an appropriate value

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

 

        /// <summary>

        ///A test for Text Constructor

        ///</summary>

        [TestMethod()]

        public void TextConstructorTest()

        {

            Text target = new Text();

            Assert.Inconclusive("TODO: Implement code to verify target");

        }

    }

}

Se observarmos a classe unit test acima, facilmente identificamos suas diferenças se compararmos com uma classe básica (como no exemplo da classe Text que criamos no projeto Text Validation). A classe possui o atributo [TestClass], identificando que é uma classe de testes e cada método também possui um atributo [TestMethod] identificando o método como sendo de testes. [2]

Outro ponto importante é observar que o namespace (using Microsoft.VisualStudio.TestTools.UnitTesting; ) importado na nossa classe de teste é utilizado para disponibilizar diversas funcionalidades de testes que podem ser usadas na classe do seu unit test. Esse namespace disponibiliza também a classe Assert, que dispõe de diversos métodos estáticos para validação e execução dos testes. O método AreEqual, por exemplo, em uma de suas sobrecargas, recebe por parâmetro o valor esperado da execução do teste e o valor que será enviado para validação de acordo com o método chamado como exemplo abaixo:

[TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            char expected = '\0'; // TODO: Initialize to an appropriate value

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

Além da criação das classes de teste, ainda é possível executá-las, saber o resultado e armazená-las para comparação posterior. Agora vamos executar todos os testes criados sem alterar uma linha de código para ver qual será o resultado. Para isso, acesse o menu Test / Windows / Test List Editor. Em seguida selecione todos os testes habilitando o checkbox ao lado esquerdo do teste e click na opção Run Checked Tests como mostrado na imagem abaixo.

Run Checked Tests

Após a execução dos testes você irá perceber que os testes não tiveram seu resultado como Passed, afinal, não fizemos nenhuma alteração do código e isso era o esperado. Neste caso, tivemos 2 testes com o resultado Inconclusive e 1 com o resultado Failed como podemos observar o resultado da nossa execução abaixo.

Test Executed No Changes

Como o nosso objetivo é ter todos os casos de teste unitário com o resultados Passed, vamos fazer as devidas alterações para testar o que queremos.

Primeiro, vamos alterar o TestMethod isEmailTest(). O objetivo do nosso teste é garantir que o método isEmail(string pStrEmail) da classe Text do nosso projeto Text Validation retorna true se o email informado para validação for um email com o formato válido. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void isEmailTest()

        {

            Text target = new Text();

            string pStrEmail = "teste@teste.com.br";

            bool expected = true;

            bool actual;

            actual = target.isEmail(pStrEmail);

            Assert.AreEqual(expected, actual);

        }

Segundo, vamos alterar o TestMethod GetDelimitatorTest(). O objetivo do nosso teste é garantir que o método getDelimitator() da classe Text do nosso projeto Text Validation retorna o delimitador de string utilizado na aplicação, que neste caso é o valor ';'. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text();

            char expected = ';';

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

        }

Por último, vamos alterar o TestMethod TextConstructorTest(). Neste caso, o nosso objetivo é simplesmente garantir que conseguimos criar um objetivo do tipo Text não nulo. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void TextConstructorTest()

        {

            Text target = new Text();

            Assert.IsNotNull(target);

        }

Pronto, agora é mandar executar os testes e verificar o resultado :-). Se tudo deu certo, todos os seus testes estão com o status Passed como na imagem abaixo:

Test Executed Passed

Para quem não percebeu, todos os métodos de teste que tinham o método Assert.Inconclusive foram removidos, mas por que isso aconteceu?

O método Assert.Inconclusive indica que uma declaração não pode ser comprovado verdadeiro ou falso ou para indicar uma declaração que ainda não foi implementada. Por isso que depois de implementar todas as nossas alterações, removemos esse método. Segue a lista de sobrecarga para este caso:

Nome

Descrição

Inconclusive() Indica que a declaração não pode ser verificada.
Inconclusive(String) Indica que a declaração não pode ser verificada. Exibe uma mensagem.
Inconclusive(String, Object[]) Indica que a declaração não pode ser verificada. Exibe uma mensagem e aplica a formatação especificada pra ele.

Espero que tenham gostado!

Até+,

Quezada

Referências:

  1. Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
  2. Visual Studio Team System Rocks by Alércio Bressano, Alexandre Tarifa, Andrey Sanches, Clementino Mendonça, Emerson Facunte, Fábio Câmara, Fábio Hirota, Hélio Sá Moreira, Igor Abade V. Leite e Mauro Sant’Anna

terça-feira, 15 de dezembro de 2009

VSTS – Visual Studio Team System para Testadores – Introdução

Antes de falar um pouco sobre o Visual Studio Tem System (VSTS), devemos entender um pouco sobre o papel do testador no ciclo de desenvolvimento de software. Resumidamente, podemos dizer que a função do testador é garantir a qualidade do produto e, para isso, o trabalho dele no ciclo de desenvolvimento de software é:

  • Auxiliar os desenvolvedores na elaboração dos testes unitários automáticos;
  • Montar e configurar o ambiente e infra-estrutura de teste;
  • Escrever casos de teste;
  • Executar testes;
  • Automatizar casos e tarefas de teste;
  • Evidenciar os resultados;
  • Acompanhar os defeitos encontrados;
  • Desenvolver novas habilidades;
  • O Analista de Teste é “o cara que aprova”. Nada é considerado “pronto” sem que ele diga que está.

Bem, agora que você já sabe um pouco sobre o papel do testador no ciclo de desenvolvimento de software, é necessário saber quais os testes que podem ser aplicados ao projeto (qualquer projeto que está sendo desenvolvido e que o testador esteja participando) de teste. Abaixo temos alguns exemplos:

Unit e Component Tests: São os testes que focam na arquitetura. Esses testes são executados automaticamente e a responsabilidade é dos desenvolvedores. Os testadores devem auxiliar os desenvolvedores na elaboração desses testes.

Functional e Story Tests, Simulations, Prototypes: São os testes que focam no negócio. Esses testes são executados automaticamente/manualmente e a responsabilidade é dos testadores em conjunto com outros envolvidos (clientes, usuários, etc.) no projeto. Neste caso, esses tipos de teste ajudam no entendimento das funcionalidades.

Scenarios, Exploratory, Usability, User Acceptance Testing: São os testes que focam no negócio e encontrar defeitos. Esses testes são executados manualmente e a responsabilidade é dos testadores. Neste caso, esses tipos de teste ajudam a encontrar o maior número de defeitos possível.

Performance, Load e Security Testing: São os testes que focam na arquitetura e estrutura do software. Esses testes são executados por ferramentas capazes de simular cenários de testes, por exemplo: Ter 10.000 usuários registrados no sistema simultaneamente. A responsabilidade da execução desses testes é dos testadores. Neste caso, esses tipos de testes ajudam identificar se a aplicação/software que está sendo testado é robusto suficiente.

Neste momento, já sabemos o papel do testador no ciclo de desenvolvimento de software e também quais os testes que podem ser aplicados aos projetos. Agora chegou o momento de criar um Projeto de Teste e incluir todos os seus artefatos de teste. Para isso, basta acessar o menu File / New / Project. Após acessar este menu, a janela abaixo será aberta e basta você selecionar a opção Test Project / Test Documents no menu (árvore) da esquerda. Feito isso, selecione o template Test Project informando o nome do projeto no campo Name.

VSTS New Test Project

Feito isso chegou a hora de Conhecer a IDE de Testes no Visual Studio.

A IDE (Integrated Development Environment) possui um leque amplo de ferramentas para manipular testes e que auxiliam muito o testador no dia-a-dia de trabalho. Para acessar as funcionalidades relacionadas com testes do Visual Studio, basta acessar o menu Test / Window. Abaixo temos a lista das principais funcionalidades:

  • Solution Explorer: essa janela apresenta uma listagem dos arquivos presentes em cada solution envolvendo projetos, arquivos de teste, etc;

VSTS Solution Explorer 

  • Test Manager: através dessa janela é possível executar os testes visualizando-os de diversas formas, adicionar novos testes, agrupar, ordenar e localizar testes na listagem;

VSTS Test Manager

  • Test Result: com essa opção, podemos visualizar todos os resultados de testes executados no projeto. Essa janela demonstrará se o teste foi executado com sucesso ou se houve erros durante a execução. A partir dessa janela também é possível reexecutar o teste que acabou de ser rodado;

VSTS Test Result

  • Code Coverage Results: se essa opção estiver habilitada, é possível visualizar as coberturas de códigos em determinadas execuções de teste, observando o percentual de código executado para cada método;

VSTS Code Coverage Results

  • Test Runs: essa janela permite acompanhar uma fila de execução de testes, a fim de identificar testes que estão esperando para serem executados, testes em execução, já executados e diversas opções desse gênero;

VSTS Test Runs

  • Test View: a janela Test View é a forma mais rápida de executar um teste. Através dela podemos executar inclusive em modo Debug, podendo acompanhar a execução passo a passo do método selecionado. Além disso, podemos configurar diversas propriedades de cada testes presente nessa janela.

VSTS Test View

Até+,

Quezada

 

Referências:

  1. Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
  2. Visual Studio Team System Rocks by Alércio Bressano, Alexandre Tarifa, Andrey Sanches, Clementino Mendonça, Emerson Facunte, Fábio Câmara, Fábio Hirota, Hélio Sá Moreira, Igor Abade V. Leite e Mauro Sant’Anna

segunda-feira, 5 de outubro de 2009

Gerenciamento de Riscos - Introdução

Nos últimos dias estava discutindo com um amigo meu o tema “Gerenciamento de Risco”, então comecei a ler um artigo sobre esse tema e resolvi divulgar um pouco dessa informação com vocês. Mas você pode estar se perguntando “O que isso tem haver com teste e qualidade de software?”, bem, tem tudo haver, todo projeto que estamos executando precisamos gerenciar riscos. A nossa vida é gerenciar riscos! :-) Bem, vamos lá!

O fator prazo é crítico na identificação, quantificação e monitoramento de riscos em projetos nos quais o cumprimento de datas é mandatório. Para o gerenciamento de riscos, utiliza-se inicialmente a identificação e quantificação do fator ou evento de risco.
Complementando os modelos de gerenciamento de riscos do PMBOK (Project Management Body of Knowledge), iremos utilizar um método para aumentar a eficácia dos modelos de gerenciamento de riscos mais utilizados. “Trata-se de um método aprimorado de gerenciamento de riscos de não alcançar a meta de prazo do projeto. Quando não é possível planejar com mais folga, deve se pensar em planejamento e preparação de contingências. Isto freqüentemente envolve alocação de recursos adicionais para algo que pode não acontecer.” (Chris Felstead).
O método utilizado tem seis etapas que devemos usar para mitigar os riscos:
  • Contextualizar: determinar a categoria da data meta e a conseqüência, caso esta não seja alcançada.
  • Identificar: identificar os riscos que devem ser gerenciados e que requerem prazo de preparação anterior a implantação. Enfatizar que se o evento de risco ocorrer, fará com que o projeto ultrapasse a data meta.
  • Analisar os riscos: identificar os responsáveis pelos planos de contingência e aqueles que podem custeá-los.
  • Tratar os riscos: determinar a data na qual a preparação deve ser iniciada e se os planos de contingência são economicamente viáveis.
  • Monitorar e revisar os riscos: para riscos que não tenham sido priorizados, determinar se e quando a preparação de contingências deve ser iniciada.
  • Comunicar e discutir: obter a autorização do interessado para iniciar a preparação.

O Sr. Felstead caracteriza estas ações adicionais com um segundo passo para o gerenciamento de riscos. As atividades requeridas pelo modelo criam um método para identificar e gerenciar os riscos do projeto de forma simplificada. “Atualmente, em muitas empresas o gerenciamento de riscos não é agressivo o suficiente para viabilizar a alocação de recursos necessários ou realizar o planejamento de contingências de forma adequada”.

Se estivermos trabalhando em um projeto de desenvolvimento de software, todas as etapas acima devem ser negociadas e de conhecimento do time todo, incluindo desenvolvedores, testadores, etc.

Para ajudar ainda mais o entendimento de Gerenciamento de Riscos e as etapas usadas no método acima explicado, abaixo estão alguns conceitos usados no gerenciamento de riscos.

  • Riscos: O risco é uma perda em potencial para a organização. Um exemplo é o risco resultante do mau uso do computador. O risco pode ser medido através da análise de risco.
  • Análise de risco: A análise de risco é uma avaliação dos recursos de informação de uma organização, seus controles e suas vulnerabilidades. Ela combina a possibilidade de perda de cada recurso com sua taxa estimada de ocorrência para estabelecer o grau de prejuízos financeiros, ou de outra ordem, que essa perda poderá ocasionar. Na verdade, a análise de riscos combina a probabilidade de ocorrência com a gravidade dos danos causados por sua ocorrência.
  • Ameaça: Existe um risco de um meteoro cair na cidade onde você mora. Isso é uma ameaça a sua vida? Não, pois a probabilidade dessa ocorrência é quase zero. Podemos dizer que a ameaça é a capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação.
  • Vulnerabilidade: A vulnerabilidade é uma falha de desenho, implementação ou operação que permite a concretização de uma ameaça. Um site na internet, por uma falha de desenho e de implementação, pode permitir que hackers invadam o ambiente interno da empresa, portanto uma falha tornou o site vulnerável. Um risco só se torna uma ameaça quando existe uma vulnerabilidade.
  • Controle: O controle é uma maneira de tentar reduzir as causas dos riscos, evitando, desse modo, sua ocorrência ou, pelo menos, reduzindo a freqüência de ocorrência.

Este texto é baseado no artigo “O desafio de projetos com data meta – novas estratégias de gerenciamento de riscos”, apresentado por Chris Felstead, PMP, no Congresso PMI 2005 – Ásia. Fonte: PM Network, edição Setembro/2005, página 76

Muitas vezes você pode utilizar uma simples planilha para gerenciar riscos. Abaixo estão algumas informações que podem ter nessa sua planilha:

  • ID do Risco: Número que identifica o Risco
  • Projeto: Nome do projeto que o risco está relacionado
  • Item de Risco: Risco que foi identificado
  • Status: Status do risco (Aberto, Parado, Em andamento, Fechado, etc.)
  • Impacto: Nível de impacto do risco no projeto (Alto(5), Médio(3), Baixo(1))
  • Plano de Mitigação e Contingência: Plano de Mitigação e Contingência elaborado para minimizar ou remover o risco encontrado.
  • Pessoa Responsável: Pessoa responsável por executar o Plano de Mitigação e Contingência
    Acompanhamento / Comentários: Informações de acompanhamento das atividades executados para mitigar o risco
  • Data de Abertura: Data de abertura do risco
  • Data de Fechamento: Data de fechamento do risco
  • Duração (dias): Tempo que o risco ficou aberto

Boa leitura!

Até+,
Quezada

sexta-feira, 25 de setembro de 2009

XXXVII Encontro do SPIN-Campinas - Participação do "Time de Teste" em Projetos Scrum

Olá Pessoal,

Gostaria de agradecer a participação de TODAS as pessoas que participaram do XXXVII Encontro do SPIN-Campinas que aconteceu no dia 24/Setembro/09 na Motorola em Jaguariúna, principalmente a Coordenação do SPIN-Campinas.
Realmente foi muito legal, conseguimos trocar experiências, tivemos várias discussões excelentes. A participação de vocês foi essencial para fazer o evento acontecer!!!

Gostaria de dar os Parabéns para a Gabriela, ela ganhou um vale presente da FNAC pois acertou o nome dos Macacos!! Hehehehehe !!! Gabriela, se você comprar um DVD de filme, depois me empresta, ok? :-)

Bem, para finalizar, segue abaixo a apresentação:

Muito obrigado!!

Até+,
Quezada

terça-feira, 1 de setembro de 2009

Palestra - Papel do Time de Teste em Projetos SCRUM

Olá Pessoal,

Chegou o momento da gente bater um papo sobre Teste de Software! Desta vez estarei falando um pouco sobre as experiências em Projetos SCRUM. :-) ANOTEM NA AGENDA DE VOCÊS!!!

Estão abertas as inscrições para o XXXVII evento do SPIN-Campinas, que será realizado no dia 24 de setembro de 2009, a partir das 13:00h, na Motorola. No evento serão realizadas três apresentações sobre Testes e eu serei um dos palestrantes. São elas:

Título: Papel do Time de Teste em Projetos SCRUM
Resumo: Os projetos de desenvolvimento de software que utilizam o SCRUM para auxiliar no gerenciamento de projetos vêm crescendo a cada dia. A empresa que decide utilizar o SCRUM nos projetos tem um grande desafio para implementá-lo e desenvolver essa nova “cultura” internamente na empresa e o desafio é maior ainda quando o time de teste participa desses projetos. A apresentação abordará alguns pontos onde o time de teste colabora e participa, e o mais importante, quais tipos de atividades o time de teste executa no projeto.
Palestrante: Gustavo Quezada (ASGA)

Título: Análise da causa de defeitos em aplicações web
Resumo: Atualmente, é crescente a dependência humana para com computadores e software. Uma vez que sistemas baseados na web são cada vez mais utilizados, avaliar sua confiabilidade é vital para que estes sejam robustos e tenham qualidade, refletida na redução no número de defeitos. Esta palestra apresenta de maneira geral um dos processos utilizados pela empresa na implantação de um mecanismo para análise da causa dos defeitos em um conjunto de aplicações web. Além disso, dados coletados em um estudo de caso serão apresentados ao público, assim como benefícios obtidos e lições aprendidas.
Palestrante: Bruno Teixeira de Abreu (SOFIST)

Título: Case – Automação de testes de interface do usuário em ambientes virtualizados
Resumo: Os testes de regressão geralmente são executados após a correção de algum defeito ou após a adição de uma nova funcionalidade. Normalmente, este tipo de teste é realizado através de ferramentas de automação de teste, devido à falta de tempo para executar novamente casos de teste já executados. E se o sistema precisa ser testado em mais de um ambiente? Não é por acaso que os testes de regressão ficam para segundo plano. Portanto, o uso de ferramenta para a automação de testes e a virtualização dos ambientes são indispensáveis para garantir os prazos e a qualidade do sistema. Alguns benefícios da automação e virtualização de ambientes de teste:
  • Métricas de retrabalho e esforço de teste
  • Aumento da qualidade do produto final
  • Diminuição do esforço e tempo do ciclo de desenvolvimento

Palestrante: Joselito Viana Soares (Synchro Solução Fiscal)

O evento é gratuito!!!

Para se inscrever, envie um e-mail para Fernanda Azevedo Oshiro (wfa019@motorola.com), informando o nome completo, RG, empresa e e-mail e placa do carro dos inscritos, até dia 22 de setembro de 2009. O endereço da Motorola é Rodovia SP 340, Km 128,7 – Tanquinho – Jaguariuna-SP.

Para maiores detalhes acessem - http://www.cpqd.com.br/spin-cps/index.php

Até+,
Quezada

quinta-feira, 13 de agosto de 2009

Execução e Relatório de Teste

Para continuar com o assunto “Relatório de Execução de Teste”, hoje vamos mostrar um pouco mais sobre Execução de Teste. A idéia deste post é auxiliar você com as atividades de planejamento, execução e relatórios de teste.

Após a fase de Análise e Design de Teste ser concluída, chega à hora de entrar na fase de Execução de Teste. A primeira coisa que deve ser feita antes de começar a execução efetivamente é planejar e/ou rever o planejamento dessa fase. Para ajudar nesse planejamento uma boa prática é utilizar um Gráfico para mostrar o planejado versus o atual e, neste caso, nada melhor do que o Gráfico Curva-S. Abaixo temos a Tabela 1 – Gráfico Curva-S, a qual é utilizada para fazer o planejamento da execução dos casos de teste.


Tabela 1 – Gráfico Curva-S

Para facilitar o entendimento da tabela acima, segue abaixo a descrição de cada coluna:
  • Data: data de execução planejada;
  • Total Planejado: número total de casos de teste planejado para execução;
  • Total Planejado Acumulativo: número total de casos de teste planejado acumulativo;
  • Total Passado Planejado: número total de casos de teste passados no dia;
  • Total Passado: número total de casos de teste passados acumulados;
  • Total Falhado Planejado: número total de casos de teste falhados no dia;
  • Total Falhado: número total de casos de teste falhados acumulados;
  • Total Bloqueado Planejado: número total de casos de teste bloqueados no dia;
  • Total Bloqueado: número total de casos de teste bloqueados acumulados;
  • Total Atingido: número total de casos de teste executados até o momento somando, total passado, total falhado, total bloqueado;
  • Comentário Execução: comentários gerais do planejamento.

Após a criação da tabela acima, basta gerar gráfico incluindo os campos Data, Total Planejado Acumulativo, Total Passado, Total Falhado, Total Bloqueado, Total Atingido, como mostrado abaixo na Figura 1 – Gráfico Curva-S.


Figura 1 – Gráfico Curva-S

Após a criação do Gráfico Curva-s, obtém-se o número total de casos de teste que foram planejados para execução incluindo os novos casos de teste, porcentagem de casos passados, falhados e bloqueados e casos de teste de regressão. Com isso é possível verificar se o planejamento feito anteriormente está de acordo com o atual, caso seja necessário, um novo re-planejamento deve ser feito e as partes interessadas informadas. Vale lembrar que a criação dos ciclos de teste deve ser planejada de acordo com o progresso da execução, estabilidade do software e critério de saída. Quando o planejamento está concluído, chega a hora da execução dos testes.
Os casos de teste são executados usando os procedimentos documentados e/ou automáticos do script de teste. Para que a fase de execução de teste seja executada com sucesso deve-se:

  • Executar os casos de teste usando o documento de procedimentos de teste e/ou scripts de teste;
  • Registrar o resultado atual;
  • Comparar o resultado atual com o resultado esperado;
  • Se necessário, repetir a execução de um caso de teste quando um incidente é encontrado, ou seja, devemos fazer o teste de confirmação;
  • Executar testes de regressão como planejado.

Devido ao alto risco de mudança do código entre a execução de um ciclo e outro, deve-se ter uma política de re-teste bem definida.
Em alguns casos, testes podem ser executados “informalmente” sem usar procedimentos de teste detalhado, como por exemplo: teste exploratório.

Relatórios de Teste
Sempre que é encontrado um incidente de teste na fase de execução é necessário relatar esse incidente. Para isso, deve-se definir os relatórios necessários para acompanhar o progresso do(s) projeto(s) de teste segundo a norma IEEE 829-1998. Os relatórios de teste que a IEEE sugere são os seguintes:

  • Relatório de Log de Teste;
  • Relatório de incidentes de Teste;
  • Relatório de Sumário de Teste.

Para ajudar no entendimento de como chegamos aos relatórios acima, segue abaixo a Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829.



Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829 -1998

Relatório de Log de Teste
Tudo o que for relevante durante a fase de execução de teste deve ser reportada no relatório de log de teste.
Segundo a norma IEEE 829 o relatório de log de teste deve ter as seguintes informações:
  • Identificador: identificador único e específico para o relatório, por exemplo, o nome do sistema com número do release mais data e hora do teste;
  • Descrição: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memória utilizada, etc;
  • Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsável;
  • Descrição da execução: descrever o que foi feito e identificar os responsáveis pela atividade incluindo testadores, observadores e operadores;
  • Resultados dos procedimentos: para cada execução, descrever os resultados encontrados podendo ser sucesso ou não;
  • Informações sobre ambiente de teste: informar qualquer condição específica do ambiente de teste, caso seja necessário;
  • Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

Relatório de Incidentes de Teste
Toda e qualquer discrepância entre o resultado esperado e o encontrado na execução dos casos de teste devem ser reportados para o time de desenvolvimento com o máximo de detalhes possíveis. Nesse caso, é utilizado o relatório de incidentes de teste o qual é registrado todos os defeitos encontrados durante a fase de execução de teste.
Segundo a norma IEEE 829 o relatório de incidente de teste deve ter as seguintes informações:

  • Identificador do relatório: identificador único e específico para o relatório, por exemplo, release testado mais o identificador de um caso de teste ;
  • Sumário da ocorrência: uma breve descrição do incidente; identificar os itens de teste envolvidos indicando sua versão, caso seja necessário; adicionar referência para a especificação do caso de teste, assim o desenvolvedor que for corrigir o defeito terá uma base de documento de teste além do documento de requisitos e adicionar também o relatório de log de teste, se necessário;
  • Descrição do incidente: prover uma descrição do incidente incluindo os seguintes itens:
  • ==>Entradas;
  • ==>Resultados esperados;
  • ==>Resultados encontrados;
  • ==>Problemas;
  • ==>Data e hora do incidente;
  • ==>Procedimentos para reproduzir o problema;
  • ==>Ambiente;
  • ==>Tentativas para repetir o problema;
  • ==>Testadores;
  • ==>Observadores.

Vale lembrar que outras informações podem ser incluídas sempre que necessário e nem sempre todos os campos acima serão necessários.

  • Impacto: indicar qual o impacto que o incidente terá no plano de teste de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma possível mudança no caso de teste ou requisitos. Se possível, informar a prioridade e severidade do incidente.
    Os incidentes de teste devem ser armazenados em um repositório e, caso necessário, revisar o relatório de incidentes de teste com as partes interessadas.

Relatório de Sumário de Teste
Fornecer um sumário das atividades de teste incluindo os resultados, como o próprio nome do relatório já diz, relatório de sumário de teste. A idéia é resumir as atividades realizadas na execução dos testes.
Segundo a norma IEEE 829 o relatório de sumário de teste deve ter as seguintes informações:

  • Identificador: identificador único e específico para o relatório, por exemplo, release e/ou projeto testado;
  • Sumário: sumarizar a evolução das atividades de teste identificando os itens testados e o ambiente utilizado para execução dos testes;
  • Variações: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilização do procedimento alternativo;
  • Avaliações do processo: avaliação resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinações de teste que não foram exercitadas explicando a razão; qualquer ocorrência que possa impactar na qualidade do software/produto deve ser considerada;
  • Sumário dos resultados: sumarizar os resultados de teste identificando o número de casos de teste executados, número de defeitos encontrados, número de defeitos fechados e abertos, etc;
  • Avaliação do(s) teste(s): proporcionar uma avaliação global de cada item, incluindo suas limitações. Essa avaliação deve ser baseada nos resultados dos casos de teste e nos critérios de aprovação/reprovação;
  • Sumário de atividades: resumir os recursos envolvidos no projeto de teste, número total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc;
  • Aprovações: listar o nome e títulos das pessoas responsáveis pela aprovação do projeto de teste incluindo os relatórios.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

No post Relatório Parcial de Execução de Teste você pode encontrar informações adicionais sobre relatório de teste.

Até+,
Quezada