Kalkınma ne zaman durmalı ve KG ne zaman başlamalı?

İki kişilik geliştirme ekibimiz için eksiksiz bir işlevsel şartname yazıyoruz. Profesyonel test kullanıcılarımız yok, ancak mevcut yardım masası personelimizin yardımıyla 'KG testi' yapmak üzere hazırladık.

Geçmişte tam işlevsellik parçalarının çalışmadığı veya kodun teslim edildiği sorunlara göre problem yaşamadık.

Sorularım: Geliştiriciler hangi aşamada KG ekibine kod yazmayı bırakmalılar? KG ekibine teslim etmeden önce geliştiricilerden kodlarını spesifikasyona göre incelemelerini istemek çok mu fazla?

Olmamalı!

Tüm işleri yapmak, durdurmak ve daha sonra tüm sorunları çözmek çok zordur. KG işlemi sırasında bulduğunuz bir sorunu gidermeye gittiğinizde, farklı bir şey yapmanın daha iyi olacağını öğrenebilirsiniz.

Her şeyi kilit adım süreci olarak düşünmek yerine, daha döngüsel hale getirmeye çalışın. Bazı işlevleri kodlayın ve test edin. Biraz daha kodlayın ve test edin (ve eski şeyler hala çalışır). Bu daha akıcı süreç, her şeyi önden yüklemeye çalışmanın zor gemisini hafifletir. Son başvuru tarihine yaklaştığınızda hala kod dondurma kavramına sahip olabilirsiniz (sadece hataları düzeltin), ancak mesele erken ve sık sık test etmektir.

Kodun tüm bölümleri çalışmayan bir durumda KG'ye teslim ediliyorsa, belki de işleminize bir tür birim / entegrasyon testi eklemeyi düşünmelisiniz. KG çalışanlarınızı kodunuzu birleştirme veya entegrasyon testinde başarısız olduğunuzu öğrenmelerini sağlayarak kötüye kullanmayın.

Bu ince bir çizgi, çünkü kod spec'e göre teslim edilirse, o zaman bana bu hata olmadığı anlamına gelir (ve KG'ye gerek yok!). Kodun rutin olarak spesifikasyona teslim edilmemesi, ilk etapta KG yapmamızın sebebidir.

Ama aslında bunun hakkında konuştuğunu sanmıyorum. Demek istediğiniz şey, dev ekibinin kodlamaları ile biraz tembel görünmesi ve işe yaramayan büyük bariz şeyler olması. Önceden, A, B ve C özellikleri (spesifikasyonda) için birim testlerinin mevcut olması ve ardından kodun ve testlerin bağımsız olarak (bir takım yalın veya yönetici tarafından) incelenmesi, bu tür problemleri hafifletmeye yardımcı olmalıdır. .

En azından geliştiricilerin "mutlu yolu" test etmeleri gerektiğini savunuyorum. Beklenen verileri girerse, spesifikasyonun yapması gerekenleri söylediği şeyi yapar. Bu kadar çok şey yapmayan geliştiriciler sorgulanmalıdır.

Bir geliştirici bariz kenar durumlarını test etmediyse de hayal kırıklığına uğradım: veritabanı için çok uzun bir dize, açıkçası geçersiz metin, bir sayının olması gereken harfleri girerseniz, vb. Bu sık sık olursa, tekrar sorular sorulmalıdır .

Bununla birlikte, bir geliştirici bir adı yalnızca büyük ve küçük harflerle sınırlar, ancak bazı adların kesme işaretlerini olduğunu veya 29 Şubat 2011 tarihine izin verirse, spesifikasyonda özellikle belirtilmediğini varsayarsak - bu biraz daha anlaşılabilir . Defalarca aynı hatayı yapmadıkları sürece.

KG ekibi, uç noktalara dikkat çekiyor olmalı. KG'nin maymun testçisi olmasını tercih ediyorum: sadece rastgele çöp girerek uygulamayı bu şekilde kırabilirler mi?

Web geliştirmede KG farklı tarayıcıları denemeli ve kodu etkileyebilecek eklentiler bulmaya çalışmalıdır. Javascript ve CSS'yi kapatmalı ve o zaman ne ile kaçabileceklerini görmelidirler. Bu tarz bir şey. Geliştiricilerin bunu yapmasını bekliyorsanız, çok fazla para harcıyorsunuz demektir.

İşe yaramayan bir işlevsellik sağlanıyorsa, sorun geliştirme ile KG arasında değil, geliştirme ile ürün sahipleri arasındadır.

Ürün sahipleri ve geliştiriciler aynı ekibin bir parçası olmalı ve bir özelliği "tamamlandı" olarak değerlendirmek için neyin çalışması gerektiğini tanımlamak ve kodun ihtiyacı karşıladığından emin olmak için birlikte çalışmalıdır.

Kod teslim edildiğinde, test sadece bir formalite olmalıdır, çünkü ürün sahiplerinin tüm kullanım durumlarının kapsandığından emin olmak için yol boyunca geliştiricilerle birlikte çalışması gerekirdi.

(Profesyonel test kullanıcılarınız varsa, bunlar ekibin bir parçası olmalı ve her aşamada yer almalıdır.)

Geliştiricilerden KG'ye girmeden önce kodlarının bir adım adım / demosunu vermelerini istediğimiz projeler için bir tarama sürecimiz var. Yalnızca KG test kullanıcılarını değil, kodun işletme sahiplerini, müşteri hizmetlerini ve pazarlama / tasarımını da ekliyoruz. Bu, geliştiricilere en azından kolay kullanım durumlarına odaklanma eğilimindedir ve bazen çeşitli ekipler arasındaki sonuç tartışması özelliklerde değişikliklere ve KG'ye girişte gecikmeye neden olur. Mümkün olduğunda, KG'yi süreçte çok daha erken sürece dahil ediyoruz, bu da kod hala sıcakken hataların düzeltilmesine yardımcı oluyor - ancak yine de "resmi" KG başlamadan önce izlenecek yolu yapıyoruz.

Bazen yanlışlıkla QA yerine üretime geçerse üzülürseniz, kodun KG'ye gönderilmemesi gerektiğini söyledim. Büyük işlev bozukluğu olan kod KG'ye ait değildir (belirli durumlar hariç)