Scrum sprint'lerinde test etme ve Scrum'da kullanıcı öyküleri yazma

Şirketimde yeni bir projenin geliştirme ekibi lideriyim. Bu, şirketin Scrum'ı kullanacağı ilk projedir. Bir şelale / yinelemeli SDLC'miz var. BA'lar dokümanları yazıyor, geliştirici ve teste devrediyor, geliştirici gelişmeye başlıyor ve iterasyonlarda teste başlayacak. Test kullanıcıları, geliştiricilerin geliştirmeye devam ettiği bir sürümü test etmek için uzun zaman alır, aynı zamanda mevcut sürüm için hata düzeltmeleri de yapar. bir kaç sorum var

1. 5 öykü içeren bir sprint'te test için ne zaman serbest bırakılır? Bir hikaye geliştirici tarafından tamamlanır tamamlanmaz mı yoksa tüm hikayeler tamamlandıktan sonra mı yoksa sprint bitmeden önce test için gerekli zamanı verir.
2. BA kullanıcı hikayeleri yazarsa, ayrıntı ne olmalıdır. Geleneksel olarak, tüm UI düzeni, davranışı, metni vb. İle sonlandırılacak bir özellik yazmak uzun zaman alır. Sanırım sorum, uygulanamaz ve test edilebilir hikayelerin nasıl yazılacağı.
3. Test ekibimiz teknik değildir. Scrum için otomatik UI testine sahip olmak ne kadar önemli. Kullanıcı arayüzü WPF'ye dayanmaktadır.

Çevik yöntemler (TDD, kod incelemeleri, yeniden düzenleme vb.) Kullanarak sağlam geliştirme deneyimi var ama scrum için yeni.

edit: Yinelemelere göre, 100 gereksinim varsa, 100 gereksinimin tamamı tamamlanana kadar beklemek yerine 30, 35, 35 gereksinimlerini bitirdiğimizde teste bırakabileceğimizi kastediyorum.

Test geliştirmeden ayrıysa, iki ayrı scrum ekibiniz var. Bir elin diğerine çalışması kötü bir fikirdir.

Kişisel geliştiriciler gerekir kendi testleri yazmak, bu diğer takımdan ayrı. Bu diğer "test" ekibini müşterileriniz gibi görmelisiniz.

Bir sprint'te ... test için ne zaman serbest bırakacaksınız?

Sprint bittiğinde. Tamamen bitti. Bu, kendi birim testinizi yaptığınız ve çalıştığından emin olduğunuz anlamına gelir . Geliştirme ekibiniz tamamlandıktan sonra, "test" veya "dağıtım" için veya kuruluşta başka ne olursa olsun diğer ekiplere yayınlarsınız.

Sanırım sorum, uygulanamaz ve test edilebilir hikayelerin nasıl yazılacağı.

Bu takımdan takıma değişir. BA, geliştirme ekibinin bir parçasıdır. Doğru miktarda ayrıntı elde etmek için bir ekip (BA artı geliştiriciler) üzerinde çalışmalısınız. BA'dan ekibin geri kalanına doğru bilgileri almak bir takım çabasıdır.

Scrum için otomatik UI testine sahip olmak ne kadar önemli.

Esansiyel. Herhangi bir UI gelişimi için tamamen gereklidir. Geliştiriciler "test ekibine" verilmeden önce tüm testleri kendileri yapmalıdır . Bir kullanıcı arayüzü varsa, bunu test etmeleri gerekir. Kullanıcı arayüzü yoksa, otomatik kullanıcı arayüzü testi gerekli değildir. Test gerekli ve bir kullanıcı arayüzü test edilmelidir. Otomatik test, mevcut en iyi uygulamadır.

Sonuç olarak. Ayrı bir "test" ekibi ve her küçük detayı yazan bir BA Scrum için en uygun organizasyon değildir. Scrum, hem organizasyonlarınızı hem de süreçlerinizi yeniden düşünmeniz gerektiği anlamına gelir.

Vereceğim cevapların çoğu, Yineleyen bir Şelale yöntemine karşı Çevik bir yazılım geliştirme yöntemiyle ilgilidir. Scrum sadece popüler bir Agile uygulamasıdır.

1. Tipik Scrum'da ayrı bir test aşaması yoktur, çünkü tüm sprint boyunca resmi testler yapılmalıdır. Bir geliştirici bir Kullanıcı Hikayesini bitirdiğinde, KG kaynağının test senaryoları önceden hazırlanmış olmalı ve o noktada teste başlamalıdır. Test senaryoları geçerse, kullanıcı hikayesini kabul eder ve bir sonrakine geçer. Tüm Kullanıcı Hikayeleri tamamlandıktan ve Kabul Edildikten sonra sprint sona erer ve bir sonrakine başlarsınız. Bu elbette Sürekli Entegrasyona bağlıdır, bu nedenle geliştirme değişiklikleri KG için hemen kullanılabilir. Regresyon testinin mümkün olduğunca hızlı ve ağrısız olmasını sağlamak için daha fazla geliştirme TDD yönergelerine uymalıdır.

2. BA'ların kullanıcı hikayeleri yazması iyi bir fikirdir, ancak daha ayrıntılı ve spesifik kontrol için Kullanıcı Öyküleri resmi Gereksinim belgelerine eşlik edebilir. Kullanıcı Hikayesi rol ile tek bir kullanıcı açısından yazılmalıdır. Kullanıcının bakış açısından bir ihtiyacı ifade eder, bu yüzden yazılım şu anda bu ihtiyacın tüm yönlerini karşılıyorsa, kullanıcı hikayesi karşılanmaktadır. Kullanıcı hikayeleri, alt kullanıcı hikayelerinden ve atanabilir Görevlerden oluşabilir. Birden çok kullanıcı hikayesi için Görevler'de çakışma olabilir.

3. Otomatik UI testi iyi bir şey olabilir, ancak şahsen TDD yöntemleri üzerinde daha fazla çaba ve tüm İş Mantığının% 100 birim testi kapsamının daha önemli olduğunu hissediyorum. Çoğu yazılım geliştirme ekibi, İş Mantığının% 100 kapsamını elde edemez gibi görünüyor, bu yüzden bence Otomatik Kullanıcı Arayüzü Testi, BL için daha fazla birim testi yazmak için kullanılabilecek değerli bir zaman kaybı olacaktır. Bence bir lüzum değil.

1. Scrum'da, her sprint sonunda potansiyel olarak sevk edilebilir bir yazılım artışı üretmeniz gerekiyor . Sonuç olarak Scrum, belirli bir kullanıcı hikayesini gerçekleştirmek için gereken her becerinin ekipte bulunması gereken tüm ekip veya çapraz fonksiyonel ekip kavramını teşvik eder .

   Mevcut projemde, tamamen test edilmiş bir hikaye yapılan tanımımızın bir parçası olduğundan, test ekiplerini ekiplere yerleştirdik. Bir sprint'in ilk birkaç gününde, geliştiriciler ilk kullanıcı hikayeleri üzerinde çalışmaya başlarken, test kullanıcıları test senaryoları hazırlayacak ve bazı test verileri ayarlayacaktır. Kullanıcı öykülerinden birinin geliştiricisi biter bitmez bunu test ederler.

2. Bu, Scrum IMO'daki en büyük zorluklardan biridir. Uygulanabilir, test edilebilir bir kullanıcı hikayesi elde etmek için gerekli miktarda spesifikasyonu bulmanız gerekir. Çok fazla açık analiz, dokümantasyon ve şartname, sprint boyunca kaçınılmaz olarak yanlış kanıtlayacak katı bir planla sonuçlanacaktır. Tersine, Ürün Sahibi tarafından açıkça tanımlanmayan ve ifade edilmeyen bir kullanıcı hikayesi, Sprint sırasında geliştiriciler ve PO arasında doymuş bir iletişim bant genişliğine ve geliştirme sırasında gecikmelere neden olurken PO, sprint'in yarısı boyunca kullanıcı hikayeleri hakkında kararlar verir. .

   Bizim durumumuzda, bir kullanıcı hikayesinin "/ ... istiyorum ... böylece ..." ve 2 / bir dizi kabul şeklinde bir açıklama olması için doğru miktarda ayrıntı tanımladık. kriterleri. Biz nadiren kullanıcı arayüzünün maketlerini yaparız, sprint planlaması sırasında olabilir, ancak daha sonra atılan daha fazla taslaktır.

3. Deneyimlerime göre, otomatik UI testi son derece zaman alıcı ve son derece kırılgandır. Bunu WPF'de yapmanın yolları var, ancak bu tür testlerin bakım maliyetini bu şekilde gitmeden önce dikkatle düşünmeliyim.

Daha kısa ve daha kısa yinelemelerde çalışmak, tüm bu aktarımları daha pahalı hale getirir. Aptalca ve basit bir kurala uyarak bu maliyetleri azaltabilirsiniz: parti boyutlarını ikiye bölün, bunu rahat hale getirmek için çalışma şeklinizi değiştirin, mutlu olana kadar tekrarlayın.

5 katlı sprint örneğinizi alın. Takımlarınız 5 hikayenin de kodunu yazmaya alışkınsa, 5 hikayenin tümünü test ederseniz, toplu iş boyutu 5 hikayedir. Bunu yarıya indir. Bir sonraki süratte, ilk önce en acil olan 3 hikaye üzerinde çalışın ve onları mümkün olduğunca erken test etmeye hazırlayın. Testçiler bu 3 hikayeyi test ederken, geri kalanlar kalan 2 hikayeyi test için hazır hale getirebilir. Bu bazı büyüyen ağrılara neden olur. Bunu daha rahat hale getirmek için çalışma şeklinizi değiştirin.

Örneğin, her hikaye üzerinde daha fazla kişi birlikte çalışacaktır, bu yüzden daha fazla eşleştirmeyi deneyin ve bunun daha düzenli çalışmanıza yardımcı olup olmadığını görün. Ya da belki de test kullanıcıları, 2. bölümde, 5. program üzerinde çalışmaya çalışırken bazı programcıları rahatsız eden sorunlar bulacaklardır. Bu nedenle, programcıları ve test uzmanlarını bir sonraki sprint'i "ilk parti" "böylece programcıların bir test cihazının bir testle kolayca yakalayabileceği bir hata yapma olasılığı daha düşüktür.

Programcılar bir sonraki hikaye grubu üzerinde çalışırken testçilerin küçük bir hikaye grubunu test etmesiyle ilgili büyük sorunları çözmek birkaç sprint gerektirebilir. Rahat hale geldiğinde, parti boyutunu tekrar yarıya kesin. Ve yeniden. Bir yıl kadar sonra, programcılar onlarla bitirdiklerine inandıklarından ve muhtemelen yol boyunca daha az hata yaptıklarından, ekip hikayeleri rahatça test edecek . Her hikaye daha erken yapılacaktır.

Tabii ki, bu noktada, artık ekibin ürün sahiplerinden aldığı veya ekibin operasyon organizasyonuna gönderdiği partilerle aynı şeyi yapabilirsiniz. Ve bunun gibi. Bu noktada, "BA'lar hikayeler için ne kadar detay yazmalı?" sorun.

Bu arada: testçilerin geri dönüş zamanlarını azaltabilmeleri için, nasıl otomatikleştirileceklerini öğrenme ve programcıların otomatikleştirmelerine yardımcı olacak bazı kombinasyonlarla bazı otomasyonları benimsemek zorunda kalacaklar. Toplu iş boyutunu azaltmaya çalıştıkça, bu sorunları ne zaman çözmeniz gerektiğini öğreneceksiniz. Bir kitabın ona ihtiyacınız olduğunu söylediği için otomasyon eklemeyin.

Umarım bu size yardımcı olur.

Sadece aşağıdaki gibi bazı deneyimleri paylaşmak istiyorum, size yardımcı olacağını umuyoruz.

5 öykü içeren bir sprint'te test için ne zaman serbest bırakılır? Bir hikaye geliştirici tarafından tamamlanır tamamlanmaz mı yoksa tüm hikayeler tamamlandıktan sonra mı yoksa sprint bitmeden önce test için gerekli zamanı verir.

Her büyük kullanıcı hikayesi için, birçok alt göreve bölünmelidir ve alt görevler geliştirici tarafından tamamen yapıldığında, hemen test etmek için QC'ye bırakılmalıdır. Bu alt görevler bitirme testi için testten sonra kusur düzeltilmelidir.

BA kullanıcı hikayeleri yazarsa, ayrıntı ne olmalıdır. Geleneksel olarak, tüm UI düzeni, davranışı, metni vb. İle sonlandırılacak bir özellik yazmak uzun zaman alır. Sanırım sorum, uygulanamaz ve test edilebilir hikayelerin nasıl yazılacağı.

Scrum'da, kullanıcı hikayeleri, hikayeleri çevreleyen sohbetler gerçekleştiği ve tamamlanması veya statik olması beklenmediği sürece herhangi bir biçimde olmalıdır. Basitçe bir kullanıcı hikayesi olarak adlandırılan küçük bir hikaye, iyi anlaşılan ve bir sprint içinde uygulanabilen hikayedir. Bir hikayenin önceliği YG'ye, işletme değerine veya kullanıcının önemli olduğu konusunda kabul ettiği başka bir şeye dayanabilir. Bu PO'nun faaliyetleri.

Test ekibimiz teknik değildir. Scrum için otomatik UI testine sahip olmak ne kadar önemli. Kullanıcı arayüzü WPF'ye dayanmaktadır

Scrum'da otomasyon testinin uygulanması oldukça zor bir faaliyettir. Çünkü tüm fonksiyonlar tamamlanmamıştır ve QC'nin test senaryosunu bazı otomatik test araçlarıyla uygulamasına izin vermek için gerçekten kararlı değildir. Regresyon adı verilen bir sprint için yapılmalıdır.