Bug Box

Qualidade e Testes de software

Usando o Redmine + Impasse para Garantia da Qualidade

 

O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos.

SOFTEX, 2001, p37.

 

Neste contexto, identifica-se a necessidade de ferramental para o controle deste processo. Pensemos então, no seguinte cenário: a realização da gestão de testes, defeitos, projeto (tarefas), cronogramas, base de conhecimento, além do nosso tema principal QA em uma só ferramenta!

Este Post nasceu de uma necessidade de realizar este controle integrado, e também, com base em uma proposta do Camilo Ribeiro no post Usando TestLink para Garantia de Qualidade.

 

 

Antes de ler, compreenda que…

 

  • O objetivo deste post é demonstrar, de uma maneira prática (porém fictícia) que há uma forma de executar o processo de garantia da qualidade, utilizando a ferramenta Redmine, com o plugin de testes Impasse.
  • A combinação Redmine + Impasse tem como objetivo principal controlar o processo de teste de software. No entanto, foi possível “enxergar” esta aplicabilidade, com base em uma necessidade!
  • O modelo proposto não é o único, nem o mais completo ou perfeito. Serve para nortear as atividades necessárias para a realização deste processo!
  • Já vamos iniciar com a “mão na massa”! Então, se houver alguma dúvida sobre esta ferramenta, pode ser consultado o post Integração da gestão de testes e defeitos: Redmine & Impasse, pois nele existem duas seções que explicam mais sobre cada uma delas.

 

Mãos à obra! 

 

Para exemplificar, foi utilizado um cenário de utilização do processo RUP, onde o ciclo de vida do software é dividido em quatro fases: Iniciação, Elaboração, Construção e Transição.

Sendo assim: Temos um ciclo de desenvolvimento baseado em RUP, e necessitamos realizar a garantia da qualidade deste processo.

Para ficar mais didático as atividades foram transformadas em um pequeno processo, o qual está descrito no diagrama abaixo (clique sobre as caixas para entender a atividade):Entendida a parte conceitual, agora necessitamos utilizar na prática! Agora, serão demonstradas em cada uma das “caixinhas” do processo, como realizar as tarefas propostas na ferramenta.

 

CONFIGURAR TAREFAS

 

Na área de administração do Redmine, criar os campos customizados e a tarefa padrão para o controle das não-conformidades:

CONFIGURAR PROJETO

 

Cadastrar o projeto, habilitar o módulo “Gerenciamento de testes”, e também associá-lo ao tipo de tarefa criada na etapa anterior:

PLANEJAR VERIFICAÇÃO

 

Organizar da maneira mais conveniente ao processo, os itens que serão verificados durante o processo de garantia da qualidade. Esta organização é realizada com base no conceito de “Suites”. As suítes são como pastas e podem ser aninhadas. Em nosso exemplo, foi criada uma suíte para cada fase do ciclo de desenvolvimento do software:

Nesta etapa, serão criados os itens a serem verificados. Para isso, será utilizado o conceito de “Caso”. Cada “Caso” representará um checklist de verificação:

Neste momento, deve ser criado o projeto que será verificado.

Atenção: Para cada projeto-processo a ser verificado, deverá ser criado um novo plano. No entanto, a quantidade de planos a ser criada deve ser baseada nas necessidades de negócio a serem atendidas.

Associar os itens que serão verificados, ao plano recém criado:

Atribuir os itens aos responsáveis pela verificação:

 EXECUTAR VERIFICAÇÃO

 

Esta é a fase onde a verificação será executada, os resultados reportados e as não conformidades serão identificadas e tratadas.

Para realizar a operação, clicar sobre o item a ser verificado, realizar as verificações necessárias e em seguida marcar o resultado obtido. Caso o resultado seja uma falha (não conformidade), a opção correspondente deve ser marcada. Quando isso ocorre, o próprio plugin já exibe a tela para reportar a não conformidade, conforme os padrões pré-estabelecidos:

 Observe que, quando uma não conformidade é relatada, a mesma fica associada ao caso de origem:

Na seção “Estatísticas”, é possível acompanhar a progressão dos trabalhos, através dos relatórios disponíveis:

CONSIDERAÇÕES FINAIS

 

Como pode ser observado, o intuito principal do plugin não é a gestão do processo de verificação, no entanto, existe a possibilidade de controle do processo de maneira efetiva utilizando-o. Ao elaborar este post, pude perceber os seguintes aspectos:

  • Centralização das informações: Todas as verificações realizadas serão controladas em uma única ferramenta, não sendo necessário portanto gerar vários arquivos e armazená-los, diminuindo o risco dos dados ficarem “pulverizados”;
  • Reuso: Os itens a serem verificados poderão ser cadastrados apenas uma vez, e serem associados aos projetos de acordo com a necessidade;
  • Padronização: Este aspecto serve tanto para o planejamento, quanto a execução e controle das verificações. Uma vez que estão padronizados, controla-los acaba sendo uma tarefa menos onerosa.

 

REFERÊNCIAS

KAWASHIMA, Yoshitaka. User Manual / Redmine impasse.  Disponível em: <http://kawasima.github.com/redmine_impasse/user_manual.html>.

RIBEIRO, Camilo. Usando TestLink para Garantia de Qualidade. Disponível em: <http://www.bugbang.com.br/usando-testlink-para-garantia-de-qualidade/>

SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro: Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível F do MR-MPS. Disponível em: <http://www.softex.br/mpsbr/_guias/default.asp>.

InfoEscola, Navegando e Aprendendo. Rational Unified Process: Fases. Disponível em: <http://www.infoescola.com/engenharia-de-software/rup/>

COMMENTS

Não há comentários postados ainda. Seja o primeiro!

Deixe um comentário!


1 + = quatro