Bir Haftadır Neden Hiç Yazmadım?

Yeniden merhaba..
Bir süredir pazar günleri hariç her gün yeni bir yazı paylaşıyordum. Fakat bir haftadir hiç yazmadım. Bu süreçte başımdan geçenleri paylaşmak istiyorum.
Öncelikle bir üniversitede araştırma görevlisi olabilmek için bilim sınavına girdim. Şehir dışında bir üniversiteydi ve günüm yolda geçtiğinden paylaşım yapamadım. Ertesi gün de hem çok yorgundum hem de sınav sonucunun açıklanmasını heyecanla beklediğimden yazmak aklıma gelmedi açıkcası. Akşam üzeri sonuçlar açıklandı ve sınavı kazanmıştım. Hayalini kurduğum mesleği yapabilecektim. Çok sevinçliydim. Misafirlerimiz geldi onlarla ilgilenmekten 2 gün daha yazı yazmaya fırsat bulamadım. Bir gün sınav sonuç listesinin yenilendiğini tesadüfen gördüm ve listede adım yoktu. Üniversiteyle görüşme yaptığımda bir yanlışlık olduğunu benim aslında sınavı kazanmadığımı söylediler. Dekanla görüştüm o da aynı şeyi söyledi. Aslında şikayet edecektim hatta mahkemeye bile vermeye karar vermiştim fakat ailem vazgeçirdi. Sırf adım çıkmasın daha kariyerime başlamadan elimin tersiyle itmiş olmayayım diye. Çok ağladım çok üzüldüm. Hayalinize ulaşıyorsunuz ve sonra aslında senin değildi diye elinizden alıyorlar nasıl bir duygu anlayanınız var mı?
Neyse bu konuyu kapatalım çünkü hala üzülüyorum. Çünkü hayaller kurmuştum. Herkes çok sevinmişti.
Daha sonra ben rahatsızlandım. Çok şükür iyiyim şimdi ve bir yazı paylaşarak (kısa da olsa) neler olup bittiğini anlatmak istedim.
Kendinize iyi bakın.




Bana ulaşmak için e-posta ve instagram.  

Gri Kutu Testleri

Gri kutu testlei, saydam kutu ve kara kutu test tekniklerinin birlikte kullanılmasıdır. Bu testlerde gereksinimleri doğrulayacak test durumları kodun içyapısı esas alınarak yazılır. Böylece gereksinimler doğrulanıp yazılımın iç yapısı sınanmış olur.
Gri kutu test yaklaşımı; testin tasarımıyla ilgilenir. Testleri kara kutu testi gibi uygulanır. Ancak test tasarlanırken işlevin içsel veri ve algoritma yapısı da göz önünde bulundurulmaktadır. Gri kutu testlerinde test ekibi yazılımın iç yapısını bildiğinden, yazılımın tasarımına ve kod yapısına karşı şartlanma olabileceğinden bazı hatalar ortaya çıkartabilecek testler yapılmadak kalabilir. Aşağıdaki şekilde gri kutu test şeması gösterilmektedir:

Bana ulaşmak için e-posta ve instagram.  

Saydam Kutu Testi (Beyaz Kutu Testi)

Saydam kutu testleri yazılımın iç yapısı bilinerek tasarlanır. Bu nedenle saydam kutu testlerini gerçekleştirenler genellikle sistemin iç yapısını bilen yazılımcılardır. Saydam kutu testiyle programın iç yapısındaki birimlerin içindeki hatalar araştırılır. Kaynak kod, saydam kutu testlerinin en önemli girdisi olduğundan, koda ulaşım olmadan saydam kutu testleri yapılamaz. Bunun yanında risk analizleri ve tasarım kısıtlerı da saydam kutu testlerinin planlanmasında, test stratejisinin belirlenmesinde, test araçlarının seçilmesinde ve test verilerinin oluşturulmasında kullanılır.
Saydam kutu testleri veri, kontrol ve bilgi akışlarının, kodlama standartlarının, hata yakalama ve ayıklama yapsının analizlerini içerir. Saydam kutu test tekniği basitçe aşağıdaki şekilde gösterilmiştir:

Saydam kutu test yaklaşımı kullanılarak yapılan testler şunlardır:

Birim Tesler: Saydam kutu testinin en iyi ve yaygın kullanımı birim testledir. Birim testler, kod yazanların belirli bir kod parçasının görevini doğru şekilde yerine getirip getirmediğini anlamak için yapılan testlerdir.

Statik ve Dinamik Analizler: Statik analiz, kod içerisindeki muhtemel hataları bulmak için yapılan kod üzerindeki incelemeleri içerir. Dinamik analizlerse kodun çalıştırılmasını ve çıkan sonucun analiz edilmesini içerir. Bu nedenle saydam kutu testleri kaynak koda ulaşım hakkı getirir.

Deyim Kapsama (Statement Coverage): Bu tür testte kod çalıştırılarak kod içerisinde yer alan her deyimin en az bir kez çalıştırılması hedeflenir. Böylece her bir deyimin bir yan etki göstermeden çalıştığı doğrulanır. Kod içerisinde çalıştırılmayan deyim olmadığı da doğrulanır.

Dal Kapsama (Branch Coverage): Hiçbir kod düz bir akışla yazılmaz. Kod içerisinde karar noktaları bulunur ve bu noktalardan kod yan dallara ayrılır. Dal kapsama ile program içerisinde yer alan tüm dalların kendilerinden beklenildiği şekilde çalıştığı doğrulanır.

Yol Kapsama (Path Coverage): Kod içerisindeki tüm yolların test edilmesidir.

Saydam kutu testiyle hata ve yanlışlar en erken safhada ve en hızlı şekilde bulunur. Böylece entegrasyon ve sistem testleri daha hızlı yapılabilir ve bulunan hata sayısında önemli bir azalma gözlemlenebilir.

Saydam Kutu Testinin Avantajları ve Dezavantajları:
Saydam kutu test tekniğiyle sınanan birimin veya modülün belirlenen girdiyle beklenen çıktıyı vermesi hedeflenir. Ancak bu çıktıyı nasıl verdiği ve kod içinde hangi yollardan geçildiği de incelenir.
Avantajlar:

• Kod içerisinde gizli kalmış mantıksal hatalar bulunur.
• Saydam kutu testleriyle yazılan kodun optimizasyonuna katkıda bulunulur.
• Kod içindeki fazla satırlar ayıklanarak ölü kod parçaları bulunur.
• Kaynak kodun analiz edilmesi ve bu analize göre testlerin gerçekleştirilmesiyle yazılım içerisindeki hatalar daha erken aşamada ve daha hızlı bulunur.
• Yazılımın geliştirilmesi için belirlenmiş olan kodlama rehberine uyumluluk, tasarım kararlarına kodlama içerisinde uyulup uyulmadığı saydam kutu testleriyle net olarak görülür.
• Saydam kutu testleriyle yazılımcıların kod geliştirme yetenekleri desteklenir ve güçlendirilir.

Dezavantajlar:

• Eğer birim tümleştirme testleri test ekibi tarafından yapılacaksa bu iş için kodun iç yapısının bilinmesi gerekir. Bu da maliyeti arttırır.
• Saydam kutu testleriyle sadece modül ve birimlerin iç işleyişleri test edildiğinden tümleştirmeden sonra ortaya çıkabilecek olan hatalar tespit edilemez.

Bana ulaşmak için e-posta ve instagram.  

Kara Kutu Testi

Test edilecek yazılımın iç işleyişine bakılmaksızın yapılan testlere kara kutu testleri denir. Bu yaklaşımda test edilecek yazılımın, sonucu bilinen bir davranışını doğrulamak için davranışın gerektirdiği girdi değerleriyle çalıştırılarak sınanır. Daha sonra yazılımın bu girdi karşısında elde edilen çıktısı, beklenen sonuçla karşılaştırılır. Bu yaklaşımın kara kutu olarak adlandırılmasının nedeni, uygulamayı test edecek kişinin yazılımın iç yapısıyla ilgilnememesidir. Bu nedenle bu testler yazılım geliştiricilerden çok test ekipleri tarafından gerçekleştirilir.
Kara kutu testinde bir yazılım parçası test ediliyorsa test mühendisi bu yazılım parçasının girdisini ve buna karşılık sistem çıktısını bilir. Fakat bu çıktıya nasıl ulaşıldığıyla ilgilenmez. Kara kutu testlerinin amacı, verilen girdilerle istenilen çıktının elde edilmesidir. Bu nedenle yazılımın iç işleyişiyle ilgili diğer bilgilerle ilgilenilmez. Kara kutu test tekniğinde diğer önemli bir nokta da geliştirilen yazılımın tasarımından veya kodlanmasından kaynaklanabilecek hataların bulunmasıdır. Bu amaçla kara kutu testlerinin yapılması ve istenilen amaca ulaşılabilmesi için yazılım geliştiricilerle test ekibi birbirinden ayrı çalışmalıdır. Böylece test ekibi, tasarım ayrıntılarını bilerek yazılıma karşı ön yargı taşımaz.
Kara kutu test tekniğiyle geliştirilen yazılım içerisinde şu hata türleri tespit edilmeye çalışılır:

1. Doğru olmayan veya hiç olmayan işlevlerin tespiti
2. Arayüz hataları
3. Performans hataları
4. Veritabanlarına ulaşma hataları veya veri yapılarındaki hatalar
5. Başlatma veya sonlandırma hataları
6. Sınır değer hataları

Kara kutu test tekniği aşağıda basit olarak gösterilmiştir:

 Kara Kutu Testinin Avantajları ve Dezavantajları
Avantajlar:

• Yazılımlarda hataların bulunması için etkin ve hızlı bir tekniktir.
• Test durumları yazılırken gereksinimlerden hareket edildiği için gereksinimlerdeki tutarsızlıkların ve belirsizliklerin belirlenmesinde önemlidir.
• Testi gerçekleştirecek kişinin yazılımın ayrıntılarını bilmesine gerek yoktur.
• Test ekibi ve kod geliştiriciler birbirinden bağımsız çalışabilirler.
• Testçiler gereksinimleri doğrulamak ve gereken testleri gerçekleştirmek için yazılıma kullanıcı gözüyle bakarlar. Bu da kod geliştiriciler tarafından fark edilmeyen pek çok olası hatanın ve eksiğin bulunmasına yardımcı olur.
• Testleri yapacak kişilerin sistem hakkında teknik ayrıntı bilmesine gerek yoktur.

Dezavantajlar: 

• Kara kutu testleri yazılımın belirli parçasını hedeflemez. Bu nedenle birçok hata tespit edilmeden kalabilir, bunlar için başka testler gerekir.
• Sadece belirli sayıda girdi değeriyle testler yapılır. Tüm girdiler ile testlerin yapılması sonsuza kadar sürer.
• Yazılım içerisinde bazı kod parçalarında birden fazla test yapılırken bazı kod parçaları hiç test edilmeden kalabilir.
• Açık ve yalın olmayan gereksinimlerin test durumlarını tasarlamak ve testlerini yapmak kara kutu test tekniğinde zordur.

Kara Kutu Test Stratejisi
Kara kutu test tekniği tümleştirme, sistem ve kabul test aşamalarında kullanılır. Bu testlerde en verimli sonuçlara ulaşmak için şu kara kutu test stratejisi izlenebilir:

• Kara kutu testleri rasgele belirlenmiş girdilerle gerçekleştirilmelidir.
• Yazılımın sağlamlığının kontrolü için belirtilen aralığın dışındaki değerlerin de testi yapılmalıdır.
• Sınır değerler mutlaka test edilmelidir.
• Değer artışlarında artış müktarı ayrıca test edilerek doğrulanmalıdır. Artış miktarı dışı artımlarda yazılımın tanımlı davranışına göre hareket ettiği doğrulanmalıdır.
• Sayısal girişlerde sıfır değeri mutlaka girdi olarak sınanmalıdır.
• Özellikle gerçek zamanlı sistemlerde stres testi yapılmalıdır. Programın aşırı yüklenme altında nasıl çalıştığı test edilmelidir.
• Kara kutu testlerinde diğer bir amaç gereksinimlerin doğrulanması olduğundan her bir gereksinim için en az bir test durumu yazılmalı ve bu şekilde gereksinim kapsama gerçekleştirilmelidir.

Bana ulaşmak için e-posta ve instagram.   

Yazılım Test Teknikleri

Yazılım testleri yapılırken test edilecek yazılıma bakış açısına göre 3 test tetkniği vardır. Bunlar;

• Kara Kutu Testi
• Saydam Kutu Testi
• Gri Kuru Testi

Bana ulaşmak için e-posta ve instagram.  

Kabul Testleri

Proje kabul testleri müşteri gereksinimlerinin doğrulanması ile gerçekleştirilir. Bunun için her bir kullanıcı gereksinimini doğrulayacak olan test durumları ve test senaryoları oluşturulur. Geliştirilen sistem, tanımlanan bu test durumları ve test senaryoları müşterinin de katılımıyla "kabul test planına" uygun olarak koşturulur. Sistemin tamamının bu testlerden geçmesi ile sistem, müşteri tarafından kabul edilmiş olur.
Kabul testleri için şu adımlar bir süreç olarak işletilir:

1. Müşteri gereksinimleri belirlenir ve belgenlendirilir.
2. Kabul test planı hazırlanır.
3. Müşteri gereksinimlerini doğrulayacak test durumu ve senaryoları hazırlanır.
4. Test hazırlık gözden geçirme toplantısında hazırlanan test durumu ve senaryoları onaylatılır.
5. Kabul testleri için gerekli test ortamı hazırlanır.
6. Sistem testlerinin başarıyla sonuçlanmasından sonra kabul testleri yapılır.
7. Kabul test planında belirtilen kabul kriterlerine ulaşılıncaya kadar testlerin yapılmasına devam edilir.
8. Test sonuçları belgelendirilir ve müşteriye onaylatılır.

Kabul testleri, bir yazılım projesinin başarısında en kritik adımdır. İyi planlanmış ve belgelendirilmiş kabul testleri, projenin başarısına büyük katkı sağlar, müşteri memnuniyetini arttırır.





Bana ulaşmak için e-posta ve instagram.  

Sistem Testleri

Sistem testleri, geliştirilen yazılımın performans, güvenilirlik, işlevsellik gibi özelliklerini değerlendiren testlerdir. Birim ve tümleştirme testlerinde geliştirilen yazılımın tasarıma uygun olarak geliştirildiği doğrulanır. Sistem testleriyse müşterinin sistemden istediklerini doğrulamayı amaçlar. Bu nedenle sistem test durumlarında sistem gereksinimleri temel alınarak sistemin çalışacağı, gerçek ortamda karşılaşılabilecek olan senaryolar tanımlanır.
Sistem testleri, kullanıcı kabul testlerinden bir önceki adım olarak yazılım ve donanım entegrasyonundan sonra "sistem test planına" göre yapılır. Sistemin işlevsel, işlevsel olmayan gereksinimlerinin doğrulanması hedeflenir.
Sistem testlerinin ilk adımı olarak işlevsel gereksinimlerin doğrulanması gerçekleştirilir. Bu doğrulama sonucunda sistemin işlevsel olarak çalıştığı gözlemlenir. İşlevselliği yönünden doğrulanan sistem üzerinde bir sonraki adımda, işlevsel olmayan gereksinimlerin karşılandığı gösterilmek amacıyla işlevsel olmayan testler yapılır. Bu testlerden bazıları:

Stres Testleri: Sisteme girdi oranı sistem tasarım oranını aştığı zaman sistemin davranışını gözlemlemek üzere gerçekleştirilen testlerdir.

Performans Testleri: Sistem çıktılarının belirlenen ve kabul edilebilecek olan zaman dilimi içerisinde üretebildiğinin değerlendirmesinin yapılabilmesi için gerçekleştirilen testlerdir.

Konfigürasyon ve Uyumluluk Testleri: Geliştirilen sistemin farklı platformlarda ve donanımlarda nasıl davrandığının değerlendirilmesi için yapılan testlerdir.

Güvenlik Testleri: Sistemin izinsiz kullanım teşebbüslerindeki davranışlarının değerlendirilmesi için yapılan testlerdir.

Kullanılabilirlik Testleri: Kullanıcı-sistem etkileşimini ve ergonomisini değerlendirmek üzere yapılan testlerdir.

Geri Alma Testleri: Bir hata durumunda sistemin otomatik veya elle yeniden normal duruma dönmesini değerlendirmek için yapılan testlerdir.

Kullanıcı Arayüzü Testleri: Kullanıcının ve yazılımın grafik gösterimi olarak nasıl bir etkileşim içerisinde olacağını, kullanıcının klavye, ekran veya fare ile sisteme vereceği girdilerin sistem tarafından nasıl işleneceğini değerlendirmek için yapılan testlerdir.

İşlevsel olmayan testleri tamamlanan sistem artık doğrulanmış olarak kullanıcı kabul testlerine hazır demektir. Sistem testleri sırasında ortaya çıkan hatalar proje hata yönetimi sürecine göre raporlanır ve gerekli düzeltme işlemleri yapılır. Gerekli düzeltmelerden sonra, düzeltmelerden sistemin geri kalanının etkilenmediğinin değerlendirilmesi için sistem üzerinde yineleme testleri yapılır.


Bana ulaşmak için e-posta ve instagram. 

Tümleştirme Testleri

Yazılım projelerinde birim testlerin başarılı bir şekilde sonuçlandırılmasından sonra tümleştirme (entegrasyon) testleri başlar. Birim testlerde amaç modüllerin ayrı ayrı kendilerinden beklenen işlevleri yerine getirdiğinin doğrulanmasıyken tümleştirme testlerinin amacı bir araya gelerek entegre edilmiş olan bir yazılımın içerisindeki bileşenleri birbirleriyle uyum içerisinde doğru bir şekilde çalıştığının ve bileşenlerin kendilerine ait gereksinimleri yerine getirdiğinin doğrulanmasıdır. Bu testlerin yapılması için kullanılacak test durumları, yazılım gereksinimleri ile arayüz gereksinimlerinden çıkartılır. Tümleştirme testlerinde kara kutu test yöntemi kullanılır. Testlerde hem pozitif hem negatif test durumları uygun parametreler kullanılarak çalıştırılır. Sonuçlar, beklenen değerlerle karşılaştırılarak sistemin kendisinden beklenen davranışları gerçekleştirdiği doğrulanır.
Tümleştirme testlerin yapılırken big bang, aşağıdan yukarıya veya yukarıdan aşağıya olmak üzere farklı stratejiler kullanılabilir.
Big bang stratejisine göre geliştirilen tüm üst ve alt düzey modüller birbirleriyle enetgre edildikten sonra testler başlar. Bu stratejide sistem bir bütün olarak ele alınarak testler yapıldığından testlerin gerçekleştirilmesi hızlıdır ve zamandan tasarruf edilir. Ama bir hata çıktığında bu hatanın hangi seviye katmanda oluştuğu veya hangi modülden kaynaklandığının tespiti zordur.
Aşağıdan yukarıya tümleştirme test stratejisi öncelikle birim testlerin yapılmasıyla başlar. Birim testleri başarıyla tamamlanan alt düzey modüller birbirleriyle entegre edilir. Bu entegrasyondan sonra alt düzey modüller ile ilgili entegrasyın testleri yapılır. Bu testlerin başarılı şekilde sonlandırılmasından sonra bir üst katman modülleri sistemi entegre edilir ve gerekli entegrasyon testleri yapılır. Bu entegrasyon tüm sistem inşa edilinceye ve entegrasyon testleri başarıyla sonuçalanıncaya kadar devam eder. Bu yaklaşımda temel şart, entegre edilcek modüllerin birim testlerinin başarıyla tamamlanmış olmasıdır.
Yukarıdan aşağıya tümleştirme test stratejisi, öncelikle sistem için en üst modülün (en dış modül, genellikle kullanıcı grafik arayüz modülü) test edilmesiyle başlar. Bu modülün ihtiyaç duyduğu alt modüllerin koçanları kullanılır. Bu yaklaşımda birçok koçan yazılması gerekir. En üst modül başarılı şekilde test edildikten sonra bir alt düzey modüller sistemle bütünleştirilir. Bu entegrasyondan sonra gerekli alt düzey tümleştirmesi testleri yapılır. Bu durum en alt düzey modüller entegre edilinceye ve entegrasyon testleri başarıyla sonuçlanıncaya kadar devam eder. Bu yalşaımda entegrasyon testleri kara kutu testleri olarak başlar ve gittikçe saydam kutu testlerine döner.





Bana ulaşmak için e-posta ve instagram.  

Birim Testleri

Metot, modül veya prosedür gibi bir kod parçasının kendisinden beklenen işlevselliği doğru olarak yerine getirip getirmediğini ve hata içermediğini göstermek için gerçekleştirilen testlerdir. Birim testler başarılı ve kaliteli yazılım ürünleri ortaya çıkartmak için kullanılabilecek öenmli bir test aşamasıdır. Bir yazılım projesinde birim testler başarılı bir şekilde gerçekleştirilirse diğer test aşamalarnda daha başarılı sonuçlar elde edilmesi muhtemeldir.
Birim testi yapılmasının en kolay yolu bir yazılım test aracı kullanılmasıdır. Eğer bir test yazılım aracı kullanılmayacaksa birim test kodları yazılım geliştirmeye paralel olarak geliştirilmelidir. Bu nedenle birim testler yazılım geliştirmenin bir parçası olarak düşünülmeli ve planlama buna uygun olarak gerçekleştirilmelidir. Gereksinimler veya kod güncellendikçe birim test kodları da güncellenmelidir.
Başaşrıyla sonuçlanan birim testler, yazılım tümleştirme ve sistem testlerinden önce geliştirilen yazılımın genel olarak istenen gereksinimleri karşıladığının  bir göstergesidir. Ancak yazılımın hatasız olduğunu göstermez. Geliştirilen yazılımdan beklenenlerin tam olarak karşılandığını ortaya koymak için entegrasyon ve sistem testleri ile arayüzlerin testlerinin de gerçekleştirilmesi gerekir.
Birim testlerinin amacı, geliştirilen ve derlenebilen en küçük kod parçalarının (metot, prosedür, sınıf vb.) kendilerine ait görevleri doğru şekilde yerine getirdiğinin doğrulanmasıdır. Bu amaçla, birim testler yapılırken test edilecek birim, diğer birimlerden izole edilir. Test edilen birim için gerekli olan girdileri sağlayacak diğer birimlerin yerine o metotların stubları kullanılır. Böylece diğer birimdeki olası bir hatanın test edilen birimi etkilemesi engellenir. Test edilecek birimin icra edeceği göreve göre test durumları oluşturulur. Bu durumlar kullanılarak test edilecek birim çalıştırılır ve elde edilen sonuçlar beklenen sonuçlarla karşılaştırılarak testlerin başarılı olup olmadığına karar verilir. Eğer test başarısız olmuşsa birimin kodu tekrar gözden geçirilir, gerekli düzeltmeler yapılır ve tekrar test edilir. Bu işlem, tüm birimler başarılı bir şekilde kendilerine ait birim testleri geçinceye kadar devam eder.






Bana ulaşmak için e-posta ve instagram.  

Yazılım Test Düzeyleri

Yazılım testleri temelde 4 ayrı aşamada gerçekleşir. Testlerin ayrıntı düzeyi arttıkça test edilen parçanın büyüklüğü azalır. Bu test aşamaları şunlardır:

• Birim Testleri
• Tümleştirme Testleri
• Sistem Testleri
• Kabul Testleri

Bana ulaşmak için e-posta ve instagram. 

Yazılım Test Süreçleri

Yazılım test süreci planlı birşekilde gerçekleşen bir dizi eylemden oluşur. Bu süreçte yazılım hatalarına odaklanılır. Aşağıdaki şekilde sadeleştirilmiş yazılım test süreci gösterilmektedir.

Bilgi Toplama: Projeyle ilgili bilgilerin elde edildiği ve projeyi anlamaya yönelik çalışmaların yapıldığı süreçtir.
Test Planlama: Testin kapsamının, testin stratejisinin, test ortamının, hangi yazılım parçalarının test edilip edilmeyeceğinin, proje kapsamında amaçlanan test eylemlerinin belirlenip doküman oluşturulduğu aşamadır. Yazılım projesinin kapsamına bağlı olarak birim test planı, yazılım test planı, sistem test planı, kabul test planı gibi birden fazla test planı geliştirilebilir.
Test planlarının geliştirilmesindeki amaç proje kapsamındaki test stratejisinin tanımlanması, kaynak paylaşımının planlanması, sorumlulukların, risklerin ve önceliklerin açıklığa kavuşturulmasıdır.
Test planının içeriğinde testin amacı, test stratejisi, test geliştirme ortam özellikleri (donanım, yazılım, ağ alt yapısı, gerekli test araçları vb.), test takvimi bulunur.
Test Tasarımı: Test ortamının hazırlandığı süreçtir. Test esnasında kullanılacak yazılım donanım ortamı belirlenir, test caseler yazılır ve test yordamı hazırlanır.
Test Çalıştırma: Birim testlerin yapılması ile test çalıştırma süreci başlar. Test koşturmada son adım kullanıcı kabul testleridir. Bu testlerde sistemin kullanıcı gereksinimlerini karşıladığı doğrulanır.
Eğer testler, gereksinimleri test etmezse o testler geçersiz sayılır. Test verileri, testlerin amacını yansıtmazsa o testler de geçersizdir.
Test çalıştırılırken test mühendisleri tarafından genel olarak şu adımlar izlenir:

1. Yazılım ekibi tarafından test edilecek yazılım oluşturulur.
2. Test ekibi gelen yazılıma uygulanacak test durumlarına karar verir.
3. Yazılımın test edilebilir olduğuna karar verilir.
4. Yazılım teste kabul edilirse testler başlar.
5. Testlerde bulunan hatalar raprolanarak yazılım ekibine bildirilir.
6. Bulunan hatalar yazılım ekibi tarafından düzeltirilir ve yeni sürüm hazırlanır.
7. Test ekibi yeni gelen yük ile yineleme testlerini yapar.
8. Bu adımlar, müşteriye yazılımın son edilebilir versiyonu verilinceye kadar devam eder.

Test Değerlendirme: Gerçekleştirilen testlerin sonuçlarının değerlendirildiği, test esnasında belirlenen yazılım hatalarının incelenip düzeltildiği aşamadır.





Bana ulaşmak için e-posta ve instagram.

Yazılım Test Prensipleri

Yazılım testinden beklenentest edilecek yazılımın, kullanıcı gereksinimlerine ve beklentilerine cevap verip veremediğinin test edilmesidir.
Günümüz yazılımlarında farklı türde hatalar vardır. Bu hatalar kimi zaman bilgi kayıplarına ve değişmelere sebep olmaktadır. Kalite, piyasaya sürülen yazılımlardaki hataları azaltmak için yazılım testi tarafından değerlendirilir. Geleneksel olarak yazılım testi, yazılımdaki mümkün olabilecek hataları bulmayı aramaktan ziyade, yazılımın karakteristiklerini ortaya çıkarmaya çalışır. Kaliteli bir yazılım ürünü ortaya çıkarabilmek için uyulması gereken bazı prensipler bulunmaktadır. Bu prensipler şunlardır:

• Test işlemi bağımsız gruplar tarafından yapılmalı
• Test için en iyi personel seçilmeli
• Test, maximum hata sayısı elde etme amacıyla planlanmalı
• Geçersiz ve beklenmeyen giriş durumları, geçerli durumlar kadar iyi test edilmeli
• Test esnasında test altındaki yazılımda değişiklik yapılmamalı
• Test durumları ve test sonuçlarını içeren test raporu hazırlanmalı
• Beklenen sonuçlar belirlenmeli ve rapora dahil edilmeli
• Test ilerledikçe planlanmalı ve daha sonra güncellenmeli
• Uygun bir test metodu seçilmeli

Bana ulaşmak için e-posta ve instagram.    

Therac-25 Tedavi Cihazı

Tümörlerin yok edilmesinde kullanılan Therac-25 cihazının tedavi esnasında düşük güç modunu algılayamayıp yüksek güç modunda çalışmasıyla hastalara normalden 100 kat fazla doz verip 6 kişinin ölümüne sebep olmuştur. Bu durumun yazılımsal sebebinin 255 giriş denemesinden sonra tampon belleğin taşması olarak açıklanmıştır.



Bana ulaşmak için e-posta ve instagram.    

Ariane 5 Patlaması

Avrupa Uzay Ajansı tarafından geliştirilen 7 milyar Euroluk uydu taşıma amaçlı füze, fırlatıldıktan 37 saniye sonra roket kontrol yazılımındaki hatadan dolayı havada infilak etmiştir. Ariane 5 füzesinde kullanılan kodlar Ariane 4'te kullanılan kodlardan geliştirilmiş modül testleri gerçekleştirilmesine rağmen sistem testleri gerçekleştirilmeden kullanılmıştır. Bir değişkendeki taşma sonucu, kontrol sistemi devre dışı kalarak 500 milyon dolarlık kayba sebep olmuştur.



Bana ulaşmak için e-posta ve instagram.   

Hedefi Iskalayan Patriot Füzeleri

Körfez savaşı esnasında patriot füzelerinden biri hedefi ıskalayarak 28 Amerikan askerinin ölümüne sebep olmuştur. Yapılan incelemede füzelerin zaman hesaplamasında kullanılan 24 bitlik değişkende oluşan hatanın buna sebep olduğu ortaya çıkmıştır.



Bana ulaşmak için e-posta ve instagram.   

Denver Havaalanı Otomatik Bagaj Sistemi

Amerika Birleşik Devletlerinin Denver kentindeki uluslararası havaalanındaki uçuşlardaki beklemeleri azaltmak, daha az maliyetle daha hızlı bagaj hizmeti sunmak için geliştirilen otomatik bagaj sistemi yazılımı, yazılım hataları nedeniyle planlanan zamandan yaklaşık 16 ay sonra hizmete girmiş ve bu gecikmenin günlük maliyetinin 1 milyon dolara yakın olduğu hesaplanmıştır. O zamandan beri çeşitli sorunlarla çalışan yazılım için iş görmeyeceği belirnelerek yenileme kararı alınmıştır.




Bana ulaşmak için e-posta ve instagram.    

Yazılım Testinin Önemi

Yazılım dünyasındaki gelişmeler yazılımın karmaşıklığını ve büyüklüğünü arttırmıştır. Bu durum hata miktarının artması, güvenliğin sağlanamaması gibi bazı sorunları beraberinde getirmiştir. Bu sorunlar yazılımların ilk geliştirilmeye başlandığından beri süre gelen sorunlardır. Var olan yazılım projeleri incelendiğinde çok az bir miktarının başarı ile sonuçlandığı görülür. Başarısız projeler nedeniyle de yılda milyonlarca dolar zarar edilmektedir. Başarısız projeler incelenerek kayıtlar tutulmaya çalışılmış ve bu başarısıklıkların nedenleri tespit edilmeye çalışılmıştır. Başarısızlığa neden olan hatalar iletişim eksikliği, programlama hataları, ihtiyaç değişikliği, zaman baskısı, dokümantasyon eksikliği, geliştirme araçları eksikliği gibi sebepler olarak tespit edilmiştir. Buna ek olarak başarılı projeler de incelenerek en iyi pratikler tespit edilmiştir.
2004 yılında The Standish Group tarafından yayınlanan "The Choas Report" adlı araştırma sonuçlarına göre ABD'de yazılım firmalarının geliştirdiği 30000 yazılım projesi incelendiğinde, bu projelerin sadece %34'ünün başarılı bir şekilde sonuçlandığını, %15'inin başladıktan sonra iptal edildiği, %51'inin ise tartışmalı, yani zamanında bitirilmemiş ya da gereksinimleri karşılamadan sonlanmış projeler olduğunu belirtmiştir.
Yazılım testinin önem ve gerekliliğini ortaya koyan en önemli yazılım felaketlerinden bazıları;

• Denver Havaalanı Otomatik Bagaj Sistemi
• Ariane 5 Patlaması
• Hedefi Iskalayan Patriot Füzeleri
• Therac-25 Tedavi Cihazı

Yukarıda bahsi geçen felakatler bir yazılım testine tabi tutulmuş olsaydı belki de önlenmiş olabilirdi. Yazılımlarda ortaya çıkan hatalar zaman kaybı, maddi kayıpların yanı sıra can kayıplarına da sebep olabilmektedir. Bu sebeple yazılımların test edilmesi öenmlidir ve zarara uğrama ihtimalini azaltmaktadır.





Bana ulaşmak için e-posta ve instagram.    

Yazılım Testi Amaçları

• Yazılımda var olan hataları tespit etmek ve tekrarını önlemek
• Yazılım geliştirme süreci boyunca meydana gelen hataları ortaya çıkarmak
• Geliştirilen yazılımın beklentilere uygunluğunu ve doğruluğunu tespit etmek
• Son ürün olarak hatadan arındırılmış ve istekleri karşılayan bir ürün teslim etmek
• Yazılım hatalarının tespit edilmesiyle ortaya çıkabilecek riskleri azaltmak
• Bir kişiye, bir ortama veya bir şirkete zarar verebilecek yazılım hatalarını belirlemek
• Hataların ana sebepleri ve etkileri arasındaki farkı ayırt etmek
• Elde edilen örnekler yardımıyla testin niçin gerekli olduğunu tayin etmek
• Test etmenin niçin kalite güvencenin bir parçası olduğunu ve elde edilen örneklere bakarak daha yüksek kalite sağlamak için nasıl bir testin olması gerektiğini saptamak
• Hata (error), kusur (defect), aksaklık (fault), bozukluk (failure), yanlışlık (mistake) ve yanlış (bug) gibi terimleri yeniden hatırlamak
• Yazılım projesinin başlangıcından bitmesine kadar olan süreçte hataları en aza indirebilmek
• Projenin teslim edildikten sonraki teknik desteğini sağlayabilmek
• Yeni gereksinimlerin projeye rahatlıkla uygulanabilmesini sağlamak
• Kullanım kolaylığı sağlamak

Bana ulaşmak için e-posta ve instagram.