QA ekibini ortadan kaldırmak aslında kötü bir karar olmuş olabilir
- Yazılım dağıtımının en yavaş kısmı testtir. Sürekli dağıtımın var olma nedeni testtir; bu yüzden bunun darboğaz olması optimize edilmiş bir durum olarak kabul edilir.
- Optimizasyon odaklı alışkanlıklar ve davranışlar, sektörün QA ekibini bir darboğaz olarak görüp onu ortadan kaldırmaya yönelmesine yol açtı. Bunun sonucunda QA rolüne duyulan saygı azaldı ve yüksek kaliteli yazılım üretilememesi gibi sorunlar ortaya çıktı.
- Geliştiriciler yazılım kalite yönetimini tam olarak kavrayamıyor. Birçok organizasyon yazılım kalitesinin sorumluluğunun kimde olduğunu bilmiyor; QA işlevini koruyanlar bile buna uygun bir yer bulmakta zorlanıyor.
Yazılım pratiklerinde kaliteyi yönetmek için yapılması gerekenler
- Hata takibi: Kullanıcıların hatalar hakkında bilgi verebilmesi ve geliştiricilerin hataları kaydedebilmesi için bir yönteme ihtiyaç vardır.
- Triyaj: Hata triyajı; hataları atama, önceliklendirme, düzenleme, sınıflandırma ve mükerrerleri ayıklama sürecidir.
- Hata inceleme: Bir hatayı yeniden üretmek, hata yönetiminin önemli bir parçasıdır; gerçek sorunu belirlemek ve çözmek için mühendislik çabası gerekir.
- Odak: Şirkette kaliteye odaklanan insanlar olmalı ve kalite ile hız arasındaki denge için kaliteyi savunacak birine ihtiyaç vardır.
- Uçtan uca test: Sistem sahipliğiyle ilgili sorunlar karmaşık mimariler nedeniyle ortaya çıkar ve bu da ürün çıkışından önce gerçek kullanım testlerinin eksikliğine yol açar.
GN⁺ görüşü
- QA ekibini ortadan kaldırmak, uzun vadede yazılım kalitesi üzerinde ciddi etkiler yaratabilecek yönetsel bir hata olabilir.
- Yazılım geliştirme sürecinde kalite güvencesi önemli bir iştir; bunu görmezden gelmek ya da küçümsemek sonunda başarısızlığa yol açabilir.
- Bu yazı, yazılım sektöründe QA'in önemini yeniden gündeme getiriyor ve kalite yönetimine dair doğru farkındalığın yanı sıra organizasyon içindeki uygun rol paylaşımının gerekliliğini vurgulaması bakımından ilgi çekici.
1 yorum
Hacker News görüşü
1970'lerin sonlarında IBM'de ürün güvencesi işinde çalışırken, sorumlu olunan ürünün (kelime işlem sistemi) test kodlarını yazıp donanım kurulumunu yaptım. Test vakalarını geliştirme ekibine ayrıntılı olarak açıklamak yerine yalnızca genel sorunları ileterek hataları düzeltmelerini sağlıyordum. Bu yöntemle bulunan hatalar ile geliştirme ekibinin düzelttiği hatalar arasındaki uyumsuzluktan, kalan hata sayısına dair istatistiksel bir tahmin hesaplanabiliyordu.
QA ekibi olmayan organizasyonlarda "sniff test" diye bir kavram uygulanıyordu. Bu, şirketteki herkesin yeni bir özelliği kısa bir süre boyunca (genelde 1 saat) yoğun şekilde test ettiği bir oturumdu ve sonuçta çok sayıda bug kaydı açılıyordu. Basit testlerin sık sık sorun çıkarması artık şaşırtıcı gelmiyor.
15-20 yıl önce çalıştığım iki şirket, birinci sınıf QA ekiplerine yatırım yapmıştı ve bu ekipler geliştiricilerin aklına gelmeyen hataları bulma konusunda olağanüstüydü. Bir ürünün yayına çıkıp çıkmayacağına karar veren son yetki QA ekibindeydi. Bugün birçok şirket, geliştiricilerin otomatik test yazmasının ve code coverage için çok zaman harcamasının daha iyi bir yöntem olduğunu düşünüyor, ama gerçekte çalışmayan pek çok ürün gördüm. Mesele otomatik testlerin kötü olması değil; insan QA test uzmanlarını ortadan kaldırmaya itiraz ediyorum.
Bir organizasyondaki en vicdanlı çalışanlar çoğu zaman en memnuniyetsiz olanlardır. Kalite sorunlarını fark eder ve çözmeye çalışırlar, ama bunun karşılığında takdir görmezler; kalite hakkında konuştuklarında da yavaş hareket etmek isteyen kişiler gibi görülürler. "Hızlı hareket et ve bir şeyleri kır" yaklaşımındakiler ödüllendirilmeye devam ederken, onlar geride kalan dağınıklığı toplamak zorunda kaldıkları için öfkelenir ve bir şeyleri önemsemenin kariyerlerine zarar verebileceğini hissederler.
QA, iş birimleri ve üst yönetim tarafından çoğunlukla bir "maliyet merkezi" olarak görülme eğilimindedir. "Maliyet merkezi" sayılan bölümlerde çalışmaktan kaçınmak gerektiğine dair bir varsayım var; çünkü ödül ve takdir her zaman gelir yaratan kişilere gider. QA daha çok işi daha az kişiyle yapmak zorunda kalır, başarısızlıklarda suçlanır ve şirket küçülmeye gitmek zorunda kaldığında işten çıkarmaların ilk adreslerinden biri olabilir.
QA mühendisleri çok güçlü debugging becerilerine sahiptir. Pipeline, source code, test dizinleri gibi uygulamanın her yönüyle çalışırlar; buna karşılık yazılım mühendisleri çoğu zaman pipeline hata mesajlarını okumaz, temel sorunu görmezden gelir ve çözümü tahmin etmeye çalışarak günlerini geçirir. QA mühendislerine yönelik küçümseme makalede abartıldığı kadar değil; QA organizasyonları, mühendislik organizasyonları kadar katı mülakat süreçlerinden geçmediği için QA mühendisleri daha aşağı görülür.
Kişisel deneyimime göre, gerçekten mühendislik için test yazan bir QA ekibiyle hiç karşılaşmadım. QA ekiplerinin çoğu "test planı"nı ya manuel olarak ya da nadiren otomatikleştirilmiş browser/cihaz testleriyle yürütüyor. Bu test türleri değerli, ama "birim testi" ya da "entegrasyon testi" kadar değil. Bu modelde asıl QA işlevini fiilen mühendislik ekibi üstlenmiş oluyor; QA ekibi ise sık sık bug olmayan şeyleri bug diye işaretleyerek değerini düşürüyor.
Microsoft'un QA ekiplerini kaldırmasının ardından Windows ve bulut ürünlerinde daha fazla hatanın ortaya çıktığı görüldü.