Çevik Test nedir?
AGILE TESTING , çevik yazılım geliştirmenin kural ve ilkelerini takip eden bir test uygulamasıdır. Şelale yönteminin aksine Çevik Test, geliştirme ve test etme arasında sürekli entegrasyonla projenin başlangıcında başlayabilir. Çevik Test metodolojisi sıralı değil (sadece kodlama aşamasından sonra yürütülmesi anlamında), süreklidir.
Bu yazıda tartışacağız
- Çevik Test Planı.
- Çevik Test Stratejileri.
- Çevik Test Çeyreği.
- Çevik yazılım geliştirme ile QA zorlukları.
- Çevik Süreçte Otomasyon Riski.
Çevik Test Planı
Çevik test planı , test verileri gereksinimleri, altyapı, test ortamları ve test sonuçları gibi bu yinelemede yapılan test türlerini içerir. Şelale modelinden farklı olarak, çevik bir modelde, her sürüm için bir test planı yazılır ve güncellenir. Agile'daki tipik test planları şunları içerir:
- Test Kapsamı
- Test edilen yeni işlevler
- Özellik karmaşıklığına göre test seviyesi veya türleri
- Yük ve Performans Testi
- Altyapı Değerlendirmesi
- Etki Azaltma veya Risk Planı
- Kaynak bulma
- Çıktılar ve Dönüm Noktaları
Çevik Test Stratejileri
Çevik test yaşam döngüsü dört aşamadan oluşur
(a) Yineleme 0
İlk aşama veya yineleme 0 sırasında, ilk kurulum görevlerini gerçekleştirirsiniz. Test için kişilerin tanımlanmasını, test araçlarının kurulmasını, kaynakların planlanmasını (kullanılabilirlik testi laboratuvarı) vb. İçerir. Aşağıdaki adımlar, Yineleme 0'da gerçekleştirilecek şekilde ayarlanmıştır.
a) Proje için bir iş vakası oluşturmak
b) Sınır koşullarını ve proje kapsamını belirleyin
c) Tasarım değiş tokuşlarını yönlendirecek temel gereksinimleri ve kullanım durumlarını ana hatlarıyla belirtin
d) Bir veya daha fazla aday mimarinin ana hatlarını çizin
e) Riskin belirlenmesi
f) Maliyet tahmini ve bir ön proje hazırlama
(b) İnşaat Yinelemeleri
Çevik test metodolojisinin ikinci aşaması İnşaat Yinelemeleridir, testlerin çoğu bu aşamada gerçekleşir. Bu aşama, çözümün bir artışını oluşturmak için bir dizi yineleme olarak gözlemlenir. Bunu yapmak için, her bir yinelemede ekip , XP, Scrum, Çevik modelleme ve çevik verilerden oluşan bir karma uygulama uygular .
Yapım yinelemesinde, Agile ekibi öncelikli gereksinim uygulamasını izler: Her yinelemede, iş öğesi yığınından kalan en temel gereksinimleri alır ve bunları uygular.
İnşaat tekrarı ikiye ayrılır: doğrulayıcı testler ve araştırma amaçlı testler. Doğrulayıcı test , sistemin bugüne kadar ekibe açıklanan paydaşların niyetini yerine getirdiğini ve ekip tarafından yapıldığını doğrulamaya odaklanır . Araştırma testi, doğrulama ekibinin atladığı veya görmezden geldiği sorunu tespit ederken. Araştırmacı testte, test uzmanı olası sorunları hata hikayeleri şeklinde belirler. Araştırma testi, entegrasyon testi, yük / stres testi ve güvenlik testi gibi yaygın sorunları ele alır.
Yine, doğrulayıcı test için geliştirici testi ve çevik kabul testinin iki yönü vardır . Her ikisi de yaşam döngüsü boyunca sürekli regresyon testini mümkün kılmak için otomatikleştirilmiştir. Doğrulayıcı test, spesifikasyona yönelik testin çevik eşdeğeridir.
Çevik kabul testi, geliştirme ekibi olarak geleneksel fonksiyonel test ile geleneksel kabul testinin bir kombinasyonudur ve paydaşlar bunu birlikte yapıyor. Geliştirici testi, geleneksel birim testi ile geleneksel hizmet entegrasyonu testinin bir karışımıdır. Geliştirici testi, hem uygulama kodunu hem de veritabanı şemasını doğrular.
(c) Yayın Sonu Oyunu veya Geçiş Aşaması
"Serbest Bırak, Oyunu Sonlandır" ın amacı, sisteminizi başarılı bir şekilde üretime yerleştirmektir. Bu aşamadaki faaliyetler, son kullanıcıların, destek personelinin ve operasyonel kişilerin eğitimini içerir. Ayrıca, ürün sürümünün pazarlanmasını, yedeklemeyi ve geri yüklemeyi, sistemin sonuçlandırılmasını ve kullanıcı belgelerini içerir.
Son çevik metodoloji test aşaması, tam sistem testi ve kabul testini içerir. Son test aşamanızı herhangi bir engelle karşılaşmadan bitirebilmeniz için ürünü inşaat yinelemelerinde daha titiz bir şekilde test etmeniz gerekir. Oyun sonu sırasında, test uzmanları kusur hikayeleri üzerinde çalışacaklar.
(d) Üretim
Serbest bırakma aşamasından sonra ürün üretim aşamasına geçecektir.
Çevik Test Çeyrekleri
Çevik test kadranları, tüm süreci dört Çeyreğe ayırır ve çevik testin nasıl yapıldığını anlamaya yardımcı olur.
a) Çevik Çeyrek I - Dahili kod kalitesi, bu kadrandaki ana odak noktasıdır ve teknoloji odaklı ve ekibi desteklemek için uygulanan test durumlarından oluşur.
1. Birim Testleri
2. Bileşen Testleri
b) Agile Quadrant II - İş odaklı olan ve ekibi desteklemek için uygulanan test senaryolarını içerir . Bu Çeyrek gereksinimlere odaklanır. Bu aşamada gerçekleştirilen test türü
1. Olası senaryoların ve iş akışlarının örneklerini test etme
2. Prototipler gibi Kullanıcı deneyiminin test edilmesi
3. Çift testi
c) Çevik Çeyrek III - Bu kadran, birinci ve ikinci kadranlara geri bildirim sağlar. Test senaryoları, otomasyon testi yapmak için temel olarak kullanılabilir. Bu çeyrekte, ürüne güven oluşturan birçok yineleme incelemesi yapılır. Bu çeyrekte yapılan test türü
1. Kullanılabilirlik Testi
2. Keşif Testi
3. Testi müşterilerle eşleştirin
4. İşbirliğine dayalı test
5. Kullanıcı kabul testi
d) Çevik Çeyrek IV - Bu kadran , performans, güvenlik, kararlılık vb. gibi işlevsel olmayan gereksinimlere odaklanır . Bu kadranın yardımıyla, uygulama işlevsel olmayan nitelikleri ve beklenen değeri sağlamak için yapılır.
1. Stres ve performans testi gibi işlevsel olmayan testler
2. Kimlik doğrulama ve bilgisayar korsanlığı ile ilgili güvenlik testi
3. Altyapı testi
4. Veri taşıma testi
5. Ölçeklenebilirlik testi
6. Yük testi
Çevik yazılım geliştirme ile kalite güvencesi sorunları
a) Belgelere daha az öncelik verildiği için hata şansı daha çeviktir ve sonuç olarak kalite güvence ekibi üzerinde daha fazla baskı oluşturur
b) Yeni özellikler hızlı bir şekilde sunulur, bu da test ekiplerinin en son özelliklerin gereksinime uygun olup olmadığını belirlemesi için gereken süreyi azaltır ve iş takımlarına gerçekten hitap ediyor mu
c) Testçilerin genellikle yarı geliştirici rol oynamaları istenir
d) Test yürütme döngüleri oldukça sıkıştırılmıştır
e) Test planı hazırlamak için çok daha az zaman
f) Regresyon testi için minimum zamanlamaya sahip olacaklar
g) Kalitenin bekçisi olmaktan Kalitede ortak olmaya rollerinde değişiklik
h) Gereksinim değişiklikleri ve güncellemeleri, çevik bir yöntemin doğasında vardır ve kalite güvencesi için en büyük zorluk haline gelir
Çevik Süreçte Otomasyon Riski
- Otomatik UI, yüksek düzeyde güven sağlar, ancak yürütmesi yavaştır, bakımı kırılgandır ve yapımı pahalıdır. Test uzmanları nasıl test yapacaklarını bilmedikçe, otomasyon test üretkenliğini önemli ölçüde artırmayabilir
- Güvenilir olmayan testler, otomatik testlerde önemli bir sorundur. Hatalı pozitifleri önlemek için başarısız testleri düzeltmek ve hassas testlerle ilgili sorunları çözmek en önemli öncelik olmalıdır.
- Otomatik test, CI (Sürekli Entegrasyon) yerine manuel olarak başlatılırsa, düzenli olarak çalışmama riski vardır ve bu nedenle testlerin başarısız olmasına neden olabilir.
- Otomatik testler, keşif amaçlı manuel testlerin yerini almaz. Ürünün beklenen kalitesini elde etmek için, test türleri ve seviyelerinin bir karışımı gereklidir.
- Piyasada bulunan birçok otomasyon aracı, manuel test senaryolarının yakalanması ve yeniden oynatılması gibi basit özellikler sağlar. Bu tür bir araç, kullanıcı arayüzü aracılığıyla testi teşvik eder ve doğası gereği kırılgan ve bakımı zor testlere yol açar. Ayrıca, test senaryolarının sürüm kontrol sistemi dışında depolanması gereksiz karmaşıklık yaratır
- Zaman kazanmak için, otomasyon test planının çoğu zaman kötü planlanmış veya planlanmamış olması testin başarısız olmasına neden olur
- Test otomasyonu sırasında bir test kurulumu ve sökme prosedürleri genellikle gözden kaçırılırken, manuel test yapılırken, bir test kurulumu ve yırtma prosedürleri sorunsuz geliyor
- Her gün oluşturulan veya yürütülen bir dizi test senaryosu gibi üretkenlik ölçütleri son derece yanıltıcı olabilir ve gereksiz testler yürütmek için büyük bir yatırım yapılmasına neden olabilir.
- Çevik otomasyon ekibinin üyeleri etkili danışmanlar olmalıdır: yaklaşılabilir, işbirlikçi ve becerikli, yoksa bu sistem hızla başarısız olur
- Otomasyon, sağlanan değere göre çok fazla sürekli bakım gerektiren test çözümleri önerebilir ve sunabilir
- Otomatik testler, etkili çözümler tasarlama ve sunma uzmanlığından yoksun olabilir
- Otomatik testler o kadar başarılı olabilir ki, çözülmesi gereken önemli sorunları ortadan kaldırır ve bu nedenle önemsiz sorunlara dönüşür.
Sonuç
Yazılım testinde çevik metodoloji, yazılım geliştirme yaşam döngüsünde olabildiğince erken test yapılmasını içerir. Kullanıma sunulur sunulmaz yüksek müşteri katılımı ve test kodu gerektirir. Kod, onu sistem testine götürmek için yeterince kararlı olmalıdır. Hataların düzeltildiğinden ve test edildiğinden emin olmak için kapsamlı regresyon testi yapılabilir. Temel olarak, ekipler arasındaki iletişim, Agile model testini başarılı kılar !!!