Aynı sprint içinde kodlama ve test

Kodlamanın tamamı veya çoğu, sprint sonuna kadar yapılmazsa, kodlama ile aynı sprint içinde test nasıl yapılır? (Sprint içinde tek bir PBI'nin "çorbadan kuruyemiş" gelişimi ve testine atıfta bulunuyorum.)

Çevrimiçi olarak gördüğüm cevapların çoğu QA otomasyonunu içeriyor, ancak bu otomatik olarak test etmek veya kaydetmek için genellikle işlevsel bir UI'ye ihtiyacınız olduğundan gerçekten mümkün değil. Yalnızca özellikler geliştirip yeni gereksinimleri keşfettiğimde gelişmeye devam eden storyboard'larım var.

Benim durumumda yeni bir masaüstü uygulaması geliştiriyorum. Masaüstü uygulamaları genellikle otomatik testleri çok iyi bir şekilde ödünç vermez. Bazı otomatik birim testlerim var, ancak bunlar bir QA uzmanının gerçekleştireceği manuel fonksiyonel / entegrasyon testleri değil.

Yani, şu an nerede olduğumda sprint yarın sona eriyor, hala bitirmek için kodlama yapıyorum, ve QA arkadaşlarımın henüz test edecek bir şeyleri yok ve ellerini tutmadan ne verirsem onlara nasıl test edeceğimi bilemiyorum.

Eminim bu ikilemi yaşayan ilk kişi ben değilim.

Geçmişte bir boru hattı yaptım: mevcut sprintte test ekibi, önceki sprint boyunca uygulanan özellikleri test ediyor. Şu anki işimde, Başbakan bu yaklaşımı "şelale" olarak kabul ediyor ve kabul edilemez.

Bir Kullanıcı Hikayesini (ABD) test etmez ve kabul kriterlerinin karşılandığını doğrularsanız bu hikaye yapılmaz. Bu yapılmazsa, ABD elbette bir sonraki koşuya gider. Tüm ABD’niz bu durumda ise, sprint projeye katma değer vermeden sona erdi. Müşteri bakış açısıyla, bunu tatile giden tüm geliştirme ekibinden ayırt edemiyorum.

Yalın ilkelerden biri (çevik israf ile bitmiyor) "kalite yerleşiktir" diyor. Bir şey yalnızca tanımladığınız kalite kriterlerini karşıladığında yapılır. Bu, gerçek bir çevik sürece sahip olmak, yayı sıfır değerde bitirmek veya gelişimden ayrı bir test yapmak için çok önemlidir.

Yapabileceğiniz birçok şey var:

• otomasyon başarının anahtarıdır. En azından birim test düzeyinde ve CI gibi diğer bazı uygulamalar da önemlidir. Bu yeterli değildir, ancak bu tür testler iyi yapılırsa, manuel testlerde keşfedilen hataların az veya hiç olmamasıyla sonuçlanır (genellikle küçük UI işlemleri). Eğer QA görevlendirilmiş kişileriniz varsa, bunlar kabul testini otomatikleştirenler olabilir ve bu otomasyonun bir kısmı bir sprint bitirmeden önce başlayabilir.

• Kullanıcı Hikayelerinizin boyutuna bakın. Sprint'in ilk iki gününde biten bir ABD varsa, üçüncü gün bir QA çalışanı test edebilir. Bence küçük (SMART) kullanıcı geçmişine sahip olmak çevik gelişimde başarı için en önemli şeylerden biriydi ve pek çok insan bunu anlamıyor gibi görünüyor.

• Test cihazı ve geliştiriciler arasındaki işbirliği başarının bir diğer önemli parçasıdır. Bir ABD bir geliştirici tarafından bittiğinde önceki projemde, bir QA çalışanı geliştirici ile "çift test" yapar (manuel olabilir, bazı otomatik veya daha iyi bir yöntemle başlatılabilir), bu oldukça iyi sonuç verir.

Asıl sorun, kodlayan ancak test etmeyen programlayıcılara ve test eden ancak kodlamayan test cihazlarına sahip olmanızdır.

Bu problemi çözün ve bu problemi yaşamayacaksınız ve tartışmalı bir şekilde daha verimli bir ekibiniz olmayacak.

Geçmişte benim için çalışmanın bir yolu, kodlayıcılara ve test uzmanlarına, tamamen test edilmiş bir hikaye sunma görevi ile hikayeleri eşleştirmek için önermek oldu. Bununla birlikte, "dev tam" düşüncenin tüm biçimlerini sildim: scrum / kanban / trello tahtasında "dev tam" sütunlar yok, kodlayıcıların "dev" davranışı yok.

Neler oldu:

• Çiftler hikaye sunmaktan sorumluydu ve eğer bir hikaye tamamlanmadıysa ikisi de başarısız olacaktı. Yazılım dağıtmaktan sorumlu profesyonel olarak muamele gördüler ve çoğu zaman yaptılar.

• Test cihazları ünite ve entegrasyon testlerine maruz kaldıklarından, daha az test çalışması yapıldı, bu yüzden aynı testi manuel olarak tekrarlamadılar.

• Bazı test cihazları, test cihazlarının ihtiyaç duyduklarını daha iyi anladıklarında otomatikleşmiştir.

• Bazı insanlar üzüldü.

• Kodlar tamamlamada daha hızlı bir şekilde teslim edildi, çünkü code-commit-pull-test döngüsü neredeyse anında gerçekleşti

Tabii ki, bu sadece benim anekdot deneyimim, ama eğer yapabilirsen kendin denemek isteyebilirsin.

Sizin durumunuzda, test ediciler ve geliştiricilerin şirketinizde otoriter bir şekilde ayrıldığına dair yorumunuz düşünüldüğünde, mesaj bana açık görünüyor. Şirket kuralları tarafından belirlenen iletişim ve işbirliğinin önünde bariz bir engel var.

Bu bir iletişim problemi, çevik bir problem değil . Çevik bir metodolojinin benimsenmesi, onu açıkça ortaya koyar. Silo'd takımları bilinen bir yönetim karşıtı model olduğundan , bu durumda çevikliğin uyumsuzluğunu benimseyin!

KG'nizin asıl rolü kabul testine yakındır. Bunun, geliştirme ekibinin bir parçası yerine ürün sahibi olarak hareket eden ayrı bir ekip tarafından yapıldığını hayal ediyorum.

Örnek: bir sprint sırasında, arama sonuçlarını farklı kriterlere göre filtrelemeyi sağlayan bir özellik eklemeniz gerekir. Arama mekanizmalarınızı zaten uyguladınız, ancak sonuçlar alfabetik olarak sıralandı.

• Sprint sırasında:

  1. Ekip, yeni özelliğin tasarımını ve gerçek kod tabanı üzerindeki etkisini hazırlar.

  2. Geliştiriciler, siparişin beklendiği gibi çalışmasını sağlayan birim testleri yazıyor ve aynı zamanda asıl kodu da yazıyor.

  3. Yeni özellik hiçbir şeyi bozmadığından (regresyon testi) ve beklendiği gibi çalıştığından (birim testleri) emin olmak için düşünceli bir şekilde test edilmiştir.

  4. Mümkünse ve uygunsa , çoğu projede böyle bir durum söz konusu değil , bir ürün sahibi (ve QA ekibiniz) ekibin yanlış yöne gitmesini önlemek için yeni özelliği sürekli olarak değerlendirebilir. Bu, her gün düzinelerce bina ile sürekli entegrasyon gerektirir.

• Sprint sonrasında, ürün sahibi, müşterinin ihtiyaçlarına uygun olup olmadığını kontrol etmek için yeni özelliği değerlendirir. QA ekibiniz sprint sona erdikten sonra aslında burada.

Asıl sorunlarınızın şöyle olduğuna inanıyorum:

• Kapsam . Bir sprint, bir ürün sahibi olarak daha fazla rol alan gerçek KG'nizle değil, ekibinizle ve yalnızca ekibinizle ilgilidir.

• Test etmek . QA ekibiniz olması, yapmanız gereken tek şey kod yazmak demek değildir. Ekibinizin işi, diğerlerinin test etmesi için kod atmamaya, beklendiği gibi çalışan bir özellik sunmaktır. QA ekibine sizin için testi yapmak için güveniyorsanız, bu genel maliyeti artıracaktır, çünkü hatalar neredeyse anında düzeltilmek yerine bir ila iki hafta sonra giderilecektir.

Kodlamanın tamamı veya çoğu, sprint sonuna kadar yapılmazsa?

Neden daha erken bitmiyor? Bu kilit sınırlama sıkıntılarınızın kaynağıdır ve iki yaklaşımın başarılı olduğunu gördüm. Biri çevik yaklaşıma iyi uyuyor (fakat diğer yaygın uygulamalar değil) ve diğer hafif uçlar biraz çevik (ama daha yaygın).

İlki, sprint sonuna kadar kodlamamanız. Aslında kod yazmak, geliştirmenin nispeten küçük bir parçasıdır. Sprint boyunca yarı yolda bitirirseniz, bu QA'nın işlerini yapması için bolca zaman sağlar. Ayrıca dokümantasyon yazmak, teknik borcu temizlemek, birikim kalemleri için tasarım yapmak için yeterli zaman bırakır ... Kaliteli bir ürün için yapmanız gereken diğer her şey. Gördüğüm bir dezavantajı, işlevselliği ve birim testleri hızlı bir şekilde yapmanın neredeyse imkansız olmasıdır. Şahsen, QA'nın fonksiyonelliğe bakmaya başlamasından sonra birim testleri yapmanın tamamen iyi olduğunu düşünüyorum , ancak TDD savunucuları (ve diğerleri) aynı fikirde olmayacak.

İkinci seçenek, KG’nın nefret ettiği gibi, geliştirme personelinin arkasında bir KG’nın çalıştırılmasıdır. Ben de bundan hoşlanmadım. Sürümleriniz için bir yükseltme süreciniz olsa bile, sprint sonunda "serbest bırakılabilir ürün" kavramını ortadan kaldırır. Daha da kötüsü, geliştiriciler QA onlara testlerle ilgili sorular veya hatalarla geldiğinde “yeni” şeylere odaklanacak. Devs, bu düzenlemede hataları düzeltmek için daha olası değildir. Ancak zamanında kaliteli bir yazılım ürettiğini gördüm.

Scrum Rehberi, ekiplerin çapraz fonksiyonel olmasını gerektirir. Tüm ekip üyeleri, uzmanlık alanlarına bakılmaksızın geliştiriciler olarak kabul edilir. Silo'd bireyler (kodlayıcı, test cihazı, qa, ux, vb.) Scrum'da yararsızdır. Ekip üyeleri, mümkün olan her yerde birbirlerine yardım eder. 'Maddeyi qa'ya aktarmak' kavramı yoktur.

Sizin durumunuzda, bir tahmin probleminiz varmış gibi görünüyor. Ürün biriktirme kalemlerini tahmin ederken, tüm faaliyetleri göz önünde bulundurmanız gerekir , örneğin: Kodlama, Test Etme, Akran Değerlendirmesi, Yerleştirme, Entegrasyon - yaptığınız talep tanımınız ne olursa olsun.

Kaba bir kural olarak, 5 ila 15 ürün backlog ürününü bir sprint içine getirmeyi umuyoruz. Bu, size her ürün biriktirme maddesinin ne kadar büyük olması gerektiği hakkında bir fikir verir. Aynı zamanda sprint içinde çalışmayı “bitirmek” için mükemmel bir şans verir.

Son olarak, ekibin görevi bir ürün biriktirme öğesini 'bitmiş' seviyesine taşımak ve ardından bir sonrakine geçmektir. Bazen bunu yapmak, insanların birbirlerine ayak parmakları üzerinde işlem yaptığı anlamına gelir ve bu nedenle bir kerede birden fazla ürün biriktirme işlemi başlatmanın anlamı vardır. Bununla birlikte, kılavuzunuz devam eden çalışmalarınızı (WIP) azaltmak ve ürün biriktirme öğelerini bitmiş hale getirmek olmalıdır.

Test etme ve kodlama el ele gider. Modül tarafından modül programlayabilirsiniz. Modül bittiğinde, test cihazlarına tedarik edebilirsiniz. Tüm bu senaryo, üzerinde çalıştığınız test aşamasına da bağlıdır. Spiral SDLC modeli iyi görünüyor. Bu durumda, eş zamanlı test ve kodlama uygundur. Başka bir yaklaşım V modeli olabilir .

Muhtemelen ilk başta oldukça garip olan cevabım şudur: Test yapmak için zaman bulamıyorsunuz çünkü testin kodun yan etkileri üzerinde yapılması gerektiğini düşünüyorsunuz . Ve yan etkisi ile bilgisayar bilimi terimini kastediyorum :

Bir fonksiyonun (...), bir değer döndürmeye ek olarak, aynı zamanda (...) dış dünyayla (...) gözlemlenebilir bir etkileşimi varsa yan etkisinin olduğu söylenir.

"Dış dünyayla etkileşimi" bölümünü vurgulamak için teklif verdim: Ekranda basıldığında UI üzerinde test yapılmasını istiyorsunuz ("[teste başlamak için] gerçekten mümkün değil çünkü Kullanıcı arayüzünden otomatik testler kaydetmek veya oluşturmak

Diğer cevaplar, bu “kabul testini” otomatikleştirmenizi, böylelikle hızlı bir şekilde gerçekleşmelerini söyledi. Bu doğru, ancak asıl sorununuzu tam olarak ele almıyor: ya bu kabul testlerini yazmak için yeterli zaman yoksa?

Kod dış dünyayla etkileşime girdikten sonra test etme görüşünüze izin vermelisiniz, yani bir şey bastırdı ve bir miktar girdi bekliyor. Yan etkilerle ilgili sorun, aslında, test edilemez olmalarıdır. Guido van Rossum ile yapılan röportajı okurken bu bana ağladı, burada bilgisayarı kapatan bir ifadenin ancak onu çalıştırarak çalışabileceğini kanıtladı.

Bu "denenemezliğin" çözümü, ifadenin işe yaradığını bir kez ispatladıysanız, her yerde kullanabileceğinizi ve işini yapmak için ona güvenebileceğinizi anlamaktır. Bir fonksiyonla izole edin ve her şeyi test edin .

Bu örneği sorunuza yaklaştırarak, işlev artık büyük olasılıkla tüm bir kütüphane veya çerçevedir ve bilgisayarı kapatmak yerine bir şey çıkarır: bir kullanıcı arabirimi. Çağrıları mümkün olduğunca salak ve olabildiğince sabit tutun , çünkü başvurunuzun o bölümüne girdiğinizde, yalnızca pahalı kabul testleri, yani bir tür dış gözlem yoluyla test edebilirsiniz.

UI'yi "yabancı bölge" olarak kabul etmek aslında doğru bir bakış açısıdır, çünkü sizin tarafınızdan sağlanmayan bir kütüphanenin mantığını test etmeniz gerekmez ve belki de şaşırtıcı bir şekilde, gerçekçi bir bakış açısıdır: Bu çağrıyı, örneğin MyWidget.draw()beklediğiniz şeyi tek bir piksel seviyesine kadar test etmek mi istiyorsunuz?

Bu, kabul testinin önemli olmadığını veya atlanabileceğini söylemek değildir. Orada kalmak ve otomatikleştirmek için orada, diğer cevapların da belirttiği gibi, çok büyük faydaları var. Ancak aynı sprint içinde test etmek ve kodlamak için zaman bulmak istiyorsanız, kodunuzu olabildiğince yan etkiden uzak tutmaya çalışın.