Gerçek zamanlı işbirlikçi düzenleme, Google Docs ve Notion gibi uygulamalarla ana akıma girdi ve geleneksel tek kullanıcı test metodolojilerinin yeterince kapsayamadığı karmaşık dağıtılmış sistem zorlukları ortaya çıkardı. Görüşmeciler, adayların nihai tutarlılık doğrulamasının yarış koşullarını, ağ bölünmelerini ve CRDT (Çatışmasız Yeniden Eşlenen Veri Türleri) uç durumlarını simüle etmeyi anlamalarını değerlendirmek için bu senaryoyu geliştirdi. Bu soru, dağıtılmış sistem hatalarını anlayan deneyimli QA mühendislerini, yalnızca sıralı işlevsel testler yapanlardan ayırır.
Manuel test uzmanları, yarış koşullarını doğrularken benzersiz zorluklarla karşılaşır çünkü yarış koşulları doğası gereği belirlenemezdir ve ağ gecikmesi, otomatik betiklerin genellikle gözden kaçırdığı öngörülemez zaman pencereleri oluşturur. Arka uç entegrasyon testlerinin aksine, manuel doğrulama, sunucu tarafı işlem günlüklerine veya veritabanı kilitlerine doğrudan erişim olmadan, birden fazla istemci arasında durum senkronizasyonunu gözlemleyerek, otantik insan etkileşim kalıplarını simüle etmelidir. Temel zorluk, kabul edilebilir nihai tutarlılık gecikmeleri ile yalnızca belirli zamanlama koşullarında ortaya çıkan gerçek veri kaybı hatalarını ayırt etmektedir.
Sistematik bir yaklaşım, oturum matris testini kontrol edilen ağ bozulmasıyla birleştirir ve tarayıcı geliştirici araçlarını kullanarak gerçekleştirilir. Test uzmanları, Chrome DevTools throttling profilleri kullanarak izole tarayıcı oturumları arasında belirli işlem dizileri düzenler, her eylemin kesin zaman damgalarını belgeleyerek ve kontrol toplamları veya görsel farklılık araçları kullanarak birleşmeyi doğrular. Bu metodoloji, istemci tarafı birleştirme mantığını taşınma sorunlarından izole ederken, çatışma çözümü arayüz kalıplarındaki uç durumları keşfetmek için gerekli araştırmacı esnekliği korur.
Bağlam
Confluence tarzı kurumsal wiki yazılımını test ederken, ekibimiz kritik bir yayından önce yeni "Eşzamanlı Düzenleme" özelliğini doğrulamak zorundaydı. Londra, Singapur ve São Paulo'da bulunan üç paydaş, aynı sayfa bölümünü eşzamanlı olarak düzenlerken, São Paulo'daki kullanıcının değişikliklerinin bazen çakışma uyarısı veya birleştirme diyaloğu tetiklenmeden kaybolduğunu bildirdi.
Problemin tanımı
Açık hatanın oluştuğu durum, Londra'daki kullanıcının bir paragrafı silmesi, São Paulo'daki kullanıcının aynı paragraf içindeki metni eşzamanlı olarak düzenlemesi ve Singapur'daki kullanıcının orijinal bölüme bir yorum dizisi eklemesiyle gerçekleşti. Geleneksel tek kullanıcı işlevsel testi tamamen geçti, ancak dağıtılmış eşzamanlılık, silme işlemlerinin, belgedeki değiştirilmiş içeriği korumadan, eşzamanlı düzenlemelere öncelik verdiği operasyonel dönüştürme algoritmasında bir hatayı ortaya çıkardı.
Çözüm 1: Manuel çoklu cihaz orkestrası
Başlangıçta, coğrafi dağılımı simüle etmek için ayrı dizüstü bilgisayarlar kullanarak aynı odada fiziksel olarak üç QA mühendisi bulundurmayı düşündük. Bu yaklaşım, otantik ağ gecikmesini yakaladı ve macOS ile Windows istemcileri arasında senkronizasyon işlemleri sırasında donanım spesifik görüntüleme sorunlarını ortaya çıkardı. Ancak, tam milisaniye düzeyinde zamanlamayı eşzamanlamak neredeyse imkansız hale geldi, bu çaba zaman dilimleri arasında geniş bir koordinasyon gerektirdi ve kesin hata senaryolarını yeniden üretmek tutarsız kalıyordu, bu da regresyon doğrulamasını imkansız hale getirdi.
Çözüm 2: Manuel doğrulama ile otomatik kaos testi
İkinci yaklaşım, Selenium Grid kullanarak üç tarayıcı örneği arasında hızlı çelişkili girişleri otomatikleştirmek ve bir manuel test uzmanının görsel sonuçları ve kullanıcı deneyimi akışını gözlemlemesini sağlamak oldu. Bu, tekrarlanabilir zamanlama hassasiyeti sağladı ve yüzlerce çelişki senaryosunu insan koordinasyon hataları olmadan verimli bir şekilde yürütmeyi sağladı. Maalesef, otomasyon, çelişki çözümlemesi sırasında ani imleç sıçramaları ve geçici içerik yanıp sönmesi gibi kritik kullanıcı deneyimi sorunlarını gözden kaçırdı ve otomatik betikler, kullanıcılara sunulan çelişki çözümleme arayüzünün sezgisel netliğini etkili bir şekilde değerlendiremedi.
Çözüm 3: Ağ boğma ile matris tabanlı keşif testi
Tarayıcı sekmelerini bağımsız olarak farklı bant genişliği profillerine boğmak için Chrome DevTools Ağ Panelini kullanan bir hibrit metodoloji seçtik ve tüm eylem kombinasyonlarını kapsayan önceden tanımlanmış bir işlem matrisini birleştirdik. Bu, durum alanının sistematik bir şekilde kapsamını sağlarken, çelişki çözümleme esnasında kullanıcı arayüzü kalitesini değerlendirme konusunda insan yargısını koruyarak zamanlama üzerinde kesin kontrol sağladı. Ana sınırlama, kapsamlı operasyon matrisleri tasarlamak için önemli hazırlık süresi gerektirmesi ve karmaşık birleşme hatalarını doğru yorumlamak için dağıtılmış sistemler kavramlarına derin bir anlayış gerektirmesiydi.
Seçilen çözüm ve gerekçesi
Çözüm 3'ü seçtik çünkü sistematik titizliği pratik kısıtlarla dengeledi, düzenleyici uyumluluk için gerekli metotatik kapsamı sağladı ve fiziksel çoklu cihaz laboratuvarlarının altyapı aşamasını ortadan kaldırdı. Matris yaklaşımı, silme ile yeniden adlandırma işlemleri gibi uç durumları kaçırmamızı sağlarken, manuel yürütme test uzmanlarının senkronizasyon gecikmeleri sırasında gerçek kullanıcı acı noktalarını deneyimlemelerine olanak tanıdı. Bu metodoloji, çoklu cihaz kurulumlarına kıyasla minimal bir altyapı gerektirirken, tanımlanan sorunların giderilmesi için geliştiricilere yeterli yeniden üretilebilirlik sağladı.
Sonuç
Testin üzerinden iki gün sonra, operasyonel dönüşüm kütüphanesinin, ağ gecikmesinin 800 milisaniyeyi aştığında silme işleminden düzenleme işlemlerinin nasıl hatalı bir şekilde ele alındığını tespit ettik, bu da São Paulo'daki değişikliklerin kaybolmasına neden oldu. Geliştirme ekibi, eşzamanlı düzenlemelerin düzgün kaydedilmesini sağlamak için silme yayılımını geciktiren bir istemci tarafı tamponlama mekanizması uyguladı. Aynı matris yaklaşımı ile yapılan düzeltme sonrası doğrulama, elli hızlı çelişki senaryosu arasında tamamen tutarlılığı doğruladı ve özellik, uluslararası paydaşlar tarafından daha önce bildirilen veri kaybı sorunları olmadan yayımlandı.
Zamana dayalı çelişki çözümlemesinin, kullanıcılar farklı zaman dilimlerinde çalışırken ve yaz saati uygulaması geçişleri aktif düzenleme oturumları sırasında gerçekleştiğinde, bütünlüğü nasıl koruduğunu doğruluyorsunuz?
Pek çok aday, sunucu zaman damgalarının senkronizasyon çelişkilerinin otomatik olarak çözdüğünü varsayıyor, ancak manuel QA, uygulamanın tüm istemciler arasında UTC normalizasyonunu tutarlı bir şekilde kullandığını doğrulamalıdır. Aktif düzenleme oturumları sırasında sistem saatinizi manuel olarak değiştirerek test etmeli ve son yazma belirlemenin, yerel sistem saatinden ziyade vektör saatleri veya mantıksal zaman damgaları kullandığını doğrulamalısınız. Doğrulanması gereken kritik detay, çelişki çözümleme arayüzünün, hangi kullanıcının değişikliklerinin kazandığını doğru meta zaman damgalarıyla açıkça görüntülediğini kontrol etmektir; bu, son kullanıcıların yerel saat dilimi yönetimi veya yaz saati geçişleri gibi temel nedenlerden dolayı veri kaybı durumlarında sıradan çalışma arkadaşlarını suçlamalarını önler.
Diğer kullanıcıların işlemleri ile yerel düzenleme geçmişinizin iç içe geçtiğinde geri alma/ileri alma işlevselliğinin belgenin bütünlüğünü nasıl koruduğuna dair hangi teknikleri kullanıyorsunuz?
Adaylar sıklıkla işbirlikçi geri almanın, tek kullanıcı geri alımından temelde farklı olduğunu unutur çünkü Ctrl+Z, başka katılımcıların eşzamanlı düzenlemeleri yerine yalnızca kendi işlemlerinizi geri almalıdır. Bunu doğru bir şekilde test etmek için belirli bir düzenleme eylemi gerçekleştirin, başka bir kullanıcının aynı belge bölgesinde farklı bir işlem yapmasına izin verin, ardından değişikliğinizi geri almaya çalışın ve katılımcının çalışmalarının sağlam kaldığını doğrulayın. Zorunlu uç durum, geri alım işleminizin daha sonra başka bir kullanıcı tarafından değiştirilmiş metinleri etkilemesi durumunda ortaya çıkar, bu da sistemin ya geri alımı net bir uyarıyla engellemesi ya da katılımcının katkılarını aşındırmadan geri alma işleminin akıllıca dönüşümünü sağlaması gerektirir.
Diğer kullanıcılar aynı belgede önemli yapısal değişiklikler yaparken, kullanıcıların uzun süre çevrimdışı kaldıklarında sistemin geri alım ve düzgün düşüş süreçlerini nasıl doğruluyorsunuz?
Bu, çevrimdışı birinci mimari ve CRDT birleştirme yetenekleri üzerinde basit metin düzenlemelerinin ötesini test eder. Manuel QA, diğer kullanıcıların kapsamlı içerik değiştirdiği veya sildiği birkaç saat çevrimdışı kalan bir PWA simüle etmeli, ardından yeniden bağlanmalı ve sistemin açık bir farklılık arayüzü sunup sunmadığını veya yıkıcı bir şekilde otomatik olarak birleştirip birleştirmediğini gözlemlemelidir. Ana doğrulama noktaları, çevrimdışı kullanıcının değişikliklerinin çevrimiçi önemli değişiklikleri sessizce geçersiz kılmadığından emin olmayı, silinen bölümlerin çevrimdışı düzenlendiğinde uygun çelişki bildirimleri oluşturmasını doğrulamayı ve karmaşık yapısal değişikliklerin veri kaybı veya bozulma olmadan nasıl birleştiğini doğrulamayı içerir.