Menü

Test Uzmanları TDD, BDD ve ATDD Tekniklerine Nasıl Dahil Edilir?

  • Ana
  • Çevik Test
  • Test Uzmanları TDD, BDD ve ATDD Tekniklerine Nasıl Dahil Edilir?

how testers are involved tdd

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

TDD, BDD ve ATDD tekniklerine genel bakış:

TDD, BDD ve ATDD, test edenin Agile dünyasında devrim yaratan ve aynı zamanda ivme kazanan terimlerdir. Test uzmanlarının zihniyetindeki değişim aynı zamanda yeni beceriler öğrenmeyi ve daha da önemlisi tutum ve çalışma şeklini değiştirmeyi gerektirir.

Tek başına çalışmanın aksine, test uzmanlarının programcılarla işbirliği yapması ve birlikte çalışması gerekir.

  • Test senaryolarının paylaşılması
  • Hikayelerin kabul kriterlerini yazmaya katılmak
  • Paydaşlara sürekli geri bildirim sağlamak
  • Kusurları zamanında çözmek için işbirliği yapmak.
  • Çıktıların kalitesini iyileştirmek için öneri ve girdi sağlayın
  • Otomasyon

Agile ile İlgili Test Uzmanları

Bir test uzmanının bu uygulamalara katılımına ilişkin tartışmaya geçmeden önce, önce bu terimlerin arkasındaki kavramları anlamaya çalışalım:

Ne öğreneceksin:

Test Odaklı Geliştirme

Kodun önce yazıldığı ve sonra test edildiği geleneksel yazılım geliştirme yaklaşımını düşünün. Test odaklı geliştirme veya TDD, geleneksel geliştirmenin tam TERSİNİ olan bir yaklaşımdır. Bu yaklaşımda önce test yapılır ve ardından kod yazılır.

Şaşkın?!!

Henüz geliştirilmemiş bir yazılımı nasıl test edebiliriz?

Evet!! Bu, test odaklı geliştirme veya TDD'dir.

TDD, aşağıdaki durumlarda küçük artışlarla çalışır:

  • Önce test yazılır
  • Test gerçekleştirilir - başarısız olur (bariz nedenlerden dolayı)
  • Kod, yalnızca test senaryosunun geçmesi için yazılır (veya yeniden düzenlenir)
  • Test tekrar yapılır
  • Test başarılı olursa, bir sonraki teste geçin ELSE, testi geçmesi için kodu yeniden yazın / değiştirin

Bunu bir akış şemasıyla açıklamaya çalışayım:

TDD Akış Şeması

Şimdi, TDD'nin testçilerin yaptığı testlerden bahsetmediğini anlamalıyız. Aksine, bu yaklaşım aslında programcıların yaptığı testlerden bahsediyor.

Evet!! Doğru tahmin ettin !! Birim testidir.

İlk yazılan test, test edenlerin yazdığı test değil, programcıların yazdığı birim testtir. Bu nedenle, adımları şu şekilde yeniden ifade ederim:

  • UNIT testi önce yazılır
  • UNIT testi yürütülür - başarısız olur (bariz nedenlerden dolayı)
  • Kod, yalnızca testi geçmesi için yazılır (veya yeniden düzenlenir)
  • UNIT testi tekrar yürütülür
  • Test başarılı olursa, sonraki teste geçin ELSE testi geçmesi için kodu yeniden yazın / değiştirin

Şimdi, burada ortaya çıkan soru şudur: TDD bir programcının işi ise, bu yaklaşımda test edenin rolü nedir?

Eh, TDD'nin bir programcının işi olduğunu söylemiş olmak, testçilerin buna dahil olmadığı anlamına gelmez. Test uzmanları, aşağıdakilerden oluşan test senaryolarını paylaşarak işbirliği yapabilir:

Demek istediğim, test uzmanları birim test senaryolarının tanımlanmasına katılmalı ve bunları uygulamak için programcılarla işbirliği yapmalıdır. Test uzmanları, test sonuçları hakkında geri bildirimde bulunmalıdır.

TDD'yi uygulamak istiyorsak, testçilerin beceri setlerini yükseltmeleri gerekir. Daha teknik olmaları ve analitik ve mantıksal becerilerini geliştirmeye odaklanmaları gerekir.

Test uzmanları ayrıca programcıların kullandığı teknik jargonu anlamak için çaba göstermeli ve mümkünse kodu kuş bakışı görmelidir. Benzer bir şekilde, programcılar test edenin yerine geçmeli ve birim testini daha sağlam ve sağlam hale getirecek daha karmaşık senaryolar bulmaya çalışmalıdır.

Programcıların birim testlerine fazla ağırlık vermedikleri eski geleneksel yaklaşımın aksine, hem programcılar hem de test ediciler, hata ve kusurları bulmak için test cihazlarına güvendikleri ve test uzmanlarının kendilerini şımartmak istemedikleri eski geleneksel yaklaşımdan farklı olarak birbirlerinin yerine geçmelidir. Kusurları bulduktan sonra işlerinin bittiğini düşündükleri için teknik konuları öğreniyorlar.

Davranış Odaklı Geliştirme

Davranış Odaklı Geliştirme veya BDD, Test Odaklı Geliştirmenin bir uzantısıdır.

BDD, adından da anlaşılacağı gibi, davranışına göre bir özellik geliştirme yöntemlerini göstermektedir. Davranış, temelde, geliştirmeden sorumlu ekipteki herkes tarafından anlaşılabilecek çok basit bir dille örneklerle açıklanır.

BDD'nin temel özelliklerinden bazıları şunlardır:

  • Davranışı tanımlamak için kullanılan dil çok basittir ve herkes tarafından anlaşılabileceği tek bir formattadır - hem teknik hem de teknik olmayan kişiler tarafından uygulamaya dahil edilir.
  • Üç amigonun (programcı, test cihazı ve PO / BA) işbirliği yapmasını ve gereksinimi anlamasını sağlayan bir platform sunar. Belgelemek için ortak bir şablon belirler
  • Bu teknik / yaklaşım, sistemin son davranışını veya sistemin nasıl davranması gerektiğini tartışır ve sistemin nasıl tasarlanması veya uygulanması gerektiğinden bahsetmez.
  • Kalitenin her iki yönünü de vurgular:
    • Gereksinimi karşılayın
    • Kullanıma uygun

Neden BDD?

Bir kusuru düzeltmenin / böcek herhangi bir geliştirme döngüsünün sonraki aşamasında oldukça maliyetlidir. Üretim hatalarının düzeltilmesi sadece kodu değil, aynı zamanda tasarımı ve gereksinimlerini de etkiler. Yaptığımız zaman RCA (Kök Neden Analizi) Çoğu zaman herhangi bir kusurda, kusurun aslında yanlış anlaşılan gereksinimlere dönüştüğü sonucuna varıyoruz.

Bu temelde herkesin gereksinimleri anlamak için farklı yetenekleri olduğu için olur. Bu nedenle, teknik ve teknik olmayan kişiler aynı gereksinimi farklı yorumlayabilir ve bu da hatalı bir teslimata yol açabilir. Bu nedenle, geliştirme ekibindeki herkesin AYNI gereksinimini anlaması ve AYNI şekilde yorumlaması çok önemlidir.

Tüm geliştirme çabalarının gereksinimleri karşılamaya yönelik olduğundan ve odaklanıldığından emin olmalıyız. Herhangi bir 'gereksinim - kaçırma' kusurundan kaçınmak için, tüm geliştirme ekibinin bunları kullanıma uygun gereksinimi anlayacak şekilde hizalaması gerekir.

BDD yaklaşımı, geliştirme ekibinin şunları yapmasını sağlar: -

  • Gereksinimi basit bir İngilizce ile tanımlamak için standart bir yaklaşım tanımlama
  • Gereklilikleri açıklayan örneklerin tanımlanmasının sağlanması
  • Teknik (programcılar / testçiler) ve teknik olmayanların (PO / BA / Müşteri) işbirliği yapmasını ve bir araya gelmesini ve gereksinimleri anlamak ve uygulamak için aynı sayfada olmasını sağlayan bir arayüz / platform sağlayın

BDD Nasıl Uygulanır?

BDD'yi uygulamak için piyasada birçok araç bulunmaktadır. Burada birkaçını adlandırıyorum:

  • Salatalık
  • Fitness
  • Konkordiyon
  • JBehave
  • Spec Akışı

Misal:

BDD'yi bir örnekle anlamaya çalışalım. Benim durumum için Gherkin (Salatalık) kullanıyorum:

Yalnızca kimliği doğrulanmış kullanıcıların XYZ sitesine girmesine izin vermek istediğimiz basit bir durumu düşünün.

Gherkin dosyası (özellik dosyası) aşağıdaki gibi olacaktır:

Özellik: Test kayıt portalı

Senaryo Özeti: Geçerli kullanıcı oturum açmış

Verilen: Müşteri kayıt portalını açar

Ne zaman: kullanıcı, kullanıcı adını '' ve şifreyi '' olarak girer

Sonra: müşteri formu görüntüleyebilmelidir.

Örnekler :

| kullanıcı | şifre |

| kullanıcı1 | pwd1 |

| kullanıcı2 | pwd2 |

Basit bir İngilizce kullanarak belirli bir gereksinimin nasıl belgelendiğini görebiliriz. Üç amigo, özellik dosyalarını tasarlamak için birlikte çalışabilir ve belirli test verileri örnek bölümünde belgelenebilir. BDD, programcıları, test uzmanlarını ve işletmeyi tek bir masaya getirmek ve uygulanacak özelliklerle ilgili ortak bir anlayış oluşturmak için bir ortam sağlar.

Müşterilerin ve geliştiricilerin işbirliği özelliğin geliştirme döngüsü boyunca devam ettiğinden, BDD yaklaşımı çaba ve maliyetlerden tasarruf sağlar ve üretim dağıtımından sonra herhangi bir kusur olup olmadığını kontrol eder.

Geliştirme ekipleri bu özellik dosyalarını kullanabilir ve belirli bir özelliği test etmek için bunları çalıştırılabilir programlara dönüştürebilir.

Nasıl?

Bunun için Salatalık / Fitnesse öğrenmelisin !!

Kabul Testi Güdümlü Geliştirme

Kabul Testi Güdümlü Geliştirme veya ATDD, uygulama fiilen başlamadan önce bir destanın / hikayenin kabul kriterlerini tanımlamak için tüm ekibin işbirliği yaptığı bir tekniktir. Bu kabul testleri, uygun örnekler ve diğer gerekli bilgilerle desteklenir.

Çoğu zaman BDD ve ATDD birbirinin yerine kullanılır. ATDD yaklaşımı, BDD yaklaşımında özellikleri nasıl yazdığımız gibi, O Zaman Verildi formatı kullanılarak da uygulanabilir.

3 yaklaşım arasındaki farkları hızlıca özetlemeye çalışalım:

  • TDD daha tekniktir ve özelliğin uygulandığı aynı dilde yazılmıştır. Özellik Java'da uygulanıyorsa, JUnit yazarız test durumları . BDD & ATDD ise basit İngilizce dilinde yazılmıştır
  • TDD yaklaşımı, bir özelliğin uygulanmasına odaklanır. BDD, özelliğin davranışına odaklanırken, ATDD gereksinimleri yakalamaya odaklanır.
  • TDD'yi uygulamak için teknik bilgiye sahip olmamız gerekir. BDD & ATDD ise herhangi bir teknik bilgi gerektirmez. BDD / ATDD'nin güzelliği, bu özelliği geliştirmeye hem teknik hem de teknik olmayan kişilerin katılabilmesinde yatmaktadır.
  • TDD geliştiğinden, iyi tasarım için kapsam sağlar ve kalitenin 'Gereksinimi Karşılama' yönüne odaklanır; BDD / ATDD 2'ye odaklanırkenndkalitenin 'kullanıma uygun' yönü

Tüm bu teknikler, geleneksel geliştirme metodolojilerinde kullanılan 'son test' yaklaşımının aksine, temelde 'önce test' yaklaşımından bahseder.

Testler önce yazıldığı için test uzmanları çok önemli bir rol oynar. Test uzmanlarının yalnızca geniş bir etki alanına ve iş bilgisine sahip olmaları değil, aynı zamanda 3 amigo tartışması sırasında beyin fırtınasına değer katabilmeleri için iyi teknik becerilere sahip olmaları da gerekir.

CI (Continuous Integration) ve CD (Continuous Delivery) gibi kavramlarla, test uzmanlarının programcılarla iyi işbirliği yapması ve geliştirme ve operasyon alanına eşit şekilde katkıda bulunması gerekir.

e-posta şifre kırıcı çevrimiçi hack aracı

Bu tartışmayı Agile'deki ünlü Test Piramidi ile özetleyeyim:

Piramidi Çevik olarak Test Edin

Bu piramidin en alt katmanı, birim test katmanından oluşur. Bu katman temel katmandır; bu nedenle bu katmanın kaya gibi sağlam olması emperyaldir. Testlerin çoğu bu katmana itilmelidir. Bu en alt katman yalnızca TDD'ye odaklanır.

İçinde Çevik Dünyada, piramidin bu katmanının daha güçlü ve sağlam olmasına vurgu yapılır ve testin çoğunun bu katmanda gerçekleştirildiği vurgulanır.

Bir piramidin bu katmanında kullanılan araçların tümü Xunit araçlarıdır.

Piramidin orta katmanı, servis seviyesi testlerini açıklayan servis katmanıdır. Bu katman, uygulama kullanıcı arayüzü ile alt seviye birim / bileşen arasında bir köprü görevi görür. Bu katman, çoğunlukla kullanıcı arayüzünden gelen istekleri kabul eden ve yanıtı geri gönderen API'lerden oluşur. BDD ve TTDD yaklaşımı piramidin bu katmanında aktiftir.

Piramidin orta katmanında kullanılan araçlar şunlardır: Fitnesse, Cucumber ve Robot Framework .

Piramidin en üst katmanı, bu katmanın en az sayıda test içermesi gerektiğini gösteren gerçek kullanıcı arayüzüdür veya söylemeliyim ki, bu belirli katmandaki test çabası minimum olmalıdır. Özelliğin testlerinin çoğu, piramidin en üst katmanına ulaştığımızda tamamlanmış olmalıydı.

Üst katmanda kullanılan araçlar - Selenyum , QTP ve RFT.

Küçük artışlarla çalıştığımız için Scrum (Sprint olarak adlandırılır), tüm bu yaklaşımların manuel olarak uygulanması mümkün değildir. Bu yaklaşımlar otomatik müdahale gerektirir. Bu durumda otomasyon çok kritiktir.

Aslında, bu yaklaşımlar aslında otomasyon yoluyla yürütülmektedir. Her sprint sonunda yeni özellikler ekleniyor, bu nedenle önceden uygulanan özelliğin beklendiği gibi çalışması önemli hale geliyor; dolayısıyla Otomasyon burada KAHRAMAN olur.

Sonuç

Makalenin sonunda, Test Uzmanlarının TDD, BDD ve ATDD Tekniklerine Nasıl Dahil Olduğunu öğrenmiş olmalısınız.

Serinin üçüncü bölümünde, tartışmamı Çevik bir dünyada otomasyona odaklayacağım.

Yazar hakkında: Bu makale STH Yazarı Shilpa'ya aittir. İnternet reklamcılığı, Yatırım Bankacılığı, Telekom gibi alanlarda son 10 yılı aşkın süredir yazılım test alanında çalışmaktadır.

Daha fazla güncelleme için bu alanı izlemeye devam edin.

Önerilen Kaynaklar

^