yazılım testi

Merhaba,

Bu günlerde, çalıştığım "Mobikom Telecommunications and Software Ltd" adlı şirkette test ve destek konusundaki eksiklerin giderilmesi için beni ve diğer bir yeni mezun arkadaşımız olan Burak'ı önemli ölçüde sorumluluk sahibi yaptılar. Test ve destek sisteminin oturtulması, gerekli dokümanın hazırlanması, prosedürlerin ve standartların belirlenmesi, testlerin tüm bu standartlara göre ayrıntıyla ve özenle yapılması son olarak her şey artık rayına oturunca (Haziran'a oturması gerekiyor) gerekli eleman alımının yapılması konusunda görevliyiz. Bu bağlamda hiç tecrübem olmayan test konusuna dün bir giriş yaptım. Testin ne olduğu konusunda öğrendiklerimi sizinle de paylaşayım.

Anladığım kadarıyla test bir ürünün (yazılım olabilir) kalitesinin artırılmasını sağlamak için olası her hangi bir hatanın tespit edilmesini sağlamak işidir. Test işlemi bir ürünün her durumda çalışacacağını garanti etmekten ziyade her hangi bir durumda çalışmayabileceğini tespit etmektir. Fonksiyonel ve fonksiyonel olmayan olarak iki gurupta incelenebilir. Fonksiyonel testler yazılımın amaçlandığı işi yapıp yapamadığını test ederler ve kullnıcı için hangi senaryoların uygun olduğunu belirlerler. Fonksiyonel olmayan testler yazılımın ölçülürlük ve güvenlik açıkları gibi herhangi özel fonksiyonel veya kullanıcı kaynaklı olmayan sorunlarını tespit etmeye yöneliktir. Örneğin bir öğrenci kayıt sistemine aynı zaman diliminde maksimum kaç öğrencinin oturum açabileceği ve işlem yapabileceği...

Potansiyel hata (error, mistake) ve gerçekleşmiş olan hata (failure, fault) olarak çavirebileceğimi düşündüğüm bir ayrım vardır. Programcının yazdığı kodda var olan hatalar uygun koşullar oluştuğunda ortaya çıkarlar ve programın istenmeyen bir şekilde sonlamasına daha da kötüsü belki de hataya rağmen yanlış çalışmasına sebep olabilirler. Bir yazılımın girdi verisine, çalıştığı işletim sistemine, donanıma, kullanıcının etkilerine, performans ve kaynak kullanımı kriterlerine sıkıca bağlı olduğunu düşününce ortaya çıkması muhtemel hataların sayısı en küçük yazılımlarda bile oldukça fazla ve bir okadar tehlikeli olabilir.

Yazlılım testinde en çok izlenen tekniklerden birisi "box tekniğidir". Bu yaklaşımda iki genel test metodu vardır. Black box metodunda testçi yazılımın bitmiş modüllerini test eder ve yazılımın içinde ne olup bittiği onu pek ilgilendirmez. Önemli olan gereksinimlere uygun olan çıktıların sorunsuz elde edilebiliyor olmasıdır. Diğer yöntem "white box" ise yazılımın gerçekleştirimi, veri yapılarının kullanılış biçimi ile daha çok ilgilenir. Kullanılan API lerin test edilmesi, birbirini etkileyen modüllerin test edilmesi, yazlılı olan tüm kod parçalarının en az bir kez çalışması sağlanarak yazılımın test edilmesi bu tür test yönteminin ürünleridir.

Ayrıca genel olarak, yazılımın fonksiyonel amaçlarının sağlanmsından sonra müşteriye iletilmeden önce test projesi olarak ele alınıp test edilmesi ve yazılımın üretilmesi aşamasında bir yandan da gereksinimlere uyup uymadığının her adımda test edilmesi olarak ayrılan yaklaşımlar var. Bu yazılımı üreten kurumların ihtiyaçlarına göre değişen, mühendislerin hangi yolu seçeceklerini elirlemesi gereken bir konu. Daha çok devlet kurumları veya askeri kurumlar için üretilen testler ayrı test projeleri ve ayrı test ekipleri oluşturularak uygulanıyor.

Test yaklaşımları, yöntemleri hakkında binlerce sayfalık teorik ve pratik doküman bulunulabilir. Ben bu yazımda daha bu alana yeni adım attığım için çok yüzeyde kalacağım. Sizlerle sadece öğrendiklerimi paylaşıyorum.

Test süreci çok genel olarak :

1) gereksinim analizini yapmak, geliştirici takımla beraber oturmak
2)test planını oluşturmak
3)testi geliştirmek
4) testi uygulamak
5) rapor oluşturmak : yazlılımın ölçülmesi, sonuçlar vs.
6) testin kapanması ve dokümanların kayıt edilmesi.

adımlarından oluşsa da bu çok değişken ve göreceli bir süreç. Dün izlediğim James Satisfice' ın videosunda testten : "Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid unthinkable happening to the anonymous" olarak bahsediliyor. Bu cümleyi "Yazılımda saklı olan, bizim o an için göremediğimiz ve fakat görmemiz gereken, yoksa başımıza bela olabilecek hatalar vardır ve bunları anonim hale getirmek test işdir" olarak açıklayabiliriz sanırım. 57 dakikalık konuşmasında testin çok ta belli standartlara dayanmadığını, senaryoları iyi incelemenin, yazılımı iyi anlamanın ve içinde olduğumuz durumu tam anlamıyla kavramanın ve elimizdeki problemi çok iyi analiz etmenin gerekli olduğunu çıkardım. Ayrıca web bloglarını okumak, akademik makaleleri okumak ve kendi test yöntemlerini oluşturmak şidetle tavsiye ediliyor. Böylece kendimize uyan ve giderek daha da gelişen bir test anlayışımızın olabileceğinden bahsediliyor. Ayrıca diplomalardan ve alınan sertifikalardan ziyade internette ve iş dünyasında bir şekilde tanınır olabilmenin çok daha yararlı olduğunu düşünüyor sayın James Satisfice. Hatta profesyonel ve geçerliliği tescil edilmiş uluslar arası test kurumunun eğitimlerini ve sertifikalarını, test hakkında yazılmış kitapları bile gereksiz görüyor.

Benden bu kadar. Bir sonraki yazım Oracle' da yedekleme işlemleri ile ilgili olacak sanırım. İyi günler dilerim.