QA ekibini dağıtmanın kötü bir karar olmuş olabileceğine dair eleştiri

 (davidkcaudill.medium.com)
5 puan yazan GN⁺ 2023-12-15 | 1 yorum | WhatsApp'ta paylaş
  • DevOps tarzı optimizasyonlarla sürüm çıkarma, dağıtım, imaj yönetimi ve geri alma süreçlerindeki darboğazlar azaltıldıktan sonra, yazılım tesliminde en yavaş nokta test olarak kaldı
  • Sektör, testin kendisinden çok QA ekibini darboğaz olarak görmeye başladı; rolden beklentiler artarken kötüleşen çalışma koşulları, sözleşmeli çalıştırma, offshore’a taşıma ve istihdam azaltma devam etti
  • QA organizasyonlarının dağıtılması, deneyimli QA çalışanlarının moralini kırdı; geliştiriciler kalite işlerini doğal biçimde üstlenemeyince düşük kaliteli yazılım sorunu büyüdü
  • Kalite yönetimi; hata takibi, sınıflandırma, inceleme, kalite savunuculuğu ve uçtan uca test gibi adlandırılması ve atanması gereken gerçek bir iştir
  • Kalite işi organize edilmezse sorunları bulan ve toparlayan kişiler ödüllendirilmez; hızlıca üretip bozan tarafın tekrar tekrar ödüllendirildiği bir yapı oluşur

DevOps optimizasyonundan sonra kalan darboğaz

  • DevOps uygulayıcıları, Theory Of Constraints yaklaşımını uygulayarak yazılım teslim hattını ve pratiklerini güçlü biçimde optimize etti
  • Manuel sürüm yönetimi, dağıtım, imaj yönetimi ve production rollback otomasyonun hedefi haline geldi
  • Ürün backlog’undan kodun müşteriye ulaşmasına kadar olan süreçteki düşük değerli faaliyetler, ortadan kaldırılacak veya optimize edilecek darboğazlar olarak ele alındı
  • Bunun sonucunda yazılım tesliminin en yavaş kısmı test olarak kaldı
    • Test, sürekli teslimatın var olma nedenlerinden biridir
    • Testleri hızlandırmak, otomatikleştirmek ve paralelleştirmek mümkündür
    • Bir pratikte en değerli faaliyet darboğazsa, bunun zaten optimuma yakın bir durum olduğu düşünülür

Sektörün QA ekibini darboğaz olarak görmesi

  • Optimizasyon alışkanlığı, testin kendisinin ötesinde QA rolüne de uygulandı
  • Entegrasyon testleri ve uçtan uca testleri birim testlerine indirerek paralelleştirme yönünde bir eğilim oluştu
  • İnsan kaynağı tarafında, kod yazamadığı düşünülen kişilerin özellik ekiplerine itilmesi de yaşandı
  • Sektör, darboğazın test değil QA ekibi olabileceğini düşünmeye başladı
    • QA rolüne yönelik beklentiler yükseldi
    • Ücretler düştü ya da diğer rollere kıyasla artmadı
    • Rol sözleşmeli hale getirildi ve offshore’a taşındı
    • QA mühendisi istihdamını azaltma tercihleri devam etti

QA rolünün küçülmesinin yarattığı kısır döngü

  • QA’da kalan kişiler giderek daha dezavantajlı bir yapının içinde kaldı
    • Yeterince iyi kod yazabilenler veya çalışma koşullarından bıkanlar QA’dan ayrıldı
    • Diğerleri, QA’da kalan insanları “o alandan çıkacak kadar yeterli olmayan kişiler” olarak gördü
    • Yeni mezunlara QA alanını önerenlerin sayısı da azaldı
  • Şirketler, “bu fonksiyonu artık bulundurmayacağız, siz halledin” yaklaşımıyla QA ile yollarını ayırdı
  • Bu süreç, QA kariyeri inşa etmiş kişiler için saygısızca ve moral bozucu oldu
  • QA’nın dağıtılması düşük kaliteli yazılım sorununu büyüttü; birçok organizasyon yazılım kalitesinde kimin ne yapması gerektiğini bilmez hale geldi
  • QA fonksiyonunu koruyan organizasyonlar bile, zaten zarar görmüş bir alan içinde bu rolün yerini bulmakta zorlandı

“Test uzmanlarını işten çıkarmak” çözüm değildi

  • Daha hızlı yazılım teslimi için “tek garip numara” test uzmanlarını işten çıkarmak değildi
  • QA alanını bozmak, en kötü yönetim hatalarına yakın bir karardı
    • On yıllar içinde gelişmiş bir şeyi yok eden bir tercihti
    • Etkisi yıllar boyunca hissedilmeyebilir
    • Organizasyon sorunu hissettiğinde, anlamlı bir toparlanma için yeniden yıllar gerekebilir
  • QA rolünde zaten bozuk olan kısımlar hâlâ çözülmeden duruyor
  • İş bölümü gerçekleşmedi; geliştiriciler ek ücret, takdir veya ödül yapısı olmadan QA işlerini gönüllü olarak üstlenmiyor
  • Yüksek işlevli QA ekipleriyle çalışmış bazı kişiler, bu davranışların bir kısmını taklit edebilir; ancak daha yeni mühendisler ve yöneticiler neyin eksik olduğunu anlamakta zorlanır
  • Temel ilke, kalite güvencesinin bir iş olduğudur
    • Diğer işler gibi, “birilerinin” yapacağı varsayılırsa başarısız olur
    • Görünmeyen iş olarak bırakmak da başarısızlığa yol açar

Yazılım kalite yönetimi için gereken işler

  • Hata takibi

    • Kullanıcıların bug bilgisi gönderebilmesi ve geliştiricilerin bug kaydedebilmesi için bir yöntem gerekir
    • Bug, neyin yanlış olduğunu ve ne kadar ciddi olduğunu açıklayan ayrı bir ticket’tır
    • Düzeltme işinin kendisini açıklamaz
    • Kusuru, yeniden üretme adımlarını ve etkiyi içermelidir
    • Son dönemde birlikte çalışılan geliştirme ekiplerinin çoğu bu tür kusurları takip etmiyordu
    • “Zaten düzeltmeyeceğiz”, “benim işim değil”, “yeni özelliklerle ödüllendiriliyorum” gibi gerekçeler düşük kaliteli sonuçları meşrulaştırmaz
    • Bug listesini yönetmek başlı başına bir iştir

  • Sınıflandırma ve önceliklendirme

    • Bug sınıflandırması, gelen bug’ları atama, önceliklendirme, düzenleme, sınıflandırma ve mükerrerleri ayıklama sürecidir
    • Yüksek, orta ve düşük ciddiyet ölçütlerini tutarlı biçimde belirlemek organizasyona yardımcı olur
    • Geçmişte buna “bug hijyeni” denirdi
    • Hangi ekibin ilgili bug’ı üstlenmesi gerektiğini belirlemek de bir iştir
    • İyi işleyen organizasyonlar, dış baskı veya yeniden yapılanma durumlarında daha iyi yanıt verebilir
    • İşten çıkarmalar olsa bile kalite düşüşünü kademeli olarak yönetir
    • Organizasyon değişikliklerinde belirli bug kategorilerini yeni ekibe devreder
    • Durdurulan özelliklere ait bug’ları topluca kapatır
    • Hiç dış stres veya organizasyon değişikliği yaşamayan ekiplerin sınıflandırma sürecini görmezden gelebileceğini söylemek neredeyse şaka gibidir

  • Kusur incelemesi

    • Yeniden üretme, bug yönetiminin önemli bir parçasıdır
    • Birinin “sinema bileti almaya çalıştım ama olmadı” raporunu, “adında İngilizce dışı karakterler olan müşterilerde karakter kodlama sorunu satın alma akışını bozdu” biçimine dönüştürmesi gerekir
    • “Bu sorun kaç kez yaşandı?”, “kullanıcı etkisi nedir?” gibi sorulara gerçek insanların zaman ayırarak yanıt vermesi gerekir
    • Kusur incelemesi, bug backlog’una mühendislik titizliği uygulama işidir

  • Kaliteye odaklanan rol

    • Şirket içinde nihai ürünün kalitesine odaklanan birinin olması gerçek değer taşır
    • Kalite herkesin işi olabilir ama aynı zamanda birinin işi olmalıdır
    • Kalite ile hız arasındaki gerilimde kaliteyi savunan birine ihtiyaç vardır
    • Test araçları, test kalitesi ve test planı için mümkün olduğunca iyi yapılmasını isteyen, görüş sahibi bir paydaş gerekir

  • Uçtan uca test

    • Birçok mühendislik organizasyonunda en büyük ve en yaygın sorunlardan biri sistem sahipliğidir
    • Mimari karmaşıklığın artması, ekipleri ve uygulamaları küçük tutma amacıyla gerçekleşti; bu makul bir strateji olabilir
    • Ancak bunun sonucunda uygulamanın en önemli kısımlarında boşluk oluştu
    • Ortalama bir ekip artık ürünün uçtan uca kullanımını ve doğrulamasını yapmıyor; çünkü bu çok zor
    • Ürün yayınlanmadan önce organizasyon içinde onu gerçekten kullanan birinin olduğundan emin olunmalıdır

Kalite işini görmezden gelince ortaya çıkan organizasyon sorunları

  • “Biz çevik, lean ve dinamiğiz; böyle işler yapmamıza gerek yok” tepkisi gelebilir
  • Yakından bakıldığında bu işlerin organizasyon içinde zaten gerçekleşiyor olma ihtimali yüksektir, ancak çok kötü yapılıyordur
  • Otomobil, banka veya doktor gibi başka alanlarda “biz kalite güvencesi yapmıyoruz” sözünü duymak iyi bir deneyim değildir
  • Kalite faaliyetleri tanınmaz ve organize edilmezse çok kötü durumlara yol açar
  • En vicdanlı çalışanlar en buruk hale gelir
    • Kalite sorunlarını görür ve sık sık çözerler
    • Bunun için takdir görmezler
    • Kalite endişeleri dile getirdiklerinde hızı yavaşlatmaya çalışan kişiler gibi muamele görürler
    • “Hızlı hareket edip bir şeyleri bozan” kişilerin tekrar tekrar ödüllendirildiğini görürler
    • Kendilerini başkalarının dağınıklığını öfkeyle temizleyen kişiler gibi hissederler
  • Böyle organizasyonlarda önemsemek başlı başına kariyer açısından dezavantaj haline gelir

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-15
Hacker News yorumları

  • Kariyerimin başlarında, 1970'lerin sonlarında IBM Hursley Park'taki Product Assurance, yani QA organizasyonunda çalıştım. Sorumlu olduğum ürün olan kelime işlem sistemini test etmek için kod ve donanım yazıyor, test edilen sistem üzerinde test vakaları çalıştırıyordum.
    Bulduğumuz sorunları geliştirme ekibine yalnızca genel açıklamalarla iletiyorduk; amaç, ekibin test vakasına uyum sağlamasını değil hataları düzeltmesini sağlamaktı. Sonuçta tireli sözcüklerin satır sonu bölünmesi ve backspace ile silme konusunda 3 hata bulduğumuzda, geliştirme ekibi o alandaki 4 hatayı düzeltiyor ama bizim gerçekten bulduklarımızdan yalnızca 2'sini düzeltmiş oluyordu; böylece kalan gerçek hata sayısını istatistiksel olarak tahmin edebiliyorduk.
    QA ekibi olmayan organizasyonlarda sniff test kavramını getirdim. Genelde şirketten ya da departmandan herkesin yeni bir özelliği yaklaşık 1 saat kurcaladığı bir oturumdur; özellik tamamlanmış kabul edilse bile sınır koşulları neredeyse her zaman bozuk olurdu. Tüm alanlara "" girip göndermek, arayüzde yalnızca klavyeyle gezinmek ya da büyük yazı tipi, tarayıcıda %110 yakınlaştırma gibi basit koşulları denemek sorunları sık sık ortaya çıkarırdı; artık buna şaşırmıyorum bile.

    • Bizim şirkette buna bug bash diyoruz ve bulunan kusur sayısı açısından genellikle çok verimli oluyor.
      Küçük özellikler geliştirilirken genelde yalnızca programcılar test eder; bu yöntem gerçek son kullanıcıların kullanım biçiminden farklı olabildiği için özellikle faydalıdır.
    • Otomasyon testlerinin kaynağını geliştiricilerden gizleme stratejisi ilginç. Testleri devre dışı bırakmaya ya da yalnızca testlere uyacak şekilde davranmaya değil, gerçek sorunu çözmeye odaklanmalarını sağlayabilir gibi görünüyor.
    • Eski Microsoft'ta buna bug bash denirdi; benim startup'ım da bu fikri devraldı. Tüm şirketin öğleden sonrasını boşaltıp katılmasını teşvik eder, etkisi en büyük hataya ya da en ilginç hataya ödüller verirdik.
    • Bir saatte 100 hata kaydı açmanın gerçekten kime faydalı olduğundan emin değilim. Çok fazla mükerrer varsa, yalnızca 10 farklı hata bile özelliğin ciddi biçimde kötü olduğunu göstermeye yeter; ondan sonrası enkazı dövmeye devam ediyormuş hissi veriyor.
    • Kesin QA test vakalarına sahip olup geliştiriciye yalnızca muğlak açıklamalar vermek oldukça zekice. Böyle bir yöntemi ilk kez görüyorum; kalan hata sayısını tahmin edebilmek de etkileyici.

  • 15-20 yıl önce en üst düzey QA ekiplerine yatırım yapan iki şirkette çalıştım; o ekipler gerçekten karşılığını veriyordu. QA, geliştiricinin soruna fazla yakın olduğu için aklına gelmeyen hataları çok iyi buluyordu ve ürünler de dünya standardında oluyordu.
    İki şirkette de kritik nokta, yukarıdan yayınlanıp yayınlanmayacağı konusunda son yetkinin QA ekibinde olduğunun belirlenmiş olmasıydı.
    Günümüzde şirketler, geliştiricilerin otomasyon testleri kullanmasının ve kod kapsamına aşırı odaklanmasının daha iyi olduğunu düşünüyor; ama %100 kod kapsamına sahip olup nesnel olarak çalışmayan çok fazla ürün gördüm. Otomasyon testleri kötü demiyorum; insan QA test uzmanlarını ortadan kaldırmanın sorun olduğunu söylüyorum.

    • Harika QA/QE organizasyonları da buna benziyordu. Üretim sürümünü onaylayıp onaylamamaya karar veren komuta zinciri geliştirmeden farklıydı, teşvik yapısı da farklıydı.
      Yakın zamanda çalıştığım bir şirketin QE ekibi testleri yürütmek için muazzam miktarda kod yazıyordu; satır sayısı, test edilip onaylanan modülden daha fazlaydı.
    • Kod kapsamı, yazılmamış ama yazılması gereken koddan kaynaklanan hataları bulamaz. Kapsam birçok metrikten yalnızca biridir; onu tek ölçütmüş gibi ele almak aptallıktır.
      Yine de herkesin bildiği büyük bir yazılım şirketinde bir test yöneticisinin, %100 kapsama ulaşıldığına göre test ekibinin işinin bittiğini ilan ettiğini duymuştum.
    • QA'in son karar yetkisine sahip olduğu yönündeki talimat tek başına yetmez; QA kültürü olmalı.
      Böyle bir yetki olsa bile QA'in çoğunlukla düşük ücretli sözleşmeli çalışanlardan oluştuğu ve yalnızca kendilerine söyleneni yaptığı şirketlerde işler hâlâ berbattı.
    • Assertion içermeyen testler ya da yalnızca assertTrue(true) olan testler yazan geliştiriciler gördüm. Her zaman yeşil yanar ve kapsam %100 olur.
      Aynı kişiler yeni özellik geliştirebiliyorken neden test yazmaları gerektiğini sorardı; sonra kıdemli bir QA gelir ve her şeyi kırardı. Bir keresinde F5'e 1 dakika içinde 50 kez basınca backend'in veritabanı isteklerini döndürürken outOfMemory ile öldüğünü bulmuştu.
    • Titiz QA'leri gerçekten seviyorum. Bir geliştirici olarak onların kaçırdıklarını yakalayacaklarına fazla bel bağlamam bir antipattern olur; ama ben kodu 1 dakika çalıştırmaktan bile korkarken onlar bundan keyif alıyor.
      Spesifikasyonun çok ötesindeki sınır koşullarını bulmakla gurur duyuyorlar ve bunun değeri fazlasıyla var. İyi bir tip sistemi değişiklik yapma konusunda nasıl güven veriyorsa, mükemmel QA de geliştiriciye güven verir. Özellikle oyunlar gibi etkileşimi yüksek uygulamalarda, birim testleri ve entegrasyon testleriyle parametre uzayının tamamını kapsamak zordur.

  • Bir organizasyondaki en vicdanlı çalışanların en çok burukluk yaşayanlar olduğu sözü acı bir gerçek. Kalite sorunlarını görür, çoğu zaman bizzat çözerler ama takdir görmezler; kalite kaygılarını dile getirdiklerinde ise hızı yavaşlatmaya çalışan kişiler gibi muamele görürler.
    “Hızlı hareket et ve bir şeyleri kır” tarafı ödüllendirilmeye devam eder; önemseyenler ise arkalarını toplar ve öfkeleri birikir. Onlara göre önemsemek bizzat kariyer açısından büyük bir dezavantaj gibi hissettirir; çünkü gerçekte de öyledir.
    DBA ve altyapı organizasyonları da QA ile aynı durumda; yakında dengenin yeniden geri gelmesini umuyorum.

    • Gemiden atlayıp şirketin batmasına izin vermek yeterli. Daha hızlı batması daha iyi; kötü şirketleri zorla ayakta tutmadığınızda iyi şeylerin mümkün hale gelmesi daha olası.
    • Bana göre dengenin geri gelme biçimi kendin yaptıysan kendin işlet olacak. Nöbet çağrı cihazının çalmasından hoşlanmıyorsan onu çaldıracak şeyler yapmamalısın.
    • Sonuçta müşteriye bağlı. Hatalar ve kesintiler yüzünden ayrılacak mı, yoksa parlak yeni özellikler yüzünden kalacak mı; mesele bu.
    • QA ve test önemli, ama yalnızca kâra bakan insanları ikna edip edemeyeceğimizi bilmiyorum. İnternetten dağıtım fazlasıyla kolaylaştığı için “hızlı çıkar, sonra yama yap” yaklaşımı sürecek gibi görünüyor.
      Kullanıcılar hataları bildirebiliyor ve internet üzerinden güncelleme alabiliyorken, çok para ve zaman harcamaya ne gerek var diye hesaplıyorlar. Oyunlar ve yazılımlar fiziksel medyadan indirme odaklı hale geldikten sonra yama yapmak daha ucuza geliyor gibi. Elbette bu korkunç güvenlik sorunlarına ve kötü kullanıcı deneyimine yol açıyor; ama yukarıdakiler kârı maksimize ettiği sürece pek umursamıyor.
    • Vicdanlı mühendis her zaman haklı değildir; bağlam ve denge gerekir. Bazen haklıdır ama anlatım biçimi bozuktur, bazen de sadece yanlış yerdedir.
      POC SaaS ürünü yapıyorsanız aviyonik mikrokontrolör düzeyinde kaliteye ihtiyacınız yoktur. Her ödünleşimin riski ve maliyeti vardır; iyi mühendis aradaki farkı bilmelidir.

  • QA ekibinin temel sorunu IT ekibi ya da yönetim organizasyonuyla aynı. İşini iyi yaptığında hiçbir şey yapmıyormuş gibi görünür
    Bu yüzden kişinin kendi işini “meşrulaştırmak” zorunda kaldığı durumlar sık yaşanır; bu da genellikle metriklere aşırı bağımlı olmaktan kaynaklanır. Goodhart Yasası’nda olduğu gibi, metriğin neyin vekil değeri olduğunu ve işin gerçek amacının ne olduğunu anlamamaktır
    Kötü QA ekipleri söyleyecek bir şeyleri varmış gibi görünmek için gereğinden fazla kusur arar; iyi QA ekipleri ise kaliteyi doğrularken aynı zamanda çalışanları daha yüksek kalite üretmeleri için eğitir
    İş gücünün genelinde eğitim eksikliği olduğunu hissediyorum. Kısa süre önce ön sayfaya çıkan “95. yüzdelik dilim de o kadar olağanüstü değil” yazısı (https://news.ycombinator.com/item?id=38560345) da, çoğu uygulayıcı aktif olarak antrenman yapmadığı ya da geri bildirim almadığı için herhangi bir alanda ilk %5’e girmenin kolay olduğu yönündeydi
    Şirketlerin amatör spor takımı gibi değil, profesyonel takım gibi sürekli antrenman yapması gerekmez mi diye düşünüyorum. İşe alımda da “zaten en iyi performans gösteren biri mi”den çok “bu kişiyi en iyi performans gösteren biri hâline getirebilir miyiz” diye bakılmalı. Önceki ortamında başarılı olmuş olması, yeni ortam çok farklıysa sanıldığından daha az anlam taşır

      1. yüzdelik dilim muazzam bir çabanın sonucu olmaktan çok gereksiz hataları azaltmanın sonucu olabileceği hâlde, bunu çok zor bir iş sayan kültürel meme yaygın durumda
        Yazılım kalitesiyle ilgili her yazıda mühendislerin yaygın ilgisizliğini doğal kabul eden çok sayıda yorum var. Duruma göre değişir ama insanlar kendi organizasyonlarının yerel optimumuna uyup sadece akıntıya kapılmak ve inisiyatifi bırakmak konusunda epey iyi görünüyor. Bu tamamen onların suçu değil ama masum da değiller
    • DevOps ekiplerinde “işini meşrulaştırmak zorunda kalma” kalıbını sürekli görüyorum. Genellikle en yüksek maaşlı ya da en kıdemli operasyon sorumlusu, kendi yetersizliği veya hatasıyla çıkardığı yangınları söndürmeye çok zaman harcıyor ve bu yüzden bir şeyler yapıyormuş gibi görünüyor
      Tekrarlayan işleri otomasyonla ortadan kaldırırsanız o kişinin pozisyonu ortadan kalkar; ama doğru yaparsanız yönetici onun bütün gün oturup hiçbir şey yapmadığını düşüneceği için, bunu doğru yapmaya yönelik teşvik azdır
    • Yeni geliştiricilerle çalışırken çift tıklama, baştaki boşluk, Android geri tuşu gibi temel testlerle bile onları sık sık tökezletebilirsiniz. Birkaç kez ticket geri çevrilince bunları öğrenirler ve sonrasında aynı sorunlar pek çıkmaz
      Bulunan bug sayısına göre değerlendirilmeyeceğiniz için, sayıyı artırmak adına aptalca bug’ları zorla bulma baskısı da yoktur
    • “Böyle eğitirsen daha fazla para alıp başka yere gider” sözünü neredeyse her şirkette duydum. Anlamlı eğitim hep uphill battle oldu
      İyi eğitim için teknik rollerde yeterince geniş görüşlü ve iyi insanların bulunması gerekir. En yeni teknolojilerin hepsini bilmeleri gerekmez ama saçmalığı sezebilmeli ve işaret edebilmelidirler. FAANG de istisna değil

  • Bu yazıda da geçtiği gibi, asıl mesele QA’nın neredeyse her zaman iş birimleri ve üst yönetim tarafından maliyet merkezi olarak görülmesi
    Maliyet merkezi olarak görülen organizasyonlarda çalışmamanın daha iyi olduğuna dair bir varsayımım var. Bonus, takdir ve saygı her zaman para kazanan tarafa gider; maliyet merkezleri ise daha az kişiyle daha fazla işi üstlenir, başarısızlığın sorumluluğunu üzerine alır ve şirket küçülürken ilk kesilen yer olur. IT için de aynı şey geçerli
    Bu kısır döngü yüzünden QA kariyeri, benzer becerilerle geliştirici olmaktan her zaman daha zor olmak zorunda kalır. Çok iyi insanlar yorulup mümkün olan en kısa sürede çıkar ve bu yapı kendi kendini güçlendirir

    • Mobil uygulama geliştiricisi olsanız bile maliyet merkezi niteliğindeki işleri üstlenmemeye dikkat etmek gerektiğini hissediyorum
      Erişilebilirlik, gözlemlenebilirlik, iyi loglama, test altyapısı iyileştirmeleri, CI/CD ayarları, stabilite, daha iyi linting ve analizör sorunları hep önemli; ama hızlıca özellik yayınladığınızda ödüllendiriliyorsunuz
      Bu yıl ekip ve uygulama için gerekli olduğunu düşündüğümden bu tür işlere fazla zaman harcadım ve yıl sonu performans değerlendirmemden endişeliyim. Şimdi diğer insanların bu işleri neden kaçındığını anlıyorum; gelecek yıl daha görünür özellik yayınlarına odaklanmayı düşünüyorum. Uygulamadaki bug’lar için üzgünüm ama konut kredisini ödemek için işe ihtiyacım var
    • Maliyet merkezi hissine katılıyorum ama deneyimime göre biraz daha nüans var
      Bazı organizasyonlar QA/QC’nin getirdiği değeri içtenlikle önemser. Bunu yazılımdan çok üretim sektöründe daha net gördüm; tahminimce bunun nedeni yazılımın doğası gereği daha soyut olması ve israfı izlemenin daha zor olması
      Gerçekten iyi QA, kolay yolu arayan kişi değil, QA’nın misyonuna inanan kişidir. Sonuçta değeri yaratan şey, organizasyonun ve bireylerin QA ruhunu gerçekten benimsemesi; bunu sadece biçimsel olarak yapan yer de çok
    • Frontend platform ekibinde performans iyileştirmeleri, CI tasarımı ve süreç mühendisliği yapıyorum; ancak banka hesabına doğrudan para olarak yansıyan özellikleri yayınlayan insanlara kıyasla takdir ve terfi almak çok daha zor
      Yine de sorun değil. Daha iyi ve sağlam hâle getirmek hoşuma gidiyor ve içimi rahatlatıyor. Bozma işini alaycı insanlara bırakacağım
    • Hayatım boyunca neredeyse hep maliyet merkezlerinde çalıştım ama bunu başka bir şeyle değiştirmek istemem
      Bonusların vb. başka gruplara gitmesi sorun değil. Teknik bir rolde yeterince iyi kazanıyorum ve para kazandıran o rollerin önemli bir kısmı, gerçekten iyi yapsam bile beni çok mutsuz ederdi
    • Bu yüzden geleneksel işletmelerin IT departmanlarında çalışmıyorum

  • Yazılım kalitesi, kodun sürdürülebilirliği ve iyi tasarım, ancak o şirkette uzun süre çalışmayı planlıyorsanız önemlidir
    Birkaç yıl sonra bir sonraki şirkete geçmeyi düşünüyorsanız, en uygun yol görünür işler yapıp hızlıca yükselmek ve bu geçmişi daha yüksek maaşlı bir işe geçmek için kullanmaktır. Birkaç yıl sonra o proje bozulsa ya da bakımı imkânsız hâle gelse bile, o sırada artık orada olmayacağınız için fark etmez
    Startup’lar da aynı şekilde işler. Her yere kazınmış büyüme zihniyeti tam olarak bu kalıptır. Ürün 5 yıl sonra bakımı imkânsız hâle gelse bile, o zamana kadar exit yapıp nakde dönmüş olabilirsiniz
    Böyle insanları tam olarak suçlamıyorum. Şirketlerin bizzat kullandığı pratikler bunlar ve insanlar sadece o kurallara göre oynuyor. Hoşuma gitmiyor, hatta gerçekten nefret ediyorum ama anlıyorum
    İşin ilginç yanı, yöneticilerin ve üst düzey yöneticilerin işten ayrılma oranından, şirkete bağlılık eksikliğinden ve sessiz istifadan şikâyet etmesi. Kendi yarattıkları zehri kendileri tatmak gibi

    • Bir startup’ın 5 yıl sonra ürününün bakımı imkânsız hâle gelebileceğini varsayması makul bir tutum olabilir. Çünkü çoğu startup 5 yıl dayanamaz ve başarısız olur
      5 yıl sonra teknik borçla birlikte hayatta kalmışlarsa, birçok startup için bu aslında iyi bir problemdir. Ne de olsa 5 yıl dayanmış oldukları anlamına gelir

  • QA mühendisleri hata ayıklamada da oldukça iyidir. Pipeline’lara, kaynak koda, test dizinlerine dokunur; uygulama geliştirme ve dağıtımının neredeyse her yönüyle ilgilenirler.
    QA lead’i olduğum dönemde, pipeline hata mesajlarını okumaya bile çalışmadan her gün Slack’te şikâyet eden yazılım mühendislerini sık görürdüm. Pipeline optimizasyonu sırasında da kök sorunu görmezden gelir, o kök sorundan çıkan semptomları sanki sihirli ve anlaşılmaz sorunlarmış gibi ele alıp günlerce tahmin yürüterek çözmeye çalışırlardı.
    Bu yazıda geçen QA mühendislerine yönelik küçümseme abartı değil. QA organizasyonu olan şirketler bile çoğu zaman mühendislik organizasyonları kadar sıkı mülakat süreçleri uygulamaz; bu yüzden QA mühendisleri düşük değerlendirilir.
    QA’ya saygı duyan SWE’ler yalnızca bizzat QA’da çalışmış kişilerdi. Bu küçümseme o kadar yaygındı ki sonunda mühendislik organizasyonuna geri döndüm; principal engineer olarak kıdemimi ya da yönetici rolümü kullanarak bunu değiştirmeye çalıştım ama başaramadım. Mühendislik kendi kibrinin ötesini göremedi, liderlik de yardımcı olmadı.
    İşten çıkarılmadan önce çalıştığım şirketteki yeni CTO, QA ihtiyacının otomasyonla ortadan kaldırılabileceğini söyledi ama bunun ne anlama geldiğine dair tek bir örnek bile vermedi. İyi yazılım üretmeye yönelik yukarıdan gelen saygı seviyesi işte bu kadardı.

  • Microsoft bu sorunun en belirgin görüldüğü örnek gibi duruyor. QA ekibini kaldırdıktan sonra Windows ve bulut ürünleri güncellemelerinde hatalar gözle görülür şekilde arttı.

    • Gelir akmaya devam ettiğine göre, iş açısından doğru karardı demek ki… iç geçirtiyor.
      İşimde Microsoft yazılımlarını ve hizmetlerini çok kullanıyorum; kalite düşüşünün bir şekilde bedelini ödemelerini isterdim.

  • Kişisel deneyimim olabilir ama mühendislik için gerçekten test yazan bir QA ekibi hiç görmedim.
    Benim karşılaştığım QA ekipleri test planları yazar ve bunları manuel olarak çalıştırırdı; nadiren de otomatikleştirilmiş tarayıcı/cihaz testleriyle yürütürlerdi. Bu testlerin de değeri var ama bence birim testleri veya entegrasyon testlerinden daha az.
    Bu modelde fiilen mühendislik ekibi QA ekibine dönüşüyordu; ayrı QA ekibi ise çoğu zaman hata olmayan şeyleri hata gibi bulup gürültü yaratıyor, sağladığı değerden daha fazla maliyet çıkarıyordu.
    İyi işleyen bir QA ekibi modelini öğrenmek isterim. Manuel test harika ama deneyimime göre sınırları var. QA çalışanlarını küçümsemeye çalışmıyorum, yalnızca kendi deneyimimi paylaşıyorum.

    • Benim gördüğüm QA değerinin kaynağı ürün aşinalığı. İyi bir QA, ürünün gerçekte nasıl çalıştığını herkesten iyi bilir.
      PM’den, satıştan ve geliştirme ekiplerinin çoğundan daha kapsamlı biçimde kullanıcıya görünen tüm sistemi bilir; hangi düğmeye basınca ne olacağını tam olarak söyleyebilir. Kötü QA gerçekten de bir gürültü kaynağıdır ama kötü geliştiriciler, sistem yöneticileri ve 1./2. seviye destek de öyle.
    • İyi QA, yazılım geliştirici için iyi bir editörün yazar için yaptığı işe benzer. Emek verilerek ortaya çıkarılan sonucu soğukkanlılıkla inceler ve acımasızca eleştirir.
      Buna maruz kalırken gerçekten sinir bozucudur ama çıktının kalitesi çok daha iyi olur.
      Eskiden QA genellikle test yazmaz, kodu manuel olarak test eder ve kullanıcıların yapmamasını umduğunuz bütün tuhaf davranışları denerdi. Testlerle genel olarak yakalanması zor sorunları ve hataları bulurdu.
      Şimdi QA’yı kullanıcılara yıkıyoruz. Genç geliştiricilerle çalışırken QA kavramının kendisinin giderek yabancılaştığını hissediyorum. Production’a hata çıkınca “lokalde kurcaladığında nasıldı?” diye sorduğumda çoğu zaman tuhaf bakışlar alıyorum. Tip denetleyiciden geçtiyse neden yayınlamayalım, der gibiler.
      Günümüzde programcı verimliliği dakikadaki PR sayısıyla ölçüldüğünden, hata sokmak sorun değil; hatta iyi bir şey. Biri production’da bulursa birkaç gün sonra onu düzelten bir PR daha açabilirsiniz. QA olsaydı bu akışı bozardı.
    • Ben mühendislik için test yazan bir QA’yım; unvanım tam olarak SDET. Yalnızca test planlarıyla değil, test framework’leriyle, altyapıyla ve bu test planlarının otomasyonuyla da ilgileniyorum.
      QA fonksiyonunu hayata geçirme biçimi şirketten şirkete değişir. Bunu müşteriye de bırakabilirler, geliştiricilere, müşteri desteğine, manuel QA’ya ya da SDET’lere de. Sonuçta her şey liderliğin kaliteye ne kadar önem verdiğine ve QA’yı nasıl gördüğüne bağlıdır.
      Bir QA ekibi varsa, sürecin erken aşamalarına katıldığında başarı ihtimalinin en yüksek olduğunu düşünüyorum. İyi bir QA ekibi, kod yazılmadan önce hataları bulmalıdır. Ne kadar geç dahil olursa hatalar da o kadar geç bulunur ve “kod tamam” ile yayın arasına daha sert şekilde sıkıştırılır. QA ekibinin otomasyon becerisi olmalı ki manuel testleri tekrar etmek yerine yeni test senaryolarına zaman ayırabilsin.
      Bu yazı epey can yakıcı geliyor. QA bazen ikinci sınıf vatandaş muamelesi görüyor ve işini düzgün yapmak için ihtiyaç duyduğu bağlamı sağlayacak tartışmaların dışında bırakılıyor. İyi insanlar geliştirme ya da ürün yönetimine ayrıldıkça durum daha da kötüleşiyor; aşağı yönlü sarmal gerçekten var.
    • QA organizasyonunu yürütmenin resmî bir yolu olmadığı için insanlar işe alındıktan sonra çoğu zaman “kendin hallet” deniyor. Böyle olunca diğer organizasyonlar QA’nın ihtiyaçlarını anlamıyor ve görmezden geliyor.
      Burada tarif ettiğin şey liderlik sorunu; QA’nın yararlılığıyla ilgili bir sorun değil.
    • Klasik modelde çoğu QA organizasyonu işe yaramaz bir eklenti gibi çalışıyordu. Bunun nedeni hem yapısaldı hem de geliştirme geciktiğinde QA’nın kenara itilmesiydi.
      QA, erken aşamada sürece dahil edilmeden test altyapısı ve test planları hazırlayarak zaman geçirir; en sonunda da önüne bir kod yığını ve 48 saatlik onay takvimi konur, yoğun baskı altında imza atması beklenirdi.
      Ama ara sıra problem alanını derinlemesine anlayan ve geliştirmeyi gerçekten yönlendiren QA organizasyonlarıyla da karşılaşmak mümkündü. Geliştirmeyle baştan sona yan yana ilerlerlerdi; yalnızca kaliteyi artırmakla kalmaz, herkesin zamanından da tasarruf sağlarlardı.

  • FoundationDB’yi geliştirirken kalite ve testlere neredeyse takıntı düzeyinde odaklanmıştık. Bu yüzden Flow adlı bir dil bile geliştirdik; rastgele büyüklükte FDB kümelerini deterministik olarak simüle edebiliyor, aşırı koşullara maruz bırakabiliyor, sistem özelliklerinin ihlalini işaretleyebiliyor ve bu ihlale yol açan test çalıştırmasını eksiksiz yeniden üretebiliyorduk.
    Her gece on binlerce test çalıştırmasının, yeni kod yoksa temelde hepsinin yeşil yandığı noktaya kadar geldik. Kırmızı yanan testler neredeyse her zaman yakın zamanda eklenen koddan kaynaklanıyordu; bu yüzden kolayca tespit edilip düzeltilebiliyordu.
    Bu sayede ekip, yeni eklenen hataların hızla yakalanacağını bilerek geliştirme yapabiliyordu; bu da yayın sonrasında işlem işleme sistemini yeniden yazmak gibi cesur projeleri güvenle üstlenebilecek bir tempoya yol açtı. Sonuçta 10 kat hız artışı da elde edildi.
    Nihayetinde kaliteye odaklanmak hıza dönüştü ve ikisi hiç de birbiriyle çelişmedi. Bunun münferit bir durum olduğunu düşünmüyorum; bu yüzden yeni bir projeye yol açtı, ama bu bir sonraki hikâye.