* Özel * Test Edici rolü olmayan bir Geliştirme Ekibinin uygulanabilirliği [kapalı]

Son zamanlarda yalın bir geliştirme ekibinin nasıl kurulacağını düşünüyorum. Sonuçta, az sayıda benzer fikirli insanla kendi küçük yazılım evimi açmak istiyorum. Amaç zengin olmak değil, sağlıklı bir çalışma ortamına sahip olmaktır.

Şimdiye kadar, yalın bir takımı şu şekilde tanımlıyorum:

• Küçük;
• Özörgütleme;
• Tüm üyelerin KG olması gerekir;
• Üyeler birden fazla rol üstlenebilmelidir

Son nokta, biraz endişelendiğim yer çünkü mantra giderken ...

Geliştiriciler kötü testçiler yapıyor.

Çoğu zaman, geliştiricilerin kodlarına veya meslektaşlarının kodlarına daha yüksek kalite değerlendirmeleri yapmak için "çok yakın" olduklarını anlasam da, bunların fiili kötü testçiler olduğuna ikna olmadım . Aksine, iyi bir geliştiricinin niteliklerinin iyi bir test edenin nitelikleri ile büyük ölçüde örtüştüğüne inanıyorum.

Bunun doğru olduğunu varsayarsak, dev / tester sorununu çözmenin farklı yollarını düşünüyorum ve uygun bir model bulduğuma inanıyorum.

Modelim şunları gerektirir:

• 2+ projeli küçük bir yazılım evi
• Geliştirme ve sunuma çevik (yinelemeli) bir yaklaşım
• Proje başına 1 takım
• Tüm ekip üyeleri Yazılım Geliştiricileri olacak
  • Görev tanımları Geliştirme , Kalite Güvencesi , Test ve Teslimatı sorumluluk olarak açıkça belirtecektir

Tüm bu önkoşullar yerine getirilmişse, projeler aşağıdaki şekilde düzenlenebilir (bu örnek A ve B adlı iki projeye atıfta bulunacaktır ):

• Her ekip üyesi Geliştirici rolü ve Test Kullanıcısı rolü arasında geçiş yapar
• Bir ekip üyesi A projesinde bir Geliştirici ise , B projesinde bir Testçi olacaktır.
  • Üye aynı anda sadece 1 proje üzerinde çalışacak ve bu nedenle olarak hareket edilmesi bekleniyor ya bir Dev veya bir Tester.
• Bir Rol Çevrim (iki farklı projelerde, yeniden) bir Dev olarak 3 yineleme ve Tester 2 yineleme oluşmaktadır
• Proje ekiplerinin her zaman 3 Devs ve 2 Testçileri olacaktır.
• Üye Rol Döngüleri 1 yineleme ile faz dışı olmalıdır.
  • Bu, takım değişikliklerinin aniden ortaya çıkmasını en aza indirir. Her yineleme için 2 Devs ve 1 Test Cihazı önceki yinelemeyle aynı kalır.

Yukarıdakiler göz önüne alındığında, aşağıdaki Artıları ve Eksileri görüyorum:

Artıları

• Proje bilgisini şirket genelinde dağıtır.
• Ekip üyelerinin yazmaya yardımcı oldukları kodu test etmemelerini sağlar.
• Faz dışı rol döngüleri hiçbir projenin% 100 üye anahtarına sahip olmadığı anlamına gelir.
• Alternatif roller sıkıcı projelerin tekdüzeliğini bozar.

Eksileri

• Her iki projenin yinelemeleri sıkı sıkıya bağlıdır. Bir proje bir yinelemeyi yarıya kadar iptal edip yeniden başlasaydı, o zaman iki proje senkronize olmazdı. Bu, rol döngüsünün yönetilmesini zorlaştıracaktır.
• İşe alım menteşeleri Geliştiriciler de Test Cihazı olarak çalışmaktadır.

Bu yaklaşımı arkadaşları ve meslektaşları ile tartışırken karışık eleştiriler aldım. Bazıları az sayıda geliştiricinin böyle rolleri değiştirmek isteyeceğine inanırken, diğerleri bana kişisel olarak denemeyi sevdiklerini söylüyor.

Benim sorum şu: Böyle bir model pratikte işe yarayabilir mi? Değilse, çalışan bir modele dönüştürülebilir mi?

Not: Kısaca, sadece Dev ve Tester rollerine odaklandım. Gerekirse diğer roller üzerinde genişleyeceğim.

Katılmıyorum

Geliştiriciler kötü testçiler yapıyor

Kariyerim üzerinde çalıştığım takımların çoğunda KG desteği yoktu. Bu, küresel giriş ve kayıt sistemleri gibi ürünleri içeren birkaç büyük, küresel şirketi içerir. Başka bir durumda, şirketin gelirinin% 30'unu masamdaki bir kutudan geçirdim. (Bu uygulamalara BTW önerilmez;)) Bu şirketler, kodlarının doğru çalıştığından emin olmak için mühendislere güveniyordu. Ve detay odaklı, biraz zorlayıcı ve çalışmalarımızdan gurur duyan bizler, yazılımımızın doğru çalıştığından emin olmak için büyük çaba harcayacağız.

Ayrıca, bir geliştirici olarak Test edicilerden çok daha fazla test yapıyorum . Java ile çalışmazsam kodumu% 90 veya% 100'e düzenli olarak test ediyorum.

Testers ile çalışmayı seviyorum çünkü onlar farklı bir perspektiften geliyorlar ve aklıma gelmeyen şeyleri yakalıyorlar. Ama% 100'den fazla test kapsamı sağlamak için onlara güvenmiyorum, kendimi% 100 sorumlu tutuyorum. (BTW Bu onlar için bir çarpma değil - genellikle projeler arasında ince yayılırlar.)

Mülakatlarda mühendislere KG yapmak isteyip istemediklerini sormak yerine şunu sorun: üretimde bir hata ortaya çıkarsa, kim sorumlu? Bir hatayı tanıtırsam ve bir müşteri bunu yaşarsa, kendimi kötü hisseder ve sorumluluk alırım. KG adamları suçlamıyorum. IMHO Bu işe almak istediğiniz (ve çalışmak istediğiniz türden bir mühendis)

Kaliteyi sağlama yöntemim a) süper agresif bir birim testtir (tam Test Odaklı Geliştirme için kendimi tam olarak getirememe rağmen), b) güçlü bir kod inceleme süreci gerçekten yardımcı olur ve c) bir intoleransı ve sabırsızlığı entegre etmek takım kültüründe kusurlar.

Her zaman en büyük adamların en küçük ve hatta küçük sorunlara karşı en dikkatli olanları olduğu dikkat çekti, çünkü daha büyük bir soruna işaret edebilirlerdi. Ama esas olarak, bunu düzeltmek için zaman harcamaya en istekli olanlardı.

Ancak, özellikle küçük şirketler için üzerinde çalıştığım ekiplerin çoğunda resmi bir KG bileşeni yoktu.

@Rob Y'nin cevabına katılıyorum ve birkaç puan eklemek istiyorum:

• Çevik olarak, bir ekip içindeki özel test uzmanları bir anti-kalıptır, çünkü ekipleri boru hattı çalışmalarına ve doğal olarak verimsiz olmaya zorlarlar. Sürekli "geliştirildi" ama test edilmemiş hikayeler ile sonuçlanır. Özel test kullanıcıları, ekibin (veya ayrı bir ekibin) dışında çalışırlarsa iyidir.

• Geliştirici kötü testçiler yapar ... ve testçiler kötü testçiler yapar. KG zor. Aslında, çok zor. Sorununuz insanlar ve roller olmayabilir. Sorununuz yazılımınızın tükenmiş olması olabilir. Yine, çevik olarak, üretimden önce test etmek ekibinizin sorumluluğundadır (özel kalite kontrolleri olsun veya olmasın).

• QA, yeniden düzenleme, mimari vb. KG, bu standardı geliştirmeyecektir. Daha iyi geliştiriciler muhtemelen.

• Provokasyon: QA'nın QA-ing'deki geliştiricilerden daha iyi olduğunu kim söylüyor? İnsanların söylediği bir şey ama ... [alıntı gerekli]. KG'nin gerekli "hacker" zihniyeti, bir geliştirici zihniyeti. Aslında, tüm hackerlar QA değil, geliştiricilerdi veya geliştiricilerdi ...

• Provokasyon 2: QA işin% 99 (diyorum cesaret ve olabilir edilmelidir script aracılığıyla otomatik). İyi bir ekip bunu yapacak ve bunu doğru bir şekilde yapmak için ... geliştiricilere ihtiyacınız var.

Önceki bir işte sadece geliştiriciler vardı ve KG personeli yoktu. Sonuç olarak, bir sorun üretime geçerse suçlanacak başka kimse yoktu. KG sorumluluklarımızı çok ciddiye aldık ve otomatikleştirilmiş test takımlarına büyük önem verdik. Otomatik testler yazmak hala kodladığı için, geliştiricilerin bunu yapmasını sağlamak çok da önemli değildi.

Anahtar şey onu takımın kültürünün ve her projenin bir parçası haline getirmektir. Test planları yazdık (sadece bir proje için yazmayı düşündüğümüz testlerin kısa bir listesi) ve diğer geliştiriciler gözden kaçırdığımız vakaları ve senaryoları inceleyip önereceklerdi.

Bu konuda titizseniz, çok iyi çalışabilir. Bizim için yaptı - biz her zaman açık bir e-ticaret web hizmet mükemmel çalışma süresi ve düşük kusurları vardı.

Önce bir uyarı - Hem QA mühendisi hem de yazılım mühendisi olarak profesyonelce çalıştım.

Böyle bir model pratikte işe yarayabilir mi?

Herşey mümkün.

Çoğu zaman, geliştiricilerin kodlarına veya meslektaşlarının kodlarına daha yüksek kalite değerlendirmeleri yapmak için "çok yakın" olduklarını anlasam da, bunların fiili kötü testçiler olduğuna ikna olmadım. Aksine, iyi bir geliştiricinin niteliklerinin iyi bir test edenin nitelikleri ile büyük ölçüde örtüştüğüne inanıyorum.

Ne tür testlere ihtiyacınız olduğuna bağlıdır. Her bir ekranın veya öğenin gerçekten Elbonian diline çevrildiğinden emin olmak için zihin uyuşturan, monoton, tekrarlayan manuel testlere ihtiyacınız varsa ... sorun yaşayacaksınız.

Ve benim deneyim, her proje (değil her proje bile test bu tür en azından biraz gerektirir yaptığı test bu tür). Sorun, en iyi KG uygulamalarına aşina olmayan kişilerden bu tür bir test almamanızdır. Cehennem, en iyi uygulamaları bilen insanlardan bile alamazsınız, ancak geliştiricilere "güvenirsiniz".

Test kullanıcısı olarak geliştiricilere güvenemezsiniz. "Muhtemelen bu değişiklik nedeniyle olamazdı" veya "dev kutusu mükemmel çalışır" bulduğum hataların sayısını kaybettim.

5 üzerinden 2 hafta yapmayı sevdikleri şeyleri yapmamaya tahammül edebilecek geliştiriciler bulabilseniz bile , bu çekirdek çelişkiye gireceksiniz. Daha da kötüsü, insanları bir değil iki işte iyi olmaları için eğitmek için zaman ve enerji harcıyorsunuz. Şirketler, ikisini bir yana, tek bir işte iyi insanları bulmak ve eğitmek için yeterince zorlanıyor.

Belki de henüz karşılaşmadığım bir şekilde harikasınız - ama bundan şüpheliyim.

Sanırım işe yarayabilir, ama bunu yaptığınızdan emin olacağım birkaç şey var.

1. Adayların ikili rolleri konusunda çok açık olun. Birçok nedenden dolayı herkes için değil. Eğer hoşlanmayan çok fazla insanınız varsa, başarısızlığınız ve cironuz olacak.
2. Bunu ekibe dahil etmenin en iyi yolunu değerlendirebileceğiniz bir planınız olsun. Her seferinde bir göreve / projeye odaklanmak istesem de, çok uzun bir süre programlama yapmak istemediğimden emin değilim. Belki test etmek programlamadan uzak güzel bir tatil. Bir değişiklik için sadece farklı beyin hücreleri kullanmak daha kolay değil. Neyin en iyi olduğuna karar vermeden önce farklı şekillerde denemeye hazır olun.

Projeleri senkronize etmek pratik bir çözüm gibi görünmüyor. Birisi bir projenin vasiyetçisiyse, bir programcıyı değiştirmek için en iyi aday olabilir veya tam tersi.

Bu plan ekiplerin kendi kendilerini yeterince organize etmelerine izin vermez. Bir strateji muhtemelen tüm ekiplere ve tüm projelere uymayacaktır.