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