<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Test Olgunluk Seviyesi Modeli</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Barış Sarıalioğlu</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Berk Dülger</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Keytorc Yazılım Test Hizmetleri</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Eski Büyükdere Caddesi GIZ</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Plaza Ofis No:</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Maslak / İstanbul</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Yazılım Projelerinin Yönetimi ve Kalite</institution>
        </aff>
      </contrib-group>
      <fpage>94</fpage>
      <lpage>100</lpage>
      <abstract>
        <p>Ö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 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.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>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</p>
      <p>Yazılım Kalitesi ve Test</p>
      <p>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.</p>
      <p>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</p>
      <p>Test Olgunluk Seviyesi Modelleri</p>
      <p>Test süreçlerinin olgunluk
kullanılabilmektedir. Bunlar özetle;
Tablo 1. Test Olgunluk Seviyesi Modelleri
seviyesi
ölçümü
için
farklı
metodolojiler</p>
    </sec>
    <sec id="sec-2">
      <title>Acronym BTM TOM</title>
    </sec>
    <sec id="sec-3">
      <title>TMAP TSM TPI TMM</title>
      <p>Details
Beizer’s Testing Model
Test Organization
Model
Test Management Approach</p>
    </sec>
    <sec id="sec-4">
      <title>Testability Support Model</title>
    </sec>
    <sec id="sec-5">
      <title>Test Process Model Test Maturity Model</title>
    </sec>
    <sec id="sec-6">
      <title>Author/Organization</title>
      <p>Authored by Beizer in 1990
Maturity Authored by Gerrad Consulting in
the U.K in the late 1990s
Authored by Martin Pol, Rudd
Teunissen and Erik can
Veenendaal in 1995 and now
owned by Sogeti which is part of
Capgemini
Authored by Dr. David Gelperin in
1996
Improvement Authored by Tim Koomen and
Martin Pol in 1996
Authored by Dr.Ilene Burstein, at
the Illinois Institude of</p>
    </sec>
    <sec id="sec-7">
      <title>TCMM TIM TCI TPA</title>
      <p>TMAP Next</p>
    </sec>
    <sec id="sec-8">
      <title>TMMi</title>
    </sec>
    <sec id="sec-9">
      <title>TPCR</title>
    </sec>
    <sec id="sec-10">
      <title>Technology in 1996 Maturity Authored by Torry Harris in 2001 Technical Capability Model</title>
      <p>Authored by Thomas Ericson in
2002
Test Capability Improvement Authored by Atos Origin
Test Process Assesment Authored by CTG
Test Management Approach for Authored by Tim Koomen,
Next Generation Michiel Vroon, Leo van der Aalst</p>
      <p>&amp; Bart Broekman in 2005
Test Maturity Model Integrated By TMMi Foundation in 2007. In
2010 level 4 and 5 framework was
released.</p>
      <p>Test Process &amp; Capability Rating Authored by Baris Sarialioglu in
2011 and revised in 2013
olarak listelenebilir.
2 Test Process and Capability Rating – TPCR Modeli</p>
      <p>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ı</p>
    </sec>
    <sec id="sec-11">
      <title>Acronym</title>
      <p>TP
TP.01
TP.02
TP.03
TP.04
TP.05
TP.06
TP.07
TP.08
TP.09
TP.10
TP.11
TP.12
TP.13
TP.14
TP.15
TP.16</p>
    </sec>
    <sec id="sec-12">
      <title>Key Process Area</title>
      <p>Test Processes
Test Methodology
Test Policy
Test Planning &amp; Budgeting
Test Effort Estimation
Early Involvement
Test Basis
Test Stop Criteria
Risk Assessment
Test Metrics
Test Documentation
Test Monitoring &amp; Reporting
Test Design Techniques
Static Testing
Functional Testing
Non-Functional Testing
Regression Testing
TP.18
TP.19
PO
PO.01
PO.02
PO.03
PO.04
TT
TT.01
TT.02
TT.03
TT.04
RP
RP.01
RP.02
RP.03
RP.04
RP.05</p>
      <p>Testing Activities for Development &amp; Unit
Testing
User Acceptance Testing
Negative Testing
People &amp; Organization
People / Organization
Project Roles for Testing
Test Skills
Test Training Program
Technology Tools
Test Tools &amp; Utilization
Test Environments
Test Automation
Test Data Management
Related Processes
Defect Management
Configuration Management
Release Management
Requirements Management</p>
      <p>User Experience &amp; Usability</p>
      <p>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.</p>
      <p>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.</p>
      <p>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.</p>
      <p>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.</p>
      <p>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.</p>
      <p>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.
2.1</p>
      <p>TPCR Değerlendirme Süreci</p>
      <p>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;</p>
      <p>Teorik Değerlendirme [%25]</p>
      <p>Test Politika, Strateji ve Metodolojisi
Süreçler, Çıktılar ve Araçlar</p>
      <p>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]</p>
      <p>Kurum Kültürü</p>
      <p>Yerinde Analiz
Kanıt Değerlendirmesi [%35]</p>
      <p>Projelerde Kurgulan Yapının İncelenmesi
oranlarında katkı sağlamaktadırlar.</p>
      <p>Belirtilen fazlardan elde edilen veriler ışığında, her bir kritik alan için ayrı ayrı
değerlendirme yapılmaktadır.
2.2</p>
      <p>TPCR Olgunluk Seviyesi Hesaplaması</p>
      <p>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</p>
      <p>TPCR, TMMi ve Diğer Olgunluk Modelleri</p>
      <p>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.
Tablo 3. “TPCR”, “TMMi” ve “TPI” Modellerinin Karşılaştırılmalı Analizi
•
•
•
•
•
•</p>
    </sec>
    <sec id="sec-13">
      <title>TPCR</title>
      <p>32 Kritik Alanın
Bulunması
‘Related Processes’
Kısmının Bulunması
“Test Processes”,
“People &amp;
Organization”,
“Technology &amp;
Tools” ve “Related
Processes”
Başlıklarının Ayrı
Ayrı İncelenmesi
Organizasyonel
Önceliklerin
Adreslenmesi
Teorik ve Pratik
Değerlendirme
yapılması
Sürecin Şeffaf
İşletilmesi
•
•
•
•
•
•</p>
    </sec>
    <sec id="sec-14">
      <title>TMMi</title>
      <p>16 Kritik Alanın •
Bulunması
Geniş Çapta Kabul •
Edilir Olması
Dünya’da Bilinirliği •
CMMi ile
Entegrasyonu ve
Uyumu •
Tümleşik Kritik •
Alanlar
Dokümantasyon ve •
Kaynaklar</p>
      <p>TPI
16 Kritik Alanın
Bulunması
Geniş Çapta Kabul
Edilir Olması
Excel Tabanlı
Ücretsiz Bir Aracı
Olması
TMAP Alyapısı
CMMi Entegre
Süreçleri
Dokümantasyon ve
Kaynaklar
3</p>
      <p>Ö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.</p>
      <p>Kaynaklar
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</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <given-names>Project</given-names>
            <surname>Management Triangle: Lewis</surname>
          </string-name>
          ,
          <string-name>
            <surname>James P.</surname>
          </string-name>
          (
          <year>2005</year>
          ).
          <article-title>Project Planning, Scheduling &amp; Control, 4E</article-title>
          .
          <source>McGraw Hill. ISBN 978-0-07-146037-8 Project Management</source>
          , The Managerial Process: Erik W. Larson, Clifforg F. Gray, 5E.
          <source>McGraw Hill. ISBN 978-0-07-340334-2 Juran</source>
          , Joseph M.
          <article-title>(1995), A History of Managing for Quality: The Evolution, Trends, and Future Directions of Managing for Quality, Milwaukee</article-title>
          , Wisconsin:
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>