Pazartesi, Ağustos 31, 2009
Cuma, Haziran 26, 2009
BDD (Behavior Driven Development) Roadmap
So after a week I finally start to see the big picture for BDD. And here is the roadmap for a beginner on BDD. I think it'll be helpful on the road.
İntroduction to Behavior Driven Development
http://dannorth.net/introducing-bdd
http://behaviour-driven.org/
http://en.wikipedia.org/wiki/Behavior_driven_development
Jbehave2 Basics
http://jbehave.org/documentation/two-minute-tutorial/
http://www.bitmotif.com/java/jbehave-rave/
Jbehave2 Selenium and Matchers
http://blog.m.artins.net/tag/jbehave/
Jbehave2 Validations
http://www.testearly.com/2007/07/16/using-bdd-to-drive-development/
Mockito is your friend ( Also Jbehave's best friend )
http://code.google.com/p/mockito/wiki/FeaturesAndMotivations
http://mockito.googlecode.com/svn/branches/1.7/javadoc/org/mockito/Mockito.html
Deeper Jbehave2
http://www.ibm.com/developerworks/java/library/j-cq09187/
Deeper Jbehave2 Part-2 ( Some codes are misssing in the tutorial )
http://www.ryangreenhall.com/articles/bdd-by-example.html
Behavior Driven Database Development
http://www.methodsandtools.com/archive/archive.php?id=78
İntroduction to Behavior Driven Development
http://dannorth.net/introducing-bdd
http://behaviour-driven.org/
http://en.wikipedia.org/wiki/Behavior_driven_development
Jbehave2 Basics
http://jbehave.org/documentation/two-minute-tutorial/
http://www.bitmotif.com/java/jbehave-rave/
Jbehave2 Selenium and Matchers
http://blog.m.artins.net/tag/jbehave/
Jbehave2 Validations
http://www.testearly.com/2007/07/16/using-bdd-to-drive-development/
Mockito is your friend ( Also Jbehave's best friend )
http://code.google.com/p/mockito/wiki/FeaturesAndMotivations
http://mockito.googlecode.com/svn/branches/1.7/javadoc/org/mockito/Mockito.html
Deeper Jbehave2
http://www.ibm.com/developerworks/java/library/j-cq09187/
Deeper Jbehave2 Part-2 ( Some codes are misssing in the tutorial )
http://www.ryangreenhall.com/articles/bdd-by-example.html
Behavior Driven Database Development
http://www.methodsandtools.com/archive/archive.php?id=78
Pazartesi, Haziran 15, 2009
Demir almak günü gelmişse zamandan...
Ayrılık hep zor gelmiştir bana. Hele bir de bunu bloglamak istediğinizde işiniz daha da zorlaşıyormuş.
Fazla uzatmamaya çalışacağım. 18 aydır profesyonel olarak yaptığım Pardus geliştiriciliğini artık amatör olarak sürdüreceğim.
Yeni işime bu gün başladım ama bu başka bir yazıya kalsın. Bütün bu macera boyunca tanıdığım, hepsinin bilgilerinden vizyonundan faydalandığım tüm ekip arkadaşlarıma, en zor zamanlarda camiamızı organize edip yardıma gelen Oi ekibine ve bu süre boyunca pek çok sorunda beraber çalıştığımız bir çoğunu yalnız ismen tanıdığım camia üyelerimize her şey için çok teşekkür ederim.
Nedense kelimeler akmıyor ekrana klavyeden, en iyisi şimdilik burada kesmek.
"So long and thanks for all the fish"
Fazla uzatmamaya çalışacağım. 18 aydır profesyonel olarak yaptığım Pardus geliştiriciliğini artık amatör olarak sürdüreceğim.
Yeni işime bu gün başladım ama bu başka bir yazıya kalsın. Bütün bu macera boyunca tanıdığım, hepsinin bilgilerinden vizyonundan faydalandığım tüm ekip arkadaşlarıma, en zor zamanlarda camiamızı organize edip yardıma gelen Oi ekibine ve bu süre boyunca pek çok sorunda beraber çalıştığımız bir çoğunu yalnız ismen tanıdığım camia üyelerimize her şey için çok teşekkür ederim.
Nedense kelimeler akmıyor ekrana klavyeden, en iyisi şimdilik burada kesmek.
"So long and thanks for all the fish"
Pazartesi, Şubat 09, 2009
Test Dünyasında Neler Oluyor ( Bölüm-4 Ubuntu )
Bu serinin son bölümünü Ubuntu oluşturuyor. Şu ana kadar incelediğim dağıtımlar arasında en iyi test süreçlerine sahip olanı mıdır emin değilim ama bu konudaki en iyi dokümantasyona sahip dağıtım olduğunu söyleyebilirim.
Ubuntu QA takımına ait 2 farklı anasayfa bulunuyor [1] [2] , bunlardan ikincisi bu girdi yazıldığı tarihte henüz tam olarak aktif değildi. Alt QA takımlarına ait siteler henüz işlerlik kazanmamıştı.
Bu nokta da QA takımına biraz daha yakından bakalım. Ubuntu QA takımı aktif olarak iş yapmaktan çok QA ile ilgili iş yapan ekiplerin kordinasyonundan sorumlu. Hata ayıklamak (çözmek değil), Testler, Brainstorm arayüzü gibi değişik pek çok alandan sorumlu QA takımı.
Hata Ekibi'nin [3] yaptığı işler ayrı bir yazı konusu olabilecek kadar fazla olduğundan burada detay vermeyi düşünmüyorum. Asıl sorumluluğunu hata sınıflandırmak olarak tanımlayabileceğimiz ekip bu başlık altında hataları uygun kişilere atama, hataları birbiri ile ve upstream ile eşleştirme, Bütün hataların istenilen temel bilgileri içermesini sağlamak, hata onaylamak gibi pek çok işi yapıyor. [4] [5]
* Pardus tarafına baktığımızda gönüllü sayısının azlığından dolayı aynı kişiler ile işler yürüyecek olsa da organizasyon olarak test ve hata ayıklama işlerini birbirinden ayrıştırmak mantıklı göründü bana da.
Gelelim Ubuntu Test Takımına; Takımın ana sayfası [6] oldukça düzenli ve özet bilgileri içeriyor. Öncelikle bir TODO listeleri bulunuyor [7] yapılacak işleri özetleyen. Bunun yanında bir sonraki sürümde yapılacak işler için de ayrı bir yol haritası [8] tutuyorlar.
Güncellemelerden çok yeni çıkacak sürümün testlerine yoğunlaşmış durumdalar, 6 aylık sürüm periyotları olduğunu düşünürsek bu çok garipsenecek bir durum değil aslında. Güncelleme testlerini ayrıca inceleyeceğiz, öncelikle sürüm testlerine bakalım.
Sürüme kadar olan süreçte oldukça fazla sayıda ön sürüm çıkartıyorlar ( Örneğin bu yazı yazıldığı tarihte 4 tane Alfa sürümü mevcuttu ). Testler için ayrı bir makina veya disk ayrılmasını istiyorlar.
Testler 2 safhada gerçekleşiyor. İlki Smoke Test [9] adı verilen ara sürüm çıkmadan önceki 4-5 günlük periyotta gerçekleşen testler. Bu testlerde herbir ara sürüm için show-stopper olan sürümün temel işlevlerini test ediyorlar. [10]
Ara sürümün çıkmasının ardından ise image validation olarak adlandırılan daha geniş kapsamlı testlere geçiliyor.
Testlerin raporlanmasını Launchpad üzerinden ISO Tracker [11] adındaki bir web uygulaması ile gerçekleştiriliyor. ISO Tracker ile güncelleme yolu ile sürüm yükselten testçilerin test etmesi mümkün olmayan ISO üzerinden farklı biçimlerdeki kurulum alternatifleri test ediliyor ve hatalar raporlanıyor. Burada Launchpad in merkezi hata takip yapısının sunduğu avantajlardan faydalanılarak yeni hata girişi ve var olan hataların takibi kolaylıkla mümkün olabiliyor. Bunun yanı sıra ISO testlerindeki onay bekleyen hataları da wiki aracılığı ile listeliyorlar. [12]
Bunun dışında kalan testler için uyguladıkları metodlara ait dokümanlara ulaşamadım ancak kullandıkları test yönergelerine [13] ulaşılabiliyor. Ayrıca bu test caselerin neleri kapsadığını görebilmekte güzel. [14] Bu noktada son olarak dikkatimi çeken bölüm eklenecek olan yeni özelliklere ilişkin herşey ( uygulamasından testine kadar ) wiki aracılığı ile detaylı bir biçimde paylaşılıyor. [15]
Şimdi de sürüm içi güncelleme testlerine bakalım. Bu testler konusunda oldukça hassas davranıyor Ubuntu. Her güncellemeyi almıyor kararlı sürüme [16] ( Sık sürüm çıkartmanın bir başka avantajı ) genellikle çok önemli bir hatayı çözüyor olması gerekiyor. Hatta güvenlik güncellemelerinde bile aynı seçilikle yaklaşıyor [17] kararlı sürüm güncellemelerine.
Bu süreçlerin her ikisinde de özel durumlar haricinde sürüm güncellemesi yapmıyor, sadece hatayı çözen yamayı mümkün olduğunca minimal bir şekilde backport ediyorlar.
Gelelim bizim için asıl önemli nokta olan güncelleme prosedürüne;
1- Öncelikle hatanın o anki geliştirme sürümünde düzeltildiğinden emin olunur.
2- Güncellemenin çözdüğü hata raporuna gerekli açıklama girilir. Bu açıklamada hatanın etkileri, geliştirme sürümünde nasıl çözüldüğü, hatanın nasıl tekrarlanabileceği ve yamanın yaratabileceği olası yan etkiler anlatılır. Ayrıca hatayı çözen minimal yama da eklenir. Eğer bu yamayı hazırlamak çok uzun bir süre alacaksa SRU ( Stable Release Updates ) takımından onay alınır ( anladığım kadarıyla sürüm güncellemesi için alınıyor bu onay ).
3- Paket aday olarak işaretlenir ve SRU takımına haber verilir. Yöneticiler tarafından onaylanan paket derlenir ve test edilmek için hazır hale gelir.
4- SRU onaylama takımı açık olan verification-needed etiketli hataları [18] düzenli olarak inceler ve onay veya ret kararı verir.
[1] https://wiki.ubuntu.com/QATeam
[2] http://qa.ubuntu.com/
[3] https://wiki.ubuntu.com/BugSquad
[4] https://wiki.ubuntu.com/Bugs/HowToTriage/
[5] https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[6] https://wiki.ubuntu.com/Testing
[7] https://wiki.ubuntu.com/Testing/TODO
[8] https://wiki.ubuntu.com/QATeam/RoadMap
[9] https://wiki.ubuntu.com/Testing/ISO/Schedule
[10] https://wiki.ubuntu.com/Testing/ISO/Smoke
[11] http://iso.qa.ubuntu.com/qatracker/
[12] https://wiki.ubuntu.com/Testing/FixesToVerify
[13] http://testcases.qa.ubuntu.com/
[14] http://testcases.qa.ubuntu.com/Coverage/Overview
[15] https://wiki.ubuntu.com/EncryptedPrivateDirectory
[16] https://wiki.ubuntu.com/StableReleaseUpdates#When
[17] https://wiki.ubuntu.com/SecurityUpdateProcedures
[18] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
Ubuntu QA takımına ait 2 farklı anasayfa bulunuyor [1] [2] , bunlardan ikincisi bu girdi yazıldığı tarihte henüz tam olarak aktif değildi. Alt QA takımlarına ait siteler henüz işlerlik kazanmamıştı.
Bu nokta da QA takımına biraz daha yakından bakalım. Ubuntu QA takımı aktif olarak iş yapmaktan çok QA ile ilgili iş yapan ekiplerin kordinasyonundan sorumlu. Hata ayıklamak (çözmek değil), Testler, Brainstorm arayüzü gibi değişik pek çok alandan sorumlu QA takımı.
Hata Ekibi'nin [3] yaptığı işler ayrı bir yazı konusu olabilecek kadar fazla olduğundan burada detay vermeyi düşünmüyorum. Asıl sorumluluğunu hata sınıflandırmak olarak tanımlayabileceğimiz ekip bu başlık altında hataları uygun kişilere atama, hataları birbiri ile ve upstream ile eşleştirme, Bütün hataların istenilen temel bilgileri içermesini sağlamak, hata onaylamak gibi pek çok işi yapıyor. [4] [5]
* Pardus tarafına baktığımızda gönüllü sayısının azlığından dolayı aynı kişiler ile işler yürüyecek olsa da organizasyon olarak test ve hata ayıklama işlerini birbirinden ayrıştırmak mantıklı göründü bana da.
Gelelim Ubuntu Test Takımına; Takımın ana sayfası [6] oldukça düzenli ve özet bilgileri içeriyor. Öncelikle bir TODO listeleri bulunuyor [7] yapılacak işleri özetleyen. Bunun yanında bir sonraki sürümde yapılacak işler için de ayrı bir yol haritası [8] tutuyorlar.
Güncellemelerden çok yeni çıkacak sürümün testlerine yoğunlaşmış durumdalar, 6 aylık sürüm periyotları olduğunu düşünürsek bu çok garipsenecek bir durum değil aslında. Güncelleme testlerini ayrıca inceleyeceğiz, öncelikle sürüm testlerine bakalım.
Sürüme kadar olan süreçte oldukça fazla sayıda ön sürüm çıkartıyorlar ( Örneğin bu yazı yazıldığı tarihte 4 tane Alfa sürümü mevcuttu ). Testler için ayrı bir makina veya disk ayrılmasını istiyorlar.
Testler 2 safhada gerçekleşiyor. İlki Smoke Test [9] adı verilen ara sürüm çıkmadan önceki 4-5 günlük periyotta gerçekleşen testler. Bu testlerde herbir ara sürüm için show-stopper olan sürümün temel işlevlerini test ediyorlar. [10]
Ara sürümün çıkmasının ardından ise image validation olarak adlandırılan daha geniş kapsamlı testlere geçiliyor.
Testlerin raporlanmasını Launchpad üzerinden ISO Tracker [11] adındaki bir web uygulaması ile gerçekleştiriliyor. ISO Tracker ile güncelleme yolu ile sürüm yükselten testçilerin test etmesi mümkün olmayan ISO üzerinden farklı biçimlerdeki kurulum alternatifleri test ediliyor ve hatalar raporlanıyor. Burada Launchpad in merkezi hata takip yapısının sunduğu avantajlardan faydalanılarak yeni hata girişi ve var olan hataların takibi kolaylıkla mümkün olabiliyor. Bunun yanı sıra ISO testlerindeki onay bekleyen hataları da wiki aracılığı ile listeliyorlar. [12]
Bunun dışında kalan testler için uyguladıkları metodlara ait dokümanlara ulaşamadım ancak kullandıkları test yönergelerine [13] ulaşılabiliyor. Ayrıca bu test caselerin neleri kapsadığını görebilmekte güzel. [14] Bu noktada son olarak dikkatimi çeken bölüm eklenecek olan yeni özelliklere ilişkin herşey ( uygulamasından testine kadar ) wiki aracılığı ile detaylı bir biçimde paylaşılıyor. [15]
Şimdi de sürüm içi güncelleme testlerine bakalım. Bu testler konusunda oldukça hassas davranıyor Ubuntu. Her güncellemeyi almıyor kararlı sürüme [16] ( Sık sürüm çıkartmanın bir başka avantajı ) genellikle çok önemli bir hatayı çözüyor olması gerekiyor. Hatta güvenlik güncellemelerinde bile aynı seçilikle yaklaşıyor [17] kararlı sürüm güncellemelerine.
Bu süreçlerin her ikisinde de özel durumlar haricinde sürüm güncellemesi yapmıyor, sadece hatayı çözen yamayı mümkün olduğunca minimal bir şekilde backport ediyorlar.
Gelelim bizim için asıl önemli nokta olan güncelleme prosedürüne;
1- Öncelikle hatanın o anki geliştirme sürümünde düzeltildiğinden emin olunur.
2- Güncellemenin çözdüğü hata raporuna gerekli açıklama girilir. Bu açıklamada hatanın etkileri, geliştirme sürümünde nasıl çözüldüğü, hatanın nasıl tekrarlanabileceği ve yamanın yaratabileceği olası yan etkiler anlatılır. Ayrıca hatayı çözen minimal yama da eklenir. Eğer bu yamayı hazırlamak çok uzun bir süre alacaksa SRU ( Stable Release Updates ) takımından onay alınır ( anladığım kadarıyla sürüm güncellemesi için alınıyor bu onay ).
3- Paket aday olarak işaretlenir ve SRU takımına haber verilir. Yöneticiler tarafından onaylanan paket derlenir ve test edilmek için hazır hale gelir.
4- SRU onaylama takımı açık olan verification-needed etiketli hataları [18] düzenli olarak inceler ve onay veya ret kararı verir.
[1] https://wiki.ubuntu.com/QATeam
[2] http://qa.ubuntu.com/
[3] https://wiki.ubuntu.com/BugSquad
[4] https://wiki.ubuntu.com/Bugs/HowToTriage/
[5] https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[6] https://wiki.ubuntu.com/Testing
[7] https://wiki.ubuntu.com/Testing/TODO
[8] https://wiki.ubuntu.com/QATeam/RoadMap
[9] https://wiki.ubuntu.com/Testing/ISO/Schedule
[10] https://wiki.ubuntu.com/Testing/ISO/Smoke
[11] http://iso.qa.ubuntu.com/qatracker/
[12] https://wiki.ubuntu.com/Testing/FixesToVerify
[13] http://testcases.qa.ubuntu.com/
[14] http://testcases.qa.ubuntu.com/Coverage/Overview
[15] https://wiki.ubuntu.com/EncryptedPrivateDirectory
[16] https://wiki.ubuntu.com/StableReleaseUpdates#When
[17] https://wiki.ubuntu.com/SecurityUpdateProcedures
[18] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
Pazartesi, Ocak 12, 2009
Test Dünyasında Neler Oluyor ( Bölüm-3 Fedora)
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/
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/
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)