User:Nesrindag/Yazılım test taktikleri

Bu makale, yazılım testinde(software testing) yararlı olan bir dizi taktiği tartışmaktadır. Yazılım kalite güvencesine(software quality assurance) (genellikle kalite güvencesi(quality assurance) olarak bilinir ve geleneksel olarak "QA" kısaltmasıyla anılır) ve genel olarak test yönteminin(test method) uygulanmasına (genellikle sadece "test" veya bazen "geliştirici testi" olarak adlandırılır) yönelik taktik yaklaşımların kapsamlı bir listesi olarak hazırlanmıştır.

Kurulum Testi

Main article: Installation testing

Kurulum testi, sistemin doğru bir şekilde yüklendiğini ve gerçek müşteri donanımında çalıştığını garanti eder.

Kutu Yaklaşımı

Yazılım test yöntemleri geleneksel olarak beyaz kutu testi ve kara kutu testi olarak ikiye ayrılır. Bu iki yaklaşım, bir test mühendisinin test senaryolarını tasarlarken aldığı bakış açısını tanımlamak için kullanılır.

Beyaz Kutu Testi

Main article: White-box testing

Beyaz kutu testi (aynı zamanda açık kutu testi, cam kutu testi, şeffaf kutu testi ve yapısal test olarak da bilinir, kaynak kodu görerek yapılır) bir programın işlevselliğinden ziyade, iç yapısını veya çalışma şeklini test eder. Beyaz kutu testinde, sistemin içsel bir perspektifi ve programlama becerileri kullanılarak test senaryoları tasarlanır. Test yapan kişi, kod içerisindeki yolları çalıştırmak ve uygun çıktıları belirlemek için girdiler seçer. Bu, devre üzerindeki düğümleri test etmeye, örneğin devre içi test (ICT) yapmaya benzer.

Beyaz kutu testi, yazılım test sürecinin birim(unit), entegrasyon(integration) ve sistem(system) seviyelerinde uygulanabilse de, genellikle birim seviyesinde yapılır. Birim içindeki yolları, entegrasyon sırasında birimler arasındaki yolları ve sistem seviyesindeki bir test sırasında alt sistemler arasındaki yolları test edebilir. Bu test tasarımı yöntemi birçok hata veya problemi ortaya çıkarabilse de, uygulanmamış kısımları veya eksik gereksinimleri tespit edemeyebilir.

Beyaz kutu testinde kullanılan teknikler şunlardır:

• API testi(API testing) – Uygulamanın, kamuya açık ve özel API'ler (uygulama programlama arayüzleri) kullanılarak test edilmesi.
• Kod kapsama(Code coverage) – Kod kapsama kriterlerini karşılamak için testler oluşturma (örneğin, test tasarımcısı, programdaki tüm ifadelerin en az bir kez yürütülmesini sağlamak için testler oluşturabilir).
• Hata enjekte etme yöntemleri(Fault injection methods) – Test stratejilerinin etkinliğini ölçmek için kasıtlı olarak hataların tanıtılması.
• Mutasyon testi yöntemleri(Mutation testing methods)
• Statik test yöntemleri(Static testing methods)

Kod kapsama araçları, siyah kutu testleri de dahil olmak üzere herhangi bir yöntemle oluşturulmuş bir test setinin tamamlanma derecesini değerlendirebilir. Bu, yazılım ekibinin nadiren test edilen sistem parçalarını incelemesine olanak tanır ve en önemli işlev noktalarının(function points) test edildiğinden emin olmasını sağlar. Kod kapsama, bir yazılım metriği(software metric) olarak şu şekilde yüzde olarak raporlanabilir:

• Fonksiyon kapsama, yürütülen fonksiyonlar hakkında rapor veren kapsama türüdür.
• İfade kapsama, testi tamamlamak için yürütülen satır sayısı hakkında rapor veren kapsama türüdür.
• Karar kapsama, belirli bir testin hem Doğru hem de Yanlış dalının yürütülüp yürütülmediği hakkında rapor veren kapsama türüdür.

%100 ifade kapsaması, tüm kod yollarının veya dallarının (kontrol akışı-control flow- açısından) en az bir kez yürütüldüğünü garanti eder. Bu, doğru işlevselliğin sağlanmasında faydalıdır, ancak aynı kodun farklı girdileri doğru veya yanlış bir şekilde işleyebilmesi nedeniyle yeterli değildir.

Siyah kutu testi

Main article: Black-box testing

Black box diagram

Siyah kutu testi, yazılımı bir 'siyah kutu' olarak ele alır, iç uygulama hakkında herhangi bir bilgiye sahip olmadan, kaynak kodunu görmeden işlevselliği inceler. Test edenler, yazılımın ne yapması gerektiğini bilirler, ancak nasıl yaptığını bilmezler. Siyah kutu test yöntemleri arasında şunlar yer alır: eşdeğer sınıflandırma(equivalence partitioning), sınır değer analizi(boundary value analysis), tüm çiftler testi(all-pairs testing), durum geçiş tabloları(state transition tables), karar tablosu testi(decision table), fuzz testi(fuzz testing), model tabanlı test(model-based testing,), kullanım senaryosu testi(use case testing), keşif testi(exploratory testing) ve spesifikasyon tabanlı test.

Spesifikasyon tabanlı test, yazılımın uygulanabilir gereksinimlere göre işlevselliğini test etmeyi amaçlar. Bu seviyedeki testler genellikle test eden kişiye sağlanması gereken kapsamlı test senaryoları(test cases) gerektirir; böylece test eden kişi, belirli bir girdi için çıkış değerinin (veya davranışının) test senaryosunda belirtilen beklenen değerle 'aynı olup olmadığını' doğrulayabilir. Test senaryoları, uygulamanın ne yapması gerektiği yani spesifikasyonlar ve gereksinimler etrafında oluşturulur. Bu testler, test senaryolarını türetmek için yazılımın dış tanımlarını, spesifikasyonları, gereksinimleri ve tasarımları kullanır. Bu testler işlevsel veya işlevsel olmayan (functional or non-functional) olabilir, ancak genellikle işlevseldir.

Spesifikasyon tabanlı test, doğru işlevselliği sağlamak için gerekli olabilir, ancak karmaşık veya yüksek riskli durumlara karşı koruma sağlamak için yeterli değildir.

Siyah kutu tekniğinin bir avantajı, herhangi bir programlama bilgisi gerektirmemesidir. Programcıların sahip olduğu önyargılar ne olursa olsun, test eden kişi muhtemelen farklı bir önyargı setine sahiptir ve işlevselliğin farklı alanlarına vurgu yapabilir. Öte yandan, siyah kutu testinin 'fener olmadan karanlık bir labirentte yürümek gibi' olduğu söylenmiştir. Kaynak kodunu incelemedikleri için, bir test eden kişi bazen sadece bir test senaryosuyla kontrol edilebilecek bir şeyi kontrol etmek için birçok test senaryosu yazabilir veya programın bazı bölümlerini test etmeden bırakabilir.

Bu test yöntemi, yazılım testinin tüm seviyelerine: birim(unit), entegrasyon(integration), sistem(system) ve kabul(acceptance) testine uygulanabilir. Genellikle, daha yüksek seviyelerdeki testlerin çoğunu, hatta hepsini kapsar, ancak birim testlerinde de baskın olabilir.

Görsel test

Görsel testin amacı, yazılım hatası meydana geldiği anda geliştiricilere neler olduğunu inceleme yeteneği sağlamaktır. Bu, verilerin geliştiricinin ihtiyaç duyduğu bilgiyi kolayca bulabileceği şekilde sunulması ve bilginin net bir şekilde ifade edilmesiyle gerçekleştirilir.

Görsel testin temelinde, bir problemi (veya bir test hatasını) sadece tarif etmek yerine birine göstermek, netlik ve anlayışı büyük ölçüde artırır fikri yer almaktadır. Bu nedenle görsel test, tüm test sürecinin kaydedilmesini gerektirir; bu, test sisteminde meydana gelen her şeyi video formatında yakalamayı içerir. Çıktı videoları, görüntü içinde görüntü (picture-in-picture) web kamerası aracılığıyla gerçek zamanlı test eden girişi ve mikrofonlardan alınan sesli yorumlarla desteklenir.

Görsel test, bir dizi avantaj sunar. Test edenler, problemi (ve ona neden olan olayları) geliştiriciye gösterebildiği için iletişimin kalitesi büyük ölçüde artar; bu da durumu sadece tarif etmekten çok daha etkilidir ve birçok durumda test hatalarını tekrarlama ihtiyacı ortadan kalkar. Geliştirici, bir test hatasıyla ilgili ihtiyaç duyduğu tüm kanıtlara sahip olacak ve bunun yerine hatanın nedenine ve nasıl düzeltileceğine odaklanabilecektir.

Görsel test, yazılım geliştirmede çevik yöntemlerin(agile methods) uygulandığı ortamlara özellikle uygundur, çünkü çevik yöntemler test edenler ile geliştiriciler arasında daha fazla iletişim ve küçük ekipler içinde iş birliği gerektirir.

Ad hoc testi(Ad hoc testing) ve keşif testi(exploratory testing), yazılım bütünlüğünü kontrol etmek için önemli metodolojilerdir, çünkü uygulanmaları için daha az hazırlık süresi gerektirir ve önemli hatalar hızlı bir şekilde bulunabilir. Ad hoc testinde, testin doğaçlama ve anlık bir şekilde gerçekleştirildiği durumlarda, bir test aracının sistemde meydana gelen her şeyi görsel olarak kaydetme yeteneği, hatayı bulmak için atılan adımların belgelenmesi açısından çok önemlidir.

Görsel test, müşteri kabul(customer acceptance) ve kullanılabilirlik testlerinde(usability testing) tanınmaya başlıyor, çünkü bu test, geliştirme sürecine dahil olan birçok birey tarafından kullanılabilir. Müşteri için, ayrıntılı hata raporları ve geri bildirim sağlamak kolaylaşır ve program kullanıcıları için görsel test, ekran üzerindeki kullanıcı eylemlerini, ayrıca ses ve görüntülerini kaydederek yazılım hatası anında geliştiricilere tam bir görünüm sunabilir.

Daha detaylı bilgi için: Graphical user interface testing

Gri kutu testi

Main article: Gray box testing

Gri kutu testi, testleri tasarlamak amacıyla iç veri yapıları ve algoritmalar hakkında bilgi sahibi olmayı içerir, ancak bu testler kullanıcı veya siyah kutu düzeyinde yürütülür. Test edenin, yazılımın kaynak koduna tam erişime sahip olması gerekmez. Girdi verilerini manipüle etmek ve çıktıyı biçimlendirmek gri kutu testi olarak sayılmaz, çünkü girdi ve çıktı, test ettiğimiz sistem olarak adlandırdığımız 'siyah kutunun' dışında net bir şekilde yer alır. Bu ayrım, iki farklı geliştirici tarafından yazılan iki kod modülü arasında entegrasyon testi(integration testing) yaparken özellikle önemlidir; burada yalnızca arayüzler test için açığa çıkar.

Ancak, bir arka uç veri deposunu (örneğin bir veritabanı veya bir günlük dosyası) değiştirmeyi gerektiren testler gri kutu testi olarak kabul edilir, çünkü kullanıcı normal üretim işlemlerinde genellikle veri deposunu değiştirme yeteneğine sahip değildir. Gri kutu testi ayrıca, örneğin, sınır değerleri veya hata mesajlarını belirlemek için tersine mühendislik(reverse engineering) yapmayı da içerebilir.

Yazılımın nasıl çalıştığına dair temel kavramları bilmek, test edenin yazılımı dışarıdan test ederken daha iyi bilgiye dayalı test seçimleri yapmasını sağlar. Genellikle, bir gri kutu test edicisinin, bir veritabanını(database) beslemek gibi faaliyetlerle izole bir test ortamı kurmasına izin verilir. Test eden, veritabanına karşı SQL ifadeleri çalıştırma gibi belirli işlemler gerçekleştirdikten sonra test edilen ürünün durumunu gözlemleyebilir ve ardından beklenen değişikliklerin yansıtıldığından emin olmak için sorgular çalıştırabilir. Gri kutu testi, sınırlı bilgilere dayanarak akıllı test senaryoları uygular. Bu durum, özellikle veri türü yönetimi, istisna yönetimi(exception handling) gibi konularda geçerlidir.

Otomatik test

Main article: Test automation

Pek çok programlama grubu, özellikle test odaklı geliştirme (test-driven development) kullanan gruplar, otomatik testlere(automated testing) giderek daha fazla bağımlı hale geliyor. Test yazmak için birçok çerçeve bulunmaktadır ve sürekli entegrasyon(continuous integration) yazılımı, kod bir sürüm kontrol(version control) sistemine her kontrol edildiğinde testleri otomatik olarak çalıştıracaktır.

Otomasyon, bir insanın yapabileceği her şeyi (ve bunu yapmanın düşündüğü tüm yolları) yeniden üretemezken, regresyon testi için oldukça faydalı olabilir. Ancak, gerçekten faydalı olabilmesi için iyi geliştirilmiş bir test senaryosu setine(test suite) ihtiyaç duyar.

Otomatik test araçları

Program testi ve hata tespiti, test araçları ve hata ayıklayıcılar (debuggers) ile önemli ölçüde desteklenebilir. Test/hata ayıklama araçları şunları içerebilir:

• Program monitörleri, program kodunun tam veya kısmi izlenmesine izin verir ve şunları içerir:
  • Talimat seti simülatörü(Instruction set simulator), tam talimat düzeyinde izleme ve izleme olanakları sağlar.
  • Hiper yönetici (hypervisor), program kodunun yürütülmesi üzerinde tam kontrol sağlar ve şunları içerir:
  • Program animasyonu(program animation), kaynak düzeyinde veya makine kodunda(machine code) adım adım yürütme ve koşullu durdurma noktası (breakpoint) sağlamaktadır.
  • Kod kapsama(code coverage) raporları
• Biçimlendirilmiş döküm veya sembolik hata ayıklama(symbolic debugging), hata durumunda veya seçilen noktalarda program değişkenlerinin incelenmesine olanak tanıyan araçlardır.
• Otomatik işlevsel GUI (Grafiksel Kullanıcı Arayüzü) test araçları, GUI üzerinden sistem düzeyinde testleri tekrarlamak için kullanılır.
• Karşılaştırma standartları (benchmarks), çalışma zamanı performans karşılaştırmalarının yapılmasına olanak tanır.
• Performans analizi(performance analysis) (veya profil oluşturma araçları), yoğun alanları(hot spots) ve kaynak kullanımını vurgulamaya yardımcı olabilir.

Bu özelliklerin bazıları, tek bir bileşik araç veya Entegre Geliştirme Ortamı (IDE - Integrated Development Environment) içine entegre edilebilir.

Otomatik teste uygulanan uygulama katmanlarının soyutlanması

Genellikle dört tanınan test seviyesi vardır: birim testi, entegrasyon testi, bileşen arayüz testi ve sistem testi. Testler, sıklıkla yazılım geliştirme sürecinde eklenme yerlerine veya testin spesifiklik seviyesine göre gruplandırılır. SWEBOK kılavuzunda tanımlanan geliştirme sürecindeki ana seviyeler, test hedefine göre ayrılan birim, entegrasyon ve sistem testidir; belirli bir süreç modelini ima etmez. Other test levels are classified by the testing objective.

Müşteriler perspektifinden iki farklı test seviyesi vardır: düşük seviyeli test (LLT) ve yüksek seviyeli test (HLT). LLT, yazılım uygulamasının veya ürününün farklı seviyedeki bileşenleri için bir test grubudur. HLT ise, tüm yazılım uygulaması veya ürünü için bir test grubudur.

Birim testi

Main article: Unit testing

Birim testi, genellikle işlev düzeyinde, belirli bir kod bölümünün işlevselliğini doğrulayan testlere atıfta bulunur. Nesne yönelimli(object-oriented) bir ortamda, bu genellikle sınıf düzeyindedir ve minimum birim testleri, yapıcılar (constructors) ve yıkıcılar (destructors) içerir.

Bu tür testler genellikle geliştiriciler tarafından kod üzerinde çalışırken (beyaz kutu tarzında) yazılır, böylece belirli bir işlevin beklendiği gibi çalıştığından emin olurlar. Bir işlevin, köşe durumlarını(corner cases) veya kod içindeki diğer dalları yakalamak için birden fazla testi olabilir. Birim testi tek başına bir yazılım parçasının işlevselliğini doğrulamaz; bunun yerine, yazılımın yapı taşlarının birbirinden bağımsız olarak çalıştığından emin olmak için kullanılır.

"Geliştirme testi", yazılım geliştirme sürecinde, yazılım geliştirme risklerini, zamanını ve maliyetlerini azaltmak amacıyla geniş bir hata önleme ve tespit stratejileri yelpazesesinin senkronize uygulanmasını içeren bir süreçtir. Yazılım geliştirici veya mühendis tarafından, yazılım geliştirme yaşam döngüsünün inşa aşamasında gerçekleştirilir. Geleneksel kalite güvencesi (QA) odaklarını değiştirmek yerine, bunları tamamlar. Geliştirme testi, kodun QA'ya aktarılmadan önce inşa hatalarını ortadan kaldırmayı amaçlar; bu strateji, elde edilen yazılımın kalitesini artırmayı ve genel geliştirme ile QA sürecinin verimliliğini yükseltmeyi hedefler.

Kuruluşun yazılım geliştirme beklentilerine bağlı olarak, geliştirme testi statik kod analizi(static code analysis), veri akış analizi, metrik analizi, eş kod incelemeleri, birim testi, kod kapsama analizi, izlenebilirlik ve diğer yazılım doğrulama uygulamalarını içerebilir.

Entegrasyon testi

Main article: Integration testing

Entegrasyon testi, yazılım tasarımına karşı bileşenler arasındaki arayüzleri doğrulamayı amaçlayan her türlü yazılım testidir. Yazılım bileşenleri, yinelemeli bir şekilde veya hepsi bir arada ('büyük patlama') entegre edilebilir. Normalde, ilk yöntem daha iyi bir uygulama olarak kabul edilir çünkü arayüz sorunlarının daha hızlı bir şekilde tespit edilmesini ve düzeltilmesini sağlar.

Entegrasyon testi, entegre bileşenler (modüller) arasındaki arayüzlerde ve etkileşimlerdeki hataları ortaya çıkarmayı amaçlar. Mimari tasarımın unsurlarına karşılık gelen, test edilen yazılım bileşenlerinin giderek daha büyük grupları entegre edilip test edilerek yazılım bir sistem olarak çalışana kadar devam eder.

Bileşen arayüz testi

Bileşen arayüz testi uygulaması, bu birimler arasındaki tam entegrasyon testinin ötesinde, çeşitli birimler veya alt sistem bileşenleri arasında iletilen verilerin işlenmesini kontrol etmek için kullanılabilir. Geçen veriler 'mesaj paketleri' olarak düşünülebilir ve bir birimden üretilen veriler için aralık veya veri türleri kontrol edilebilir ve başka bir birime geçmeden önce geçerliliği test edilebilir. Arayüz testinin bir seçeneği, iletilen veri öğelerinin ayrı bir günlük dosyasını tutmaktır; genellikle analiz için zaman damgası kaydedilir ve bu sayede birimler arasında günler veya haftalar boyunca iletilen binlerce veri durumu incelenebilir. Testler, bazı aşırı veri değerlerinin işlenmesini kontrol etmeyi içerebilirken, diğer arayüz değişkenleri normal değerler olarak iletilebilir. Arayüzdeki alışılmadık veri değerleri, bir sonraki birimde beklenmeyen performansı açıklamaya yardımcı olabilir. Bileşen arayüz testi, bir alt sistem bileşeninin yalnızca ilgili eylemlerinin ötesinde, veri değerlerine odaklanan bir siyah kutu(black-box testing), testinin bir varyasyonudur.

Sistem testi

Main article: System testing

Sistem testi, tamamen entegre bir sistemi test ederek sistemin gereksinimlerini karşıladığını doğrular. Örneğin, bir sistem testi, bir giriş arayüzünü test etmeyi, ardından bir kayıt oluşturmayı ve düzenlemeyi, sonuçları göndermeyi veya yazdırmayı, ardından kayıtların özet işlenmesini veya silinmesini (veya arşivlenmesini) ve son olarak çıkışı (logoff) içerebilir.

Operasyonel kabul testi

Main article: Operational acceptance testing

Operasyonel kabul, bir ürün, hizmet veya sistemin operasyonel hazır olduğunu (ön sürüm) belirlemek amacıyla kalite yönetim sisteminin(quality management system) bir parçası olarak kullanılır. OAT, yazılım geliştirme(software development) ve yazılım bakım(software maintenance) projelerinde yaygın olarak kullanılan bir tür işlevsel olmayan yazılım testidir. Bu tür test, desteklenecek sistemin operasyonel(operational readiness) hazır olmasına ve/veya üretim ortamının bir parçası haline gelmesine odaklanır. Bu nedenle, operasyonel hazır olma testi (ORT) veya Operasyonların hazır olma ve güvence (Operations readiness and assurance - OR&A) testi olarak da bilinir. OAT içindeki işlevsel testler(Functional testing), sistemin işlevsel olmayan yönlerini doğrulamak için gereken testlerle sınırlıdır.

Ayrıca, yazılım testleri, sistemin taşınabilirliğini sağlamakla birlikte beklendiği gibi çalıştığından emin olmalı; ayrıca, işletim ortamını zarar vermemeli veya kısmen bozarak o ortam içindeki diğer süreçlerin çalışmaz hale gelmesine neden olmamalıdır.

Uyumluluk testi

Main article: Compatibility testing

Yazılım hatalarının (gerçek veya algılanan) yaygın bir nedeni, diğer uygulama yazılımları(application software), işletim sistemleri(operating systems) (ya da işletim sistemi sürümleri-versions-, eski veya yeni) veya orijinalden büyük ölçüde farklı hedef ortamlarla uyumsuzluğudur(compatibility). (Örneğin, masaüstünde(desktop) çalıştırılması amaçlanan bir terminal veya GUIuygulamasının şimdi bir web uygulaması(web application) haline gelmesi gerektiğinde, bu durum geçerlidir ve uygulamanın bir web tarayıcısında(web browser) render edilmesi gerekmektedir.) Geriye dönük uyumluluğun(backward compatibility) eksikliği durumunda, bu durum, programcıların yazılımı yalnızca hedef ortamın en son sürümünde geliştirip test etmesinden kaynaklanabilir; bu da tüm kullanıcıların çalıştırmadığı bir sürüm olabilir. Bu, en son çalışmanın, hedef ortamın daha önceki sürümlerinde veya önceki sürümlerin kullanabildiği daha eski donanımlarda çalışmamasına neden olan istenmeyen bir sonuç doğurur. Bazen bu tür sorunlar, işletim sistemi işlevselliğini ayrı bir program modülüne(module) veya kütüphaneye(library) proaktif bir şekilde soyutlayarak(abstracting) düzeltilebilir.

Smoke ve sağlamlık testi

Sağlamlık testi(Sanity testing), daha fazla test yapmanın mantıklı olup olmadığını belirler.

Smoke testi(Smoke testing), yazılımı çalıştırmak için minimum denemelerden oluşur ve yazılımın çalışmasını tamamen engelleyecek temel sorunların olup olmadığını belirlemek için tasarlanmıştır. Bu tür testler, derleme doğrulama testi(build verification test) olarak da kullanılabilir.

Regresyon testi

Main article: Regression testing

Regresyon testi, büyük bir kod değişikliği sonrası hataları bulmaya odaklanır. Özellikle, yazılım regresyonlarını(software regressions), yani degrade olmuş veya kaybolmuş özellikleri, eski hataların geri döndüğünü ortaya çıkarmayı hedefler. Bu tür regresyonlar, yazılım işlevselliğinin daha önce doğru çalıştığı durumların, artık istenildiği gibi çalışmamaya başlaması durumunda meydana gelir. Genellikle regresyonlar, program değişikliklerinin istenmeyen bir sonucu(unintended consequence) olarak ortaya çıkar; yeni geliştirilen yazılım bileşeni, daha önce mevcut olan kodla çakıştığında oluşur. Regresyon testinin yaygın yöntemleri arasında, önceki test vakalarının yeniden çalıştırılması ve daha önce düzeltilmiş hataların tekrar ortaya çıkıp çıkmadığının kontrol edilmesi bulunmaktadır. Testing derinliği, sürüm sürecinin aşamasına ve eklenen özelliklerin riskine bağlıdır. Değişiklikler, sürümün sonlarına doğru eklenmiş veya riskli olarak değerlendirilmişse, testler tamamen kapsamlı olabilir; eğer değişiklikler sürümün başında yapılmış veya düşük riskli olarak değerlendiriliyorsa, her bir özellik için yalnızca pozitif testlerden oluşan çok yüzeysel testler yapılabilir. Regresyon testi, ticari yazılım geliştirmede genellikle en büyük test çabasını gerektirir; çünkü önceki yazılım özelliklerindeki çok sayıda ayrıntının kontrol edilmesi gerekir. Hatta yeni yazılım geliştirilirken, önceki işlevselliğin hala desteklendiğinden emin olmak için bazı eski test vakaları kullanılabilir.

Kabul testi

Main article: Acceptance testing

Kabul testi iki anlamına gelebilir:

1. Bir smoke testi, yeni bir sürümü ana test sürecine dahil etmeden önce, yani entegrasyon(integration) veya regresyon(regression) öncesinde kabul testi olarak kullanılır.
2. Müşteri tarafından, genellikle kendi laboratuvar ortamlarında kendi donanımları üzerinde gerçekleştirilen kabul testine kullanıcı kabul testi (user acceptance testing- UAT) denir. Kabul testi, geliştirme sürecinin herhangi iki aşaması arasındaki devretme sürecinin bir parçası olarak da yapılabilir.

Alpha testi

Alpha testi, potansiyel kullanıcılar/müşteriler veya bağımsız bir test ekibi tarafından geliştiricilerin sitesinde gerçekleştirilen simüle edilmiş veya gerçek operasyonel testlerdir. Alpha testi, yazılımın beta testine geçmeden önce, genellikle raf ürünleri için iç kabul testi şeklinde kullanılır.

Beta testi

Beta testi, alpha testinden sonra gelir ve dış kullanıcı kabul testinin(user acceptance testing) bir biçimi olarak değerlendirilebilir. Beta sürümleri(beta versions) olarak bilinen yazılım versiyonları, beta tester olarak adlandırılan programlama ekibinin dışındaki sınırlı bir kitleye sunulur. Yazılım, ürünün daha az hata veya bug(bugs) içermesini sağlamak için daha fazla test yapılabilmesi amacıyla insan gruplarına dağıtılır. Beta sürümleri, geri bildirim(feedback) alanını maksimum sayıda gelecekteki kullanıcıya genişletmek ve değeri daha erken sunmak için halka açık hale getirilebilir; bu süre uzatılabilir veya sınırsız bir süre (sürekli beta) olarak devam edebilir.

Fonksiyonel Test vs. Fonksiyonel Olmayan Test

Fonksiyonel test, kodun belirli bir eylemini veya işlevini doğrulayan faaliyetleri ifade eder. Bu testler genellikle kod gereksinimleri belgelerinde yer alır; ancak bazı geliştirme metodolojileri, kullanım senaryoları veya kullanıcı hikayeleri üzerinden çalışır. Fonksiyonel testler, genellikle "kullanıcı bunu yapabilir mi?" veya "bu belirli özellik çalışıyor mu?" sorularını yanıtlamaya odaklanır.

Fonksiyonel olmayan test, yazılımın belirli bir işlev veya kullanıcı eylemiyle doğrudan ilişkili olmayan yönlerini ifade eder; örneğin, ölçeklenebilirlik(scalability), performans(performance,), belirli kısıtlar(constraints) altındaki davranış veya güvenlik(security) gibi. Bu testler, aşırı ölçeklenebilirlik veya performansın dengesiz çalışmaya neden olduğu kırılma noktasını belirler. Fonksiyonel olmayan gereksinimler genellikle ürünün kalitesini yansıtan gereksinimlerdir ve özellikle kullanıcıların uygunluk perspektifinde önem taşır.

Sürekli Test

Main article: Continuous testing

Sürekli test, yazılım teslimat sürecinin bir parçası olarak otomatik testlerin(automated tests) yürütülmesi sürecidir; bu, bir yazılım sürüm adayının iş riskleri hakkında anında geri bildirim almak için kullanılır. Sürekli test, hem fonksiyonel(functional requirements) hem de fonksiyonel olmayan(non-functional requirements) gereksinimlerin doğrulanmasını içerir; test kapsamı, alt düzey gereksinimlerin veya kullanıcı hikayelerinin doğrulanmasından, genel iş hedefleriyle ilişkili sistem gereksinimlerinin değerlendirilmesine kadar uzanır.

Yıkıcı Test

Main article: Destructive testing

Yıkıcı test, yazılımın veya bir alt sistemin başarısız olmasını sağlamaya yönelik bir çabadır. Yazılımın, geçersiz veya beklenmedik girişler aldığında bile düzgün çalıştığını doğrulayarak, giriş doğrulama ve hata yönetimi rutinlerinin dayanıklılığını(robustness) belirler. Yazılım hata enjeksyonu(Software fault injection), fuzzing biçiminde bir örnektir. Ticari olarak çeşitli fonksiyonel olmayan test araçları, yazılım hata enjeksyonu(Software fault injection) sayfasından bağlantılıdır; ayrıca yıkıcı test gerçekleştiren birçok açık kaynak ve ücretsiz yazılım aracı da mevcuttur.

Further information: Exception handling and Recovery testing

Yazılım Performans Testi

Main article: Software performance testing

Performans testi, genellikle bir sistemin veya alt sistemin belirli bir yük altında yanıt verme süresi ve stabilite açısından nasıl performans gösterdiğini belirlemek amacıyla gerçekleştirilir. Ayrıca, sistemin ölçeklenebilirliği, güvenilirliği ve kaynak kullanımı gibi diğer kalite özelliklerini incelemek, ölçmek, doğrulamak veya onaylamak için de kullanılabilir.

Yük testi(Load testing), sistemin belirli bir yük altında (ister büyük veri miktarları ister çok sayıda kullanıcı-users) çalışmaya devam edebilmesini test etmeye odaklanır. Bu genellikle yazılım ölçeklenebilirliği(scalability) olarak adlandırılır. İlgili yük testi etkinliği, fonksiyonel olmayan bir aktivite olarak gerçekleştirildiğinde genellikle dayanıklılık testi (endurance testing) olarak anılır. Hacim testi(Volume testing), yazılım işlevlerini belirli bileşenlerin (örneğin bir dosya veya veritabanı) boyutunun radikal bir şekilde arttığı durumlarda test etme yöntemidir. Stres testi(Stress testing), beklenmedik veya nadir yükler altında güvenilirliği test etmenin bir yoludur. Stabilite testi (genellikle yük veya dayanıklılık testi olarak adlandırılır), yazılımın kabul edilebilir bir süre içinde ya da üzerinde sürekli olarak iyi çalışıp çalışmadığını kontrol eder.

Performans testinin belirli hedefleri konusunda pek az fikir birliği vardır. Yük testi, performans testi, ölçeklenebilirlik testi ve hacim testi terimleri genellikle birbirinin yerine kullanılır.

Gerçek zamanlı(real-time software) yazılım sistemleri, katı zamanlama kısıtlamalarına sahiptir. Zamanlama kısıtlamalarının karşılanıp karşılanmadığını test etmek için gerçek zamanlı testler(real-time testing) kullanılır.

Kullanılabilirlik Testi

Kullanılabilirlik testi(Usability testing), kullanıcı arayüzünün kullanımı ve anlaşılması kolay olup olmadığını kontrol etmektir. Esas olarak uygulamanın kullanımı ile ilgilidir.

Erişilebilirlik testi

Erişilebilirlik(accessibility) testi, aşağıdaki gibi standartlara uyumu içerebilir:

• Americans with Disabilities Act of 1990
• Section 508 Amendment to the Rehabilitation Act of 1973
• Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)

Güvenlik testi

Güvenlik testi(security testing), sistemin hackerlar tarafından(system intrusion by hackers.) saldırıya uğramasını önlemek için gizli verileri işleyen yazılımlar için hayati öneme sahiptir.

Uluslararası Standardizasyon Örgütü (ISO), bunu "bir test nesnesinin ve ilgili veri ile bilgilerin, yetkisiz kişilerin veya sistemlerin bunları kullanmasını, okumasını veya değiştirmesini engelleyecek şekilde korunma derecesini değerlendirmek amacıyla gerçekleştirilen bir test türü" olarak tanımlar.

Uluslararasılaştırma ve Yerelleştirme Testi

Yazılımın uluslararasılaştırma ve yerelleştirme(internationalized and localized) yeteneği, gerçek çeviri olmadan otomatik olarak test edilebilir; bu süreçte sahte yerelleştirme (pseudolocalization) kullanılır. Bu yöntem, uygulamanın yeni bir dile çevrildikten veya yeni bir kültüre (örneğin, farklı para birimleri veya saat dilimleri) uyarlanmış olmasına rağmen hala çalıştığını doğrular.

Gerçek dillerdeki çevirilerin de test edilmesi gerekmektedir. Olası yerelleştirme hataları şunları içerebilir:

• Yazılım genellikle bağlamdan bağımsız olarak bir dizi dizeyi (strings) çevirerek yerelleştirilir ve çevirmen, belirsiz bir kaynak dizesi için yanlış bir çeviri seçebilir.
• Teknik terimler, proje birkaç kişi tarafından doğru koordinasyon olmadan veya çevirmen dikkatsizse tutarsız hale gelebilir.
• Kelime kelime yapılan çeviriler, hedef dilde uygunsuz, yapay veya çok teknik görünebilir.
• Orijinal dildeki bazı mesajlar, kaynak kodda yerleşik (hard coded) bırakılabilir.
• Bazı mesajlar, çalışma zamanında (run time) otomatik olarak oluşturulabilir ve sonuçta ortaya çıkan dize dil bilgisel olarak hatalı, işlevsel olarak yanlış, yanıltıcı veya kafa karıştırıcı olabilir.
• Yazılım, kaynak dilin klavye düzeninde işlevi olmayan bir kısayol tuşu(keyboard shortcut) kullanabilir, ancak bu tuş hedef dilin klavye düzeninde(keyboard layout) karakter yazmak için kullanılmaktadır.
• Yazılım, hedef dilin karakter kodlamasını(character encoding) desteklemiyor olabilir.
• Kaynak dilde uygun olan fontlar ve font boyutları, hedef dilde uygun olmayabilir; örneğin, CJK characters, font çok küçükse okunamaz hale gelebilir.
• Hedef dildeki bir dize, yazılımın işleyebileceğinden daha uzun olabilir. Bu, dizeyi kullanıcının göremeyeceği şekilde kısmen görünmez hale getirebilir veya yazılımın çökmesine veya işlevsiz hale gelmesine neden olabilir.
• Yazılım, çift yönlü metni (bi-directional text) okumak veya yazmak için doğru desteklemeyi sağlamıyor olabilir.
• Yazılım, yerelleştirilmemiş metin içeren görüntüleri görüntüleyebilir.
• Yerelleştirilmiş işletim sistemleri, farklı isimlendirilmiş sistem yapılandırma dosyaları(configuration file) ve ortam değişkenleri(environment variable) ile farklı tarih(formats for date) ve para(currency) formatlarına sahip olabilir.

Geliştirme testi

Main article: Development testing

Birim testi, yazılım geliştirme sürecidir ve yazılım geliştirme risklerini, zamanını ve maliyetlerini azaltmak amacıyla geniş bir hata önleme ve tespit stratejilerinin senkronize bir şekilde uygulanmasını içerir. Yazılım geliştiricisi veya mühendisi tarafından yazılım geliştirme yaşam döngüsünün inşa aşaması sırasında gerçekleştirilir. Geleneksel kalite güvence (QA) odaklarını değiştirmek yerine, bunları tamamlar. Birim testi, kodun QA'ya terfi etmeden önce inşa hatalarını ortadan kaldırmayı amaçlar; bu strateji, sonuçta ortaya çıkan yazılımın kalitesini artırmayı ve genel geliştirme ve QA sürecinin verimliliğini artırmayı hedefler.

Kuruluşun yazılım geliştirme konusundaki beklentilerine bağlı olarak, birim testi statik kod analizi(static code analysis), veri akış analizi(data-flow analysis), metrik analizi, eş kod incelemeleri, kod kapsama(code coverage) analizi ve diğer yazılım doğrulama(software verification) uygulamalarını içerebilir.

A/B testi

Main article: A/B testing

A/B testi, temelde iki çıktının karşılaştırılmasıdır; genellikle yalnızca bir değişkenin değiştiği durumlarda uygulanır: bir test çalıştırılır, bir şey değiştirilir, test tekrar çalıştırılır ve sonuçlar karşılaştırılır. Bu yöntem, daha küçük ölçekli durumlarda daha faydalı olsa da, herhangi bir programın ince ayarını yapmak için oldukça etkilidir. Daha karmaşık projelerde ise çok değişkenli testler (multivariant testing) gerçekleştirilebilir.

Eşzamanlı Test

Main article: Concurrent testing

Eşzamanlı testlerde, stres testi veya tüy testinin aksine, normal girdiyle ve normal çalışma koşullarında sürekli çalışırken performansa odaklanılır. Bellek sızıntılarının yanı sıra temel hataları da bu yöntemle bulmak daha kolaydır.

Uyum testi veya Tür testi

Main article: Conformance testing

Yazılım testinde, uyum testi bir ürünün belirlenen standartlara göre performans gösterip göstermediğini doğrular. Örneğin, derleyiciler, o dil için tanınmış standartları karşılayıp karşılamadığını belirlemek amacıyla kapsamlı bir şekilde test edilir.