Örneklerle Yazılım Testinin 7 Prensibi

Bu eğitimde, her Yazılım test uzmanının ve QA profesyonelinin bilmesi gereken yedi temel Yazılım Test Prensibi tanıtılmaktadır.

Aşağıdakilerle test prensiplerini öğrenelim video örneği-

Tıkla okuyun videoya erişilemiyorsa

Olayın Arka Planı

Yazılım testi yaparken hedeften sapmadan optimum test sonuçlarına ulaşmanız önemlidir. Peki test için doğru stratejiyi izlediğinizi nasıl belirlersiniz? Bunun için bazı temel test prensiplerine bağlı kalmanız gerekir. İşte yazılım sektöründe yaygın olarak uygulanan yedi ortak test prensibi.

Bunu anlamak için, bir dosyayı A klasöründen B Klasörüne taşıdığınız bir senaryoyu düşünün.

Bunu test edebileceğiniz tüm olası yolları düşünün.

Alışılmış senaryoların dışında, aşağıdaki koşulları da test edebilirsiniz

• Dosya Açıkken taşınmaya çalışılıyor
• Dosyayı B Klasörüne yapıştırmak için güvenlik haklarınız yok
• B klasörü paylaşılan bir sürücüde ve depolama kapasitesi dolu.
• B klasöründe zaten aynı adda bir dosya var, aslında liste sonsuzdur
• Veya test edilecek 15 giriş alanınız olduğunu ve her birinin 5 olası değeri olduğunu varsayalım; test edilecek kombinasyon sayısı 5^15 olacaktır.

Tüm olası kombinasyonları test edecek olsaydınız, projenin YÜRÜTME SÜRESİ VE MALİYETLERİ katlanarak artacaktır. Test çabalarını optimize etmek için belirli prensiplere ve stratejilere ihtiyacımız var

İşte 7 İlke:

1) Kapsamlı testler mümkün değildir

Evet! Kapsamlı testler mümkün değildir. Bunun yerine uygulamanın risk değerlendirmesine dayalı olarak optimum miktarda teste ihtiyacımız var.

Milyon dolarlık soru şu: Bu riski nasıl belirlersiniz?

Bunu cevaplamak için bir egzersiz yapalım

Sizce, hangi operasyon sizin için en olası sonuçtur? Operasistem başarısız mı olacak?

Eminim çoğunuz tahmin etmişsinizdir, 10 farklı uygulamayı aynı anda açmak.

Eğer bunu test ediyorsan Operasistemi incelerseniz, çoklu görev faaliyetlerinde kusurların bulunabileceğini ve kapsamlı bir şekilde test edilmesi gerektiğini fark edeceksiniz; bu da bizi bir sonraki prensibimize getiriyor. kusur Clustering

2) Kusur Clustering

kusur ClusterBu, az sayıda modülün tespit edilen kusurların çoğunu içerdiğini belirtir. Bu Pareto Prensibinin yazılım testine uygulanmasıdır: sorunların yaklaşık %80'i modüllerin %20'sinde bulunur.

Bu tür riskli modülleri deneyimleyerek tespit edebilirsiniz. Ancak bu yaklaşımın da kendi sorunları var

Aynı testler defalarca tekrarlanırsa, sonuçta aynı test senaryoları artık yeni hatalar bulmayacaktır.

3) Pestisit Paradoksu

Tarım sırasında böcekleri yok etmek için aynı pestisit karışımının tekrar tekrar kullanılması, zamanla böceklerin pestisitlere karşı direnç geliştirmesine ve dolayısıyla pestisitlerin böcekler üzerinde etkisiz olmasına yol açacaktır. Aynı şey yazılım testi için de geçerlidir. Aynı dizi tekrarlı testler yapılırsa, yöntem yeni kusurların keşfedilmesinde yararsız olacaktır.

Bunun üstesinden gelmek için test senaryolarının düzenli olarak gözden geçirilmesi ve revize edilmesi, daha fazla kusur bulunmasına yardımcı olacak yeni ve farklı test senaryolarının eklenmesi gerekir.

Test uzmanları yalnızca mevcut test tekniklerine güvenemezler. Testi daha etkili hale getirmek için mevcut yöntemleri sürekli olarak iyileştirmeye dikkat etmelidir. Ancak tüm bu ter ve sıkı test çalışmalarından sonra bile ürününüzün hatasız olduğunu asla iddia edemezsiniz. Bu noktaya gelmek için, halka açık lansmanının bu videosunu izleyelim. Windows 98

MICROSOFT gibi bir şirketin işletim sistemini yeterince test etmediğini ve işletim sisteminin kamuoyuna açık lansmanı sırasında çökmesini izlemek için itibarını riske atacağını mı düşünüyorsunuz!

4) Test kusurların varlığını gösterir

Bu nedenle, test ilkesi şunu belirtir: Test, kusurların varlığından bahseder ve kusurların yokluğundan bahsetmez. Yazılım testi yazılımda keşfedilmemiş kusurların kalma olasılığını azaltır ancak hiçbir kusur bulunmasa bile bu doğruluğun kanıtı değildir.

Peki ya ekstra çalışırsanız, tüm önlemleri alırsanız ve yazılım ürününüzü %99 hatasız hale getirirseniz. Ve yazılım müşterilerin ihtiyaçlarını ve gereksinimlerini karşılamıyor.

Bu bizi bir sonraki prensibimize götürür: Hatanın Olmaması

5) Hatanın Olmaması – Yanlışlık

%99 oranında hatasız olan yazılımın hala kullanılamaz durumda olması mümkündür. Sistemin yanlış gereksinim açısından kapsamlı bir şekilde test edilmesi durumunda bu durum söz konusu olabilir. Yazılım testi yalnızca kusurları bulmak değil, aynı zamanda yazılımın iş ihtiyaçlarını karşılayıp karşılamadığını da kontrol etmektir. Hatanın olmaması bir yanılgıdır, yani sistem yapısı kullanılamazsa ve kullanıcının ihtiyaç ve gereksinimlerini karşılamıyorsa hataları bulmak ve düzeltmek yardımcı olmaz.

Bu sorunu çözmek için testin bir sonraki ilkesi Erken Testin

6) Erken Test

Erken Test – Test, Yazılım Geliştirme Yaşam Döngüsünde mümkün olduğunca erken başlamalıdır. Böylece gereksinimlerdeki veya tasarım aşamasındaki herhangi bir kusur erken aşamalarda yakalanır. Bir Kusuru testin erken aşamalarında düzeltmek çok daha ucuzdur. Ancak teste ne kadar erken başlanmalıdır? Gereksinimler tanımlandığı anda hatayı bulmaya başlamanız önerilir. Bu ilke hakkında daha sonraki bir eğitim öğreticisinde daha fazla bilgi edinebilirsiniz.

7) Test bağlama bağlıdır

Test bağlama bağlıdır; bu, temel olarak bir e-ticaret sitesini test etme yönteminizin, kullanıma hazır ticari bir uygulamayı test etme yönteminizden farklı olacağı anlamına gelir. Geliştirilen yazılımların tümü aynı değildir. Uygulama türüne bağlı olarak farklı bir yaklaşım, metodolojiler, teknikler ve test türleri kullanabilirsiniz. Örneğin, bir perakende mağazasındaki herhangi bir POS sisteminin test edilmesi, bir ATM makinesinin test edilmesinden farklı olacaktır.

Efsane: “İlkeler yalnızca referans amaçlıdır. Bunları pratikte kullanmayacağım.”

Bu çok yanlış. Test İlkeleri etkili bir test oluşturmanıza yardımcı olacaktır. Test Stratejisi ve test senaryolarını yakalayan taslak hata.

Ancak test ilkelerini öğrenmek, ilk kez araba kullanmayı öğrenmek gibidir.

Başlangıçta, araba kullanmayı öğrenirken vites geçişleri, hız, debriyaj kullanımı vb. gibi her şeye ve her şeye dikkat edersiniz. Ancak deneyim kazandıkça, sadece sürüşe odaklanırsınız, gerisi doğal olarak gelir. Öyle ki, arabanın içindeki diğer yolcularla bile sohbet edebiliyorsunuz.

Aynı şey test ilkeleri için de geçerlidir. Deneyimli test uzmanları bu ilkeleri, hiç düşünmeden uygulayacak kadar içselleştirmişlerdir. Dolayısıyla ilkelerin pratikte kullanılmadığı efsanesi kesinlikle doğru değildir.