Sadelik nihai gelişmişliktir.
-Leonardo da Vinci
‘Nasıl yazıyorsunuz?’ diye sorulduğunda, her seferinde ‘tek kelime’ diye cevap veriyorum.
-Stephen King
Seni endişelendiren şey, sana hakim
-John Locke
Taç Takıyorsun Ama Kral değilsin
-Blessthefall’dan bir şarkı
Herhangi bir kuruluşta büyük bir sorun ve parayı çarçur etmenin çok kolay bir yolu, asla kullanılmayacak bir yazılım satın almaktır.
Bu konuyu yazma ihtiyacı hissediyorum çünkü el değmemiş veya çok az kullanılan yazılımlara harcanan milyonlarca dolar yatırım gördüm. Bu ilk bakışta size mantıksız gelebilir ama sizi temin ederim ki birçok test kuruluşu gerekliliği ve getiriyi düşünmeden yazılım satın almaya heveslidir. İnsanlara “Evet, bu aktivite için gerekli yazılıma sahibiz” demek için yazılımı satın alıyorlar.
Konuyu yazılım testi ile daralttığımızda, her şey aşağı yukarı aynıdır. Kuruluşlar, herhangi bir tür test yazılımı satın almak için büyük yatırımlar yaparlar, ancak genellikle kullanımlarını umursamazlar veya yeterince bilmezler. Aynı anda üç test yönetim aracına sahip olduğumu ve hala test senaryolarını yazmak ve sürdürmek için Excel sayfalarını kullandığımı hatırlıyorum. Ne kadar da boş!
Satıcılar ise insanları nasıl çekeceklerini çok iyi biliyorlar. Ürünleri hakkında mükemmel sunumlar hazırlarlar, kavramların kanıtlanması (PoC’ler) için sanal ortamlar yaratırlar ve sizi rahat ve etkileyici hissettirmeye çalışırlar. Elbette bu rahatlık ve iyimser ortam, aletlerin satın alınmasından hemen sonraya kadar sürer!
Genelde büyük eksiklikleri fark eder ve kendi ortamınızla (dahili ağ, güvenlik duvarı, işletim sistemi, sunucular vb.) ilgili sorunları kullanmaya niyetlendikten hemen sonra gözlemlersiniz. Ama neden? PoC’de her şey gerçekten mükemmeldi, ne oldu?
Cevap çok açık: Basit bir sanal deneyime güvendiniz ve aracı kendi ortamınızda denemediniz. Bu kadar! Aşağıda etkili bir PoC için ipuçları verilmiştir; Sanırım hepsi biliniyor ama kesinlikle takip edilmiyor.
- Takım seçim sürecini ciddiye alın
- Probleminizi tanımlayın ve ölçün
- İhtiyaçlarınızı netleştirin ve araç gereksinimlerinizi belgeleyin
- Araçların kullanımında koçluk gereksinimlerini belirleyin
- Bir pilot proje seçin ve gerekli tüm paydaşları dahil edin
- Mümkün olduğu kadar çok aracı deneyimlemeye çalışın; sorun başına bir araç asla yeterli değildir
- Araçları kendi ortamınızda deneyin (ağ, güvenlik duvarı, işletim sistemi, DB’ler, uygulamalar vb.)
- Araçlar arasındaki entegrasyonu kontrol edin (örneğin, Test Yönetim Aracı ve Hata İzleme Aracı)
- Paket ürünleri satın alırken dikkatli olun çünkü paketler daha ucuz seçenekler gibi görünüyor; çoğu zaman kuruluşunuzdaki raf malzemesi miktarını artırırlar
- Yinelenmeyen maliyetleri kontrol edin (knowhow transferi, PoC süreci, ilk satın alma maliyetleri, uyarlama ve gerekli geliştirme/özelleştirme maliyetleri)
- Yinelenen maliyetleri kontrol edin (bakım maliyetleri, destek ücretleri ve sahip olma maliyeti)—bir araç ucuz olabilir, hatta satın almak
- neredeyse bedava olabilir, ancak bakımı gerçekten pahalı olabilir
- Açık kaynak alternatiflerini ve tamamlayıcılarını kontrol edin; her şey için ödeme yapmanız gerekmez
- Gerekenden fazla lisans satın almayın—biraz cimri olun
- Geri dönüş konusunda sabırlı olun; mükemmel kullanım için taahhütte bulunmanız ve fedakarlık yapmanız gerekir – hiçbir şey kendi kendine olmaz
- Bir seferde çok sayıda alet satın almayın; zaman ayırın ve adım adım ilerleyin – unutmayın, doğruluk ve mükemmellik özveri gerektirir
Yukarıdaki listeye eklenebilecek başka pek çok şey var, ancak söylemek istediğim son bir şey, herhangi bir özel yazılım test faaliyetini gerçekleştirmek için gerçekten bir araca ihtiyacınız yoksa, o zaman araçtan uzak durun (örn. ad hoc veya aletsiz). Süslü bir araç satın almak, ihtiyacınız olmadığı sürece sizi asla bir adım daha ileri götürmez. Bunun yerine verimsizlikler ve maliyet aşımları getirerek tam tersiyle sonuçlanabilir.
Şimdi, lütfen araç seçiminin doğru zamanlamasını ele almama izin verin. Tüm seçimlerinizi doğru zamanda yapmanız koşuluyla, yukarıda belirtilen tüm eylemler, doğru aracı seçmenize kesinlikle yardımcı olacaktır.
İkilemi analiz ederek konuyu daha açık hale getirmeme izin verin: araç güdümlü süreçlere karşı süreç güdümlü araçlar. Ne yazık ki birçok kuruluşun (benim çalıştığım kuruluşlar dahil) süreçlerini tanımlamadan önce araçlarını seçmesine şahit oldum. Bu iyi bir yaklaşım değildir, çünkü süreçlerinizi tasarlamalarına ve günlük operasyonel faaliyetlerinizi yönlendirmelerine izin vererek araçlar üzerindeki kontrolü kaybedersiniz. Bunlar sadece araçlar; bunlar sizin stratejileriniz, planlarınız veya kurumsal hedefleriniz değildir, bu yüzden kontrolü onların ele geçirmesine izin vermeyin. Bunun yerine, araçlarınızın hedeflerinize ulaşmanıza yardımcı olmasını sağlarsınız. Bu ancak doğru zamanlama ile mümkündür. Test departmanınızda ortak bir dil belirlemeden ve test süreçlerinizi (örn. politikalar, stratejiler, temel, yaşam döngüsü, çıktılar vb.) tanımlamadan önce herhangi bir araçtan ve hatta PoC’lerden bahsetmemelisiniz.
Aşağıda test yönetim piramidi bulunmaktadır. Kendiniz için bir rehber olarak alıp adım adım ilerleyebilirsiniz. Eğitim, süreçler, organizasyon ve tekniklerle işiniz bittiğinde, son yapı taşı araçlar olacaktır.
