Testin 7 Temel İlkesi

Bu eğitimde, her Yazılım Test Uzmanı ve Kalite Güvencesi (QA - Quality Assurance) profesyonelinin bilmesi gereken, yazılım testinin yedi temel ilkesi tanıtılacaktır.

Altyapı

Yazılım testi yaparken, hedeften sapmadan, optimum bir test sonucu elde etmeniz önemlidir. Peki, doğru test stratejisini izlediğinizi nasıl belirlersiniz? Bunun için, bazı temel test ilkelerine bağlı kalmanız gerekir. İşte şimdi bu yazıda, yazılım endüstrisinde yaygın olarak uygulanan yedi test ilkesinden bahsedeceğiz.

Bir dosyayı A klasöründen B klasörüne taşıdığınız bir senaryoyu ve bunu test etmenin olası tüm yollarını düşünün. Genel senaryolardan ayrı olarak, aşağıdaki koşulları test edebilirsiniz:

• Taşınacak dosyanın açık olması.
• Dosyayı B klasörüne yapıştırmak için güvenlik haklarınızın olmaması.
• B klasörü paylaşılan bir sürücüye sahip olması ve depolama kapasitesinin dolu olması.
• B klasöründe zaten aynı adlı bir dosyanın var olması.

Veya test etmek için 15 giriş alanınız olduğunu varsayalım; bunların her birinin 5 olası değeri varsa, test edilecek kombinasyon sayısı 5^15 olacaktır.

Olası tüm kombinasyonları denemek isterseniz TEST SÜRESİ & MALİYET üssel olarak yükselecektir. Bu sebeplerden dolayı test çabalarını optimize etmek için belirli ilkelere ve stratejilere ihtiyacımız var.

İşte 7 ilke:

1) Kusursuz test mümkün değildir.

Evet! Her şeyi kapsayan kusursuz bir test mümkün değildir. Bunun yerine, risk değerlendirmesine dayalı optimum test miktarına ihtiyacımız vardır.

Ve milyon dolarlık soru şu ki; bu riski nasıl değerlendirebiliriz?

Buna cevap vermek için, haydi bir beyin jimnastiği yapalım.

Size göre, hangi işlem, işletim sisteminizin hata vermesine neden olabilir?

- Çoğunuzun tahmin ettiğinden eminim; aynı anda 10 farklı uygulamayı açmak.

Yani, eğer bu İşletim Sistemi'ni test ediyor olsaydınız, hataların çoklu-görev aktivitelerinde bulunduğunu ve etraflıca test edilmeleri gerektiğini farkedecektiniz, ki bu da bizi bir sonraki ilkemiz olan Hata Kümelenmesi ilkesine götürmektedir.

2) Hata Kümelenmesi

Hata Kümelenmesi, az sayıda modülün çok sayıda hatayı içermesini ifade eder. Bu, Pareto İlkesi'nin yazılım testine uygulanmasıdır: hataların yaklaşık %80'i modüllerin % 20'sinde bulunur.

Tecrübeye dayalı olarak, bu tür riskli modülleri tanımlayabilirsiniz. Ancak bu yaklaşımın kendi sorunları vardır.

Aynı testler defalarca tekrarlanırsa, sonuç olarak aynı test senaryoları artık yeni hatalar bulamaz.

3) Böcek İlacı Paradoksu

Tarımda aynı böcek ilacı karışımının tekrar tekrar kullanılması, zamanla böceklerin ilaçlara karşı direnç geliştirmesine yol açar. Dolayısıyla, ilaç etkisiz kalır.
Aynısı yazılım testleri için de geçerlidir. Aynı test kümeleri tekrar tekrar koşulursa, bir süre sonra yeni hatalar keşfetmede yararsız olur.

Bunun üstesinden gelmek için, test senaryolarının daha fazla hata bulmak için düzenli olarak incelenmesi ve tekrar düzenlenmesi, yeni ve farklı test senaryolarının eklenmesi gerekir.

Test uzmanları sadece mevcut test tekniklerine bağlı kalamazlar. Testi daha etkin hale getirmek için mevcut yöntemleri iyileştirmek için sürekli olarak araştırma yapmalıdırlar. Ancak bütün bu zorlu ve sıkı çalışmaya rağmen, ürününüzün hatasız olduğunu iddia edemezsiniz. Buna çarpıcı bir örnek olarak, Windows 98'in piyasaya sürülürken sunum sırasında karşılaştığı hatayı gözden geçirmelisiniz. (Video)

Sizce MICROSOFT gibi bir şirket, işletim sistemini tamamen test etmedi ve ünlerini tehlikeye atacak bu hatayı sunum sırasında görmeyi mi bekliyordu?

4) Testler, hataların varlığını gösterir.

Test ilkesi şunu ifade eder: Test etmek hataların varlığından bahseder, hataların yokluğundan bahsetmez. Yazılım testi, yazılımda kalan keşfedilmemiş hataların olasılığını azaltır; ancak herhangi bir hata bulunmasa bile, bu doğruluğun bir kanıtı değildir.

Peki ya ekstra sıkı çalışıp, bütün önlemleri alıp, %99 hatasız yazılım ürettiniz ve yazılım müşterilerin ihtiyaç ve gereksinimlerini karşılamıyorsa?

Bu bizi bir sonraki ilkemize götürüyor: Hata Yokluğu

5) Hata Yokluğu

%99 hatasız bir yazılımın hala kullanılamaz olması mümkündür. Bu, sistemin yanlış gereksinim için test edildiğinde ortaya çıkacak bir durumdur. Yazılım testinin amacı sırf hataları bulmak için değil, aynı zamanda bu yazılımın iş ihtiyaçlarına hitap edip etmediğini kontrol etmektir. Hatanın yokluğu bir yanılgıdır. Yani, hataların bulunması ve düzeltilmesi, sistemin kullanılamaması ve kullanıcının ihtiyaç ve gereksinimlerini karşılamaması durumunda yardımcı olmaz.

Bu sorunu çözmek için bir sonraki test ilkesine ihtiyacımız var: Erken Test.

6) Erken Test

Test, Yazılım Geliştirme Yaşam Döngüsü'nde olabildiğince erken başlatılmalıdır. Dolayısıyla, gereksinimlerdeki veya tasarım fazındaki herhangi bir hatanın erken fazlarda yakalanması sağlanır. Testin erken aşamalarında bir hatayı düzeltmek çok daha ucuza mal olur. Fakat, test etmeye ne kadar erken başlamalı? Gereksinimlerin tanımlanması anında hatayı bulmaya başlamanız önerilir.

7) Test, içeriğe bağlıdır.

Test, içeriğe bağlıdır; bu temel olarak bir e-ticaret sitesini test etme şeklinizin, ticari kullanıma hazır bir uygulamayı test etme şeklinizden farklı olacağı anlamına gelir. Geliştirilen yazılımların tümü özdeş değildir. Uygulama çeşidine bağlı olarak farklı yaklaşımlar, yöntemler, teknikler ve test türleri kullanabilirsiniz. Örneğin, bir POS sisteminin bir perakende mağazasında test edilmesi, bir ATM makinesini test etmekten farklı olacaktır.

7 Test İlkesinin Özeti

1. İlke	Test, hataların varlığını gösterir.
2. İlke	Kusursuz test imkansızdır.
3. İlke	Erken Test
4. İlke	Hata Kümelenmesi
5. İlke	Böcek İlacı Paradoksu
6. İlke	Test, içeriğe bağlıdır.
7. İlke	Hata Yokluğu - Yanılgı

~~~~~~~~~~O~~~~~~~~~~

Referanslar
- Turkish Testing Board

- Guru99