Otomatik testler nasıl popüler hale getirilir? [kapalı]

13

Kod tabanımız 20 yıldır büyüyor. 500kloc ile çalışan yaklaşık 10 devs + sqa'yız. Bir süre önce küçük bir ekibimiz (2 geliştirici, biri sqa'dan) otomatik bir test programı üzerinde çalışmaya başladı. Şu anda bir çalışma 11 saat sürüyor ve bir şekilde bir entegrasyon testidir. Bunu azaltmak ve yanlış pozitifleri azaltmak için çalışıyoruz ve bu konuda iyi ilerleme kaydediyoruz. Ancak ayrıntılar önemli değil.

İyi çalışıyor ve geliştirmeye devam ediyoruz. Biz (küçük ekip) çok beğendik. Bir şeyi kırarsak, bir gün sonra ve 2 ay sonra sqa'ya baktığında fark ederiz. Ayrıca, yöneticilerimiz (dev + sqa) fikri beğendiler. Ancak takımdaki diğer insanlar test sonuçlarını görmezden geliyorlar. Onların aklında, eğer bir check-in sonrasında testler başarısız olursa, kod değişikliği değil testin bir problemi ve bu sadece bizim oyuncak projemiz. Başarısız bir testin gerçek bir hata olması durumunda birkaç kez tartıştık. Çoğu zaman öyledir.

Bir şeyi zorlayamayız ve istemeyiz. Otomatik testin bir şey olduğunu nasıl gösterebiliriz?

testing  integration-tests 
— Peter Schneider
kaynak
11
Bu bir Yazılım Mühendisliği sorunu değildir; bu bir insan sorunu.
— Robert Harvey
@RobertHarvey Ben "görüş tabanlı" ve bu sitenin mükemmel (ve bu yorum upvotes) uygun bir yorum çünkü SO aşağı oy var. Peki: nereye sormalıyım? Beni eğit.
— Peter Schneider
2
Bu bir insan sorunu olma konusunda @RobertHarvey ile birlikteyim. Ama İşyerine göre, sorunuz muhtemelen bir dupe olarak değerlendirilecek. Örneğin, temel olarak işyerinde
— Peter M
1
Bu downvoter'ların (hatta yakın oyların) sizi caydırmasına izin vermeyin! Bazı insanlar bu tür soruların önemli olduğunu anlayabilir ve belki de yardım sağlayabilir. Bu arada, meslektaşlarım da önceki testlere (otomatik testler olmadan) bir hata kutusu olmasına rağmen otomatik testlerin kullanışlılığını göremiyorlar. Sadece bir şeyi değiştirin ve görünüşte ilgisiz birkaç şeyi kırın. Bazı insanlar sadece öğrenmek istemiyorlar (yeni şeyler öğrenmeye karşı açık bir direnç var).
— Bernhard Hiller
1
Bu sorunun kapatıldığı bir utanç. Yazılım mühendisliği bir şey ifade ediyorsa, gerçek insanlarla çalışmanın sorunları anlamına gelir ve bu tür sorunların cevapları fikirleri içerir. Bununla birlikte, birkaç hızlı fikir: (1) testler yanlış negatifler verirseniz, bu kesinlikle geri dönüşü artıracaktır, çünkü sonuçlar zaman kaybı gibi hissedecektir; (2) mümkünse çalışma zamanını azaltın. İki saatten daha iyi olsa bile 11 saat hemen hissetmez; (3) sqa bu testleri izledikleri metrikler olarak benimseyecektir. zaten bu bölgedeki kuruluşunuz tarafından tanınıyorlar.
— Dale Hagglund

Yanıtlar:

4

feragat

Yönetici gibi görünsem de, bunu otomatik testlerin iyi olduğuna ikna edilmesi gereken bir geliştirici olarak yazdım.

Geliştiricilerin temel psikolojisini anlamalısınız. Kod geliştiricilerin kökleşmiş bir ihtiyacıdır. Bunu yapmalarını engelleyen her şey çok, çok kötü bir şeydir. Başarısız test kesinlikle onların bunu yapmasını engelleyen bir şeydir, ergo bu kötü bir şeydir. Böylece direnç.

Dikkat etmeniz gereken şey, otomatik testlerin kısa vadede onları yavaşlatmasına rağmen, uzun vadede onları çok fazla kederden koruyacak ve aslında hızlandıracak, çünkü bunların geliştirilmesine daha fazla odaklanabilecekler. ve geliştiricilerin yapmaktan nefret ettiği diğer şeyleri yapmak için daha az zaman kaybedecek: hataları düzeltmek.

Ve evet, zorlamalısınız. Yönetimden koşulsuz destek almalı ve otomatik testler yazmayı zorunlu ve pazarlıksız hale getirmelisiniz. Zamanla, geliştiriciler onlara alışacaklar. Ne kadar yeni gelişme yapıldığını ve otomatik testleri başlattığınızdan bu yana hata sayısının ne kadar azaldığını gösterecek bazı metrikler tasarlayabiliyorsanız yardımcı olacaktır. Kelimeler uçucudur. Sayılar sağlam. Ve sayılar, ortalama bir geliştiricinin kelimelerden daha iyi anladığı bir şeydir. Otomatik testlerin iyi olduğunu sağlam sayılar kullanarak kanıtlayabilirseniz, onlara çok az direnç gösterecek veya hiç direnç göstermeyeceksiniz.

— Vladimir Stokic
kaynak
11

Onların aklında, eğer bir check-in sonrasında testler başarısız olursa, kod değişikliği değil testin bir problemi ve bu sadece bizim oyuncak projemiz. Başarısız bir testin gerçek bir hata olması durumunda birkaç kez tartıştık. Çoğu zaman öyledir.

Sorun burada. Testleriniz kesintili ise ('çoğu zaman güvenilir' olsalar bile), insanlar sonuçları görmezden gelme eğiliminde olacaktır. Otomasyon ekibiniz bu yanlış negatifleri ortadan kaldırmaya odaklanmalıdır. Ancak o zaman ekibin geri kalanı sonuçlara gerçekten güvenmek için yeterli güven kazanacaktır.

— Eternal21
kaynak
5
Sonra tekrar, başka bir şey olabilir. Değişime karşı direnç gibi. Bir test başarısız olursa, her zaman düzeltilecek bir şey vardır, ya kod ya da test, bu yüzden testlerin kesiştiği için insanların testleri göz ardı edeceği tutumu yanlış yerleştirilmiştir.
— Robert Harvey
Bir şeyin kırıldığından emin olduğumuzda onlarla konuştuk (örneğin, testin söz konusu işlevselliği etkilemesinden sonra 3 kez başarısız oldu). Ancak evet, güvenilirliği artırmak şu anki önceliktir.
— Peter Schneider
1
@PeterSchneider bir test arka arkaya 100 kez başarısız olabilir, özellikle test yanlışsa bunu yapar.
— Pieter B
Öte yandan, asla başarısız olmayan bir test büyük olasılıkla tamamen işe yaramaz
— Vladimir Stokic
1
+1 Kırılgan testler kesinlikle bir sorundur. Geliştiriciler, yazdıkları testlerin yararlı olduğuna, gereksiz komplikasyonlara neden olmadığına ve meşgul çalışmadığına ikna edilmelidir .
— Andres F.13
6

Bir şeyi zorlayamayız ve istemeyiz.

Kesinlikle zorlamalısınız! Birisi yeni kod iterse ve testler başarısız olursa kod reddedilmelidir! Daha büyük bir yazılım projesini güvenilir bir şekilde sürdürmenin tek yoludur.

— Banan
kaynak
Sanırım bu sisteme, testlere, ölçeğe ve geliştirme sürecine bağlı. Tüm hatalar hemen çözülemez ve tüm sorunların hemen çözülmesi gerekmez.
— NickL
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.