[firebase-br] Firebird Project - Garantia de Qualidade

Eduardo Jedliczka eduardo em gerasoft.com.br
Ter Mar 8 09:28:45 -03 2005


Segue abaixo um texto extraído do site IBPhoenix sobre o programa de
"testes" para o FireBird 2.0, talvez seja uma boa idéia sé nós brazucas nos
unissemos para testar o nosso querido "pássaro de fogo" e assim "acelerar" o
seu lançamento...

Estou ciente que muitos aqui já tem conhecimento desta notícia, mas
certamente não todos ...

[s]

==========================
Eduardo Jedliczka
Gerasoft Informática
Apucarana - Pr
==========================

- - - - - -

Firebird Project - Garantia de Qualidade

Olá a todos,

O Projeto Firebird em breve irá lançar a primeira versão "alfa" do Firebird
2.0.
Esta versão é um lançamento longamente aguardado do Firebird com muitas
novas
funcionalidades, melhoramentos e correções de erros. Para mais detalhes veja
as
Release Notes da versão alfa em:

http://firebird.sourceforge.net/download/prerelease/rnotes0200_01.zip

Em número de mudanças, o salto neste lançamento é equivalente (senão maior)
ao
feito quando da transição da versão 1.0 para a 1.5.

Vocês sabem o quanto nos preocupamos com a qualidade, e não iremos lançar a
versão final do Firebird 2.0 enquanto este não estiver cumprindo nossos
exigentes
requisitos de Garantia de Qualidade (GQ).  Para a versão 1.5, isso demorou
um ano
antes de estarmos satisfeitos. Mas desta feita estamos em uma situação um
tanto
diferente.

O projeto Vulcan atingiu a meta de usabilidade geral, com algumas poucas
pontas
soltas, e desejamos juntar ambas as bases de código o mais cedo possível.
Dessa
junção resultará no Firebird 3.0 com total suporte a multiprocessamento
simétrico
(SMP), arquitetura unificada (sem mais nenhuma necessidade de compilações
classic/superserver/embedded ) e outros melhoramentos. Para obter mais
detalhes
sobre o Vulcan visite a url abaixo:
http://www.ibphoenix.com/downloads/VulcanOverview.pdf

Além dos claros benefícios para os usuários de Firebird, esta junção irá
resultar uma
arquitetura e base de código mais limpas e concisas; e completará a
transição do
antigo código procedural em C para um código totalmente OOP em C++. Isso irá
abrir portas para desenvolvedores para projetar e implementar
funcionalidades mais
complexas namespaces, tabelas temporárias e outras tantas funcionalidades
altamente requisitadas.

Mas não podemos focar a junção Firebird/Vulcan antes que a versão final do
Firebird 2.0 seja lançada; de modo que gostaríamos de encurtar a fase de GQ
tanto
quanto possível; mas sem comprometer nossos exigentes requisitos de
qualidade
para essa versão. Nós *podemos* faze-lo se fizermos nosso processo de GQ
mais
eficiente. A eficiência do processo de GQ do Firebird é altamente dependente
do
retorno proporcionado por nossos usuários finais, deste jeito é natural que
comecemos nossa busca por um GQ mais eficiente com isso.

Até o momento, o retorno dos usuários era aleatório e totalmente na mão dos
usuários. Basicamente, nós lançamos uma compilação,  esperamos por retorno
durante um tempo e resolvemos as questões reportadas (assim como outros
problemas que porventura encontremos internamente durante esse período). Se
nenhum problema importante for encontrado e / ou reportado desde a última
compilação do Release Candidate, essa compilação será re-empacotada como
sendo
a final. Claro que existem estágios alfa e beta que também seguem esse
padrão, mas
diferem em que mudanças os desenvolvedores pode fazer no código.

Embora esta rotina tenha nos servido bem no passado, ela possui uma
desvantagem
importante: nós não sabemos o quanto a compilação foi testada em campo,
tanto em
escala quanto em cobertura de funcionalidades. Nós podemos apenas adivinhar
a o
quadro de forma estimada baseados na contagem de downloads, retorno direto,
"ouvir dizer", estágio de desenvolvimento, etc. para estimar o "índice de
qualidade".
Nós também temos apenas um uma medida para trabalhar: tempo, o que causa o
longo ciclo de lançamentos.

Para melhorar isso, nós gostaríamos de iniciar um programa de testes de
campo
gerenciados, iniciando com o Firebird 2.0. Este teste de campo gerenciado
*não irá*
substituir nosso cenário de teste usual (ou os teste internos), mas deve
agir como um
complemento às outras rotinas de GQ que nós utilizamos. O objetivo do teste
de
campo gerenciado é coletar informações precisas sobre o campo de test (ou
seja,
como a compilação lançada foi testada e com qual resultado), de modo a
obtermos
uma melhor estimativa do resultado do processo de GQ, focando em brechas
abertas
no GQ e alocar melhor nossos recursos de GQ mais precisamente, desta forma a
construir a confiança na qualidade do código mais rapidamente.

A participação no teste de campo gerenciado é muito simples. Você precisa se
inscrever enviando email para <pcisar ARROBA ibphoenix.cz>; onde você
descreverá como deseja testar nosso lançamento. Nós preferimos qualquer
método
de teste que se aproxime do uso real. Isso significa que, se você possui uma
aplicação que roda sobre o Firebird, você pode simplesmente rodar num "test
drive"
com o novo lançamento do Firebird em algum ambiente de teste,
preferivelmente
com dados reais. Claro que você pode utilizar qualquer método de teste lhe
coniver,
e pode mesmo focar apenas uma área particular a qual lhe interesse  mais
(como por
exemplo: otimizador, performance, backup/restore, novas funcionalidades,
etc).
Você deve também qual o(s) tipo(s) de Firebird (CS / SS / embedded)  você
utilizará
em seus testes e as plataformas nas quais será efetuado os testes.  Nós
enviaremos a
você uma notificação de quando a nova(s) compilação(ões) de teste estará(ão)
disponível, e nós esperaremos um relatório de você com o resultado (tanto
bom
quanto ruim) de seus testes.

Nós sabemos que tal compromisso não é fácil de cumprir, então é possível que
você
pule uma compilação de teste e deixe definitivamente o programa a qualquer
ponto.
Assim, iremos recompensar aqueles que nos ajudaram! Nós criamos uma "cesta
de
prêmios" que atualmente contém camisa pólo na cor e estampa que você
escolher da
IBPhoenix, mas nós acreditamos que poderemos obter mais prêmios nesta cesta
antes do lançamento da versão final do Firebird 2.0. No fim do ciclo de
lançamentos
nós recompensaremos o(s) testador(es) mais "ativo(s)"  e um testador
escolhido
aleatoriamente.

O programa de teste de campo gerenciado é aberto a todos, a qualquer momento
no
ciclo de lançamentos ( inciando com a primeira versão alfa até o último RC),
mas
aqueles que inscreverem cedo terão uma chance melhor de obter uma recompensa
por sua ajuda.

Pavel Cisar
Divisão de GQ do Projeto Firebird
Se o seu inglês tem alguns problemas, contacte qa em comunidade-firebird.org





Mais detalhes sobre a lista de discussão lista