Kaoru İshikawa - Balık Kılçığı Tekniği

BALIK KILÇIĞI TEKNİĞİ
Ishikawa diagramı olarak da bilinen balık kılçığı tekniği, 1943’te Kaoru İshikawa tarafından geliştirilmiştir. Teknik, bir problemin (nükleer patlama, seçim, öğrenme güçlükleri, gençlerin suç işlemesi gibi) nedenlerini ve alt nedenlerini tanımlama sürecini yapılandırmaya yardım edebilir. Ayrıca, tüm öğrencilerin derin ve nesnel bir görüş kazanmalarını ve problemin çeşitli bölümleri arasında ki önemli ilişkileri görmesini, öğrencilerin daha derin bir şekilde bir problem üzerinde yoğunlaşmasını sağlar. Problem çözme tekniklerinden biri olan bu teknik, öğrencilerin düşüncelerini organize etmeye yardım eder; ancak, problem için çözümler sağlamaz. İlginç bir teknik olan balık kılçığı tekniği öğrenmesi ve uygulaması kolaydır. Bu teknik; birlikte çalışmayı, gerçeği aramayı, değişik görüşlere açık olmayı ve karşıt görüşlerin ortaya çıkmasını sağlar.

Balık kılçığı tekniğinin adımları;
Problemi tanımlama: Ele alınacak problem hakkında kısa bir bilgi verilir.
Nedenler üretme: Yapılandırılmamış beyin fırtınası tekniğini kullanma ( bu probleme neden olan faktörler nelerdir? Bu nedenler arasındaki ilişkiler nelerdir? Gibi sorular üzerinde beyin fırtınası yapılabilir).
Yapılandırılmış beyin fırtınası tekniğini kullanma: (Round Robin 6-3-5,6 kişi 5 dakikada 3 fikir sunması).

Balık kılçığı diyagramını oluşturma;
Bir kâğıdın üzerine yönü sağa doğru olan bir ok çizilmeli ve açıklanacak konunun başlığı, ‘’balığın omurgası’’ temsil eden okun üzerine yazılmalıdır. Daha sonra balığın omurgasına 45 derecelik açıyla oklar çizilir ve okların üzerine ana nedenler yazılır ve ana nedene de oklar çizilerek bu nedenlerin detayları kısaca açıklanır.

Aşağıdaki şekilde balık kılçığı diyagramının genel şeması görülmektedir;

Balık kılçığı tekniğinin etkili kullanılabilmesi için;
1. Tekniğe başlamadan önce herkesin problem üzerinde hem fikir olduğundan emin olun.
2. Kısa ve öz sözcükler kullanın.
3. Nedenlerin ne olabileceğini düşünün ve onu okların üzerine ekleyin.
4. Nedenlerin ayrıntılarını üzerine ekleyin.
5. Herkesin birbirinin görüşüne saygılı olmasını sağlayın.

Aşağıdaki şekilde balık kılçığı diyagramında öğrenci performansının düşmesine neden olan etkenler görülmektedir;

Vilfredo Pareto - 80-20 kuralı

Pareto ilkesi (80-20 kuralı önemli azın yasası ve etken seyrekliliği ilkesi olarak da bilinir) der ki, çoğu olay için, etkilerin kabaca % 80′i etkenlerin % 20′sinden kaynaklanır.

İş yönetimi düşünürü Joseph M. Juran bu ilkeyi önermiş ve İtalya’nın % 80 arazisinin sahibinin nüfusun % 20′si olduğunu gözleyen İtalyan ekonomist Vilfredo Pareto‘nun adıyla isimlendirmiştir. İş dünyasında yaygın bir kuraldır; örn. “satışların % 80′i müşterilerin % 20′sinden gelir.” Matematiksel olarak, yeterince büyük bir sayıda katılımcının paylaştığı bir şey olması durumunda, her zaman 50 ile 100 arasında öyle bir k sayısı olacaktır ki % k, % (100 – k) katılımcı tarafından paylaşılmış olsun. Fakat k, eşit dağılım olan 50′den, küçük sayıda katılımcının kaynakların neredeyse tamamına sahip olduğu 100′e kadar değişebilir. 80 sayısı ile ilgili özel bir durum yoktur, fakat çoğu sistemde dağılımda dengesizliğin orta noktası olan bu civarda bir k değeri görülür.
Pareto ilkesi, aynı ekonomist, Vilfredo Pareto, tarafından ortaya konulan Pareto verimliliği ile sadece yüzeysel olarak ilgilidir. Pareto her iki kavramı da nüfustaki gelir ve zenginlik dağılımı bağlamında geliştirmiştir.

Ekonomide
Başlangıçta gözlenenler gelir ve zenginlik ile bağlantılıydı. Pareto, İtalya'nın % 80 zenginliğinin nüfusun % 20'ne ait olduğunu farketti. Daha sonra diğer ülkelerdeki araştırmaları inceledi ve benzer bir dağılımın olduğunu şaşkınlıkla gözlemledi.

Güç yasası ilişkisinin büyüklükle değişmeyen doğası nedeniyle, bu ilişki gelir sınıflarının diğer altkümelerinde de geçerlidir. Dünyanın en zengin on insanını bile düşünsek, görüyoruz ki en yüksek üçü (Warren Buffett, Carlos Slim Helú ve Bill Gates) diğer yedisinin toplamı kadar mal varlığına sahiptir.

'Şampanya bardağı' etkisi adı verilen, eşitsizliği gözle görülebilir ve anlaşılabilir şekilde ortaya koyan eğri, dünyanın gelirinin % 82.7'sini kontrol edenlerin nüfusun % 20'sini oluşturduğunu ortaya koyan ve küresel gelirin dağılımının büyük dengesizliğini gösteren 1992 Birleşmiş Milletler Gelişme Programı Raporu'nda yer almaktaydı.

Dünya GSMH'sinin dağılımı; 1989


Pareto İlkesi aynı zamanda ABD'deki artan ekonomik eşitsizliğin 'beceri-önyargılı teknik değişim' ile ilişkisini vurgulamak için kullanılmaktadır - yani gelir artışı yeni teknolojilerden ve küreselleşmeden yararlanmak için gereken eğitim ve becerilere sahip olanların payına düşmektedir. Fakat, Paul Krugman New York Times'ta bu "80-20 yanılgısı"na, son 30 yıldaki ekonomik büyümenin yararlarının en büyük % 20'den çok en büyük % 1'de yoğunlaştığından yola çıkarak "doğru olduğu için değil, ama rahatlatıcı" diyerek izin vermiştir.

Matematiksel notlar
Bu fikrin birçok alanda uygulaması vardır, ama genellikle yanlış uygulanır. Örneğin bir soruna bulunan çözüm için sadece durumların % 80'ine uyduğu için "80-20 kuralına uyar" diye düşünülürse hata yapılmış olur, aynı zamanda çözüm, kaynakların sadece % 20'sini gerektirmelidir.
Matematiksel olarak, yeterince büyük sayıda katılımcının paylaştığı bir şey için, her zaman % k'nın katılımcıların % (100 - k) kadarı tarafından paylaşıldığı, 50 ile 100 arasında bir k sayısı olacaktır, fakat k değeri eşit dağılımdaki 50'den (örn. insanların % 50'sinin kaynakların % 50'sine sahip olduğu) çok küçük sayıda katılımcının neredeyse kaynakların tamamına sahip olduğu yaklaşık 100'e kadar değişebilir. 80 sayısıyla ilgili özel bir durum yoktur, ama çoğu sistem dağılımdaki dengesizlikte ortalamayı temsil eden bu aralıkta bir k değerine sahiptir.

Bu, Pareto dağılımının özel bir durumudur. Eğer Pareto dağılımındaki parametreler uygun seçilirse, sadece etkilerin % 80'i nedenlerin % 20'sinden kaynaklanmaz aynı zamanda bu % 80 etkinin en yüksek % 80'i de % 20 nedenin en yüksek % 20'sinden kaynaklanır ve bu böyle devam eder (% 80'in % 80'i % 64'tür, % 20'nin % 20'si % 4'tür, böylece bir "64-4 yasası" ortaya çıkar).

İş hayatında 80-20 sadece genel bir ilke için kısayoldur. Ayrı ayrı durumlarda, dağılım aynı şekilde 80-10 ya da 80-30 gibi de olabilir. (İki sayının toplamının % 100 olması gerekmez, çünkü bunlar farklı şeylerin ölçüleri olabilirler, örn. 'müşteri sayısı'na karşılık 'harcanan miktar'). Klasik 80-20 dağılımı eşit ölçekli eksenlere sahip log-log üzerine çizildiğinde eğrinin eğiminin -1 olduğu durumda ortaya çıkar. Pareto kuralları birbirini dışlayan değildir. Aslında 0-0 ve 100-100 kuralları herzaman doğrudur.

100'e toplamak hoş bir simetriye yol açar. Örneğin, eğer etkilerin % 80'i kaynakların en yüksek % 20'sinden geliyorsa, o zaman kalan % 20 etki daha düşük % 80 kaynaktan gelmektedir. Buna "birleşik oran" denir ve dengesizliğin derecesini ölçmek için kullanılabilir: 96:4 birleşik oranı çok dengesizken, 80:20 büyük ölçüde dengesiz (Gini indeksi: % 60), 70:30 ise orta düzeyde dengesiz (Gini indeksi: % 40) ve 55:45 sadece biraz dengesizdir.

Pareto İlkesi aynı zamanda ufak orman yangınlarında ve depremlerde de görülen "Güç yasası"nın bir gösterimidir. Geniş bir büyüklük menzilinde kendine benzerlik gösterdiği için Gauss Dağılımı fenomeninden çok farklı çıktılar gösterir. Bu gerçek, -örneğin- borsa hareket büyüklüklerinin Gauss ilişkisine uygun olduğu varsayılımıyla modellenen karmaşık finansal araçların sık çöküşünü açıklar.

Test Sürecinin Aşamaları

Planlama ve Kontrol
Planlama aşaması test misyonu, amaçları ve aktivitelerinin belirlenmesini, test kontrol
aşaması ise test planından sapmaların raporlanması ve bu sapmalardan kaynaklanabilecek
sorunlar için gerekli tedbirlerin alınmasını kapsamaktadır.

Analiz ve Tasarım
Test altyapısı ve test ortamına ilişkin detaylar belirlenmekte, test case’lere baz teşkil edecek
olan test tasarımları yapılmaktadır.

Testin Uygulanması
Test tasarımları test case’lere dönüştürülmekte, test ortamı ve test script’ler (testware)
oluşturulmakta ve uygulamaya alınmakta, buglar düzeltilinceye kadar regression testleri
yapılmaktadır.

Testin Sonlandırılması ve Raporlanması
Planlamada test için belirlenen misyon ve amaçlara ulaşılıp ulaşılamadığı kontrol edilmekte, sonuçlar üst yönetime raporlanmaktadır.

Testin Kapatılması
Sonlandırılan testlerin sonuçları birleştirilerek test projesinin kapatılma kararı verilmekte,
Kapatılan teste ilişkin dokumanlar ve test scriptleri diger testlerde kullanılmak üzere
arşivlenmektedir.

Testlerin Sınıflandırılması

Yazılım testinin en önemli amaçlarından birisi kusurları, eksiklikleri belirlemektir. Yazılım testinde kusurlar; gereksinim ya da kullanıcı beklentisinde oluşacak uyuşmazlıklar olarak tanımlanabilir. Bu basit tanımlamadan sonra, kusurları kolay bir biçimde sınıflandırabiliriz.
Örneğin;
• Eğer sistem işlevsel olarak uygun değilse, bu bir işlevsel kusurdur.
• Eğer sistem performans olarak iyi değilse, bu bir performans kusurudur.
• Eğer sistem kullanılabilir değilse, bu bir kullanılabilirlik kusurudur.
• Eğer sistem güvenilir değilse, bu bir güvenlik kusurudur.

Bu değişik kusurları tanımlamak; değişik yetenek kümesine, değişik tekniklere ve değişik türde test durumlarına gereksinim duymaktadır. Testlerin değişik türlere bölünmesini amacı; ne çeşit kusurların bu aktivitelerle ortaya çıkarılabileceğidir. Ayrıca, tüm test türlerinde birisinin yetenekli olması çok nadirdir. Bu bölünme ile yazılım takımında bir ya da birkaç türde farklı kişilerin uzmanlaşması sağlanarak kaynak kullanımı daha uygun bir biçimde olması sağlanır.

Yazılım Yük - Performans Testi Nedir ?

Yazılımların yük ve performans testlerinde en iyi sonuca ulaşarak müşteri memnuniyeti sağlamak ve karlılığını artırmak için gerçekleştirilen test aktiviteleridir. Ürünün lansmanı yapılmadan önce, kurulan sistemin maksimum sayıda kulanıcı ile işlem yaptığında dahi işlemlerin her birinin hedeflenen zaman biriminde, eksiksiz bir şekilde gerçekleştirildiğinin ispatlanması gerekmekdedir. Bu isbatı ancak performans testi sonuçları ile müşteriye garanti edebiliriz. 

Temel olarak 3 çeşit performas testi gerçekleştirilebilir. 

Normal Performans Testi: Web uygulamalarının normal şartlar altındaki performans seviyelerinin belirlenmesi.
Load Testi: Web uygulamasının giderek artan sayıda(sistem çökene kadar) virtual user'lar ile yüklenilerek sistemin sınırlarının ölçülmesi.
Stress Testi: Maksimum sayıdaki kullanıcı ile periyodik bir şekilde sisteme yüklenilmesi.

Testlerin Sonuçlarının Raporlanması

Test sonuçları Yazılım Test Raporları ile raporlanmakta ve ilgili kişilere duyurulmaktadır.
Testler sırasında tespit edilen hatalar, Hata Takip aracına girilmekte ve problemin ilgili kişiye atanmasından
doğrulanmasına kadar bu araç üstünden takibi gerçekleştirilmektedir.
Hataların kayıt altına alındığı Hata Takip araçları raporlama konusunda birçok olanak sunmaktadır.
Hata Takip aracına girilen bir yazılım hatası, yazılım sorumlusu tarafından incelenmekte, yazılımda gerekli
düzeltme yapıldıktan sonra girilen hatanın düzeltildiği aynı araç yoluyla bildirilmektedir.
Yine aynı araç üzerinden hatanın düzeltildiği bilgisini alan test sorumlusu hatanın gerçekten düzeltildiğini
yazılımın yeni sürümü üzerinde ilgili testi tekrar gerçekleştirerek hatanın giderilip giderilmediğini
doğrulamaktadır.
Özetle, test sorumlusu ile yazılım sorumlusu arasındaki hata takibi, Hata Takip aracı kullanılarak yapılmaktadır.
Böylelikle hataların sağlıklı bir şekilde kayıt altına alınması sağlanmaktadır.

Yeterlilik testlerinin tamamlanmasının ardından test kayıtları kullanılarak Yazılım Test Raporu hazırlanır. Test raporları YKB sorumluları ve kalite temsilcileri tarafından incelenerek YKB yeterlilik testinin tamamen yapılıp yapılmadığı, YKB'nin yeterliliği ve Sistem/Alt Sistem Entegrasyon ve Test aşamasına hazır olup olmadığı değerlendirilir.

Testlerin Gerçekleştirilmesi

Kodun hazır olduğunun duyurulmasını takiben YKB Yeterlilik testleri gerçekleştirilmeye başlanır.

Bu amaçla süreçte şu adımlar tanımlanmıştır;

* Test tanımları ve test araçları olgunlaştırılır.
* Yazılım gereksinimlerinden test tanımlarına izlenebilirlik kontrol edilir.
* YKB ile üzerinde koşacağı DKB (Donanım Konfigürasyon Birimi) hedef prototipi ve test yazılım ve araçlarının bir araya getirilmesiyle bir test düzeneği kurulur.
* Test tanımları çerçevesinde YKB’nin yeterlilik testleri gerçekleştirilir. Hata oluşması durumunda problemlerin çözülmesi amacıyla ilgili sürece geçilir ve süreç işletilir.

Testler gerçekleştirilmeye başlanmadan önce ortamın (test konfigürasyonunun) testlere hazır olup olmadığının kontrolünün yapılması gereklidir. Hazırlanan test yazılımlarının testler öncesinde doğrulanmış olması önem taşımaktadır. Resmi testler öncesi test edilecek yazılımın test ortamına entegrasyonun gerçekleştirildiği ve yazılımın testlere hazır olup olmadığının kontrolü duman (smoke) testleri aracılığıyla yapılır. Bu testler, test edilecek yazılımın en temel yeteneklerini doğrulayan test tanımları arasından seçilmelidir. Ancak bu testler başarılı olarak gerçekleştirilirse, resmi olarak testlere başlanmalıdır.

Testlerin hangi sırayla yapılacağı doğrulanan testlerin kritikliği ve testlerin fonksiyonel olarak birbirleri ile olan bağlantılarıyla alakalı olabilir. Bu sıranın ne olacağına test planlama aşamasında karar verilmeli ve onaylanmalıdır.

Yazılıma yapılan ekleme veya düzeltmeler yeni hatalara sebep olabilmektedir. Bu hataların tespit edilmesi ve olası gerilemenin belirlenmesi amacıyla yapılan testler regresyon (gerileme) testleridir. Herhangi bir değişiklik sonucunda, yeni sürümü yapılan yazılımın regresyon testlerinde, sadece yeni sürümdeki değişiklik bilgisinin incelemesi sonucunda gerekli olduğunu belirlenen testler yapılabilir.

Testin gereklilik nedenleri

Yazılım Defectlerinin Nedenleri

* İnsanlar hata yaparlar, bu hatalar kodda, yazılımda, sistemde ya da dokümanda defect oluşturur.

* Defect olan kod çalıştırıldığında sistem yapması bekleneni gerçekleştiremez ve başarısız olur.

* Yazılımda, sistemde ya da dokümandaki defectler başarısızlıklara neden olur, ama her defect başarısızlık yaratmak durumunda değildir.

* İnsanlar yanılabilir olduklarından, zaman baskısı altında çalıştıklarından, kodların ve alt yapının karmaşıklığından, değişen teknolojiler nedeniyle ya da bir den çok sistemin iç içe girmesi nedeniyle defectler oluşur.

* Çevresel koşullar donanımda arızalara neden olabilir.

Testin Yazılım Geliştirme, Bakım Ve Operasyonlardaki Rolü
* Sistemler ve operasyonlar yoğun olarak test edildiğinde tespit edilen defectler sürüm öncesi çözüldüğünde, operasyonlar sırasında oluşacak problem riskleri azalır ve yazılım sisteminin kalitesi artar.

* Yazılım testi ayrıca, sözleşmesel ve yasal gereksinimler ile, endüstriye özgü standartların da karşılanmasını sağlar.

Test ve Kalite
* Test, fonksiyonel ve fonksiyonel olmayan gereksinimler (kullanışlılık, güvenilirlik, sürdürülebilirlik vb) ve özellikler için tespit edilen defectler yoluyla yazılımın kalitesinin ölçülmesine yardımcı olur.

* Test sırasında az sayıda ya da hiç defect bulunmaması, teste konu yazılımın kalitesi konusunda güvence sağlar. Düzgün tasarlanmış ve tamamlanmış testler, sistemin genel risk seviyesini azaltır. Test sırasında tespit edilen defectlerin çözümlenmesi, yazılım sisteminin kalitesini yükseltir.

* Önceki projelerden dersler çıkarılmalıdır. Diğer projelerdeki defectlerin nedenleri doğru olarak anlaşılırsa, süreçler geliştirilebilir ve aynı defectlerin tekrarı önlenebilir ve gelecekteki sistemlerin kalitesi artırılabilir. Bu kalite güvencenin bir yüzüdür.

Ne Kadar Test Yeterlidir ?
* Ne kadar testin yeterli olacağına karar vermek için, teknik ve iş anlamında risk seviyesini, zaman ve bütçe gibi proje kısıtlarını dikkate almak gerekir.

Hata Düzeltme Maliyeti

 

Yazılım testleri geçmişi

. . . – 1956 Hata ayıklama ile yazılım testi arasında
net bir ayrım yoktu.

1957 – 1978 Hata ayıklama ve yazılım testi kavramları
ayrı ayrı işlenmeye başladı. Yazılımın gereksinimlere
uyduğu yazılım testleri ile kontrol
edilmeye başlanmıştır.

1979 – 1982 Yazılım geliştirmede temel amaç hata
ayıklaması haline gelmiştir.

1983 – 1987 Yazılımın kullanım süresi boyunca
kullanımı gözetlenmiş ve kalite testlerine tabi tutulmuştur.

1988 – günümüz Yazılım testleri, yazılımın belirtimlere uyduğunu test etmenin yanı sıra, hataları bulma ve hataları engelleme gibi amaçlara hizmet etmeye başlamıştır. Günümüz yazılım test kültürünün temel dayanak noktaları olan IEEE’nin test dokümanlari standardı 2 ve ”The Complete Guide of Software Testing” kitabının üretimi bu döneme denk gelir.

IE 8.0'da Hp Quality Center çalıştırılması

İe 8.0'da Qc'yi açmak istediğinizde, açılamadığını görmek sizi üzüntüye sürüklemesin çünkü bunun çözümü
var;

1.yol;
İnternet explorer'dan
- internet seçenekleri - gelişmiş - güvenlik sırası takip edilerek ulaşılan listede;
“Çevrimiçi saldırıların azaltılmasına yardımcı olmak için bellek korumayı etkinleştir” (Enable memory protection to help mitigate online attacks)
tiki işaretliyse kaldırılır. Tüm IE 8 pencereleri kapatılıp yeniden açılır.

Not: Bu alan pasif ve değiştirilemez durumda ise;
Alanı aktifleştirmek için işletim sisteminizi(Win7) test moduna almanız gerekmektedir, bu işlemi Komut satırına
bcdedit -set TESTSIGNING off yazıp çalıştırmak ve ardından bilgisayarınızı yeniden başlatmak suretiyle gerçekleştirmiş olursunuz. Not: Bu işlemin başarılı bir şekilde gerçekleşmesi için
bilgisayarınızda local admin olmanız gerekmektedir.

2.yol;
Hp'nin hazırladığı plug-in leri kurmak;
QC 9.0 için
QC 9.2 için

İyi testler

Test eğitimleri ve sertifikasyonu

ISTQB'nin Foundation Level(başlangıç) ve Advanced Level(ileri seviye) eğitimlerini almış biri olarak şunları söyleyebilirim;
Eğitim süresi dışarıdan bakıldığında kısa görünüyor(3gün) fakat bana göre katma değeri yüksek bir eğitim.
Eğitim Test Mühendisi olarak hergün uğraştığımız işlerin bir sunumundan ibaret gibi gelebilir ama işin profesyonel boyuttada böyle yapıldığını görmek kendinize ve işinize karşı bir ispat niteliği taşıyor...
3 günlük eğitimlerin ardından uygulanan sınav bu işte tecrübe edinmiş kişilerin pekte zorlanmadan geçebileceği türden. Benim fikrim eğitimlerin alınması yönünde.

Uluslararası düzeydeki eğitim programları ve sertifikasyonlarını veren kurumlar şunlardır;
ISQTB - http://www.istqb.org/
CSTE -   http://www.qaiglobal.com/
CSTP -   http://www.testinginstitute.com/
CTM -    http://www.testinginstitute.com/ctm.php
CSQA -  http://www.qaiindia.com/Certification/note.htm
CSPM -  http://www.qaiindia.com/Certification/note_cspm.htm
CSPE -   http://www.qaiasia.com/edistacertification/Certification.asp

White Box Testing

Beyaz Kutu (white box) test tekniği;
Bu test tekniğinin en genel tabiri kod testidir. Projenin hem kaynak kodu, hemde derlenmiş kodu test edilir.

White-Box Test Metodları

Birim Test: Çalışan bir kod parçası ya da modül için, geliştiriciler tarafından gerçekleştirilir.Düşük seviyede işlem gerçekleştirir.
  
Statik ve Dinamik Analiz: Statik analiz kodu sıralı bir şekilde inceler ve hataları araştırır. Dinamik analiz,kodun çalışmasını ve çıktıyı analiz eder.
  
Açıklama Kapsamı: Açıklamaların test edilmesiyle ilgilenir.Her bir açıklama en az bir kez test edilir. Tüm açıklamaların sorun yaşamadan çalıştığını garanti altına alır.
  
Sınıf Kapsamı: Hiçbir yazılım uygulaması sürekli olarak kodlanmaz, bazı noktalarda, kodun dağılışı incelemeli ve belirli bir fonksiyonu çalıştırılmalıdır. Tüm sınıflar doğrulanmasına yardım eder ve uygulamanın anormal davranış göstermesini engeller.

Güvenlik Testi: Sistemin izinsiz erişimler, kod bozulması, hacklenme gibi olaylardan nasıl korunacağı ile ilgilenir. Karmaşık test metotları gerekir.
Değişim Testi: Belirli bir hata düzeltildikten sonra yapılan bir testtir.Hangi kodun, stratejinin geliştirmeye yardımcı olacağını belirlemeyi sağlar.

Avantajları

• Kodun optimizasyonunu sağlar.
• Ekstra kod parçasını kaldırır ve tek bakışta gözükmeyen sorunları ortaya çıkarır.
• Hangi verinin kodu en iyi şekilde test edeceğini tespit eder.

Dezavantajları

• Belirli özelliklere sahip test yapıldığında maliyet artar.
• Kodun inceleyip tek tek hata bulmak çok zor bir işlemdir.

Bazı testler hem White-Box hem de Black-Box kapsamında incelenebilir. Bunlara örnek verecek olursak;

Fonksiyonellik Testi:Kodla birlikte fonksiyonelliği test eder.
Birleştirme Testi:Uygulamaya yeni eklenen kod ile işbirliği yapar.
Performans ve Yükleme Testi:Kodun hangi kısmının sistemin kaynaklarını yönettiğini ve performansı verilişini belirler.

Black Box Testing

Kara-Kutu Yapı Taşları Test Uygulaması

Kara-Kutu test uygulaması yazılımın tipine bakmaksızın seçtiği test yöntemini uygulayan yazılım test tekniklerinden
oluşur. Kara-Kutu test tekniği girdi olarak uygulanabilir bir yapı taşı (Component) ve bir varsayımla işe başlar.
Her program girdisinden sonra oluşan çıktı kontrol edilir , hata meydana gelmiş ise bu teknik aracılığı ile
belirlenir.

Kara kutu test uygulaması , yazılımın satın alındığı firma tarafından bu test uygulamasına tabi tutulduğu bildirilse
dahi yine de yapılmalıdır.

Kara-Kutu testindeki başarıda en önemli etken ortaya konan varsayımdır. Kötü planlanan bir varsayım tam ters bir
sonucun doğmasına neden olabilir. Ancak bu varsayımın hazırlanması gerçekten güç bir konudur. Bununla ilgili
çözümler piyasada bulunmaktadır. Ancak en uygun yol satın alan kuruluşun bu konuyu bizzat kendisinin belirlemesidir.

Çok önemli bir diğer nokta da kuruluşun test çalışmalarını firmanın ileri sürdüğü özelliklere karşı değil kendi
belirlediklerine karşı yürütmesidir. Zira sonuçta yazılım satıcı firma için değil kurumun gereksinmeleri için
geliştirilecektir.

Kara-Kutu test uygulaması temelde ilk kez B.P.Miller tarafından yine kendisinin geliştirdiği Fuzz Model de
kullanıldı. Fuzz Model kara-kutu için girdileri rastgele olarak yürütür ve bunları UNIX sistem fonksiyonları içine
gönderir ve oluşan hataları gözler. Ancak bu gözlemlerin yazılımın problemlerini belirlemede iyi bir yaklaşım
olduğunu söylemek olanaksızdır.

Fuzz Modelde bu güvensizliğin nedeni , örneğin yazılımda var olan eksikliği belirliyecek test uygulamalrından sadece
bir tanesinin bu hatayı belirliyebilmesi ve bu test uygulamasının Kara-Kutu çalışmasında kullanılmamış olmasıdır. Bu
nedenle Kara-Kutu test uygulamasında izlenecek uygun yol müşterinin girdileri , varsayımları ve test sürücüleri
kendinin yaratmasıdır.

Ancak doğal olarak bu uygulama yöntemi hem pahalı bir yol hem de deneyim gerektiren bir iştir. Bu konuda deneyimli
personeli olmayan bir kuruluş için bu yolu izlemenin tek seçeneği danışman bir kuruluşla bu işleri yürütmesidir.
Ancak ileride oluşacak ve geri dönüşe neden olacak her türlü hatanın yukarda saydığımız giderlerin çok çok üstünde
bir gider oluşturacağını unutmamak gerekir.


Black Box Test Sınıflandırmaları;

Functional Testing

Stress Testing

Load Testing

Ad-hoc Testing

Exploratory Testing

Usability Testing

Smoke Testing

Recovery Testing

Volume Testing

Domain Testing

Scenario testing

Regression Testing

User Acceptance

Alpha Testing

Beta Testing

Yazılım Test Teknikleri

• Fonksiyonel Test / Functional Testing
Fonksiyonel test, öncelikle sistemin yapması beklenen işlevlerine odaklanır. Tanımlı spesifikasyonların sağlanıp
sağlanmadığının kontrol edilmesinin yanısıra, tanımlı olmayan, düşünülmemiş durumları da incelenir. Özellikle,
beklenmeyen koşullar altında sistemin davranışı saptanarak, olumsuz durumların varlığı aranır.

Gerçek kullanıcılar için data kaybı, runtime hataların alınması gibi durumlar güvenilirliği etkileyeceğinden
fonksiyonel testlerin işletilmesi önem taşır. Test ekibi tarafından test altındaki uygulamanın
operasyonları çok yönlü olacak şekilde analiz edilerek gerekli test teknikleri geliştirilir. Uygulamanın test
kapsamının belirlenmesi, sistem noktalarının ortaya çıkarılması ile tüm fonksiyonel spesifikasyonların teste dahil
edilmesi sağlanır.

• Regresyon Testi / Regression Testing
Daha önce teste alınmış bir yazılımın; hataların çözüldüğünden emin olabilmek, hata düzeltme aktivitelerinde yapılan
değişikliklerin yeni hataları tetiklemediğini görebilmek, yeni eklenen özelliklerin hatalarını yakalayabilmek
amacıyla yürütülen testlerdir.

• Kullanıcı Arayüzü Testi / User Interface Testing
Uygulamanın fonksiyonel işleyişini sağlayabilmek için kullanıcı arayüzünün bu doğrultuda tasarlanması ve kodlanması
gereklidir. Uygulamadaki, ekranlar, menüler, butonlar, resimler, yazılar vs. kullanıcı arayüzü öğelerinin atlanmadan
test edilmesi, pozitif ve negatif test adımlarında davranışlarının değerlendirilmesi gerekmektedir. Manuel ya da
otomatik olarak test edilmesi ile gereksinimlerin karşılandığı görülüp, beklenmeyen sonuçların da ortaya çıkarılması
sağlanır.

• Test Otomasyonu / Test Automation
Test otomasyonu çeşitli tekniklerin dahil edildiği, başarı için sürdürülebilirliğin ve güvenilirliğin şart olduğu
bir alandır. Test otomasyonunun başarılı olabilmesi için öncelikle uygun best practice’lerin seçilmesine önem
verilmelidir.
Test otomasyonunun sağladığı yararları şöyle sıralayabiliriz;
o Zamandan tasarruf edebilmek
o Manuel testlerde harcanan insan gücünü azaltıp, proje maliyetlerini düşürebilmek
o Test edilebilirliği artırmak
o Tekrar test edilebilirliği sağlamak
Uygun test aracının seçilmesi önem taşıdığı için otomasyon projelerinde müşteri yazılımlarına göre
ihtiyacın belirlenmesi ve implementasyon gereksiminimlerinin ortaya net bir şekilde konması gerekir.
Bu sayede süreçlere bağlı, doğru test planlaması yapılarak testler hızlandırılabilir.

• Manuel Test / Manual Testing
Manuel testler, test ekibinin test senaryolarını belirleyerek, ihtimam ile test adımlarını işletmeleri ile
yürütülür. Sistematik yaklaşım ile yürütülen testler, her adımda gerekli detaylandırma yapılarak, otomasyon ile
test edilmesi uygun olmayan testlerde dahil edilerek yapılır.
Bir test mühendisi, her zaman çantasında taşıdığı, merak, sabır, çözüm takip edebilme erdemleri ile daha fazla hata
yakalayabilmeyi amaçlamalıdır.

• Performans Testi & Yük Testi / Performance Testing & Load Testing
Çeşitli iş yükleri altında sisteminizin performansınızı ölçmeniz gerekecektir. Beklenen işlevlerin yerine getirilip
getirilemediği, hangi noktalarda darboğazlar oluştuğu, başarısız senaryo adımları değerlendirilerek performans
analizi yapılmalıdır.

Test ekibi mevcut sistemin performans senaryolarını oluşturarak, client/server tarafında belirlenen metriklerin
değerlerini toplayıp, gerekli analiz sonuçlarını ilgili birimlere sunarak, tahminlere dayalı release
geliştirmemelerini sağlamalıdır.
Test mühendisleri, özel lisanslı/açık kaynak performans test araçlarını kullanarak, tanımlanan sayıda sanal
kullanıcılar ile gerçek ortam koşullarını simüle edebilmektedirler.
İhtiyaçları karşılayabilecek en uygun test aracının belirlenmesi ile test senaryoları çıkarılabilmektedir. Yük
tanımlarının işletilmesi ile de yük altındaki sistemin detaylı performans istatistikleri belirlenmektedir.

• Kullanılabilirlik Testi / Usability Testing
Uygulamanın her işlevi yerine getirdiğini spesifikasyonlara bağlı olarak doğrulayabilirsiniz, ancak kullanıcı ihtiyaçlarını gerektiği gibi karşılamayabilir. Kullanım kolaylığı düşünülmüş, kullanıcı arayüzü açık uygulamaların istenileni daha iyi sağladığını söyleyebiliriz.

• Lokalizasyon Testi / Localization Testing
Test altındaki uygulamanın farklı yönlerden belirgin bir kültür veya lokal odaklı testlerinin yapılabilmesi
gerekmektedir. Lokalizasyon testinde; desteklenmesi beklenen diller, kullanım durumları/alışkanlıkları, bölgesel
saat/tarih ayarları gibi öğelerin test kapsamına alınıp, dikkatli hazırlanacak test planları ile teste tabi
tutulması sağlanır.
Çeşitli pazarları hedefleyen müşteriler, bu testler sayesinde iş gereksinimlerinin karşılanıp karşılanamadığını
görebilmiş olur.

• Uyumluluk Testi / Compatibility Testing
Test kapsamında geliştirilen uyumluluk matrisi ile sürümlerin; farklı işletim sistemleri, tarayıcılar, sunucular,
veri tabanları, çeşitli donanımlar, çözünürlükler vs. belirlenmektedir. Tüm konfigürasyon seçenekleri ortaya
çıkarıldıktan sonra, test ekibi matriste belirtilen her bir öğe için testlerin detaylarını ve sürelerini
ortaya çıkararak yeni sürümlerde/versiyon geçişlerinde uyumluluk testlerini planlayabilmektedir.

Başlangıç

Bu blog yararlı gördüğüm bilgi ve kaynakların paylaşılması düşüncesiyle oluşturulmuştur.

10 yılı aşkın tecrübe ve deneyimlerime dayanan bilgiler bulabileceğiniz gibi,
yazılım testi, kalite güvence, iş analizi, proje yönetimi ve kurumsal eğitim konularında da
genel kabul görmüş kaynaklara ulaşabileceksiniz.