2010-KPSS Lisans 10.07.2010 ve 11.07.2010 tarihlerinde sınavlar olacak. 10-21 Mayıs arası başvurular var. Başvuru ücretleri: 1 Otr: 35 TL, 2 Otr: 55 TL, 3 Otr: 75 TL,4 Otr: 95 TL

2010-KPDS Sonbahar Dönemi 07.11.2010 tarihinde sınav, ücreti ise 40TL.

2010-ALES Sonbahar Dönemi 28.11.2010 tarihinde sınav, ücreti ise 40TL.

Hata raporlama sürecinde hataların durumları hakkında görüş bildirmemiz gerekir bunlar ve açıklamalarını şöyle sıralayabiliriz:

Yeni(New): Yeni bir hata raporlandığı ilk ilk olarak bu etiketle durur. Herhangi birisi inceleyip hakkında yorum yapana kadar bu şekilde kalır.

Doğrulandı(Verified): Hata QA ekibi tarafından doğrulandıysa bu geliştiricilere bildirilir. Eğer projenin QA ekibi yoksa bu işle direkt olarak geliştiriciler ilgilenir.

Ertelendi(Deferred): Hata çok acil değilse ve inşa edilmekte olan sürüme yetişmeyecekse düzeltilmesi ertelenebilir. Genelde bir sonra ki yamada bu tarz hatalar düzeltilebilir. Düzeltilmesi daha uzun sürecekse bu etiketle kalır ya da daha sonra hatırlatma(remind) ya da sonra(later) gibi etkiketler alır.

Atandı(Assigned): Proje lideri hatanın düzeltilmesi için belli bir geliştiriciye atama yaptığında bu etiket kullanılır.

Çözüldü(Fixed): Geliştirici hatayı çözdüğünü bu şekilde bildirir. QA ekibi teste başlar.

Hata Tekrarı(Duplicate): Eğer daha önce girilmiş bir hata raporu tekrarlanmışsa bu şekilde etiketlenir.

Yeniden Üretilemedi(Could not reproduce): QA ekibinin bildirdiği hata ile tekrardan karşılaşılamadıysa bu durum bildirilir. Duruma göre QA test aşamalarını kontrol eder ve hatayı tekrardan üretip geliştiriciye geri iletir.

Geri Bildirim(FeedBack): Geliştirici hatanın nasıl oluştuğu konusunda yeterince bilgilendirilmemişse bu etiketi kullanır. Hatanın oluşum süreciyle ilgili ayrıntılı bilgiler aşama aşama geliştiriciye iletilmelidir.

Yeniden Açıldı(Reopen): Hata çözüldü olarak işaretlenmiş olmasına rağmen QA ekibi sorunun varlığını tespit ederse tekrardan bildirim yapar ve düzeltilmesi için çalışmalara başlanır. QA’in işi düzeltildiği söylenen hatanın düzeltildiğinden emin olmaktır.

Geçersiz(Invalid): Hata olarak bildirilen sorun bir hata değilse geçersiz olarak işaretlenebilir. Genelde kullanıcılardan gelen eksik bilgiden kaynaklı sorunlar bu şekilde etiketlenir. Bu noktada topluluğa veya destek birimlerine pas atılır.

Kapalı(Closed): Eğer hatanın giderildiği QA ekibi tarafından onaylanırsa hata kaydı kapatılır.

QA ile Geliştirici ekibi arasında iletişim kritik öneme sahiptir. Bu iki ekibin ne yaptıkları konusunda bir birlerini sürekli haberdar etmeleri ve günlük toplantılarda bir araya gelmeleri test süreçlerinin ve hata takibinin verimli bir şekilde ilerlemesine büyük katkı sağladığı bir gerçektir. Her iki ekibinden bir birlerinden beklediği bazı şeyler vardır. Bunları nerede dile getirecekleri ve nasıl iletecekleri de ayrı bir sorundur. Klasik hata takip sistemlerinin yanında anlık düzenlemelerinde yapılabilmesi için farklı iletişim kanalları kullanılmalıdır. İletişim bu gibi konularda anahtar kelimedir.

QA ekibinin geliştiricilerden beklentisi başlangıçta ürünün ne olduğunu öğrenmektir. Eğer ürünün fikrinin ortaya çıkışından itibaren QA ekibini işin içine katıp SCRUM yönteminde ki gibi esnek bir gelişim süreci işlerseniz buna gerek olmayabilir ama hazır bir ürünü belli bir aşama kat ettikten sonra test edecekseniz ürünün ne olduğunu ve müşteriye nasıl sunulması gerektiğini QA ekibine anlatmanız gerekir. Aksi takdirde neyin doğru neyin yanlış olduğunun kararını vermek için QA ekibi tekrardan size dönmek zorunda kalır. Kullanıcılar tarafından ürünün özelliği sanılan bir konu geliştiriciler açısında bir hata olarak kabul edilebilir. Bu gibi sorunlarla karşılaşmamak için kontrol süreçlerine başlamadan önce ürün hakkında ayrıntılı bilgi QA ekibine verilmelidir.

QA için yararlı olabilecek bir diğer hususta olası hatalar konusunda geliştiricilerin görüşleridir. Karmaşık sistemlerde hatalara daha sık rastlanılır ve geliştiriciler daha programlama aşamasında nerelerde sorun olabileceği tahmin edebilirler, bunların önceden bildirilmesi QA ekibinin bu konulara yoğunlaşıp bu alanları iyice incelemesine olanak sağlar. Eğer bir hata bulunmazsa geliştiricilerin hata çıkma korkusuda giderilmiş olur.

Bir hata bulunduğunda bunun raporlanmasının ardından hızlı bir şekilde cevap verilmesi ve giderilme aşamalarının ne durumda olduğunun da QA ekibine bildirilmesi gerekir. Bir hata giderildiyse öncelikle bu bildirilmeli, düzeltiliyorsa ne kadar sürede düzeltilecek, geliştiriciler ne aşamadalar bunların hepsi bildirilmeli.

Benzer şekilde ürün üzerinde bir değişiklik yapılacağı zamanda QA ekibine anında haber verilmelidir. QA ekibinden habersiz bir değişiklik yapılması “bu değişiklik önemsiz ya da ufak görülse dahi” kritik hatalara yol açabilir. Ummadık taş baş yarar sözü kulağa küpe olmalı ve yapılan her değişiklik QA ekibine bildirilmelidir. Karmaşık ürünlerin gelişim sürecinde ufak değişikliklerin olmaması gereken alakasız hatalara yol açabileceği unutulmamalıdır. Gelecek olan güncellemeler, değişiklik notları, güncelleme takvimleri QA ekibine ivedilikle iletilmelidir. Bu şekilde ekipte kendini bu değişikliklere göre ayarlar ve zamanı geldiğinde uygun testleri yapabilir.

QA, Quality Assurance departmanı ürünün toplam kalitesinin ve müşteriye uygunluğunun arttırılmasıyla ilgilenir. QA Ürün veya hizmetlerin düzenli olarak farklı açılardan gözetlenmesini yapar ve kalitenin arttırılması için çalışır. QA ekibi bulunan hataların raporlanması ve düzeltilmesinin takibini yapar. Görevlerin yapılıp yapılmadığını kontrol eder. Bu süreçlerin uygulanmasında gerekli uygulamaları(yazılım) kullanırlar veya bizzat kendileri geliştirilmesi için çalışırlar. Acil durumlarda ürün veya hizmete müdahele ederek bakıma alınmasını sağlayabilirler.

Kullanıcı beklentilerini ölçmekte QA’in görevleri arasındadır. Çünkü beklentileri bilmeden bu beklentileri karşılamak için neler yapılması gerektiği bilinemez. Kaliteye ulaşılmasında en sık kullanılan yöntemlerden birisi Shewhart Cycle’dır. İkinci dünya savaşı sonrası dönemde Dr. W. Edwards Deming tarafından geliştirilen bu yöntem 4 aşamadan oluşur:

Plan – Amaçlanan hedefe ulaşmada gerekenlerin ve uygulanacak yöntemlerin belirlenmesi,
Hareket – Belirlenen süreçlerin uygulamaya konulması,
Kontrol – Uygulanan süreçlerin takip edilerek analizinin yapılması,
Eylem – İstenilenlere ulaşılmamışsa gerekli değişikliklerin yapılması.

QA bu süreçler boyunca çeşitli bilgilerden ve geri dönüşlerden faydalanmak zorundadır. Elde edilecek ürün için gerekli iş ve malzemelerden ürünün üretilmesinin ardından gelen kullanıcı şikayetlerine kadar bir çok veri değerlendirilmek zorundadır.

Yazacak bir şey bulamayınca etrafına bak. İnsanları, dünyayı seyret, onlar senden rahatsız olsun, izlendiklerini bilsin, bir tarafları kalksın ama izlemeye devam et. Sadece güzel şeylere değil, çirkinliklere de bakmayı bil. Hislerini aç, gözlemleme, tecrübe etme sadece gözlerle olmaz. Bilmediğin şeyleri dene, hisset. İnsanları dinle, her yerde kulakların açık olsun. Acı nedir bil, üzüntü nedir öğren. Bilmediğin bir şeyi yazamazsın. Bilmiyorum diye insanları kandırmaya çalışabilirsin ama kendini kandıramazsın. Bildiğini ve yazman gerektiğini sende biliyorsun. Hatta bunun bir görev olduğunun farkındasın. Yazacak bir şeyler bulamazsan oturup yazmaya başlamamışsın demektir. Yazmaya başlamalısın, yazmalısın, çünkü ancak o zaman devamı gelir. Sökük iplik gibi yazılar parmaklarının arasından akıp gider ta ki geride senden bir şey kalmayana dek.

WordPress kullananlar bilir otomatik güncelleştirme gibi güzel bir özelliği vardır.

Blog’a eskisi gibi vakit ayıramıyorum, farkındayım. Bu hem iyi hem kötü bir şey. İyi çünkü boşta değilim ki vakit bulamıyorum, çalışıyorum; kötü çünkü vakit bulamasam da yazmak istediğim çok şey var ve bunları yazamamak beni rahatsız ediyor. Arada sırada elimden geldiğince bir şeyler yapmaya çalışıyorum ama bunlara çok az vakit ayırabiliyorum. İşim İstanbul da olduğu için ömrüm yolda geçiyor. Efe Tur beni şaşırtmamaya devam ediyor, geç gelen seferler, dönüşte sorunlar… Gidişim o kadar kısa sürüyor ki bazen akşam eve dönmeye çalışırken 3 saatim yolda heba olunca hafif kızıyorum. Ama hafif… ya da ufak, mini minnacık. Ne de olsa bu dünya da hiç bir şey kızmaya değmez değil mi? Değmez…

2008 Yılının Mayıs ayında Linux.Com yeni sitesini yayına sokmuştu. Sitenin yayına girmesiyle birlikte yeni özelliklerinden biri olan gruplar bölümüne Pardus Linux User Group adı altında bir grup kurmuştuk. Amacı yabancı kullanıcılara Pardus’u duyurmak olan bu grup bugün itibariyle yüzüncü üyesiyle çok daha büyük çok daha güçlü.

Elimizden geldiğince Pardus’un tanıtımına katkı yapmaya çalıştık. Umarım grubumuz daha da büyür ve bazı şeylere ön ayak olur. Son zamanlarda topluluk süreçlerinden oldukça uzak kalmış olsam da 100. üyemiz olan Volkan arkadaşımızın aramıza katılmasından çok mutlu oldum.