Daha İyi Çevik Teste Giden Yol

Capgemini tarafından oluşturulan yıllık Dünya Kalite Raporu, ankete katılanların %42'sinin "profesyonel test uzmanlığı eksikliğini" Çevik geliştirmeye test uygularken bir zorluk olarak belirttiğini gösteriyor. Çevikliğin ortaya çıkışı, yazılım geliştirme için artan yineleme hızını beraberinde getirmiş olsa da, bazı durumlarda bu, kalite pahasına olmuştur.

Şiddetli rekabet, ekipleri sürekli olarak yeni ürün güncellemeleri sunmaya zorluyor, ancak bu bazen teste gösterilen ilginin azalması da dahil olmak üzere kendi maliyetini beraberinde getiriyor. Rob Mason gibi bazıları daha da ileri giderek Agile'ın yazılım testlerini öldürdüğünü iddia ediyor. Son zamanlarda Facebook, kaliteden ödün verme cazibesini ortadan kaldırmak için sloganını "hızlı hareket et ve bir şeyleri kır" yerine "sağlam altyapı ile hızlı hareket et" olarak değiştirdi.

Peki, test, Çevik yazılım geliştirmenin yeni dünyasına nasıl daha iyi entegre edilebilir? Çevik testler.

Geleneksel testler oldukça zahmetlidir ve çok sayıda belgeye bağlıdır. Çevik test, Çevik yazılım geliştirme ilkelerini taklit eden test sürecine yönelik bir yaklaşımdır ve bu sayede:

• Test çok daha sık yapılır,
• Test, belgelere daha az, ekip üyelerinin işbirliğine daha çok dayanır ve
• Bazı test faaliyetleri yalnızca test uzmanları tarafından değil, geliştiriciler tarafından da üstlenilir.

Son yedi yılda, birçok ekibi Çevik teste geçirdim ve süreçlerinin yeni metodolojiye uymasına yardımcı olmak için test uzmanlarıyla yan yana çalıştım. Bu yazıda, daha iyi Çevik test etme yolum boyunca öğrendiğim en etkili ipuçlarından bazılarını paylaşacağım. Çevik uygulamalarda hız ve kalite arasında sürtüşme olması doğal olsa da bu makale, çeviklikten ödün vermeden test kalitesini artırmak için kullanılabilecek birkaç tekniği ele alacaktır. Burada özetlenen önerilerin çoğu ekibin katılımını gerektirecektir, bu nedenle hem geliştiricilerin hem de testçilerin planlamaya katılması faydalı olacaktır.

Bir Yayın Testi Döngüsü Sürecini Resmileştirin

Testle ilgili bir sorun, sürüm testi döngüsünün olmaması, sürüm planının olmaması veya düzensiz test istekleridir. İsteğe bağlı test talepleri, özellikle test uzmanları birden fazla projeyi yürütüyorsa, KG sürecini zorlaştırır.

Birçok takım, her sprintten sonra yalnızca tek bir derleme yapar ve bu, Çevik projeler için ideal değildir. Haftada bir sürümlere geçmek, kademeli olarak haftada birden çok yapıya geçmek faydalı olabilir. İdeal olarak, geliştirme derlemeleri ve testlerin günlük olarak gerçekleştirilmesi gerekir; bu, geliştiricilerin her gün depoya kod göndermesi ve derlemelerin belirli bir zamanda çalışacak şekilde programlanması anlamına gelir. Bunu bir adım daha ileri götürmek için geliştiriciler, talep üzerine yeni kod dağıtabilecekler. Bunu uygulamak için ekipler sürekli bir entegrasyon ve sürekli dağıtım (CI/CD) süreci kullanabilir. CI/CD, büyük bir yayın gününde başarısız bir derleme olasılığını sınırlar.

CI/CD ve test otomasyonu birleştirildiğinde, kritik hataların erken tespiti mümkündür ve geliştiricilerin, planlanmış istemci sürümünden önce kritik hataları düzeltmek için yeterli zamana sahip olmalarını sağlar. Agile ilkelerinden biri, çalışan yazılımın ilerlemenin birincil ölçüsü olduğunu belirtir. Bu bağlamda, resmileştirilmiş bir sürüm döngüsü, test sürecini daha çevik hale getirir.

Dağıtım Araçları ile Test Kullanıcılarını Güçlendirin

Test için yaygın olarak karşılaşılan sorunlardan biri, kodun bir hazırlama ortamına dağıtılmasıdır. Bu süreç, ekibinizin etkileyemeyeceği teknik altyapıya bağlıdır. Bununla birlikte, biraz esneklik varsa, testçiler veya proje yöneticileri gibi teknik olmayan kişiler için, kendilerini test etmek için güncellenmiş kod tabanını dağıtmalarına izin verecek araçlar oluşturulabilir.

Örneğin, ekiplerimden birinde sürüm kontrolü için Git ve iletişim için Slack kullandık. Geliştiriciler Git'e, dağıtım komut dosyalarına ve bir sanal makineye erişimi olan bir Slackbot oluşturdu. Test kullanıcıları, GitHub veya Jira'dan alınan bir dal adıyla bota ping atabildi ve onu bir hazırlama ortamında konuşlandırdı.

Bu kurulum, geliştiriciler için çok zaman kazandırırken, iletişim israfını ve testçilerin geliştiricilerden test için bir dal dağıtmalarını istemesi gerektiğinde sürekli kesintileri azaltır.

TDD ve ATDD ile deney yapın

Test odaklı geliştirme (TDD), kaliteye çok önem veren bir tür yazılım geliştirme sürecidir. Geleneksel olarak, bir geliştirici kod yazar ve ardından biri bunu test eder ve herhangi bir hata bulunup bulunmadığını bildirir. TDD'de geliştiriciler, bir kullanıcı hikayesini tamamlayacak herhangi bir kod yazmadan önce birim testleri yazarlar. Testler başlangıçta, geliştirici testleri geçmek için minimum miktarda kod yazana kadar başarısız olur. Bundan sonra kod, ekibin kalite gereksinimlerini karşılamak için yeniden düzenlenir.

Kabul testi güdümlü geliştirme (ATDD), TDD ile benzer bir mantığı takip eder, ancak adından da anlaşılacağı gibi, kabul testlerine odaklanır. Bu durumda, geliştiriciler, testçiler ve istek sahibi (müşteri, ürün sahibi, iş analisti vb.) ile işbirliği içinde geliştirme öncesinde kabul testleri oluşturulur. Bu testler, herhangi bir kod yazılmadan önce ekipteki herkesin müşterinin gereksinimlerini anlamasına yardımcı olur.

TDD ve ATDD gibi teknikler, test prosedürlerini geliştirme yaşam döngüsünün ilk aşamalarına taşıyarak testi daha çevik hale getirir. Test senaryolarını erken yazarken, geliştiricilerin gereksinimleri gerçekten iyi anlamaları gerekir. Bu, gereksiz kod oluşturmayı en aza indirir ve ayrıca geliştirme döngüsünün başlangıcındaki ürün belirsizliklerini de çözer. Ürünle ilgili sorular veya çelişkiler ancak sonraki aşamalarda ortaya çıktığında, geliştirme süresi ve maliyetleri artar.

Görev Kartı Hareketini İzleyerek Verimsizlikleri Keşfedin

Ekiplerimden birinde, özellikle küçük özelliklerle son derece hızlı olan bir geliştiricimiz vardı. Kod incelemesi sırasında çok fazla yorum alırdı, ancak Scrum ustamız ve ben bunu deneyim eksikliği olarak yazdık. Ancak daha karmaşık özellikleri kodlamaya başladıkça sorunlar daha belirgin hale geldi. Tamamen hazır olmadan önce test etmek için bir kod geçiş modeli geliştirmişti. Bu model tipik olarak geliştirme sürecinde şeffaflık olmadığında gelişir; örneğin, farklı insanların belirli bir görev için ne kadar zaman harcadıkları net değildir.

Bazen geliştiriciler, özellikleri mümkün olan en kısa sürede çıkarmak ve kaliteyi testçilere "dış kaynak sağlamak" amacıyla çalışmalarını hızlandırır. Böyle bir kurulum, darboğazı yalnızca sprintte daha da aşağılara taşır. Kalite güvencesi (QA), ekibin sahip olduğu en önemli güvenlik ağıdır, ancak bu, QA'nın varlığının geliştiricilere kalite hususlarından vazgeçme yeteneği verdiği anlamına gelebilir.

Pek çok modern proje yönetimi aracı, bir Scrum veya Kanban panosundaki görev kartlarının hareketini izleme yeteneklerine sahiptir. Bizim durumumuzda, söz konusu geliştiricinin görevlerinde neler olduğunu analiz etmek için Jira'yı kullandık ve ekipteki diğer geliştiricilerle karşılaştırmalar yaptık. Şunu öğrendik:

• Görevleri, kurulumuzun test sütununda neredeyse iki kat daha fazla zaman harcadı;
• Görevleri, ikinci veya üçüncü bir düzeltme turu için QA'dan çok daha sık iade edilirdi.

Bu nedenle, testçilerin görevlerine daha fazla zaman harcaması dışında, aynı zamanda bunu birden çok kez yapmaları gerekiyordu. Opak sürecimiz, geliştiricinin gerçekten hızlı olduğunu gösteriyordu; ancak test süresini hesaba kattığımızda bunun yanlış olduğu ortaya çıktı. Kullanıcı hikayelerini ileri geri taşımak kesinlikle yalın bir yaklaşım değildir.

Bunu çözmek için bu geliştiriciyle dürüst bir tartışma yaparak başladık. Bizim durumumuzda, çalışma düzeninin ne kadar zararlı olduğunun farkında değildi. Daha düşük kalite gereksinimlerine ve daha büyük bir testçi havuzuna sahip olan önceki şirketinde çalışmaya böyle alışmıştı. Konuşmamızdan sonra ve Scrum ustamızla birkaç çift programlama seansının yardımıyla, yavaş yavaş daha yüksek kaliteli bir geliştirme yaklaşımına geçiş yaptı. Hızlı kodlama yetenekleri nedeniyle, hala yüksek bir performans sergiledi, ancak QA sürecinin ortadan kaldırılan “atıkları”, tüm test sürecini çok daha çevik hale getirdi.

QA Ekibi Beceri Setine Test Otomasyonu ekleyin

Çevik olmayan projelerde test etme, test analizi, test tasarımı ve test yürütme gibi etkinlikleri içerir. Bu faaliyetler sıralıdır ve kapsamlı dokümantasyon gerektirir. Bir şirket Çevik'e geçtiğinde, çoğu zaman geçiş, test yapanlara değil, çoğunlukla geliştiricilere odaklanır. Kapsamlı belgeler oluşturmayı bırakırlar (geleneksel testlerin bir direği) ancak manuel test yapmaya devam ederler. Ancak manuel test yavaştır ve tipik olarak Agile'ın hızlı geri bildirim döngüleriyle baş edemez.

Test otomasyonu bu soruna popüler bir çözümdür. Otomatik testler, geliştiriciler ve testçiler diğer görevlere odaklanırken test kodu arka planda çalışabileceğinden, yeni ve küçük özellikleri test etmeyi çok daha kolay hale getirir. Ayrıca testler otomatik olarak yapıldığından, test kapsamı manuel test çalışmalarına kıyasla çok daha büyük olabilir.

Otomatik testler, test edilmekte olan kod tabanına benzer yazılım kodu parçalarıdır. Bu, otomatik testler yazan kişilerin başarılı olmak için teknik becerilere ihtiyaç duyacağı anlamına gelir. Farklı ekipler arasında otomatikleştirilmiş testin nasıl uygulandığına dair birçok farklı varyasyon vardır. Bazen geliştiricilerin kendileri testçi rolünü üstlenir ve her yeni özellikle test kod tabanını artırır. Diğer ekiplerde, manuel test uzmanları test otomasyon araçlarını kullanmayı öğrenir veya test sürecini otomatikleştirmek için deneyimli bir teknik test uzmanı işe alınır. Ekip hangi yolu seçerse seçsin, otomasyon çok daha çevik testlere yol açar.

Test Önceliklerini Yönetin

Çevik olmayan yazılım geliştirmede, test kullanıcıları genellikle proje bazında tahsis edilir. Ancak, Agile ve Scrum'ın ortaya çıkmasıyla, aynı QA profesyonellerinin birden fazla projede çalışması yaygınlaştı. Bu örtüşen sorumluluk, programlarda çelişkiler yaratabilir ve bir testçi bir ekibin sürüm testine diğerinin sprint planlama oturumuna göre öncelik verdiğinde testçilerin kritik törenleri kaçırmasına neden olabilir.

Test uzmanlarının bazen birden fazla proje üzerinde çalışmasının nedeni açıktır - tam zamanlı bir rolü doldurmak için test için nadiren sürekli bir görev akışı vardır. Bu nedenle, paydaşları bir ekibe tahsis edilmiş özel bir test kaynağına sahip olmaya ikna etmek zor olabilir. Bununla birlikte, bir test uzmanının, test faaliyetlerine katılmadığı zamanlarda kapalı kalma sürelerini doldurmak için yapabileceği bazı makul görevler vardır.

Müşteri Desteği

Olası bir kurulum, testçinin sprint kesinti süresini müşteri destek ekibine yardım ederek geçirmesidir. Test uzmanı, müşterilerin yaşadığı sorunlarla sürekli olarak yüzleşerek, kullanıcı deneyimini ve nasıl iyileştirileceğini daha iyi anlıyor. Planlama oturumları sırasında tartışmalara katkıda bulunabilirler. Ayrıca, müşterilerin yazılımlarını gerçekte nasıl kullandıklarına daha iyi aşina olduklarından, test faaliyetleri sırasında daha dikkatli olurlar.

Ürün Yönetimi

Test kullanıcısı önceliklerini yönetmek için başka bir teknik, onları manuel test gerçekleştiren genç ürün yöneticileri yapmaktır. Bu, aynı zamanda, bir testçinin görev dışı zamanını doldurmak için uygun bir çözümdür, çünkü genç ürün yöneticileri, kullanıcı hikayeleri için gereksinimler oluşturmak için çok zaman harcarlar ve bu nedenle çoğu görev hakkında derin bilgiye sahiptirler.

Test Otomasyonu

Daha önce tartıştığımız gibi, manuel test genellikle otomasyondan daha düşüktür. Bu bağlamda, otomasyona yönelik baskı, bir test uzmanının tüm dikkatini ekibe ayırması ve boş zamanlarını Selenium gibi test otomasyon araçlarıyla çalışmak için öğrenmesi ile birleştirilebilir.

Özet: Kalite Çevik Testi

Testi daha çevik hale getirmek, birçok yazılım geliştirme ekibinin şu anda karşı karşıya olduğu kaçınılmaz bir durumdur. Ancak “olabildiğince hızlı test edin” zihniyeti benimsenerek kaliteden ödün verilmemelidir. Çevik bir geçişin Çevik teste geçişi içermesi zorunludur ve bunu başarmanın birkaç yolu vardır:

• Bir sürüm testi döngüsü sürecini resmileştirin.
• Dağıtım araçlarıyla test cihazlarını güçlendirin.
• Test odaklı geliştirme ve kabul testi odaklı geliştirme ile denemeler yapın.
• Görev kartı hareketini izleyerek verimsizlikleri keşfedin.
• QA ekibi beceri setine test otomasyonu ekleyin.
• Test kullanıcısı önceliklerini yönetin.

Her yıl yazılımlar daha iyi hale geliyor ve kullanıcı beklentileri artıyor. Ayrıca müşteriler Google, Apple ve Facebook gibi önde gelen yazılım markalarının yüksek kaliteli ürünlerine alıştıkça bu beklentiler diğer yazılım ürünlerine de yansıyor. Bu nedenle, kaliteye verilen önem önümüzdeki yıllarda daha da önem kazanacaktır. Bu testler ve genel geliştirme süreci iyileştirmeleri, testleri daha çevik hale getirebilir ve yüksek düzeyde ürün kalitesi sağlayabilir.