Scrum rehberi neden test kullanıcısı söylemiyor?

Scrum.org'dan Scrum Rehberini okudum ve şöyle diyor:

Geliştirme Ekipleri, test veya iş analizi gibi belirli alanlara adanmış alt ekipler içermez.

Kelimenin tam çevirisinde, kafa karıştırıcı hiçbir test kullanıcısı olmadığı anlamına gelir. Bunu nasıl önerebilirler?

Bunun anlamı:

1. Test kullanıcıları, geliştiricilerin test etmenin yanı sıra test etmelerine yardımcı olmak için geliştirme ekibi oluşturma araçlarına entegre edilmiştir.

   veya:

2. Ekip, Test Odaklı Geliştirme uygular - yani sistemi uygulayan otomatik testler yazarlar.

Bunların her ikisi de ayrı bir test ekibine ihtiyaç olmadığı anlamına gelir.

Kelimenin tam anlamıyla çevirisinde bu, kafa karıştırıcı hiçbir test edicinin olmadığı anlamına gelir ... Bunu nasıl önerebilirler?

Evet, tam olarak önerdikleri şey bu. Başka bir deyişle - geliştiriciler test edicilerdir ve test ediciler geliştiricilerdir.

Fikir, kod sahipliğini ve kalitesini artırmaktır .

Bu, kodun test edilmediği anlamına gelmez, ancak kodun yazılmasına katılan kişilerin onu test etmeye dahil olan kişiler olduğu anlamına gelir - sorumlulukların ayrılması yoktur.

Bu yaklaşımın ele almaya çalıştığı sorun, geliştiricilerin kod yazıp diğer duvara "duvarın üzerinden atması" gereken geliştiriciler ve test ediciler arasındaki çok yaygın ayrımdır ve daha sonra projeyi geciktirir ve üretir alt standart yazılım.

Bunun temel kısmı, kodlayıcının sorumluluğunun, çalışan ve gereksinimi karşılayan kod oluşturmaktır. Bu belirli bir zihniyet gerektirir - "Ben yazıyorum kod ne gerekiyorsa yapar."

Kodlayıcının sorumluluklarını karıştırmak, kodlayıcının şimdi başka faaliyetler için başka zihniyetlere girmesi gerektiği anlamına gelir, ancak bir kodlayıcı olarak kişinin kendini bu zihniyetten tamamen boşaltması imkansızdır.

Testçinin sorumluluğu, işlevsellikin gerekli işlevsellikten saptığı hataları ve yerleri bulmaktır. Bu, "Kod bozuk ve nasıl olduğunu bulacağım."

Benzer şekilde, bir iş analisti müşterinin gerçekten istediği gereksinimleri belirlemeye çalışıyor. Bu da "uygulama bu şekilde çalışmaz, ancak olmalıdır."

Bir kodlayıcının diğer kapasitelerin herhangi birinde çalışması için, zihniyetlerin çatışması ve kodlayıcının par.

• Coder / QA - "Kod mükemmel çalışıyor ve ben bunu bozabileceğini düşündüğüm olası her yolu işlemek için kodladım."
• Coder / BA - "Kod istediğim gibi çalışmalı ve bunlar müşterinin düşünmediği bir şey eklemek için düzgün şeyler olurdu.

Bu, her kodlayıcının bu sorunlara yatkın olduğu anlamına gelmez (bazı yetenekli kodlayıcı / KG türlerini karşıladım ... yazdıkları kod için olmasa da).

Bu da geliştirme ekibine kadar uzanır. Bir geliştirme ekibi için bu sorumlulukların sorumluluklarını ve ilişkili zihniyetlerini karıştırmak nihai ürünü (kod) tehlikeye atar.

Teste adanmış alt ekip olmadığını söylüyor . Bu, hiçbir test yapılmadığı anlamına gelmez. Bu sadece ekip üyelerinin kendi testlerini yapacakları ve diğer kişilerin kodlarını / özelliklerini test edecekleri anlamına gelir. Scrum metodolojisine aşina değilim, ama bir uzuv gideceğim ve müşterinin teste dahil olabileceğini söyleyeceğim.

Bence bu kısmen kendi kodunuz için testler yazmanız bekleniyor, böylece işe yaradığını biliyorsunuz (eğer gerçekten bitirmediyseniz) ve kısmen de bazen başkalarının kodu için bir testçi olmanız beklenebilir .

İnsanların yazılım kalitesi işini bir başkasına boşaltmasına ve görmezden gelmesine izin vermek yerine, herkesi yazdıkları kodu her zaman kalite perspektifinden düşünmeye zorlar, bu yüzden iyi bir fikirdir.

Bu ifade temelde sessiz çalışmayı önlemeye çalışıyor. Bunun çözümünün bir kısmı - Test Tahrikli Geliştirme - Çift Programlama - Çekme İstekleri - Test otomasyonu ve testlerin, yan tarafta veya 'sonra'.

Buna ek olarak, Scrum Rehberindeki roller hakkında çok sınırlı bir konuşma vardır. Aslında, Geliştirme Takımı hakkında konuşuyorlar. Demek istedikleri, güçlü bir çapraz fonksiyonel takım istemenizdir. Bu, projelerinizin neye bağlı olduğuna bağlı olarak, UX, BA, QA / Test Cihazı, Ops, Coder vb.Gibi bir dizi beceriye ihtiyacınız olduğu anlamına gelir, ancak bunun bunları kapsayan bir veya daha fazla kişi olup olmadığı gerçekten önemli değildir.

Birlikte çalıştığım ekipler DevOps çalışanlarımız olduğu için kesinlikle rol olarak KG'ye sahipler. Ama hepsi de sadece bu alanlarda uzman olan Devs. Hile gerçekten silolara düşmemek ve yalnız çalışmaktır.

Bu mutlaka test kullanıcısı olmadığı anlamına gelmez. Bir Scrum ekibinin özel test kullanıcıları olması söz konusu olabilir veya olmayabilir.

Bana göre, Scrum hakkındaki bu ifadenin anlamı, tüm dağıtım hattını tek bir ekip olarak düşünmeniz gerektiğidir. Aynı ekibin bir parçası olmak birkaç şey önerir:

1. Bir öykü / hata / görev hakkında tek bir tahmin vardır. Bir dev tahmini ve test tahmini yoktur.
2. Ekip, bir hikaye tahmin etmez ve test cihazı mevcut olmadan bunu taahhüt etmez.
3. Bir şeyler ters giderse, geliştiricinin hatasından daha fazla test edenin hatası değildir. Bu takımın hatası .
4. Ekibin hiçbir zaman test kullanıcılarını ödünç alması, talep etmesi veya istemesi gerekmez.
5. Test, done tanımının bir parçasıdır. Test edilmemiş iş eksik iştir.
6. Geliştiriciler kodlarını tasarlarken test edilebilirliği düşünmelidir.

Tek bir ekiple birlikte çalışıyorlarsa, ekip birlikte başarılı olur ve birlikte başarısız olur. Birkaç testçiye sahip çok başarılı bir Scrum takımındaydım. Testçiler tüm stand-up'lar, tımar oturumları, planlama vb. Sırasında mevcuttu. Bir hikayenin nasıl test edileceği net değilse, ekip buna katılmayacaktı. Tahmin yaparken her zaman test uzmanlarımızla konuştuk.

Yaptığınızı düşünseniz bile, test kullanıcılarına teslimat ekibinin bir parçası olarak gerçekten davranamayabileceğiniz potansiyel işaretler:

1. Testçilerin bir "KG standı" var (evet, gördüm).
2. Test kullanıcıları ayrı bir yönetim yapısına sahiptir.
3. Bir KG talebiniz var.
4. Uçtan uca testlere büyük ölçüde güveniyorsunuz.
5. Testler aşağıdaki süratle yazılır.
6. Testlerin çoğu sprint'in son gününde gerçekleşir.

Bunlar özneldir ve mutlaka yanlış değildir. Bence kırmızı bayraklar.

Bütün bunlar, test görevlisinin belirlenmiş bir rolüne sahip olmayan bir Scrum ekibine sahip olmanın tamamen mümkün olduğunu söyledi. Bu da işe yarayabilir. Özellikle testi otomatik hale getirirseniz. TDD de yardımcı olur.