Orta Ölçekli Yazılım Firmaları İçin İdeal Bağımsız Dğrulama ve Geçerleme Organizasyn Yaklaşımı Erdem Yıldırım 1, Mehmet Umut Pişken 2 1 STM (Savunma Teknljileri Mühendislik) A.Ş., Yazılım Mühendisi, Ankara 2 STM (Savunma Teknljileri Mühendislik) A.Ş., Kalite Güvence Mühendisi, Ankara eyildirim@stm.cm.tr, mpisken@stm.cm.tr Özet: Yazılım prjelerin test faaliyetlerinin rl bazında gerçekleştirilmesi ve teknik test uzmanlığına sahip lan kişiler tarafından yapılmaması snucunda düşük kalite ürünler çıkmaktadır. Bu makale, yukarıdaki prbleme çözüm önerisi larak, yazılım şirketleri bünyesinde bağımsız dğrulama ve geçerleme-test ekibi kurulmasını teknik, idari ve mali açıdan inceleyip, rta ölçekli yazılım firmalarının bütçe-persnel kısıtlarını gözeterek ideal bağımsız dğrulama ve geçerleme rganizasyn yaklaşımını sunmak ü aşağıdaki knu başlıkları incelenerek hazırlanmıştır. Türkiye de faaliyet gösteren yazılım şirketlerinde dğrulama ve geçerleme rganizasyn yapısı ve yöntemleri. Dünyada önde gelen yazılım şirketlerinde kullanılan bağımsız dğrulama ve geçerleme rganizasyn mdelleri ve yöntemleri. Dünyada kabul görmüş standartlar nasıl bir bağımsız dğrulama ve geçerleme rganizasyn yapısı öneriyr? Araştırmalar, makaleler. Aynı yazılımı üreten, bağımsız test ekibi lan ve lmayan iki yazılım ekibinin karşılaştırmalı çıktıları. Bağımsız yazılım test ekibi kurulmasının getirileri. Orta ölçekli yazılım firmaları için ideal bağımsız dğrulama ve geçerleme rganizasyn mdeli. Bağımsız test ekibi luşturulurken dikkat edilmesi gereken nktalar ve riskler. Anahtar Sözcükler: Bağımsız yazılım dğrulama ve geçerleme rganizasyn mdeli, yazılım test, rganizasynu, test yöntemleri, test persneli. Abstract: Because f the fact that tests activities are perfrmed by peple wh have n technical expertise abut validatin & verificatin tpics, lw-quality sftware prduct is made. This article has been written t prvide ideal independent verificatin and validatin mdel in rder t slve the prblem mentined abve by taking int cnsideratin the cnstraints f the medium-sized sftware cmpanies having budget-staff. 1. Giriş Dğrulama - Geçerleme Nedir? Dğrulama ve Geçerleme süreçleri nedir? Neyi amaçlar? Ayrıldıkları nktalar nelerdir? Ve benzeri sruların cevapları Tabl 1 de verilmiştir. Dğrulama Dğru ürünü mü inşa ediyrum? Sistemin gereksinimleri Geçerleme Ürünü dğru mu inşa ediyrum? Kabul edilebilir lduğundan emin
karşılayıp karşılamadığı ve amaçlanan, kuruluşun hedeflerini ve kullanıcı ihtiyaçlarını karşılayan fnksiynların gerçekleştirilip gerçekleştirilmediğini belirleme. Bu, geleneksel ve prje snunda yapılır. Dğru veriye mi ulaşıyrum (gereksinimi karşılamak için gerekli lan veriler açısından)? Üst (genel) seviye aktivite. Bir iş ürünü üretildikten snra gerçekleştirilir. Ürünün kurulum rtamına dğru entegre lduğundan emin lmak için belirlenmiş kriterlere uygun lup lmadığını belirlemeye çalışır. Sn yazılım ürününün, kullanıcı ihtiyaçlarına ve gereksinimlerine göre dğruluğunun belirlenmesi. lmak için prje sırasında iş adımları ve ara çıktılar gözden geçirilir. Sisteminin tutarlı, standartlara bağlı, güvenilir teknikler ve pratikler uygulanarak ve seçilmiş fnksiynların dğru şekilde uygulanarak sistemin geliştirilip geliştirilmediğini belirlemek için yapılır. Veriye dğru şekilde mi erişiyrum (dğru yerde, dğru şekilde)? Alt (detay) seviye aktivite. Yazılım geliştirme esnasında izlenecek yllar, gözden geçirme ve yrumlar, geribildirimler, eğitim, kntrl listesi ve standartlar gibi anahtar knular üzerinden gidilerek gerçekleştirilir. Her yazılım geliştirme yaşam döngüsü aşamasında ve aşamalar arasında yazılımın tutarlılığının, bütünlüğünün ve dğruluğunun gösterimi. Tabl 1. Dğrulama Geçerleme 2. Türkiye deki Mevcut Durum Türkiye Yazılım Test ve Kalite Derneği nin (Turkish Testing Bard -TTB) hazırladığı 2012-2013 Türkiye Yazılım Kalitesi Rapru nda[1] aşağıdaki tespitler yapılmıştır: Türkiye de bir önceki rapr dönemine kadar gözlemlenmiş lan testleri yazılım geliştirme gruplarına yaptırma yönündeki eğilimin, sn rapr döneminde tersine döndüğü ve firmaların büyük çğunluğunun test mühendisi istihdam etmeye başladığı tespit edilmiştir. Yapılan araştırmaya göre, araştırmaya katılan yazılım firmalarının %7,8 nin testlerini dışarıdan bir firmaya altyüklenici kullanımı yluyla yaptırdıkları tespit edilmiştir. Aynı araştırmaya göre, firmaların %70,1 i yazılım testlerinde geliştiricilerden bağımsız larak yazılım test mühendisi kullandıklarını belirtmişlerdir. Rapra göre, önümüzdeki 5 yıl içerisinde rta ve büyük byutlu yazılım firmalarında yazılım geliştiricilere sadece birim test yaptırılacağı, kalan diğer tüm test işlerinin bağımsız test grupları ya da test mühendisleri tarafından gerçekleştirileceği öngörülmektedir. Araştırmaya katılan firmalardan %65 i prje takvimlerinde test faaliyetlerine ayırdıkları zamanın, prje takviminin %30 undan daha az lduğunu belirtmişlerdir. Bunun sebebi larak, tasarım ve geliştirme faaliyetlerindeki gecikmeleri göstermişlerdir. Raprda, Telekm, Bankacılık ve IT sektörlerinde firma bünyesinde bağımsız test grubu luşturulmasının ldukça yaygın lduğu belirtilmiştir. 3. Dünyadaki Mevcut Durum Dünya genelinde yazılım firmalarında test rganizasynlarının nasıl luşturulduklarını ve yazılım testi knusunda yükselen değerlerin neler lduğunu anlamak adına literatür taraması yapılmış ve aşağıdaki bilgilere ulaşılmıştır.
Dünyada Yazılım Şirketlerinde Dğrulama ve Geçerleme Nasıl Yapılıyr? Dünyada yazılım prjelerinde dğrulama ve geçerleme işlerinin ayrı bir ekip tarafından yapılması süreçlerde standart hale gelmiş durumdadır. NASA Langley Research Center tarafından 1999 yılında bağımsız test rganizasynun getirilerini ölçen araştırmada [2], test rganizasynunun bağımsızlığının Amerikan Savunma Sanayi prsedürlerinde sabitlenmiş lduğu görülmektedir. Dğrulama ve geçerleme süreçleri için güncel yükselen değerler; bağımsız test ekiplerinin eğitimleri, yapısı, dış kaynaklı bağımsız test ekiplerinin kullanım ranları, yerleşimi ve iletişimi gibi knulardan luşmaktadır. Micrsft [3] Bağımsız bir test müdürlüğü ve ekibi bulunmaktadır. Organizasyn üçlü süreç (Şekil 1) ve birim yönetiminden luşmaktadır. Kalite Mühendisleri test müdürlüğü altında istihdam edilmektedir. süreçlerine göre işletebilecek kalifiyede lması gerekir. Unvanı Test Yazılım Geliştirme Mühendisidir (Sftware Develpment Engineer in Test). Yazılım piyasaya sürüldükten snra çıkan hataların srumluluğu geliştirme mühendislerine değil, test mühendislerine aittir. Test mühendislerine srumlulukla birlikte üst seviye değer verilir. Teste verilen değer maaş skalalarına da yansımakta ve test mühendislerine yazılım mühendislerinden daha fazla maaş ödenmektedir (Tabl 2). Kıdem Yeni (Junir) Kıdemli (Senir) Lider (Principle) Test Mühendisi Yıllık Ücreti Yazılım Mühendisi Yıllık Ücreti 80.000 $ 70.000 $ 130.000 $ 100.000 $ 180.000 $ 150.000 $ Tabl 2. Test Mühendisi ve Yazılım Mühendisi Maaş Skalası Şekil 1. Geliştirme, Test ve Prje Yönetiminden Oluşan Üçlü Organizasyn Yapısı [3] Testler altı farklı seviyede yapılır: Birim testleri, temel değer testleri, giriş testleri, fnksiynel testler, entegrasyn testleri, tekrar testleri (sürekli entegrasynla her gece kd derleme snrasında ve yazılımcının her kd kaydında (check-in) kşulan test tmatizasynları). Test süreçlerine büyük önem verilmekle birlikte öne çıkan knular: Test Ekibi yazılımı geliştiren teknik ekipten bağımsız, test teknikleri ve test araçları knusunda uzman teknik kişilerden luşmakta, geliştirme ve tasarım ekibinden kimse test sürecine dahil edilmemektedir. Test Mühendislerinin yazılım geliştirmeyi bilen, kd yazabilir - debug edebilir, tmatik test araçlarını ve tmatik test scriptlerini yazabilir, sürekli entegrasynu kurup işletecek bilgiye sahip, testleri tasarlayıp test Ggle [4], [5] Bağımsız bir test müdürlüğü ve ekibi bulunmaktadır. Şirket ve prjeler büyük lmasına karşın, küçük ekipler halinde çevik yöntemleri kullanarak yazılım geliştirilmektedir. Test Mühendislerinin kddan anlar, yazabilir ve debug edebilir durumda lması gerekiyr. Unvan Test Yazılım Geliştirme Mühendisi (Sftware Develpment Engineer in Test) larak görünüyr. Yazılım geliştirmeyi bilen, tmatik test araçlarını ve tmatik test scriptlerini bilen, sürekli entegrasynu
kurup işletecek bilgiye sahip, testleri tasarlayıp test süreçlerine göre işletebilecek kalifiyede persnelden luşuyr. İki seviye test mühendisi bulunmakla birlikte çevik süreçlerin etkisiyle testler üç seviyede yapılıyr [5]: Kdu geliştiren yazılım mühendisi ilk testleri yapmaktan ve kdun kalitesinden srumlu. Kdu iyileştirme ve beyaz kutu testinden srumlu test mühendisi, kd geliştiricilerin arkasından kdu tekrar elden geçiriyr ve iyileştiriyr. Test tmatizasynundan srumlu test mühendisi ilgili kd için tmatik test kdlarını ve test prsedürünü yazıyr. Amerikan Savunma Sanayii Şirketleri [2][9] Amerikan savunma sanayi yazılım mühendisliği prsedürlerinde, test rganizasynun bağımsızlığı sabitlenmiştir. Dünyada Kabul Görmüş Standartlar ve Otriteler Nasıl Bir Organizasyn Yapısı Öneriyr? ISTQB(Internatinal Sftware Testing and Quality Bard) [6] Bağımsız test rganizasyn yapıları aşağıda listelenmiştir. Tavsiye edilen rganizasyn yapısı ikinci maddede anlatılan yapıdır. Geliştirme ekibinde bulunan bağımsız test ekibi. Organizasyndan ve prje yönetiminden bağımsız test ekibi. İşletmeden bağımsız test ekibi. Farklı test klları için ayrı dallarda (kullanılabilirlik, güvenlik, vb.) uzmanlaşmış bağımsız, farklı test ekipleri. Dış firmadan kiralanmış test ekibi. TMMI (Testing Maturity Mdel Integratin) [7] TMMI IV&V standardında, rta ölçekli firmalar için tavsiye edilen TMMI Seviye 3 de daha iyi test yapabilmek ve daha kaliteli yazılım elde etmek adına bağımsız test rganizasynu şart larak sunuluyr. TMMI için bağımsız test rganizasynunun anlamı: Tasarımcılar ve geliştiriciler test ekibinde bulunmaz, en önemli nkta test mühendisleri geliştirme yönetiminden farklı bir yönetime rapr verirler. Böylece test mühendisleri geliştirme ekibinin baskısından kurtarılarak, bjektif ve tarafsız lmaları sağlanır. TMMI 3 ve CMMI 3 birbirini tamamlayıcı aynı seviyede yapılardır. IEEE-1012-2004 IV&V (IEEE Standard fr Sftware Verificatin and Validatin) [8] Bağımsız dğrulama ve geçerleme rganizasyn yapısı üç parametreyle belirlenir: Teknik bağımsızlık Yönetimsel bağımsızlık Bütçesel bağımsızlık Bu parametreler snucunda test rganizasynu bağımsızlığının hangi seviyede başarıldığı saptanır (Tabl 2). IV&V Teknik Yönetimsel Bütçe Seviyesi Klasik T T T Mdifiye T k T Entegre k T T İç k k k Gömülü m m m NOT: T = Tam bağımsızlık; k = Kşullu bağımsızlık, m = Minimal bağımsızlık Tabl 2. Bağımsız Test Organizasynu Yapıları NASA Bağımsız Dğrulama ve Geçerleme Prgramı [9] [10] NASA IV&V (Bağımsız Dğrulama ve Geçerleme) kalite prsedüründe IV & V fisinin gerek rganizasyn yapısı içinde gerekse fis ve yerleşim larak tamamen bağımsız ve ayrı bir binada çalıştığı görülmektedir. IV & V fisinin amacı yazılımın güvenilir şekilde çalışacağına dair
güvence sağlayarak, NASA'nın yazılımı üzerinde bağımsız dğrulama ve geçerleme yapmaktır. IV & V kendi içinde dört ayrı uzmanlaşmış test grubu içerir: Bağımsız Dğrulama ve Geçerleme, Yetenek Geliştirme (CD), Teknik Kalite ve Mükemmellik (TQ & E) ve Yazılım Güvencesi Araçları (SWAT). Yazılım dört farklı seviye test grubu tarafından test edilir. IV & V ekibi prjenin ilk safhasından itibaren çalışmaya başlar ve prje bitiminde perasyn-bakım safhalarında devam eder. IV&V ekibinin görevleri: Kavram Belgelerini Dğrula ve Geçerle Gereksinimleri Dğrula ve Geçerle Test Dkümantasynunu Dğrula ve Geçerle Tasarımı Dğrula ve Geçerle Uygulamayı Dğrula ve Geçerle Operasyn ve Bakım İçeriğini Dğrula ve Geçerle Dünyada Yapılan Araştırmalar, Makaleler, Karşılaştırmalar Bağımsız Dğrulama ve Geçerleme Ekibinin Verimliliğinin Değerlendirilmesi [2] NASA Langley Araştırma merkezi 1999 senesinde, Amerikan savunma sanayi-yazılım mühendisliği yaşam döngüsünde mevcut lan dğrulama-geçerleme sürecinin geliştirme ekibinden bağımsız bir ekip tarafından yapılmasının verimliliği değerlendirilmiştir. Aynı yazılımı iki ayrı yazılım geliştirme grubu geliştirir. Grup 1: Geliştirme ekibi + Bağımsız test ekibi. Grup 2: Sadece geliştirme ekibinden luşur. Test süreçlerini de geliştirme ekibi gerçekleştirir. Değerlendirmenin snuçları: Bağımsız test ekibine sahip lan Grup 1: çğunluğu prjenin ilk safhaları lan gereksinim ve tasarım safhalarında lmak üzere 97 hata bulurken, Grup 2: 58 hata bulabilmiş ve bunları da kd rtaya çıktıktan snra, yani düzeltme maliyeti en yüksek lan safhada bulabilmiştir. Aradaki bulunamayan 39 hatalık farkın etkisi kabul testlerinde çıkan ürünün kalitesinde kendisini gösterir: Grup 1, 36 testin 33 ünü başarıyla geçip 3 ünde başarısız lur. Grup 2, 36 testin 11 ini başarıyla geçip 25 inde başarısız lur. Yazılım Test Süreçleri ve Stratejilerinin Ayrıntılı Değerlendirmesi [11] Jussi Kasurinen (Lappeenranta Teknlji Üniversitesi) tarafından gerçekleştirilen araştırmaya göre kaliteli bir ürün rtaya çıkabilmesi için rganizasyn yapısında aşağıdaki şartlar sağlanmalıdır: Prjelere uygun test araçları Kendini tekrar eden tmatik test araçları ve test stratejileri Bağımsızlığı ve srumluluklarıyla birlikte yetkileri net larak tanımlanmış test ekibi Test tasarımı ve seçim mettları Kalite kriterleri (Test başlangıç ve bitiş kriterleri) Yazılım Test Organizasynu Tasarımı ve Yapılandırması [12] Bruce Bentn (Sr. Test Manager, Micrsft) tarafından yapılan araştırmaya göre test rganizasynu bağımsız lmalı ve test ekibi karma yapıda kurulmalıdır: Teknik ekip gerektiğinde kd yazabilecek, yazılan kdu değerlendirip iyileştirebilecek seviyede kd bilgisine sahip lmalı ve test senarylarını tasarlayabilmeli ve tmatik test kdlarını yazıp yönetebilmelidir. Analiz ekibi gereksinimleri analiz eder ve tasarım safhasında (kd yazılmadan) teknik ekiple birlikte sistem ve yazılım mühendislerine hata ve geri bildirimler sunarak snradan çıkması muhtemel ve düzeltilmesi çk daha maliyetli lacak hatalar prjenin erken safhalarında tespit edilir. 4. Bağımsız Yazılım Test Ekibi Kurulmasının Getirileri Geliştirme ekiplerinin yğunlukları
sebebiyle yeterli zaman ayıramadıkları dğrulama, geçerli kılma ve test rtamı luşturma faaliyetlerine test ekibi aracılığıyla gerekli zaman ve efr ayrılabilecektir. İç test faaliyetleri geliştirme faaliyetlerine paralel yürütülecek, böylece geliştirme fazının snunda rtaya kalitesi yüksek bir ürün çıkması sağlanacaktır. Test rtamı kurulması, test yaklaşımlarının belirlenmesi, test araçlarının seçilmesi gibi knular prjenin sn aşamasına kalmayacak, geliştirme çalışmalarına paralel larak yürütülebilecektir. Prje yaşam döngüsü byunca, her türlü çıktı (dkümanlar, yazılım vs.) dğrulama ve geçerli kılma bakış açışıyla incelenecektir. Bu durum çıktıların kalitesini yükseltecektir. 5. Orta Ölçekli Yazılım Firmaları İçin İdeal Bağımsız Dğrulama Ve Geçerleme Organizasyn Mdeli Literatürde tavsiye edilen test rganizasynunun teknik larak geliştirme ekiplerinden ve idari larak prje yönetiminden tamamen bağımsız lmasıdır. Fakat rta ölçekli firmalarda bütçe kısıtlarından dlayı tüm test ekibi sabit test uzmanlarından luşturulamayabilmektedir. Yazılım persnelleri özellikle yeni işe başlamış yazılım mühendisleri rtasyn (geçici larak, sadece prje özelinde) test persneli larak görev alıyr. Karma bir mdeldir. Az sayıda Test Liderinden luşan çekirdek bir test ekibi kurularak, test knularında uzmanlık ve bilgi birikiminin kayblmaması ve prjeler arasında aktarılması sağlanır. Böylece literatürde ve dünyadaki uygulamalarda kabul gören en ideal çözüme (test persnelinin tamamen bağımsız lması) yakın durulmuş ama yüksek maliyetinden kaçınılmış lur. Test liderleri test knularında ve bağlı ldukları alan bilgisi knularında eğitim alır ve uzmanlaşır. Bu liderin altına, ilgili müdürlükler (Sistem/Yazılım), rtasyn yöntemiyle prje özelinde test mühendisi larak çalışacak lan persneli atar. Prjenin yarı safhasından snra test ekibine ¼ ranında sistem mühendisi katılır. Oluşturulan ekip, ilgili prjede hiçbir şekilde geliştirme faaliyetlerine katılmaz. Ekip test knularında lider tarafından eğitilir ve yönlendirilir. Test lideri, bağımsız test yapabilmek adına, geliştirme ekibi ve prje yönetiminden bağımsız şekilde direktörlük ve/veya kalite birimine bağlıdır. Her prjenin bünyesinde prjenin büyüklüğü ile rantılı lacak şekilde prjenin başlangıcında bir test ekibi kurulur. Bu sayede test ekibi müşteri isterlerini belirleme ve tasarım safhalarından itibaren prjeye katkı vererek, snradan tespiti mümkün lmayan hataların bulunmasını ve düşük maliyetlerle düzeltilmesini sağlar. Sabit test liderleriyle yazılım testi knularında uzmanlaşma ve bilgi birikimi sağlanır. Uzmanlığı test lan sabit persnel istihdam edilmesiyle test işlerinde srumluluk ve mtivasyn üst seviyeye çekilir. Test liderlerinin sabit test persneli lması nların tarafsız, bağımsız, cesur ve test bakış açısına sahip lmalarını sağlar. Tümden rtasynla luşturulan ekipler prje snunda yazılım ekibine tekrar geri dönecekleri için geliştirme ekibine hata açmak istememekte ve test bakış açısıyla çalışamamaktadırlar. Test rtamı kurulması, test yöntemlerinin belirlenmesi, test araçlarının seçilmesi gibi knular ilgili prje tipinden srumlu uzman test lideri tarafından daha evvel tecrübe edilmiş ve uzmanlık kazanılmış lduğu için daha hızlı ve verimli bir şekilde yönetilir. Bu madde anahtar knumundadır; aksi takdirde her prje ekibi yöntemleri ve araçları sıfırdan tecrübe edecek ve uzmanlaşamadan test görevini tamamlayıp esas işine geri dönecektir. Bu da test rganizasynunun veriminin düşük ve amacından uzak lmasına sebep lacaktır. Sistem mühendisleri gereksinim yazma fazında, sistem testlerini daha snra yine kendilerinin yapacaklarını bilmeleri, gereksinimleri daha kaliteli ve test edilebilir şekilde yazmalarını sağlar.
Yüksek kalitede ürün (kullanıcı dstu, sağlam, güvenilir) geliştirilmesi sağlanarak müşterilerin gözünde şirketin imajı kalite kelimesiyle bütünleşir ve yeni işlerin ve pazarların kazanılması sağlanır. [5] James Whittaker - Jasn Arbn - Jeff Carll, Hw Ggle Tests Sftware, Addisn-Wesley Prfessinal, 2012 [6] ISTQB Advanced Level Certificatn Syllabus SONUÇ Yazılım prjelerinde bağımsız test ekibinin kurulması çıkan ürünün kalitesini gözle görülür şekilde artırmaktadır. Bağımsız test rganizasynunu yapılandırılırken şirketin teknik persnel, idari ve bütçe yapısı göz önünde bulundurularak şirkete özel en uygun yapıda luşturulmalıdır. Kaynaklar [1] Turkish Testing Bard, Turkey Sftware Quality Reprt 2012-2013, 2012 [2] James D.Arthur, Markus K.Gröner - Virginia Tech, Kelly J.Hayhurst, C. Michael Hllway - NASA Langley Research Center, Evaluating the Effectiveness f Independent Verificatin and Validatin, 1999 [3] Alan Page, Ken Jhnstn, Bj Rllisn, Hw We Test Sftware at Micrsft, Micrsft Press, 2009 [7] TMMI (Test Maturity Mdel Integratin) [8] IEEE-1012 Standart (IEEE Standard fr Sftware Verificatin and Validatin) [9] NASA Independent Verificatin & Validatin Prgram - Quality Manual - IVV QM [10] NASA Independent Verificatin & Validatin Technical Framewrk - IVV 09-1 [11] Jussi Kasurinen - Lappeenranta University f Technlgy, Elabrating Sftware Test Prcesses and Strategies, 2010 Third Internatinal Cnference n Sftware Testing, Verificatin and Validatin [12] Bruce Bentn Sr. Test Manager - Micrsft, Designing and Building a Sftware Test Organizatin, 2008 Internatinal Cnference n Sftware Testing, Verificatin, and Validatin [4] Patrick Cpeland, Ggle, Ggle s Innvatin Factry: Testing, Culture, And Infrastructure, ICST 2010