Geliştirilen ürünün, gereksinimlerini ve müşteri ihtiyaçlarını karşıladığını sağlamak ve hataları bulmak amacıyla gerçekleştirilir. Test hem doğrulama hem geçerleme sürecinin bir türüdür Bu sürecin sonucunda,

• Ürün, gereksinimlerine karşı sınanmış,
• Yazılımın müşterinin kullanacağı ortamda müşteri beklentilerini karşılayacak şekilde uygun çalıştığı sağlanmış,
• Gereksinimler ve test sonuçları arasında izlenebilirlik kurulmuş ve izlenebilirlik matrisi güncellenmiş,
• Test senaryoları oluşturulmuş,
• Hataların düzeltildiği onaylanmış,
• Hatalar kayıt altına alınmış olur.

Test süreci başarılı bir şekilde uygulandığında, müşterinin kullanımda bulduğu hata sayısı az, uygulamanın her bileşeni test edilmiş, regresyon testleri planlanmış, üründe değişiklik olduğu zaman etkilenen test durumlarını ve eklenmesi gereken test durumlarını tespit etmek kolay olur.

Test Durumu: IEEE 829-1998 standardına göre, test durumu girdisi ve beklenen sonucu olan bir test süreci çıktısıdır. Test durumuna ait, olay, girdi, çıktı ve beklenen sonuçlar vardır. Test Senaryosu: Test senaryoları, senaryo tabanlı test yönteminin girdisidir. Senaryolar, insanların kompleks bir sistem üzerinde düşünmesini sağlayacak sistemin kullanılma hikayeleridir. Bir akış şemasından ya da detaylı bir akış prosedüründen ibaret olabilir.

Test Planı: Test sürecinde yapılacak işler hakkında testin kapsamı, testin çizelgelemesi, testin çıktıları, test stratetjisi, riskler ve çözüm yöntemleri konusunda detaylı bilgi veren bir dokümandır Test Seti (test suite): Test durumlarının bütününe test seti adı verilir. Bir test seti, test durumlarından daha fazla ayrıntıya sahip olabilir. Test durumlarının çalıştırılması için olması gereken önkoşullar, testin uygulanacağı sistemin konfigürasyon bilgileri test setinde yer alabilir.

Failure (Başarısızlık): Yazılımın kullanıcının ve müşterinin isteklerini yerine getirmemesi durumudur.

Fault (kusur): Programlama hatalarına denir. Kusur, başarısızlık olmak zorunda değildir. Kusur, yazılımın semantiğine bağlı olan bir hata olabilir. Bir kusur, farklı donanıma yüklendiğinde farklı derleyici ile çalışıtırıldığında başarısızlığa dönüşebilir.

Bug (Hata) : Yazılımın, istenilen şekilde çalışmasını engelleyecek, hatalı çalışmasına sebep olacak kusur, başarısızlık vs.

• ISO 9000:2008
• TS ISO/IEC 15504-1
• TS ISO/IEC 15504-2
• TS ISO/IEC 15504-3
• TS ISO/IEC 15504-4
• TS ISO/IEC 15504-5
• TS ISO/IEC 15504-6
• TS ISO/IEC 15504-7
• CMMI v1.2

Süreç projelerde aynen kullanılabilir veya kalite güvence uzmanının onayı alınarak, Proje Yönetim Planı ile proje gerekliliklerine göre uyarlanabilir. Bu durumda Proje Yönetim Planı değiştirilecek/uygulanmayacak maddeleri tam olarak tarif etmelidir. Bu süreçte geliştirme sürecinin farklı aşamalarında gerçekleştirilen test yöntemlerinden bahsedilmiştir. Projelerde kullanılan yazılım yaşam döngüsü ve projenin özelliklerine göre uygulanan test metotlarının kapsamı farklılık gösterebilir. Farklı test tipleri için ayrı test planları oluşturulabilir. Örneğin, regresyon testleri, entegrasyon testleri için test planı şablonu kullanılarak ayrı planlar hazırlanabilir. Test sürecinde kaç tane plan hazırlanacağı yöntemin ne olacağı proje yönetim planının teknik süreç planında belirtilmeli ya da belirtilen yere referans verilmelidir. Yazılım Test Planı standardı, test durumları ve test senaryoları şablonları tüm test tipleri için kullanılabilir.

Test Uzmanı: Gereksinimleri, kullanım durumlarını, müşteri ihtiyaçlarını ve tasarımı inceleyerek test durumlarını ve senaryolarını oluşturur. Test durumlarıyla, gereksinimler arasında izlenebilirlik kurar. Fonksiyonel testleri ve proje sonunda sistem testlerini gerçekleştirir. Bazı durumlarda, beyaz kutu testlerini de gerçekleştirebilir. Test sonuçlarını kayıt altına alır, düzeltilmesi için yazılım geliştirme ekibine iletir. Düzeltilen hataları yeniden test ederek hatanın giderildiğini doğrular. Müşteri kabul testlerine katılır. Test ortamı konfigürasyon ihtiyaçlarını belirler.

Sistem Analisti: Test sürecinin girdisi olan gereksinimleri ve senaryoları oluşturur. Test durumları hazırlanırken test uzmanına destek olur ve test durumlarının gözden geçirmesine katılır.

Proje Yöneticisi: Yapılacak testleri planlamaktan ve kapsamlarını belirlemekten, ilgili görevlendirme ve kaynakları sağlamaktan sorumludur. Test durumlarını gözden geçirir ve müşteriye onaylatır.

Tasarım ve Yazılım Geliştirme Uzmanı: Birim test durumlarını hazırlamaktan, test kapsamı belirlenirken proje yöneticisine teknik konular hakkında destek vermekten ve tasarım değişikliklerinde etkilenen test durumları ve riskli yazılım bileşenlerini bulup durumları önceliklendirmekten sorumludur. Testten dönen hataları düzeltip kayıt altına alır.

Konfigürasyon Yöneticisi: Test durumlarının konfigürasyonlarını takip etmekten, test planlarından temel oluşturup gelen değişiklikleri takip etmekten, test durumları ve diğer konfigürasyon öğeleri arasında izlenebilirlik sağlamaktan sorumludur. Test ortamı konfigürasyonunu ve işletim konfigürasyonunu takip etmekten sorumludur.

Kalite Güvence Uzmanı: Test sürecinin doğru işlediğini kontrol etmekten, sürecin uygulayıcılarına destek vermekten sorumludur.

• Gereksinim Yönetimi Süreci (HIZ.MUH.01)
• Tasarım Süreci (HIZ.MUH.02)
• Problem Yönetim Süreci ( HIZ.DES.06)
• Gerçekleştirim Süreci(HIZ.MUH.03)
• Entegrasyon Süreci (HIZ.MUH.04)
• Risk Yönetim Süreci (HIZ.YON.03

• Gerçekleştirim Süreci (HIZ.MUH.03)
• Problem Yönetim Süreci ( HIZ.DES.06)
• Risk Yönetim Süreci (HIZ.YON.03)

• Şartname
• Gereksinim Tanımlama Dokümanı(RPR-004-GTD)
• Yazılım Tasarım Tanımları Dokümanı (RPR-030-YTT)
• Yazılım ürünü
• Risk

Projede test aşamasında yapılacak işler, görevlendirmeler, test metodolojisiyle ilgili kararlar, kararların alınacağı zaman planı, uygulanacak test tipleri, test süreci proje planlama aşamasında proje yöneticisi, ilgili personel, müşteri ve diğer ilgililer tarafından karara bağlanır. Bu aşama test planı hazırlanmasından önce proje planlama aşamasında gerçekleştirilir. Proje planının, teknik süreç planı kısmında proje yöneticisi tarafından dokümante edilir.

Birim Test (Unit Test): Yazılım geliştirenlerin, kendi yazdıkları en küçük yazılım birimini test etmeleridir. Birim test, kaynak kodun doğrulamasını yapmak için yazılan bir programdır. Birim, yazılım uygulamasının test edilebilen en küçük parçasıdır. Yapısal programlamada birim, programın kendisi, web sayfası, prosedür, fonksiyon, menü olabilirken, nesneye yönelik programlamada birim her zaman sınıfa karşılık gelir. Birimler ve modüller arasındaki fark modüllerin birimden oluşmasıdır. Ideal olan, her bir test durumunun diğer test durumlarından bağımsız bir şekilde çalıştırılabilmesidir. Taklit nesne ve test araçları bu bağımsızlığı sağlayabilirler.

Entegrasyon Testi: Arayüzlere ait ve arayüzlerin birbirleriyle etkileşimden kaynaklanan hataları bulmak amacıyla yapılır. Entegrasyon testi, yazılım birimlerinin birleştirilmesinden sonra gerçekleştirilir. Birim testlerden sonra sistem testlerinden önce gerçekleştirilir. Entegrasyon testinde, birim testlerini tamamlamış modüller alınır, daha büyük modüller halinde gruplanır ve entegrasyon test planında belirtildiği şekilde test edilir. Entegrasyon testinden başarı ile geçmiş modüller sistem testine yollanır.

Fonksiyonel Testler: Ürünün gereksinimlerine uygun bir şekilde çalışıp çalışmadığını programlama detayına inmeden gerçekleştiren testlerdir. Testçi basitçe, programlama mantığını sorgulamadan yazılım ürününün işlevselliğini gerçekleştirip gerçekleştiremediğini sorgular. Fonksiyonel testler manuel ya da otomasyona geçirilmiş bir şekilde gerçekleştirilir.

Sistem Testi: Entegre edilmiş bir sistemin gereksinimlerini karşılayıp karşılamadığını kontrol eder. Sistem testi hem doğrulama hem sağlama tekniğidir. Sistem testi bir kara kutu ( black box) testidir. Yani testçinin yazılım tasarımından, programlama mantığından haberli olmasına gerek yoktur. Sistem testi yapabilmek için entegre edilmiş yazılım sisteminin ve donanım ortamının bulunması gerekir. Entegrasyon testi, entegre edilmiş komponentler arasında tutarsızlıkları ararken, sistem testi hem komponentler arasındaki hem de sistemin tümündeki tutarsızlık ve hataları arar. Sistem testi, yazılım gereksinim belirtimi (YGB)deki gereksinimler göz önünde bulundurularak yapılır. Sistem testi, sistemin hatasını bulmaya yönelik, sadece yazılım tasarımına yönelik olmayan aynı zamanda sistemin davranışına yönelik müşteri beklentilerini de göz önünde bulunduran bir test yöntemidir. Sistem testi, kabul testinden önce yapılan son hata bulmaya ve sistemi çökertmeye çalışan testtir.

Kabul Testi: Kabul testi genelde müşteri tarafından yapılan testtir. Son kullanıcı ya da müşterinin, yazılım ürününün müşterinin beklentilerini karşılayıp karşılamadığını test eder. Kabul testi de bir kara kutu (black box) test yöntemidir.

Alfa Testi: Alfa testi potansiyel kullanıcılar ya da bağımsız bir test ekibi tarafından gerçekleştirilen yazılımın işleyeceği ortamda ya da benzetiminde yapılan testtir. Alfa testi, yazılım beta testine gitmeden yapılan bir çeşit iç kabul testidir. Beta Testi: Beta testinde yazılım kısıtlı bir kullanıcı çevresine dağıtılır. Bu şekilde asıl ortamına çıkmadan yazılımda olası hataların giderilmesi hedeflenir. Alfa ve beta testi, test tekniklerinden bağımsız ve sistematik olmayan bir test yöntemidir. Burada kontrol edilen yazılımın çalıştığı ortam koşullarına göre hatalı çalışıp çalışmadığıdır.

Regresyon Testi: Yazılıma ait bir hata düzeltildiğinde yapılan değişikliklerin yazılımın geri kalanını etkileyip etkilemediğini kontrol etmek için yapılan testtir. Performans Testi: Belirli bir yük altında sistemin ne kadar hızlı çalışacağını kontrol eden testtir. Ölçeklenebilirlik ve güvenilirlik gibi sisteme ait diğer kalite gereksinimlerinin de testi bu şekilde sağlanır.

Yeniden Elde Etme Testi: Sistem değişik koşullarda test edilerek, hata oluşması koşulları zorlanır. Hata durumunda verilerin kaybedilmediği test edilir.

Dokümantasyon Testi: Dokümanlar kontrol edilerek içeriğin tam ve anlaşılır olduğu test edilir. Stres Testi: Sistemin yoğun işlem hacmi ve büyük miktarda veri girişi altında nasıl çalıştığı test edilir. Normalde beklenenden daha fazla kullanıcı ve daha yüksek miktarda veri ile sistem test edilerek zorlanır.

Güvenlik Testi: Sistemin ne kadar güvenilir olduğu test edilir. Bu testler sırasında sistemin değişik katmanlarında yer alabilecek gizli bilgilere istenilmeyen kişilerce erişilip erişilmediği test edilir.

Kurulum Testi: Kurulum testiyle ilgili bilgiler Kurulum ve İşletim planında belirtilmiştir.

Bu aşamada projede uygulanacak test stratejileri, test edilecek ve edilmeyecek özellikler, başarı ve başarısızlık kriterleri, uygulanacak test tipleri, roller ve sorumluluklar, test hata raporlama ve kayıt altına alma mekanizması belirlenir. Kullanılacak yazılım yaşam döngüsüne göre test planı bir kere hazırlanabileceği gibi her sürüm için de tekrar tekrar hazırlanabilir. Test durumları, gereksinimleri ve ilgili senaryoları kapsayacak şekilde test uzmanları ya da yazılımcılar tarafından hazırlanır. Test durumları için girdiler analiz modelinin oluşmaya başlamasıyla ortaya çıkar. Test durumları, analiz aşamasından entegrasyon aşamasının sonuna kadar güncellenerek oluşturulabilir. Kullanılan yazılım yaşam döngüsüne göre test durumlarının hazırlanmaya ne zaman başlanacağı proje yönetim planında ya da test planında belirtilir. Fonksiyonel, kapalı kutu testleri için hazırlanan test durumları gereksinimler oluştuktan sonra müşteriye sunulur. Müşteri test durumlarını onaylayarak kabul kriterlerini de oluşturmuş olur.

Sürümler oluşturulduktan sonra teste hazır olanlar test ortamına entegrasyon ya da konfigürasyon sorumlusu tarafından aktarılır. Projeler test planı ya da konfigürasyon yönetim planlarında test ortamına aktarım, sürümlerin kurulumuyla ilgili işleri ve sorumlulukları, zamanları tanımlarlar. Projede sürümler planlanan faz sonlarında, yeterli özelliği sağladıklarına kurulum ve işletim planları hazırlanır. Bu aşama kurulum ve işletim sürecinde belirtildiği şekilde kurulum ve işletim planları oluşturularak yapılır. Sürümler oluşturulduğunda ve ortamlara kurulmaya hazır olduklarında sürüm raporları hazırlanır. Bu sürüm raporları sürüm yönetim araçları tarafından otomatik sağlanabilir. Projeler işleyişlerini konfigürasyon planlarında ya da ilişkili planlarında açıklarlar. RPR-021-SR sürüm raporu test ortamına kurulan sürümler için oluşturulur.

Projede testin gerçekleşmesi ve yönetiminin sağlanması için ihtiyaç duyulan araçlar testler başlamadan kurulur

Test planı ve test durumları dokümanı proje içerisinde gözden geçirildikten sonra müşteriye sunulur. Müşteri test planıyla birlikte test durumlarını da gözden geçirir ve onaylar. Test durumları projenin çeşitli aşamalarında oluşturulursa müşteriden ara onaylar vermesi için durumlar müşteriye iletilir. Bu işlemin amacı müşterinin doğru gereksinimlerin üretildiğini ve doğru çalıştığını teyit etme yöntemini oluşturmasıdır. Test gözden geçirmede esas olarak gereksinimleri karşılayan test durumlarının var olup olmadığını kontrol etmek ve test aşaması planlanırken her test tipi için doğru stratejilerin planlandığını geçerlemektir. Test durumlarının gözden geçirilebilmesi için izlenebilirlik matrisinin oluşturulmuş olması gerekir.

Test durumları gerçekleştirildikçe testin başarılı ya da başarısız olma durumlarının ikisi de kayıt altına alınır. Hata dönen test sonuçları problem takip aracıyla kayıt altına alınır. İlgili yazılımcıya iletilir. Yazılımcı hatayı giderince test hata gidene kadar tekrar edilir Başarılı olan test durumları başarılı olarak loglanır. Test sonuç raporuyla ya da şartnamede istenen aralıklarla test raporu oluşturularak projenin ilgili taraflarına sunulur. Test sonuç raporu için RPR-027-TSR şablonu kullanılır. Test sonuç raporları, test ve sürüm yönetim araçları tarafından otomatik olarak da oluşturulabilir. Bu durum projelerin test planlarında belirtilmelidir.

Hangi gereksinimlerin test edilip edilmediğini takip etmek ve regresyon testlerinde kolaylık sağlamak amacıyla test durumları ile gereksinimler ve test edilen sürüm arasında izlenebilirlik sağlanır. Test durumlarıyla test sonuçları, test sonuçlarıyla test edilen ürün program arasında izlenebilirlik kurulur. İzlenebilirlik analiz, tasarım, kodlama ve planlama çıktıları arasında FRM.01’e uygun olarak oluşturulur. İzlenebilirlik sağlanması konfigürasyon ve değişiklik yönetimi araçları tarafından otomasyona geçirilebilir. İzlenebilirliğin kontrolünü konfigürasyon yöneticisi sağlar fakat aradaki KM’ler arasındaki bağları geliştirme ekibi, işi yapan kişiler yapmak durumundadır. Projeye ait izlenebilirlik mekanizması projenin konfigürasyon yönetim planında açıklanır.

Test aşamasından uygun olduğu onaylanarak çıkan yazılım ürünü geliştirme ekibi tarafından test ortamına kurulur. Müşteri kabul testini kendisi test durumlarını hazırlayarak ya da ŞİRKET tarafından hazırlanıp kendisinin onayladığı test durumları üzerinden gerçekleştirir. Kabul testi sonucunda müşteri ürünün gereksinimlerine uygun bir şekilde gerçekleştirildiğine karar verirse ürünü kabul eder. Kabul testi aşamasında tespit edilen uygunsuzluklar ve bunlar için yapılan değişiklikler için hata kayıtları açılır. Eğer müşterinin hataları bildirmek için kullanılan otomasyona erişimi varsa kendisi hata girişlerini yapabilir. Eğer yoksa ya da proje yönetim ve ilgili planlarda başka bir yöntemin kullanılacağı belirtilmişse o zaman hatalar toplantı tutanağıyla kaydedildikten sonra proje ekibi tarafından sisteme kaydedilir. Müşterinin bulduğu hatalar düzeltildikten sonra testler müşteri tarafından aksi müşteri tarafından belirtilmemişse tekrarlanır. Bu aşamada müşteri ile görüşme yapılırsa, toplantı tutanakları kullanılarak kayıt altına alınır.

Kullanım kılavuzları proje kullanıma hazır hale geldikten sonra projeyi gerçekleştiren personel tarafından hazırlanır ve müşteriye sunulur.(Kurulumla ilgili bilgiler Kurulum ve İşletim Planında yer almaktadır. (HIZ.MUH.06)

• Testten geçmiş sistem
• Test Planı RPR-025-TP
• Test Durumları RPR-024-TDD
• Test Sonuçları ve Raporu RPR-027-TSR
• Gereksinim İzlenebilirlik Matrisi FRM.01
• Sürüm Raporu RPR-021-SR
• Müşteri kabul test sonuçları

Test Uzmanının,

• Test yöntemleri
• Yazılım yaşam döngüsü
• Gereksinim analizi
• Konfigürasyon Yönetimi
• Kullanılacak araçlar hakkında bilgi sahibi olması gereklidir.

Yazılım Geliştirme Uzmanının,

• Birim testler
• Yazılım yaşam döngüsü
• Kullanılacak araçlar ve dokümantasyon
• Konfigürasyon yönetim hakkında bilgi sahibi olması gereklidir.

Tüm proje ekibinin,

•Test süreci hakkında bilgi sahibi olması gereklidir.

Test sürecini hızlandırmak için otomasyondan faydalanılmalıdır. Projeler farklı test tipleri için kullanacakları otomasyon araçlarını test planlarında belirtirler. Sürüm çıkarılırken JAVA projeleri için ANT vs. gibi sürüm çıkarma araçları kullanılır. ANT ve JUNIT entegre edilir. Bu şekilde eğer sürüm birim testlerden başarılı olarak geçmezse ANT sürümü oluşturmaz. Test sonuçları, ANTın raporundan alınır. ANT ve JUNIT entegrasyonu aşağıdaki bağlantıda anlatılmıştır: http://ant.apache.org/manual/OptionalTasks/junit.html JUNIT’te test durumu oluşturma, test sonuçları elde etme aşağıdaki bağlantıda anlatılmıştır: http://www.junit.org/junit/javadoc/3.8.1/index.htm Test için kullanılabilecek yöntemler prosedürün içerisinde anlatılmıştır. Projeler kullanacakları test yöntemlerini Yazılım Kalite Güvence Planında anlatırlar. Test sonuçları değişiklik yönetimi aracına girilebilmelidir. Mümkün olduğunca test sonuçları ve kodlama ortamı entegre edilebilir olmalıdır.

•MS Visual Studio Team System

•Parasoft Concerto

•Quality Center

•Bugzilla

•ERP

•TrackIT kullanılabilecek hata takip araçlarıdır.

Projeler mümkün olduğunca testlerini otomasyona geçirmelidirler. •QuickTest

•MS Visual Studio Team System

•http://www.parasoft.com/jsp/home.jsp araçları

Birim testler için

•JUNIT

•HTMLUNIT

•BPELUNIT

•DBUNIT

•NUNIT Vs

Fonksiyonel testler için

•Fitnesse www.fitnesse.org

•Selenium

olabilir.

Test Uzmanının

• Test yöntemleri
• Yazılım yaşam döngüsü
• Gereksinim analizi
• Konfigürasyon Yönetimi
• Kullanılacak araçlar hakkında bilgi sahibi olması gereklidir.

Yazılım Geliştirme Uzmanının,

• Birim testler
• Yazılım yaşam döngüsü
• Kullanılacak araçlar ve dokümantasyon
• Konfigürasyon yönetim hakkında bilgi sahibi olması gereklidir.

Tüm proje ekibinin,

•Test süreci hakkında bilgi sahibi olması gereklidir.

Test sürecini hızlandırmak için otomasyondan faydalanılmalıdır. Projeler farklı test tipleri için kullanacakları otomasyon araçlarını test planlarında belirtirler. Sürüm çıkarılırken JAVA projeleri için ANT vs. gibi sürüm çıkarma araçları kullanılır. ANT ve JUNIT entegre edilir. Bu şekilde eğer sürüm birim testlerden başarılı olarak geçmezse ANT sürümü oluşturmaz. Test sonuçları, ANTın raporundan alınır. ANT ve JUNIT entegrasyonu aşağıdaki bağlantıda anlatılmıştır: http://ant.apache.org/manual/OptionalTasks/junit.html JUNIT’te test durumu oluşturma, test sonuçları elde etme aşağıdaki bağlantıda anlatılmıştır: http://www.junit.org/junit/javadoc/3.8.1/index.htm Test için kullanılabilecek yöntemler prosedürün içerisinde anlatılmıştır. Projeler kullanacakları test yöntemlerini Yazılım Kalite Güvence Planında anlatırlar.

Test sonuçları değişiklik yönetimi aracına girilebilmelidir. Mümkün olduğunca test sonuçları ve kodlama ortamı entegre edilebilir olmalıdır.

•MS Visual Studio Team System

•Parasoft Concerto

•Quality Center

•Bugzilla

•ERP

•TrackIT kullanılabilecek hata takip araçlarıdır.

Projeler mümkün olduğunca testlerini otomasyona geçirmelidirler.

•QuickTest

•MS Visual Studio Team System

•http://www.parasoft.com/jsp/home.jsp araçları

Birim testler için

•JUNIT

•HTMLUNIT

•BPELUNIT

•DBUNIT •NUNIT Vs

Fonksiyonel testler için •Fitnesse www.fitnesse.org •Selenium olabilir.

Test planları, test durumları, test logları ve raporları Word dokümanı olarak hazırlanmışsa proje sitesinde (FTP Sunucu) saklanır ve konfigürasyon kontrolü altına alınır. Hata kayıtları ve diğer kayıtlar ŞİRKET ’da var olan ERP otomasyon araçlarıyla kayıt altına alınıyorsa bu araçların sağladığı konfigürasyon yönetim olanakları kullanılır ve kayıtların değişiklik tarihçesi ve iş akışı takip edilebilir. Test durumları, hata kayıtları ve diğer konfigürasyon maddeleri arasındaki ilişki izlenebilirlik matrisiyle takip edilir. Konfigürasyon kontrolü altındaki konfigürasyon öğelerine değişiklik yönetimi uygulanır.

Test sürecinin kontrolü projelere yapılan iç denetimlerle yapılır. Ortaya çıkan düzeltici ve önleyici faaliyet istekleri incelenerek süreç performansı değerlendirilir. Eğer düzeltici faaliyetlerin oranı yapılan denetimlere ve soru sayılarına göre yüksekse projede süreç uygulanmıyor olabilir. Bu durumda projede gereksinim yönetim performansını değerlendirmek mümkün olmaz. Bu durumda sürecin neden uygulanmadığı araştırılır Düzeltici faaliyetler az ve süreç uygulanıyorsa, bu durumda veri toplanarak sürecin performansı değerlendirilir. Süreç etkin uygulandığı durumda, yazılım bileşenleri homojen şekilde test edilmiş, risk yönetimi test planlama için uygulanmış, yazılım müşteri kabulüne sunulmadan kritik hataların hepsi tespit edilmiş ve düzeltilmiş, müşterinin kullanımındayken sistemde oluşan kritik hata olmamalıdır. Bu azlık, çokluk değerleri proje aşamalarında ya da geçmiş projelere bakılarak ya da projenin şartnamesine ve proje ekibinin kararına göre proje planlama aşamasında belirlenir ve ölçüm planına yansıtılır Süreç performansı, veriler yıllık olarak tüm süreçlerden alınarak kalite grubu tarafından değerlendirilir ve kalite yönetim sistemi performans raporuna yansıtılır. Bu raporda süreçlerle ilgili iyileştirme önerileri sunulur. Yönetim kurulu, proje yöneticileri, kalite ekibi iyileştirme önerileri için önceliklendirme yapıp plan hazırlarlar. Öncelik verilen süreçler veya hedefler için süreç iyileştirme çalışması başlatılır ve takip edilir. Bu çalışmanın sonunda değerlendirme yapmak için sağlıklı veri bulunmadığı yorumu da çıkabilir. O zaman verilerin doğru değerlendirilebilmesi için metrik toplamaya devam edilmesine ve sürecin izlenmesine karar verilir.