Yazılımda test de neymiş?

Yazılımda test kavramı sadece kelimelerle aşina olduğum bir durumdu ancak daha öncesinde hiç üzerine araştırma yapmamış, hiç bir yerde kullanma ihtiyacı hissetmemiştim – ne salakmışım. Bir sistemi kafanda kurguluyorsun, kağıt üzerinde adım adım her şey çalıştırıyorsun, oturup kodunu yazıyorsun ama sonra canlıya çıkınca bir bakıyorsun patır patır dökülüyor.

Bunun hepimizin öncesinde karşılaştığı bir problem olduğunu düşünüyorum. Kimse yoktur ki “Benim yazdığım kod tek seferde babalar gibi çalışır, kafamda oluşturduğum yapı Nikola Tesla’nın yansılarında oluşturduğu gibi kusursuz çalışır halde olur” diyebilsin. İşte bu problemleri, kodu yazdıktan sonra debug etme süresini, oluşabilecek ekstra senaryoları ve projenin ilerleyen süreçlerinde yapılacak ekleme çıkartmaların yazdığınız koda etkisini görebilmek için test yazmak çok büyük önem arz ediyor. Hele bir de gömülü sistemler gibi yazdığınız kodun çıktılarını görsel olarak alamayabileceğiniz bir alanda çalışıyorsanız bu debug süreci zaten alıyor başını gidiyor.

Yazılım testini gömülü sistemlerde nasıl kullanabiliriz sorusuna cevap aramaya başladığım dönemde bir yazılımın geliştirme süreçleri üzerine de bilgiler edindim. Çünkü normal bir yazılımı test etmek için sadece test methodları yeterli olabilirdi, ancak burada bahsettiğimiz konuda işin içerisine dahil olan bambaşka bir şey daha var: Donanım. Gömülü yazılımlar donanım üzerine koşan yazılımlardır, yani yazdığın sistemin fonksiyonel tarafını soyutlayabilirsiniz, bunun testlerini yapabilirsiniz ancak işin içerisine donanım üzerindeki fonksiyonlar da girince biraz tuhaflaşıyor gibi geliyor insana. Ancak bu konu üzerine de çalışmalar yapılmış tabii ki, bkz: Mock, Stubs, Fakes. James W. Grenning’in “Test Driven Development for Embedded C (Pragmatic Programmers)” kitabını okumanızı şiddetle öneriyorum. Zaten benim de bu işin ucundan tutmama vesile olan kitaptır kendisi. Bu öneri için Burak Kirazlı‘ya teşekkür ederim.

Yaklaşık 3-4 yıldır C dili ile projeler geliştirmeye çalışıyorum. 3 ay kadar denilebilecek bir sürede test yazılımları üzerine çalışmaya başladım ve daha önceden oluşturmuş olduğum basit algoritmaları ve bazı veri yapıları kütüphanelerimi testlerini yazarak yeniden oluşturmaya başladım. Bu süreçte o kullandığım kütüphanelerde yaptığım hataları, eksikleri görme fırsatım oldu. Bana kazandırdığı bakış açısı sayesinde olayı çoklu bir şekilde bakabilmeyi öğrendim diyebilirim. Yavaş yavaş da donanım üzerinde çalışan kısımların testleri nasıl yapılır onlar üzerine kafa yormaya başlıyorum. Ve bu öğrenme sürecimin sonunda ortaya çıkan çıktıları YouTube üzerinde Google Test özelinde anlatmaya çalışıyorum. Bahsettiğim konuların şu an için Unit Test – Birim Testi kapsamında olduğunu da belirtmek istiyorum. Umarım ilerleyen dönemlerde diğer test kavramlarına (Integration Test, System Test, Performance Test vb.) değinme fırsatı bulabilirim.

Bu kavramlarla tanıştığım sırada Nordic Semiconductor firmasının “Senior Software Test Engineer” ilanını görüp “Olmaz ya, yine de şans bu” diyerek başvurumu tamamladım ve bir hafta sonrasında Test Takım Lideri ile 1 saat süren bir görüntülü görüşme yaptık ve sonucunda bir test ödevi verdiler. İşte bu ödevi yapabilme dürtüsüyle giriştiğim araştırmalar sonucunda yaptığım bir şeylerin yanlış olduğunu, bu tekniğin çok daha sistematik bir kod yazmak, dokümantasyon oluşturmak için faydalı olduğunun farkına vardım. Beni bu deneyime iten tecrübe bu buldu, eğer sizi bir şekilde bu yazımla daha geniş bir bakış açısına tetikleyebildiysem ne mutlu bana. Tabii deneyimleyip yararlı veya yararsız olduğuna karar verecek olan yine sizsiniz.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.