Sistem testi için yazılım yayınlarken yeni özellikler eklemeden hataları düzeltmek doğru mudur?

Bu soru deneyimli test uzmanlarına veya test adaylarına yöneliktir. Bu bir yazılım projesinin senaryosudur:

Geliştirme ekibinin 10 özelliğin ilk yinelemesini tamamladığını ve sistem testine çıkardığını varsayalım. Test ekibi, bu 10 özellik için test senaryoları oluşturdu ve test için tahmini 5 gün oluşturdu. Geliştirme ekibi elbette 5 gün boyunca boşta kalamaz ve bir sonraki yineleme için 10 yeni özellik oluşturmaya başlar. Bu süre zarfında test ekibi hatalar buldu ve bazı hatalar kaldırdı. Hatalar önceliklidir ve bir sonraki yinelemeden önce bazılarının düzeltilmesi gerekir. Yakalama, yeni sürümü yeni özelliklerle veya mevcut özelliklerde yapılan değişikliklerle tüm bu hatalar düzeltilene kadar kabul etmemeleri. Test ekibi, hata düzeltmesiyle birlikte yeni özellikler de eklersek, test için kararlı bir sürümü nasıl garanti edebileceğimizi söylüyor. Ayrıca her tekrarında tüm test vakalarının regresyon testlerini yapamazlar.

Bu, dev ekibinin yalnızca hata düzeltmesi için bir kod dalı ve geliştirmeye devam ettikleri başka bir dal oluşturması gerektiği anlamına gelir. Yeniden düzenleme ve mimari değişikliklerle özel olarak daha fazla birleştirme yükü vardır.

Bunun ortak bir test prensibi olup olmadığını kabul edebilir misiniz? Test ekibinin endişesi geçerli mi? Projenizde pratikte bununla karşılaştınız mı?

Bunun yerine, yeni özelliklerin her sürümünün ayrı bir dalda olması gerektiğini söyleyebilirim. Bu, geliştirme ve sürümlerin ayrılmasını sağlar.

Son kullanıcılara yönelik sürümünüz bu süreçte nasıl çalışır? Sistem test ekibiniz geliştirme programı ile daha az ilgilenmeli ve bunun yerine müşteri sürüm planına odaklanmalıdır.

Geliştirme devam ederken yeni özellikleri resmi olarak test etmeye çalışmanın pek bir anlamı yoktur, çünkü sonraki 10 özelliğinizin aynı işlevselliğe dokunması ve bu alanları tekrar test etmelerini gerektirme olasılığı yüksektir.

Geliştirme sırasında ara dahili sürümleri gayri resmi olarak test etmeye devam edebilirler ve test tasarımlarını (umarım bu yeni özelliklerde hataların çoğunu yakalarlar) test edebilirler, ancak yeni özelliklerin ve regresyonun resmi testi için geliştirme sonunda ek bir süreye ihtiyaç duyacaklardır. test yapmak.

10 yeni özelliğinizi test etmek için 5 gün gerektiğini tahmin ettiklerinde, dikkate almaları gereken şey, geliştirme döngüsünün sonunda, müşterilere bırakılmadan önce yeni özellikleri doğrulamak için (ve muhtemelen tekrarlamak için daha fazla zamana) ihtiyaç duymalarıdır. hatalar bulunursa). Bu süre zarfında, müşteri sürümü test için ayrılabilir ve bir sonraki sürüm için yeni özellik geliştirme devam edebilir.

Karma bir yaklaşım kullanıyoruz. Müşteri sürümü için, kesinlikle sadece kritik hata düzeltmeleri için olan kendi şubemiz var.

Birden çok yazılım sürümünde düzenli geliştirme devam eder. Örneğin, en son kararlı sürümün 2.0 olduğunu varsayalım. Tüm riskli özellikler 3.0 şubesine eklenecektir. 2.0 hata sadece hata düzeltmeleri gider. Özel QA ekibi tarafından testler sadece kararlı dallarda yapılır. Müşteri sürümleri elbette 2.0 tabanlı başka bir şubeden yapılır. Bir sonraki nesil platform geliştirme gibi uzun süren özellikler, 3.0'da bile 4.0'da yapılacak.

Bütün bunlar kağıt üzerinde iyi görünüyor. Ancak bir müşteri belirli bir özellik isterse, 3.0 müşterilere sunulacak kadar kararlı olmadığı için 2.0 şubesine eklenmesi gerekir. Bu, KG ekibinin tüm regresyon paketini yeniden çalıştırmak zorunda kalacağı anlamına gelir.

Yaptığımız bir şey, her regresyon testi vakasının kod kapsamını yapmaktır. Özelliğin kod değişikliklerinden etkilenecek olan sadece bu regresyon testi vakaları çalıştırılır. Tabii ki, bir müşteri sürümü için tam regresyon paketi çalıştırılır.

Bu, yeni özelliklerin hata düzeltmeleri gerektiren bölümlerle ne kadar yakından ilişkili olduğuna bağlıdır. Örneğin, kullanıcı arayüzünün küçük bir bölümüne yeni sürükle ve bırak özelliği eklerseniz, kullanıcı tarafından yüklenen dosyanın ayrıştırılmasıyla ilgili hatayı 'etkilememelidir'.

Bunu söyledikten sonra, test edicilerin 'Ceteris paribus' (tüm 'diğer' şeyler eşittir) düzeltmelerini test etmek istedikleri anlaşılabilir (zorunlu olarak haklı değildir).

Yayınlanma şekli ve son kullanıcı beklentisiyle ilgili başka endişeler de olabilir. Örneğin, yalnızca bir kez hata düzeltmeleri + test ve bir yeni özellik + testten sonra serbest bırakmanız gerekebilir, çünkü kullanıcılar SADECE yeni özellikler olduğunda yeniden yüklemek veya yükseltmek isterler. Bazıları en öncelikli ASAP olarak düzeltmeler talep edebilir.

Bu (yaygın) sorunu her iki takımı birleştirerek birleştirebilirsiniz.

Geliştirme ekibi içindeki test cihazları, özellikler üretilirken test edilir, çoğu takımın çıktı kalitesini artırmasına yardımcı olabilir.

Sana gelen bu mükemmel blog yazısı okumak için önermek Henrik Kniberg açıklamak Kaban . Scrum sürecinde birçok fikir bulacaksınız ( Henrik Kniberg'in de ücretsiz kitabı ).

Ayrıca blogunda mükemmel bir Kanban VS Scrum makalesi yazdı .

Zevk almak.

Test ekibinin kesinlikle geçerli bir endişesi var, ancak her sürüm için birden fazla test yinelemesi ihtiyacını sorgulayacağım. Neden kullanıcıların hiçbir zaman görmeyecekleri bir kod sürümü üzerinde tam bir test yapalım?

Test kullanıcıları, bir müşteriye tanımlanmış bir sürüm almaya çalışıyorsa, bu yeni özellikler beklemiyorsa, istekleri makul, haklıdır ve teslim etmek için geriye doğru eğilmelisiniz.

Bu, normal geliştirme aşamalarında sadece "süreçlerine" yardımcı olmak ve hata listesinin kontrol dışı kalmadığından emin olmak ve ardından bir sorun çıkarmadan test etmek için, bu kısıtlamanın biraz gevşetilip giderilemeyeceğini test başlığına sorun. çıkış noktasına yaklaşıyoruz.

Kaynak kontrol sisteminizi dağıtılmış bir ürün olarak değiştirmeyi düşünün. Bu, böyle bir sürümün sunulmasını çok daha kolay hale getirecektir.

"Bunun ortak bir test prensibi olup olmadığını kabul edebilir misiniz?

Yes

Test ekibinin endişesi geçerli mi?

Yes

Bunu projenizde pratikte karşılaştınız mı? "

Yes

:

and Yes Merging is the downside of it 

Kimin sorumluluğunu sormadınız, ancak bu Configuration Manager'ın sorumluluğundadır. Bu akış stratejisi CMP'sinde olmalıdır. Aksi takdirde kovun. Bence Pierre 303'ün cevabı da çok iyi ama teknik olarak mümkün olduğu kadar (örneğin bir Siebel sürümünün düşünülmesi ...) ve örgütsel olarak.

Sorun şu ki, bir daldaki hataları test ederse, tekrar test etmeleri gerekir ve regresyon tekrar birleştirildikten sonra bagajda test edilmeleri gerekir (hangi iyi test cihazlarının nadiren olduğuna çok güvenmedikleri sürece). Bu sadece geliştiriciler için daha fazla iş yapmakla kalmaz, aynı zamanda test ediciler için daha fazla iş yapar.

Burada doğru bir cevap yok ama dikkate almanız gereken birkaç şey var:

• Bu hata sürümleri (yeni işlevler olmadan) kullanıcılara hiç gidebilir mi? Eğer öyleyse evet, dallanmış ve test edilmiş olmalı ve herkesin bunu genel gider olarak kabul etmesi gerekir.

• Yeni işlevselliği, uygulamanın tamamen ayrı alanlarında üzerinde çalışılmış olan önceki parçalara ayrılacak şekilde bölmek mümkün müdür? Eğer öyleyse bu size seçenekler sunar - test uzmanları uygulamanın tekrar testlerini ve regresyon testi bölümlerini gerçekleştirebilir. İdeal değil ama işe yarayan ve istediklerinden bazılarını verebilecek bir uzlaşma.

• Onları serbest bırakmak için ne kadar iş var? Genellikle bir acıdır, ancak gerçek iş miktarı normalde o kadar büyük değildir. Açıkçası onların da sadece onlar için daha fazla iş olmadığını doğrulamak zorundasınız (söylediğim ilk şeye bakın) ama bu işi yapan yerlerin olduğunu gördüm.

• Burada sürüm kontrolünü kullanmanın daha iyi bir yolu var mı? Mercurial ( http://hginit.com/ - okuyun, iyi)) veya başka bir dağıtılmış sürüm kontrol sistemi dallarını farklı bir şekilde birleştirir ve sorunu çözmenize izin verebilir. Gerçekten, bir göz atın çünkü sorununuzun cevabı olabileceğini düşünüyorum.

Ama iyi şanslar, bu bir acı. Her şeyden önce, en iyi yolun şirketinize, ürününüze ve durumunuza çok bağlı olacağını unutmayın, bu yüzden bunu düşündüğünüzden emin olun ve sadece raftan bir şey çekmeyin ve% 100'e uymanız gerektiğine inanın.

Açıkladığınız hatalar gerçek kusurlarsa ve tasarım optimizasyonları değilse , evet, yeni özellikler üzerinde çalışmaya başlamadan önce bunları düzeltmeye çalışmalısınız.

Bilinen hataların üzerine yeni özellikler oluşturursanız, bir kart evi oluşturuyorsunuz. Muhtemelen kırılgan, öngörülemeyen bir yazılım geliştirebilirsiniz. Buggy kodu ve yeni özellikleriniz arasındaki yalıtım düzeyine bağlı olarak, hatalar yeni özelliklerinizi de etkileyebilir. Öyleyse, yeni özelliklerinizin doğru çalışıp çalışmadığını nasıl anlarsınız?

İlk olarak hatalarınızı düzeltirseniz, eklediğiniz yeni özellikler için daha güçlü bir temeliniz olacaktır.

Elbette, dış güçlerin sizi daha iyi muhakemenize karşı baskı yapmaya zorladığı zamanlar vardır. Karar vericilerin, her iki hareket tarzının (yani çözümlenemeyen kusurlar ve kaçırılan özellik teslim tarihlerine karşı) sonuçlarının farkında oldukları ve kararlarını kullanmalarına izin veren bilinçli bir karara ulaşmalarına yardımcı olmaya çalışın. Bazen tercih edilmemesine rağmen bir hareket tarzının gerekli olduğu yasal ve finansal nedenler vardır.

Yeni özellikler eklemeden önce her zaman hataları düzeltmeye çalışın!

Çalıştığım yerde üretime yönelik her bir sürümün kendi dalı olduğu bu senaryoyu ele alıyoruz. Örneğin, bir saniye haziran ayı sonunda ve bir diğeri de temmuz sonunda bir tahliye olacağını varsayalım. Haziran sürümü kendi şubesini alacak ve tüm özellikler oraya eklenecek ve KG'ye gönderilecekti. Bu noktada July'in serbest bırakılması ve Haziran'ın şubesinden dal üzerinde çalışmaya başlayacağız. KG hataları bulduğunda bunları Haziran'ın şubesinde düzeltiriz ve düzeltmeler KG'ye gönderildikten sonra July'in yayın şubesine birleştirilir. Bu, bu birleşmeleri işlemek için biraz ek yük getirir, ancak tipik olarak birleşmeler oldukça ağrısızdır. Arada sırada ne büyük bir acı olduğunu biliyorsunuz, ancak bu sadece toptan değişiklikler yapıldığında gerçekleşir ve bunlar KG döngüsü sırasında gerçekleşmemelidir (ancak gerçekleşir, kabul ettiğimden daha fazla). Ancak iyi bir test paketi (birim ve entegrasyon), kod kapsamı ve diğer tüm TDD terimleriyle riskler biraz azaltılır. Yardım etmek için, tipik olarak her proje için bir kişi işlemektedir.