En büyük müşterinize ulaşan ilk hata bir araç tarafından yakalanmayacak. "Bunu yayına almadan önce çalıştığını nereden bileceğiz?" sorusunu kimse sahiplenmediği için sızacak. Bir girişimde bu soru şaşırtıcı derecede uzun bir süre yanıtsız kalır — ta ki size bir yenilemeye mal olduğu güne kadar.
Kurucular QA'ya, tıpkı bir yangın söndürücüye sarıldıkları gibi sarılma eğilimindedir: duman çıktıktan sonra. Talebin "bize birkaç test uzmanı alın" olduğu bir düzine danışmanlığa dahil edildim. Bu neredeyse hiçbir zaman doğru ilk hamle olmadı.
Kadro sayısıyla değil, riskle başlayın
Tek bir test senaryosu yazmadan ya da tek bir ilan yayınlamadan önce, bozulduğunda gerçekten neyin acıttığı konusunda somutlaşın. Bir ödeme akışının çökmesi, bir ipucu balonunun iki piksel kaymış görünmesinden bambaşka bir evrendir. Ürününüzü üç kategoriye ayırın:
- Para ve güven yolları — ödeme, kimlik doğrulama, veri bütünlüğü, bir düzenleyicinin ya da bir iadenin dokunduğu her şey.
- Temel günlük iş akışları — her aktif kullanıcının her oturumda yaptığı üç ya da dört şey.
- Diğer her şey — tepkisel olarak düzeltmeyi göze alabileceğiniz uzun kuyruk.
Erken QA çabanızın yüzde doksanı ilk iki kategoriye aittir. Bu adımı atlarsanız, yanlış şeyleri koruyan ve pahalı başarısızlıkların yine de sızmasına izin veren güzel bir test paketi kurarsınız.
İlk işe alımınız bir unvan değil, bir zihniyettir
İçgüdü, her sürümden önce uygulamada tıklayarak gezen bir manuel test uzmanı işe almaktır. Bu size bir haftalık huzur ve ömür boyu sürecek bir darboğaz kazandırır. Erken dönemde asıl istediğiniz kişi ise şudur: bir şeyleri kırmaktan hoşlanan bir mühendis — ki bu kişi, alışkanlıkları ekibin çalışma biçimine yerleştirebilir.
Kalite, iş hattının sonundaki bir aşama değildir. Ekibin kodu nasıl yazdığının bir özelliğidir ve ya onu baştan tasarlarsınız ya da sonsuza dek onu ararsınız.
Danışmanlıklarımda, en yüksek kaldıraca sahip erken dönem QA kişisi, zamanının belki üçte birini test ederek, üçte ikisini ise iskeleyi kurarak geçirir: ortak bir "bitti" tanımı, bir hata önceliklendirme ritmi, bir duman testi kontrol listesi ve otomasyonun ilk dilimi. Bunun için işe alın; böylece fonksiyon, ürüne karşı değil, ürünle birlikte ölçeklenir.
Önce sıkıcı %20'yi otomatikleştirin
İlk ayda %80 kapsama ihtiyacınız yok. Sizi zaten korkutmuş olan başarısızlıkları yakalayabilecek birkaç teste ihtiyacınız var. Acının en yüksek, yolun en kararlı olduğu yerden başlayın:
- İnce bir uçtan uca test katmanı — para ve güven yolları boyunca beş ila on akış, her dağıtımda çalıştırılır.
- Gerçekten çetrefilli mantığın etrafında birim testleri — fiyatlandırma, izinler, tarih hesapları, insanların üzerinde tartıştığı uç durumları olan her şey.
- Bir CI kapısı — duman testleri kırmızıysa main'e hiçbir şey birleştirilmez. Bu tek satırlık politika, kültürü herhangi bir araçtan daha çok değiştirir.
Bir kapsam sayısının peşinden koşma dürtüsüne direnin. Herkesin görmezden gelmeyi öğrendiği 400 test yerine, asla istikrarsızlaşmayan 40 sağlam testi tercih ederim. İstikrarsız bir paket, hiç paket olmamasından daha kötüdür, çünkü ekibinizi gerçek başarısızlıklarda "yeniden çalıştır"a tıklamaya alıştırır.
Hata bildirimini ucuz ve kaybolmasını imkânsız hâle getirin
Bir QA fonksiyonu, geri bildirim döngüsüyle yaşar ya da ölür. Hatalara tek bir yuva verin — tek bir pano, net bir şablon (adımlar, beklenen, gerçekleşen, önem derecesi) ve her önem derecesinin sürüm için ne anlama geldiğine dair kalıcı bir mutabakat. Bir hatayı bildirmek sürtünmesiz olduğunda, insanlar onları erkenden, ucuzken bildirir. Zahmetli olduğunda ise, iş bir müşteri şikâyetine dönüşene kadar sessiz kalırlar.
Davranışı değiştiren şeyi ölçün
Gösteriş metriklerini atlayın. Test sayısı ve ham kapsam, kalite hakkında size neredeyse hiçbir şey söylemez. Sistemin gerçekten sağlıklı hâle gelip gelmediğini ortaya koyan birkaç sayıyı izleyin:
- Kaçan kusurlar — üretimde bulunan hatalara karşılık sürüm öncesi yakalananlar. Dürüst skor tablosu budur.
- Tespit süresi ve düzeltme süresi — ne kadar hızlı fark ettiğiniz ve ne kadar hızlı toparlandığınız.
- Değişiklik hata oranı — dağıtımların ne kadarının bir olaya neden olduğu.
Bunları bir çeyrek boyunca izleyin, hikâye kendini anlatır. Daha hızlı yayına alırken kaçan kusurlar düşüyorsa, QA fonksiyonunuz çalışıyordur — bir elektronik tabloda kaç test senaryosu durduğundan bağımsız olarak.
Pazartesi nereden başlamalı
En önemli üç para ve güven akışınızı seçin. Tam olarak bunlar için uçtan uca testler yazın, onları bir birleştirme kapısı olarak CI'ye bağlayın ve gerçek bir önem derecesi tanımı olan bir hata panosu kurun. Bu bir haftalık iştir ve gelişigüzel tıklamayla geçen bir çeyrekten daha çok önemli şeyi yakalar.
Ekip küçükken kaliteyi bir alışkanlık olarak inşa edin, o zaman katlanarak artar. Sonradan üzerine monte edin, o kısayolun faizini yıllarca ödersiniz. Yarın bozulsa akışlarınızdan hangisi en çok acıtırdı — ve en son ne zaman biri onu bilerek test etti?