terça-feira, janeiro 31, 2006

RTH - Mais uma ferramenta open source para gestão de testes

O RTH é uma interessante ferramenta com foco em gestão de testes. Porém possui módulo para cadastrar também requisitos, como veremos mais à frente. Facilita a associação e relacionamento das informações. É uma espécie de Mercury TestDirector (claro que não tem tantas funcionalidades quanto a ferramenta da Mercury) só que open source. É também uma concorrente para a também ótima ferramenta open source TestLink, já citada em meu blog.

No comparativo com o TestLink vejo como as seguintes vantagens do RTH:

- Interface gráfica mais intuitiva
- Capacidade de versionar mudanças em requisitos e documentos anexos
- Visão dos requisitos como uma árvore hierarquizada
- Definição mais granular dos passos de um caso de teste e das possíveis falhas
- Discussões(estilo fórum) em requisitos

Como desvantagem posso citar:

- Inexistência de uma integração simples com uma ferramenta de bug tracking externa (porém ele possui a sua própria funcionalidade de bug tracking para controlar os defeitos)
- Quantidade de relatórios ainda pequena

Segue um fluxo breve e algumas das telas da ferramenta para dar uma noção do que faz.

A tela inicial do rth é essa:


Os primeiros passos (depois de instalar e configurar conforme descrito nas instruções do site, o que levei uns 10 minutos para fazer) são relacionados à criação do projeto, tipos de requisitos que serão coletados, tipos de testes, usuários alocados ao projeto, tipos e categorias de defeitos. Não vou demonstrar essa parte porque ele possui um projeto Demo para exemplificar também. Eu criei um novo projeto para testar as funcionalidades.

Abaixo podemos ver a tela onde registramos os requisitos do nosso projeto. Estes podem ser classificados conforme os desejos do usuário (user stories, casos de uso, requisitos declarativos, cenários, etc e etc!):


A tela a seguir mostra uma das abas que um requisito possui. São discussões associadas a um requisito específico. Uma ótima funcionalidade também existente em ferramentas como o Rational RequisitePro:




A tela a seguir também é muito interessante, pois é uma visão dos requisitos em forma de árvore e diretórios mostrando requisitos associados como pais e filhos(talvez até ajude a atender o requisito do CMMI 2 de uma matriz de rastreabilidade)


Agora uma visão da aba onde estão os casos de teste associados ao requisito. No momento do cadastro da associação podemos definir o quanto de cobertura cada caso de teste fornece a um requisito:


A primeira tela com os detalhes de um caso de teste:


E essa tela mostra cada um dos passos registrados dentro do caso de teste e permite a adição de novos passos:


No RTH, assim como no TestLink, podemos criar builds dentro de uma release. Poderíamos também chamar de baterias de testes ou ciclos de testes que podem ocorrer. O poder desse conceito é que podemos controlar o número de vezes que executamos cada caso de teste em uma versão, iteração e/ou bateria. A tela abaixo mostra como asssociar um caso de teste a um conjunto de testes(você pode querer controlar o conjunto de testes funcionais e o conjunto dos testes de performance em separado) dentro de uma bateria:


Agora vamos observar a tela que controla os resultados de um conjunto de testes dentro de uma bateria de testes que está dentro de um release (ufa :-) !!!):


Clicando no detalhe de um caso de teste o que encontramos? Cada um dos passos do caso de teste com a informação se passou ou falhou (não coloquei aqui a tela onde você vai marcando cada um dos passos da execução do caso de teste). Note que no passo 2 eu já associei um defeito(de número 00003) ao passo com falha do caso de teste:


Portanto ao clicar no link do defeito somos levados à tela com os detalhes do defeito. Aqui entramos no ciclo da funcionalidade que uma ferramenta de bug ou issue tracking também nos oferece. Note o dado "Verification ID". Ele possui um link que nos leva de volta ao caso de teste falho dentro da bateria de testes. Ótimo para o desenvolvedor que precisa entender o que foi feito pelo analista de testes e onde ocorrer exatamente o erro:


E, para finalizar as screenshots, um dos relatórios já disponíveis na ferramenta:


Quanto à desvantagem de integração com ferramentas de issue tracking externas há dois modos de resolver: um mais fácil(a famosa gambiarra) e o mais difícil. No mais fácil você pode criar o defeito do rth mas usá-lo apenas para colocar um link apontando para a página do bug cadastrado na ferramenta oficial. A outra maneira é customizar o código-fonte do produto para fazer essa integração como é feita no TestLink.

Para terminar digo que não resisti à curiosidade e mandei alguns e-mails para os desenvolvedores da ferramenta. Com a permissão já requisitada deles descrevo aqui o que eles pretendem para futuras versões:

"Jose,
We don't currently have integration with other bug trackers but it's not a big job to add the integration. Maybe something I'll work on with our next release. I'm getting ready to release a new version that cleans up a few bugs and allows users to import and export to excel rather than csv format.
After that, I want to finish the e-mail functionality within bugs and then write more reports. We capture a lot of data, but I haven't finished writing all the reports that I want to. I'll probably upload a new release that includes the excel integration this weekend. Thanks for the promotion. I hope this information helps.

Thanks, George"

Muito obrigado a eles por mais uma interessante ferramenta para a comunidade de engenharia de software!!!

PS: Quem for instalar a ferramenta talvez tenha duas dificuldades que eu tive. A primeira pode ocorrer quando você tenta criar um novo projeto. Pode ocorrer um erro no mkdir. Depois de uma rápida busca sobre essa função do PHP descobri que isso se resolve com a maneira como você define o PATH dos diretórios. Portanto você precisa mudar a variável 'FILE_UPLOAD_PATH' do arquivo properties_inc.php para que fique assim:
'FILE_UPLOAD_PATH', "C:\\Program Files\\xampp\\htdocs\\rth\\rth_file_upload\\"

O outro problema é que podem aparecer mensagens de warning estranhas em suas páginas. Isso ocorre porque por default as variáveis 'SHOW_WARNINGS' e 'SHOW_NOTICES' podem estar ON. Basta colocá-las em OFF.

Outro lembrete: as páginas funcionam melhor no browser IE. Quando testei com o Firefox várias configurações de cores e fundos ficaram desabilitadas.

Marcadores:

Leituras da Semana V

Um livro excelente de uma metodologia ágil menos conhecida (o pessoal costuma debater mais sobre XP e Scrum) é Crystal Clear: A Human-Powered Methodology for Small Teams .

A forma como ele divide o livro para definir o conceito de sua metodologia para times pequenos é muito interessante. Ele define:

- As sete propriedades gerais do Crystal Clear
- As estratégias e técnicas específicas ligadas às propriedades
- O processo de forma geral desde os períodos longos até os pequenos episódios de desenvolvimento do dia a dia
- Os produtos gerados
- Erros frequentes cometidos com metodologias ágeis
- Perguntas frequentes como comparação com XP, CMMI, etc.
- Um Estudo de Caso

Recomendo fortemente o livro, especialmente para equipes que sentem que Extreme Programming é um processo muito disciplinado e que requer pessoas mais experientes. Como o próprio Cockburn descreve o seu processo é menos estrito em diversos pontos e estrito em alguns outros poucos.

De forma geral creio que é um excelente processo para ser usado em times pequenos.

Aproveito para fazer outra recomendação de livro que li, aos desenvolvedores J2EE. O livro se chama POJOs in Action . É um guia prático e uma visão geral dos principais frameworks leves para desenvolvimento J2EE com um POJO Domain Model e usando frameworks como iBatis, JDO, Hibernate, Spring. Tem uma base ótima em visão arquitetural e utilizando os princípios de Domain-Driven Design . Possui também capítulos falando sobre a nova especificação do EJB 3.0. É um livro que não foca em uma tecnologia específica pois tem um objetivo(que considero muito bom!) de demonstrar as tecnologias existentes, seus prós e contras e possíveis situações em que cada uma delas melhor se encaixa. Se o interesse é por alguma das tecnologias específicas fica a recomendação para os livros Hibernate in Action e Spring in Action .

Marcadores:

terça-feira, janeiro 24, 2006

Certificações IBM Rational

Hoje finalmente finalizei o ciclo de certificações IBM Rational que eu almejava. Em três semanas realizei cinco exames para obter três certificações distintas.

Para obter a certificação IBM Certified Specialist for Rational Unified Process foi necessário o teste 639: Rational Unified Process realizado em centro autorizado Prometric.

Para obter a certificação IBM Certified Specialist for Rational Requirements Management w/Use Cases foram necessárias quatro provas realizadas em centro autorizado Prometric:
Teste 636 - Requirements Management with Use Cases - Part 1
Teste 637: Requirements Management with Use Cases - Part 2
Teste 638: Rational RequisitePro
Teste 639: Rational Unified Process

Para obter a certificação IBM Rational Solution Sales Professional foi necessário realizar um exame via web.

É importante lembrar que estas certificações são abertas ainda apenas para IBM Business Partners. Porém qualquer um pode fazer o exame na Prometric. Apenas não conseguirão receber o certificado oficial da IBM.

Meus scores nas provas foram os seguintes:
Requirements Management with Use Cases Part 1 --> 78% (Mínimo para passar 68%)

Requirements Management with Use Cases - Part 2 --> 94% (Mínimo para passar 68%)

Rational RequisitePro --> 82% (Mínimo para passar 75%)

Rational Unified Process --> 93% (Mínimo para passar 70%)

Rational Sales Mastery --> 94.1% (Mínimo para passar 75%)


As provas costumam ter quatro alternativas por questão sendo que algumas questões podem ter mais de uma resposta possível. Apenas a prova de RUP (que é a mais complexa e possui maior quantidade de assuntos) possui sempre 5 alternativas (inclusive para as questões com mais de uma resposta!!!), o que torna a prova mais difícil.

Recomendo as seguintes estratégias para estudo por prova:
Requirements Management with Use Cases Part 1 --> Material de Treinamento Oficial da IBM do curso Mastering Requirements Management with Use Cases e leitura da disciplina de Requirements do RUP 2003. A parte 1 foca mais nos conceitos da gestão de requisitos e gestão de mudanças.

Requirements Management with Use Cases - Part 2 --> Material de Treinamento Oficial da IBM do curso Mastering Requirements Management with Use Cases e leitura da disciplina de Requirements do RUP 2003. A parte 2 é voltada para modelagem de casos de uso (sabia que esse era meu forte :-)! ).

Rational RequisitePro --> Material de Treinamento Oficial da IBM do curso Essentials of Rational RequisitePro e experiência de uso na ferramenta propriamente dita.

Rational Unified Process --> Material de Treinamento Oficial da IBM do curso Essentials of Rational Unified Process, leitura do RUP 2003 (a fundo!) e experiência prática com o RUP.

Rational Sales Mastery --> Apresentações de Vendas da IBM Rational liberadas para parceiros e livros de vendas de soluções.

Quem tiver interesse em mais informações basta deixar um comentário neste artigo. Se eu puder responderei com prazer! Minhas próximas metas de certificações esse ano ainda são: ITIL, Cobit e MSF 4.0. Para o início do ano que vêm (também tenho que terminar meu mestrado este ano!!!) o PMP.

José Papo, o mais novo:

IBM Certified Specialist for Requirements Management w/Use Cases
IBM Certified Specialist for Rational Unified Process
IBM Rational Solution Sales Professional

Marcadores:

segunda-feira, janeiro 23, 2006

Ambientes de Desenvolvimento de Software - Parte VII

Este artigo demonstra um exemplo de uso da ferramenta de issue tracking Eventum integrada com a ferramenta de controle de versões para uma gerência de configuração mais integrada. É importante notar que alguns passos de configuração foram necessários para gerar a integração como a alteração do repositório do Subversion para uso de atributos, criação de post-commit hooks, configuração do Eventum e alteração de configurações no WebSVN. O objetivo é finalmente mostrar como é a face deste ambiente integrado e não as configurações e customizações necessárias para se chegar neste ponto final.

A primeira tela da demonstração mostra a criação de um issue de defeito no Eventum:


Outras pessoas podem adicionar notas ao issue aberto e ao mesmo tempo alterar o status do defeito (no caso para status implementação):


Pode-se notar a alteração de status e como ela é visualizada através de cores diferenciadas. Perceba também que o ID do bug(ID único e individual por issue) é 8:


Vamos agora fazer uma alteração em alguns arquivos de código-fonte. A tela abaixo mostra o Windows Explorer antes da alteração:


Aqui se vê após a alteração dos arquivos MVC.aspx e MVC.aspx.cs:


Vamos fazer um commit no Subversion das alterações realizadas:


A tela da mensagem de log aparece. Notem que um campo chamado BugID aparece na interface do TortoiseSVN. Este só aparece devido a alterações de atributos do repositório. O que faremos é associar esse changeset ao ID do bug 8 que está no Eventum e que foi criado em passos anteriores:


Fazemos o commit e note que o número do changeset(revision) é 22:


Confirmando que os fontes locais agora estão atualizados com o repositório:


E agora a grande mágica realizada pelos hooks ligados a scripts do Eventum. Os fontes que foram modificados aparecem automaticamente no campo de SCM Integration existente no issue do Eventum:


Clicando no link você é levado diretamente à página do WebSVN relacionado ao fonte:


Você também pode clicar no link que leva diretamente às diferenças entre a versão gerada para corrigir o defeito e a versão anterior:


E na página que contém o changeset 22 mais uma excelente surpresa. O ID do Bug (no caso 8) está na página do changeset. Clicando no link do número 8 somos levados ao bug que foi aberto no Eventum:


Para ficar ainda mais interessante. A mesma informação acima também pode ser vista através da lista de mensagens de logs existentes no TortoiseSVN(e o link para o bug também está lá):


Para terminar a demonstração podemos fechar o issue:


Verificamos a tela de buscas e notamos que o issue foi fechado:


E temos também a ótima tela de gráficos do eventum com informações sumarizadas dos issues do projeto:


E finalmente terminamos a demonstração da integração entre Eventum, Subversion, TortoiseSVN e WebSVN. O próximo artigo dessa série tratará do tipo de integração existente hoje entre o Eventum e o dotProject. Mas com certeza a integração até esse ponto já é um grande diferencial qualitativo tanto em termos gerenciais como de produtividade ao desenvolvedor devido à facilidade de analisar e encontrar informações relevantes à configuração de software atrelada com os issues que geraram as alterações. A funcionalidade de integração com sistemas de controle de versão é um dos recursos que considero essenciais para as ferramentas de issue tracking atuais e que possuem como objetivo suportar o processo de desenvolvimento de software.

O trabalho de integração não é tão complexo e permite um salto de qualidade no processo de qualquer projeto. O livro Ship It! enfatiza a essência dessa infra-estrutura.

Marcadores:

segunda-feira, janeiro 16, 2006

Scarab: Mais uma opção de ferramenta de issue tracking

O Scarab é mais uma opção para quem está procurando uma ferramenta de issue tracking.

Lembrando que as outras opções muito interessantes, já avaliadas aqui ou utilizadas por mim em projetos, são:

- Mantis Bug Tracker
- Eventum
- Jira (não é gratuito)
- IBM Rational ClearQuest (não é gratuito)

O Scarab é fácil de instalar, apesar de necessitar do Ant(ele foi feito em Java e não em PHP como o Eventum e o Mantis), pois não vêm compilado. Em um próximo artigo colocarei um guia rápido de instalação e dicas para seu uso. Sua forma de uso é muito similar ao Jira(usa, por exemplo, três letras com as iniciais de um módulo para diferenciar issues de cada módulo mas poder tratá-los em conjunto quando necessário), apesar de sua interface Web não ser tão bem elaborada.

Pontos fortes do Scarab:
- Capacidade de customização de workflow de status e/ou qualquer outro campo combo box. Pode definir regras de segurança específicas de quais perfis podem mudar determinado status.

- Tipos de issues (defeitos, recursos, mudanças, riscos, etc) podem ser configurados e inclusive cada projeto(módulo) pode possuir tipos diferenciados.

- Tipos de atributos configuráveis por projeto

- Validação automática de campos, para verificar possibilidade de duplicação de issues

- Integração com Subversion

Pontos fracos:
- O principal é a documentação ainda básica e pouco amigável (em comparação com a do Jira, por exemplo)


No geral, fiquei muito empolgado com a ferramenta, devido às possibilidades de customização de status e workflows. Este recurso é um grande diferencial que ferramentas pagas como o Jira e o ClearQuest possuem em comparação ao Mantis e ao Eventum.

Recomendo fortemente para as empresas que precisam tratar issues diferentes com customizações específicas por projetos, e que não possuem orçamento para a compra de uma ferramenta paga.

Devido à sua flexibilidade, assim que eu finalizar o artigo com a integração do Eventum com o Subversion e o DotProject, escreverei alguns artigos detalhando também a ferramenta Scarab e sua integração com o Subversion.

Marcadores:

segunda-feira, janeiro 02, 2006

A importância de um especialista de processos e ferramentas

Um grande número de empresas de desenvolvimento de software ou que dependem largamente deste desenvolvimento para seus negócios não possuem pessoas ou equipes focadas na gestão e melhoria de processos de desenvolvimento e manutenção de software e do ambiente geral de gestão e desenvolvimento.

Quando existem essas áreas ou equipes costumam receber nomes variados como metodologia, SEPG, Engenharia de Software, Processos, etc. Mesmo quando isso ocorre existem certos problemas comuns que essas equipes e os gestores que a suportam enfrentam.

Vamos analisar inicialmente a importância dos especialistas de processos e ferramentas. Sem estas pessoas cada um dos gerentes de projeto e suas respectivas equipes usarão práticas variadas de gestão e desenvolvimento. Cada projeto pode e deve ser customizado de acordo com as suas especificidades, mas sem seguir uma base de apoio padrão irá provavelmente gerar retrabalho e muitas vezes práticas pouco aderentes. Além disso o esforço de pessoas que deveriam estar focadas em sua maior parte nos projetos pode acabar sendo desviada deste foco. Muitas vezes, especialmente na falta de um gerente de projetos especializado em desenvolvimento de sistemas, dentro de uma mesma equipe pode existir formas distintas de realizar e controlar os mesmos tipos de atividades.

Nas empresas mais "espertas" esse comportamento improdutivo é mitigado com o uso de especialistas em processos e ferramentas. Elas sabem que um ambiente padrão e pensado previamente para a criação de sistemas produz melhores resultados que uma coleção de ferramentas e práticas distintas e sem integrações automáticas e/ou manuais.

Os especialistas em processos e ferramentas devem estar ligados em todas as áreas do desenvolvimento de software: Requisitos, Análise e Design, Arquitetura de Software, Programação, Testes, Gestão de Configuração e Mudança, Manutenção de Sofware, etc. O ideal é que eles conheçam e possuam experiência em todas as áreas, mas esses profissionais são mais raros (modéstia à parte você pode encontrar um deles falando com o autor deste artigo... rs ). Também devem conhecer e ter experiência com no mínimo duas ferramentas de SCM, duas ferramentas de build, duas ferramentas de issue tracking, duas ferramentas para gestão de projetos, duas ferramentas de gestão de testes, uma ferramenta de integração contínua, uma ferramenta de automação de testes funcionais e outra de testes unitários. Realmente é muita coisa e poucas pessoas conhecerão todas. Dependendo do tamanho das equipes de desenvolvimento e da quantidade de suporte às equipes que os especialistas terão de fornecer será necessário a contratação de uma equipe maior.

Erros comuns (e gravíssimos!!!) cometidos por equipes de processos e que devem ser evitados:

- Não coletar feedbacks acerca dos processos e ferramentas das equipes envolvidas no dia a dia dos projetos. Esse fator também é conhecido como "Torre de Marfim" onde os especialistas de processos ficam em suas salas criando processos maravilhosos mas que na prática poucos conseguem usar devido à sua rigidez e burocracia.

- Não automatizar. Esse é crítico também pois alguns processos sem automação geram burocracias, dores de cabeça e trabalhos inúteis que seriam resolvidos facilmente por uma ferramenta. Pense por exemplo no custo de se produzir um documento Word por requisição de mudança ou uma planilha de defeitos separada por projeto. A dificuldade em obter métricas, controlar projetos e saber quando um determinado defeito foi fechado ou se ainda está em análise é fundamental para o gerente de projetos.

- Oferecer atualizações regulares do status do ambiente de desenvolvimento aos envolvidos

- Ter o apoio constante da alta gerência, dos gerentes de projeto e das equipes de desenvolvimento. Esse é obtido principalmente com a demonstração de resultados da implantação de melhores processos e ferramentas.

- Acompanhar e dar mentoring às equipes dentro dos próprios projetos. Vivenciar e entender os problemas pelos quais as equipes passam é fundamental para a melhoria contínua.

- Customizar os processos e ferramentas de acordo com cada projeto. Um projeto de manutenção é diferente de um projeto de desenvolvimento de um novo sistema do zero. Um sistema de missão crítica é diferente de uma intranet departamental. Os especialistas de processos devem estar presentes e incluídos nos projetos especialmente em suas fases iniciais.


Espero ter deixado claras as necessidades que temos desses profissionais e das ferramentas de suporte para conseguir criar produtos com mais qualidade, agilidade, produtividade e menor retrabalho.

Marcadores:

Ferramentas para Gerenciamento de Testes

O assunto de hoje é acerca do processo de gerenciamento de testes e de casos de teste.

A grande maioria das empresas possui ainda pouca disciplina no processo de testes. Mesmo as organizações que possuem processos e profissionais experientes em técnicas de testes costumam registrar e organizar seus planos, casos de testes e resultados de testes em planilhas Excel e/ou documentos de texto. A grande desvantagem dessa abordagem(como qualquer outra abordagem que não utiliza banco de dados para armazenamento de informações) é a maior dificuldade de gerar relatórios, métricas e buscas específicas de informações.

Temos no mercado excelentes ferramentas pagas como o Rational TestManager e o Mercury TestDirector.

Porém, como sabemos, nem todas as empresas tem orçamento para adquirir soluções deste porte. Isso ocorre mesmo com uma análise demonstrando que estas ferramentas trazem grandes benefícios. Além disso são soluções que não estão disponíveis com facilidade para todos os estudantes e pessoas interessadas em aprender mais sobre processos de testes e conceitos envolvidos nas ferramentas de gestão de testes.

Portanto também indicamos aqui ferramentas open source. As duas mais interessantes que analisei foram o TestLink e o QATrak (outras podem ser encontradas aqui).

O QATrack possui a interface gráfica mais interessante. Porém ela não possui algumas características que considero essenciais e que estão disponíveis no TestLink. Estas características são: o registro de requisitos e o relacionamento destes com os casos de testes, a execução e o armazenamento dos resultados de testes por builds e uma interface para ferramentas de bug tracking (atualmente com Bugzilla, JIRA e Mantis).

Os relatórios gerados pelo TestLink também são mais informativos, incluindo um com os resultados de testes com base nos requisitos.

Conceitos implementados pela ferramenta TesLink:

Especificação de Requisitos: onde os analistas de testes registram os requisitos que serão testados e alocam os casos de testes relacionados a cada um dos requisitos.

Produto, Componente e Categoria: O Sistema sob teste e seus módulos. Uma forma de organizar os casos de testes de cada Produto.

Plano de Testes: Onde são adicionados os casos de testes de produtos relacionados a um plano de testes de um projeto específico.

Casos de Teste: Onde são registradas as informações de cada um dos procedimentos de testes das funcionalidades do sistema.

Build: Uma versão específica de software gerado por um projeto. O Build está relacionado a um plano de testes específico.

Em um artigo futuro descreverei uma idéia para a gestão de projetos utilizando um conjunto de ferramentas open source (algumas integradas e outras não) e uma customização para estas ferramentas baseadas em um processo de desenvolvimento padrão para pequenos e médios projetos. Adianto já que esta idéia terá como fundamentos conceitos retirados do RUP, MSF, Extreme Programming e SCRUM.

Por enquanto recomendo o download do TestLink e sua utilização em projetos. Além da automação dos planos de testes ele trará um benefício para a equipe de testes relacionado com o aprendizado que esta irá obter dos principais conceitos relacionados à diciplina de Testes de Software.

Marcadores:


Veja as Estatísticas