Test Stratejileri ve Spotify – Kristian Karl

Spotify’da testleri Canlı Sistem’de yapıyoruz.

TESTISTANBUL 2016’da Spotify’dan Kristian Karl ile keyifli bir söyleşi yaptık.

Spotify’daki ekiplerin yapılarını bize anlatır mısınız?

Temel olarak, çok işlevli ekiplerden bahsediyoruz. Her ekibin bir görevi var ve ürünün bir parçasından sorumlu. Bunu başarabilmeleri için bazı yetkinliklere ve bir dizi beceriye ihtiyaçları var. Bazı ekipler sadece arka uç geliştiricilerden oluşuyor; bazı ekipler hem arka uç ve ön uç geliştiricilerden, hem de test uygulayıcılardan oluşuyor. Bazı ekiplerin test uygulayıcıları yok. Tüm bunlar, karşılaştıkları sorunlara ve aldıkları görevlere göre değişiyor. Tek cümlede özetleyecek olursak tüm ekiplerin çok işlevli olduğunu söyleyebiliriz.

Siz bunlara kabile (tribe) ve bölük (squad) diyorsunuz.

Evet, doğru. Ondan fazla kabilemiz (tribe) ve yüzden fazla bölüğümüz (squad) var. Kabile derken takım, bölük derken de ekipleri kastediyoruz. Takımlar daha bilgilendirilmiş ekipler.

“Bölük (squad)” gruplarının Spotify ’da çok dar bir bakış açısı var, onlar sadece amaçlarını bilirler, oysaki takımların neler olup bittiği ile ilgili daha geniş bilgileri vardır. Örneğin; ben medya ortamı ekibinde çalışıyorum, esasen bu ekibin iki amacı var, birincisi sesli, sesli olmayan, video, podcast gibi tüm verileri incelemek ve bizden hizmet alan haber ajansları, stüdyo şirketleri, BBC vb.gibi şirketlere iyi bir deneyim sağlamak. İşin diğer tarafı da müşterilerimize ürün yapan asıl ekiplere; iç müşterilerimize bir ara yüzle bu verileri sağlamak. Böylece görüntüleri meta verilerle besleyebiliyorlar. Müziği çalmak istedikleri zaman “liste akışı-stream” sağlıyoruz. Bu benim içinde bulunduğum takımın yaptığı iş. Altyapısı daha geniş olan, Spotify ’in tamamına verimlilik sağlayan başka takımlarımız, mesela ara yol takımımız(aisle tribe) da var. Takımlar tüm resmi görmeseler de daha geniş bir görüş alanları var.

Test uygulamanın programlamadan farkı olmadığını söylediniz. Lütfen bunu biraz daha açar mısınız?

Programlama çok yaratıcı bir süreç. Bir programcı olarak benim gerçekleştirmek istediğim bir amacım var ve bunun için bazı sözcükleri bir araya koymam, program dilinde yazmam gerekiyor ki Java veya C++’a benzer olsun. Programlamayı sizin için yapacak kimse yoktur, bunu sizin yapmanız gerekir. Bunun için üretim sürecinde kullanabileceğiniz IntelliJ ya da Eclipse gibi farklı araçlar var, ancak bunlar da programlamayı sizin için yapamaz. Bu süreçte ancak size yardımcı olabilirler.

Aynı şey test uygulama için de geçerlidir. Test otomasyonundan bahsettiğimiz zaman, bu otomasyon bir test uygulama süreci değildir, burada bahsettiğimiz otomasyona uğramış bir doğrulama sürecidir ya da denetimdir. Biz programların “belirli” bir şeyi aramasını isteriz. Test uygulama, insan zekâsı ile deneyimi birleştiren bir süreçtir. Ben, test uygulama süreci esnasında neler olduğunu incelerim. Birden bire, sıra dışı bir şey fark ederim, olmaması gereken garip bir durumla karşılaşırım: bunu deneyimim ve zekâmla çözerim ancak bu süreci programlamak çok zor bir iş. Bana göre test uygulama süreci programlama ile eşdeğerdir. Programlamayı nasıl tam anlamıyla otomatize edemiyorsak benzer sebepler test uygulama otomasyonu için de geçerli.

Program geliştiriciler için geçerli olan gelişim ortamı test uygulama için de mevcut. Birim testlerini gerçek test olarak değerlendirmiyorum ancak kalite için iyi ve gerekli. Kaliteyi en başından beri önemseyen program geliştiricilerini program gelişimi yönteminin içine sokuyor.

Benim için, test otomasyonu veya otomatikleşmiş doğrulama test uygulama sürecinde yardımcı olan metot ve araçlardır. Varsayımlarda bulunabilirim ve eğer gerçekten iyi düzeyde otomasyon kapsamı olursa, sonuçtan daha emin olurum. Bu alanda kodlamaya fazla dokunmadan sistemin detaylarına daha fazla odaklanabilirim.

İşin ne kadar yüzdelik bir kısmı makineler tarafından yapılıyor veya yapılacak?

Testlerin ne kadar kısmının makineler tarafından otomasyona tabi olacağını bilmiyorum.

Bunun yerine test uygulamada insanların yerine makineleri kullanamayacağınızı söyleyebilirim. Test uygulayıcıların %20’sini kaybedebiliriz ancak uygulayabileceğiniz testlerin sayısı sonsuzdur. Eğer otomasyon bize yardımcı olacaksa ben de daha derin, ileri seviyede ve geniş kapsamlı testlere odaklanabilirim. Benim otomasyondan anladığım ve başarmak istediğim bu.

Slaytlarınızdan anladığım kadarıyla testlerin bazı bölümleri makineler tarafından yapılabiliyor çünkü bunlar rutin, operasyonel unsurlar ancak diğerleri için kesinlikle insan duyusuna ihtiyacınız var.

Evet, doğru. Spotify ‘da çalma listesi benim bir araya getirdiğim albüm şarkılarından oluşan bir derleme. Şarkı listemde bir güncelleme yapmak istediğimde, şarkı ekleyebiliyorum, çıkarabiliyorum veya değiştirebiliyorum. Düşük seviyede bir birim testi uyguluyorum, komple sistemde bu tip durumları doğrulamak için işlevsel testlerim olabilir. Bunu otomasyon sürecine sokarsam benim için gerçekten çok yararlı olur. Tamamen otomasyona güvenemem çünkü insanın sistemle nasıl etkileşim içerisinde olduğu da önemli. Farz edelim; tüm işlemleri müşteri tarafından doğru olarak yaptık ve veri açısından baktığımızda da problem yok, sonra bir albümden şarkıyı çıkardığınızda fark ediyoruz ki liste eksik. Oldukça kötü bir durumdur bu. İşte burada insan faktörü devreye giriyor, çünkü insan; anonim ve sıra dışı şeyleri fark etmede başarılı. Kullanıcı, aniden iyi görünmeyen ciddi bir şeyi saptayabilir. Veri tabanı uygun diyor, şarkıların sayısı doğru ama liste yanlış, eksik bir şekilde işlenmiş. İşte bunlar gerçekten otomasyona güvenmediğim yerler. Ben bir şekilde yargı çağrısı yapıyorum, bu doğrulama süreçleri güvenilir olmak için oluşturuluyor ama yine de tamamen onlara güvenmiyorum. Her şey benim test uygulayıcısı olarak zamanımı nerede harcadığıma bağlı.

Karşılaştığınız zorluklar neler ve bunlarla nasıl baş ettiniz? 

Güvenilirliği yüksek, istikrarlı testler yapmak ve bu noktaya ulaşmadaki izlenecek yol karşılaştığımız zorluklar. Eğer test uygulamanız gereken zor bir sisteminiz varsa, test edilebilir çok fazla eleman eklemeniz gerekir. Bazen ürün sahiplerine sizin istediğinizi vermemiz için on ekstra gün gerekiyor diyorum. Hoşlarına gitmiyor tabii ancak gelecekte güvenilirliği yüksek bir ürün çıkartmak için yapmamız gereken bu oluyor. Bu yüzden bu sürecin bir nevi mühendislik problemi olduğunu söyleyebilirim.

Süreç mühendisliği mi?

Hayır, salt mühendisliktir. Ekip olarak, biz oturup düşünürüz; testleri nasıl yürütüyoruz, nasıl doğruluyoruz? Güvenilir olmaları gerekli. Buna ulaşmak için neye ihtiyacımız var? İşte asıl çabayı burada harcıyoruz. Bir seviyeye kadar güvenilir testler yapmanız lazım. Eğer güvenmezseniz, testler başarısız olduğunda size karşı bir tutum gelişecektir. Asıl işte o zaman gerçek bir sorunla karşı karşıyasınız demektir. En büyük zorluk budur. Bunun ekip içerisinde tartışılması ve değerlendirilmesi gerekir.

Sunumunuzda Canlı Sistem üzerinde yaptığınız test uygulamalarından bahsettiniz.

Evet, Canlı Sistem’de test yapıyoruz.

Bu ifade biraz riskli değil mi? Canlı sistemde nasıl test yaptığınızı açıklar mısınız?

Canlı Sistemi test ediyoruz dediğimizde bizim canlı verilerimizi kullanıyoruz demek istiyoruz. Test amaçlı oluşturulan hesapları kullanıyoruz. Kimsenin gerçek hesabını kullanmıyoruz. Sadece kendi hesaplarımızı ve canlıda kullandığımız test hesaplarını kullanıyoruz.

Hayali kullanıcılar oluşturup sonra da test mi uyguluyorsunuz?

Hayali kullanıcılar değil, onlar gerçek test amaçlı oluşturulan hesap kullanıcıları.

Bildiğim kadarıyla Facebook’da  bunu yapıyor, ama farklı kümeleri(cluster) var. Canlı verilere bir şey olduğunda, bir şeyler yanlış gittiğinde kümeyi değiştiriyorlar. Buna benzer bir şey yapıyor musunuz?

Bu yöntemle ne tür problemlerle karşılaşabileceğimiz üzerine tartışıyoruz. Biz yazılım yapmıyoruz ve hiçbir şeyi yok etmiyor ya da değiştirmiyoruz. Banka verileri ve ona benzer şeylerle etkileşim içerisine girmiyoruz. Bu bizim konumuz değil. Bu olası da değil. Bizim yaptığımız çalma listesi yaratmak, şarkıları dinlemek ve nasıl bir veri trafiği olduğunu takip etmek. Bizim test anlayışımızda herkes aynı ekosistem içinde yaşıyor. Demek istediğim canlı sistem açısından bu kullanıcılar sadece farklı kullanıcılar. Facebook’un yaptığına henüz ihtiyacımız yok. Gerçekten nasıl yaptıklarını bilmiyorum.

Test uygulama sektöründe önümüzdeki on yılda neler olacak?

Kesinlikle daha çok otomasyon doğrulama sistemleri olacak.

Örneğin daha çok test mühendislerimiz olacak mı?

Evet, belki.

Veya yapay zekâya sahip makineler daha fazla görev üstlenecek mi?

Sanırım. Kesinlikle bunu söyleyebilirim. Demek istediğim on yıl çok uzun bir zaman dilimi.

Beş yıl desek?

Yüksek derecede otomasyon sistemlerinin yer alacağını ve gelecekte daha istikrarlı ve güvenilirliği yüksek test sonuçları elde edeceğimizi hayal edebiliyorum. Sanırım, gelecekte bugün yaptığımız kadar fazla zaman harcayacağız ama otomasyondan elde edebileceğimiz bilgiler ve kullanacağımız araçlar test uygulama işimizi hayli değiştirecek. Test uygulama olarak düşündüğümüzde biz hemen hemen aynı işi yapıyor olacağız. Spotify’da başladığımız test koçu uygulamasıyla, ekiplerin kaliteyi ve daha fazla test uygulamanın önemini anlamasına yardımcı olmaya çalışıyoruz. Ekipler daha bilinçli olabilir. Bankacılık ve finansı da içerecek şekilde daha geniş çaplı bakarsak, otomasyonu bugün olduğundan kesinlikle farklı bir ölçekte görüyorum.

Gençlere üniversiteye gitmelerini ve test mühendisi, test otomasyonu uzmanı ve test uygulama sektörünün bir parçası olmalarını önerir misiniz?

Elbette. Benim tecrübelerime göre, en iyi test uygulayıcılar en iyi eğitim almış olanlar olmayabilir, iyi bir eğitim almış olabilirler, kimse üstüne alınmasın. Burada kilit nokta: deneyim ve bu deneyimin nasıl ele alındığı ve kullanıldığı. İleri yaştaki uzmanların daha iyi test uygulayıcıları olduklarını söylemiyorum. Bu tecrübenizle nasıl çalıştığınıza ve tecrübenizi nasıl ele aldığınıza bağlı. Genelde şunu söyleyebilirim ki bildiğim en iyi test uygulayıcı uzmanları geçmişlerinde geliştirici olarak çalışmış olanlar. Birçoğunun üniversite geçmişi var, bilgisayar bilimi üzerine eğitimi var, gelişmeye herhangi bir noktadan başlayıp kalite sürecine doğru yol alıyorlar. Bence başlangıç yapmak için oldukça uygun bir rota. Bir test uygulama uzmanı olarak programlama dilini, kurmuş olduğun sistemin test işlemleri esnasında nasıl çalıştığını bilmek gerekli. Sonuçta bilgisayar bilimi üzerine lisans, ön lisans düzeyinde bir eğitime sahip olmalı, biraz da program yazma ve program açısından işlerin nasıl yürüdüğünü anlamalı ve daha sonra da kalite safhasına geçmelisiniz.

Otomasyonun artacağından bahsettiniz. Buna rağmen test uygulama alanında iş imkânı olacak mı?

Bir hizmet olarak test uygulamanın yarın da var olacağını kesinlikle söyleyebilirim. Genelde, test deneyimlerini pazarlayan uzmanlar emin olun var olacaktır.

Startuplar için önerileriniz nelerdir? Sizce iyi bir sektör mü? Yaratıcı çözümler örneğin bir yazılım oluşturmak gibi denenmeli mi?

Yazılıma gelince, geçmişte WinRunner, LoadRunner kullanıyorduk. Bugün muhtemelen ihtiyaç duyabileceğiniz her türlü aracı sağlayabilecek, gerçekten herkese açık olan iyi bir kaynak topluluğumuz var. Burada bir konuşmacının dediği gibi; konu, en iyi aracı seçmekte değil, yapmanız gereken öncelikle ihtiyaçlarınızın ne olduğunu bilmek ve ondan sonra bunu kendi başınıza mı inşa edeceğinize -ki bu kötü bir fikir-  yoksa dış kaynak mı kullanacağınıza karar vermek. Herkesin kullanımına açık çok fazla araç var. Demek istediğim, bu ihtiyaçlarınızın neler olduğuna ve bu döngüde kendinize ne kadar harcama yapmak istediğinize bağlı. Test uygulamalarını ücretsiz yapabileceğiniz uygun araçlar var. Araç bulmakla ilgili bir sorun yok. Araçlar geçmişte çok pahalıydı. Bugün artık bu da problem değil. Web testi yapmak istiyorsanız örnek verecek olursak Selenium’u kullanabilirsiniz. Mobil uygulama testi yapacaksanız Appium’u kullanabilirsiniz. Tüm bu araçlar uygun. Tüm bu araçlar içinden bir başlangıç yapmak istiyorsanız burada bir gelecek görmüyorum.

Hizmet sektöründe test uygulama sürecinde daha fazla fırsat olduğunu düşünüyorum.

Çok teşekkür ederiz.

Benim için keyifti.