Test, Yazılım Geliştirmenin Mühendislik Zorluğudur

Geliştiriciler, aile üyelerine, eşlere ve diğer teknik olmayanlara ne yaptıklarını açıklamaya çalışırken işkence görmüş metaforları kullanmayı severler. Sıklıkla köprü inşasına ve diğer "zor" mühendislik disiplinlerine başvururuz. Tüm bu metaforlar, onları çok fazla zorlamaya başladığınızda hızla düşüyor. Yazılım geliştirmenin birçok önemli yönden "zor" mühendislik disiplinlerinin çoğu gibi olmadığı ortaya çıktı.

"Zor" mühendislikle karşılaştırıldığında, yazılım geliştirme dünyası, ortak stratejinin bir köprü inşa etmek ve ardından üzerinde ağır bir şey yuvarlamak olduğu zamanki köprü inşaatçılarının bulunduğu yerdedir. Kalırsa, iyi bir köprüydü. Değilse, çizim tahtasına geri dönme zamanı. Son birkaç bin yılda mühendisler, ne yaptığını görmek için inşa etmek zorunda kalmadan yapısal bir çözüm için kullanabilecekleri matematik ve fizik geliştirdiler. Yazılımda böyle bir şeye sahip değiliz ve belki de asla olmayacak çünkü yazılım aslında çok farklı. Yazılım "mühendisliği" ile normal mühendislik arasındaki karşılaştırmanın derinlemesine bir incelemesi için, "Yazılım Tasarımı Nedir?", Jack tarafından yazılmıştır. 1992'de C++ Journal'da yayınlanan Reeves, bir klasiktir. Neredeyse yirmi yıl önce yazılmış olmasına rağmen, yine de dikkate değer ölçüde doğrudur. Bu karşılaştırmada kasvetli bir tablo çizdi, ancak 1992'de eksik olan şey, yazılım için güçlü bir test etme anlayışıydı.

"Zor" şeyleri test etmek zordur çünkü onları test etmek için inşa etmeniz gerekir, bu da sadece ne olacağını görmek için spekülatif yapıyı caydırır. Ancak yazılımdaki yapım süreci gülünç derecede ucuzdur. Bunu yapmayı kolaylaştıran eksiksiz bir araçlar ekosistemi geliştirdik: birim testi, sahte nesneler, test koşum takımları ve daha birçok şey. Diğer mühendisler, bir şeyler inşa etmeyi ve gerçekçi koşullar altında test etmeyi çok isterdi. Yazılım geliştiricileri olarak, yazılımın birincil (ancak tek değil) doğrulama mekanizması olarak testi benimsememiz gerekir. Yazılım için bir tür hesap beklemek yerine, iyi mühendislik uygulamalarını sağlamak için zaten elimizde araçlar var. Bu açıdan bakıldığında, "Test için zamanımız yok" diyen yöneticilere karşı artık mühimmatımız var. Bir köprü inşaatçısı patronundan asla "O bina üzerinde yapısal analiz yapmakla uğraşmayın - son teslim tarihimiz kısıtlı" diye bir şey duymaz. Testin gerçekten de yazılımda tekrarlanabilirlik ve kaliteye giden yol olduğunun kabul edilmesi, geliştiriciler olarak bize, profesyonel olarak sorumsuz olduğu için buna karşı çıkan argümanları geri itmemize izin veriyor.

Yapısal analizin zaman alması gibi, test etme de zaman alır. Her iki faaliyet de nihai ürünün kalitesini garanti eder. Yazılım geliştiricilerin ürettikleri şeyin sorumluluğunu üstlenmelerinin zamanı geldi. Tek başına test etmek yeterli değildir, ancak gereklidir. * Test etme * yazılım geliştirmenin mühendislik titizliğidir.

Neal Ford Tarafından