Fedora kalite güvence ekibinin 4 ana sorumluluğu bulunuyor; Hata sınıflandırma, Güncelleme testleri , Sürüm testleri, Test araçları geliştirmek.
Hata sınıflandırma bölümünde hataların doğru insanlara atanmasını sağlıyorlar.
Güncelleme testlerini Bodhi [1] adındaki web tabanlı bir yazılım ile gerçekleştiriyorlar. Bu yapının önemli avantajlarından birisi detaylı ölçüm ve istatistikler tutmaya izin vermesi [2]. Konu ile ilgili ilginç bulduğum ilk nokta yeni paketlerin test edilip edilemeyeceği kararını paket için güncelleme isteyen geliştirici belirliyor. İkinci ilginç nokta ise paketlerin testi dondurulmuş belirli bir depo durumu içinde değil tek tek paketler üzerinde yapılıyor olması.
Sürüm testleri üzerinde oldukça detaylı çalışılan bir süreç, 2 temel kategoriye ayrılıyor güncelleme ve kurulum testleri ve yeni özelliklerin test edilmesi. Hangi özelliklerin sürüme alınacağına ve hangi hataların sürüm için engelleyici olduğuna bu testler sonucu karar veriyorlar.
Sürüm testleri için oldukça detaylı bir test planına sahipler [3] hangi ön sürümün hangi adımlara kadar sorunsuz çalışması gerektiği belirlenmiş durumda. Bundan dolayı test ettikleri adımları daha detaylı biçimde test edebiliyorlar. Özetle beklentilerini ilk adımlarda düşük tutarak eldeki iş gücünü daha verimli değerlendirebiliyorlar.
Bu kategorideki test sonuçlarını pek renkli fakat hoş bir tablo üzerinden takip ediyorlar [4] . Burada dikkatimi çeken nokta ise her test adımının 1 kişi tarafından onaylanmasını test sonucu için yeterli görmeleri oldu.
Tabi bütün bu süreçler için hazır şablon belgelerden [5] yararlanıyorlar. Ayrıca her sürüm ile ilgili bilinen hataları ve çözümlerini listeledikleri [6] bir sayfaları mevcut.
Bu testler sırasında düzeltilen hataları NEEDSRETESTING olarak işaretleyerek [7] istekli testçiler tarafından yeniden test edilmesini sağlıyorlar.
Test araçları geliştirme bölümünde farklı kategorilerden araçlar üzerinde çalışıyorlar. Kurulum testleri için SNAKE [8] , python-bugzilla kütüphanesi [9] , ve Bodhi [10] bunlardan öne çıkanlar. Ayrıca test sistemini tam anlamı ile otomatik hale getirecek Breaker [11] aracının geliştirmesi de devam ediyor.
Bu noktada Breaker'ın üzerinde biraz daha durmakta fayda var. Breaker aslında RedHat tarafından kullanılan RHTS [12] aracının Fedora portu. Ancak aracı sadece port etmiyor aynı zamanda bazı özelliklerini ( örneğin test yazımı [13] gibi ) değiştiriyorlar. Test sonuçlarını Spike[14] adındaki bir arayüz ile kaydediyor.
Bittiğinde neredeyse tamamen otomasyona geçirilmiş ( alandığım kadarıyla GUI testleri içinde DogTail [15] entegrasyonu planlıyorlar ) bir test sistemine sahip olacaklar.
RHTS ve DogTail a biraz daha yakından bakacağım sanırım. Belki bu serinin ardından bir seri de otomatik test araçları için yazmak fena olamaz
[1] https://admin.fedoraproject.org/updates/F10/pending
[2] https://admin.fedoraproject.org/updates/metrics/?release=F10
[3] http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install
[4] http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha
[5] http://fedoraproject.org/wiki/QA/TreeTestingTemplate
[6] http://fedoraproject.org/wiki/Bugs/Common
[7] http://feeds.feedburner.com/NeedsRetesting
[8] https://fedorahosted.org/snake/
[9] https://fedorahosted.org/python-bugzilla/
[10] https://fedorahosted.org/bodhi/
[11] http://fedoraproject.org/wiki/QA/Beaker
[12] https://testing.108.redhat.com/wiki/index.php/Rhts
[13] https://testing.108.redhat.com/wiki/index.php/Rhts/Docs/TestWriting
[14] http://developer.spikesource.com/wiki/index.php/Test_Results_Publication_Interface
[15] http://people.redhat.com/zcerza/dogtail/
Pazartesi, Ocak 12, 2009
Salı, Ocak 06, 2009
Test Dünyasında Neler Oluyor ( Bölüm-2 Mandriva )
Serinin bu bölümünde dünyadaki en yaygın son kullanıcı dağıtımlarından birisi olan Mandriva'nın test ve bununla bağlantılı olarak kararlı depoya paket giriş süreçlerini inceleyeceğiz. Serinin bir önceki yazısını burada bulabilirsiniz.
Sanırım en doğrusu bir paketin kararlı depoya giriş sürecini [1] anlatarak başlamak olacak. Bir paket kararlı olduğuna emin olunan main/updates deposuna alınmak isteniyorsa, paketçi öncelikle bununla ilgili bugzilla raporu açar.
Bu rapor paketin neleri değiştirdiğini ve düzelttiğini anlatan advisory ile nasıl test edilmesi gerektiğini içerir ( örneğin: paketin kapattığı hatayı tekrar eden bir betik ve bunun dışındaki temel işlevleri nasıl test edileceğine dair bilgiler gibi). Hata kaydı kalite güvence takımına atanır( qateam ) ve güvenlik takımı da CC ye alınır ( secteam ). Bu işlemin ardından paket main/testing deposuna alınır.
Kalite-Güvence takımı pakete onay vermemişse ( daha iyi bir test-case yazılması veya uygulamanın kullanımına dair daha detaylı bilgi verilmesi bile olabilir bu ) paketin bakıcısı bu sorunları gidermek zorundadır.
Paketler ile ilgili hatalar tek bir e-posta adresinden giriliyor anladığım kadarıyla bunun amacı mesajlardan bütün takımın haberdar olması ve katkıda bulunabilmesi.
Kalite-Güvence takımdan onay alan paket için ilgili rapor güvenlik takımına atanır. Güvenlik takımı kaynak rpm dosyasını temiz bir sistemde yeniden inşa eder, paket ile ilgili advisory bültenini yayımlar [2] ( bu nokta ilginç aslında, konu güvenlikle ilgili olmasa dahi bütün paketler güvenlik takımından geçiyor ve düzeltme ile ilgili bülten yayımlanıyor ). Bu işlemlerin ardından paket main/updates deposuna alınarak hata kapatılır.
Anladığım kadarıyla güvenlik güncellemeleri ve kritik güncellemeler yukarıdaki politikanın dışında tutuluyor.
Bunun yanı sıra test otomasyonu (buna yarı-otomatik diyelim :) ) için web tabanlı testzilla[3] adlı bir araçtan faydalanıyorlar. Bu aracın temel işlevi testçinin donanım setine uygun olarak test edebileceği paketleri göstermek [4] ve bu paketler ile ilgili raporları girmesini sağlamak.
Asıl otomatik testler yalnız Paris'deki merkez ofiste yapılabiliyormuş. Burada PXE üzerinden başlatılan bilgisayarlara bu iş için özelleştirilen bir sürüm yükleniyor ağ üzerinden ve bu bilgisayarlarda önceden yazılmış test betikleri [5] çalıştırılıyor ve otomatik raporlar üretiliyor bugzillaya girilen.
Bunların yanı sıra bu prosedürleri ve betikleri wikiye aktarıyorlar [6] [7] belirli bir template [8] yapısı içinde.
Son olarak çekirdek testleri için ayrı bir bölüm ayırmışlar [9] ve çekirdek güncellemelerine ayrı bir özenle yaklaşıyorlar. Bu konuda da otomatik test için bir takım araçlardan haberdarlar ancak bunların ne kadarını kullandıklarına dair bir ipucu içermiyor test belgesi.
[1] http://wiki.mandriva.com/en/Policies/Support
[2] http://wiki.mandriva.com/en/2009.0_Errata
[3] http://wiki.mandriva.com/en/Development/Howto/Testzilla
[4] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup
[5] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup
[6] http://wiki.mandriva.com/en/Testing
[7] http://wiki.mandriva.com/en/Testing:Bind
[8] http://wiki.mandriva.com/en/Testing:Template
[9] http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_Kernels
Sanırım en doğrusu bir paketin kararlı depoya giriş sürecini [1] anlatarak başlamak olacak. Bir paket kararlı olduğuna emin olunan main/updates deposuna alınmak isteniyorsa, paketçi öncelikle bununla ilgili bugzilla raporu açar.
Bu rapor paketin neleri değiştirdiğini ve düzelttiğini anlatan advisory ile nasıl test edilmesi gerektiğini içerir ( örneğin: paketin kapattığı hatayı tekrar eden bir betik ve bunun dışındaki temel işlevleri nasıl test edileceğine dair bilgiler gibi). Hata kaydı kalite güvence takımına atanır( qateam ) ve güvenlik takımı da CC ye alınır ( secteam ). Bu işlemin ardından paket main/testing deposuna alınır.
Kalite-Güvence takımı pakete onay vermemişse ( daha iyi bir test-case yazılması veya uygulamanın kullanımına dair daha detaylı bilgi verilmesi bile olabilir bu ) paketin bakıcısı bu sorunları gidermek zorundadır.
Paketler ile ilgili hatalar tek bir e-posta adresinden giriliyor anladığım kadarıyla bunun amacı mesajlardan bütün takımın haberdar olması ve katkıda bulunabilmesi.
Kalite-Güvence takımdan onay alan paket için ilgili rapor güvenlik takımına atanır. Güvenlik takımı kaynak rpm dosyasını temiz bir sistemde yeniden inşa eder, paket ile ilgili advisory bültenini yayımlar [2] ( bu nokta ilginç aslında, konu güvenlikle ilgili olmasa dahi bütün paketler güvenlik takımından geçiyor ve düzeltme ile ilgili bülten yayımlanıyor ). Bu işlemlerin ardından paket main/updates deposuna alınarak hata kapatılır.
Anladığım kadarıyla güvenlik güncellemeleri ve kritik güncellemeler yukarıdaki politikanın dışında tutuluyor.
Bunun yanı sıra test otomasyonu (buna yarı-otomatik diyelim :) ) için web tabanlı testzilla[3] adlı bir araçtan faydalanıyorlar. Bu aracın temel işlevi testçinin donanım setine uygun olarak test edebileceği paketleri göstermek [4] ve bu paketler ile ilgili raporları girmesini sağlamak.
Asıl otomatik testler yalnız Paris'deki merkez ofiste yapılabiliyormuş. Burada PXE üzerinden başlatılan bilgisayarlara bu iş için özelleştirilen bir sürüm yükleniyor ağ üzerinden ve bu bilgisayarlarda önceden yazılmış test betikleri [5] çalıştırılıyor ve otomatik raporlar üretiliyor bugzillaya girilen.
Bunların yanı sıra bu prosedürleri ve betikleri wikiye aktarıyorlar [6] [7] belirli bir template [8] yapısı içinde.
Son olarak çekirdek testleri için ayrı bir bölüm ayırmışlar [9] ve çekirdek güncellemelerine ayrı bir özenle yaklaşıyorlar. Bu konuda da otomatik test için bir takım araçlardan haberdarlar ancak bunların ne kadarını kullandıklarına dair bir ipucu içermiyor test belgesi.
[1] http://wiki.mandriva.com/en/Policies/Support
[2] http://wiki.mandriva.com/en/2009.0_Errata
[3] http://wiki.mandriva.com/en/Development/Howto/Testzilla
[4] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/procedures/NVIDIA/procedure.html?revision=1.5&view=markup
[5] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/testzilla/tests/pamd/valid-pamd-modules.test?revision=1.2&view=markup
[6] http://wiki.mandriva.com/en/Testing
[7] http://wiki.mandriva.com/en/Testing:Bind
[8] http://wiki.mandriva.com/en/Testing:Template
[9] http://wiki.mandriva.com/en/Development/Howto/Test_Update_Candidate_Kernels
Kaydol:
Kayıtlar (Atom)