Test Ekibi Olmadan Facebook Mobil Uygulamasını Nasıl Test Ediyor?
Facebook mobil uygulaması hakkında yazılan “ Continuous Deployment of Mobile Software at Facebook” makalesini incelediğim serinin ikinci yazısına hoş geldiniz.
Serinin ilk yazısında Facebook mobil uygulamasının “deployment” süreçlerine değinmiştik. Bu yazıda “test” uygulamaları ve süreçleri hakkında makaleden aldığım notları ve yorumlarımı sizlerle paylaşacağım.
İlk yazıyı okumak isteyenler için linki bırakıyorum.
Önemli not: Bu yazıdaki bütün bilgiler aşağıda linki verilen makaleden alınmıştır.
Makaleye ulaşmak isteyenler şu linki kullanabilir: https://research.fb.com/wp-content/uploads/2017/02/fse-rossi.pdf
Mobil Uygulama Testleri Neden Daha Önemli?
Herhangi bir test için önemsiz demek pek doğru olmayabilir ama mobil uygulamarın testleri aşağıda listelenen sebeplerden ötürü çok daha önemli ve zorlu olabiliyor.
- Her hafta mobil uygulamaya binlerce güncelleme yapılıyor.
- Mobil uygulamanın çalıştırılabileceği yüzlerce cihaz ve işletim sistemi kombinasyonu var.
- Deployment yapıldıktan sonra oluşuacak hata durumlarında düzeltici aksiyonlar alabilmek zor ve imkanlar sınırlı. Risk arttığı için de testlerin de önemi artıyor.
İlginç bilgi: Facebook yazılım ekibinde test için özel bir takım yok
Test Altyapısı (Testing Infrastucture-as-a-Service)
Tahmin ettiğiniz gibi Facebook gibi devasa sayıda kullanıcıya hizmet veren bir uygulamayı test edebilmek için çok güçlü bir altyapıya ihtiyaç var. Makalede bu altyapıdan şöyle bahsedilmiş;
- Binlerce “node” sadece mobil uygulamayı test etmek için ayrılmış durumda. White-box ve Black-box testleri sümülasyon ve emülasyon ortamlarında koşturuluyor. (Simülasyon ve emülasyon farkı için: https://www.quora.com/What-are-the-differences-between-simulation-and-emulation)
- Gerçek mobil cihazlarla test yapabilmek için Prineville data-center kullanılıyor. Bu laboratuvarda yoğunluklu olarak mobil uygulamanın hızı, hafıza kullanımı ve batarya verimliliği test ediliyor.
- Laboratuvarda elektro-manyetik olarak izole edilmiş rack kabinler bulunuyor. Bu kabinlerin içinde iOS ve Android cihazlara bağlı çok sayıda “node” bulunuyor.
- “Node”lar test edilecek uygulamayı kuruyor, test ediyor ve daha sonra ilgili cihazdan kaldırıyor. Cihazların konfigürasyonunu otomatik konfigürasyon aracı olan “Chef” ile yönetiyorlar.
İlginç bilgi: Test yapılan cihazların ekranlarını kamera ile takip ediyorlar, kodu değiştiren yazılımcı değişikliğinin direkt etkisini bu sayede görebiliyor.
Test Prensipleri
Facebook mobil uygulamasını daha iyi test edebilmek için 5 prensip belirlemiş.
1. Kapsam (Coverage)
Testler kaynakların elverdiği ölçüde en kapsamlı şekilde koşturulmaya çalışılıyor. Neredeyse yazılan bütün testler, o test için anlamlı olacak bir frekans ile koşturuluyor.
2. Tepki Veren (Responsive)
Test yapmanın en önemli amacı hataları en kısa sürede yakalayıp düzeltilmesini sağlamak diyebiliriz. Hatalar erken yakalandığı zaman çözümü hem daha az maliyetli hem de daha hızlı oluyor.
Facebook’un mobil uygulamasını test ederken hedefi, smoke testler ile 10 dakika içerinde kod değişikliği yapan kişilere geri bildirim verebilmek.
3. Kalite
Facebook gibi bir uygulamayı test ederken çok fazla sayıda false-positive ve false-negative durumlar oluşabiliyor. Facebook’un buradaki hedefi hataları çok keskin bir doğruluk ile bulmak. Aksi durumda hem geliştiricilerin vakti boşa harcanmış oluyor daha da kötüsü belli bir süre sonra hata durumları görmezden gelinmeye başlanabiliyor.
4. Otomasyon
Bu kadar yoğun testi yapabilmek ancak test otomasyon sistemleriyle mümkün olabiliyor. Facebook çok büyük bir şirket olsa da insan kaynağı sınırsız değil ve varolan kaynağı verimli kullanabilmek için bütün sistemlerinde otomasyonun büyük önemi var.
Serinin ilk yazısında “deployment” için süreçlerin büyük bir bölümünün otomasyon ile yapıldığından bahsetmiştik. Test için de aynı şeyi söylemek mümkün. Bu sayede testler düzenli ve kısa aralıklarla tekrarlanabiliyor. Ayrıca otomasyon ile bir hata tespit edildiği zaman, ilgili kod bloğunda son değişiklikleri yapan geliştiricilere otomatik bir bildirim gidiyor.
5. Önceliklendirme
Daha önce de belirttiğim gibi bu kadar kapsamlı testleri yapabilmek için çok fazla kaynağa ihtiyaç duyuluyor. Kaynakları daha iyi kullanabilmek için otomasyon sistemleri kullanılıyor ama yine de her testi her zaman yapmak mümkün olmuyor. Otomasyon sistemleri insan kaynağına ihtiyaç duymasa bile donanım kaynağına ihtiyaç duyuyor ve o kaynak da sınırlı.
Bu sebeplerle testlerin belirli durumlar için önceliklendirilmesi gerekiyor. Örnek vermek gerekirse;
- Master branch’ine herhangi bir değişiklik yapılırsa geliştiriciye daha kısa sürede geri bildirim verebilmek için sadece ilgili kısımların entegrasyon testi koşuluyor.
- Entegrasyon test suite’inin tamamı Master ve Release branchleri için bir kaç saatte bir koşuluyor.
Test Zamanları
- Push Öncesi Testleri: Facebook ekibinde ayrı bir test takımı yok. Bu sebeple Master branch’ine atılacak her kod parçasının öncelikle review edilmesi gerekiyor. Bunun bışında geliştiriciler kendi bilgisayarlarında birim (unit) testlerinin bir kısmını koşturabiliyorlar. Tamamını koşturmak isterlerse server makinelerindeki simülasyon ortamındaki birim testlerini çalıştırıyorlar. Bunlara ek olarak aşağıdaki testleri manuel olarak koşturabiliyorlar.
Statik Analiz : Null-exception hataları ve memory leak hataları statik analiz ile yakalanmaya çalışılıyor.
Build Testleri: Kodun tamamının hatasız bir şekilde build olup/olmadığı test ediliyor.
Snapshot Testleri: Uygulamadan snapshotlar alınarak pixel seviyesinde ekranlar inceleniyor ve daha önceki snapshotlar ile karşılaştırılıyor.
Entegrasyon Testleri: Black-box şekilde yapılan regresyon testleriyle uygulamanın en önemli özellikleri ve en çok kullanılan akışları test ediliyor. Simülasyonlar üzerinde, herhangi bir cihaz bağımlılığı olmadan yapılıyor.
Performans Testleri: Laboratuvar ortamında uygulamanın performansı ve kaynak kullanımı test ediliyor.
Kapasite Testleri : Uygulamanın belirlenen kapasite limitlerini aşıp/aşmadığı test ediliyor.
Uygunluk Testleri: Uygulamanın belirlenen isterleri (requirement) karşılayıp/karşılamadığı test ediliyor.
2. Push Sonrası Testleri: Geliştirici push yaptığında bunun bloklanıp/bloklanmayacağına karar vermek için,
- standart birim testleri
- sık kullanılan özellikler için “smoke” testleri
- değiştirilen kod ve bağımlılıkları için “build” testleri koşturuluyor.
Bütün testler başarılı olarak geçerse, kod Master branchi ile birleşiyor.
3. Master ve Release Branch için Sürekli Testler: Bir kaç saatte bir Master ve Release Branch’i için
- Bütün kodu kapsayacak şekilde “build” testleri
- Bütün suite çalışacak şekilde “entegrasyon” testleri
- Laboratuvarda koşulan “performans” testleri koşuluyor.
iOS uygulaması için günde 2 kez, Android uygulaması için günde 1 kez Master branch’inden alpha versiyonu üretilip test ediliyor.
Release branch’inden ise günde 3 defa beta versiyonu üretilip, test ediliyor.
Manuel Testler
Otomasyon ile yapılabilen bütün testlerin otomatik olduğundan bahsettik ama yine de sözleşmeli şekilde çalışan 100 kişilik bir ekip (yazının yayınladığı 2017 yılı itibariyle) manuel olarak uygulamayı test ediyor.
Bu ekip smoke testleri ve edge-case testleri yapıyor. Ayrıca yeni geliştirilen özellikleri test otomasyonları hazır olmadığı için yeni özellikleri de manuel olarak test ediyorlar.
En son olarak da, dil destekleri sağlandıktan sonra uygulamanın ara yüzünü son kez kontrol ediyorlar.
Sonuç
Bu yazı kapsamında;
- Mobil uygulama için yapılan testlerin zorluklarına
- Facebook’un mobil uygulamasını test edebilmek için kullandığı güçlü altyapı’ya
- Test süreçlerinde takip ettikleri prensiplere
- Test zamanlarına ve test tiplerine değinmeye çalıştık.
Bunlara artı olarak da Facebook’da ayrıca test yapan bir test ekibinin olmadığını ve yoğunlukla kendi yazılımcılarının ürettiği araçlar ile otomatik testler yapıldığını öğrenmiş olduk.
Bir sonraki yazımda aynı makaleden aldığım notlar kapsamında Facebook’un 8 senelik datasından çıkardığı ilginç sonuçları sizlerle paylaşacağım.
Bu yazıyı yazmama vesile olan Gokhan Topcu’ya teşekkür ederim.
Okuduğunuz için teşekkürler. Alkışlayarak ve paylaşarak destek olmayı unutmayın.
