Bir Regresyon Testi Yaklaşımı Önerisi

Regresyon testi, tanımı gereği, test edilmiş ve doğrulanmış bir ürüne yeni bir özelliğin eklenmesi ve/veya var olan özelliklerdeki bir hatanın düzeltilmesi sonrasında, testten geçmiş ürünün bu değişikliklerden olumsuz etkilenmediğini doğrulamak amacıyla yapılır.

Adı geçen bu değişiklikler kullanıcı arayüzü üzerindeki kozmetik değişiklikler olabileceği gibi, bir modülün çalışma şekline müdahale eden bir değişiklik de olabilir. Dolayısıyla yapılan bu değişikliğin halihazırdaki ürünü bozmadığından emin olmak gerekir.

Bir projenin yaşamı süresince ortaya çıkabilecek bazı regresyon testi ihtiyaçlarını ve neler yapılması gerektiğini aşağıdaki şemada örneklendirdim:

Peki nasıl bir test yaklaşımı ile regresyon testlerini planlamak gerekir?

Geliştirilen ürünün yapısına bağlı olarak farklı yaklaşımlar ortaya çıkacaktır. Ancak genel bir yaklaşım olarak şöyle bir yöntem izlenebilir (burada verilen yaklaşımlar örnektir, kendi proje ihtiyaçlarınıza göre çeşitlendirebilirsiniz):

Kozmetik Değişiklik
	Ne Yapıldı?
		Yazım Hatası Düzeltildi
		Resim, İkon, Konum Değiştirildi
		Font Değiştirildi
	Nasıl Doğrulanacak?
		Ürünü farklı platformlarda çalıştır (İşletim sistemi, internet gezgini, mobil cihaz)
		Yapılan değişikliğin istendiği gibi göründüğünü doğrula
		Yapılan değişikliğin aynı kullanıcı arayüzündeki diğer nesneleri bozmadığını doğrula
Yetenek Üzerinde Değişiklik
	Ne Yapıldı?
		Kullanıcı Arayüzünde Bir Nesne Silindi / Eklendi
		Modüller Arası Arayüze Yeni Yetenek Eklendi / Varolan Silindi
		Bir sınıfın çalışma mantığı değiştirildi
		Veritabanı sorguları değiştirildi
		Rapor şablonu değiştirildi
		Kullanılan donanımlar değiştirildi
		...
	Nasıl Doğrulanacak?
		Kullanıcı arayüzünü test et, istenen sonuçta olduğunu doğrula
		Kullanıcı arayüzünü çağıran diğer arayüzleri test et, istenen sonuçta olduğunu doğrula
		Arayüzü kullanan modülleri test ederek, iletişimde bulunan modüllerin istenen girdi ve çıktıları sağladığını doğrula
		Değişiklik yapılan sınıfı birim test ile doğrula, bu sınıfı kullanan diğer sınıfları birim entegrasyon testi ile doğrula
		Veritabanına atılan sorguyu gözden geçir
		Ekran arayüzü üzerinden test yaparak veritabanına atılan sorguda doğru parametrelerin kullanıldığını doğrula
		Farklı sayıda girdiler kullanarak farklı sayıda sayfa içeren raporlar üret, içeriğin istenen sonuçları içerdiğini doğrula
		Donanıma özel olarak geliştirilmiş yeteneklerin olması durumunda, ilgili yeteneğin testlerini baştan sona tekrarla
Yaklaşım
		Test mühendisi, deneyimine dayanarak hangi yeteneklerin etkilenmiş olabileceğinin listesini hazırlar, liste üzerinden tüm ilgili yetenekleri test eder,
		Proje ekibi (en az 1 yazılılm mühendisi ve 1 test mühendisi), tasarım ve kod üzerinden etkilenmiş olabilecek yeteneklerin listesini çıkarır, birim seviyesi ve üst seviye testler tekrar edilir,
		Test otomasyonu varsa, değişiklikten etkilenen testler güncellenir ve (tercihen, zaman varsa tüm) testler tekrarlanır

Test Ortamının Kurulumunu Kim Yapmalı ve Nelere Dikkat Edilmeli

Eğer şirket bünyesinde test ortamı kurulumlarını yapmak için bağımsız bir ekip yoksa, ortam kurulumlarını kimin yapması gerektiği ile ilgili tartışmalar yaşanmaktadır.

Benim görüşüm, bu işi kesinlikle test mühendislerinin yapması. Çünkü, nasıl ki geliştirilen uygulama bağımsız bir test mühendisi tarafından doğrulanmaktadır, geliştirilen doküman da bağımsız bir kişi tarafından doğrulanmalıdır. Nihayetinde, ortam kurulumu da bir doküman kullanılarak yapıldığına göre, dokümanda yazılanlar uygulandığında test ortamına kurulan ürünün teste hazır olduğunu doğrulamak gerekmektedir.

(Doküman ile kastedilen sadece Word belgesi değildir; bir veritabanı betiği, kurulum sihirbazı uygulaması, işletim sistemi betikleri, ... de birer dokümandır.)

Kurulum öncesinde ve esnasında dikkat edilmesi gerekenler;

• Kurulum yapılacak ortamın "temiz" olması; ilgili donanımlar üzerinde önceki kurulumlardan kalan herhangi bir ürün olmaması. Bunu gerçekleştirmenin en kolay yolu, donanımlara işletim sistemi kurulduktan sonra sabit disklerin birer imajını alarak her kurulum öncesinde bu imajın sabit disklere geri yüklenmesidir.
• Kurulum ortamında kullanılacak doküman ve yazılımların konfigürasyon yönetim aracı üzerinden alınması. 
• Kurulumu yapılacak ürünlerin doğru versiyonlarının kurulduğundan emin olunması.
• Kurulum dokümanında yazılan kurulum adımları uygulanırken her bir adımın anlaşılır (diğer kişiler tarafından da anlaşılır) bir şekilde yazıldığının doğrulanması.
• Kurulum adımı gerçekleştirilirken İşlem'in tam olarak yapılabildiği ve Beklenen Sonuç'un gözlemlenebildiği görülmeli, aksi durumlar anlaşılır bir şekilde (doküman üzerine) not edilmelidir.
• Kesinlikle herhangi bir adımın atlanmaması.
• Kurulum sonrasında "duman testi" uygulayarak kurulumu yapılan uygulamaların çalışır olduğunun görülmesi.

Test Verisi Havuzu Oluşturmanın Faydaları ve Nelere Dikkat Edilmeli

Test verisi havuzu oluşturmak en az iki açıdan faydalıdır:

• Testleri hazırlarken farklı test sınıflarına yönelik test durumları oluşturmak,
• Testleri gerçekleştirirken uygun test verisi bulma zamanından tasarruf etmek.

Aşağıda farklı test sınıflarına yönelik olarak test verisi türlerini listeledim. Test altındaki uygulamanın arayüzlerindeki veri ihtiyacına göre bu liste genişletilebilir.

• Normal Girdi
• Metin, resim, ses, video ve diğer tür dosyaların çalışır durumdaki kopyaları.
• Dosyaların bozuk olmadığından emin olunmalı, böylece, test altındaki uygulamaya bu dosyalar yüklendikten sonra uygulama üzerinden tekrar erişildiğinde dosyanın halen çalışır durumda olduğu görülebilmeli. 

• Hatalı Girdi
• Dosya uzantıları bilinçli olarak değiştirilerek test altındaki uygulamaya yüklenir.
• Dosya uzantısına karşı hassas olan uygulamalara sadece doğru uzantılı dosyaların yüklenebildiği doğrulanabilir.
• Bozuk Dosyalar
• Dosya içeriği bilinçli olarak bozulur.
• Dosya içeriğine karşı hassas olan uygulamalara sadece çalışır durumdaki dosyaların yüklenebildiği doğrulanabilir.

• Sıfır Boyutlu Dosyalar
• Uzantısı geçerli ama içeriği olmayan sıfır boyutlu dosyalar oluşturularak test altındaki uygulamaya yüklenir.
• Uygulamanın böyle bir dosya yüklendiğinde herhangi bir hataya neden olmadığı doğrulanabilir.

• Büyük Boyutlu Dosyalar
• Uygulamanın dosya yükleme sınırları içinde olmak üzere, (uygulamanın ihtiyacına göre) 10, 50, 100, 500 MB'lık dosyalar hazırlanır.
• Farklı dosya formatları için birkaç adet dosya hazırlamak iyi olacaktır.
• Uygulamaya bu dosyaların sorunsuz olarak yüklenebildiği doğrulanabilir.

• Çok Büyük Boyutlu Dosyalar
• Bu tür dosyaları kullanmanın amacı, uygulamanın tasarım sınırlarının üzerinde büyük boyutlu dosyalar yüklendiğinde, uygulamanın nasıl davrandığını test etmektir.
• Herhangi bir dosya boyut sınırı olmayan (sadece depolama ortamının boyutu ile sınırlı olan) uygulamalarda da, dosya yükleme sürelerini ölçmek, çok büyük boyutlu bir dosya yüklenirken sistemin nasıl davrandığını gözlemlemek, birkaç farklı kullanıcı eşanlı olarak bu dosyaları yüklediğinde ne olduğunu gözlemlemek, dosyalar yüklenirken uygulamanın diğer yeteneklerinin kullanılıp kullanılamadığını gözlemlemek gibi pek çok test yapılabilir.

• Dile Özel Karakterli Dosyalar
• Geliştirilen uygulamanın hedef kullanıcılarının yerel dilleri ne(karakter setlerine) uygun dosyalar hazırlanır.
• Örneğin, Arapça karakterler içeren bir metin dosyası uygulamaya yüklenip, uygulamadan geri çağrıldığında dosya içeriğindeki karakterlerin bozulup bozulmadığı doğrulanabilir.

• Şifreli Dosyalar
• Yukarıda belirtilen dosya türleri şifreleme yeteneği olan bir araç (7-Zip gibi) kullanılarak şifrelenir.
• Uygulamaya yüklenen bu dosyalar, uygulamadan geri çağrılıp ilgili şifre girilerek açıldığında şifrenin herhangi bir sebeple bozulmadığı doğrulanabilir.

Sözleşme Aşamasında Test İhtiyaçlarının Belirlenmesi

Yazılım projelerine teklif veren şirketlerin, ihalenin kazanılması durumunda, ne tür test (doğrulama) faaliyetlerini gerçekleştireceklerini bilmeleri, bu faaliyetlerin iş gücü ihtiyaçlarını ve maliyetlerini tahmin edebilmeleri açısından önemli olmaktadır. Bu faaliyetleri bilmek, geliştirme ve kabul aşamalarında ortaya çıkabilecek risklerin de önceden görülebilmesi açısından ayrıca önemlidir. (Bakınız: Test Mühendisliğinde Olası Riskler )

Verilecek teklifin doğru maliyetlendirilebilmesi ve ileride yaşanabilecek sorunları öngörmek amacıyla teklife verilecek cevabın deneyimli bir ekip tarafından hazırlanması gerekmektedir. Bu ekipte test mühendislerinin de olması, aşağıda verilen başlıklardaki konularda test mühendislerinin girdilerini almak açısından gereklidir.

• Ne Tür Doğrulama İhtiyaçları Bulunmaktadır,
• Burada temel olarak hangi türde testlerin yapılmasının beklendiği belirlenir. Fonksiyonel, (Dış Sistemlerle) Entegrasyon, Performans (Yük / Stres), Güvenlik, Güvenilirlik, Uygunluk, Platform Bağımsızlık, Uyumluluk, Erişebilirlik, gibi. 
• Ne tür testlere ihtiyaç duyulacağının bilinmesi personel, uzmanlık, araç / gereç, süre gibi ihtiyaçların tahminine temel teşkil edecektir.

• Hangi Sahalarda Doğrulama İhtiyacı Vardır,
• Sadece yüklenici ortamında yapılan bir doğrulama çoğunlukla yeterli olmaz. 
• Yüklenici ortamında dahili ve fabrika kabul testlerinden sonra, müşterinin ortamında da en az bir seviye doğrulama faaliyetinin olması beklenir.
• Buna ek olarak müşterinin ön kabul, ara kabul, nihai kabul gibi farklı kabul aşamaları da olacak mı, kaç farklı sahada / ortamda / platformda (hava, kara, deniz araçları) doğrulama faaliyeti olacak, sorularına yanıt bulunması gerekmektedir.

• Ne Tür Donanımlar / Yazılımlar Üzerinde Doğrulama Yapılması Gerekmektedir,
• Nihai kullanıcı ortamına en yakın test ortamının kurulabilmesi, ilerde yaşanacak donanım / yazılım uyumsuzluklarını asgariye indirecektir.
• Bu amaçla (belirlenebildiği kadar) ne tür ve kaç adet sunucu, istemci, ağ donanımları (yük dengeliyici, router / switch, ...) ve mobil cihazlara ihtiyaç duyulacağı belirlenmeli. Ayrıca, bu donanımları müşterinin mi sağlayacağı yoksa şirketin kendisinin mi sağlayacağı belirlenmeli.
• Hangi tür işletim sistemleri, internet gezginleri, ofis araçları ve diğer 3.taraf yazılımlarına ihtiyaç duyulacağı belirlenmeli.
• Belirlenen donanım ve yazılımların satın alma mı yoksa kiralama yoluyla mı kullanılacağının belirlenmesi de faydalıdır.

• Ne Tür Uzmanlık Alanlarına İhtiyaç Vardır,
• Doğrulaması yapılacak ürün / sistem için ne tür uzmanlık alanlarına ihtiyaç vardır?
• Bir ürünü / sistemi doğrulayabilmek için o konuyu iyi bilmek gerekmektedir. Doğrulamayı yapacak personelin bu yetkinliği var mıdır, yoksa bu yetkinliği ne kadar sürede kazanabilirler?

• Ne Tür Test Araçlarına İhtiyaç Duyulması Beklenmektedir,
• Yapılması beklenen doğrulama faaliyetleri belirlendikten sonra, bu faaliyetlerde kullanılması muhtemel test araçlarının da belirlenmesi faydalı olacaktır.
• Fonksiyonel test araçları (Ranorex, Selenium, SoapUI, QTP, gibi), performans test araçları (LoadRunner, Jmeter, ....), güvenlik test araçları (OWASP, ...) gibi araçların kullanılma ihtiyacı varsa, bu araçları kullanmayı bilen deneyimli personel var mı, yoksa yetiştirmek ne kadar zaman alır? Dış kaynak kullanımı mümkün mü?
• Araçların tahmini maliyeti ne kadar olur?

• Kaç Kişilik Doğrulama Ekibine İhtiyaç Duyulması Beklenmekte,
• Kaç türde ve seviyede, kaç sahada, ne tür araçlar kullanılarak doğrulama faaliyetlerinin yapılacağı belirlendikten sonra hangi yetkinlikte ve deneyim seviyesinde personele ihtiyaç duyulacağı da belirlenmelidir. 

TestRail İncelemesi

TestRail bir test yönetim aracıdır.

Ürünün Web Sitesi: TestRail

Deneme Sürümü (Ücretsiz Üyelik): https://secure.gurock.com/customers/testrail/trial/

Kullanım Kitapçığı: http://docs.gurock.com/testrail-userguide/start

Öne çıkan özellikleri; web üzerinden erişilebiliyor olması, içerdiği alanların konfigüre edilebiliyor olması (yeni alanlar eklenebilmesi) ve hata takip araçları ile entegre olabilmesi.

Özellikle yöneticilerin / liderlerin testlerin ilerleyişini takip edebilmeleri için faydalı. Ayrıca test geliştiricilerinin de düzenli ve hızlı şekilde test oluşturmalarına imkan sağlıyor.

Ben deneme sürümünü kullanma fırsatı yakalayabildim, burada yazdığım değerlendirme de bu deneme sürümüne yönelik.

Diğer test yönetim araçları ile arasında bir karşılaştırma yapmadım bu değerlendirmede.

Sonda söyleyeceğimi başta söyleyim:

TestRail, kullanımı ve yönetimi gayet kolay bir araç. Benim, aracın büyük çoğunluğuna hâkim olmam yaklaşık 2 saatimi aldı.

Kullanmaya başlamadan önce ilk olarak "Administration" sekmesinin içeriğini detaylıca kontrol etmekte fayda var, çünkü olmadığını düşündüğüm pek çok özelliğin aslında var olduğunu "Customizations" alt-sekmesinde gördüm.

Kurumunuzun ihtiyaçlarına yönelik olarak test durumlarının içerdiği alanları özelleştirmekten tutun, piyasada yaygın olarak kullanılan hata takip araçlarına entegrasyona kadar pek çok yetenek dahil edilmiş.

Ben sanırım 2 sene önceki bir sürümünü kullanmıştım, pek hoşuma gitmemişti. Fakat şu anki hali gerçekten şaşırttı beni. Gereksinim izlenebilirlik aracı ile entegrasyon da olduğu söylenmiş ama onu deneyemedim.

Bu aracı şirket içinde yaygınlaştırma kararı vermek isteyenlerin, şirketin ilerde ortaya çıkabilecek ihtiyaçlarını da düşünerek gereksinim yönetim araçları ile entegrasyon, raporlama yetenekleri, TestRail'da yazılan testlerin diğer bir uygulamaya aktarılması gibi yetenekleri de sorgulaması faydalı olacaktır.

Olumsuz Tarafları:

• Test adımları içine tablo ekleme biraz karışık olmuş.
• Test durumları içine yeni alanlar eklenebiliyor fakat bu eklenen alan üzerinden rapor alabilme yeteneği (gördüğüm kadarıyla) yok. Örneğin test durumu içine "İlgili Ekran" şeklinde bir alan eklenirse, rapor olarak ' "İlgili Alan" alanı boş olan test durumlarını raporla' veya '"Giriş Sayfası" ekranını test eden test durumlarını listele" şeklinde bir rapor alamadım.
• Oluşturulan testlerin hepsinin nihai hali olduğunu düşünmüşler sanırım. Bir testin henüz geliştirilmesi devam ediyorsa, durumunun taslak olarak belirtilmesi gibi bir yetenek yok. Evet, "Test Runs" oluşturulurken test durumları seçilebiliyor ancak binlerce test durumunun olduğu bir projede, bir test durumu eklerken öncesinde bir süzme yapmak gerekiyor. Süzgeç koymuşlar fakat "Test Case Status" gibi bir alan olmadığından henüz geliştirilmesi bitmemiş bir test durumunu da "Test Runs" içine yanlışlıkla dahil edebiliriz.
• "Overview" sekmesinde, projenin / ürünün kaç tane test olması gerekiyordu, bunların %de kaçını yazdık, test geliştirme açısından ne kadar gerideyiz, gibi sorulara bir cevap veren bir mekanizma göremedim.
• Proje planlama araçları ile bir entegrasyon (gördüğüm kadarıyla) yok.

Olumlu Tarafları:

• En başta, testlerin yazımı ve test koşularının genel durumunu göstermesi açısından faydalı bir ürün. Pek çok firmanın ihtiyacını karşılar nitelikte.

• "Todo" Sekmesi
• "Todo" sekmesinde bir kişinin veya tüm ekibin yapması gereken test koşularının listesi verilmiş.
• Test koşularının sonuçlarına (Passed, Failed, Untested, Blocked, Retest) göre filtreleme yapmak da mümkün.

• "Milestones" Sekmesi
• "Milestones" sekmesinde projenin iterasyonlarına ait bilgiler giriliyor ve bu iterasyonlara testler dahil ediliyor.

• "Test Cases" Sekmesi:
• Test durumları yazılırken test adımlarının hepsi bir alanda, beklenen sonuç(lar) da bir alanda olacak şekilde yazabiliyorsunuz. Ayrıca, standartlarda beklenen "Adım - Beklenen Sonuç" ikilisi şeklinde de test adımları yazılabiliyor.
• Test adımları içine "PrintScreen - CTRL+V" tuş kombinasyoları ile ekran görüntülerini eklemek mümkün. Ayrıca bu ekran görüntüleri hem adım hem de beklenen sonuç alanlarına eklenebiliyor.
• Yine test durumu içine, ekranın sağındaki alandan herhangi bir türde dosya eklemek mümkün.
• Yine "Test Cases" sekmesinde bir test durumunun detayları, hangi test koşularının içinde olduğu, hangi hataların açıldığı ve test durumu üzerinde daha önce yapılan değişikliklerin tarihçesi de görülebiliyor; gayet güzel.
• "Print" düğmesine tıklanarak istenen test durumlarının PDF çıktısı alınabiliyor.

• "Test Runs" Sekmesi
• "Test Runs" sekmesinde bir test koşusunda hangi testlerin koşacağı planlanıyor. Bu test koşuları, bir "Test Plan"a dahil edilebiliyor, test planının konfigürasyonu (hangi işletim sistemleri, web gezginleri, donanım tipleri, gibi) ayarlanabiliyor. Güzel bir özellik. Böylece, test koşularının her bir test konfigürasyonunda tekrar edilebilmesi, takip edilmesi ve raporlanması da sağlanmış.
• Test planlarının görünümü Durum, Aktivite, İlerleme ve Hatalar'a göre ayarlanabiliyor, böylece testin ilerleyişine farklı açılardan bakmak mümkün oluyor.
• Test planlarının raporları farklı ihtiyaçlara göre oluşturulabiliyor. Öyle sanıyorum ki deneme sürümündeki bu rapor sayısı, ücretli TestRail sürümünde çok daha fazladır.

• "Reports" Sekmesi
• Bir rapor oluşturulurken ("Reports" sekmesi) hangi tür testler veya hangi test durumları dahil edilecek, hangi test koşularının / test planlarının sonuçları raporlanacak, rapora kimler erişebilir, bu rapor ne zaman ve hangi periyotlarda üretilecek, rapor üretilince kimlere e-posta gönderilsin gibi gayet güzel özellikler içeriyor.
• Deneme sürümündeki kullanılabilecek rapor şablonları şöyle:

• "Administration" Sekmesi
• Bu sekme, TestRail'ın yönetimi için kullanılıyor. Aşağıda görülen alanlarda ayarlamalar yapılabiliyor.

Test Mühendisliğinde Olası Riskler ve Alınabilecek Tedbirler

Bir proje / ürün geliştirmesi sürecinde test mühendisliği açısından pek çok risk bulunmaktadır. Aşağıdaki resimde örnek bir risk listesi bulunmaktadır:

Bu liste, proje / ürün bazında daha da detaylandırılabilir.

Test faaliyetlerinden sorumlu lider mühendisin, bu tarz bir risk yönetimi yapmasının faydası, ilerde ortaya çıkabilecek sorunlara karşı önceden hazırlık yaparak (proaktif bir yaklaşım ile) süreci yönetmesidir. Bu risklerin bazısı ürün yaşam döngüsü (SDLC) boyunca hiç gerçekleşmeyebilir de, ancak hazırlıklı olmak her zaman faydalıdır.

Aşağıdaki listeye isteğe bağlı olarak Olasılık ve Etki (Önem) sütunları da eklenebilir. "Risk yönetimi nedir, nasıl yapılır" diye daha detay bilgi arayanlar "IEEE-STD-1540-2001-Risk management" standardına bakabilirler.

Ana Başlık	Risk	Alınabilecek Eylem
Değişiklik Alanları
	Gereksinimlerde / Arayüzlerde Değişiklik	- Değişiklik ihtiyacının müşteri (iç müşteri) ile koordine edilmesi, - Değişiklikten etkilenecek alt ürünlerin (tasarım maddesi, ekran, doküman, testlerin) belirlenmesi, - Değişikliğin tüm alt ürünlere uygulanması ve gözden geçirilmesi, - Değişiklikten etkilenen testlerin ve entegrasyon testlerinin yeniden koşturulması.
	Testten Geçmiş Modüllerde Kod Değişikliği	(Hata düzeltme veya gereksinim / arayüz değişiklikleri olması durumunda) - Kod değişikliğinin etkilediği fonksiyonların belirlenmesi, - Bu fonksiyonları doğrulayan testlerin belirlenmesi, - Testlerin tekrar koşturulması
Test Ortamı Altyapısı
	Kurulum Hataları	- Kurulum dokümanı / ürünündeki hatanın tespiti, - Kurulumun tekrarlanması, - İlgili testlerin tekrar koşturulması. - Kullanılan kütüphane ve ek uygulamaların versiyonlarının doğru olmasının sağlanması için bu ürünlerin sadece proje kütüphanesinden alınması (bu kütüphane konfigürasyon yönetim uzmanı kontrolünde olmalı).
	Donanım Bozulmaları	- Bellek, sabit disk gibi OEM parçaların bozulma ihtimaline karşı risk bütçesi belirlenmesi, - Tedarik sürelerinin göz önüne alınarak test planlamasının yapılması.
	Son Kullanıcı Ortamı ile Farklılık	- Son kullanıcı / müşteri ortamının detaylı olarak incelenmesi, - Test ortamının müşteri ortamına göre kurulması, - Farklılık olması durumunda, farklılıklardan kaynaklanabilecek sorunlara karşı, müşteri ortamında en erken zamanda kontrollerin yapılması.
	Yetersiz Donanım Sayısı	- Test mühendislerinin ihtiyacından az donanım olması durumunda ve bu donanımın tedarik edilmesi mümkün değilse, test koşturma takviminin buna göre planlanması veya vardiya usulü çalışma, - Geliştiricilerin hata izolasyon yapabilmeleri için test ortamının bir kopyasının sanal sunuculara kopyalanması veya test ortamı kullanım zamanlarının geliştirici ihtiyaçlarına da uygun olarak planlanması.
	Test Sırasında Ortama Dışardan Müdahale Edilmesi	- Test ortamına veri / ürün aktarımının konfigürasyon yönetim uzmanı / kalite güvence uzmanı eşliğinde yapılması, - Test ortamının izole edilmesi (ağ bağlantılarının sökülmesi, gerekirse USB bellek, CD/DVD takılmasının engellenmesi)
Test Faaliyetleri
	Test Dokümantasyonunda Hatalar	- Test dokümanlarının mutlaka lider mühendis ve geliştiriciler tarafından gözden geçirilmesi.
	Test Mühendislerinin Hataları	- Testlerin tasarlanması, yazılması ve koşturulması süreçlerinin lider mühendisin yakın kontrolü altında yapılması.
	Test Mühendislerinin Yetkinliklerinin Az Olması	- Proje süresince kullanılacak ürün, standartlar ve teknikler açısından test mühendislerinin bir eksiği varsa, bunların şirket içi / dışı eğitimlerinin proje başında planlanması ve yeterli bir süre öncesinde verilmesi.
	Testlerin Bütçesini / Süresini Aşması	- Gecikmeler olabileceği düşünerek, doğrulama faaliyetine en erken aşamada (gereksinim analiz aşamasında) başlanması, - İterasyonlar bazında testlerin koşturulması, - Test planından sapma olması durumunda, fazla çalışma veya ek personel takviyesi ile gecikmenin (ileride daha fazla sapmaya neden olmasına izin vermeden) ortadan kaldırılması.
	Testlere Geç Başlanmış Olması	- Geliştirici bilgisayarında, test mühendisi tarafından testin yapılıp, kodun “commit”lenmesi öncesinde mümkün olduğu kadar çok hatanın tespit edilmesi ve düzeltilmesi, böylece hata akışı yaşam döngüsünün süresinin azaltılması. (Çeşitli sebeplerle testlere geç başlanması gerekmişse) - Teslimat tarihlerinin ötelenmesi, - Eğer öteleme imkanı yoksa, ek destek personeli ile testlerin paralel koşturulması (tabii bunun için yedek bir test ortamı olması gerekecek), - Vardiya usulü ile çalışma (bu yöntemin çok sayıda olumsuz tarafı var).
	Test - Gereksinim - Fonksiyon / Ekran İzlenebilirliğinde Eksikler	- Her bir gereksinim, tasarım maddesi, müşteri isteği, toplantı tutanacağı maddesi ve ekranların en az bir test tarafından kapsandığının periyodik olarak kontrol edilmesi.
Müşteri / Son Kullanıcı Tarafı
	Koordinasyon Eksiği	- Proje sistem mühendisi / ürün sorumlusunun müşteri temsilcileri ile haftalık koordinasyon toplantıları yapması, ilerleme ve gecikmeler hakkında erken zamanda bilgi vermesi, - Son kullanıcılar ile yakın iletişim içinde bulunarak hatalı / zor kullanılan yeteneklerin, kullanıcıda bir hassasiyet oluşmaya başlamadan ortadan kaldırılması.
	Test / Kabul İçeriğinin Eksik Aktarılmış Olması	- Her bir test / kabul aşamasında, tüm projenin kabule temel teşkil eden yeteneklerinden nelerin test edileceği kabul heyetine aktarılmalı, - Kabule girecek müşteri temsilcilerinin ürün yeteneklerin hakim olmalarının sağlanması için test öncesinde oryantasyon verilmesi.
	Kabul Ekibinin Değişmesi	- Kabul ekibinin değişmesi durumunda oryantasyonların tekrar edilmesi, - Oryantasyondan kaynaklanacak gecikmelerin teslimat süresine eklenmesi gerektiğinin müşteri ile koordine edilmesi.

Test Mühendisliği Açısından Konfigürasyon Yönetiminin Önemi

Gerek gayri-resmi (kabul öncesi) testler gerekse resmi testlerde test edilen ürünün versiyon bilgisinin "doğru" olması hayatı önem taşımaktadır.

Burada "doğru" tanımını biraz detaylandırmak gerekirse;

• Yazılımın oluşturma (build) süreci sonrasında her seferinde tekil (daha önce kullanılmamış) bir değeri olmalı,
• Bu değer her seferinde ardışık olarak artmalı; 1.0, 1.1, 1.2, gibi.

Yazılım şirketlerindeki konfigürasyon yönetimi uzmanları, yazdıkları Konfigürasyon Yönetim Planı (KYP) içerisinde hangi ürünün versiyonlamasının hangi yöntem ile yapılacağını detaylı olarak belirtirler.

Test edilmek amacıyla konfigürasyon kütüphanesi / "build" ortamından alınan yazılımın versiyonunun "doğru" ve KYP'ye uygun olduğunun "her seferinde" kontrol edilmesi, bir test mühendisi için gerekli ve şarttır.

Çünkü hata açılan ürünün versiyonu bilinmiyorsa / yoksa / yanlışsa, hem yazılım geliştirici hatayı tespit etmekte zorlanacaktır, hem de geriye dönük süreç denetlemelerinde (özellikle müşteri tarafındaki kalite uzmanlarının yaptığı denetlemelerde) sorunlar çıkacaktır (testlerin tekrar edilebilirliği konusunda).

Örneğin müşteriden şöyle bir istek gelmesi durumunda, daha önceden versiyon belirterek açtığımız hataları, yine aynı versiyonlu üründe tekrar edebiliyor olmamız gerekiyor:

"3.0 versiyonlu uygulamayı konfigürasyon kütüphanesinden indirin, temiz bir ortama kurun, testleri baştan sonra tekrarlayın, 3.0 versiyonuna girilmiş tüm hataları tekrarlayın".

Böylece müşteri / müşteri kalite temsilcisi, test planlarınızı / prosedürlerini şirket kalite prosedürlerinizde belirttiğiniz gibi yaptığınızı görecek ve güven duyacaktır; aksi durumda kendilerini yanıltmaya çalıştığınızı düşünebilirler.

Testlerde Hata Bildiriminde Dikkat Edilmesi Gereken Girdiler

Testlerde bulunan hataları yazılım geliştirme ekibine "Hata Takip Aracı" (Mantis, Jira, gibi) üzerinden iletirken dikkat edilmesi gereken başlıkları aşağıda listeledim; bu liste amaca göre daha da detaylandırılabilir.

Hata bildirirken dikkat edilecek temel konular:

• Hata tanımını okuyan herkesin, bu tanımda ne belirtmek istediğinizi anlayabileceği kadar açık ve net yazılmış olmalı,
• Yazılım geliştiricinin koddaki hatayı tespit etmesini kolaylaştırmak üzere hatanın nerede, ne yaparken, hangi ortamda, (varsa) hangi dosya / eklenti ile çalışırken ortaya çıktığı belirtilmeli.

Başlıklar halinde ele alırsak:

1. Kısa Açıklama / Başlık
2. Hatanın detaylı açıklaması: Tam olarak hangi ekranda, ne yaparken ne oldu bilgisi.
3. Test dokümanı ile test yaparken bulunan bir hata ise;
1. Test dokümanı ismi, revizyonu, test durumunun ismi, hatanın bulunduğu adım no.
4. Test edilen uygulamanın versiyonu,
5. (Eğer web uygulaması ise) Kullanılan internet gezgini ismi ve versiyonu,
6. Hatanın önem derecesi (sisteme etkisi),
7. Hatanın öncelik derecesi (testlerin devamına engel ise öncelikli),
8. Kullanılan işletim sistemi ve versiyonu,
9. Hatanın ekran görüntüsü,
10. Eğer testte bir dosya / betik kullanıldıysa, hata tanımına ek olarak verilmeli.
11. Eğer varsa, sunucu kayıt dosyasındaki hata kaydı (error.log, server.log) gibi.

Eğer daha standart bir liste arıyorsanız, "IEEE-STD-1044-2009-Standard Classification for Software Anomalies" standartını kullanabilirsiniz.

Yazılım Test Araçları

Yıllar içerisinde kullandığım test araçlarını burada liste haline getirdim. Bunun dışında test mühendisliği kariyeriniz boyunca gelişiminize faydası olabilecek konferans / toplulukların videolarını da fırsat buldukça ekliyorum.

Fonksiyonel Test Araçları:
Selenium - Web temelli ürünlerin fonksiyonel testlerinin otomasyona alımında kullanılabilecek bir araç. Üç adet bileşeni var; IDE, WebDriver, Grid.
IDE bir Firefox eklentisi. Kaydet-Oynat mantığında çalışan bir uygulama. Bazı basit testleri bu IDE'yi kullanarak yapabilirsiniz. Fakat detaylı iş akışları, kontroller, tekrarlar, vs. gerektiren testleri yazmak için WebDriver ile kod yazmanız gerekmektedir. IDE'nin faydası, bir testi kaydedip sonrasında bunu WebDriver kodu olarak dışarı aktarabilmektir. Kod yazım zamanını oldukça kısaltıyor. WebDriver'ın kullandığı betik dilinin adı Selenese, öğrenmesi çok zor değil, Java'ya benziyor. Programlama dillerine aşina iseniz, hızlıca öğrenebilirsiniz. Grid ise yazılan testlerin pek çok farklı internet gezgininde (Chrome, Firefox, Safari, IE, ...) çalıştırılmasını sağlamaktır.

Ranorex - Bu ürün görece yeni bir araç. Kaydet-Oynat mantığında çalışıyor, fakat RanoreXPath özelliği ile kaydedilen testler daha etkin bir hale getirilebiliyor. Şurada kısa bir incelemesini yapmıştım. Benim hoşuma gitti açıkçası bu ürün.

IBM Rational Functional Tester - Bu ürünü birkaç senedir kullanmadım. Temelde bu da Ranorex gibi bir ürün. Geniş bir protokol desteği var. Dezavantajı pahalı olması.

SoapUI - Web servislerinin testleri için vazgeçilmez bir araç. Pro versiyonunda ekstradan kolaylıklar da sağlanmış, manuel yapılan işlemleri kolaylaştırmışlar. Ama ücretsiz versiyonu da işinizi fazlasıyla görecektir. Bir de kardeş ürünü var LoadUI, web servislerine yük testi yapmak için kullanılıyor.

Performans Test Araçları:
Jmeter - Apache firmasının geliştirdiği vazgeçilmez bir araç. İlk başlarda alışmanız biraz zaman alabilir ancak oldukça güçlü ve ücretli ürünlerden aşağı kalır bir yanı yok. Eklentiler ile raporlama yetenekleri de oldukça geliştirildi.

OpenSTA - Web ürünlerinin performans testlerinde kullanılır. Birkaç senedir güncellenmiyor, o yüzden artık bu ürünü tavsiye edemem.

Güvenlik Test Araçları:
OWASP ZAP - Open Web Application Security Project Zed Attack Proxy. 
Wireshark
FindBugs

Sharkfest:
http://www.youtube.com/results?search_query=sharkfest

Riverbed Channel: 
http://www.youtube.com/user/RiverbedTechnology/videos

Hackathon:
http://www.youtube.com/results?search_query=hackathon

Ranorex Test Otomasyon Aracı

Ranorex isimli fonksiyonel test otomasyon aracını ancak deneme fırsatı bulabildim. Toplamda şimdilik 2 gün bakabildim.

Kullanımı kolay sayılır, açıkçası benim çok hoşuma gitti.

Windows tabanlı uygulamaların yanında plugin desteği sayesinde Java'dan SAP'ye kadar pek çok uygulamanın arayüzündeki nesneleri yakalama yeteneğine sahip. Ayrıca Web ve Mobil teknolojilerin fonksiyonel test otomasyonunda da kullanılıyormuş; bu ikisine henüz bakamadım.

Test durumlarının oluşturulması, yönetimi, yeni test / adım eklenmesi oldukça kolay. Ancak GIS uygulamalarını Ranorex de yakalayamıyor (Rational Functional Tester da yakalayamıyordu).
Çünkü bu GIS uygulamaları "render" edilen uygulamalar. Bu tür test araçları da "render" edilen veya 3-boyutlu olan uygulamaları şimdilik yakalayamıyor.

Onun dışında genelde nesnelerin hepsini yakaladı ve başarılı testler oluşturabildim. Yaşadığım 2 küçük sayılabilecek sıkıntı;
 - Java'da JPanel container 'ı tek bir nesne olarak yakalıyor, içindeki metinleri satır satır yakalamıyor,
 - Windows command ekranını tek bir nesne olarak yakalıyor, içindeki metinleri satır satır yakalamıyor,

Böylece doğrulamayı "imaj"lar ile yapmak durumunda kaldım; çok büyük sıkıntı değil.

Oldukça fazla yeteneği var ürünün, keşfettikçe buraya yazarım.

Ranorex'in 30 günlük deneme sürümünü web sitesinden indirebilirsiniz. Eğitim videoları da var, onları izlemenizi de tavsiye ederim.

Web Sitesi = http://www.ranorex.com/

Youtube'da da birkaç video var: Ranorex Tanıtım Videoları

Test Mühendisi Olarak İş Görüşmesinde Sorulabilecek Sorular

Başvuru yaptığınız iş hakkında ne kadar detaylı bilgi sahibi olursanız, hem firma hem de siz daha iyi bir seçim yapabilirsiniz.
Bana göre sorulması gereken soruları aşağıda listeledim. Hepsini sormak ve/veya cevap almak mümkün olmayabilir... :)

1. Benden beklentiniz tam olarak nedir?
2. Kaçar senedir bu firmada çalışıyorsunuz?
3. Bu firmayı 3 kelime ile nasıl anlatırsınız?
4. Bu pozisyona neden ihtiyaç duyuldu? Daha önce biri çalışıyordu da işten mi ayrıldı, yoksa yeni bir proje sebebiyle ihtiyaç mı doğdu? Ayrıldı ise neden ayrıldığını biliyor musunuz?
5. Projelerin / ürünlerin geliştirilme süreleri en az / en çok kaç ay?
6. Test mühendisi olarak kaç kişi çalışıyor?
7. Hangi test mühendisliği pozisyonları var?
8. Test mühendisleri hiyerarşide kimlere bağlı?
9. Eğer proje yöneticisine bağlı ise test mühendislerinin bağımsızlığını nasıl garanti ediyorsunuz?
10. Hangi seviyelerde test yapıyorsunuz? 
11. Bağımsız test ortamınız var mı?
12. Test süreçleriniz hangi standartlarla uyumlu?
13. Test otomasyonunu hangi seviyede yapıyorsunuz? Neler yapıyorsunuz? Beklentiniz ne?
14. Performans, Güvenilirlik, Uyumluluk, Güvenlik, vesaire testlerden kaç kişi sorumlu?
15. Dokümante edilmiş süreçleriniz var mı?
16. Analiz ve tasarımı kimler yapıyor? Ne tip bir kontrolden geçiyor?
17. Analizde ne tip sorular soruyorsunuz?
18. Müşteri tarafında analiz ve tasarım sonuçlarını yorumlayacak kimse yoksa, ne yapıyorsunuz?
19. Kullanıcı ortamına ilk ne zaman ve sonrasında hangi sıklıkla yayımlama yapıyorsunuz?
20. Her bir yayımdaki değişiklikleri müşteri ile nasıl koordine ediyorsunuz?
21. Eğitimleri kim / nasıl veriyor? Ne tür materyal kullanıyor?
22. Projeler / ürünler hangi teknolojiler ile geliştiriliyor?
23. Ar-Ge mi Taahhüt mü Ürün-temelli mi çalışıyorsunuz?
24. Feature Developer’lar müşteri ile hangi aşamalarda görüşüyor?
25. Müşteri istekleri ve şikayetleri ile kim yüzleşiyor?
26. Konfigürasyon Yönetimi hangi aşamalarda devreye giriyor? Kaç kişi çalışıyor?
27. Kalite Güvence hangi aşamalarda devreye giriyor? Kaç kişi çalışıyor?
28. Çalışana bağımlılığını nasıl en aza indirgiyorsunuz?
29. Fazla mesai yapıyor musunuz? Ne sıklıkta?

Kullanıcı ile Empati Kurabilmek Neden Önemlidir?

Bunu örnek bir senaryo üzerinden inceleyelim. Bazı konuları bilerek abartıyorum, çünkü bizler en kötü duruma hazırlıklı olmak için test senaryoları geliştirmeliyiz.

"Ayşe hanım, 4 aylık hamiledir. İstanbul'da toplam çalışanı 750 olan bir devlet dairesinde veznede çalışmaktadır. Aylardan Temmuz ve aynı zamanda Ramazan ayıdır. Dışarıda sıcaklık 37 derece. Klima / havalandırma sistemi arıza yaptığı için çalışma ortamındaki sıcaklık bunaltıcıdır. Saat 16:00'dır ve Ayşe hanımın veznesi önünde bekleyen 25 kişi vardır. Bekleyenler, işlemlerin uzun sürdüğü gerekçesi ile söylenmektedir. İşlem sırası kendisinde olan yaşlı amcamız, evraklarında nelerin eksik olduğunu pek anlayamamıştır ve Ayşe hanımla tartışmaktadır. Bu arada Ayşe hanım, yaşlı amcaya detaylı bilgi vermek istemektedir, fakat 'Detayları Göster' düğmesine tıklamasının üzerinden 3 dakika geçmesine rağmen halen sistem bir cevap verememiştir. Sırada bekleyenlerin sesleri daha da yükselmekte, ortamdaki gerilim de artmaktadır. Ayşe hanım, yan veznedeki Hüseyin beye sistemin onda da çalışıp çalışmadığını sorar. Hüseyin bey 'bu sisteme geçtik geçeli iki yakamız bir araya gelmedi, sürekli donuyor, bekletiyor, garip garip hatalar veriyor' der..."

Biraz hikaye havasında oldu :) Fakat gerçekte de olması gereken de bu.
Şimdi kendinizi o veznede çalışan insanın yerine koyun. Orada bir hizmet vermeye çalışıyorsunuz fakat işlerinizi kolaylaştırması gereken "sistem", sizi engelliyor. Ne yaparsınız? Ne söylersiniz? :)

Bu yüzdendir ki, test mühendisleri olarak, kullanıcılar ile yakın temasta olup, onların hangi zorluklar altında çalıştığı, onlar için nelerin kritik olduğunu öğrenip, geliştirdiğimiz sistemi, bu tür şartlar altında sorunsuz olarak çalışacak hale getirmemiz gerekiyor. Bazı konuları / sıkıntıları kullanıcı size söylemez / söylemek istemeyebilir veya henüz farkında değildir. Fakat siz, deneyiminiz ile, ilerde ne tür ortam olacağını hayal edip, ona göre tedbirlerinizi almalısınız.

Test Mühendisliğinde Teknik mi Önemlidir Sosyal Yetkinlikler mi?

Yani, iyi bir test mühendisi olmak için teknolojilere ve tekniklere mi ihtiyacımız var yoksa sosyal yetkinliklere mi?

Hayatta her konuda olduğu gibi bu konuda da en optimal yaklaşım "denge" sağlamak olmalıdır;
 hem teknik hem de sosyal yetkinlikler önemlidir.

Çok özel durumlarda, örneğin, son kullanıcı / müşteri ile hiç görüşmeyecekseniz ve şirket içinde de tüm iletişimi elektronik yoldan yapıyorsanız, sosyal yeteneklere çok ihtiyacınız olmayabilir.
Fakat böyle çalışan kaç kişi var?

Aslında sadece test mühendisliği değil, genel olarak yazılım mühendisliği yoğun olarak sosyal yetkinliklere (özellikle de empatiye) ihtiyaç duyulan bir alandır.
Kendini müşterinin yerine koyamıyorsan, her gün defalarca ve de saatlerce kullanacağı bir yazılımı geliştiren ekip olarak, müşteri / kullanıcının dertlerini ve önceliklerini anlayamamışsan, "kaliteli" bir ürün verme ihtimalin düşük olacaktır.

Bu durumda, test mühendisi olarak, en kötü durumlar için senaryolar geliştirip, bunları test etmek için gerekli teknik yetkinliklere ihtiyacımız olduğu gibi müşteri / kullanıcının önceliklerini anlamak ve etkili iletişim kurabilmek için sosyal yetkinliklere ihtiyacımız vardır.

Yazılım Test Mühendislerinin Eksiklikleri

Yazılım geliştirme mühendisleri, gelişen teknoloji ve müşteri / şirket beklentileri doğrultusunda sürekli olarak yeni teknolojileri öğrenme ve uygulama mecburiyetindedilrer; en azından "mühendislik" yapan büyük bir kısmı.

Fakat yazılım test mühendislerinde durumun böyle olmadığını gözlemliyorum.
Test mühendisliği teknikleri daha yavaş ilerleme ihtiyacı duyuyor olabileceği gibi test yazılımları / teknolojileri de daha yavaş gelişim gösterme gereği duyuyor olabilir.
Bu bir tarafa...

Asıl sorun, test mühendislerinin bir aşamaya kadar kendilerini eğitip sonrasında "duraklama dönemi"ne girmeleri. Pek çok meslekte var bu sorun fakat onlar hakkında yorum yapacak deneyimim yok...

Gördüğüm sorunlar şu şekilde:
- Birkaç manuel test tekniği, planlama, test tasarımı ve geliştirme konusunda deneyim sahibi olunur,
- Bir parça SDLC bilgisine sahip olunur,
- Çok nadiren, mecbur kalındıkça test araçları öğrenilir,
- Ve "zaten ben bu işte her şeyi biliyorum" diye uzunca yıllar bu bilgilere yenisi pek eklenmeden devam edilir.

Ben de aslında çok farklı değildim; bunun sebepleri biraz deneyimsizlik biraz da yol gösteren / referans alabileceğin kişilerin azlığı.

Fakat günümüzde durum farklı.
Bu meslek dalı yaygınlaştı; kitaplar, videolar, bloglar, standartlar, metodolojiler fazla fazla var.
Geriye kalan tek ihtiyaç kişinin öğrenme isteği oluyor.

Gereksinim ile Tanımlama Arasında Ne Fark Vardır?

IEEE Yazılım Mühendisliği Terminolojisinin Standart Sözlüğü'ne göre:

Gereksinim (Requirement) 
(1) Bir problemi çözme veya bir amacı gerçekleştirmek için kullanıcı tarafından ihtiyaç duyulan bir durum veya kabiliyet,
(2) Bir sistem veya sistem bileşeninin bir sözleşme, standart, tanımlama veya resmi olarak dayatılan diğer dokümanların isteklerine cevap verebilmesi için karşılaması veya sahip olması gereken bir durum veya kabiliyet.
(3) (1) ve (2)deki gibi, bir durum veya kabiliyetin dokümante edilmiş gösterimi.

Tanımlama (Specification) 
Bir sistem veya bileşenin gereksinimleri, tasarımı, davranışı veya diğer karakteristiklerini tam, kesin, doğrulanabilir bir şekilde tanımlayan bir dokümandır.

İstisnai Durum (Exception) Nedir ve Java'da Yaygın Karşılaşılan İstisnai Durumlar Nelerdir?

"Exception" kelimesini İstisna veya İstisnai Durumu olarak tercüme edebiliriz.
Oracle'a göre istisnanın açıklaması şöyle:
"Bir programın çalışması sırasında ortaya çıkan ve programın normal komut akışını bozan bir durumdur."

İstisnaların "throw" ile atılması, "try/catch/finally" ile yakalanması gerekmektedir. Kontrol altına alınmamış istisna durumları RuntimeException olarak adlandırılır.

Java'da yaygın olarak karşılaşılan istisnai durumlar ve açıklamaları aşağıdadır. Yaptığınız testlerde bu istisna durumlarına özellikle dikkat etmeniz faydalı olur.
(Tam liste için http://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html adresine bakabilirsiniz.)

ArithmeticException 
İstisnai bir aritmetik durum ortaya çıktığında atılır.

ArrayIndexOutOfBoundsException 
Bir diziye (array) geçerli olmayan bir indeks numarası ile erişilmeye çalışıldığında atılır.

ArrayStoreException 
Bir nesne dizisi içine yanlış tipte bir nesne kaydedilmeye çalışıldığında atılır.

ClassNotFoundException 
Bir uygulama bir sınıfı karakter dizisi ismi ile (Class sınıfındaki forName metodunu kullanarak) yüklemeye çalıştığında atılır.

IllegalArgumentException 
Bir metotun geçerli veya uygun olmayan bir argümanı geçirmeye çalıştığını belirtmek için atılır.

IllegalStateException 
Bir metot geçerli veya uygun olmayan bir zamanda çağrıldığında atılır.

IllegalThreadStateException 
Bir iş parçacığının, talep edilen işlem için uygun bir durumda olmadığını belirtmek için atılır.

IndexOutOfBoundsException 
Herhangi bir tipteki (dizi, karakter dizisi, veya vektör gibi) indeksin sınırları dışında olduğunu belirtmek için atılır.

InterruptedException 
Bir iş parçacığı ("thread") beklerken, uyurken veya diğer türlü bir şekilde meşgulken, bu iş parçacığına iş yaparken veya işini bitirmeden müdahale edilirse atılır.

NegativeArraySizeException
Uygulama negatif genişlikte bir dizi oluşturmaya çalıştığında atılır.

NoSuchMethodException 
Belirli bir metot bulunamadığında atılır.

NullPointerException 
Bir uygulama, bir nesnenin gerektiği bir durumda "null" kullanmaya çalıştığında atılır.

NumberFormatException 
Uygulamanın bir karakter dizisini nümerik tiplerden birine dönüştürmeye çalıştığı ama karakter dizisinin uygun formata sahip olmadığını belirtmek için atılır.

RuntimeException 
RuntimeException, Java Sanal Makinası'nın normal çalışması sırasında atılabilecek diğer istisnaların bir süpersınıfıdır.

SecurityException 
Güvenlik yöneticisii tarafından bir güvenlik ihlali olduğunu belirtmek için atılır.

StringIndexOutOfBoundsException 
Bu istisna "String" methodları tarafından, bir indeksin ya negatif veya karakter dizisinin uzunluğundan büyük olduğunu belirtmek için atılır.

UnsupportedOperationException 
Talep edilen işlemin desteklenmediğini belirtmek için atılır.

Ayrıca, aşağıda belirtilen durumlarda en sık karşılaşılan istisnalar listelenmiştir:

Casting: ClassCastException
Arrays: ArrayIndexOutOfBoundsException, NullPointerException
Collections: NullPointerException, ClassCastException
IO: java.io.IOException, java.io.FileNotFoundException, java.io.EOFException
Serialization: java.io.ObjectStreamException
Threads: InterruptedException, SecurityException, IllegalThreadStateException

Şu video da oldukça faydalı: How to handle 10 common Java Exceptions

Yazılım Test Mühendisliği - İş Görüşmesinde Sorulan Sorular

Bu konuda oldukça sık e-posta alıyorum, o yüzden bir blog mesajı yazmayı uygun gördüm. Sorular genelde yeni mezun ve/veya test mühendisliği alanında çalışmamış ama yaptığı ilan başvurusu sonrasında iş görüşmesine çağrılmış kişilerden geliyor.

Genelde soru içeriği "iş görüşmesine çağırdılar, hangi soruları sorarlar, ne cevap vermeliyim" şeklinde oluyor.

Herhangi bir iş görüşmesinde sorulabilecek soruların sınırı yoktur, hepsini burada yazmaya imkân yok. Özel olarak, yazılım test mühendisliği iş görüşmelerinde sorulan / sorulabilecek soruları aşağıda listeledim, cevaplarını araştırmayı ise okuyucuya bıraktım :)

İş görüşmelerinde (özellikle yeni mezunlar ile yapılanda) sorulan her soruya doğru cevap vermeniz beklenmez (en azından ben beklemem), fakat daha ziyade bu sorulara karşı nasıl bir yaklaşım geliştirdiğiniz, nasıl çözüm ürettiğiniz ile ilgilenilir.

Sorular:

• Yazılım Testi sizce nedir? 

• Yazılımı neden test edelim, zaten yazılım geliştiriciler dikkatli bir şekilde kod yazıyorlar ve birim test yapıyorlar? 

• Sizce tek tip yazılım testi mi vardır, yoksa birden fazla test türü olabilir mi? 

• Bildiğiniz test türleri nedir? Bunlardan hangilerini icra ettiniz?
  

• Hata (Defect) ile Kusur (Deficiency) arasındaki fark nedir?

• Sorun, Arıza, Kusur, Hata, Bozukluk tanımları sizce aynı şey midir? Ne gibi farkları olabilir?

• Bir hatanın önem derecesi ile öncelik derecesi arasındaki fark nedir?

• Örneğin bir yazılımda hata tespit edildi ve yazılım geliştirici tarafından hatanın düzeltildiği söylendi. Sonrasında ne yaparsınız?

• Daha önce hangi test araçlarını kullandınız?

• Özgeçmişinizde HP Load Runner'ı bildiğiniz yazıyor, işte size bilgisayar ve Load Runner programı, şirketimizin web sitesine hemen bir yük testi hazırlayabilir misiniz?

• Bir hesap makinesini nasıl test edersiniz?

• Peki bir meşrubat şişesini nasıl test edersiniz?

• TürkSat 2A uydusunun yazılım test sorumlusu olsaydınız, ne tip testler yapardınız?

• Yazılım ekibi, geliştirdikleri uygulamanın 16 milyon adet rengi desteklediğini iddia etmektedir. Uygulamanın kullanıcısı olan grafik tasarımcılar için 16 milyon rengin desteklenmesi önemlidir. Uygulamanın gerçekten bu kadar rengi desteklediğini nasıl doğrularsınız?

• Bir yazılım mühendisinin geliştirdiği uygulamadaki hataları test mühendisi bulur, peki test mühendisinin olası hatalarını kim bulur?

• Test edilecek uygulamanın bir sayfasında bir metin alanı ve bir sayı alanı vardır. Bu iki alanın her birini nasıl / hangi girdileri kullanarak test edersiniz?

• Test etmekte olduğunuz uygulama ile ilgili açılmış 100 adet hata henüz çözülmemiş durumdadır. Ancak proje yöneticisi uygulamanın müşteri ortamına kurulmasında ısrar etmektedir. Sizce nasıl bir yol izlenmelidir?

• 20 adet alt modülden oluşan bir sistem olduğu düşünelim. Sistem, pek çok sensörden bilgi toplamakta, topladığı bu bilgileri bu 20 adet modül içerisinde çeşitli işlemlerden geçirmekte ve işlemler sonunda tek bir karar vermektedir (ve bu kararın ölümcül sonuçlarını olduğunu düşünelim). Sistemin doğru karar verdiğini test etmek için nasıl bir yol izlersiniz?

• Hangi yazılım test standartları hakkında bilgi sahibisiniz?

• Hangi yazılım geliştirme yaşam döngüleri hakkında bilgi sahibisiniz?

• Bir yazılım geliştirilirken baştan sona hangi aşamalardan geçilir?

• Yazılım ile sistem arasında sizce nasıl bir fark vardır?

• Gereksinim ne demektir? Neden ihtiyaç vardır?

• Gereksinimi olmayan bir uygulama olabilir mi? 

• Uygulamaların gereksinimlerinin olmamasının ne gibi sakıncaları olur? 

• Bir "Test Durumu" (Test Case) ile "Kullanım Durumu" (Use Case) arasındaki fark / ilişki nedir? 

• Gereksinim - Tanımlama (Specification) - Kullanım Durumu (Use Case) - Test Durumu (Test Case) arasında nasıl bir ilişki vardır? 

• Fonksiyonel bir gereksinim ile Fonksiyonel Olmayan bir gereksinim arasında ne gibi farklar vardır? 

• 10.000 adet gereksinimi ve 3500 adet test durumu olan bir projenin Kabul Komitesi'nde olsaydınız, uygulamanın eksiksiz olarak doğrulandığından emin olmak için neleri kontrol ederdiniz?
  

Yazılım Testi'nde Kendimi Geliştirmek İstiyorum, Önerileriniz Nedir?

Soru: Yazılım testine ilgi duyuyorum ve bu mesleği seçerek yolumda ilerlemeye çalışıyorum. Bilgisayar mühendisliği öğrencisiyim şuan software test specialist olarak çalışıyorum. Kendimi bu alanda geliştirmek istiyorum. Test türlerinide açıkladığınız bir dökümanınız varmı gerçi wikiden falan inceledim...
Test türlerini bir ağaç gibi oluşturmak istersem neler dikkat etmem gerekir örneğin fonsiyonel ve fonksiyonel olmayan testleri sınıflandırmak iki başlık altında toparlamak istiyorum bu konuda yardımcı olabilir misiniz? Yol gösterebilir misiniz?

Cevap: 

Benim test türlerini açıkladığım bir doküman yok.

Şurada bir kaç yazı paylaşmıştım bir boş zamanımda, aşağıdan yukarıya doğru okursan daha faydalı olur:  http://serdartorun.blogspot.com/search/label/Yaz%C4%B1l%C4%B1m%20Testi

Test türlerini bir ağaç gibi oluşturmak istiyorsan, ayırmak zorunda değilsin aslında ama, evet, çok üst seviyede fonksiyonel ve fonksiyonel olmayan diye iki ana dala ayırabilirsin.

Fonksiyonel, bir fonksiyonun / yeteneğin istendiği gibi çalışıp çalışmadığını doğrulamaktır. Bu birim seviyesinde de olabilir, sistem seviyesinde de. 

Fonksiyonel olmayanlar ise, bir sistemin kalitesi ile ilgilidir. Sistem çalışıyordur, kendisinden istenenler yapıyordur, ama 5 saat aralıksız çalıştığında memory leak oluyordur veya sistem yavaşlıyordur. sonuçta sistem çalışıyor, ama kaliteli mi? değil.

Veya sistem windows üzerinde çalışıyor ama bu sistemi linux üzerine taşımak istesem bir sürü masraf çıkıyordur.

Veya sistem aldım, kaynak kodu da bende, aradan 3 sene geçti, bir başka firmaya mevcut sistem üzerinde bir kaç ekleme yaptıracağım, "maintainable" değilse yeni firma tırmalar durur, gibi. Bunlar hep sistemin kalitesini artıran özellikler.

Bence ilk önce şöyle yap.

Fonksiyonel testlerin listesini çıkar internetten.

ISTQB, SQA Forum, Wikipedia, vesaire yerlerde var bunlar.

Bir de Test Glossary bul (istqb glossary of testing terms, gibi); bir kaç farklı kaynaktan bulup derlemen en iyisi. Uzun bir liste olacak bu.

Sonra fonksiyonel olmayanlara geçersin, ki o çok daha uzun olacak.

Şu standartlara bakman faydalı olur:

IEEE-STD-1012-2004-Standard for Software Verification and Validation

IEEE-STD-1044-2009-Standard Classification for Software Anomalies

IEEE-STD-829-2008-Standard_for_Software_and_System_Test_Documentation

ISO-STD-12207-2008_Software_life_cycle_processes

Mil-Std-498 ve ekleri (DID diye geçer).

Ayrıca fonksiyonel olmayan testler için bu "-ibility" ile biten kalite karakteristiklerinin tanımı için ISO-IEC-FDIS-25010_(E) standartına bakmalısın.

Böylelikle kendi dokümanını kendin hazırlamış olursun, bir taraftan da elinde standartlar birikmeye başlar. Mutlaka ama mutlaka standartlarda yazanlara öncelik ver, internette pek doğru olmayan / yanıltıcı bilgiler de oluyor.

Özetle şunlar elinde birikmiş olacak:

Test Türlerinin İsimleri,

Açıklamaları,

Kalite Karakteristiklerinin İsimleri,

Açıklamaları,

Test Sözlüğü,

IEEE Test Standartları,

ISTQB Syllabus

Mil-Std-498 Standartı

Gereksinim Analizi Yaparken Nelere Dikkat Edilmeli

Gereksinim analizinin amacı temel olarak, müşterinin / kullanıcının ihtiyaçlarının neler olduğunu ortaya çıkarmaktır.

Yazılım projelerinin önemli bir kısmının başarısız olmasının temel sebeplerinden biri budur.
Kısaca, cevaplanması gereken sorular şunlardır:

• Kim; kullanıcı kimdir? Eğitim seviyesi, bilgisayar / mobil cihaz bilgisi nedir? Kullanıcılar arasında bedensel /zihinsel engeli olanlar da var mı? 
• Nerede; kullanıcı bu ürünü ne tip bir ortamda kullanacak? Evde mi, iş yerinde mi, açık havada mı, atölyede mi, sarsıntılı / nemli / sıcak / soğuk bir ortamda mı, ...? Donanım / ağ altyapısı nedir?
• Ne; kullanıcı hangi sorununu çözmek için bu yazılımı kullanacak?
• Nasıl; kullanıcı bu yaşadığı sorunu çözerken nasıl bir iş akışından geçiyor? 
• Ne Sıklıkta; kullanıcının bu iş akışlarını hangi sıklıkta gerçekleştirdiği: her gün, her saat ? Gün içerisinde herhangi bir anda?
• Kaç Kişiyle; yazılımı kaç kişi kullanacak? Bu kullanıcılar hangi iş akışlarını hangi sıklıkta kullanacak? 

Bu soruların tamamına doyurucu cevaplar alındığında geliştirilecek yazılım ile müşteri beklentileri çok büyük oranda örtüşmüş olacaktır.

Test Mühendisi Projenin Sahibidir

Yazılım projeleri, tanımları gereği genelde bir "proje" olarak algılanırlar. Proje, başlangıç ve bitiş tarihi belirli olan bir süreçtir. Dolayısıyla bu projede çalışanlar da (genelde) "bana verilen işi yaptım, ücretimi aldım" gözüyle bakarlar projelere.
Yani aslında kendilerini projenin sahibi olarak görmezler; sonuçta proje müşterinin ve projeyi yapan şirket sahiplerinindir diye düşünülür. Proje ile ortaya çıkan ürün veya hizmetin kimlerin hayatını kolaylaştıracağı veya zorlaştıracağı, kimlerin bu ürün/hizmetten dolayı mutlu olacağı veya acı çekeceği pek düşünülmez (düşünenler vardır tabii, genel izlenimlerimi aktarıyorum).

Bu tarz bir düşünce yanlıştır diyemeyiz; herkesin algısı ve hayata bakışı farklı.

Bir test mühendisi olarak eğer ki yaptığınız işin altına imza atacaksanız ve/veya bulunduğunuz şirkette uzun seneler çalışmayı düşünüyorsanız, sorumluluğunuz altına aldığınız veya verilmiş projelerin "genel sağlığı"ndan da birinci derecede sorumlusunuzdur. Şöyle ki;
- Eğer yaptığınız işin altına imzanızı atacak kadar güvenmiyorsanız veya "aman yapılsın bitsin de..." tarzında düşünüyorsanız, bu işler bir süre sonra sizi takip edecek ve isminizi kötüye çıkaracaktır (gerçi bu her sektör ve her iş grubu için aynı).
- Eğer bulunduğunuz şirkette uzun seneler boyunca çalışmayı düşünüyorsanız ve çalıştığınız projeler uzun soluklu (operasyon denilebilecek tarzda) projeler ise, diğer herkes (proje yöneticisi, yazılım geliştiriciler) başka projelere veya şirketlere gittiğinde o üründen neredeyse tek başınıza sorumlu olursunuz, çünkü şirkette o projeyi detaylı olarak bilen bir başkası kalmamıştır.

Test mühendisi ürünün doğru, hızlı ve kullanılabilir olmasından sorumludur, ürünün şirket içindeki müşterisidir, ürünü müşteriye ve son kullanıcıya kabul ettirecek kişidir; bu açıdan bakıldığında projenin sahibidir.

Eğer aşağıda yazdığım konulara zamanında dikkat etmezseniz, projenin ilerleyen aşamalarında büyük zorluklar çekmeniz ve/veya ürün kalitesinde düşüş kaçınılmazdır .

- Fonksiyonel Doğruluk: Ürün/hizmet istendiği şekilde ilgili kullanıcıların ihtiyacını karşılamak zorunda. Bundan aslında bahsetmeye gerek bile yok.

- Kullanılabilirlik: Mümkün olduğu kadar az işlem yaptırarak, kullanıcının istediği bilgiyi mümkün olduğu kadar hızlı bir şekilde sunmak, şeklinde özetleyebiliriz. Diğer bir durum da, kullanıcının karşısına çıkardığınız ürün/hizmette tek bir tane bile gereksiz simge, resim, yazı vesaire olmamalıdır. Sunulan fonksiyon, arayüz, hizmet, ... amacına uygun olmalıdır.
Ayrıca Erişebilirlik (Accessibility) yani engelli kişilere kolaylık sağlayacak özellikler de bu kapsamda değerlendirilebilir.

- Performans: Ürünler/hizmetlerin sanki bunu tek bir kişi kullanacakmış tasarlanması ve geliştirilmesi ölümcül bir hatadır. Hedef kullanıcı kitlenizin büyüklüğünü bilmek durumundasınız.

- Ölçeklenebilirlik: Bugünün veya yakın geleceğin şartlarına göre üretilen bir ürün/hizmetin senelerce insanlara hizmet etmesi isteniyorsa, bu ürün/hizmetin artan kullanıcı sayısı ile paralel olarak genişletilebilmesi gerekir.

Yazılımın Test Edilebilirliği

Sözleşmelere genelde eklenen ama ne sözleşmeyi yazanların ne de proje takımlarının net olarak bilmediği bir konu olan Yazılımın Test Edilebilirliği ile ilgili bir blog mesajıdır bu.

Aşağıdaki 1. bölüm Wikipedia'dan tercümedir (tercüme sonrasında anlamın korunmasına gayret ettim).
2. bölümde standartlardaki konu ile ilgili açıklamalar verilmiştir.

1) Yazılım test edilebilirliği, bir yazılım ürününün (örneğin bir yazılım sistemi, yazılım modülü, gereksinim veya tasarım dokümanı) test faaliyetini desteklemesidir.
Test edilebilirlik bir yazılım ürünün doğal olarak içinde olan bir özellik değildir ve doğrudan ölçülemez. Aksine, test edilecek ürün ile testin amaçları, kullanılan test yöntemleri ve test kaynakları arasındaki karşılıklı bağımlılıktan doğan dışsal bir özelliktir.
Düşük seviye test edilebilirlik, test eforunun artmasına sebep olur. Bir uç durum olarak, test edilebilirliğin olmayışı yazılımın test edilecek parçalarının gizlenmesine sebep olabilir.

Yazılım bileşenlerinin (modüller, sınıflar) test edilebilirliği aşağıdaki gibi faktörler tarafından belirlenir:
Kontrol Edilebilirlik: Test edilmesi gereken bileşenin bulunduğu durumun kontrolüne ne ölçüde imkan sağlandığı,
Gözlemlenebilirlik: Ara veya nihai test sonuçlarının gözlenmesine ne ölçüde imkan sağlandığı,
İzole Edilebilirlik: Teste tabi bileşenin izole bir ortamda test edilebilme seviyesi,
Sorumluluğun Ayrıştırılması: Teste tabi bileşenin ne seviyede iyi tanımlı, tek bir sorumluluğu olduğu,
Anlaşılabilirlik: Teste tabi bileşenin ne seviyede dokümante edildiği veya kendinden-anlaşılabilir olduğu,
Otomatikleştirilebilmesi: Teste tabi bileşenin testlerinin otomatikleştirilmesine ne oranda imkan sağlandığı,
Ayrışıklık: Paralel olarak farklı test yöntemlerinin ve araçlarının kullanımının gerektiği.

Yazılım bileşenlerinin test edilebilirliği Test-Odaklı Geliştirme ve Test Edilebilirlik için Tasarım yaklaşımları ile artırılabilir.

Gereksinimlerin Test Edilebilirliği: Test edilebilir olması için gereksinimlerin aşağıdaki kriterleri sağlaması gerekmektedir:
Tutarlı,
Tam,
(Tartışmasız bir şekilde) Kesin,
Nicel ("hızlı tepki süreleri" gibi ifadeler olmamalı),
Uygulamada Doğrulanabilir (Test, sınırlı kaynaklar ile sadece teoride değil uygulamada da yapılabilir olmalı).

2) Bu bölümde doğrulama ile ilgili çeşitli standartlardaki Test Edilebilirlik tanımları verilmiştir:
IEEE Std 12207-2008: "Tarafsız ve uygulanabilir bir testin, bir gereksinimin karşılanıp karşılanmadığını belirlemesi ölçütü"


ISTQB (ISO 9126'dan faydalanarak): "Bir yazılımın ürününün, değiştirilmiş yazılımın test edilmesine imkan sağlama kabiliyetidir".

Fonksiyonel Olmayan Gereksinimlere Örnekler

Sistem mühendisliği ve gereksinim mühendisliğinde fonksiyonel olmayan bir gereksinim belirli davranışlardan ziyade sistemin işleyişini yargılamak için kullanılabilecek kriterleri belirten bir gereksinimdir. Bu açıdan, belirli davranış veya fonksiyonları tanımlayan fonksiyonel gereksinimden farklıdırlar. Fonksiyonel gereksinimler sistem analizi / tasarımında detaylandırılırken, fonksiyonel olmayan gereksinimler sistem mimarisinde detaylandırılırlar.

Fonksiyonel gereksinimler bir sistemin ne yapması gerektiğini belirtirken, fonksiyonel olmayan gereksinimler ise sistemin nasıl olması gerektiğini belirtirler. Fonksiyonel olmayan gereksinimlere aynı zamanda sistemin kalite karakteristikleri de denir.

Fonksiyonel olmayan gereksinimleri iki ana kategoriye ayırabiliriz:
- İcra Özellikleri: Güvenlik, Kullanışlılık gibi işleyiş süresi içinde gözlemlenebilenler.
- Gelişim Özellikleri: Test Edilebilirlik, İdame Edilebilirlik, Genişleyebilirlik ve Ölçeklenebilirlik gibi yazılım sisteminin durağan yapısına gömülü olanlar.

Fonksiyonel olmayan gereksinimlerden sıklıkla kullanılanlarından bazılarını aşağıda listeledim. Her biri için yapılan tanımın altında örnekleri de verdim:

Bütünlük
Emniyet
Erişebilirlik
Erişim Güvenliği
Esneklik
Gizlilik
Hayatta Kalabilirlik
İdame Edilebilirlik
Kullanılabilirlik
Kurulabilirlik
Ölçeklenebilirlik
Taşınabilirlik
Tekrar Kullanılabilirlik

Yazılım Ekiplerinde Performansı Olumsuz Etkileyen 1 Numaralı Etken

Son 10 senedir yazılım projelerinde çalışarak edindiğim deneyim sonucu diyebilirim ki, bir proje ekibinin günlük performansını en çok olumsuz etkileyen faktör, çalışanın kısa süreli aralıklarla bölünmesidir.
Yüksek bir seviyede odaklanma gerektiren diğer işlerde de olduğu gibi, özellikle yazılım geliştirme (kodlama) ve test (doğrulama ve geçerleme) aktiviteleri de yoğun bir konsantrasyon gerektirmektedir.

Her 3-5 dakikada bir çalışması bölünen kişinin gün içindeki performansı aşırı derecede düşmesi de kaçınılmazdır. Bu performans kaybının hem üretkenliği hem çalışan memnuniyetini hem de nihai ürünün kalitesini olumsuz etkilediğini rahatlıkla söyleyebilirim.

Yazılımda Bulunan Hata, Kimin Hatası?

Bir ürünü geliştiren kişi yeterli bilgiye sahip olmayabilir, dikkatsiz davranmış olabilir, önemsememiş olabilir, ..., en nihayetinde üründe bir hataya sebebiyet verilmiş olabilir.
Evet, ürünü geliştiren kişinin bu hatada payı vardı, fakat bulunan hata gerçekten de sadece geliştirene mi aittir?

Nihai bir yazılım ürününde bulunan bir hatayı sadece o uygulama kodunu geliştiren kişiye atfedebilir miyiz?
Hayır !

Çünkü, her ne kadar geliştirme/yazma işini yapan kişinin gözünden bu hata kaçmışsa da, o yazılım kodunu gözden geçirmekle, birim testlerini yapmakla, fonksiyonel testlerini yapmakla, gerekli kaynakları sağlamakla sorumlu kişiler de bu hatayı kaçırmış demektir !

Dolayısıyla, (daha önceden de yazdığım gibi) üründe yapılmış olan hata, sadece ilgili kod parçasını yazan kişinin değil, proje ekibinindir.

Ve eğer proje ekibi, üründe bulunan hatalara bu bakış açısıyla yaklaşırsa, kimseyi rencide etmeden, ekibin motivasyon ve performansını olumsuz etkilemeden süreci yönetmiş olacaktır.

Yazılım Testinde İletişim Ne Kadar Önemli?

Sosyal olma ve kolay iletişim kurabilme bir yazılım test uzmanı için hayati öneme sahiptir; özellikle de müşterili projelerde...

Test uzmanları şirket içinde projenin müşterisi rolünü üstlenirler. Bu rol sebebiyle tam olarak nihai müşterinin istediği ürünün teslim edildiğine ikna olana kadar ürünleri sorgulamak durumundadırlar.
Test uzmanı, geliştirilen projeyi nihai müşteriye kabul ettirecek kişidir. Bu sebeple, kabul testlerinde herhangi bir sorun / aksama olmaması için, şirket içindeki testlerde gereksinimlerin tam olarak karşılandığından ve üründe (bilinen) herhangi bir hata olmadığından emin olmak zorundadır; aksi halde ürünün teslimatı gecikecek ve hem şirket hem de müşteri zarara uğrayacaktır.


Bu sorgulama süreci, yazılım geliştirme ekibi ile sürtüşmelere sebep olabilir; özellikle uygulamada bulunan bir uygunsuzluğun hata olarak değerlendirilip değerlendirilemeyeceği konusunda...

Gerek şirket içerisinde gerekse de müşteri ile olan iletişimde esas önemli olan empati kurabilmektir.

Projelerde yazılım geliştirme ekipleri, bir ürünün analizi, tasarımı, kodlaması, birim testi, dokümantasyonu, hataların giderilmesi gibi pek çok konuda yoğun ve stresli bir şekilde çalışmak durumda kalabilirler; özellikle kısa takvime sahip projelerde...

Böyle stresli durumlarda iletişim kurulan kişilerin bu durumlarını da göz önünde bulundurarak, üzerinde konuşulan konu ne ise, karşı tarafı suçlamadan ve çözüm odaklı bir şekilde müşteri isteğinin karşılanması esastır.

Bu noktada bir test uzmanına düşen görev, bildirdiği uygunsuzluğun içeriği, gerekli veri setleri, uygulama çıktıları, ekran görüntüleri ve müşteri isteğinin ne olduğu, sistemin hangi özelliğini veya özelliklerini etkilediğini anlaşılır bir şekilde yazılım ekibine iletmektir; bildirilen uygunsuzluk ne kadar anlaşılır tanımlanmış ise ilgili geliştirici de uygunsuzluğu o kadar hızlı tespit edip, düzeltecektir.

Uygulamada bulunan hatayı herhangi bir çalışana adreslemek (senin hatan izlenimini vermek) yanlıştır. Gerçekte de, hata bir kişinin değil, proje ekibinindir.

Nihai müşteri tarafında ise test uzmanı ürünü müşteriye kabul ettiren kişidir; şüphesiz ki proje yöneticisi, lider yazılım geliştirme uzmanı, kalite güven uzmanı da kabul sürecinde yer alır, ancak kabule esas teşkil edecek testlerin gerçekleştirilmesi ve başarılı olması test uzmanının sorumluluğundadır.

Peki test uzmanı test dokümanlarını kullanarak bir kabul testini gerçekleştirirken müşteri ile ilişkilerinin kabulde ne gibi bir etkisi vardır?

Aynı şirket içerisindeki ekiple iletişim kurduğu gibi müşteri ile de iletişiminde empati kurabilmelidir. Müşteri, belli bir ücret karşılığında şirketinin/kurumunun işlerinde kullanmak üzere bir yazılım sipariş etmiştir ve verdiği paranın tam karşılığını aldığından emin olmak istemektedir.

Test uzmanı nihai müşteri ile sadece kabul testlerinde değil, sözleşmenin imzalanmasından itibaren analiz, ekran tasarımları, prototiplerin kullanımı, ilerleme toplantıları gibi pek çok proje aktivitesinde yakın bir şekilde çalışma imkanı bulur. Bu süreçte sözleşme, konsept dokümanları, analiz dokümanlarında belirtilenlerden öte müşterinin uygulamayı hangi amaçla kullanacağını, müşteri için nelerin kritik olduğunu, hangi tür iş adımlarını daha sık yaptıklarını, uygulamayı kullanacak nihai kullanıcının deneyim ve bilgi seviyesini mümkün olduğunca irdeleyip, "müşterinin ruhu"nu yakalamaya çalışmalıdır.

Böylece, kendisini müşteri yerine koyup, şirket içindeki testlerde, tabii ki gereksinimlere uygun olarak, fakat gereksinimlerde belirtilmemiş kullanım alışkanlıkları, iş adımlarında sık tekrarlanan ve kritik olan özelliklere daha da önem vererek testlerini hazırlaması ve koşturması önemlidir. Çünkü en nihayetinde bir yazılım ürünü kullanıcı gereksinimlerini bire bir karşılıyor olsa da "müşterinin ruhu"nu yakalayamıyorsa, kabul aşamasında sorunlar yaşanması kaçınılmazdır.

Bu nedenlerle bir test uzmanının empati kurarak, müşterinin ruhuna uygun ürünü teslim edebilmek için, hem proje ekibi hem de müşteri ile iyi, yakın ve çözüm odaklı ilişkiler kurması önemlidir.

Yazılım Testi ve Kalite Güvence Dergisi (İngilizce)

Uzun zamandır takip ettiğim ve çok da başarılı bulduğum bir dergiyi paylaşıyorum.
Software Test and Quality Assurance (Eski adı Software Test and Performance idi):
http://www.softwaretestpro.com/Publication/p/STPM/2012

Geçmiş yıllara ait sayıları da okumanızı öneririm, zira bazı konseptler çok da hızlı değişmiyor.
Ücretsiz üyelik seçeneği de var.

Yazılım Testi Terimler Sözlüğü

Yazılım Testine ait terimlerin (ki yazılım teknolojileri ilerledikçe yeni terimler literatüre giriyor) listesini buraya yazmaktansa iki adet güvenilir (İngilizce) bağlantı paylaşıyorum:

Software Testing Glossary (by ApTest): http://www.aptest.com/glossary.html

ISTQB Glossary of Testing Terms: http://istqb.org/downloads/finish/20/14.html