Yazılım Projelerinde Müşteri İletişiminin Önemi

Her ne kadar yazılım mühendisliği yoğun teknik bilgiler gerektirse de en nihayetinde yapılan iş bir müşteri / kullanıcı grubunun ihtiyaçlarını karşılamak üzere yapılır. Dolayısıyla ciddi miktarda sosyal beceriler de gerektirir.

Bu sebeple, hem ürünün geliştirilmesi için bütçe ayıran Müşteri ile hem de ürünü kullanacak Son Kullanıcı ile yakın iletişimde olmak, sonradan ortaya çıkabilecek kullanım zorluklarını çok daha erken bir zamanda ortadan kaldırmak için fırsatlar sağlamaktadır.

Bu faydaları şu şekilde sıralayabiliriz:

• Sözleşme Aşaması: Bu aşamada ihale çağrı dosyasında, müşteri ve son kullanıcı menfaatine olacak olan ancak sözleşmede belirtilmemiş idari ve teknik konularda müşteriye fikir sunulabilir. Örneğin, ürünün hedeflenen performansı, donanım altyapısı, engelli kullanıcıların da sistemi kullanmasını kolaylaştıran erişebilirlik isterleri gibi konularda önerilerde bulunabiliriz. Yine bu aşamada müşteri ve son kullanıcı hakkında mümkün mertebe detaylı bilgi sahibi olmak, nihai ürünün kalitesini artırıcı faydalar sağlayacaktır.

• Analiz Aşaması: Son kullanıcının nasıl bir ortamda, hangi şartlar altında, hangi işi, nasıl ve neden yaptığı, iş akışının ne olduğu, bu akışta kimlerin hangi sorumlulukları ve sınırlamaları olduğu gibi ürün için son derece önemli olan "kullanım durumları", kullanıcı ile empati kurularak, ortaya çıkarılmış olacaktır.

• Geliştirme Aşaması: Sözleşmede "Proje İlerleme Raporları" istenmemiş bile olsa, müşteri temsilcilerini projenin gidişatı hakkında bildirmek ve ürün ortaya çıktıkça sunumlar yapmak, müşteri temsilcilerinin projenin sağlıklı bir şekilde ilerlediğini görmeleri bakımından faydalıdır.

• Kabul Aşaması: Kabul işlemleri öncesinde oryantasyonlar verilerek, kabul sürecine müşteri temsilcilerinin en iyi şekilde hâkim olmaları sağlanır ve akıllarında herhangi bir soru işareti kalmaz.

• Ürünün Devreye Alınması: Bu aşamada yüklenici şirketin personelinin, son kullanıcı ile yakın çalışması, ürünün kullanıcı tarafından sahiplenilmesi, eski sistemden yeni sisteme geçişin hızlandırılması, ürünün nihai ortamında çalışma performansının yakından takip edilmesi gibi pek çok konuda fayda sağlar. Bu aşamada özellikle dikkat edilmesi gereken konu, kullanıcıdan gelecek olan istek / hata bildirimlerine çok hızlı bir şekilde geri dönüş sağlamak, ürünün kullanımının sekteye uğramasına engel olmaktır.

Pazarlama Faaliyetlerine Test Mühendisleri Nasıl Destek Verebilir

Test mühendisleri, geliştirilen sistemin / yazılımın ( = ürünün) tüm yeteneklerine hâkim oldukları için gerek fuarlardaki tanıtımlarda, gerek şirkete misafir olan potansiyele müşterilere yapılan sunumlarda, gerekse tanıtım araçlarının oluşturulmasında şirketlerin satış / pazarlama / iş geliştirme bölümlerine ciddi destekler verebilirler.

Aşağıdaki liste bu noktada aydınlatıcı olabilir:

• Demo Hazırlığı
• Geliştirilen ürünün demosunun, potansiyel müşteri gruplarına yönelik verilerini içererek hazırlanması,
• Demo senaryosunun oluşturulması,
• Demonun gerçekleştirilmesi  
• Sunum Hazırlığı
• Demo, fuar, müşteri ziyareti gibi amaçlara yönelik olarak ürünün genel olarak tanıtımını içeren sunum dosyasının hazırlanması,
• Sunumda 5N1K sorularına yönelik cevaplar içerilmesi,
• Potansiyel müşterinin hangi ihtiyaçlarına cevap verdiğinin net olarak belirtilmesi,
• Pazarlama Araçları Hazırlığı
• Hazırlanacak broşür için ürünün ekran görüntülerinin alınması,
• Ekran görüntüleri ile ilişkili olarak ürünün yeteneklerinin listelenmesi,
• Ürünün uyumlu olduğu standartların belirtilmesi,
• Ürünün, sektördeki diğer ürünlere göre karşılaştırmalı performansının ölçülmesi,
• Ürünün demo videosunun hazırlanması.

Gereksinim Anlaşılabilirlik Toplantısının Amacı

Her ne kadar gereksinim analizi çalışmaları sonucunda ortaya çıkan gereksinimler mümkün mertebe atomik hale getirilse ve okuyan herkesin aynı şeyi anlaması sağlanmaya çalışılsa da kimi gereksinimler özellikle farklı ekip üyeleri (yazılım mühendisi  - test mühendisi - kalite uzmanı - müşteri temsilcisi) tarafından farklı anlaşılabilmektedir.

Bu nedenle, özellikle gereksinim analizinin hemen ardından, müşteri tensilcilerinin de katılımıyla, (özellikle sistem seviyesi) hangi gereksinimde tam olarak neyin amaçlandığının net bir şekilde tüm ilgili ekip üyeleri tarafından anlaşılması çok önemlidir.

Bu amaçla yapılan toplantıların adı Gereksinim Anlaşılırlık Toplantısı veya Gereksinimleri Anlama Toplantısı'dır.

Test Mühendisliğinde Hangi Dokümanlar Üretilir, Amaçları Nedir

Kimi standartlarda ek olarak birkaç başka doküman olsa da, tüm standartlar ve metodolojiler tarafından istenen test dokümanları şunlardır:

• Sistem Test Planı (STP)
• Sistem seviyesinde, tüm alt-bileşenleri ve donanımları göz önüne alarak sistem seviyesi gereksinimlerin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı dokümandır.

• Sistem Test Tanımları (STT)
• STP'de belirlenen testlerin, detaylı test adımlarının yazıldığı dokümandır.

• Sistem Entegrasyon Doğrulama Planı (SEDP)
• Sistem Altsistem Tasarım Tanımları ve Arayüz Gereksinimleri Tanımları dokümanlarında belirtilen arayüz gereksinimlerinin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı  ve sistemi oluşturan modüllerin hangi sıra ile entegre edileceğinin belirtildiği dokümandır.

• Sistem Entegrasyon Test Tanımları (SETT)
• SEDP'de belirtilen testlerin detaylı test adımlarının yazıldığı dokümandır.

• Yazılım Test Plan(lar)ı (YTP)
• Yazılım seviyesi gereksinimlerin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı dokümandır.
• Her bir alt-sistem (modül) için ayrı bir yazılım test planı hazırlanabileceği gibi, kimi projelerde tek bir tane YTP de hazırlanabilir.

• Yazılım Test Tanımları (YTT)
• YTP'de belirlenen testlerin detaylı test adımlarının yazıldığı dokümandır.

• Test Raporu (Sistem / Sistem Entegrasyon / Yazılım) (STR - SETR - YTR)
• Kurulum aşamasından başlayarak hangi işlemlerin yapıldığı, hangi testlerin koşturulduğu, hangi hataların çıktığının belirtildiği dokümandır.

Ek olarak projenin doğasına göre aşağıdaki dokümanlar da hazırlanabilir:

• Test Mühendisliği Ana Planı
• Yazılım Doğrulama ve Geçerleme Planı
• Kabul Testi Tanımları
• Test Araçları / Simülatör Geliştirme ve Doğrulama Dokümanı
• Birim ve Birim Entegrasyon Test Tanımları

Test Hazırlık Gözden Geçirme: Neden Yapılır

Özellikle kabul testleri öncesinde, testlere başlayıp başlamama kararının verildiği toplantıdır.

Bazı şirketlerde dahili testler öncesinde de bu tarz toplantılar yapılabilir.

Bu toplantılarda incelenen ana durumlar şunlardır:

• Test edilecek ürünün test dokümanları tamamlandı, gözden geçirildi ve bu dokümanlar kullanılarak en az bir kere baştan sona test yapıldı mı,

• Gereksinim, tasarım ve/veya toplantı tutanaklarına işlenmiş maddeler ilgili dokümanlara yansıtıldı mı ve test dokümanları bunlara göre güncellendi mi,

• Önceki testlerde çıkan hatalar düzeltildi mi,
• Şirket içinde yapılan bu testlerde çıkan toplam hata sayısı genelde müşteriye söylenmez, söylenmesi de gereksizdir,

• Testlerde bulunan fakat düzeltilememiş hatalar var mı,
• Bunu belirtmek özellikle gereklidir. Çünkü halihazırda, sistemde var olduğunu bildiğiniz bir hata varsa fakat bunu müşteriye önceden söylemezseniz, kabul testi sırasında bu hatanın ortaya çıkması kabule engel bir duruma sebep olabilir.
• Bilinen fakat henüz düzeltilememiş hatalarla teste başlayıp başlamama kararı, müşteri ile birlikte verilir.

• Test ortamı kurulumu yapıldı mı ve test ortamı izole edildi mi,
• Bazı projelerde müşteri, test ortamının tamamen baştan kurulması sürecini de görmek isteyebilir.

• Testlerin süresi,

• Test öncesinde müşteriye oryantasyonun nasıl ve nerede verileceği.

Proje ihtiyaçlarına göre bu listeye eklemeler de yapılır.

Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir

Gerek kamu gerekse özel sektöre yapılıyor olsun, yazılım projeleri bir nihai kabul makamı için geliştirilir. Yani bu projenin bütçesini oluşturan ve ödeme yapacak bir makam için geliştirilir.

Bu makamın görevlendirdiği ekip tarafından bir sözleşme hazırlanır, ihale süreci başlatılır ve bu sözleşmeyi karşılayacak sistem / yazılımı geliştirmeye tâlip şirketler ile görüşüldükten sonra sözleşme nihai haline gelir.

İhale sürecinin sonunda ihaleyi kazanan şirket, sözleşme isteklerine göre ürünü geliştirdikten ve dahili testlerini yaptıktan sonra, müşteri, müşteri temsilcisi ve/veya danışmanlık / müşavir firma katılımı ile, geliştirilen ürünün sözleşme isterleri ile uyumluğunun doğrulandığı kabul testi yapılır.

Kabul testi için, doğrudan sözleşme isterlerini doğrulayan bir Kabul Test Dokümanı kullanılabileceği gibi, müşteri onayı alınması durumunda, Sistem Test Dokümanı da kullanılabilir.

Bu aşamada dikkat edilmesi gerekenler:

• Kabul testinde kullanılacak test dokümanının, sözleşme isterlerinin tamamını test ettiğinden emin olunmalıdır,
• Test öncesinde, hatta Test Hazırlık Gözden Geçirme toplantısı öncesinde, müşteri temsilcileri ile ayrı bir toplantı yapıp, test dokümanının detayları, sözleşme maddelerinin hangi testlerle nasıl karşılandığı sunulmalıdır. Böylece, müşteri temsilcileri test dokümanına hâkim olacak, olası eksikler erken aşamada ortaya çıkmış olacak, müşterinin istediği ek testler varsa test dokümanına eklenebilecek ve müşteri temsilcileri sözleşmenin her maddesinin testten geçtiğini göreceği için içleri rahat olacaktır.
• Bu aşamada, testler öncesinde senaryo akışı anlatılmalı ve üzerinden mutabık kalınmalıdır.
• Kabul testine gelen kabul heyetinin (müşteri temsilcileri) asıl işlerinin yazılım geliştirme olmadığını düşünürsek, yazılacak test adımlarının yeterince açıklayıcı olması, test ettiği isterin ne olduğu açık olarak belirtilmelidir.

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.