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