Çevik Test - Hızlı Kılavuz

Agilehem geliştirme hem de test faaliyetlerinin eşzamanlı olduğu yinelemeli bir geliştirme metodolojisidir. Test ayrı bir aşama değildir; Kodlama ve Test etkileşimli ve aşamalı olarak yapılır ve müşteri gereksinimlerini karşılayan kaliteli son ürün elde edilir. Dahası, sürekli entegrasyon, kusurların erken giderilmesi ve dolayısıyla zaman, çaba ve maliyet tasarrufu sağlar.

Çevik Manifesto

Çevik Manifesto, 2001 yılında bir yazılım geliştiricileri ekibi tarafından yayınlandı ve geliştirme ekibinin önemini vurgulayarak, değişen gereksinimleri ve müşteri katılımını barındırdı.

The Agile Manifesto is −

Bunu yaparak ve başkalarının yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz. Bu çalışma sayesinde, değer kazandık -

Süreçler ve araçlardan ziyade bireyler ve etkileşimler.
Kapsamlı dokümantasyon yerine çalışan yazılım.
Sözleşme pazarlığı yerine müşteri işbirliği.
Bir planı takip etmek yerine değişime yanıt vermek.

Yani sağdaki öğelerde değer varken soldaki öğelere daha çok değer veriyoruz.

Çevik Test nedir?

Çevik Test, çevik yazılım geliştirme ilkelerini takip eden bir yazılım test uygulamasıdır.

Çevik Test, test uzmanlarının katkıda bulunduğu özel uzmanlığa sahip proje ekibinin tüm üyelerini kapsar. Test, ayrı bir aşama değildir ve gereksinimler, tasarım ve kodlama ve test senaryosu oluşturma gibi tüm geliştirme aşamalarıyla iç içe geçmiştir. Geliştirme Yaşam Döngüsü boyunca test aynı anda gerçekleşir.

Dahası, test uzmanlarının işlevler arası ekip üyeleriyle birlikte tüm Geliştirme Yaşam Döngüsüne katılmasıyla, test uzmanlarının yazılımı müşteri gereksinimlerine göre, daha iyi tasarım ve kodla oluşturmaya katkısı mümkün olacaktır.

Çevik Test, tüm test seviyelerini ve her tür testi kapsar.

Çevik Test Vs. Şelale Testi

Bir Şelale Geliştirme metodolojisinde, Geliştirme Yaşam Döngüsü etkinlikleri sıralı aşamalar halinde gerçekleşir. Bu nedenle test, ayrı bir aşamadır ve ancak geliştirme aşaması tamamlandıktan sonra başlatılır.

Çevik Test ve Şelale Testi arasındaki farkların önemli noktaları aşağıdadır -

Çevik Test	Şelale Testi
Test, ayrı bir aşama değildir ve geliştirme ile eşzamanlı olarak gerçekleşir.	Test ayrı bir aşamadır. Tüm seviyeler ve türlerdeki testler ancak geliştirme tamamlandıktan sonra başlayabilir.
Test uzmanları ve geliştiriciler birlikte çalışır.	Test uzmanları, geliştiricilerden ayrı çalışır.
Test uzmanları, gereksinimleri belirlemeye dahil olur. Bu, gerçek dünya senaryosundaki davranışların gereksinimlerini eşleştirmeye ve ayrıca kabul kriterlerini çerçevelemeye yardımcı olur. Ayrıca, mantıksal Kabul Testi Durumları gerekliliklerle birlikte hazır olacaktır.	Test uzmanları, gereksinimler aşamasına dahil olamaz.
Kabul Testi her yinelemeden sonra yapılır ve müşteri geri bildirimi alınır.	Kabul Testi sadece proje sonunda yapılır.
Her yineleme kendi testini tamamlar, böylece her yeni işlev veya mantık piyasaya sürüldüğünde regresyon testinin uygulanmasına izin verir.	Regresyon Testi ancak geliştirme tamamlandıktan sonra uygulanabilir.
Kodlama ve test arasında zaman gecikmesi yok.	Kodlama ve test arasındaki olağan gecikme süreleri.
Çakışan test seviyeleri ile sürekli test.	Test, zamanlanmış bir faaliyettir ve test seviyeleri çakışamaz.
Test, en iyi uygulamadır.	Test genellikle gözden kaçar.

Çevik Test İlkeleri

Çevik testin ilkeleri şunlardır:

Testing moves the project forward- Sürekli test, sürekli ilerleme sağlamanın tek yoludur. Çevik Test, sürekli olarak geri bildirim sağlar ve nihai ürün iş taleplerini karşılar.
Testing is not a phase- Agile ekip, belirli bir yineleme sırasında uygulanan özelliklerin gerçekten yapıldığından emin olmak için geliştirme ekibiyle birlikte testler. Test daha sonraki bir aşama için tutulmaz.
Everyone tests- Çevik testte, analistler, geliştiriciler ve test uzmanları dahil olmak üzere tüm ekip uygulamayı test eder. Her yinelemeden sonra, müşteri bile Kullanıcı Kabul Testini gerçekleştirir.
Shortening Feedback Loops- Çevik Testte, iş ekibi her bir yineleme için ürün geliştirmeyi öğrenir. Her yinelemede yer alırlar. Sürekli geri bildirim, geri bildirim yanıt süresini kısaltır ve böylece düzeltmenin maliyeti daha azdır.
Keep the Code Clean- Aynı yinelemede ortaya çıktıkça kusurlar giderilir. Bu, geliştirmenin herhangi bir kilometre taşında temiz kod sağlar.
Lightweight Documentation - Kapsamlı test dokümantasyonu yerine, Çevik test ediciler -
- Test önermek için yeniden kullanılabilir kontrol listelerini kullanın.
- Tesadüfi ayrıntılardan ziyade testin özüne odaklanın.
- Hafif dokümantasyon stillerini / araçlarını kullanın.
- Keşif testleri için sözleşmelerde test fikirlerini yakalayın.
- Belgeleri birden çok amaç için kullanın.
Leveraging one test artifact for manual and automated tests- Aynı test komut dosyası yapısı manuel test için ve otomatik testler için girdi olarak kullanılabilir. Bu, Manuel Test Dokümantasyonu ve ardından eşdeğer bir Otomasyon Test Komut Dosyası gerekliliğini ortadan kaldırır.
“Done Done,” not just done - Agile'da bir özelliğin geliştirildikten sonra değil, geliştirme ve testten sonra yapıldığı söyleniyor.
Test-Last vs. Test Driven- Test Örnekleri gerekliliklerle birlikte yazılır. Bu nedenle geliştirme, testlerle yürütülebilir. Bu yaklaşıma Test Güdümlü Geliştirme (TDD) ve Kabul Testi Güdümlü Geliştirme (ATDD) denir. Bu, Şelale Testinin son aşaması olarak yapılan testin tersidir.

Çevik Test Faaliyetleri

Proje Düzeyindeki Çevik Test Faaliyetleri:

Sürüm Planlama (Test Planı)
- Her Yineleme için
- Bir Yineleme Sırasında Çevik Test Etkinlikleri
Gerileme testi
Sürüm Etkinlikleri (Testle İlgili)

Bir yineleme sırasında Çevik Test Faaliyetleri şunları içerir:

Yineleme planlamasına katılmak
Test açısından görevleri tahmin etme
Özellik açıklamalarını kullanarak test senaryoları yazma
Birim Testi
Entegrasyon Testi
Özellik Testi
Kusur Tespiti
Entegrasyon Testi
Kabul testleri
Testin İlerlemesine İlişkin Durum Raporlaması
Kusur Takibi

Çevik, tüm proje ekibinin tüm faaliyetlere katıldığı yinelemeli bir geliştirme metodolojisidir. Müşteri ve kendi kendini organize eden ekipler arasındaki işbirliği sayesinde, yinelemeler ilerledikçe gereksinimler de değişir. Kodlama ve Test etkileşimli ve aşamalı olarak yapıldığından, geliştirme süreci boyunca, son ürün kaliteli olur ve müşteri gereksinimlerini sağlar.

Her yineleme, entegre bir çalışan ürün artışıyla sonuçlanır ve Kullanıcı Kabul Testi için sunulur. Bu şekilde elde edilen müşteri geri bildirimi, sonraki / sonraki Yinelemeler için bir girdi olacaktır.

Sürekli Entegrasyon, Sürekli Kalite

Sürekli Entegrasyon, Çevik Geliştirme başarısının anahtarıdır. Sık sık, en azından günlük olarak, gerektiğinde bir sürüme hazır olacak şekilde entegre edin. Çevik olarak test etme, ürünün sürekli kalitesini garanti ederek, geliştirmenin tüm aşamalarının temel bir bileşeni haline gelir. Projeye dahil olan herkesten gelen sürekli geri bildirimler, ürünün kalitesine katkıda bulunur.

Agile'da iletişime büyük önem verilir ve müşteri talepleri gerektiği zaman ve zamanda alınır. Bu, müşteriye tüm girdilerin dikkate alındığı ve çalışma kalitesi ürünün geliştirme boyunca mevcut olduğu konusunda memnuniyet verir.

Çevik Metodolojiler

Çevik Geliştirmeyi destekleyen birkaç Çevik Metodoloji vardır. Çevik Metodolojiler şunları içerir:

Scrum

Scrum, takım merkezli yaklaşımı vurgulayan Çevik bir geliştirme yöntemidir. Tüm ekibin tüm proje geliştirme faaliyetlerine katılımını savunur.

XP

eXtreme Programming müşteri merkezlidir ve sürekli değişen gereksinimlere odaklanır. Sık sürümler ve müşteri geri bildirimleriyle son ürün, süreç sırasında daha net hale getirilen müşteri gereksinimlerini karşılayan kalitede olacaktır.

Kristal

Crystal; kiralama, döngüsel teslimat ve tamamlamaya dayanır.

Kiralama, bir geliştirme ekibi oluşturmayı, bir ön fizibilite analizi yapmayı, bir ilk plana ulaşmayı ve geliştirme metodolojisini içerir.
İki veya daha fazla teslimat döngüsüne sahip Döngüsel Teslimat, geliştirme aşamasına ve son entegre ürün teslimatına odaklanır.
Toparlama sırasında, kullanıcı ortamına dağıtım, dağıtım sonrası incelemeler ve yansımalar gerçekleştirilir.

FDD

Özellik Odaklı Geliştirme (FDD), özelliklerin tasarlanmasını ve oluşturulmasını içerir. FDD ile diğer Çevik Geliştirme Metodolojileri arasındaki fark, özelliklerin belirli ve kısa aşamalarda ayrı ayrı geliştirilmesidir.

DSDM

Dinamik Yazılım Geliştirme Yöntemi (DSDM), Hızlı Uygulama Geliştirmeye (RAD) dayanır ve Çevik Çerçeve ile uyumludur. DSDM, kullanıcıları aktif olarak dahil ederek ve ekipleri hızlı kararlar almaları için güçlendirerek, ürünün sık sık teslim edilmesine odaklanır.

Yalın Yazılım Geliştirme

Yalın Yazılım Geliştirmede odak, israfı ortadan kaldırmak ve müşteriye değer vermektir. Bu, hızlı gelişme ve değerli ürün ile sonuçlanır.

Atık, kısmen yapılan işleri, ilgisiz işleri, müşteri tarafından kullanılmayan özellikleri, teslimatta gecikmelere neden olan kusurları vb. İçerir.

Lean Principles -

İsrafı Ortadan Kaldırın
Öğrenmeyi Güçlendirin
Gecikme Taahhüdü
Ekibi Güçlendirin
Hızlı Teslim Et
Dürüstlük Oluşturun
Bütünü Gör

Kanban

Kanban, ekip üyelerini aşırı yüklememekle birlikte tam zamanında (JIT) teslimata vurgu yaparak işi yönetmeye odaklanır. Görevler, tüm katılımcıların görmesi ve Takım Üyelerinin bir kuyruktan iş çekmesi için görüntülenir.

Kanban şuna dayanır -

Kanban Kurulu (Geliştirme Boyunca Görsel ve Kalıcı)
Devam Eden Çalışma (Devam Eden Çalışma) Sınırı
Teslim süresi

Çevik Test Metodolojileri

Kaliteli ürünler sunmak için Agile olsun veya olmasın her proje için test uygulamaları iyi tanımlanmıştır. Geleneksel Test ilkeleri, Çevik Testte oldukça sık kullanılmaktadır. Bunlardan biri, aşağıdakilere odaklanan Erken Testtir -

Sistemin davranışını ifade etmek için Test Örnekleri Yazma.
Erken Kusur Önleme, tespit ve giderme.
Doğru test türlerinin doğru zamanda ve doğru test seviyesinin bir parçası olarak çalıştırılmasını sağlamak.

Tartıştığımız tüm Çevik Metodolojilerde, Çevik Test kendi başına bir Metodolojidir. Tüm yaklaşımlarda, Test Örnekleri Kodlamadan önce yazılır.

Bu eğitimde, Çevik Test Metodolojisi olarak Scrum'a odaklanacağız.

Yaygın olarak kullanılan diğer Çevik Test Metodolojileri şunlardır:

Test-Driven Development (TDD) - Test Güdümlü Geliştirme (TDD), testler tarafından yönlendirilen kodlamaya dayanır.
Acceptance Test-Driven Development (ATDD) - Kabul Testi Odaklı Geliştirme (ATDD), müşteriler, geliştiriciler ve test uzmanları arasındaki iletişime dayanır ve önceden tanımlanmış Kabul Kriterleri ve Kabul Testi Durumları tarafından yönlendirilir.
Behavior-Driven Development (BDD) - Davranış Odaklı Geliştirme (BDD) testi, geliştirilmekte olan yazılımın beklenen davranışına dayanır.

Çevik Test Yaşam Döngüsü

Scrum'da Test faaliyetleri şunları içerir:

Test Durumları olarak gösterilen Sistemin beklenen davranışına dayalı olarak Kullanıcı Hikayelerine katkıda bulunmak
Test Eforuna ve Kusurlara Dayalı Sürüm Planlaması
Kullanıcı Hikayelerine ve Kusurlarına Dayalı Sprint Planlama
Sürekli Test ile Sprint Yürütme
Sprint'in tamamlanmasından sonra Regresyon Testi
Test Sonuçlarını Raporlama
Otomasyon Testi

Test, yinelemelidir ve aşağıda verilen diyagramda gösterildiği gibi sprintlere dayanır -

Çevik Geliştirme ekip merkezlidir ve geliştiriciler ve test uzmanları tüm proje ve geliştirme faaliyetlerinde yer alır. Ekip Çalışması, Çevik projelerde test başarısını en üst düzeye çıkarır.

Agile ekibindeki bir Test Cihazı, tüm proje faaliyetlerine katılmalı ve katkıda bulunmalı ve aynı zamanda test uzmanlığından yararlanmalıdır.

Çevik bir test cihazı geleneksel test becerilerine sahip olmalıdır. Ek olarak, Çevik test cihazının ihtiyacı olan -

İyi kişilerarası beceriler.
Ekip üyeleri ve paydaşlar ile olumlu ve çözüm odaklı hareket etme becerisi.
Ürün hakkında eleştirel, kalite odaklı, şüpheci düşünme becerisi.
Paydaşlardan aktif olarak bilgi almak için proaktif olma yeteneği.
Test edilebilir Kullanıcı Hikayelerini, Kabul Kriterlerini tanımlamada müşteriler ve paydaşlarla etkili bir şekilde çalışma becerileri.
Kaliteli kod üretmede geliştiricilerle birlikte çalışan iyi bir ekip üyesi olma yeteneği.
Doğru test senaryolarına doğru zamanda ve doğru seviyede sahip olmak için test becerilerinin kullanılabilirliği ve bunları sprint süresi içinde iyi bir şekilde gerçekleştirilmesi.
Test sonuçlarını, test ilerlemesini ve ürün kalitesini değerlendirme ve raporlama yeteneği.
Test senaryolarının değiştirilmesi, eklenmesi veya iyileştirilmesi dahil olmak üzere değişikliklere hızlı yanıt verme açıklığı.
Çalışmayı kendi kendine organize etme potansiyeli.
Sürekli beceri gelişimi için coşku.
Test Otomasyonunda Yetkinlik, Teste Dayalı Geliştirme (TDD), Kabul Testine Dayalı Geliştirme (ATDD), Davranış Odaklı Geliştirme (BDD) ve deneyime dayalı Test.

Agile Takımında Test Cihazının Rolü

Agile Team'deki Tester, en iyi test uzmanlığına katkıda bulunmak için tüm proje ve geliştirme faaliyetlerine katılır.

Çevik Test Etkinlikleri şunları içerir:

Test araçlarının doğru kullanımının sağlanması.
Test ortamlarını ve test verilerini yapılandırma, kullanma ve yönetme.
Diğer ekip üyelerine testin ilgili yönlerinde rehberlik etmek.
Sürüm ve sprint planlaması sırasında uygun test görevlerinin programlanmasını sağlamak.
Test stratejisini anlamak, uygulamak ve güncellemek.
Test edilebilirlik, tutarlılık ve eksiksizlik açısından gereksinimleri netleştirmek için geliştiriciler, müşteri ve paydaşlarla işbirliği yapmak.
Doğru testlerin doğru zamanda ve doğru test seviyelerinde yapılması.
Hataları bildirmek ve bunları çözmek için ekiple birlikte çalışmak.
Geçerli tüm kapsam boyutlarında test kapsamını ölçme ve raporlama.
Sprint retrospektiflerine katılmak, proaktif olarak iyileştirmeler önermek ve geliştirmek.

Çevik Yaşam Döngüsünde, bir test uzmanı şu konularda önemli bir Rol oynar:

Teamwork
Test Planlama
Sprint Sıfır
Integration
Çevik Test Uygulamaları

Takım çalışması

Çevik Geliştirme'de ekip çalışması esastır ve bu nedenle aşağıdakileri gerektirir:

Collaborative Approach- Test Stratejisi, Test Planlama, Test Spesifikasyonu, Test Yürütme, Test Değerlendirme ve Test Sonuçlarının Raporlanması konularında çapraz fonksiyonel ekip üyeleriyle birlikte çalışma. Diğer ekip etkinlikleriyle bağlantılı olarak test uzmanlığına katkıda bulunmak.
Self-organizing - Diğer ekip üyelerinin de uzmanlıklarını birleştirerek test hedeflerine ulaşmak için sprintler içinde iyi planlama ve organizasyon.
Empowerment - Takımın hedeflerine ulaşmada uygun teknik kararlar almak.
Commitment - Müşterilerin ve paydaşların gerektirdiği şekilde ürünün davranışını ve özelliklerini anlamayı ve değerlendirmeyi taahhüt etmek.
Transparent - Açık, İletişimci ve Hesap Verebilir.
Credibility- Test stratejisinin, uygulanmasının ve yürütülmesinin güvenilirliğini sağlamak. Müşterileri ve paydaşları test stratejisi hakkında bilgilendirmek.
Open to Feedback- Hem başarılardan hem de başarısızlıklardan öğrenmek için sprint retrospektiflerine katılmak. Kaliteli çıktılar sağlamak için müşteri geri bildirimi istemek ve hızlı ve uygun şekilde hareket etmek.
Resilient - Değişikliklere yanıt vermek.

Test Planlama

Test Planlaması, sürüm planlaması sırasında başlamalı ve her sprint sırasında güncellenmelidir. Test planlaması aşağıdaki görevleri kapsamalıdır -

Test kapsamını, test kapsamını, test ve sprint hedeflerini tanımlama.
Test ortamı, test araçları, test verileri ve konfigürasyonlara karar vermek.
Özelliklerin ve özelliklerin test edilmesi.
Test görevlerini planlamak ve test sıklığını tanımlamak.
Test yöntemlerini, tekniklerini, araçlarını ve test verilerini tanımlama.
Önceki görevler, uzmanlık ve eğitim gibi ön koşulların belirlenmesi.
İşlevler, kod, sistem bileşenleri, satıcı, teknoloji, araçlar, etkinlikler, görevler, ekipler, test türleri, test seviyeleri ve kısıtlamalar gibi bağımlılıkları tanımlama.
Müşteri / kullanıcı önemi ve bağımlılıkları dikkate alınarak önceliklerin belirlenmesi.
Test için gereken süre ve çabaya ulaşma.
Her sprint planlamasında görevleri tanımlama.

Sprint Sıfır

Sprint Zero, ilk sprint öncesi hazırlık faaliyetlerini içerir. Bir test uzmanının aşağıdaki etkinliklerde ekiple işbirliği yapması gerekir:

Kapsamı belirleme
Kullanıcı hikayelerini sprintlere bölme
Sistem mimarisi oluşturma
Araçları planlama, edinme ve kurma (test araçları dahil)
Tüm test seviyeleri için ilk test stratejisinin oluşturulması
Test ölçümlerini tanımlama
"Bitti" tanımı olarak da adlandırılan kabul kriterlerini belirtme
Çıkış kriterlerini tanımlama
Scrum panosu oluşturma
Sprintler boyunca test için yön belirleme

Entegrasyon

Çevik'te, kaliteli bir çalışan ürün, geliştirme yaşam döngüsünün herhangi bir anında piyasaya sürülmeye hazır olmalıdır. Bu, gelişimin bir parçası olarak sürekli entegrasyon anlamına gelir. Çevik bir test cihazının sürekli testlerle sürekli entegrasyonu desteklemesi gerekir.

Bunu başarmak için bir test uzmanının şunları yapması gerekir:

Entegrasyon stratejisini anlayın.
İşlevler ve özellikler arasındaki tüm bağımlılıkları tanımlayın.

Çevik Test Uygulamaları

Agile test edicisinin, Agile projesinde test etmek için Agile uygulamalarını uyarlaması gerekir.

Pairing- İki ekip üyesi aynı klavyede birlikte çalışır. Bunlardan biri test ederken, diğeri testleri gözden geçirir / analiz eder. İki ekip üyesi olabilir
- Bir test cihazı ve bir geliştirici
- Bir test uzmanı ve bir iş analisti
- İki testçi
Incremental Test Design - Test senaryoları, basit testlerden başlayıp daha karmaşık testlere doğru ilerleyen kullanıcı öykülerinden oluşturulur.
Mind Mapping- Zihin haritası, bilgiyi görsel olarak düzenlemek için bir diyagramdır. Zihin haritalama, Agile testinde etkili bir araç olarak kullanılabilir, gerekli test seansları, test stratejileri ve test verileri ile ilgili hangi bilgilerin organize edilebileceği kullanılır.

Test Durumu iletilebilir -

Günlük stand-up toplantıları sırasında
Standart test yönetimi araçlarını kullanma
Haberciler aracılığıyla

Test geçme durumuna göre belirlenen test durumu, görevin "Bitti" olup olmadığına karar vermede çok önemlidir. Bitti, görev için tüm testlerin başarılı olduğu anlamına gelir.

Test İlerlemesi

Test İlerlemesi şu şekilde izlenebilir -

Scrum Panoları (Çevik Görev Panoları)
Burndown Grafikleri
Otomatik Test Sonuçları

Test İlerlemesi, geliştirme ilerlemesi üzerinde de doğrudan etkiye sahiptir. Bunun nedeni, bir Kullanıcı Hikayesinin şu adrese taşınabilmesidir:Donedurumu ancak Kabul Kriterlerine ulaşıldıktan sonra. Buna karşılık, Kabul Kriterleri bir Test Durumuna göre değerlendirildiği için Test Durumuna göre karar verilir.

Test ilerlemesinde herhangi bir gecikme veya tıkanma varsa, tüm ekip tartışır ve sorunu çözmek için işbirliği içinde çalışır.

Çevik Projelerde, değişiklikler oldukça sık gerçekleşir. Birçok değişiklik gerçekleştiğinde, Test Durumunun, Test İlerlemesinin ve Ürün Kalitesinin sürekli olarak gelişmesini bekleyebiliriz. Çevik test uzmanlarının, her bir yinelemenin başarılı bir şekilde tamamlanması için doğru zamanda doğru kararların alınabilmesi için bu bilgileri ekibe alması gerekir.

Değişiklikler gerçekleştiğinde, önceki yinelemelerin mevcut özelliklerini etkileyebilirler. Bu gibi durumlarda, regresyon riskiyle etkili bir şekilde başa çıkmak için manuel ve otomatik testler güncellenmelidir. Regresyon testi de gereklidir.

Ürün kalitesi

Ürün Kalite Ölçütleri şunları içerir -

Testler Başarılı / Başarısız
Bulunan / Düzeltilen Kusurlar
Test kapsamı
Test Başarılı / Başarısız Oranları
Kusur Keşif Oranları
Kusur Yoğunluğu

Ürün kalitesi ölçümlerinin toplanmasının ve raporlanmasının otomatikleştirilmesi şu konularda yardımcı olur:

Şeffaflığı korumak.
Tüm ilgili ve gerekli ölçümleri doğru zamanda toplamak.
İletişim gecikmeleri olmadan anında raporlama.
Test uzmanlarının teste odaklanmasına izin verme.
Metriklerin kötüye kullanımını filtrelemek.

Genel ürün kalitesini güvence altına almak için Agile ekibinin, ürünün müşteri beklentilerini karşılayıp karşılamadığına dair müşteri geri bildirimi alması gerekir. Bu, her yinelemenin sonunda gerçekleştirilmelidir ve geri bildirim, sonraki yinelemeler için bir girdi olacaktır.

Anahtar Başarı Faktörleri

Çevik projelerde, Çevik test başarılı olursa kaliteli ürünler teslim edilebilir.

Çevik testin başarısı için aşağıdaki noktaların dikkate alınması gerekir -

Çevik test, önce test ve sürekli test yaklaşımlarına dayanır. Bu nedenle, son test yaklaşımı üzerine kurulu geleneksel test araçları uygun olmayabilir. Bu nedenle, Çevik projelerde Test Araçlarını seçerken, Çevik test ile uyumun doğrulanması gerekir.
Geliştirme yaşam döngüsünün başlarında testleri otomatikleştirerek toplam test süresini azaltın.
Çevik test uzmanlarının, geliştirme yayın programına uyum sağlamak için hızlarını korumaları gerekir. Bu nedenle, test faaliyetlerinin uygun şekilde planlanması, takibi ve yeniden planlanması, hedef olarak ürün kalitesiyle birlikte anında yapılmalıdır.
Manuel test, projelerdeki testlerin% 80'ini oluşturmaktadır. Bu nedenle, uzmanlığa sahip test uzmanlarının Agile ekibinin bir parçası olması gerekir.
Geliştirme yaşam döngüsü boyunca uzmanlığa sahip bu test uzmanlarının katılımı, tüm ekibin müşteri beklentilerini karşılayan kaliteli ürüne odaklanmasını sağlar.
- Son kullanıcılar tarafından beklenen ürün davranışını vurgulayan kullanıcı hikayeleri tanımlama.
- Müşteri beklentilerine göre kullanıcı hikayesi seviyesinde / görev seviyesinde Kabul Kriterlerinin belirlenmesi.
- Test faaliyetleri için çaba ve süre tahmini.
- Test faaliyetlerinin planlanması.
- Önceden test tasarımıyla gereksinimleri karşılayan kod üretimini sağlamak için geliştirme ekibiyle uyum sağlama.
- Beklenen zamanda kabul kriterlerini karşılayan bitmiş duruma ulaşıldığından emin olmak için ilk ve sürekli testi test edin.
- Sprint içinde her seviyede testin sağlanması.
- Her sprint sonunda regresyon testi.
- Projenin başarısı için yararlı olan ürün ölçümlerini toplamak ve analiz etmek.
- Mevcut Sprint'te hangilerinin düzeltilmesi gerektiğini ve hangilerinin sonraki Sprintlere ertelenebileceğini belirlemek için kusurları analiz etmek.
- Müşterinin bakış açısından önemli olana odaklanmak.

Lisa Crispin, Çevik Test Başarısı için yedi temel Faktör tanımladı -

Whole Team approach- Bu tür bir yaklaşımda, geliştiriciler test uzmanlarını eğitir ve test uzmanları diğer ekip üyelerini eğitir. Bu, herkesin projedeki her görevi anlamasına yardımcı olur, böylece işbirliği ve katkı maksimum fayda sağlar. Test uzmanlarının müşterilerle iş birliği de, beklentilerini en baştan belirlemek ve kabul kriterlerini testi geçmek için gerekenlere çevirmek için önemli bir faktördür.
Agile Testing Mindset - Test uzmanları, kaliteyi sürekli iyileştirme ve ekibin geri kalanıyla sürekli işbirliği yapma konusunda proaktiftir.
Automate Regression Testing- Test edilebilirlik için tasarım ve testlerle sürücü geliştirme. Basit başlayın ve takımın araçları seçmesine izin verin. Tavsiye vermeye hazır olun.
Provide and Obtain Feedback- Bu temel bir Çevik değer olduğundan, tüm ekip geri bildirime açık olmalıdır. Test uzmanları uzman geri bildirim sağlayıcıları olduğundan, ilgili ve gerekli bilgilere odaklanmaları gerekir. Buna karşılık, geri bildirim alındığında, test senaryosu değişiklikleri ve testler uygun olmalıdır.
Build a Foundation of Core Agile Practices - Kodlama, sürekli entegrasyon, işbirliğine dayalı test ortamları, aşamalı olarak çalışma, değişiklikleri kabul etme, sinerjiyi sürdürmenin yanı sıra test etmeye odaklanın.
Collaborate with Customers - Örnekler oluşturun, anlayın ve ürün davranışına yönelik gereksinimleri kontrol edin, Kabul Kriterlerini ayarlayın, geri bildirim alın.
Look at the Big Picture - Gerçek dünya test verilerini kullanarak ve diğer alanlardaki etkileri düşünerek işle ilgili testler ve örneklerle gelişimi teşvik edin.

Bu bölümde, Çevik Testin bazı önemli özelliklerini göreceğiz.

Çevik Test Avantajları

Çevik testin faydaları şunlardır:

Hızlı, sürekli tamamen test edilmiş ürün ve müşteri geri bildirimi arayışı ile müşteri memnuniyeti.
Müşteriler, geliştiriciler ve test uzmanları birbirleriyle sürekli etkileşime girerek döngü süresini kısaltır.
Çevik test uzmanları, neyin uygulanabilir olduğuna odaklanmak için test uzmanlıklarına katkıda bulunarak gereksinimleri tanımlamaya katılır.
Çevik test uzmanları, test çabasını ve süresini değerlendirmeye katılır.
Kabul Kriterlerini yansıtan erken test tasarımı.
Tüm ekip tarafından birleştirilmiş test gereksinimleri, dezavantajlardan kaçınılır.
Tüm ekip tarafından ürünün kalitesine sürekli odaklanma.
Tanımı Done durumu yansıtan testler geçmesi, gereksinimin karşılanmasını sağlar.
Tüm ekibin çabasıyla derhal çözüme kavuşturulabilmesi için gecikmeler veya tıkanmalar hakkında sürekli geri bildirim.
Değişen gereksinimlere hızlı yanıtlar ve bunları kısa sürede karşılama.
Sürekli entegrasyon odaklı regresyon testi.
Geliştirme ve test arasında zaman gecikmesi yok. önce test edin, sürekli test yaklaşımları takip edilir.
Otomasyon testi, geliştirme yaşam döngüsünün başlarında uygulanarak toplam test süresini ve çabasını azaltır.

Çevik Testte En İyi Uygulamalar

Aşağıda verilen en iyi uygulamaları izleyin -

Tüm seviyelerde her tür testte uzmanlığa sahip test uzmanlarının dahil edilmesi.
Ürünün beklenen davranışı konusunda müşterilerle işbirliği yaparak gereksinimlerin tanımına katılan test uzmanları.
Test uzmanları, geliştiriciler ve müşteri ile sürekli olarak geri bildirim paylaşır.
Geliştirme çalışmasına uyum sağlamak için ilk ve sürekli test yaklaşımlarını test edin.
Kaliteli ürün sunmaya odaklanarak test durumunu ve test ilerlemesini hızlı ve sürekli olarak izleme.
Döngü süresini azaltmak için geliştirme yaşam döngüsünün başlarında otomasyon testi.
Regresyon Testini gerçekleştirmek için Otomasyon Testini etkili bir yöntem olarak kullanın.

Çevik Testte Zorluklar

Çevik testte aşağıdaki zorluklar mevcuttur -

Çevik yaklaşımın ve sınırlamalarının İşletme ve Yönetim tarafından anlaşılmaması, ulaşılamaz beklentilere yol açabilir.
Çevik, tüm Takım yaklaşımını takip eder, ancak herkes Test Uygulamalarının temellerini bilmiyor. Testçilerin diğerlerine koçluk yapması tavsiye edilir, ancak gerçek senaryoda zaman kutulu Sprintler (Yinelemeler) ile uygulanamaz.
İlk Test Yaklaşımı, Geliştiricilerin kodlamayı Test Kullanıcısı Geri Bildirimine dayandırmasını gerektirir, ancak gerçek senaryolarda Geliştiriciler, kodlamayı Müşteri veya İşletmeden gelen Gereksinimlere dayandırmaya daha alışkındır.
Kaliteli Ürün için Hesap Verebilirlik tüm Çevik Ekibin içindedir, ancak ilk aşamalarda Geliştiriciler, uygulama moduna daha çok girdiklerinden Kaliteye Odaklanmayabilirler.
Sürekli Entegrasyon, otomatikleştirilmesi gerekse bile önemli ölçüde çaba gerektiren Regresyon Testini gerektirir.
Test uzmanları, Agile zihniyetiyle değişikliklere uyarlanabilir, ancak sonuçta ortaya çıkan Test Değişikliklerine ve Testlere uyum sağlamak, Sprint sırasında hedeften bitişe ulaşmak için pratik olmayabilir.
Erken Otomasyon tavsiye edilir, böylece Manuel Test Eforu ve Süresi azaltılabilir. Ancak gerçek senaryoda, otomatikleştirilebilen Testlere ulaşmak ve bunları otomatikleştirmek Zaman ve Çaba gerektirir.

Çevik Test Yönergeleri

Çevik Test gerçekleştirirken aşağıdaki yönergeleri kullanın.

Gerekli Test faaliyetlerini belirlemek ve test planının ilk versiyonunu bulmak için Sürüm Planlamaya katılın.
Test faaliyetlerinin yinelemelerde yer alması için test eforuna ve süresine ulaşmak için tahmin oturumuna katılın.
Kabul Testi Durumlarına ulaşmak için Kullanıcı Hikayesi Tanımına katılın.
Kapsamı anlamak ve Test Planını güncellemek için her Sprint Planlama Toplantısına katılın.
Test ve Kodlamanın Sprint içinde başarılı olmasını sağlamak için Sprint sırasında Geliştirme Ekibi ile sürekli işbirliği yapın.
Anında çözüm almak için Günlük Stand-up Toplantılarına katılın ve varsa Test Gecikmelerini veya Blokajları iletin.
Test Durumunu, Test İlerlemesini ve Ürün Kalitesini düzenli olarak izleyin ve bildirin.
Test Durumlarında, Test Verilerinde yapılan değişikliklerle yanıt vererek değişiklikleri düzenlemeye hazır olun.
En İyi Uygulamaları ve Öğrenilen Dersleri anlamak ve bunlara katkıda bulunmak için Sprint Retrospektiflerine katılın.
Her Sprint'te Müşteri Geri Bildirimi almak için işbirliği yapın.

Geleneksel Testte olduğu gibi, Çevik Testin de tüm Test Düzeylerini kapsaması gerekir.

Birim Testi
Entegrasyon Testi
Sistem Testi
kullanıcı Kabul Testi

Birim Testi

Geliştirici tarafından Kodlama ile birlikte yapılır
% 100 Tasarım Kapsamı sağlayan Test Durumlarını yazan Test Uzmanı tarafından desteklenir
Birim Testi Durumları ve Birim Testi sonuçlarının gözden geçirilmesi gerekiyor
Çözülmemiş büyük kusurlar (öncelik ve ciddiyete göre) kalmaz
Tüm Birim Testleri otomatiktir

Entegrasyon Testi

Sprintler ilerledikçe Sürekli Entegrasyon ile birlikte yapılır
Tüm Sprintler tamamlandıktan sonra bitti
Tüm İşlevsel Gereksinimler test edilir
Üniteler arasındaki tüm Arayüzler test edilir
Tüm Kusurlar Rapor Edilir
Testler mümkün olduğunda otomatiktir

Sistem Testi

Geliştirme ilerledikçe yapılır
Kullanıcı Hikayeleri, Özellikleri ve İşlevleri Test Edilir
Üretim Ortamında yapılan testler
Kalite Testleri yapılır (Performans, Güvenilirlik vb.)
Kusurlar rapor edildi
Testler mümkün olduğunda otomatiktir

kullanıcı Kabul Testi

Her Sprint'in sonunda ve projenin sonunda yapılır
Müşteri tarafından yapılır. Geri bildirim Ekip tarafından alınır
Geri bildirim, sonraki Sprintler için bir girdi olacaktır
Bir Sprint'teki Kullanıcı Hikayeleri, test edilebilir olmaları için önceden doğrulanmıştır ve tanımlanmış Kabul Kriterlerine sahiptir

Test Türleri

Bileşen Testleri (Birim Testleri)
Fonksiyonel Testler (Kullanıcı Hikayeleri Testleri)
Fonksiyonel Olmayan Testler (Performans, Yük, Stres vb.)
Kabul testleri

Testler tamamen Manuel, Tam Otomatik, Manuel ve Otomatik Kombinasyonu veya Araçlar tarafından desteklenen Manuel olabilir.

Destek Programlama ve Kritik Ürün Testleri

Testler şunlar olabilir -

Supporting Development (Support Programming) - Destek Programlama Testleri, Programcılar tarafından kullanılır.
- Bir Sistemin belirli bir davranışını gerçekleştirmek için hangi kodu yazmaları gerektiğine karar vermek
- Yeni Kodun Sistemin geri kalan davranışlarını engellememesini sağlamak için Kodlamadan sonra hangi Testlerin çalıştırılması gerekir?
Verification only (Critique Product) - Kritik Ürün Testleri, bitmiş Üründeki eksiklikleri tespit etmek için kullanılır

İşle Yüzleşme ve Teknolojiyle Yüzleşme Testleri

Hangi testlerin ne zaman yapılacağına karar vermek için, bir testin -

Business Facing veya
Teknoloji Karşılaşması

İş Karşılıklı Testler

Bir Test, işletme alanından kelimelerle çerçevelenmiş soruları yanıtlarsa, işe yönelik bir testtir. Bunlar iş uzmanları tarafından anlaşılır ve ilgilerini çeker, böylece sistemin davranışı gerçek zamanlı senaryoda açıklanabilir.

Teknoloji Karşılıklı Testler

Test, teknoloji alanından kelimelerle çerçevelenen soruları yanıtlayan teknolojiye dönük bir testtir. Programcılar, teknolojiyle ilgili açıklamalara dayanarak nelerin uygulanması gerektiğini anlar.

Test türlerinin bu iki yönü Brian Marick tarafından tanımlanan Çevik Test Çeyrekleri kullanılarak görüntülenebilir.

Çevik Test Çeyrekleri

Test Türlerinin iki yönünü birleştiren aşağıdaki Çevik Test Çeyreği Brian Marick tarafından türetilmiştir:

Çevik Test Çeyreği, ekiplerin gereken testleri belirlemesine, planlamasına ve yürütmesine yardımcı olmak için yararlı bir sınıflandırma sağlar.

Quadrant Q1- Birim Seviyesi, Teknoloji Karşılaşması ve geliştiricileri destekler. Birim testleri bu Çeyreğe aittir. Bu testler Otomatik testler olabilir.
Quadrant Q2- Sistem düzeyi, işle ilgili ve ürün davranışına uygunluk. Fonksiyonel testler bu kadrana aittir. Bu testler manuel veya otomatiktir.
Quadrant Q3- Sistem veya Kullanıcı Kabul Düzeyi, İşle Yüzleşme ve gerçek zamanlı senaryolara odaklanma. Kullanıcı Kabul Testleri bu kadrana aittir. Bu testler manueldir.
Quadrant Q4- Sistem veya Operasyonel Kabul Seviyesi, Teknoloji Karşılaşması ve Performans, Yük, Stres, Sürdürülebilirlik, Ölçeklenebilirlik Testlerine Odaklanma. Otomasyon testi ile birlikte bu testler için özel araçlar kullanılabilir.

Bunları birleştiren Çevik Test Çeyrekleri What-Testing-When aşağıdaki gibi görselleştirilebilir -

Scrum savunucuları Whole Team Approachher ekip üyesinin her proje faaliyetinde yer alması gerektiği anlamında. Scrum ekibi, proje çıktılarına karşı hesap verebilirlikle kendi kendini organize eder. Karar verme ekibe bırakılır ve bu da herhangi bir gecikme olmaksızın doğru zamanda uygun önlemlerin alınmasını sağlar. Bu yaklaşım aynı zamanda tek bir faaliyetle sınırlandırmak yerine takım yeteneğinin doğru kullanımını teşvik eder. Test uzmanları, test konusundaki uzmanlıklarına katkıda bulunan tüm proje ve geliştirme faaliyetlerine de katılırlar.

Tüm ekip Test Stratejisi, Test Planlama, Test Spesifikasyonu, Test Yürütme, Test Değerlendirme ve Test Sonuçları Raporlama konularında birlikte çalışır.

İşbirliğine Dayalı Kullanıcı Hikayesi Oluşturma

Testçiler, Kullanıcı Hikayesi Oluşturma'ya katılır. Test uzmanları, sistemin olası davranışına ilişkin fikirlerine katkıda bulunur. Bu, müşterinin ve / veya son kullanıcının sistemi gerçek ortamda anlamasına ve böylece sonuç olarak gerçekte ne istedikleri konusunda netlik kazanmasına yardımcı olur. Bu, gereksinimlerin daha hızlı dondurulmasına neden olur ve ayrıca daha sonra gereksinimlerde değişiklik olasılığını azaltır.

Test uzmanları ayrıca müşteri tarafından kabul edilen her senaryo için Kabul Kriterlerini oluşturur.

Test uzmanları, test edilebilir kullanıcı hikayelerinin oluşturulmasına katkıda bulunur.

Sürüm Planlama

Tüm proje için Sürüm Planlaması yapılır. Bununla birlikte, Scrum çerçevesi, sprintlerin gerçekleştirilmesi sırasında daha fazla bilgi elde edildiğinden yinelemeli karar vermeyi içerir. Bu nedenle, projenin başlangıcındaki Sürüm Planlama oturumunun tüm proje için ayrıntılı bir yayın planı üretmesine gerek yoktur. İlgili bilgiler mevcut olduğundan sürekli olarak güncellenebilir.

Her sprint-ucunun bir sürüme sahip olması gerekmez. Sürüm, bir grup sprintten sonra olabilir. Bir sürümün ana kriteri, müşteriye iş değeri sağlamaktır. Ekip, bir girdi olarak yayın planlamasıyla birlikte sprint uzunluğuna karar verir.

Sürüm Planlama, test yaklaşımının ve sürüm için test planının temelidir. Test uzmanları Test Eforunu tahmin eder ve sürüm için Test yapmayı planlar. Sürüm planları değiştiğinde, test uzmanları değişiklikleri ele almalı, daha geniş sürüm bağlamını dikkate alarak yeterli bir test temeli edinmelidir. Test uzmanları ayrıca tüm sprintlerin sonunda gerekli olan test çabasını sağlar.

Sprint Planlama

Sprint planlaması her sprintin başında yapılır. Sprint iş yığını, belirli bir sprintte uygulama için ürün birikiminden alınan kullanıcı hikayeleriyle oluşturulur.

Test uzmanları şunları yapmalıdır:

Sprint için seçilen kullanıcı hikayelerinin test edilebilirliğini belirleyin
Kabul testleri oluşturun
Test seviyelerini tanımlayın
Test otomasyonunu tanımlayın

Test uzmanları, test planını, sprintteki test eforu ve sürelerine ilişkin tahminlerle günceller. Bu, zaman kutulu sprintler sırasında gerekli testler için zaman sağlanmasını ve ayrıca test çabasının hesap verebilirliğini sağlar.

Test Analizi

Bir sprint başladığında, geliştiriciler tasarım ve uygulama için hikaye analizini gerçekleştirirken, test uzmanları sprint iş yığınındaki hikayeler için test analizi yapar. Test cihazı, gerekli test senaryolarını oluşturur - hem manuel hem de otomatik testler.

Test yapmak

Scrum ekibinin tüm üyeleri teste katılmalıdır.

Geliştiriciler, kullanıcı hikayeleri için kod geliştirirken birim testlerini yürütürler. Birim Testleri, kod yazılmadan önce her sprintte oluşturulur. Birim test senaryoları, düşük seviyeli tasarım özelliklerinden türetilmiştir.
Test uzmanları, kullanıcı hikayelerinin işlevsel ve işlevsel olmayan özelliklerini gerçekleştirir.
Test uzmanları, scrum ekibindeki diğer üyelere test konusundaki uzmanlıkları ile mentorluk yapar, böylece tüm ekip, ürünün kalitesi için kolektif bir sorumluluğa sahip olur.
Sprint sonunda müşteri ve / veya son kullanıcılar Kullanıcı Kabul Testi yapar ve scrum ekibine geri bildirim sağlar. Bu, bir sonraki sprint için bir girdi oluşturur.
Test sonuçları toplanır ve muhafaza edilir.

Otomasyon Testi

Scrum takımlarında otomasyon testine büyük önem verilmektedir. Test uzmanları, otomatik testlerin ve sonuçların oluşturulması, yürütülmesi, izlenmesi ve sürdürülmesine zaman ayırır. Scrum projelerinde herhangi bir zamanda değişiklikler olabileceğinden, test uzmanlarının değişen özelliklerin testine ve ayrıca ilgili regresyon testine uyum sağlaması gerekir. Otomasyon testi, değişikliklerle ilişkili test çabasının yönetilmesini kolaylaştırır. Her seviyedeki otomatik testler, sürekli entegrasyona ulaşmayı kolaylaştırır. Otomatik testler, ek çaba gerektirmeden manuel testlerden çok daha hızlı çalışır.

Manuel test daha çok keşif testi, ürün güvenlik açığı ve kusurları tahmin etmeye odaklanır.

Test Faaliyetlerinin Otomasyonu

Test faaliyetlerinin otomasyonu, tekrarlanan iş yükünü azaltır ve maliyet tasarrufu sağlar. Otomatikleştirmek

Test Verisi Üretimi
Test Verisi Yükleme
Test Ortamına Dağıtım Oluşturun
Test Ortamı Yönetimi
Veri Çıkışı Karşılaştırması

Gerileme testi

Bir sprintte, testçiler o sprintte yeni / değiştirilmiş kodu test eder. Bununla birlikte, test uzmanlarının önceki sprintlerde geliştirilen ve test edilen kodun da yeni kodla birlikte çalıştığından emin olmaları gerekir. Bu nedenle, Scrum'da Regresyon testine önem verilmektedir. Otomatik regresyon testleri sürekli entegrasyonda çalıştırılır.

Konfigürasyon yönetimi

Scrum projelerinde otomatik derleme ve test çerçevelerini kullanan bir Konfigürasyon yönetim sistemi kullanılır. Bu, yeni kod Yapılandırma Yönetim Sisteminde kontrol edilirken statik analiz ve birim testlerinin tekrar tekrar çalıştırılmasına izin verir. Ayrıca yeni kodun sistemle sürekli entegrasyonunu da yönetir. Otomatik Regresyon Testleri, Sürekli Entegrasyon sırasında çalıştırılır.

Manuel Test Durumları, Otomatik Testler, Test Verileri, Test Planları, Test Stratejisi ve diğer Test Yapılarının Sürüm Kontrollü olması ve ilgili Erişim İzinlerinin sağlanması gerekir. Bu, Konfigürasyon Yönetim Sistemindeki Test Artefaktlarının bakımı yapılarak gerçekleştirilebilir.

Çevik Test Uygulamaları

Bir Scrum Takımındaki testçiler aşağıdaki Çevik Uygulamaları takip edebilir -

Pairing- İki Ekip Üyesi birlikte oturur ve işbirliği içinde çalışır. İki kişi, iki Test Kullanıcısı veya bir Test Cihazı ve bir Geliştirici olabilir.
Incremental Test Design - Test Durumları, Sprintler aşamalı olarak ilerledikçe ve Kullanıcı Hikayeleri eklendikçe geliştirilir.

Çevik Metrikler

Yazılım geliştirme sırasında, ölçümlerin toplanması ve analizi, sürecin iyileştirilmesine ve böylece daha iyi üretkenlik, kaliteli çıktılar ve müşteri memnuniyeti elde edilmesine yardımcı olur. Scrum tabanlı geliştirmede bu mümkündür ve test uzmanları ihtiyaç duydukları ölçütlere dikkat etmelidir.

Scrum geliştirme için çeşitli ölçütler önerilir. Önemli ölçütler -

Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Başarılı bir Sprint, Takımın taahhüdünü yerine getirebileceği bir sprinttir.
Velocity- Bir takımın Hızı, bir takımın bir sprint sırasında kazandığı Hikaye Puanı miktarına bağlıdır. Hikaye Puanları, tahmin sırasında sayılan Kullanıcı Hikayelerinin ölçüsüdür.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. Odak Faktörü, ekibin bitmiş hikayelerle sonuçlanan çabasının yüzdesidir.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. Tahmin Doğruluğu, Takımın çabayı doğru bir şekilde tahmin etme yeteneğidir.
Sprint Burndown- Kalan Vs. olan iş (Hikaye Puanı veya saat cinsinden) İdeal olarak Kalması gereken iş (Tahmine göre).
- Daha fazlaysa, Takım yapabileceğinden daha fazla İşe girmiş demektir.
- Daha azsa, Takımın doğru Tahmin yapmadığı anlamına gelir.
Defect Count- Bir Sprint'teki kusur sayısı. Kusur sayısı, biriktirme listesi ile karşılaştırıldığında yazılımdaki kusurların miktarıdır.
Severity of Defects- Kusurlar ciddiyetlerine göre küçük, büyük ve kritik olarak kategorize edilebilir. Test uzmanları kategorilendirmeyi tanımlayabilir.

Sprint Retrospektifleri

Sprint Retrospektiflerinde tüm ekip üyeleri katılacaktır. Paylaşırlar -

İyi giden şeyler
Metrics
İyileştirme kapsamı
Uygulanacak eylem öğeleri

Çevik Testte yaygın olarak kullanılan Test yöntemleri geleneksel uygulamalardandır ve Erken Test Et prensibiyle uyumludur. Test Örnekleri, kod yazılmadan önce yazılır. Vurgu, doğru test türlerini doğru zamanda ve doğru seviyede çalıştırarak kusur önleme, algılama ve gidermedir.

Bu bölümde, yöntemleri anlayacaksınız -

Test Odaklı Geliştirme (TDD)
Kabul Testi Güdümlü Geliştirme (ATDD)
Davranış Odaklı Geliştirme (BDD)

Test Odaklı Geliştirme

Test Güdümlü Geliştirme (TDD) yönteminde kod, Otomatik Test Örnekleri tarafından yönetilen Testfirst yaklaşımına göre geliştirilir. Önce başarısız olması için bir test senaryosu yazılır, testin başarılı olmasını sağlamak için buna göre kod geliştirilir. Yöntem tekrarlanır, yeniden düzenleme, kodun geliştirilmesi yoluyla yapılır.

TDD, aşağıdaki adımların yardımı ile anlaşılabilir -

Step 1 - Yazılması gereken kodun işlevselliğinin beklenen davranışını yansıtacak bir Test senaryosu yazın.
Step 2- Testi çalıştırın. Kod hala geliştirilmediği için test başarısız olur.
Step 3 - Test senaryosuna göre kod geliştirin.
Step 4- Testi tekrar çalıştırın. Bu sefer işlevsellik kodlandıkça testin geçmesi gerekir. Test geçene kadar Adım (3) ve Adım (4) 'ü tekrarlayın.
Step 5 - Kodu yeniden düzenleyin.
Step 6 - Geçtiğinden emin olmak için testi tekrar çalıştırın.

Tekrar et Step 1 – Step 6işlevsellik eklemek için test senaryoları eklemek. Kodun beklendiği gibi çalıştığından emin olmak için eklenen testler ve önceki testler her seferinde çalıştırılır. Bu süreci hızlandırmak için testler otomatikleştirilmiştir.

Testler birim, entegrasyon veya sistem düzeyinde olabilir. Test uzmanları ve geliştiriciler arasında sürekli iletişim sağlanmalıdır.

Kabul Testi Odaklı Geliştirme

Acceptance Test Driven Development (ATDD) yönteminde kod, Acceptance Test Case'ler tarafından yönetilen test-first yaklaşımı temel alınarak geliştirilir. Odak noktası, müşteri, son kullanıcılar ve ilgili paydaşlarla işbirliği içinde Kullanıcı Hikayesi Oluşturma sırasında test uzmanları tarafından yazılan kabul kriterleri ve Kabul Testi Durumlarıdır.

Step 1 - Müşteri ve kullanıcılarla işbirliği içinde kullanıcı hikayelerinin yanı sıra Kabul Testi Durumlarını yazın.
Step 2 - İlişkili kabul kriterlerini tanımlayın.
Step 3 - Kabul testleri ve kabul kriterlerine göre kod geliştirin.
Step 4 - Kodun beklendiği gibi çalıştığından emin olmak için kabul testlerini çalıştırın.
Step 5- Kabul testlerini otomatikleştirin. Tekrar etStep 3 – Step 5 yinelemedeki tüm kullanıcı hikayeleri uygulanana kadar.
Step 6 - Regresyon testlerini otomatikleştirin.
Step 7 - Sürekli Regresyonu sağlamak için otomatik Regresyon Testlerini çalıştırın.

Davranış Odaklı Geliştirme (BDD)

Davranış Odaklı Geliştirme (BDD), Test Güdümlü Geliştirmeye (TDD) benzer ve odak, sistemin beklenen davranışını sağlamak için kodu test etmektir.

BDD'de kullanıcılar, test uzmanları ve geliştiriciler için anlamlı olması için İngilizce gibi bir dil kullanılır. Sağlar -

Kullanıcılar, testçiler ve geliştiriciler arasında sürekli iletişim.
Nelerin geliştirildiği ve test edildiği konusunda şeffaflık.

Geleneksel testlerden Test Teknikleri, Çevik testlerde de kullanılabilir. Bunlara ek olarak, Agile projelerinde Agile'e özel test teknikleri ve terminolojileri kullanılmaktadır.

Test Esası

Çevik projelerde, ürün birikimi, gereksinim özellik belgelerinin yerini alır. Ürün birikiminin içeriği normalde kullanıcı hikayeleridir. İşlevsel olmayan gereksinimler de kullanıcı hikayelerinde dikkate alınır. Dolayısıyla Agile projelerinde test temeli kullanıcı hikayesidir.

Kalite testini sağlamak için aşağıdakiler ek olarak test temeli olarak da düşünülebilir -

Aynı projenin veya geçmiş projelerin önceki yinelemelerinden edinilen deneyim.
Sistemin mevcut fonksiyonları, mimarisi, tasarımı, kodu ve kalite özellikleri.
Mevcut ve geçmiş projelerden kusur verileri.
Müşteri geribildirimi.
Kullanıcı belgeleri.

Bitti'nin Tanımı

Bitti Tanımı (DoD), Sprint iş yığınındaki bir faaliyetin tamamlanmasını sağlamak için Çevik projelerde kullanılan kriterlerdir. DoD, bir Scrum takımından diğerine değişebilir, ancak bir takım içinde tutarlı olmalıdır.

DoD, kullanıcı öyküsünün bir parçası olan işlevsel olmayan gereksinimlerin yanı sıra bir kullanıcı öyküsündeki işlevlerin ve özelliklerin uygulanmasını sağlayan gerekli etkinliklerin bir kontrol listesidir. Savunma Bakanlığı kontrol listesindeki tüm maddeler tamamlandıktan sonra bir kullanıcı hikayesi Bitti aşamasına ulaşır. Ekip arasında bir Savunma Bakanlığı paylaşılır.

Bir kullanıcı hikayesi için tipik bir Savunma Bakanlığı şunları içerebilir:

Ayrıntılı Test Edilebilir Kabul Kriterleri
Kullanıcı Hikayesinin Yinelemedeki diğerleriyle tutarlılığını sağlamak için kriterler
Ürünle İlgili Özel Kriterler
İşlevsel Davranış Yönleri
İşlevsel olmayan özellikler
Interfaces
Test Verisi Gereksinimleri
Test kapsamı
Refactoring
İnceleme ve Onay Gereksinimleri

Kullanıcı Hikayeleri için DoD'ye ek olarak, DoD de gereklidir -

her Test Düzeyinde
her Özellik için
her Yineleme için
Yayın için

Test Bilgileri

Bir test uzmanının aşağıdaki Test bilgilerine sahip olması gerekir -

Test edilmesi gereken Kullanıcı Hikayeleri
İlişkili Kabul Kriterleri
Sistem Arayüzleri
Sistemin Çalışmasının Beklendiği Ortam
Araçların kullanılabilirliği
Test kapsamı
DoD

Çevik projelerde, test sıralı bir faaliyet olmadığından ve test uzmanlarının işbirliğine dayalı bir modda çalışması gerektiğinden, test uzmanının sorumluluğu:

Sürekli olarak gerekli test bilgilerini alın.
Testi etkileyen bilgi boşluklarını belirleyin.
Diğer ekip üyeleriyle işbirliği içinde boşlukları çözün.
Bir test seviyesine ulaşıldığında karar verin.
İlgili zamanlarda uygun testlerin yapıldığından emin olun.

Fonksiyonel ve Fonksiyonel Olmayan Test Tasarımı

Çevik projelerde geleneksel test teknikleri kullanılabilir, ancak odak noktası erken testtir. Uygulama başlamadan önce test senaryolarının oluşturulması gerekir.

Fonksiyonel test tasarımı için, test uzmanları ve geliştiriciler geleneksel Kara Kutu test tasarım tekniklerini kullanabilir:

Eşit bölümlere ayırma
Sınır Değer Analizi
Karar Tabloları
Devlet geçişi
Sınıf Ağacı

İşlevsel olmayan test tasarımı için, işlevsel olmayan gereksinimler de her kullanıcı öyküsünün bir parçası olduğu için, kara kutu test tasarım teknikleri yalnızca ilgili test senaryolarını tasarlamak için kullanılabilir.

Araştırma testi

Çevik projelerde, zaman genellikle Test Analizi ve Test Tasarımı için sınırlayıcı faktördür. Bu gibi durumlarda, Keşif test teknikleri, geleneksel test teknikleriyle birleştirilebilir.

Keşif Testi (ET), eşzamanlı öğrenme, test tasarımı ve test yürütme olarak tanımlanır. Keşif Testinde, test uzmanı, testlerin tasarımını gerçekleştirilirken aktif olarak kontrol eder ve test sırasında elde ettiği bilgileri yeni ve daha iyi testler tasarlamak için kullanır.

Keşif Testi, Çevik projelerdeki değişiklikleri karşılamak için kullanışlıdır.

Risk Temelli Test

Risk tabanlı test, başarısızlık riskine dayalı testlerdir ve test tasarım tekniklerini kullanarak riskleri azaltır.

Ürün kalitesi riski, ürün kalitesiyle ilgili potansiyel bir sorun olarak tanımlanabilir. Ürün kalitesi riskleri şunları içerir:

Fonksiyonel riskler
İşlevsel olmayan performans riskleri
İşlevsel olmayan kullanılabilirlik riskleri

Her bir riskin olasılığını (olasılığını) ve etkisini değerlendirmek için risk analizi yapılacaktır. Ardından risklere öncelik verilir -

Yüksek Riskler Kapsamlı Testler gerektirir
Düşük Riskler yalnızca Cursory Test gerektirir

Testler, her bir Riskin Risk Seviyesi ve Risk Karakteristiğine göre uygun Test Teknikleri kullanılarak tasarlanır. Daha sonra Riskleri azaltmak için testler yapılır.

Fit Testleri

Uygunluk Testleri, otomatik Kabul Testleridir. Tools Fit ve FitNesse, kabul testlerini otomatikleştirmek için kullanılabilir.

FIT, JUnit kullanır, ancak test işlevini genişletir. Test senaryolarını görüntülemek için HTML tabloları kullanılır. Fixture, HTML tablosunun arkasındaki bir Java sınıfıdır. Fikstür, HTML tablosunun içeriğini alır ve test edilen projede test senaryolarını çalıştırır.

Test Planı, Sürüm Planlaması sırasında hazırlanır ve her Sprint Planlamasında revize edilir. Test Planı, eksiksiz test kapsamına sahip olmak için test süreci için bir kılavuz görevi görür.

Bir Test Planının Tipik İçeriği:

Test Stratejisi
Test ortamı
Test kapsamı
Test Kapsamı
Test Eforu ve Programı
Test Araçları

Çevik Projelerde, tüm Ekip Üyeleri ürünün kalitesinden sorumludur. Bu nedenle, herkes test planlamasına da katılır.

Bir test uzmanının sorumluluğu, gerekli yönlendirmeyi sağlamak ve ekibin geri kalanına test uzmanlıkları konusunda rehberlik etmektir.

Kullanıcı hikayeleri

Kullanıcı Hikayeleri prensip olarak çalışma ürünlerini test etmez. Ancak Agile Projelerinde, testçiler Kullanıcı Hikayeleri Oluşturma programına katılır. Test uzmanları, müşteriye değer katan ve sistemin farklı olası davranışlarını kapsayan Kullanıcı Hikayeleri yazar.

Test uzmanları ayrıca tüm Kullanıcı Hikayelerinin test edilebilir olmasını sağlar ve Kabul Kriterlerini sağlar.

Manuel ve Otomatik Testler

Testin ilk çalıştırması sırasında Manuel Testler kullanılır. İçerirler -

Birim Testleri
Entegrasyon Testleri
Fonksiyonel Testler
Fonksiyonel Olmayan Testler
Kabul testleri

Testler daha sonra sonraki çalıştırmalar için otomatikleştirilir.

İçinde Test Driven Development, Birim Testleri önce başarısız olacak şekilde yazılır, Testlerin başarılı olmasını sağlamak için Kod geliştirilir ve test edilir.

İçinde Acceptance Test Driven Development, Kabul Testleri önce başarısız olacak şekilde yazılır, Testlerin başarılı olması için Kod geliştirilir ve test edilir.

Diğer Geliştirme yöntemlerinde, Test Uzmanları, Test Kapsamını sağlamak için Ekibin geri kalanıyla işbirliği yapar.

Tüm yöntem türlerinde, sürekli entegrasyon testini içeren Sürekli entegrasyon gerçekleşir.

Ekip, ne zaman ve hangi testlerin otomatikleştirileceğine karar verebilir. Testlerin otomasyonu çaba ve zaman gerektirse bile, ortaya çıkan otomatik testler, Agile Projesinin yinelemeleri sırasında tekrarlayan test çabasını ve süresini önemli ölçüde azaltır. Bu da ekibin yeni Kullanıcı Hikayeleri, Değişiklikler vb. Gibi diğer gerekli faaliyetlere daha fazla dikkat etmesini kolaylaştırır.

İçinde Scrum, yinelemeler zaman sınırlıdır. Dolayısıyla, bir Kullanıcı Hikayesi testi belirli bir Sprint'te tamamlanamazsa, test uzmanı günlük standup toplantısında kullanıcı hikayesinin o Sprint içinde Bitti Durumuna ulaşamadığını ve bu nedenle bir sonraki Sprint için beklemede tutulması gerektiğini bildirebilir.

Test sonuçları

Çevik Projelerde Testlerin çoğu otomatik olduğundan, Araçlar gerekli Test Sonuçları Günlüklerini oluşturur. Test uzmanları, Test Sonuçları Günlüklerini inceler. Her sprint / sürüm için test sonuçlarının korunması gerekir.

Aşağıdakileri içeren bir Test Özeti de hazırlanabilir:

Test Kapsamı (Ne test edildi ve ne test edilmedi)
Mümkünse Kök Neden Analizi ile birlikte Hata Analizi
Kusur Düzeltmelerinden Sonra Regresyon Testi Durumu
Sorunlar ve ilgili Çözüm
Varsa Bekleyen Sorunlar
Test Stratejisinde gerekli herhangi bir değişiklik
Test Metrikleri

Test Metrikleri Raporları

Çevik Projelerde, Test Metrikleri her Sprint için aşağıdakileri içerir -

Test Çabası
Test Tahmin Doğruluğu
Test kapsamı
Otomatik Test Kapsamı
Kusur Sayısı
Kusur Oranı (Kullanıcı Hikaye Puanı Başına Kusur Sayısı)
Kusur Şiddeti
Aynı Sprint'te Bir Kusuru Düzeltme Süresi (Mevcut sprint'ten kaçan bir hatayı düzeltmenin maliyeti 24 kat daha fazladır)
Aynı Sprint'te düzeltilen Hata Sayısı
Sprint İçinde Müşteri Tarafından Kabul Testinin Tamamlanması

Sprint İncelemesi ve Geriye Dönük Raporlar

Test uzmanları ayrıca Sprint İnceleme ve Geriye Dönük Raporlara katkıda bulunur. Tipik içerikler -

Test Metrikleri
Test Sonuç Günlükleri inceleme sonuçları
Testing Point of View ile nelerin doğru gittiği ve nelerin geliştirilebileceği
En İyi Uygulamalar
Dersler öğrenildi
Issues
Müşteri geribildirimi

Çevik Test faaliyetleri, Kanban konseptleri kullanılarak etkili bir şekilde yönetilebilir. Aşağıdakiler, testlerin bir yineleme / sprint içinde zamanında tamamlanmasını ve böylece kaliteli ürünün teslimine odaklanılmasını sağlar.

Test edilebilir ve etkili bir şekilde boyutlandırılan Kullanıcı Hikayeleri, belirlenen süre sınırları içinde geliştirme ve test etme ile sonuçlanır.
WIP (Devam Eden Çalışma) sınırı, bir seferde sınırlı sayıda kullanıcı öyküsüne odaklanmanıza olanak tanır.
İş akışını görsel olarak temsil eden Kanban panosu, varsa test faaliyetlerini ve darboğazları takip etmeye yardımcı olur.
Kanban ekip işbirliği kavramı, darboğazların tanımlandıkları anda bekleme süresi olmadan çözülmesini sağlar.
Test Durumlarının önceden hazırlanması, geliştirme ilerledikçe test takımının sürdürülmesi ve Müşteri Geri Bildiriminin alınması, yineleme / sprint içindeki Kusurların ortadan kaldırılmasına yardımcı olur.
Bitti (DoD) Tanımı, bir Hikayenin ancak test de tamamlandıktan sonra tamamlanma durumuna gelmesi anlamında Bitti-Bitti olarak söylenir.

Ürün Geliştirmede Test Faaliyetleri

Ürün geliştirmede, sürümler Kanban panosu özelliği ile takip edilebilir. Belirli bir sürümün özellikleri, özellik geliştirme durumunu görsel olarak izleyen Özellik Kanban panosuna atanır.

Bir sürümdeki Özellikler, hikayelere ayrılmıştır ve çevik yaklaşım kullanılarak sürüm içinde geliştirilmiştir.

Aşağıdaki Çevik Test faaliyetleri, her sürümde ve tüm sürümlerin sonunda kaliteli teslimat sağlar -

Test uzmanları User Story Creation'a katılır ve böylece şunları sağlar:
- Sistemin olası tüm Davranışları, Kullanıcı Hikayeleri ve Kullanıcı Hikayelerinin bir parçası olan İşlevsel Olmayan Gereksinimler aracılığıyla yakalanır.
- Kullanıcı Hikayeleri Test Edilebilir.
- Kullanıcı Hikayelerinin boyutu, Geliştirme ve Testin Yineleme içinde tamamlanmasına (Bitti) izin verir.
Görsel Görev Kanban Panosu -
- Görevlerin durumunu ve ilerlemesini gösterir
- Darboğazlar oluştukları anda tespit edilir
- Daha sonra optimize edilebilen döngü süresinin ölçülmesini kolaylaştırır
Takım İşbirliği yardımcı olur -
- Kaliteli ürün için tüm Ekibin sorumluluğu
- Darboğazların ortaya çıktıkça çözülmesi, bekleme süresinden tasarruf sağlar
- Her uzmanlığın tüm faaliyetlere katkısı
Sürekli Entegrasyon Testine odaklanan Sürekli Entegrasyon
Test Eforu ve Zamanından Tasarruf için Testlerin Otomasyonu
Geliştiricilere daha önce yazılan Test Durumlarıyla Kusur Önleme ve Sistemin farklı davranışları tarafından beklenenler konusunda Geliştiricilere rehberlik etme -
- Bir seferde sınırlı sayıda Kullanıcı Hikayesine odaklanmak için Devam Eden Çalışma Sınırı
Yinelemede Kusur Düzeltmelerini sağlamak için Geliştirme ilerledikçe Sürekli Test -
- Test Kapsamı Sağlayın
- Açık Kusur Sayısını Düşük Tutun

Hikaye Keşfi

Story Exploration, ürün sahibi geliştirme için kabul edilmek üzere bir hikaye geçirdiğinde Hikayeyi anlamayı keşfetmek için bir Agile ekibi içindeki iletişimdir.

Ürün sahibi, sistemin beklediği işlevselliğe dayalı bir hikaye oluşturur. Geliştiriciler, kabul için hazır olarak işaretlemeden önce her bir hikayeyi daha çok araştırıyor. Test uzmanları, mümkün olduğunca test edilebilir hale getirmek için iletişime test perspektifinden de katılır.

Hikayenin sonuçlandırılması, Ürün Sahibi, Geliştiriciler ve Test Edenler arasındaki sürekli ve sürekli iletişime dayanmaktadır.

Tahmin

Tahmin, Sürüm Planlamasında ve her Yineleme Planlamasında gerçekleşir.

Sürüm Planlamada, test uzmanları şunları sağlar:

Hangi test faaliyetlerinin gerekli olduğu hakkında bilgi
Aynı şey için çaba tahmini

Yineleme planlamasında, test uzmanları bir yinelemeye hangi ve kaç öykünün dahil edilebileceğine karar vermeye katkıda bulunur. Karar, Test Eforuna ve Test Çizelgesi Tahminine bağlıdır. Hikaye Tahmini aynı zamanda test tahminini de yansıtır.

Kanban'da Bitti-Bitti, yalnızca bir hikaye geliştirilip test edildiğinde ve hatasız olarak eksiksiz olarak işaretlendiğinde gerçekleştirilir.

Bu nedenle, Test Tahmini, hikaye tahmininde önemli bir rol oynar.

Hikaye Planlama

Hikaye Planlama, bir Hikaye tahmin edildikten ve mevcut Yinelemeye atandıktan sonra başlar.

Hikaye Planlama aşağıdaki test görevlerini içerir -

Test Verilerini Hazırlayın
Kabul Testlerini Genişletin
Manuel Testleri Yürütme
Keşif Testi oturumları düzenleyin
Sürekli Entegrasyon Testlerini Otomatikleştirin

Bu Test Görevlerine ek olarak, aşağıdakiler gibi başka görevler de gerekebilir:

Performans testi
Gerileme testi
İlgili Sürekli Entegrasyon Testlerinin güncellemeleri

Hikaye İlerlemesi

Story Progression, geliştiriciler ve test uzmanları arasındaki sürekli iletişimle sonuçlanan gerekli ek testleri ortaya çıkarır. Geliştiricilerin uygulama konusunda daha fazla netliğe ihtiyaç duyduğu durumlarda, test uzmanları keşif testleri gerçekleştirir.

Sürekli Test, Öykü İlerlemesi sırasında gerçekleştirilir ve Sürekli Entegrasyon Testini içerir. Ekibin tamamı test faaliyetlerine katılır.

Hikaye Kabulü

Hikaye Kabulü, hikaye Bitti-Bitti durumuna ulaştığında gerçekleşir. yani hikaye geliştirilir, test edilir ve tamamlanmış olarak işaret edilir.

Hikaye testinin, hikaye geçme veya test otomasyon seviyesi ile ilgili tüm testler karşılandığında tamamlandığı söylenir.

Çevik Projelerde, Test Uzmanları aşağıdaki günlük görevlerden sorumludur -

Geliştiricileri, sistemin beklenen davranışına ilişkin açıklamalarla kodlamada destekleyin.
Etkili ve verimli birim testleri oluşturmada geliştiricilere yardımcı olun.
Otomasyon komut dosyaları geliştirin.
Otomasyon test araçlarını / komut dosyalarını regresyon testi için sürekli entegrasyonla entegre edin.

Bu görevlerin etkili ve hızlı bir şekilde uygulanması için, Agile projelerinin çoğunda CI of Code ve test bileşenlerini destekleyen bir Sürekli Entegrasyon (CI) sistemi kullanılır.

Agile projelerindeki test uzmanları ve geliştiriciler, test oturumlarını yönetmek ve Kusur raporları oluşturmak ve göndermek için çeşitli araçlardan yararlanabilir. Çevik testler için özel araçlara ek olarak, çevik ekipler ayrıca test otomasyonu ve test yönetimi araçlarından da yararlanabilir.

Note - Kayıt ve Oynatma, Test Sonu, Ağır Siklet ve Test Otomasyonu Çözümleri -

Bu tür araçların teşvik ettiği son test iş akışı, Agile ekipleri için çalışmaz.
Bu tür araçlarla oluşturulan sürdürülemez komut dosyaları, değişime engel olur.
Bu tür özel araçlar, Test otomasyonu uzmanlarına ihtiyaç yaratır ve böylece siloları besler

Yaygın olarak kullanılan araçlar şunlardır:

S.No.	Araç ve Amaç
1	Hudson CI Çerçevesi
2	Selenium Fonksiyonel Test - Hudson ile Entegre
3	CruiseControl CI Çerçevesi
4	Junit Java Birim Testi
5	Nunit .Net Birim Testi
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Java Test Kapsamı
7	Jester Java - Mutasyon Testi / Otomatik Hata Tohumlama
8	Gretel Java Test Kapsamı İzleme Aracı
9	TestCocoon C / C ++ veya C # - Gereksiz Testler bularak Testlerin miktarını azaltır ve Ölü Kodu bulur
10	JAZZ Java - Dallanma, Düğüm ve Defuse Kapsamı ve bir GUI, Test Planlayıcıları, Dinamik Enstrümantasyon ve Test Analizcisi uygular
11	Ant Java - Otomasyon Oluşturma
12	Nant .Net - Otomasyon Derlemesi
13	Bonfire JIRA için Çevik Test eklentisi

Çevik Test Otomasyon Araçları

Etkili Çevik test otomasyon araçları desteği -

Önce test yaklaşımı kullanarak erken test otomasyonu.
Gerçek diller, alana özel diller kullanarak test otomasyon kodu yazma.
Sistemin beklenen davranışına odaklanmak.
Testin özünü uygulama detaylarından ayırarak, Teknolojiden bağımsız hale getirir.
İşbirliğini Teşvik Etmek.

Otomatik Birim Testleri (Junit veya NUnit kullanarak) kodlama için önce test yaklaşımını destekler. Bunlar beyaz kutu testleridir ve tasarımın sağlam olmasını ve herhangi bir kusur olmadığını garanti eder. Bu tür testler, test uzmanlarının desteğiyle geliştiriciler tarafından oluşturulur ve gerekli işlevsellikten bağımsız olabilir. Bu, müşteri gereksinimlerini karşılamayan ve dolayısıyla ticari değeri olmayan bir ürün teslimiyle sonuçlanır.

Bu endişe, müşteri, diğer paydaşlar, test uzmanları ve geliştiricilerin işbirliği ile yazılan Kabul Testlerini otomatikleştirerek giderilir. Otomatik Kabul Testleri, ürünün beklenen davranışını yansıtan müşteriler veya ürün sahipleri / iş analistleri tarafından yazılır. Geliştiricilerin katılımı, gereksinimlere göre kod üretimini sağlar. Bununla birlikte, test yalnızca kabule odaklanırsa, ortaya çıkan kod genişletilemez kalabilir.

Bu nedenle, Otomatik Birim Testleri ve Otomatik Kabul Testleri ücretsizdir ve Çevik Geliştirmede her ikisi de gereklidir.

Otomatik Kabul Testini destekleyen Çevik Araçlar ve Çerçeveler şunlardır:

Fit
Fitnesse
Concordion
Ruby
Cucumber

Uygun

Ward Cunningham, Kabul Testi Otomasyonu için kullanılabilecek Fit aracını geliştirdi. Fit izin verir -

Müşteriler veya Ürün Sahipleri, Microsoft Word ve Microsoft Excel kullanarak ürün davranışına örnekler verir.
Programcılar bu örnekleri kolayca otomatik testlere dönüştürür.

Fit 1.1 hem Java'yı hem de .NET'i destekler.

FitNesse

FitNesse, herhangi bir ziyaretçinin mevcut sayfaları değiştirmek ve yeni sayfalar oluşturmak da dahil olmak üzere herhangi bir düzenleme yapmasına izin veren bir web sunucusu stili olan bir wiki'dir. Basit bir biçimlendirme dili, kolayca başlık oluşturmanıza, metni kalın, altı çizili ve italik yapmanıza, madde işaretli listeler oluşturmanıza ve diğer basit biçimlendirme türlerini yapmanıza olanak tanır.

FitNesse'de Kabul Test Otomasyonu aşağıdaki gibidir -

Testleri girdi verileri ve beklenen çıktı verileri tabloları olarak ifade edin.
Düzenleyebileceğiniz sayfaya test tablosunu yerleştirmek için FitNesse'i kullanın.
- Alternatif olarak, test tablosunu Microsoft Excel'e koyun, panoya kopyalayın ve ardından Spreadsheet to FitNesse FitNesse'nin tablonuzu düzgün biçimlendirmesi için komut
Testi çalıştırın
Test sonuçlarını, test tablosundaki hücrelerin renk kodlamasıyla alırsınız.
- yeşil hücreler beklenen değerlerin elde edildiğini gösterir
- kırmızı hücreler, beklediğinizden farklı bir değer elde edildiğini gösterir
- sarı hücreler bir istisna atıldığını gösterir

Salatalık

Hıyar, Davranış Odaklı Geliştirme (BDD) çerçevesine dayalı bir araçtır. Temel özellikler şunlardır:

Web uygulamaları için kabul testleri yazmak için kullanılır.
Basit İngilizce gibi kolayca okunabilir ve anlaşılabilir bir biçimde işlevsel doğrulamanın otomasyonuna izin verir.
Ruby'de uygulandı ve ardından Java çerçevesine genişletildi. Her ikisi de Junit'i destekliyor.
Perl, PHP, Python, .Net gibi diğer dilleri destekler.
Selenium, Watir, Capybara vb. İle birlikte kullanılabilir.