Skip to content

Yazılımlarınız Türkiye Testini Geçiyor mu?

Aranızda Stackoverflow‘u duymayan var mıdır? Stackoverflow, Joel Spolsky ve Jeff Atwood‘un programcılara özel bir soru-cevap sitesi yapma fikirleriyle doğan ve günümüzde programlama ile ilgili temel kaynaklardan biri olarak gösterilen bir oluşum. Ayrıca ikili sitenin tüm hayat çizgisini 87 bölümlük bir podcast serisi ile yayımladılar, dinleyin, harcadığınız 87 saate değecektir.

Stackoverflow podcast’inin 50. bölümünde Joel şöyle bir laf ediyor (Çeviri bana aittir, hatalarım için şimdiden özür dilerim);

Türkçe Testi

Düşünüyorum da, Microsoft’ta bir programcı kod yazdığında, bu kod devasa bir fabrikaya yollanıyor ve [bu yapı hakkında] hiç bir fikriniz yok. Ve [yazılan bu kodun] milyonlarca kopyası var ve milyonlarca değişik dilde [işletiliyor] ve bir bakıyorsunuz kodunuz Türk dilinde çalışıyor.

Ve bir gün birileri Türkçe karakter setinin kurallarına aykırı olarak İngilizce I harfini büyük yaptığınız zaman üzerindeki noktasının kaybolduğu ile ilgili şikayet ediyor ve siz de “Ne? Benim kodun Türk dilinde mi çalışıyor?” diye kalıyorsunuz.

Joel’in dünyada konuşulan onca dil içerisinden bu örneklemeyi Türkçe ile vermesinin aslında çok geçerli bir sebebi var. Türk dili uluslararasılaştırma ile uğraşanların çok sık üzerine konuştukları bir dil. Hatta uluslararasılaştırma konularının konuşulduğu koridorlarda Türkiye Testi‘nden bahsedildiğini söylesem şaşırır mıydınız? (DEVAM EDIYOR)

TESTURK ile Yola Devam

Uzunca bir aradan sonra tekrar merhabalar. Yakın dostlar yine “Bildiğimizi anlatma bize” diyecekler ama diğer okurlar için gelsin; Hollanda’ya taşınmamı takiben bir yıl içerisinde QualiTest’teki tüm görevlerimden ayrılıp Hollanda Polisi’nde yine yazılım kalitesi alanında bir danışmanlık pozisyonunu kabul ettim.

TESTURK LOGO

Malum sebeplerden dolayı ne çalıştığım kurum ile ilgili bilgi verebildim, nede burada günlük deneyimlerimi sizlerle paylaşabildim.

Uzunca bir aranın ardından bu yıl başında memleketime kesin dönüş yaptım ve çalışmalara tam gaz başladık.

Türkiye’de hepimizin belini büken servis tabanlı yazılım geliştirme alışkanlıklarından, tüm dünyaya yazılım satabilir hale gelebilmemiz için ürün temelli bir yazılım geliştirme kültürüne geçmemiz gerektiğini idrak ettik.

Bu sebeple ismi Türk ve yegane amacı da Türkiye olan TesTürk isimli test hizmetleri ve danışmanlık firmasını kurmak için kolları sıvadık.

TesTürk ile yapmak istediklerimizin hepsini keşke buradan paylaşabilsem. Kesinleşmemiş parçaları olan hedeflerimizde yaşanabilecek aksilikleri göz önünde bulundurup Türk filmlerindeki “Umut Taciri” karakterlerden birisine dönüşmek istemem. Lakin bir nevi tadımlık olarak şunu sizinle paylaşabilirim; Çok yakında James Bach’ın makalelerini kendi ana dilinizde okuyor olursanız sakın şaşırmayın!

Bu arada artık İstanbul’da olduğumu hatırlatmak isterim. Yazılım kalitesi ve test mühendisliği ile ilgili çene çalmak isteyen herkes bana +90 212 318 90 63 numaralı ofis telefonumdan yada doğrudan Swiss Offices 10, Maya Akar Center 100-102 C Blok No:4 Esentepe adresine bizzat gelip bana ulaşabilirler. Gelmeden bir gün evvel benimle irtibata geçerseniz de süprizler olmadan oturup sohbet edebiliriz.

Şimdilik müsadenizi isterken yazılarımla artık burada olacağımı da hatırlatayım.

Herkese İyi Testler!

Test Mühendisliği Kariyeri ve Aranan Nitelikler

Aralıklarla bazı okurlar, yazılım test mühendisliği konusunda kariyer yapmak istediklerini belirten e-posta mesajları gönderiyorlar. Ne yalan söyleyeyim, yazılım testi konusunda insanların ilgili olmaları çok hoşuma gidiyor.Gönderilen e-posta mesajlarını ayrıca yanıtlama hakkımı saklı tutarak, bu konuda konuşma, dertleşme fırsatı bulamadığımız okurlar için bugün bu konuda yanıtlamaya çalıştığım bir e-posta mesajını -burada yayınlamak amacıyla düzenleyerek- sizlerle paylaşmak istiyorum.E-posta mesajını gönderdiğim arkadaşa danışma fırsatı bulamadığım için ismini yada bana gönderdiği mesajı sizlerle paylaşamıyorum.Eğer uygun görürlerse kendileri aşağıdaki yorumlar bölümünde kendisini tanıtabilir ve konu ile ilgili aldığı diğer fikirleri de bizlerle paylaşabilir. Lafı uzatmayalım, yolladığım e-posta mesajı aşağıdadır.

Öncelikle e-posta mesajınız için teşekkür ederim. Elimden geldiğince sizlere konu hakkındaki fikirlerimi bildirmek isterim lakin farklı kaynaklardan da bu konuda tavsiyeler almanızın sizin açınızdan iyi olacağı kanaatindeyim.

Developen’ı takip ediyorsanız, yazılım kalitesi ve test mühendisliği konularındaki fikirlerimin hayli idealist ve biraz da sektörümüzün mevcut durumuna tepki olarak militanca olduğunu görmüşsünüzdür. Bu sebeple benim tavsiyelerimin daha küçük bir alt kümesi de günümüz Türkiye yazlım sektöründe yeterli olarak görülebilmektedir.

Yazılım test işinde olup doğruların kişiye, zamana ve şartlara göre değişmediğini kavramamak mümkün değildir. Ben size kendi fikirlerimi iletmek istiyorum, sonuçta karar sizin olacaktır.

Test mühendisliğini ben disiplinler arası bir alan olarak görmekteyim. Gerçeklediğimiz aktiviteleri de “farkındalığın denetimi” olarak gördüğümü defalarca yazdım. Bu sebeple salt yazılım test tasarım/işletme tekniklerine hakimiyet ile iyi test yapılabileceğine inanmıyorum. (DEVAM EDIYOR)

Yazılım geliştirmenin anatomisi

Emrah Olgun, çok sevdiğim dostum, telefonda son konuşmamızda beni şaşırtınca, telefonu kapadıktan sonra uzun uzun Techinox Yazılım’ı kurduğumuz zamanları düşündüm. Uzun saçlı*, ayakları yere basmayan ama yeni medya, yazılım ve yazılım üretimi üzerine çok net fikirleri olan gençlerdik.

Ofisimizi kurup oturduğumuzda ilk yaptığımız neydi biliyor musunuz? Bir uygulama çatısı geliştirmek!

Mathilda 1.0 böyle bir atmosfer içerisinde doğdu. Çocukluk ve ergenlik dönemini bitirdiğinde kendi üzerindeki kod üreticileri ile veri tabanı erişimimizden tüm CRUD** ekranlarına, kullanıcı/erişim yönetiminden loglamaya birçok işimizi hallediyordu.

3770015203_9cb9aa2188Bir süre sonra artık kaynak kodunun %80’i Mathilda tarafından bizim için üretilmiş projelerimiz vardı! Bu sayede, biz kullanıcı arabirimi ve iş süreçlerine daha fazla odaklanabiliyorduk. O günün proje bütçelerinde rakiplerimiz projelerinde doğru düzgün HTML yazmaya kaynak bulamazken, kaynak kodunun üçte biri JavaScript, web tabanlı yazılımlar ürettiğimizi bilirim. Bugün için bu rakamlar alelade görünse de bütün bunlar olurken AJAX’ın henüz ismi olmadığını düşünürseniz durumun ciddiyeti daha net anlaşılır sanıyorum.

Geçen birkaç yılda her doğru kararı verdiğimizi düşündüğümüz ama sonunda tökezlediğimizde, aldığımız dersi Mathilda’ya ekledik. Yazılımlarımızı test ederken yada bir şekilde üretim ortamına kaçmış belki binlerce yazılım hatasını Mathilda üzerinde düzelttik yada engelledik.

Birçok tahminimizde yanılıp, çoğu kararlarımızı yanlış alırken yaptığımız tek doğru belki de, nasıl bir uygulama çatısına ihtiyacımız olduğunu öğrenmek ve öğrendiklerimizi Mathilda’ya geri kazandırmak olmuştur.

(DEVAM EDIYOR)

Test araçları piyasasında neler oluyor?

20 yıl önce, 274658790_3474c1f724 1989 yılında start verilen Mercury Interactive , 10-15 sene gibi bir süre içinde WinRunner, Test Director ve QuickTest Professional gibi çözümleri ile kurumsal dünyanın kalbini çaldı ve bu efsanevi ürünleriyle kısa süre içinde milyar dolarlık bir deve dönüştü.

Bugüne kıyasla, Mercury işe başladığında, test aracı geliştirmek çok daha zordu. Test edilebilirlik hiçbir teknolojinin odağında değildi ve dolayısıyla her teknoloji üzerinde test için teker teker geliştirme yapmak gerekiyordu. Bu sebeple piyasada gelişmiş test otomasyonu ve yük testi araçları sınırlıydı.

Böyle bir ortamda Mercury, geniş yelpazede desteklediği teknolojiler ve kolay kullanıcı arabirimiyle kısacık zamanda piyasanın %80’ine yakınını elde etti. Böylesi dar bir sektörde Mercury’nin başı boş bırakılmayacağı belliydi. Biz IBM yada Microsoft’u beklerken 2006 yılında HP’nin Mercury’yi 4.6 milyar dolara alması, piyasanın fitilini yaktı.

Geliştirilmesi, pazar payları ile kıyaslandığında maliyetli olan test otomasyonu ve yük testi araçları, teknolojinin imkanlarının artmasıyla daha fazla firmanın beceri alanına giriverdi. Milenyumun başından beri yılda %30 büyüyen test araçları pazarı ağızları sulandırırken, yem de böyle lezzetli olunca, balıkların oltaya vurması fazla zaman almadı.

(DEVAM EDIYOR)

Yazılım üretimi bilimsel mi?

Tanıyanlar bilir, ben de yazılım üretiminin öyle sınıflarda öğretilebileceğine inanmayanlardanım. Her ne kadar yazılım üretmek için belirli teorik bilginin gerekliliği yadsınamaz olsa da asıl yazılım üretimi aktiviteleri ve düşünsel süreçleri, programcının çıraklık döneminde edindiği becerilere daha yakın bence. 1806829922_eebeb74c6f

Glenford J. Myers 1979′da ünlü kitabı The Art of Software Testing‘de yazılım testini "bir yazılımı ya da sistemi hataları bulmak amacıyla işletmek" olarak tanımlamıştı. Geçen 30 senede bu tanımın yanına yüzlerce yenisinin konmasının haricinde, yapısal olarak belki de fazladan ilave edebildiğimiz tek katma değer, statik testlerin yazılım testi terminolojisine eklenmesi oldu -ki bunu da icat etmedik, uygulamaya başladık.

Örneğin, test mühendisinin öngörülerinin, hislerinin ve farkındalığının formal test yöntemlerinin ve sistemlerinin daha önünde bir öneme sahip olmasını nasıl açıklayabiliriz? Yanılıyor isem eğer, bilgi ve beceri seviyesi sertifika programları ile ölçülen sözde testçilerin acziyetini görmezden gelmemiz gerekecektir.

(DEVAM EDIYOR)

Hafıza Sızıntısı* (Memory Leak) nasıl saptanır

Aşağıdaki adreste Sam Allen çeşitli tarayıcıların hafıza kullanımları ile ilgili güzel bir çalışma yapmış.safari-memory-usage

http://dotnetperls.com/Content/Browser-Memory.aspx

Makale içerisindeki grafikler ve anlatım, test altındaki uygulamaları uzun süre kullanıp hafıza kullanımlarını incelediğimizde mutlak hafıza sızıntılarını nasıl saptayabileceğimize mükemmel bir örnek sunuyor.

Makaledeki su götürmez hafıza sızıntılarını bir kenara bırakırsak, özellikle modern yazılım platformlarında gördüğümüz Garbage Collector’ların (GC), tembel programcılara neler yaptırabileceklerine bir bakalım.

GC’lerin keşfi babalarımızın çocukluğuna denk gelse de, popüler programcılık dünyasına seslerinin duyulması, bizlerin doğumundan hayli sonralara tekabul ediyor. 1972 yılında eli yüzü şekillenen bir C programlama dilini, 1983′leri bulan C++’yı ve bu platformların popülerliğini düşünürsek, GC sektörde hayli yeni bir kavram diyebiliriz. Belki de bu denli öne çıkmasını nesneye yönelik programlamanın ve hafıza dertsiz programlamanın popülerleşmesine de bağlayabiliriz, ve sanırım bağlarken de yanılmayız.

(DEVAM EDIYOR)

Borland Maceraları : Perde II

Hafta sonu sistem yöneticilerimiz Windows 113178808_fb3f0b27e6 tabanlı sunucuların tümüne bir güncelleme paketi yollamışlar. Bu güncellemelerden biri de henüz düzeltilmemiş PDF JavaScript açığını engellemek üzere tarayıcılardaki ve Adobe Acrobat Reader’da JavaScript desteğini kaldırmış. Açıkcası bildirim de gelmedi değil ama ben de herkes kadar okuyorum bu bildirimleri. Uzatmadan anlatalım;

Biz de bu arada Borland’ın test yönetim yazılımı Silk Central Test Manager yazılımının son sürümünü kurmak ile meşgulüz. Tahmin edebileceğiniz gibi konfigürasyonu da sunucu üzerindeki tarayıcı üzerinden yapmaya çabalamaktayız.

(DEVAM EDIYOR)

Bilgiden para kazanmak: Bir Borland Deneyimi

Bir süre önce, projelerimizden birinde kullandığımız Silk Cenral Test Manager uygulaması ile ilgili garip davranışlar görmeye başladık. Örneğin olur olmadık zamanlarda uygulama sunucusu yazılımı (AppServ) donup kalıyor ve gerek web kullanıcılarına, gerekse de takvimlenmiş otomatik testlere sistem yanıt veremiyordu.422064493_3b1579a512

Malımızı bilsek de disiplini elden bırakmayarak sırasıyla uygulama sunucusu, veri tabanı katmanı, test çiftliği iletişimi (ExecServ yada Silk Central SilkTest entegrasyon noktaları) ile ilgili profil çıkardık. Sonunda farkettik ki SilkTest yüklü istemci sunucu ile bağlantısı kopup yeniden bağlanmaya kalkığında sunucu 100MB’a yakın ek bir hafızaya ihtiyaç duyuyordu.

Anlaşılan münferit kopmalar sorun yaratmıyordu lakin bir şekilde bizim sahip olduğumuz 35 SilkTest yüklü cihaz bir şekilde toptan gidip geldiğinde sunucumuz buna dayanamıyordu.

Yapılacak basitti, JVM Heap Size’ı yükseltmek. Windows Registry’de Silk Central’in alışık olduğumuz kayıtlarında -Xms değerini 512′den 1024′e çıkardık ve artık kısa vadeli bir çözümümüz vardı.

Daha sonra bu sıkıntının sebebini araştırdığımızda sunucumuzun önündeki ağ aygıtlarından birinde bir düzensizlik farkettik. Görünen oydu ki cihazdaki düzensizlik, bağlantının ender de olsa kopmasına sebep oluyordu.

(DEVAM EDIYOR)

Test Mühendisliği Müthiştir!

Yakın tanıdıklarım bilir, aslında yazılım testi benim çalışma hayatımdaki ilk uğraşım değil. Hayatımı daha önce, yine yazılım sektöründe ama geliştirici ekiplerde farklı görevlerde çalışarak idame ettirmekteydim. Her ne kadar sektörümüzde daha çok aksini görsek de, ilerleyen zamanlarda biraz şansımın yardımı, biraz da yazılıma bakış açımın değişmesi neticesinde, yazılım üretiminin kalite güvencesi ve test alanına odaklandım.

Yazılım kalitesi ile ilgili çalışmaya başladıktan sonra ilgi alanlarım ile ilgili aniden birçok değişiklik olmaya başladı. Öncelikle sosyal bilimler ile ilgili karşı konulmaz bir merak ile başlayan bu değişim beni felsefe, psikoloji, sosyoloji gibi daha önce hiç ilgilenmediğim disiplinlerle haşır neşir olmaya, etrafımda olup bitenlere bilimsel bir kuşkuculuk ile yaklaştırmaya başladı.

Bir süre sonra artık nüfus cüzdanımı yeniletmeye gittiğim nüfus idaresinin nasıl daha verimli olabileceği yada basit geometrik şekillere sahip GUI nesnelerinin neden daha kolay algılanabildiği üzerine düşünür buldum kendimi. Yazılım geliştirirken böylesine konular gündemimde nedense hiç olmazdı.dead end

Monitör başında sabahladığımız geceler geldi aklıma. Hafta başına yetişmesi gereken onlarca yeni fonksiyonun adım adım, sabırları zorlayan bir tekrarlılıkta karşımıza çıkan paternlerini algılayıp refleks ile kodlamaya başladığımız ekranlar, sorgular yada o anlamsız CSS düzenleme rutinleri… Bitmeyen ve kendini tekrarlayan bir klavye emekçiliği ile geçen günler ve geceler. Sonuçta kimsenin aslında memnun olmadığı, ama iş ve teknik gereksinimleri karşılayan birçok ürün gelip geçti ellerimizden.

Şimdi ise proje ekiplerinde test mühendisi olarak çalışıyorum ve çok daha mutluyum. Mutluyum, çünkü değişimin bir parçası olma şansım var artık. Öncelikle geliştirici olarak "teknik problemler kümesi" olarak gördüğüm yazılım geliştirme işinin aslında teknik değil, iş ve insan odaklı olduğunu görebildim örneğin.

Yazılımları test etmek, kod yazmaktan daha güzeldir. Daha sosyalsinizdir herşeyden önce. Teknik insanlarla konuşursunuz, son kullanıcılarla da.. Sistemi eş zamanlı olarak gereksinim-mimari-kaynak kod olarak görüp bu yapının her noktasında da görev alırsınız. Gerektiğinde öylesine teknik bir iştir ki elinizde RFC’ler bir parça Ada95 kodunu devşirmeye çalışırsınız, yeri gelir pazarlama ekibi ile ürünün gelecek dönemde öne çıkarılacak fonksiyonlarını tartışırsınız.

Programcılık eğer sabah 8 akşam 5 saatleri arasında gittiğiniz ve görevinizin VB6 ile geliştirilmiş bir sigortacılık yazılımını sürdürmek ise, Test Mühendisliği evde oturup Lisp derleyicisi yazmak gibidir. Merakınız ve öğrenme güdünüz tarafından beslenen yazılım testi, geliştirdiğiniz disiplin ve sistematik yaklaşım teknikleri ile bilenir, yeşerir.

Her ne kadar Hollanda gibi iş dünyasının sınırları kalın çizilmiş bir yerde çalışıyor olsam da, böylesine durağan iş yapma biçimleri olan bir kültürde hala yaptığım işi bu kadar seviyorsam, test mühendisliğinin eğlenceli yanının ve çok yönlülüğünün yadsınamaz bir etkisi olmalı.

İyi Testler!