Yazılım testi karmaşıktır ve yüksek kaliteli ürünler üretmek için önemli kaynaklar gerektirir. Ancak, doğru yazılım test stratejisini uyguladığımızdan ve bunun doğru yol olduğundan nasıl emin olabileceğimizi hiç düşündünüz mü? ISTQB’nin yazılım testi ilkeleri bu çabanızda size yardımcı olabilir. Ancak bu yedi yazılım test ilkesi tam olarak nedir?
ISTQB (Uluslararası Yazılım Testi Nitelikler Kurulu) , test sürecini iyileştirmeye ve daha yüksek kaliteli yazılım veya uygulama oluşturmaya yardımcı olabilecek yedi yazılım testi ilkesini özetledik. O halde, daha fazla gecikmeden, bu yedi yazılım test etme ilkesini tek tek keşfetmeye başlayalım.
Yazılım Testinin Yedi İlkesi
ISTQB (Uluslararası Yazılım Testi Nitelikler Kurulu), yazılım testinin yedi ilkesini özetledi:
- Test, kusurların varlığını gösterir
- Kapsamlı test imkansız
- Erken test
- Hata kümeleme
- Böcek öldürücü paradoksu
- Test, bağlama bağlıdır
- Hata yokluğu yanılgısı
Yazılım testinin bu yedi ilkesinin her birini ayrıntılı olarak inceleyelim.
Test, kusurların varlığını gösterir
Bu, ilk yazılım test ilkesidir. Bu ilkeye göre, bir yazılım test tekniği veya stratejisi, uygulamayı veya yazılımı genel kullanıma sunmadan önce bir hatayı veya kusuru belirlemenize yardımcı olabilir. Ancak bu, oluşturulan yazılım veya uygulamanın tamamen hatasız olduğunu garanti etmez.
Meslekten olmayan terimlerle ifade edecek olursak, bu ilke, test tekniklerinin ve geliştiriciler, test uzmanları ve diğerleri tarafından yürütülen testlerin hataları veya kusurları belirlemenize yardımcı olabileceğini belirtir. Ancak, oluşturulan yazılımın tamamen hata ve kusur içermediğini garanti eden hiçbir test prosedürü veya tekniği yoktur.
Kapsamlı test imkansız
Bu prensibe dalmadan önce, kapsamlı testleri anlamak iyi bir fikirdir. Kapsamlı test, bir yazılım uygulamasının tüm işlevlerinin hem geçerli hem de geçersiz girdiler ve ön koşullar kullanılarak doğrulanmasını ve test edilmesini gerektiren bir test türüdür.
Ancak kapsamlı testler gerçekçi değildir. Geçerli ve geçersiz girdilerin yanı sıra ön koşullarla yazılım veya uygulamayı test etmek imkansızdır. Bu prensibi daha iyi anlamak için bir örneğe bakalım. 0’dan bir milyara kadar sayısal girdi kabul eden bir uygulama yazdığınızı varsayalım. Zaman alıcı olacağından ve test maliyetini artıracağından artık her bir değer için çıktıyı test edemezsiniz.
Sonuç olarak, yazılımı veya uygulamayı test etmeden önce dikkatli bir planlama ve değerlendirme yapılması gerekir. Test kapsamınızın yeterli olmasını ve her bir kod parçasını incelemek zorunda kalmadan nihai ürüne güvenebilmenizi sağlar.
Erken test
Yazılım geliştirme yaşam döngüsü ile ilgili olarak, gereksinimler, işlevsellik veya tasarım aşamalarındaki kusurları veya hataları belirlemek için erken testler kritik öneme sahiptir.
Teste erken başlamak için çeşitli geliştiriciler statik test tekniğini kullanmayı seçerler. Statik test, kodu çalıştırmadan uygulamadaki aksaklıkları veya hataları test etmenize olanak tanır. Bu, geliştiricilerin ve test uzmanlarının hataları veya kusurları yazılım geliştirme yaşam döngüsünün başlarında tespit etmelerini sağlayarak zamandan, sıkı çalışmadan ve paradan tasarruf etmelerini sağlar.
Bu yazılım testi ilkesine göre, test sürecinin başlarında hataları düzeltmek, yazılım yaşam döngüsünün sonuna göre çok daha kolay ve daha ucuzdur. Kod, tasarım, işlevsellik vb. değişiklikler hem para hem de zaman açısından maliyetli olabilir. Sonuç olarak, erken testler kritiktir ve mümkün olan en kısa sürede başlamalıdır.
Hata kümeleme
Bu yazılım testi ilkesi, belirli yazılım birimlerinin, modüllerinin veya bileşenlerinin en fazla hatayı veya kusuru içerdiğini ve sonunda operasyonel hataların çoğuna neden olduğunu belirtir. Layman’ın terimleriyle, bu ilke, tespit edilen kusurların çoğunun birkaç modülde yer aldığını belirtir.
Bunu bilmek, yazılım testi için çok yararlı olabilir çünkü belirli bir modülde veya bölgede bir sorun bulursak, o alanda çok sayıda başka sorun bulma ihtimalimiz yüksektir. Testimizi, yazılımın karmaşıklığı, modül sayısı, üçüncü taraf bağımlılıkları vb. gibi diğer çeşitli faktörlere de odaklayabiliriz.
Bu alanlarda kusur bulunma olasılığı daha yüksek olduğundan, bunlara odaklanmak uygulamanızdaki hataların çoğunu bulmanıza yardımcı olabilir. Ve Pareto ilkesi de aynı şeyi söylüyor – sorunların %80’i bileşenlerin %20’sinde bulunuyor.
Pestisit paradoksu
Bu yazılım testi ilkesi, bir çiftçinin zararlıları ortadan kaldırmak için aynı mahsullerde aynı ilacı tekrar tekrar kullandığında, zararlıların sonunda bağışıklık geliştirerek ilacı etkisiz hale getirdiği teorisine dayanmaktadır. Aynısı yazılım testi için de geçerlidir.
Yazılım testinde pestisit paradoksu, hataları veya kusurları bulmak için aynı test durumlarını tekrar tekrar gerçekleştirmeyi ifade eder. Ancak, aynı test durumlarını tekrar tekrar kullanmak, sonunda yazılımdaki yeni hataları belirlemede başarısız olacaktır.
Sonuç olarak, pestisit paradoksu durumunun üstesinden gelmek için, yeni ve daha fazla kusurun keşfedilebilmesi için test senaryolarının düzenli olarak gözden geçirilmesi ve güncellenmesi gerekir. Testin etkinliğini artırmak için, test ekibi sürekli olarak mevcut test yöntemlerini geliştirmenin yollarını araştırmalı veya yazılımı doğrulamak için yeni test senaryoları oluşturmalıdır.
Test, bağlama bağlıdır
Bir doktorun aynı ilacı farklı sorunları olan iki hastayı tedavi etmek için kullanması mümkün müdür? Daha basit ve anlaşılır kılmak için şu soruyu yanıtlayın: Bir ilaç, Dollo (standart bir ateş ilacı), kalp hastalığını tedavi edebilir mi? Cevap olumsuz olacaktır. Aynısı yazılım testi için de geçerlidir.
Bu yazılım testi ilkesine göre, her tür yazılıma uyan tek bir yazılım testi yaklaşımı yoktur. Bu nedenle, farklı yazılım türleri için farklı test teknikleri kullanılmalıdır.
Örneğin, bir e-ticaret web sitesi, bir veritabanı raporlama uygulamasından farklı testler ve yaklaşımlar gerektirebilir. Bu nedenle test stratejileri veya teknikleri, uygulamanın içeriğine, yani test edilen uygulama veya yazılımın türüne göre değişmelidir.
Hata yokluğu yanılgısı
Diyelim ki oluşturulan yazılım %99 hatasız ama client’ın istediği özellik ve fonksiyonelliği sağlamıyor. Bu, oluşturulan yazılımı tam bir atık haline getirir. Hatasız yazılımlar bile, işletmenin ihtiyaçlarını karşılayamazsa işe yaramaz hale gelecektir.
Sonuç olarak, sistem gereksinimleriyle ilgili testler yapmak çok önemlidir, çünkü yazılım testi sadece hataları bulmaktan daha fazlasıdır. Ayrıca, yazılımın kullanıcının gereksinimlerini ve beklentilerini karşılayacağını garanti eder.
Yazılımın kullanılabilir olduğundan ve yazılımın kullanıcıları veya iş gereksinimlerini karşılayacağından emin olmak için kullanabileceğiniz kullanıcılardan geri bildirim almak için kullanılabilirlik testi aşamasında erken prototiplere karşı test yapabilirsiniz.