7 temel ISTQB test ilkesi | #3 Yazılım testinde ilk adımlar

Kesin ve doğru yazılım testi yapmak çok sayıda ilkeyi takip eder. Uluslararası Yazılım Testi Yeterlilikler Kurulu, bugün tartışacağımız yedi temel ilkeyi ayırt eder. Öğrenmek için mi merak ediyorsunuz? Temel ISTQB test ilkeleri hakkında bir makale okuyun!

ISTQB test ilkeleri – içindekiler:

1. Test, kusurları ortaya çıkarır, ancak yokluklarını kanıtlayamaz
2. Kapsamlı test imkansız
3. Erken test zamandan ve paradan tasarruf sağlar
4. Arıza kartopu etkisi
5. Böcek öldürücü paradoksu
6. Bu koşullara bağlıdır
7. Kusursuz yazılımın reklamını yapmak, hareketsizdir
8. Özet

Test, kusurları ortaya çıkarır, ancak yokluklarını kanıtlayamaz

Test etme , hataları bulma olasılığını artırır ve bu da onları düzeltme şansını kolaylaştırır. Ancak, büyük çoğunluğu tespit edilip düzeltilse bile yazılımın tüm kusurlardan arınmış olduğunu tam olarak garanti edemez. Kusursuz yazılım oluşturamama nedeniyle, çoğu kişi süreci tasarım olarak olumsuz olarak değerlendirir, çünkü hiçbir zaman olumlu bir sonuç alamayacaksınız ve programlarda her zaman bir miktar “kir” bulacaksınız.

Kapsamlı test imkansız

Yukarıdaki temel kural , yazılımın tüm arızalarını tespit etmenin boşuna olduğunu belirtir. Ancak, bu basit kısa programlar için geçerli değildir. Bu da, bazı programları tamamen test etmek için tüm girdi ve ön koşul kombinasyonlarını görme şansı olduğunu gösterir. Gelişmiş yazılımları değerlendirirken, en iyi yapay zeka bile, manuel test cihazlarını bırakın, gerekli tüm ölçümleri gerçekleştiremez. Otomatik değerlendiriciler, uygulamaları daha verimli ve doğru bir şekilde inceleyecek, ancak yine de kusursuz performansı garanti edemezler. Bunu yapmak için, önceliklendirme, risk analizi ve diğer test tekniklerini bulma ve çalıştırma gibi ek görevlere başlamanız gerekir.

Erken test zamandan ve paradan tasarruf sağlar

Birçok profesyonel de bu ilkeye “sola kayma” diyor. Kusurları ne kadar erken tespit ederseniz, onları o kadar kolay düzeltebilirsiniz, bu nedenle statik ve dinamik testler mümkün olan en kısa sürede başlamalıdır. Kısaca:

• Statik test – kodu çalıştırmadan ürünü değerlendirmek.
• Dinamik test - performansı sırasında bir modülün veya sistemin kodunun değerlendirilmesi

Uygulamanın ilk aşamalarında kusurları tespit etmek, daha ileri tanılamayı kolaylaştırır. Ancak, yazılımın iki alanı etkileşime girdiğinde, hataya sahip olanı tam olarak belirleyememesi nedeniyle kusurları değiştirmek zahmetli hale gelir. Bu gibi durumlarda, üstesinden gelmek için ekstra zaman, çaba ve insan gücü gerekir. Sonuç olarak, çatlakların çoğalmasını önleyebilen, yüzeydeki engellere hızlı tepkidir.

Arıza kartopu etkisi

Çoğu aksaklık, çoğu kritik modülde kümelenme eğilimindedir, bu nedenle derinlemesine incelemeleri, çoğunu ortaya çıkarır ve yeterince ortadan kaldırır. Bu gruplar, eylemlerin gelecekteki davranışlarını belirlemek ve belirlemek için risk analizi yürütmenin ana odak noktası haline gelir . Kusurların çoğu, kullanıcıların izlediği yolları izledikten sonra ortaya çıkar, ancak bu durumlarda, bilgi tek başına modülleri kusursuz hale getirmez.

Pareto ilkesi, sonuçların %80'inin nedenlerin yalnızca %20'sinden kaynaklandığını söyler. Diğer bir deyişle, hataların %80'i modüllerin %20'sinde bulunur. Bir modülde çok sayıda arızayla karşılaşırsanız, orada olacakları için kazmaya devam edin.

Böcek öldürücü paradoksu

Aynı testleri tekrar tekrar çalıştırmak başarısız olabilir, çünkü bunlar en başta yanlış tasarlanmış olabilir ve hiçbir zaman etkili olmazlar. Yazılımda yeni hatalar bulma şansını artırmak için testleri değiştirmeniz ve yükseltmeniz gerekir.

Tamamen yeni bir teşhis sistemi oluşturmak da işe yaramaz. Önceki kombinasyonları takip etmek, değerlendirme sürecini aynı seviyede durdurabilir. Bu ilke, 'pestisit paradoksu' olarak adlandırılır, çünkü zararlıları kontrol eden pestisitler de belirli bir miktarda kullanımdan sonra etkinliğini kaybeder.

Bu koşullara bağlıdır

Testi yürütme şekli, incelenen konulara bağlıdır. Bu nedenle, bir muhasebe programını, bir video oyununu veya bir sosyal ağ uygulamasını test etmek büyük ölçüde farklılık gösterir. Aynı zamanda duruma da bağlıdır, örneğin, bir uygulamanın kullanıcılar için çekiciliğini, kullanım kolaylığını, görsel katmanını vb. kontrol etme gibi pratikliğine odaklanan bir analiz ayrıca programın işlevsel özelliklerine yönelik değerlendirmelerden farklıdır, örn. doğru hesaplamalar

Kusursuz yazılımın reklamını yapmak, hareketsizdir

Çeşitli teşhis araçlarının uygulanması, yerinde uygulamaları garanti edemez. Uygulamalarının bu şekilde olduğunu iddia eden ve reklamını yapanların çoğu yanılıyor, ancak muhtemelen sadece pazarlama çabaları için iddiada bulunuyorlar. Mümkün olduğu kadar çok hatayı ortaya çıkarma ve düzeltme olasılığını artırmak için birden fazla manuel ve otomatik test gerçekleştirebilirsiniz, ancak yine de mükemmel performans garantisi yoktur. Bazı durumlarda, engeller işletim yazılımı ile ilgilidir, örneğin program tüm kullanıcı beklentilerini karşılamayabilir.

ISTQB test ilkeleri – özet

ISTQB, temel düzeyde, bir yazılım testçisinin izlemesi gereken yedi ISTQB test ilkesini bu şekilde sunar. İlk olarak, tam yazılım teşhisinin uygulanabilir olmadığını gösterirler, bu nedenle diğer şeylerin yanı sıra testleri değiştirmek ve ayrıca anahtar modüllerde kapsamlı bir arama yapmak çok önemlidir. Bu eylemler, gelecekte arıza olasılığını azaltan kusurların çoğunun aranmasını ve temizlenmesini geliştirir.

Yazılım testi nedir? Şimdi cevabı biliyorsun! Python ve Javascript ile ilgili diğer serimize göz atın!

İçeriğimizi beğendiyseniz, Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest'teki meşgul arılar topluluğumuza katılın.

Yazar: Robert Whitney

BT departmanlarına koçluk yapan JavaScript uzmanı ve eğitmeni. Ana hedefi, başkalarına kodlama yaparken nasıl etkili bir şekilde işbirliği yapacaklarını öğreterek ekip üretkenliğini yükseltmektir.

Tüm gönderileri görüntüle

Yazılım testinde ilk adımlar:

1. Yazılım testi nedir?
2. Yazılım hataları hakkında 1 büyük gerçek
3. Yedi temel ISTQB test ilkesi
4. STLC'nin 6 aşaması
5. Test ve hata ayıklama
6. Yazılım test sürecinde doğrulama ve doğrulama