developen

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. Öncelikle yazılım yaşam döngüsü konusunda kendinizi pişirmenizi sizlere öneririm. Bu bilgi hangi aktivitelerin hangi sebeplerle gerçeklendiğini kavramanıza ve üretim sürecinde karşılaşabileceğiniz sıkıntıları öngörmenize yardımcı olacaktır.

Test mühendisi, yazılım üzerinde bulduğu beklenmedik durumları ekip arkadaşlarıyla paylaşırken ciddi miktarda empati kurma becerilerine sahip olmalıdır. Bu, bulgularınızı paylaşımda “anlatabilmenizi”, kurulan geliştirme ekibinin gerçeklerini kavrayarak mevcut riskleri “anlayabilmenizi” kolaylaştıracaktır.

Yazılım yaşam döngüsünü anlamak demek yazılımın yanında yazılım geliştirenleri de anlamak demektir.

Konuya hakimiyetiniz arttığında ekibin kalanı ile aynı dili konuşmanın yanında müşteri isterlerinin dokümante edilip edilmemesinin final ürünün kalitesinde ne gibi sonuçları olduğunu öngörebilir ve buna karşı test süreçlerinde önlemler alabilirsiniz.

Bunun yanında eğer ki bir de daha evvelden yazılım geliştirdi iseniz, teknik olarak da geliştirilen yazılım ile daha net bir görüşe sahip olursunuz. Bu sebeple birkaç popüler yazılım geliştirme teknolojisine (Java, C# ilk aklıma gelenler) ve gündelik işlerinizi otomatikleştirebilecek kadar betik dillere (Ör: Ruby, Python ve Perl) hakimseniz, hem iş hayatınızı kolaylaştırabilir, hem geliştirilen yazılımın sahip olduğu riskleri öngörebilir, hem de terminolojimiz dahilindeki bazı hata kaynaklarını tam olarak kavrayabilirsiniz.

Misal, çok işlemli bir mimaride (İng. multi-threaded) zamanlama hataları ile ilgili (thread timing issues) okuyabilir, bu noktada elinize verilen riskler ile ilgili çok güzel test aktiviteleri gerçekleyebilirsiniz.

Lakin eğer bu tip uygulamalar ile haşır neşir olduysanız, “Bu özellik yazılıma uygulanırken çok işlemlilik zaruridir” gibi bir yargıya varma şansınız olacaktır. Bu bazı bilgilerin sizlere sağlanmaması durumunda sistemin kendisinden bu bilgileri edinebilmeniz demektir.

Benim kanaatim bu becerinin içinde bulunduğunuz ekibe çok şeyler kattığı yönündedir.

Örneğin bu deneyime sahip bir test mühendisi sadece asenkron AJAX tabanlı Web uygulamalarında — ki günümüzde çoğu böyledir — zamanlama risklerine yönelik aksiyon alacaktır. Böyle test mühendisleri olmasaydı, GMail gibi araçları bugün kullanıyor olamazdık.

Kodlama deneyimi bunun yanında test otomasyonu ve yük testleri gibi bizlerin “teknik test aktivitesi” olarak adlandırdığımız alanlarda da boy gösterebilmenize imkan tanıyacaktır. Zira test otomasyonu ve yük testi genel olarak kendi başlarına yazılım geliştirme aktiviteleri olarak tanımlanırlar.

Bunun üzerine önemli bir nokta olarak ISEB/ISTQB gibi kuruluşların derleyip birçok dile de çevirdiği eğitim içeriklerini de kavrar ve uygulama deneyimi elde ederseniz test mühendisliği yönünde büyük bir adım atmış olursunuz diye düşünüyorum.

Zaruri olmamakla beraber ISEB/ISTQB gibi kurumların sertifikasyon programları, bu alandaki eğitim için sizlere formal bir yapı sunacaktır. Söz konusu eğitimler test süreçleri, test tasarım teknikleri vb. temel konularda sizleri test mühendisliği terminolojisi ile buluşturacaktır.

İlgili içerikleri kurumların web sitelerinden de indirebilir yada kurumlara başvurarak eğitim ve sertifikasyon konularında hizmet alabilirsiniz.

Ek olarak alanımız ile ilgili Lee Copeland’in yazmış olduğu “A Practitioner’s Guide to Software Test Design” ve Cem Kaner ve James Bach’ın beraber yazdığı “Lessons Learned in Software Testing” isimli kitapları da şiddetle tavsiye ederim.

Yukarıda sıraladıklarım işin “bilmek” noktasında benim gereksinim olarak gördüğüm şeylerdir. Bunun yanında işin “anlamak” noktasında ise sizi acilen Psikoloji, Felsefe (Özellikle Epistemoloji) ve Sistem Mühendisliği konularında kendinizi yetiştirmeye davet ediyorum.

Bu alanlar her ne kadar “sözel” ve “uzak” alanlar gibi görünse de test mühendisliği kariyerinizde “söyleneneni yapmak” ile “mesleğinize katkı sağlamak” arasındaki farkı belirlemektedirler.

Değerli Bilgisayar Bilimleri uzmanı Knuth’un özlemini belirttiği gibi (http://www.paulgraham.com/knuth.html) sanat olarak ilerleyen yazılım üretimi yavaş yavaş bilim olma yolunda ilerlemekte. Lakin henüz yazılım üretmeyi tam olarak öğrenemediğimiz bu dünyada test mühendisi olarak çalışırken -ne yazık ki- kendinizi sık sık savaş alanında kılıcı elinden düşmüş bir savaşçı gibi hissedeceksiniz.

Çoğu zaman çeşitli sebeplerle “Doğru” ‘nun ekseni kayarken yazılımların kalitesine yönelik yargılarda bulunmanız beklenecek. Böyle zamanlarda yukarıda saydıklarımın hiçbiri işinize yaramıyor olacak.

İşte bu zamanlarda sistemleri, insanları ve doğru bilginin ne olduğunu kavrayabilmek “farkındalığı denetlerken” elinizdeki tek silah olacaktır.

Çok uzun ve zorlu bir yola girmeye niyetlendiğinizi belirtmeliyim. Umarım bu süreç sonucunda mesleğinizde muvaffak olur, bizlere de saygı duyduğumuz ve işini layıkıyla yerine getiren bir meslektaş kazandırırsınız.

Bu yolda tökezlediğiniz, vazgeçmek üzere olduğunuz her anda elimden geldiğince yanınızda

olacağımı ve hiç çekinmeden benimle her konuda irtibata geçebileceğinizi de belirtmek isterim.Son olarak da, Test Mühendisliği ile ilgilendiğiniz için öncelikle kendi adıma, sonra da bu işi memleketimizde layıkıyla yapan bir avuç insan adına sizlere teşekkür ederim.

Bu arada Turkish Testing Board, 2010 yılının Mayıs ayında İstanbul’da bir Test Konferansı tertip etmişler. Konferansın ismi Test İstanbul olarak belirlenmiş.Her ne kadar organizasyonun adına binaen, testistanbul.org alan adını sevemesem ve 5 ay kala bile belli olmayan program nedeniyle tereddütlerim olsa da bu konferansları düzenleye düzenleye daha iyiye gideceğimizi düşünüyorum.Böyle bir ilke adım atan Turkish Testing Board’u da buradan bu vesile ile tebrik edelim.Söz vermemekle beraber, eğer konferans sırasında Türkiye’de olabilecek isem, 6-7 Mayıs tarihlerinde Dedeman Hotel’de görüşmek üzere de diyelim.İyi Testler!