=Paper=
{{Paper
|id=Vol-1483/9_Bildiri
|storemode=property
|title=Test Olgunluk Seviyesi Modeli
|pdfUrl=https://ceur-ws.org/Vol-1483/9_Bildiri.pdf
|volume=Vol-1483
|dblpUrl=https://dblp.org/rec/conf/uyms/DulgerS15
}}
==Test Olgunluk Seviyesi Modeli==
https://ceur-ws.org/Vol-1483/9_Bildiri.pdf
Test Olgunluk Seviyesi Modeli
Barış Sarıalioğlu1, Berk Dülger1,
1
Keytorc Yazılım Test Hizmetleri, Eski Büyükdere Caddesi GIZ 2000 Plaza Ofis No: 41
Maslak / İstanbul, Türkiye
baris.sarialioglu@keytorc.com berk.dulger@keytorc.com
Özet. Kalite Kontrol/Test aktiviteleri, sistemdeki hataların en etkin ve verimli
bir biçimde ortaya konulup, düzeltilmesini hedeflemektedir. Yazılım
sistemlerinde ise, benimsenen yaşam döngüsü modeline göre bu aktiviteler
farklı şekillerde kurgulanabilmektedir. Geleneksel modellerde test aktiviteleri,
diğer aktiviteler gibi bağımsız bir adım olarak kurgulanırken, çevik modellerde
kodlama aktivitelerine entegre biçimde yer almaktadır. Bunun yanında, test
süreçlerinin olgunluk seviyesi ölçümü için farklı modeller kullanılabilmektedir.
Bu bildiride, belirtilen modellerden sonuncusu olan ve Barış Sarıalioğlu
tarafından 2011 yılı itibariyle geliştirilmeye başlanan Test Process and
Capability Rating (TPCR)’ın yapısı ve özelliklerine yer verilecektir. TPCR
modelini diğerlerinden ayıran en büyük özellik, yalnızca test süreçlerine
odaklanmayıp, ilgili diğer süreçleri de inceliyor olmasıdır. Bu kapsamda
incelenen otuz iki kritik alanın, dört başlık altında listelenebilmesi mümkün
olmaktadır.
Anahtar Kelimeler: Yazılım Testi, Test Olgunluk Modeli, Test Process and
Capability Rating - TPCR
1 Yazılım Projelerinin Yönetimi ve Kalite
Yazılım sektörünün gelişmesiyle birlikte, projelerin gerçekleştiriminde “Zaman”,
“Maliyet” ve “Kapsam” unsurlarının toplam kalite üzerindeki etkisi gittikçe daha
belirleyici hale gelmektedir. Proje yönetimi kuramlarının temelini oluşturan bu
yaklaşımda, mevcut kaynaklarla gerçekleştirilebilecek bir projenin ancak belirli bir
seviyede değer üretebileceği ve bu değerin farklı unsurlar arasında istenilen oranlarla
paylaştırılabileceğine değinilmektedir. Bu paylaşımın denge merkezinde ise Kalite
kavramı bulunmaktadır. Bazı modellerde de “Kapsam” ve “Kalite” tek bir unsur
olarak kabul edilerek “Ürün” ismiyle değerlendirilmektedir. Ancak, kurgulanan
model ne olursa olsun temel ilke değişmemektedir; proje kriterleri üzerindeki
herhangi bir değişiklik mutlaka diğerlerini de etkiliyor olacaktır. Bir diğer deyişle,
gerçekleştirilen hiçbir değişikliğin bütünsel sistem üzerindeki etkisi göz ardı
edilemeyecektir.
Bu kabulle yola çıkıldığında, toplam kalitenin arttırılması için kriterlerde iyileşme
gerekliliği ortaya çıkmaktadır. Bu da dolaylı olarak, yazılım geliştirme yaşam
döngüsünün tüm aşamalarında eş zamanlı nitelik artışı anlamına gelmektedir. Ancak
bu sayede toplam kalite üzerinde belirgin bir artış sağlanabilecektir. Özetle, herhangi
bir yazılım projesinde kalite tüm proje paydaşlarının sorumluluğundadır.
94
Bu kapsamdaki teorik yaklaşımların pratiğe geçirilebilmesi için
gerçekleştirilebilecek iki farklı yaklaşım söz konusu olmaktadır. İlki,
engelleme/önleme aktiviteleri olarak tanımlayabileceğimiz “Kalite Güvence”, ikincisi
ise tespit etme anlamında değerlendirebileceğimiz “Kalite Kontrol/Test” aktiviteleri
olarak nitelendirilebilir. Ülkemizde sık sık rast gelindiği gibi, bu iki kavram birbirleri
yerine hatalı bir biçimde kullanılabilmektedir.
1.1 Yazılım Kalitesi ve Test
Kalite Güvence faaliyetleri isminden de anlaşılacağı gibi, hataların daha oluşmadan
önlenebilmesi için gerçekleştirilmektedir. Bu alanda önce çıkan “ISO”, “Kaizen”,
“Six Sigma” gibi çatıların tümü, üretim süreçlerinde hata oluşumunu hedef
almaktadır.
Kalite Kontrol/Test aktiviteleri, sistemdeki hataların en etkin ve verimli bir
biçimde ortaya konulup, düzeltilmesini hedeflemektedir. Yazılım sistemlerinde ise,
benimsenen yaşam döngüsü modeline göre bu aktiviteler farklı şekillerde
kurgulanabilmektedir. Geleneksel/Sıralı modellerde test aktiviteleri diğer aktiviteler
gibi bağımsız bir adım olarak kurgulanırken, çevik modellerde kodlama aktivitelerine
entegre biçimde yer almaktadır. Ancak, hangi model uygulanırsa uygulansın yazılım
testine olan ihtiyaç değişmemektedir. Bu sebeple, yüksek olgunlukta bir yazılım test
sürecine sahip olunması nihai ürün kalitesi, müşteri memnuniyeti, marka algısı,
çalışan motivasyonu gibi birçok alan üzerinde belirleyici olmaktadır.
1.2 Test Olgunluk Seviyesi Modelleri
Test süreçlerinin olgunluk seviyesi ölçümü için farklı metodolojiler
kullanılabilmektedir. Bunlar özetle;
Tablo 1. Test Olgunluk Seviyesi Modelleri
Acronym Details Author/Organization
BTM Beizer’s Testing Model Authored by Beizer in 1990
TOM Test Organization Maturity Authored by Gerrad Consulting in
Model the U.K in the late 1990s
TMAP Test Management Approach Authored by Martin Pol, Rudd
Teunissen and Erik can
Veenendaal in 1995 and now
owned by Sogeti which is part of
Capgemini
TSM Testability Support Model Authored by Dr. David Gelperin in
1996
TPI Test Process Improvement Authored by Tim Koomen and
Model Martin Pol in 1996
TMM Test Maturity Model Authored by Dr.Ilene Burstein, at
the Illinois Institude of
95
Technology in 1996
TCMM Technical Capability Maturity Authored by Torry Harris in 2001
Model
TIM Test Improvement Model Authored by Thomas Ericson in
2002
TCI Test Capability Improvement Authored by Atos Origin
TPA Test Process Assesment Authored by CTG
TMAP Next Test Management Approach for Authored by Tim Koomen,
Next Generation Michiel Vroon, Leo van der Aalst
& Bart Broekman in 2005
TMMi Test Maturity Model Integrated By TMMi Foundation in 2007. In
2010 level 4 and 5 framework was
released.
TPCR Test Process & Capability Rating Authored by Baris Sarialioglu in
2011 and revised in 2013
olarak listelenebilir.
2 Test Process and Capability Rating – TPCR Modeli
Bu makalede, yukarıda belirtilen modellerden sonuncusu olan ve Barış Sarıalioğlu
tarafından 2011 yılı itibariyle geliştirilmeye başlanan TPCR’ın yapısı ve prensiplerine
yer verilecektir. TPCR modelini diğerlerinden ayıran en büyük özellik yalnızca test
süreçlerine odaklanmayıp, ilgili diğer süreçleri de inceliyor olmasıdır. Bu süreçler
“Test Processes” başlığı dışında gruplanmıştır. Bu kapsamda incelenen 32 kritik
alanın, dört başlık altında listelenebilmesi mümkündür. Bunlar;
Tablo 2. “Test Process and Capability Rating” Modeli Kritik Alanları
Acronym Key Process Area
TP Test Processes
TP.01 Test Methodology
TP.02 Test Policy
TP.03 Test Planning & Budgeting
TP.04 Test Effort Estimation
TP.05 Early Involvement
TP.06 Test Basis
TP.07 Test Stop Criteria
TP.08 Risk Assessment
TP.09 Test Metrics
TP.10 Test Documentation
TP.11 Test Monitoring & Reporting
TP.12 Test Design Techniques
TP.13 Static Testing
TP.14 Functional Testing
TP.15 Non-Functional Testing
TP.16 Regression Testing
96
TP.17 Testing Activities for Development & Unit
Testing
TP.18 User Acceptance Testing
TP.19 Negative Testing
PO People & Organization
PO.01 People / Organization
PO.02 Project Roles for Testing
PO.03 Test Skills
PO.04 Test Training Program
TT Technology Tools
TT.01 Test Tools & Utilization
TT.02 Test Environments
TT.03 Test Automation
TT.04 Test Data Management
RP Related Processes
RP.01 Defect Management
RP.02 Configuration Management
RP.03 Release Management
RP.04 Requirements Management
RP.05 User Experience & Usability
TPCR modeli bu alanlardaki olgunluğun ölçümlenip, iyileştirilmesine katkı
sağlamak amacıyla geliştirilmiştir. Modelde 10’luk skala üzerinden derecelendirme
yapılmaktadır. Bu derecelendirme sonucunda elde edilen puanların, niteliksel
açıklamaları şu şekildedir.
Ad-Hoc [0-2): Bu seviyede test süreçleri el yordamıyla gerçekleştirilmektedir. Bu
nedenle gerçekleştirilen aktiviteler tekrar edilebilir ya da standartlara uygun değildir.
Adoption [2-4): Bu seviyede test aktiviteleri bir süreç olarak kurgulanmıştır. Bu
nedenle tanımlı bir strateji dokümanı, test planı ve müşteri isterlerini baz alan test
senaryoları bulunmalıdır. Test aktiviteleri, ürün test fazına gelene kadar
başlayamamaktadır.
Moderate [4-6): Bu seviyede test fazı, yazılım geliştirme yaşam döngüsüne
tamamen entegre hale gelmiştir. Testler, risk yönetimine dikkat edilerek, geliştirme
aktivitelerinden bağımsız olarak ele alınmaktadır.
Advanced [6-8): Bu seviyede test aktiviteleri, isterlerin ve tasarımın doğrulanması
dahil tüm yaşam döngüsü fazlarında yer almaktadır. Kalite kriterleri tüm kurum
genelinde kabul edilmiş haldedir.
Standardized [8-10]: Bu seviyede test aktiviteleri sürekli olarak kontrol edilmekte
ve geliştirilmektedir. Genellikle bir araç desteği ve hata engelleme aktiviteleri söz
konusu olmaktadır.
97
2.1 TPCR Değerlendirme Süreci
TPCR Olgunluk Ölçümü çalışmalarında diğer denetleme çalışmalarında olduğu
gibi, mevcut durumun ortaya konulması için çeşitli değerlendirme adımları
gerçekleştirilmektedir. Her bir aşamanın ise, toplam puan üzerinden belirli bir ağırlığı
bulunmaktadır. Bunlar sırasıyla;
Teorik Değerlendirme [%25]
Test Politika, Strateji ve Metodolojisi
Süreçler, Çıktılar ve Araçlar
Dokümantasyon ve Prosedürler
Mülakatlar / Anket Sonuçları [%25]
Üst Yönetim, Proje Yönetimi, İş Birimleri, Yazılım, Analiz, Test ve Altyapı
Ekipleri ile Görüşmeler
Denetçi Görüşü [%15]
Kurum Kültürü
Yerinde Analiz
Kanıt Değerlendirmesi [%35]
Projelerde Kurgulan Yapının İncelenmesi
oranlarında katkı sağlamaktadırlar.
Belirtilen fazlardan elde edilen veriler ışığında, her bir kritik alan için ayrı ayrı
değerlendirme yapılmaktadır.
2.2 TPCR Olgunluk Seviyesi Hesaplaması
Her bir alanın değerlendirmesi sonucunda, ağırlıklı ortalama ile (Her bir kritik
alanında farklı ağırlık derecesi bulunabilmektedir.) mevcut test seviyesi
hesaplanabilmektedir. Benzer modellerde olduğu gibi, bir seviyedeki tüm kritik
alanların karşılanması, bir üst seviyeye yönelmek için zorunlu tutulmamaktadır (Bknz
TMMi).
2.3 TPCR, TMMi ve Diğer Olgunluk Modelleri
TPCR modelinin bir diğer avantajı da, elde edilen değerlendirme sonuçlarının
diğer birçok modele dönüştürülebilir olmasıdır. Örneğin, TPCR değerlendirmesi
tamamlanmış bir kurumun TMMi ve TPI modellerindeki olgunluk seviyesi de
kolaylıkla hesaplanabilmektedir. Böyle bir dönüşüm mümkün olma nedeni, TPCR’ın
TMMi ve TPI gibi modellerin üzerine kurgulanmış olmasıdır(Kapsar kümesi).
Süreçsel olarak da benzer yapıları olduğundan, bazı kritik alanların hesaplamalardan
çıkarımı olgunluk derecesi dönüşümü için yeterli olacaktır.
98
Tablo 3. “TPCR”, “TMMi” ve “TPI” Modellerinin Karşılaştırılmalı Analizi
TPCR TMMi TPI
• 32 Kritik Alanın • 16 Kritik Alanın • 16 Kritik Alanın
Bulunması Bulunması Bulunması
• ‘Related Processes’ • Geniş Çapta Kabul • Geniş Çapta Kabul
Kısmının Bulunması Edilir Olması Edilir Olması
• “Test Processes”, • Dünya’da Bilinirliği • Excel Tabanlı
“People & • CMMi ile Ücretsiz Bir Aracı
Organization”, Entegrasyonu ve Olması
“Technology & Uyumu • TMAP Alyapısı
Tools” ve “Related • Tümleşik Kritik • CMMi Entegre
Processes” Alanlar Süreçleri
Başlıklarının Ayrı • Dokümantasyon ve • Dokümantasyon ve
Ayrı İncelenmesi Kaynaklar Kaynaklar
• Organizasyonel
Önceliklerin
Adreslenmesi
• Teorik ve Pratik
Değerlendirme
yapılması
• Sürecin Şeffaf
İşletilmesi
3 Özet
TPCR olgunluk modeli ile mevcutta sunulmuş olan modeller ile çözümlenememiş
sorunların adreslenebilmesi ve test olgunluk seviyesinin en doğru şekilde
belirlenmesini hedeflenmektedir. Bu sebeple test süreçlerinin yanında; teknoloji,
kişiler, organizasyon ve ilgili süreçler de değerlendirilip toplam test olgunluk
seviyesinin belirlenmesinde dikkate alınmaktadır. Bu doğrultuda, özellikle bankacılık
ve telekomünikasyon alanında gerçekleştirdiğimiz olgunluk seviyesi ölçümlerinde
TPCR’ın benzerlerine göre daha anlamlı ve kesin bir sonuç üretmekte olduğunu
gözlemlemekteyiz. İleriki dönemde TPCR’ın açık hale getirilecek, değerlendirme
kriterleri ve yöntemlerinin paylaşılması hedeflenmektedir.
Kaynaklar
1. Project Management Triangle: Lewis, James P. (2005). Project Planning,
Scheduling & Control, 4E. McGraw Hill. ISBN 978-0-07-146037-8
2. Project Management, The Managerial Process: Erik W. Larson, Clifforg F. Gray,
5E. McGraw Hill. ISBN 978-0-07-340334-2
3. Juran, Joseph M. (1995), A History of Managing for Quality: The Evolution,
Trends, and Future Directions of Managing for Quality, Milwaukee, Wisconsin:
99
ASQC Quality Press, p. 596, ISBN 9780873893411, OCLC 32394752, retrieved
2013-10-20
4. Erik van Veenendaal, Jan Jaap Cannegieter, “The Little TMMi”, 2011
5. Sogeti, “TPI Framework”, December 2012
6. Sogeti, “TMap Next 1.3” Test Management Framework, 2006
100