Duman Testi ve Sanity Testi: Örneklerle Fark

smoke testing vs sanity testing

Duman Testi ve Akıl Testi arasındaki Farkları örneklerle ayrıntılı olarak keşfedin:

Bu eğitimde, Yazılım Testinde Akıl Testi ve Duman Testinin ne olduğunu öğreneceğiz. Ayrıca basit örneklerle Sanity ve Smoke testi arasındaki temel farkları öğreneceğiz.

Çoğu zaman Sanity Testing ve Smoke Testing'in anlamı arasında kafamız karışır. Her şeyden önce, bu iki test yol ' farklı ”Ve bir test döngüsünün farklı aşamalarında gerçekleştirilir.

Ne öğreneceksin:

• Sağlık Testi
• Benim deneyimim
• Sanity Testing Vs Regresyon Testi
• Mobil Uygulama Testi Stratejisi
• İhtiyati önlemler
• Duman Testi
• Duman Testi Örnekleri
  • # 1) Kabul Testi
  • # 2) Entegrasyon Testi
  • # 3) Sistem Testi
• SCRUM Metodolojisindeki Önemi
• Duman Testi Vs Yapı Kabul Testi
• Duman Test Döngüsü
• Duman Testini Kim Yapmalıdır?
• Duman Testlerini Neden Otomatikleştirmeliyiz?
• Avantajlar ve dezavantajlar
• Duman ve Akıl Testi Arasındaki Fark
  • DUMAN TESTİ
  • SAĞLIK TESTİ
• Önerilen Kaynaklar

Sağlık Testi

Sağlık Testi, bir QA olarak tüm test durumlarını çalıştırmak için yeterli zamanımız olmadığında yapılır. Fonksiyonel test , UI, OS veya Tarayıcı Testi.

Dolayısıyla ben tanımlardım

'Her uygulamaya ve etkisine dokunmak için yapılan, ancak kapsamlı veya derinlemesine olmayan bir test yürütmesi olarak Sağlık Testi, uygulamaya ve etkisine bağlı olarak işlevsel, kullanıcı arayüzü, sürüm vb. Testleri içerebilir.'

Hepimiz bir veya iki gün içinde çıkış yapmamız gereken bir duruma düşmüyor muyuz, ancak test için yapı hala yayınlanmadı mı?

java'da deneyimli olanlar için web hizmetleri mülakat soruları ve cevapları

Ah evet, bahse girerim bu durumla Yazılım Testi deneyiminizde en az bir kez karşılaşmış olmanız gerekir. Pekala, bununla çok karşılaştım çünkü projelerim çoğunlukla çevikti ve bazen aynı gün teslim etmemiz istendi. Hata! Yapıyı birkaç saat içinde nasıl test edip yayınlayabilirim?

Bazen çıldırırdım çünkü küçük bir işlevsellik olsa bile, çıkarım çok büyük olabilirdi. Ve pastanın üzerine krema olarak, müşteriler bazen fazladan zaman vermeyi reddediyorlar. Tüm testi birkaç saat içinde nasıl tamamlayabilirim, her işlevi nasıl doğrulayabilirim, Hatalar ve serbest bırakmak mı?

Tüm bu tür sorunların cevabı çok basitti, yani Sağlık Testi stratejisi.

Bu testi bir modül veya işlevsellik veya tam bir sistem için yaptığımızda, Yürütme için test senaryoları aynı şeyin tüm önemli bit ve parçalarına dokunacak şekilde seçilir, yani geniş ancak sığ test.

Bazen test, test senaryosu olmadan rastgele bile yapılır. Ama hatırla, Sanity testi yalnızca zamanınız kısıtlı olduğunda yapılmalıdır, bunu asla normal sürümleriniz için kullanmayın. Teorik olarak, bu test bir alt kümesidir Gerileme testi .

Benim deneyimim

Yazılım Testindeki 8 yılı aşkın kariyerimin dışında, 3 yıldır çalışıyordum Çevik metodolog y ve bu, çoğunlukla bir akıl sağlığı testi kullandığım zamandı.

Tüm büyük sürümler sistematik bir şekilde planlandı ve uygulandı, ancak bazen küçük sürümlerin mümkün olan en kısa sürede teslim edilmesi istendi. Test senaryolarını belgelemek, yürütmek, hata dokümantasyonu yapmak, regresyon yapmak ve tüm süreci takip etmek için fazla zamanımız olmadı.

Bu nedenle, bu tür durumlarda takip etmeye alıştığım temel işaretlerden bazıları şunlardır:

# 1) Uygulamayı tartışırken yönetici ve geliştirici ekibiyle oturun çünkü hızlı çalışmaları gerekir ve bu nedenle bizi ayrı ayrı açıklamalarını bekleyemeyiz.

Bu aynı zamanda neyi uygulayacakları, hangi alanı etkileyeceği vb. Hakkında bir fikir edinmenize yardımcı olacaktır, bu yapılması gereken çok önemli bir şeydir çünkü zaman zaman sonuçların ve mevcut herhangi bir işlevselliğin farkına varmayız. (en kötü ihtimalle) engellenecek.

#iki) Zamanınız kısıtlı olduğundan, geliştirme ekibi uygulama üzerinde çalışırken, test durumlarını kabaca Evernote vb. Araçlara not edebilirsiniz. Ancak bunları daha sonra ekleyebilmek için bir yere yazdığınızdan emin olun. test durumu aracı.

# 3) Uygulamaya göre test yatağınızı hazır tutun ve eğer bir test yatağı zaman alacaksa (ve bu, sürüm için önemli bir testtir) belirli bir veri oluşturma gibi herhangi bir tehlike işareti olduğunu düşünüyorsanız, derhal bu bayrakları kaldırın ve müdürünüzü bilgilendirin veya Barikat hakkında PO.

Müşterinin en kısa zamanda istediği için, bu, yarı test edilmiş olsa bile QA'nın yayınlanacağı anlamına gelmez.

# 4) Ekibiniz ve yöneticinizle, zaman sıkışıklığı nedeniyle hataları yalnızca geliştirme ekibine ileteceğiniz ve hata izleme aracında farklı aşamalar için hataları işaretlemenin daha sonra yapılacağı resmi ekleme sürecinin zamandan tasarruf etmek için yapılacağına dair bir anlaşma yapın. .

# 5) Geliştirme ekibi sonunda test ederken, onlarla eşleştirmeye çalışın (dev-QA eşlemesi olarak adlandırılır) ve kurulumlarının kendisinde temel bir tur yapın; bu, temel uygulama başarısız olursa derlemenin ileri ve geri gitmesini önlemeye yardımcı olacaktır. .

# 6) Artık yapıya sahip olduğunuza göre, önce iş kurallarını ve tüm kullanım durumlarını test edin. Bir alan, navigasyon vb. Gibi testleri daha sonrası için saklayabilirsiniz.

# 7) Bulduğunuz hatalar ne olursa olsun, hepsini bir yere not edin ve tek tek bildirmek yerine bunları geliştiricilere birlikte bildirmeye çalışın çünkü bir grup üzerinde çalışması kolay olacaktır.

# 8) Genel bir gereksiniminiz varsa Performans testi veya Stres veya Yük Testi, ardından bunun için uygun bir otomasyon çerçevesine sahip olduğunuzdan emin olun. Çünkü bunları bir akıl sağlığı testi ile manuel olarak test etmek neredeyse imkansızdır.

# 9) Bu, akıl sağlığı testi stratejinizin en önemli kısmı ve aslında son adımıdır - 'Yayın e-postasını veya belgeyi taslak haline getirdiğinizde, yürüttüğünüz tüm test senaryolarını, bir durum işaretiyle bulunan hataları ve herhangi bir şey kalmışsa belirtin denenmemiş sebeplerle bahset ' Testiniz hakkında herkese neyin test edildiğini, neyin doğrulandığını ve neyin yapılmadığını aktaracak net bir hikaye yazmaya çalışın.

Bu testi kullanırken bunu dini olarak takip ettim.

Kendi deneyimlerimi paylaşmama izin verin:

# 1) Bir web sitesi üzerinde çalışıyorduk ve o, reklamları anahtar kelimelere göre açıyordu. Reklamverenler, aynı şekilde tasarlanmış bir ekrana sahip olan belirli anahtar kelimeler için teklif verirlerdi. Eskiden varsayılan teklif değeri, teklif verenin bile değiştirebileceği 0,25 ABD doları olarak gösteriliyordu.

Bu varsayılan teklifin göründüğü bir yer daha vardı ve başka bir değerle de değiştirilebilirdi. Müşteri, varsayılan değeri 0,25 ABD dolarından 0,5 ABD dolarına değiştirme talebiyle geldi, ancak yalnızca açık ekrandan bahsetti.

Beyin fırtınası tartışmamız sırasında, bu amaç için fazla kullanılmadığı için bu diğer ekranı unuttuk (?). Ancak teklifin temel durumunu 0,5 dolar olarak çalıştırdığımda ve uçtan uca kontrol ettiğimde, aynı cronjob'un başarısız olduğunu, çünkü bir yerde 0,25 doları bulduğunu gördüm.

Bunu ekibime bildirdim ve değişikliği yaptık ve aynı gün başarılı bir şekilde teslim ettik.

#iki) Aynı proje kapsamında (yukarıda bahsedilmiştir), ihale için notlar / yorumlar için küçük bir metin alanı eklememiz istendi. Çok basit bir uygulamaydı ve aynı gün teslim etmeyi taahhüt ettik.

Bu nedenle, yukarıda bahsedildiği gibi, tüm iş kurallarını ve etrafındaki kullanım durumlarını test ettim ve bazı doğrulama testleri yaptığımda, bir özel karakter kombinasyonu girdiğimde sayfanın çöktüğünü gördüm.

Bunun üzerinde düşündük ve gerçek teklif verenlerin hiçbir durumda bu tür kombinasyonları kullanmayacağını anladık. Bu nedenle, konu hakkında iyi hazırlanmış bir notla yayınladık. Müşteri bunu bir hata olarak kabul etti, ancak daha sonra uygulamaya koymamız için bizimle anlaştı çünkü bu ciddi bir hataydı ama öncekinden değildi.

# 3) Son zamanlarda bir mobil uygulama projesi üzerinde çalışıyordum ve uygulamada gösterilen teslimat zamanını saat dilimine göre güncellememiz gerekiyordu. Sadece uygulamada değil, aynı zamanda web hizmeti için de test edilecek.

Geliştirme ekibi uygulama üzerinde çalışırken, web hizmeti testi için otomasyon betikleri ve teslimat öğesinin saat dilimini değiştirmek için DB betikleri oluşturdum. Bu çabalarımı kurtardı ve kısa sürede daha iyi sonuçlar elde edebildik.

Sanity Testing Vs Regresyon Testi

Aşağıda, ikisi arasındaki birkaç fark verilmiştir:

Mobil Uygulama Testi Stratejisi

Neden burada özellikle mobil uygulamalardan bahsettiğimi merak ediyor olmalısınız?

Bunun nedeni, web veya masaüstü uygulamaları için işletim sistemi ve tarayıcı sürümünün çok fazla değişmemesi ve özellikle ekran boyutlarının standart olmasıdır. Ancak mobil uygulamalarda ekran boyutu, mobil ağ, işletim sistemi sürümleri vb. Mobil uygulamanızın kararlılığını, görünümünü ve kısacası başarısını etkiler.

Dolayısıyla, bu testi bir mobil uygulamada gerçekleştirirken bir strateji formülasyonu kritik hale gelir, çünkü bir başarısızlık başınızı büyük belaya sokabilir. Testler de akıllıca ve dikkatli yapılmalıdır.

Aşağıda, bu testi bir 'mobil uygulamada' başarılı bir şekilde gerçekleştirmenize yardımcı olacak bazı ipuçları verilmiştir:

# 1) Öncelikle, ekibinizle birlikte işletim sistemi sürümünün uygulama üzerindeki etkisini analiz edin.

Davranış sürümler arasında farklı olacak mı gibi sorulara yanıt bulmaya çalışın. Uygulama desteklenen en düşük sürümde çalışacak mı yoksa çalışmayacak mı? Sürümlerin uygulanmasında performans sorunları olacak mı? İşletim sisteminin, uygulamanın davranışını etkileyebilecek belirli bir özelliği var mı? vb.

#iki) Yukarıdaki notta, telefon modellerini de analiz edin, yani telefonun uygulamayı etkileyecek herhangi bir özelliği var mı? GPS ile davranış değişikliği uygulaması mı? Uygulama davranışı telefonun kamerasıyla değişiyor mu? vb. Etkinin olmadığını fark ederseniz, farklı telefon modellerinde test etmekten kaçının.

# 3) Uygulama için herhangi bir UI değişikliği olmadıkça, UI testini en düşük öncelikte tutmanızı tavsiye ederim, ekibe (isterseniz) UI'nin test edilmeyeceğini bildirebilirsiniz.

# 4) Zamandan tasarruf etmek için iyi ağlarda test yapmaktan kaçının çünkü uygulamanın güçlü bir ağda beklendiği gibi çalışacağı açıktır. Bir 4G veya 3G ağında test etmeye başlamanızı tavsiye ederim.

# 5) Bu test daha kısa sürede yapılacaktır, ancak yalnızca bir kullanıcı arayüzü değişikliği olmadığı sürece en az bir saha testi yaptığınızdan emin olun.

# 6) Farklı bir işletim sistemi matrisini ve sürümlerini test etmeniz gerekiyorsa, bunu akıllıca yapmanızı öneririm. Örneğin, test için en düşük, orta ve en son işletim sistemi sürümü çiftlerini seçin. Sürüm belgesinde her kombinasyonun test edilmediğinden bahsedebilirsiniz.

# 7) Benzer bir hatta, UI uygulama mantığı testi için zamandan kazanmak için küçük, orta ve büyük ekran boyutlarını kullanın. Ayrıca bir simülatör ve emülatör de kullanabilirsiniz.

İhtiyati önlemler

Sanity Testing, zamanınız az olduğunda gerçekleştirilir ve bu nedenle, her bir test senaryosunu çalıştırmanız mümkün değildir ve en önemlisi, testinizi planlamak için yeterli zaman verilmez. Suçlama oyunlarından kaçınmak için ihtiyati tedbirler almak daha iyidir.

Bu gibi durumlarda yazılı iletişim eksikliği, test belgeleri ve eksiklikler oldukça yaygındır.

Bunun kurbanı olmadığınızdan emin olmak için şunlardan emin olun:

• Müşteri tarafından paylaşılan yazılı bir gereksinim size verilmedikçe test için asla bir yapıyı kabul etmeyin. Müşterilerin değişiklikleri veya yeni uygulamaları sözlü olarak veya sohbette veya bir e-postada basit bir 1 satırda ilettikleri ve bunu bir gereklilik olarak ele almamızı bekledikleri görülür. Müşterinizi bazı temel işlevsellik noktaları ve kabul kriterleri sağlamaya ikna edin.
• Düzgün bir şekilde yazmak için yeterli zamanınız yoksa, her zaman test senaryolarınız ve hatalarınız hakkında kaba notlar alın. Bunları asla belgesiz bırakmayın. Zamanınız varsa, liderinizle veya ekibinizle paylaşın, böylece eksik bir şey varsa kolayca belirtebilirler.
• Siz ve ekibiniz zamanınız kısaysa, hataların bir e-postada uygun durumda işaretlendiğinden emin olun. Ekibe hataların tam listesini e-postayla gönderebilir ve geliştiricilerin bunları uygun şekilde işaretlemesini sağlayabilirsiniz. Topu daima diğerinin sahasında tutun.
• Eğer varsa Otomasyon Çerçevesi hazır, kullan ve yapmaktan kaçının Manuel Test , bu şekilde daha kısa sürede daha fazlasını kapsayabilirsiniz.
• Teslim edebileceğinizden% 100 emin değilseniz, '1 saat içinde yayın' senaryosundan kaçının.
• Son olarak, yukarıda bahsedildiği gibi, neyin test edildiğini, neyin dışarıda bırakıldığını, nedenlerini, risklerini, hangi hataların çözüldüğünü, 'Daha sonra' nelerin alındığını bildiren ayrıntılı bir e-posta taslağı hazırlayın.

Bir QA olarak, uygulamanın test edilmesi gereken en önemli kısmının ne olduğuna ve dışarıda bırakılabilecek veya temel teste tabi tutulabilecek kısımların neler olduğuna karar vermelisiniz.

Kısa bir süre içinde bile, nasıl yapmak istediğinize dair bir strateji planlayın ve verilen zaman çerçevesinde en iyisini başarabileceksiniz.

Duman Testi

Duman Testi kapsamlı bir test değildir, ancak söz konusu yapının temel işlevlerinin beklendiği gibi iyi çalışıp çalışmadığını doğrulamak için yürütülen bir testler grubudur. Bu, herhangi bir 'yeni' yapıda yapılacak ilk testtir ve her zaman olmalıdır.

Geliştirme ekibi test için KG'ye bir yapı yayınladığında, tüm yapıyı test etmek ve uygulamalardan herhangi birinde hata olup olmadığını veya çalışma işlevlerinden herhangi birinin bozuk olup olmadığını hemen doğrulamak açıkça mümkün değildir.

Bunun ışığında, bir QA, temel işlevlerin düzgün çalıştığından nasıl emin olacaktır?

Bunun cevabı bir Duman Testi .

Testler Duman testleri (test paketinde) olarak işaretlendikten sonra, ancak o zaman yapı, derinlemesine test ve / veya regresyon için QA tarafından kabul edilir. Duman testlerinden herhangi biri başarısız olursa, yapı reddedilir ve geliştirme ekibinin sorunu düzeltmesi ve test için yeni bir yapı yayınlaması gerekir.

Teorik olarak, Duman testi, geliştirme ekibi tarafından QA ekibine sağlanan yapının daha ileri testler için hazır olduğunu doğrulamak için yüzey seviyesinde test olarak tanımlanır. Bu test, derlemeyi QA ekibine yayınlamadan önce geliştirme ekibi tarafından da gerçekleştirilir.

Bu test normalde Entegrasyon Testi, Sistem Testi ve Kabul Seviyesi Testinde kullanılır. Bunu asla tamamlanmış testi sonlandırmak için gerçek uçtan uca ikame olarak kullanmayın. . Yapı uygulamasına bağlı olarak hem pozitif hem de negatif testlerden oluşur.

Duman Testi Örnekleri

Bu test normalde Entegrasyon, Kabul ve Sistem Testi .

büyük veri analizi araçları açık kaynak

Kariyerimde QA olarak, her zaman bir yapıyı ancak bir duman testi yaptıktan sonra kabul ettim. Öyleyse, duman testinin ne olduğunu bazı örneklerle bu üç testin perspektifinden anlayalım.

# 1) Kabul Testi

Bir yapı QA'ya bırakıldığında, bir yapı şeklinde duman testi Kabul testleri yapılmalı.

Bu testte ilk ve en önemli duman testi, uygulamanın temel beklenen işlevselliğini doğrulamaktır. Bunun gibi, söz konusu derleme için tüm uygulamaları doğrulamalısınız.

Bunlar için duman testlerini anlamak için bir yapıda yapılan uygulamalar olarak aşağıdaki Örnekleri alalım:

• Kayıtlı sürücülerin başarıyla oturum açmasına izin vermek için oturum açma işlevi uygulandı.
• Bir sürücünün bugün yürüteceği rotaları göstermek için gösterge panosu işlevselliği uygulandı.
• Belirli bir gün için hiçbir rota yoksa uygun bir mesaj gösterme işlevi uygulandı.

Yukarıdaki yapıda, kabul düzeyinde, duman testi, temel üç uygulamanın iyi çalıştığını doğrulamak anlamına gelecektir. Bu üçünden herhangi biri bozulursa, QA yapıyı reddetmelidir.

# 2) Entegrasyon Testi

Bu test genellikle tek tek modüller uygulandığında ve test edildiğinde yapılır. İçinde Entegrasyon Testi düzeyinde, bu test, tüm temel entegrasyonun ve uçtan uca işlevlerin beklendiği gibi iyi çalıştığından emin olmak için gerçekleştirilir.

İki modülün veya tüm modüllerin birlikte entegrasyonu olabilir, bu nedenle duman testinin karmaşıklığı entegrasyon seviyesine bağlı olarak değişecektir.

Bu test için aşağıdaki entegrasyon uygulama örneklerini ele alalım:

• Rota ve durdurma modüllerinin entegrasyonunu gerçekleştirdi.
• Varış durumu güncellemesinin entegrasyonunu uyguladı ve aynı şeyi duraklar ekranında yansıtıyordu.
• Teslimat işlevselliği modüllerine kadar tam teslim alma entegrasyonu uygulandı.

Bu yapıda, duman testi yalnızca bu üç temel uygulamayı doğrulamakla kalmayacak, üçüncü uygulama için birkaç durum da tam entegrasyon için doğrulanacaktır. Entegrasyonda ortaya çıkan ve geliştirme ekibi tarafından fark edilmeyen sorunları bulmak çok yardımcı olur.

# 3) Sistem Testi

Adından da anlaşılacağı gibi, sistem seviyesi için duman testi, sistemin en önemli ve yaygın olarak kullanılan iş akışlarına yönelik testleri içerir. Bu, yalnızca tüm sistem hazır olduktan ve test edildikten sonra yapılır ve sistem düzeyindeki bu test, regresyon testinden önce duman testi olarak da adlandırılabilir.

Tüm sistemin regresyonuna başlamadan önce, duman testinin bir parçası olarak temel uçtan uca özellikler test edilir. Tüm sistem için duman test paketi, son kullanıcıların çok sık kullanacağı uçtan uca test durumlarından oluşur.

Bu genellikle otomasyon araçları yardımıyla yapılır.

SCRUM Metodolojisindeki Önemi

Günümüzde projeler, proje uygulamasında Waterfall metodolojisini neredeyse hiç takip etmiyor, çoğunlukla tüm projeler Agile'yi takip ediyor ve SCRUM sadece. Geleneksel şelale yöntemiyle karşılaştırıldığında, Duman Testi, SCRUM ve Çevik'te yüksek saygılara sahiptir.

SCRUM'da 4 yıl çalıştım . Ve SCRUM'da sprintlerin daha kısa sürdüğünü bildiğimiz için, bu testi yapmak son derece önemlidir, böylece başarısız yapılar hemen geliştirme ekibine bildirilebilir ve aynı zamanda düzeltilebilir.

Aşağıdakilerden bazıları paket servisi SCRUM'da bu testin önemi hakkında:

• İki haftalık sprint dışında, devre süresi QA'ya tahsis edilir, ancak bazen QA için yapılan derlemeler ertelenir.
• Sprintlerde, sorunların erken bir aşamada bildirilmesi ekip için en iyisidir.
• Her hikayenin bir dizi kabul kriteri vardır, bu nedenle ilk 2-3 kabul kriterinin test edilmesi, bu işlevselliğin duman testine eşittir. Müşteriler tek bir kriterin başarısız olması durumunda teslimatı reddeder.
• Geliştirme ekibinin yapıyı size teslim ettiği 2 gün ve demo için yalnızca 3 gün kaldıysa ve temel bir işlevsellik hatasıyla karşılaşırsanız ne olacağını hayal edin.
• Ortalama olarak, bir sprint 5-10 arasında değişen hikayelere sahiptir, bu nedenle yapı verildiğinde, yapıyı teste kabul etmeden önce her hikayenin beklendiği gibi uygulandığından emin olmak önemlidir.
• Tüm sistem test edilip gerileyeceği zaman, faaliyete bir sürat atanır. Bütün sistemi test etmek için iki hafta daha az olabilir, bu nedenle regresyona başlamadan önce en temel işlevleri doğrulamak çok önemlidir.

Duman Testi Vs Yapı Kabul Testi

Duman Testi doğrudan Yapı Kabul Testi (BAT) ile ilgilidir.

BAT'da, aynı testi yapıyoruz - yapının başarısız olup olmadığını ve sistemin iyi çalışıp çalışmadığını doğrulamak için. Bazen bir derleme oluşturulduğunda bazı sorunlar ortaya çıkar ve teslim edildiğinde derleme QA için çalışmaz.

BAT'ın duman kontrolünün bir parçası olduğunu söyleyebilirim çünkü sistem arızalıysa, bir QA olarak yapıyı test için nasıl kabul edebilirsiniz? Yalnızca işlevler değil, sistemin kendisinin de QA’lar Derinlemesine Teste devam etmeden önce çalışması gerekir.

Duman Test Döngüsü

Aşağıdaki akış şeması Duman Testi Döngüsünü açıklamaktadır.

Bir yapı bir KG'ye dağıtıldıktan sonra, izlenen temel döngü, duman testi başarılı olursa, yapının daha ileri testler için KG ekibi tarafından kabul edilmesidir, ancak başarısız olursa, rapor edilen sorunlar giderilene kadar yapı reddedilir.

Test Döngüsü

Duman Testini Kim Yapmalıdır?

Tüm QA'lerin zaman israfını önlemek için tüm ekip bu tür testlere dahil değildir.

Duman Testi ideal olarak, yapının daha ileri testler için ekibe aktarılıp aktarılmayacağına veya reddedilmesine sonuca göre karar veren QA lideri tarafından gerçekleştirilir. Ya da liderin yokluğunda, KG'nin kendisi de bu testi gerçekleştirebilir.

Zaman zaman, proje büyük ölçekli olduğunda, bir grup kalite güvencesi de herhangi bir engelleyici olup olmadığını kontrol etmek için bu testi gerçekleştirebilir. Ancak SCRUM durumunda durum böyle değildir çünkü SCRUM, Liderleri veya Yöneticileri olmayan düz bir yapıdır ve her test uzmanının hikayelerine karşı kendi sorumlulukları vardır.

Dolayısıyla, bireysel QA'lar, sahip oldukları hikayeler için bu testi gerçekleştirir.

Duman Testlerini Neden Otomatikleştirmeliyiz?

Bu test, geliştirme ekibi (ler) tarafından yayınlanan bir yapıda yapılacak ilk testtir. Bu testin sonuçlarına göre, daha fazla test yapılır (veya yapı reddedilir).

Bu testi yapmanın en iyi yolu, bir otomasyon aracı kullanmak ve duman süitini yeni bir yapı oluşturulduğunda çalışacak şekilde programlamaktır. Belki neden yapayım diye düşünüyor olabilirsin 'Duman test takımını otomatikleştirmek' mi?

Şu duruma bakalım:

Diyelim ki tahliyenize bir hafta uzaktasınız ve toplam 500 test vakası içinde duman testi süitiniz 80-90 kişiden oluşuyor. Tüm bu 80-90 test senaryosunu manuel olarak yürütmeye başlarsanız, ne kadar zaman alacağınızı bir düşünün. Sanırım 4-5 gün (minimum).

Ancak otomasyon kullanır ve tüm bu 80-90 test senaryosunu çalıştırmak için komut dosyaları oluşturursanız, ideal olarak bunlar 2-3 saat içinde çalıştırılır ve sonuçları anında yanınızda alırsınız. Değerli zamanınızdan tasarruf etmedi mi ve kurulumla ilgili sonuçları size çok daha kısa sürede vermedi mi?

5 yıl önce, maaşınız, birikimleriniz vb. Hakkında girdiler alan ve mali kurallara bağlı olarak vergilerinizi, tasarruflarınızı, karlarınızı tahmin eden bir finansal projeksiyon uygulamasını test ediyordum. Bununla birlikte, ülkeye ve değişmek için kullanılan vergi kurallarına (kodda) bağlı olan ülkeler için özelleştirme yaptık.

Bu proje için 800 test vakam vardı ve 250'si duman testi vakasıydı. Selenium kullanımı ile bu 250 test vakasının sonuçlarını 3-4 saatte kolayca otomatik hale getirip sonuçlarını alabildik. Sadece zamanımızı kurtarmakla kalmadı, bize gösterileri en kısa sürede gösterdi.

Bu nedenle, otomatikleştirmek imkansız olmadığı sürece, bu test için otomasyondan yardım alın.

Avantajlar ve dezavantajlar

Birkaç dezavantajı ile karşılaştırıldığında sunabileceği çok şey olduğu için önce avantajlara bir göz atalım.

Avantajlar:

• Gerçekleştirmesi kolay.
• Riski azaltır.
• Kusurlar çok erken bir aşamada belirlenir.
• Çaba, zaman ve paradan tasarruf sağlar.
• Otomatikleştirilmişse hızlı çalışır.
• En az entegrasyon riskleri ve sorunları.
• Sistemin genel kalitesini iyileştirir.

Dezavantajları:

• Bu test, tam fonksiyonel teste eşit veya onun yerini tutmaz.
• Duman testi geçtikten sonra bile, çarpıcı hatalar bulabilirsiniz.
• Bu tür testler en iyisidir, eğer otomatikleştirebilirseniz, özellikle 700-800 civarında test senaryosu olan büyük ölçekli projelerde test senaryolarının manuel olarak yürütülmesi için çok fazla zaman harcanırsa.

Duman Testi kesinlikle her yapıda yapılmalıdır, çünkü çok erken bir aşamada büyük arızalara ve göstericilere işaret eder. Bu sadece yeni işlevler için değil, aynı zamanda modüllerin entegrasyonu, sorunların giderilmesi ve doğaçlama için de geçerlidir. Gerçekleştirmek ve doğru sonucu almak çok basit bir işlemdir.

Bu test, işlevselliğin veya sistemin (bir bütün olarak) eksiksiz İşlevsel Testi için giriş noktası olarak değerlendirilebilir. Ama ondan önce, QA ekibi, duman testleri olarak hangi testlerin yapılacağı konusunda çok net olmalıdır . Bu test, çabaları en aza indirebilir, zamandan tasarruf sağlayabilir ve sistemin kalitesini artırabilir. Sprintlerdeki süre daha az olduğu için sprintlerde çok önemli bir yer tutar.

Bu test hem manuel olarak hem de otomasyon araçları yardımıyla yapılabilir. Ancak en iyi ve tercih edilen yol, zaman kazanmak için otomasyon araçlarını kullanmaktır.

Duman ve Akıl Testi Arasındaki Fark

Çoğu zaman Sanity Testing ve Smoke Testing'in anlamı arasında kafamız karışır. Her şeyden önce, bu iki test yol ' farklı ”Ve bir test döngüsünün farklı aşamalarında gerçekleştirilir.

Aşağıda, farklılıklarının şematik bir gösterimi verilmiştir:

DUMAN TESTİ

• Bu test, donanım yeni bir donanım parçasını ilk kez açma ve ateş ve duman tutmazsa başarılı olacağını düşünme uygulaması. Yazılım endüstrisinde bu test, uygulamanın tüm alanlarının çok derine inmeden test edildiği sığ ve geniş bir yaklaşımdır.
• Bir duman testi, yazılı bir test seti veya otomatik bir test kullanılarak oluşturulur.
• Bir Duman testi, uygulamanın her bölümüne üstünkörü bir şekilde dokunmak için tasarlanmıştır. Sığ ve geniştir.
• Bu test, bir programın en önemli işlevlerinin çalışıp çalışmadığını, ancak daha ince ayrıntılarla uğraşmadığından emin olmak için yapılır. (Yapı doğrulama gibi).
• Bu test, derinlemesine test etmeye başlamadan önce bir uygulamanın derlenmesinde yapılan normal bir sağlık kontrolüdür.

SAĞLIK TESTİ

• Akıl sağlığı testi, işlevselliğin bir veya birkaç alanına odaklanan dar bir regresyon testidir. Akıl Testi genellikle dar ve derindir.
• Bu test genellikle önceden yazılmamıştır.
• Bu test, küçük bir değişiklikten sonra uygulamanın küçük bir bölümünün hala çalıştığını belirlemek için kullanılır.
• Bu test, üstünkörü bir testtir, uygulamanın spesifikasyonlara göre çalıştığını kanıtlamak için üstünkörü bir testin yeterli olduğu her durumda gerçekleştirilir. Bu test seviyesi, regresyon testinin bir alt kümesidir.
• Bu, gereksinimlerin karşılanıp karşılanmadığını doğrulamak ve tüm özelliklerin genişliğini önce kontrol etmek içindir.

Bu iki geniş ve önemli Yazılım Testi türü arasındaki farklar konusunda net olduğunuzu umuyoruz. Aşağıdaki yorumlar bölümünde düşüncelerinizi paylaşmaktan çekinmeyin !!

Önerilen Kaynaklar

• En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
• Masaüstü, İstemci Sunucu Testi ve Web Testi arasındaki fark
• Fonksiyonel Test ve Fonksiyonel Olmayan Test
• Primer e-Kitap İndirmeyi Test Etme
• Alfa Testi ve Beta Testi (Tam Kılavuz)
• Pratik Örneklerle Taşınabilirlik Testi Kılavuzu
• Yazılım Testi Türleri: Ayrıntılarla Birlikte Farklı Test Türleri
• Fonksiyonel Test ve Performans Testi: Aynı Anda Yapılmalı mı?