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.