Birim test geliştirme veya test mi?

Birim yöneticisi ile birim ve entegrasyon testinin rolü hakkında bir tartışma yaptım. Geliştiricilerin birim ve entegrasyon testlerinin ne olduğunu ve nasıl yapıldığını bildirmelerini istedi. Benim bakış açım, birim ve entegrasyon testlerinin test sürecinin değil geliştirme sürecinin bir parçası olduğu. Anlambilimin ötesinde demek istediğim, birim ve entegrasyon testlerinin test raporlarına dahil edilmemesi ve sistem test uzmanlarının onlar hakkında endişelenmemesi gerektiğidir. Akıl yürütmem iki şeye dayanıyor.

1. Her zaman bir arayüz ve sözleşmeye karşı birim ve entegrasyon testleri planlanır ve gerçekleştirilir. Resmi sözleşmeleri kullanıp kullanmadığınızdan bağımsız olarak, örneğin bir yöntemin yapması gereken, yani bir sözleşmenin ne olduğunu hala test edersiniz.

   Entegrasyon testinde iki farklı modül arasındaki arayüzü test ediyorsunuz. Arayüz ve sözleşme , testin ne zaman geçeceğini belirler. Ancak her zaman tüm sistemin sınırlı bir bölümünü test edersiniz. Diğer taraftan, sistem testi sistem spesifikasyonlarına göre planlanmakta ve gerçekleştirilmektedir. Spesifikasyon testin ne zaman geçeceğini belirler.

2. Birimin genişliğini ve derinliğini ve entegrasyon testlerini (sistemler) test cihazına iletmede hiçbir değer görmüyorum. Belirli bir iş katmanı sınıfında ne tür birim testlerinin yapıldığını listeleyen bir rapor yazdığımı varsayalım. Bundan ne çıkarması gerekiyor?

   Neyin test edilmesi ve neyin test edilmemesi gerektiğine karar vermek yanlış bir sonuçtur, çünkü sistem tüm ünite ve entegrasyon testleri geçse bile özelliklerin gerektirdiği şekilde çalışmayabilir.

Bu işe yaramaz bir akademik tartışma gibi gözükebilir, ancak benim gibi kesinlikle resmi bir ortamda çalışıyorsanız, işlerin nasıl yürüdüğünü belirlemede önemlidir. Her neyse, tamamen yanlış mıyım?

Otomatikleştirilmiş testler yazmak bir geliştiricinin işidir; Testler kod tabanının bir parçasıdır ve bu şekilde ele alınmalıdır - bunlar projenin geri kalanıyla aynı kod incelemelerine, kodlama standartlarına, kaynak kontrol disiplinine vb. tabi olmalıdır.

Bu testlerin yapılması iki nedenden ötürü yapılır: Birincisi, geliştiricilere yol gösterici bir araç olarak. Yeni yazdığınız kodun yapılması gerekeni yaptığını, ek belgeler olarak kullandığınızı ve değişikliklerin varolan herhangi bir işlevselliği bozmadığını doğrulamak için testler yaparsınız. Gerçek bir TDD yaparsanız, testler aynı zamanda teknik özelliklerin yetkili kaynağıdır. Testleri kullanmanın ikinci nedeni KG ve dağıtım sırasındadır. Tüm otomatik testlerin yapılması, her test turunda ilk adımlardan biri olmalıdır; otomatik testlerin yapılması ucuzdur (neredeyse hiç insan gücü gerektirmez) ve otomatik testlerin başarısız olması durumunda manuel testlere girmenin bir anlamı yoktur.

Bu, sorumlulukların şöyle olması gerektiği anlamına gelir:

• Geliştiriciler otomatik testler yazar
• Geliştiriciler, geliştirme iş akışlarının bir parçası olarak gerektiğinde bireysel otomatik testler gerçekleştirir
• KG, tüm otomatik testleri testin ilk aşamalarından biri olarak gerçekleştirir

Bir yapı sunucunuz varsa, KG'nin görevi (otomatik testlerle ilgili olarak) "yapı sunucusunun raporunu açmak ve her şeyin yeşil olduğunu doğrulamak" anlamına gelir.

Bence sizin için en önemlisi, bu rapora niye ihtiyaç duyduğunu açıklamak olacaktır .

Çok farklı stratejiler gerektiren farklı açıklamalar olabilir (birkaç cevapla önerildiği gibi).

• Makul bir kişi ise, sadece test ekibinin çalışmasına yardımcı olmak için bilgi edinmek isteyen ortak bir anlayışa sahip olmak ve her ikinize de uygun bir çözüm bulmak mantıklı olacaktır. Birim testlerinin mahiyeti ve birim - fonksiyonel / sistem / kabul testleri arasındaki temel farkı onunla tartışabilirsiniz. Umarım bu çalışmaların çok farklı seviyelerde olduğunu ve ikisinin de yerini alamayacağını anlayabilirsiniz.
• eğer bir kontrol manyağı ya da bürokrat ise, sadece onun uğruna bir rapor talep ederek, kaprislerini en az çaba ile karşılamak için bir şeyler üretebilirsiniz (örneğin, @Doc'un önerdiği :-).
• eğer biraz güç oyunu oynuyorsa, geliştiricilerden rapor talep etme hakkına sahip olup olmadığını sorgulayabilirsiniz. Tecrübelerime göre, geliştiricilerin genellikle KG departmanına rapor vermemeleri gerekiyor.

Kalite Güvencesi ve Gelişim'in rolü ile etkileşimin kuruluşlar arasında çok çeşitli olduğunu düşünüyorum. Ancak genel olarak ekibimde, üyelere katılmayı temel olarak bir QA ekibi yokmuş gibi yapıp, üretime soktukları değişikliklerden sorumlu oldukları anlamında söylüyorum. Sırasıyla, Kalite Güvence ekibimiz geliştirici testleri konusunda pek fazla bir fikre sahip değil ve sistemi işlevsel bir bütün olarak test etmek için yeterli miktarda çalışıyor.

Bu nedenle, QA ekibimiz, teste başlamadan önce ünite testli olan ve olmayan şeyler hakkında pek fazla umrunda değil.

QA ekibinin ünite testlerinin ne yaptığını ve üst düzeyde kapsamadığını anlamalarının yararlı olduğunu düşünüyorum, böylece boşlukları ve daha fazla titizlik gerektiren alanları tespit etmek için toplu olarak çalışabiliriz. Belki meslektaşınız, kanlı ayrıntıların aksine yüksek bir özetin peşindedir.

Devs, neyin ve entegrasyon testlerinin ne olduğunu ve nasıl test edildiğini bildirmek için ısrar etti.

Gerçekten bu tür bir testin aslında “geliştirme” alanında olup olmadığını tartışmaya mı çalışıyor, yoksa sadece kodunuzun birim testiyle ne kadar iyi karşılandığını anlamaya mı çalışıyor? Verdiğiniz bilgilere bakarak, kodun hangi kısımlarının kapsandığını ve ekibinin çabasını nereye odaklaması gerektiğini bilmek istiyor gibi görünüyor.

Gelişim rolüne geçmeden önce okul dışında bir test ekibinde çalıştım ve bunun onun ve ekibinin ne kadar değerli olabileceğini görebiliyorum.

Bunun çok önemli olduğunu anlamıyorum.

Onları KG / Test'e sağlamazsanız ve uygun testler yapmazlarsa ve üretimde başarısız olurlarsa, KG'nin belirtilen şekilde çalıştığını doğrulamadan üretime sokmasını sağlamak onların hatasıdır.

Onları KG / Test'e sağlarsanız ve uygun testler yapmazlarsa, vermemiş olmanızla aynı sonucu verir.

Ancak, eğer bunları sağlarsanız, bunları teknik özelliklerle de karşılaştırabilirler ve / veya hangi testlerin hatalı olabileceğini veya bir hata buldukları için değiştirilmesi gerekebileceğini önerebilirler.

Gerçekten, onları sağlamada pek dezavantaj göremiyorum. Spesifikasyonu doğrulamak için hala QA / test yapılıyor. Eğer tembel bir şekilde ilerlerlerse ve sadece testlerinizin yeterince iyi olduğuna güvenirlerse, çünkü hepsi geçtiler, işlerinde başarısız olan onlar. Spesifikasyona hala sahip oldukları sürece, ünite / entegrasyon testlerinin sonuçları tamamen kabarıktır ve size bir şekilde zarar vermemelidir. Dev ve QA'nın nedeni budur. Uygulamanın belirtildiği gibi yaptığı birden çok kontrol.

Devs hatalar yapar, QA hata yapar, ideal olarak ikisi de aynı maddede hata yapmazlar ... ve yaparlarsa, topu belirsiz bir şekilde yazıp düşüren bir analist olabilir.

Birim testi, kod parçalarının kendi başlarına nasıl çalıştığını anlamak için testlerin faydalı olabileceği geliştiricilerin sorumluluğundadır. Bazıları bunu bir dokümantasyon şekli olarak görebilir ve bu nedenle birimin testleri düzenli olarak değiştirilirse genel gider olmasına rağmen bazı değerleri vardır.

Testlerin geçilmesinde bir diğer değer, bunun, temel işlevselliği sağlama açısından gereksiz olabilecek testleri iki katına çıkarmaktan kaçınabileceğidir.

Son kullanıcı bir sistemin nasıl işleyeceği konusunda kendi anlayışına sahip olabileceğinden, bunlardan ayrı bir kullanıcı kabul testi de vardır.

Şirketinizin ürünlerinin kalitesini sağlamak için tanımlanmış bir metodolojisi varsa (eğer SOX ile uyumlularsa veya CMMI seviyelerini yükseltmeye çalışıyorlarsa, muhtemelen yaparlar), o zaman ürünler, sürecin gösterilmesi için denetlemeye dayanabilmelidirler. Takip edildi.

Genelde, tanımlanan işlem birim testini içerir (bu iyi bir şeydir). Ne yazık ki, bu aynı zamanda birim testlerinizi belgelemeniz ve denetlemeye ayak uydurmak için çalıştıklarını kanıtlamanız gerektiği anlamına gelir. Bu, birim testlerinizi rapor etmek için bir yola ihtiyacınız olduğu anlamına gelir.

Size yardımcı olmak için Sonar gibi bir araca bakın; kod kapsamı düzeyini ve birim testinizin sonuçlarının sonuçlarını bildirir.

Bu gerçekten şirkete bağlı, ancak benim tecrübeme göre hem geleneksel bir yaklaşımda hem bir sistem testcisi hem de CD modelinde çevik bir ekipte çalışan bir test cihazı olarak çalıştığımdan beri, ünitenin ne olduğunu ve test edilmesinin ne kadar yararlı olduğunu bilmek çok yararlı.

Kalite ekibin sorumluluğundadır - hem geliştiriciler, hem test edenler hem de Ürün Yönetimi ve birlikte çalışmak, bunu sağlamanın en iyi yoludur.

Bu nedenle test yöneticisi neyin ve entegrasyonun test edildiğini bilmek istiyor ve geliştiriciler için biraz daha fazla iş yapıyor ama proje için genel çalışmayı kurtarıyor! Bilgileri test yöneticisine vererek, test ekibi çabalarını neyin kritik ve önemli olduğuna odaklayabilirler. Daha önce de belirtildiği gibi, eğer bir kod alanı birim test edilmemişse, ekip burada yoğun bir şekilde test edilen bir alana kıyasla çabalarını odaklayabilir - neden bu çabayı yineliyorsunuz? Hepiniz zamanında yayımlanan daha yüksek kalitede yazılımın aynı nihai hedefi için çalışıyorsunuz.

Bu tür bir şeyi sağlamanın yararlı olacağını düşünüyorum. Birim test kapsamı, bunu hesaba katmak için geliştirme ve test etme ile bilinen bir şey olmalıdır.

Açıkçası, ne olursa olsun işle ilgili kritik konuları test etmeniz gerekiyor. Sık kullanılan ünite kapsamına sahip olup olmadığına bakılmaksızın yaygın olarak kullanılan işlevselliği zor test etmeniz gerekir. Başka hangi yerlerin ünite testleri ile kapsandığını bilmelerini sağlamak incinemezdi. Bu küçük kontrolde kod zaten son durumları kontrol ediyor mu? Bu tür şeyler işin her tarafında bilmek yardımcı olur.

"Google Yazılımı Nasıl Test Ediyor" kitabında tartışılan yaklaşımdan bahsetmeye değer: Test ve Kalite Kontrol herkesin sorumluluğundadır ve standartlar çok katıdır.

Gerçek geleneksel olarak "Test" bölümü denen rolü aslında geliştirici verimliliği olduğu; Örn. ekonomik olarak kurumun istenen titizlik seviyesine ulaşmasını sağlamak için otomasyon.