The Bug Bang Theory

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

 Loading ...

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

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

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

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

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

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

2 – Cadastrar as práticas.

(Cadastrar especificações de requisitos e requisitos)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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