ad hoc testing how find defects without formal testing process
Ad-hoc terimi, yapı eksikliğini veya metodik olmayan bir şeyi ifade eder. Hakkında konuşurken geçici test , bunun bir form olduğu anlamına gelir siyah kutu veya herhangi bir resmi süreç olmadan gerçekleştirilen davranışsal testler.
Buradaki resmi süreç, gereksinim belgeleri, Test Planları, Test senaryoları gibi belgelere sahip olmak ve uygulanan testlerin çizelgesi ve sırası açısından uygun Test planlaması anlamına gelir. Ayrıca, test sırasında gerçekleştirilen eylemler tipik olarak belgelenmez.
Bu, esas olarak test döngüsü sırasında izlenen geleneksel veya resmi süreçlerle tespit edilemeyen kusurları veya kusurları ortaya çıkarmaya çalışmak amacıyla yapılır.
Daha önce anlaşıldığı gibi, bu testin özü, resmi veya yapılandırılmış bir test yöntemine sahip olmamaktır. Bu tür rastgele test teknikleri uygulandığında, Test uzmanları bunu, sistemi kırmak amacıyla herhangi bir özel kullanım durumu düşünmeden gerçekleştirirler.
Bu nedenle, bu tür sezgisel veya yaratıcı test metodolojisinin gerektirdiği kesinlikle daha açıktır. test cihazı son derece yetenekli, yetenekli ve sistem hakkında derinlemesine bilgi sahibi olmalıdır. Ad-hoc test, gerçekleştirilen testin tamamlanmasını sağlar ve özellikle test paketinin etkinliğini belirlemede çok yararlıdır.
Önerilen Kaynaklar=> Keşif Testi - Geleneksel Test Sınırlarının Ötesinde Nasıl Düşünülür?
Ne öğreneceksin:
- Ad-hoc Test Örneği ile Başlayalım
- Ne Zaman Ad-hoc Test Yapıyoruz?
- Ad-hoc Test Türleri
- Geçici Testin Yararları
- Ad-hoc Test Dezavantajları
- Bu Testi Daha Etkili Kılmak İçin En İyi Uygulamalar
- Sonuç
- Önerilen Kaynaklar
Ad-hoc Test Örneği ile Başlayalım
UI Sihirbazı söz konusu olduğunda bu testi nasıl gerçekleştirebileceğimize dair bir örnek.
Diyelim ki bu kullanıcı arayüzü sihirbazını kullanarak gerçekleştirilecek bir tür görev için bir plan veya şablon oluşturmanız gerekiyor. Sihirbaz, ad, açıklama vb. Gibi kullanıcı girişine sahip bir dizi bölmedir.
Sihirbaz ilerledikçe: Örneğin bölmelerden birinde kullanıcı verileri girilir ve bu kullanıcı verileri, kullanıcı verileri girilir ve bu da, UI sihirbazının sihirbazı tamamlamak ve sihirbazı dağıtmak / etkinleştirmek için ilişkili verileri ekleyen bir bağlam açılır kutusu atmasını içerir.
Bu test cihazını test etmek için aşağıdaki gibi düzenli testlerini yapar:
unix'te, w (yazma) erişim izni,
- Sihirbazı tüm geçerli verilerle başarıyla tamamlayın ve planı oluşturun.
- Yolun ortasında sihirbazı iptal edin.
- Sihirbaz aracılığıyla oluşturulan bir planı düzenleyin.
- Oluşturulan planı silin ve hiçbir kalıntısı olmadığını görün.
- Sihirbaza negatif bir değer girin ve uygun hata mesajlarının görüldüğüne bakın.
Şimdi, yukarıdaki örnek için anlık testler için bazı test senaryoları aşağıda verilmiştir gerçekleştirilebilir mümkün olduğunca çok sayıda kusuru ortaya çıkarmak için:
- Negatif veriler eklemeye çalışırken, düzgün işlenip işlenmediklerini görmek için sınırlandırılmamış belirli özel karakterler ekleyin. Örneğin, bazen sihirbazlar {veya (parantezleri kısıtlamaz, ancak bazı durumlarda bu, yazıldığı dile bağlı olarak kodla çakışabilir ve çok güvenilmez davranışlara neden olabilir.
- Başka bir test, özellikle pop-up'larla ilgilidir. Bir kullanıcı açılır pencerenin başlamasına neden olabilir ve ardından klavyedeki geri al düğmesine basmayı deneyebilir. Bunu yaptığımda arka plan sihirbazının tamamen kaybolduğunu ve açılır pencerenin başlatıldığı noktaya kadar girilen tüm kullanıcı verilerinin kaybolduğunu birçok kez gözlemledim!
Ad-hoc testin özellikleri:
Yukarıdaki senaryolara dikkat ederseniz, bu tür testlerin çok farklı özelliklerini göreceksiniz.
Onlar:
- Her zaman test hedefiyle uyumludurlar. Ancak, sistemi bozmak amacıyla gerçekleştirilen bazı sert testlerdir.
- Test edenin, test edilen sistem hakkında tam bilgi ve farkındalığa sahip olması gerekir. Bu testin sonucu, test sürecinin boşluklarını vurgulamaya çalışan hataları bulur.
- Ayrıca yukarıdaki iki teste bakıldığında, buna doğal tepki şudur: Bu tür bir test, ilişkili bir kusur olmadıkça bir yeniden test için uygun olmadığından, sadece bir kez yapılabilir.
Ne Zaman Ad-hoc Test Yapıyoruz?
Gerçekten milyon dolarlık bir soru!
Çoğu zaman test ekipleri, sınırlı zaman çizelgeleri içinde test etmek için her zaman çok fazla özellikle yüklenir. Bu sınırlı zaman aralığında, tamamlanması gereken resmi süreçten türetilen birçok test etkinliği vardır. Bu gibi durumlarda, geçici testler teste girmenin yolunu bulmakta zayıftır.
Bununla birlikte, deneyimlerime göre, bir tur geçici test, ürün kalitesi için harikalar yaratabilir ve birçok tasarım sorusunu gündeme getirebilir.
Geçici test, yapılandırılması gerekmeyen bir 'vahşi çocuk' test tekniği olduğundan, genel öneri, mevcut test kümesinin yürütülmesinden sonra gerçekleştirilmesi gerektiğidir. Diğer bir bakış açısı, bunun daha az zaman nedeniyle ayrıntılı test yapılamadığında yapılabileceğidir.
Benim görüşüme göre şunu söyleyebilirim Geçici testler neredeyse her zaman yapılabilir - başlangıçta, ortaya ve sona doğru! Herhangi bir zamanda yerini bulur. Bununla birlikte, maksimum değeri ortaya çıkarmak için geçici test yapılması gerektiğinde, en iyi, test edilen sistem hakkında derinlemesine bilgiye sahip deneyimli bir test uzmanı tarafından değerlendirilir.
Ne zaman infaz edilmeyecek?
Önceki soru bir milyon dolar değerinde olsaydı, bu bir milyar değerinde olmalı!
Geçici testlerin ne kadar etkili ve verimli olabileceğini belirlemiş olsak da, yetenekli ve yetenekli bir test cihazı olarak bu tür testlere ne zaman yatırım yapmamamız gerektiğini de çözmemiz gerekiyor. Test sahibinin takdirine bağlı olmasına rağmen, işte gerekli olmayabilecek bazı öneriler / örnekler.
- Kusurlu bir test senaryosu olduğunda bu testten kaçının. Böyle bir durumda, test durumu başarısızlık noktasını belgelemek ve ardından hatayı giderildiğinde doğrulamak / yeniden test etmek gerekir. Dolayısıyla burada geçerli olmayacak.
- Müşterilerin veya müşterilerin davet edilebileceği belirli senaryolar da olabilir. yazılımın beta sürümünü test edin . Böyle durumlarda bu test yapılmamalıdır.
- Başka bir senaryo, eklenen çok basit bir UI ekranının olmasıdır. Maksimum kusurları ortaya çıkarmak için geleneksel pozitif ve negatif testler burada yeterli olmalıdır.
Ad-hoc Test Türleri
Geçici testler aşağıdaki üç kategoriye ayrılabilir:
# 1) Arkadaş Testi
Bu test biçiminde, aynı modül üzerinde çalışmak üzere seçilecek bir test üyesi ve bir geliştirme üyesi olacaktır. Hemen sonra geliştirici birim testini tamamlar , test cihazı ve geliştirici birlikte oturur ve modül üzerinde çalışın. Bu tür testler, özelliğin her iki taraf için daha geniş bir kapsamda görüntülenmesini sağlar.
Geliştirici, test edenin çalıştırdığı tüm farklı testlerin bir perspektifini kazanacak ve test uzmanı, geçersiz senaryolar tasarlamaktan kaçınmasına yardımcı olacak ve böylece geçersiz kusurları önleyecek doğal tasarımın nasıl olduğuna dair bir bakış açısı kazanacaktır. Birinin diğerini düşünmesine yardımcı olacaktır.
# 2) Çift Testi
Bu testte, iki test kullanıcısı, aralarında paylaşılan aynı test kurulumuna sahip bir modül üzerinde birlikte çalışır. Bu test biçiminin arkasındaki fikir, iki test uzmanının bir takım kusurlara sahip olmak için fikirler ve yöntemler için beyin fırtınası yapmasını sağlamaktır. Her ikisi de test çalışmalarını paylaşabilir ve yapılan tüm gözlemlerin gerekli dokümantasyonunu yapabilir.
# 3) Maymun Testi
Bu test, esas olarak birim test seviyesinde gerçekleştirilir. Test cihazı, sistemin herhangi bir çökmeye dayanabilmesini sağlamak için verileri veya testleri tamamen rastgele bir şekilde ayrıştırır. Bu test ayrıca iki kategoriye ayrılabilir:
temel html ve css mülakat soruları
Geçici Testin Yararları
Test, test uzmanının gerektiği kadar yaratıcı olmasını garanti eder.
Bu, test kalitesini ve verimliliğini aşağıdaki gibi artırır:
- Göze çarpan en büyük avantaj, bir test uzmanının, yazılımı test etmek için uygulayabilecekleri çeşitli yenilikçi yöntemler nedeniyle, geleneksel testlere göre kusur sayısını bulabilmesidir.
- Bu test şekli SDLC'nin herhangi bir yerinde uygulanabilir; sadece test ekibiyle sınırlı değildir. Geliştiriciler ayrıca bu testi gerçekleştirerek daha iyi kod yazmalarına yardımcı olabilir ve ayrıca hangi sorunların ortaya çıkabileceğini tahmin edebilir.
- En iyi sonuçları elde etmek için başka bir testle birleştirilebilir ve bu da bazen düzenli test için gereken süreyi kısaltabilir. Bu, daha kaliteli test senaryolarının oluşturulmasını ve genel olarak ürünün daha kaliteli olmasını sağlayacaktır.
- Test cihazı üzerindeki ekstra yükü önleyen herhangi bir dokümantasyonun yapılmasını zorunlu kılmaz. Bir test uzmanı, temeldeki mimariyi gerçekten anlamaya odaklanabilir.
- Test etmek için fazla zamanın olmadığı durumlarda, bu, test kapsamı ve kalitesi açısından çok değerli olabilir.
Ad-hoc Test Dezavantajları
Geçici testin de birkaç dezavantajı vardır. Bazılarına bir göz atalım. telaffuz edilen dezavantajlar:
Çok organize olmadığı ve zorunlu bir dokümantasyon olmadığı için, en belirgin sorun, test edenin hafızadaki ad-hoc senaryoların tüm ayrıntılarını hatırlaması ve hatırlaması gerektiğidir. Bu, özellikle farklı bileşenler arasında çok fazla etkileşimin olduğu senaryolarda daha da zor olabilir.
- İlk noktadan itibaren, bu aynı zamanda bilgi istenirse sonraki denemelerde kusurların yeniden yaratılamamasına neden olur.
- Bunun gün ışığına çıkardığı bir diğer önemli soru da çaba hesap verebilirliğidir. Bu planlanmadığı / yapılandırılmadığı için, bu tür testler için harcanan zaman ve çabayı hesaba katmanın bir yolu yoktur.
- Ad-hoc testler, potansiyel kusurlu alanları önceden görmek açısından proaktif ve sezgisel olmayı gerektirdiğinden, ekipte yalnızca çok bilgili ve yetenekli bir test uzmanı tarafından yapılmalıdır.
Bu Testi Daha Etkili Kılmak İçin En İyi Uygulamalar
Bu testin güçlü ve zayıf yönlerini uzun uzadıya tartıştık.
İdeal olarak, geçici test, SDLC'de yerini bulmalıdır, ancak uygun şekilde yaklaşılmazsa, maliyetli ve değerli test zamanı kaybı olabilir. Aşağıda, geçici testi etkili kılmak için birkaç ipucu verilmiştir:
# 1) Kusur eğilimli alanları belirleyin:
Belirli bir yazılım parçasını test etme konusunda iyi bir fikriniz olduğunda, hatalara diğerlerinden daha yatkın olan belirli özelliklerin olacağını kabul edersiniz. Sistemde yeniyseniz, devam edin ve bunlara karşı açılan özellik kusurlarını kontrol edin.
Belirli bir özellikteki kusurların sayısı, size bunun hassas olduğunu ve anlık test yapmak için tam olarak o alanı seçmeniz gerektiğini gösterecektir. Bu, bazı ciddi kusurları ortaya çıkarmanın çok zaman açısından verimli bir yolu olduğunu kanıtlıyor.
# 2) Yapı uzmanlığı:
Kuşkusuz, daha fazla deneyime sahip bir test uzmanı, çok fazla tecrübesi olmayan birine kıyasla daha sezgiseldir ve hataların nerede olabileceğini tahmin edebilir. Deneyimli olsun ya da olmasın, dalmak ve test edilmekte olan sistem üzerinde uzmanlık oluşturmak kişiye bağlıdır.
Evet, deneyimli test uzmanları, yıllar içinde geliştirilen becerileri işe yaradığından bir avantaja sahiptir, ancak yeni test uzmanları bunu, daha iyi anlık senaryolar tasarlamak için olabildiğince fazla bilgi edinmek için bir platform olarak kullanmalıdır.
# 3) Test kategorileri oluşturun:
Test edilecek özelliklerin listesinin farkına vardıktan sonra, bu özellikleri nasıl sınıflandıracağınıza ve test edeceğinize karar vermek için birkaç dakikanızı ayırın. Örneğin, Yazılımın başarısı için kritik görüneceğinden, kullanıcı tarafından en görünür olan ve en yaygın olarak kullanılan özellikleri her şeyden önce test etmeye karar vermelisiniz.
Daha sonra bunları işlevsellik / öncelik açısından sınıflandırabilir ve bölümlere göre test edebilirsiniz.
Bunun özellikle çok önemli olduğu başka bir örnek, bileşenler veya modüller arasında entegrasyon olup olmadığıdır. Bu durumlarda ortaya çıkabilecek pek çok anormallik olabilir. Sınıflandırmanın kullanılması, bu tür testlere en az bir veya iki kez dokunmaya yardımcı olacaktır.
# 4) Kaba bir plan yapın:
Evet, evet, planlaması veya dokümantasyonu olmaması gereken test amaçlı geçici testi tanımladığımız için bu nokta kafanızı biraz karıştırabilir. Buradaki fikir, geçici testlerin özüne bağlı kalmaktır, ancak yine de, nasıl test etmeyi planladığınıza dair bazı kaba işaretler not edin.
Çok temel bir örnek, bazen yapmayı düşündüğünüz tüm testleri hatırlayamayabileceğinizdir. Bu yüzden onları not almak hiçbir şeyi kaçırmamanızı sağlar.
# 5) Araçlar:
Hepimizin çok sık karşılaştığı bir örneği ele alalım. Çoğu zaman gözlemlerseniz, işlevselliğin kendi içinde test edilmesi, davranışında herhangi bir tutarsızlık rapor edilmeden başarılıdır. Ancak, perde arkasındaki günlükler, test hedefini hiçbir şekilde engellemediği için testçiler tarafından gözden kaçırılabilecek bazı istisnaları rapor ediyor olabilir.
Bunların ciddiyeti bile yüksek olabilir. Bu nedenle, bunu hemen tespit etmeye yardımcı olacak araçları ve öğrenmemiz bizim için çok önemlidir.
# 6) Daha fazla kusur için belge:
Yine anlıyorum ki, bu tekrar bazı kaşları kaldırabilir. Dokümantasyonun ayrıntılı olması gerekmez, ancak kapsanan tüm farklı senaryolara kendi referansınız için küçük bir not, ilgili adımlardaki sapmalar ve belirli test özelliği kategorisi için bu kusurları kaydedin.
Bu, genel test grubunu geliştirmenize de yardımcı olur ve böylece mevcut test senaryolarını nasıl doğaçlama yapacağınıza veya gerekirse daha fazlasını nasıl ekleyeceğinize karar verebilirsiniz.
Sonuç
Geçici test tekniklerini ayrıntılı olarak tartıştık - güçlü yönleri, zayıf yönleri, yararlı olacağı ve olmayacağı durumlar.
Bu, bir test uzmanının yaratıcılığını maksimum düzeyde karşılamayı ve tatmin etmeyi garanti eden bir test tekniğidir. Benim bütününde test kariyeri , İnovasyon yapmanın sınırı olmadığı ve yalnızca daha bilgili olduğunuz için anlık testlerden en üst düzeyde memnuniyeti elde ediyorum.
Bunu söyledikten sonra, yukarıdaki tüm bilgilerden geri alınması gereken en önemli şey, özel testlerin güçlü yönlerinden nasıl yararlanılacağını belirleyin ve genel test sürecine ve ürün kalitesine değer katmasını sağlayın.
Yazar hakkında: Bu Sneha Nadig'in konuk makalesi. Manuel ve otomasyon test projelerinde 7 yılı aşkın deneyime sahip bir Test lideri olarak çalışmaktadır.
Projenizde geçici testler yapıyor musunuz? Geçici testi başarılı kılmak için önerileriniz nelerdir?
Önerilen Kaynaklar
- Fonksiyonel Test ve Fonksiyonel Olmayan Test
- Alfa Testi nedir? Kusurlar için Erken Alarm
- Kara Kutu Testi ile Beyaz Kutu Testi Arasındaki Temel Farklılıklar
- Birim Testi, Entegrasyon Testi ve İşlevsel Test Arasındaki Farklar
- Performans Testi - Yük Testi - Stres Testi (Fark)
- Keşif Testleri ve Komut Dosyalı Testler: Kim Kazanır?
- Kusur Temelli Test Tekniği Nedir?
- B2B (İşletmeler Arası) Ağ Geçidi Test Süreci