Geliştirme ekibimiz GitFlow dallanma stratejisini kullanıyor ve bu harika oldu!
Yakın zamanda yazılım kalitemizi iyileştirmek için birkaç test görevlisi işe aldık. Buradaki fikir, her özelliğin bir test cihazı tarafından test edilmesi / KG'nin yapılması gerektiğidir.
Geçmişte geliştiriciler, ayrı özellik dallarındaki özellikler üzerinde çalışırlar ve tamamlandığında bunları tekrar dalda birleştirirler develop. Geliştirici, çalışmasını o featuredalda kendisi test edecektir . Şimdi testçilerle bu soruyu sormaya başladık
Test cihazı yeni özellikleri hangi dalda test etmelidir?
Açıkçası, iki seçenek var:
- bireysel özellik dalında
- üzerinde
developşube
Geliştirme Dalında Test Etme
Başlangıçta, bunun kesin bir yol olduğuna inandık çünkü:
- Özellik,
developgeliştirme başladığından beri şubeye birleştirilen diğer tüm özelliklerle test edilir . - Herhangi bir çakışma daha sonra tespit edilebilir
- Testçinin işini kolaylaştırır,
developher zaman yalnızca bir şubeyle ( ) ilgilenir . Geliştiriciye hangi dalın hangi özellik için olduğunu sormasına gerek yoktur (özellik dalları, ilgili geliştiriciler tarafından özel olarak ve ücretsiz olarak yönetilen kişisel dallardır)
Bununla ilgili en büyük sorun şudur:
developŞube böcek kirlenmektedir.Test kullanıcısı hatalar veya çakışmalar bulduğunda, bunları geliştiriciye geri bildirir, bu sorunu geliştirme dalında düzeltir (özellik dalı birleştirildikten sonra terk edilmiştir) ve sonrasında daha fazla düzeltme gerekebilir. Birden çok alt dizinin tamamlanması veya birleştirilmesi (bir dal,
develophataları düzeltmek için daldan yeniden oluşturulursa ),developmümkünse , özelliğin daldan geri alınmasını çok zor hale getirir . Şubeyedevelopfarklı zamanlarda birleşen ve sabitlenen birden çok özellik vardır . Bu,developdaldaki özelliklerden yalnızca bazılarıyla bir sürüm oluşturmak istediğimizde büyük bir sorun yaratır.
Özellik Dalında Test Etme
Bu yüzden tekrar düşündük ve özellikleri özellik dallarında test etmemiz gerektiğine karar verdik. Test etmeden önce, developdaldan özellik dalına yapılan değişiklikleri birleştiriyoruz (dalı yakalayın develop). Bu iyi:
- Hala özelliği diğer ana akım özelliklerle test ediyorsunuz
- Daha fazla geliştirme (örneğin, hata düzeltme, anlaşmazlığı çözme)
developşubeyi kirletmeyecektir ; - Tam olarak test edilip onaylanana kadar özelliği serbest bırakmamaya kolayca karar verebilirsiniz;
Ancak bazı dezavantajlar var
- Test uzmanı, kodu birleştirmek zorundadır ve herhangi bir çakışma varsa (büyük olasılıkla), geliştiriciden yardım istemelidir. Test uzmanlarımız test konusunda uzmanlaşmıştır ve kodlama yeteneğine sahip değildir.
- bir özellik, başka bir yeni özellik olmadan test edilebilir. Örneğin, Özellik A ve B aynı anda test altındadır, iki özellik birbirinden habersizdir çünkü ikisi de
developdalda birleştirilmemiştir . Budevelop, her iki özellik yine de geliştirme şubesiyle birleştirildiğinde , şubeye karşı tekrar test etmeniz gerekeceği anlamına gelir . Ve bunu gelecekte test etmeyi unutmamalısın. - Özellik A ve B hem test edilmiş hem de onaylanmışsa, ancak birleştirildiğinde bir çakışma tespit edilirse, her iki özelliğin geliştiricisi de bunun kendi hatası / işi olmadığına inanır çünkü özellik dalı testi geçmiştir. İletişimde fazladan bir yük vardır ve bazen çatışmayı çözen kişi hüsrana uğrar.
Yukarıdaki hikayemiz. Sınırlı kaynakla, her şeyi her yerde test etmekten kaçınmak isterim. Bununla başa çıkmanın daha iyi bir yolunu hala arıyoruz. Diğer takımların bu tür durumlarla nasıl başa çıktığını duymak isterim.
