QA ve Geliştiriciler

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.

31 Mart 2010

Posted In: developers, geliştiriciler, linux, qa

Ekonomik krizin açık yazılımlara etkisi

Bundan yaklaşık 16-17 ay önce özgür yazılım ve açık kaynak firmalarının ekonomik krizden nasıl etkileneceği internette tartışılan favori konulardan biriydi. Red Hat CEO’su Jim Whitehurst ve daha bir çok konuya vakıf insan “krizin açık yazılımlar için büyük bir fırsat olduğunu ve daralan bilgi teknolojisi bütçelerinin şirketleri açık yazılımlara yönelteceğini” savunuyordu. Kasım 2008 deki “Servis, Açık […]

29 Mart 2010

Posted In: Açık kaynak, akk, Gezegen, IT, linux, Özgür yazılım, red hat, servis

QA


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.

26 Mart 2010

Posted In: linux, qa, Quality Assurance, Quality control, Shewhart Cycle

Dünya ülkelerinin askeri / silah harcamaları ne kadar?

Google Dünya bankası verilerini bünyesine kattı ve bu bilgileri arama şeklinde yapıldığı zaman sunuyor. Bu bilgilere ulaşmak için: “military expenditure” yazabilirsiniz. Google türkçeden “ordu harcamaları” ve “military expenditure” diye aratmaya çalıştım ama wikipedia önde çıkıyor onun için özel verilerin ve grafiklerin gösterildiği kısıma erişmek için altta verdiğim linki kullanabilirsiniz. Verdiğim linkte ayrıca Türkiye’nin bölgesinde etkin […]

8 Mart 2010

Posted In: linux, Twitter - Kısa yazılar

Twitter Auto Publish Powered By : XYZScripts.com