Size verecek herhangi bir araştırma makalem veya istatistikim yok, ancak deneyimlerimi tarihsel olarak düşük ortalama bir birim test kapsamı olan ve uçtan uca testler olmayan ve yavaş yavaş bir ekip / kuruluşta çalışmaktan alacağım. daha fazla ATDD (ama ironik bir şekilde geleneksel TDD değil ) yaklaşımıyla çıtayı şu anda bulunduğumuz yere taşımak .
Özellikle, proje zaman çizelgeleri aynı organizasyondaki diğer ekiplerde / ürünlerde oynamak için kullandı:
- 4 haftaya kadar analiz ve uygulama
- 2 haftalık regresyon testi, hata düzeltme, stabilizasyon ve salım hazırlığı
- Bilinen kusurları gidermek için 1-2 hafta
- 2-3 haftalık kod temizleme ve üretim sonrası sorunlar / destek (bilinmeyen hatalar / planlanmamış kesintiler)
Bu saçma bir yük gibi görünüyor, ancak aslında çok yaygın, çoğu kuruluşta genellikle eksik veya etkisiz KG ile maskeleniyor. İyi test edicilerimiz ve yoğun test kültürümüz var, bu nedenle bu konular aylarca / yıl boyunca yavaşça oynamalarına izin vermek yerine erken yakalanır ve ön tarafta (çoğu zaman) sabitlenir. % 55-65 bakım yükü, hata ayıklama için harcanan zamanın% 80'inin genel kabul görmüş normundan daha düşüktür - bu makul görünüyor, çünkü bazı birim testlerimiz ve çapraz fonksiyonel ekiplerimiz (KG dahil) vardı.
Ekibimizin en son ürünümüzün ilk sürümünde, kabul testlerini güçlendirmeye başlamıştık, ancak enfiye etmek için yeterli değildiler ve hala birçok manuel teste güvenmek zorunda kaldık. Serbest bırakma diğerlerinden biraz daha az acı vericiydi, IMO kısmen gelişigüzel kabul testlerimizden ve kısmen de diğer projelere göre çok yüksek birim test kapsamımızdan dolayı. Yine de yaklaşık 2 hafta regresyon / stabilizasyon ve 2 hafta da post prodüksiyon konularında geçirdik.
Buna karşılık, bu ilk sürümden bu yana yapılan her sürümde erken kabul kriterleri ve kabul testleri vardı ve mevcut yinelemelerimiz şöyle görünüyor:
- 8 günlük analiz ve uygulama
- 2 günlük stabilizasyon
- 0-2 kombine günlerde üretim sonrası destek ve temizlik
Başka bir deyişle,% 55-65 bakım yükünden% 20-30 bakım yüküne geçtik. Aynı ekip, aynı ürün, temel fark kabul testlerimizin aşamalı olarak iyileştirilmesi ve düzenlenmesi.
Bunları sürdürmenin maliyeti, sprint başına bir KG analisti için 3-5 gün ve bir geliştirici için 1-2 gündür. Ekibimizin 4 geliştiricisi ve 2 KG analisti var, bu yüzden (UX, proje yönetimi vb. Sayılmaz) 60 üzerinden en fazla 7 adam-gün, ki bu sadece devam etmek için% 15 uygulama yüküne yuvarlayacağım güvenli tarafı.
Her bir serbest bırakma döneminin% 15'ini otomatik kabul testleri geliştirerek geçiriyoruz ve bu süreçte her bir serbest bırakmanın% 70'ini regresyon testleri yaparak ve üretim öncesi ve üretim sonrası hataları düzeltebiliyoruz.
İkinci zaman çizelgesinin birincisinden çok daha kesin ve daha kısa olduğunu fark etmiş olabilirsiniz. Bu, ön kabul kriterleri ve kabul testleri ile mümkün kılınan bir şeydir, çünkü "yapılan tanımını" büyük ölçüde basitleştirir ve bir sürümün kararlılığına daha fazla güvenmemizi sağlar. Başka hiçbir ekip (şimdiye kadar), belki de oldukça önemsiz bakım sürümleri (yalnızca hata düzeltme, vb.) Yapma durumu dışında, iki haftalık bir yayınlama programını başaramadı.
Bir başka ilginç yan etki ise, yayınlama programımızı iş gereksinimlerine uyarlayabilmemiz. Bir kez, başka bir sürümle çakışmak için yaklaşık 3 hafta uzatmamız gerekiyordu ve bunu daha fazla işlevsellik sunarken, ancak test veya stabilizasyon için fazladan zaman harcamadan yapabildik. Başka bir zaman, tatil ve kaynak çatışmaları nedeniyle yaklaşık 1½ haftaya kısaltmak zorunda kaldık; daha az geliştirme çalışması yapmak zorunda kaldık, ancak beklendiği gibi, yeni kusurlar ortaya koymadan test etme ve stabilizasyon için daha az zaman harcayabildik.
Deneyimlerime göre, kabul testleri, özellikle bir proje veya sprintte çok erken yapıldığında ve Ürün Sahibi tarafından yazılan kabul kriterleri ile bakıldığında, yapabileceğiniz en iyi yatırımlardan biridir. Diğer insanların doğru bir şekilde işaret ettiği geleneksel TDD'den farklı olarak, hatasız koddan ziyade test edilebilir kod oluşturmaya odaklanmıştır - ATDD gerçekten kusurları çok daha hızlı yakalamaya yardımcı olur ; her gün tam bir regresyon testi yapan, ancak çok daha ucuz bir testçi ordusuna sahip olmanın örgütsel eşdeğeridir.
ATDD, RUP veya (ugh) Şelale tarzında yapılan uzun vadeli projelerde, 3 ay veya daha uzun süren projelerde size yardımcı olacak mı? Bence jüri hala bu konuda. Deneyimlerime göre, uzun süredir devam eden projelerde en büyük ve en çirkin riskler gerçekçi olmayan teslim tarihleri ve değişen gereksinimlerdir. Gerçekçi olmayan son tarihler, insanların test kısayolları da dahil olmak üzere kısayolları almasına neden olur ve gereksinimlerdeki önemli değişiklikler büyük olasılıkla çok sayıda testi geçersiz kılarak yeniden yazılmasını ve uygulama yükünü potansiyel olarak şişirmesini gerektirir.
ATDD'nin Agile modelleri veya resmi olarak Agile olmayan ancak çok sık sürüm programları olan takımlar için harika bir getirisi olduğundan eminim. Asla uzun vadeli bir projede denemedim, çünkü bu tür bir projede denemek isteyen bir kuruluşta hiç duymadım, hatta duymadım, bu yüzden standart feragatnameyi buraya ekleyin. YMMV ve hepsi.
PS Bizim durumumuzda, "müşteri" fazladan çaba gerekmez, ama biz gerçekten kabul kriterleri yazan özel, tam zamanlı bir Ürün Sahibi var. "Danışmanlık yazılımı" işindeyseniz, son kullanıcıların yararlı kabul kriterleri yazmasını sağlamanın çok daha zor olabileceğinden şüpheleniyorum . Bir Ürün Sahibi / Ürün Yöneticisi, ATDD yapmak için oldukça önemli bir unsur gibi görünüyor ve bir kez daha sadece kendi deneyimlerimden konuşabilmeme rağmen, ATDD'nin bu rolü yerine getirecek biri olmadan başarılı bir şekilde uygulandığını hiç duymadım.
