MOBİL UYGULAMALARINIZI DAHA İYİ TEST ETMENİZE YARDIMCI OLACAK 20 PRATİK TAVSİYE
Kurallara bağlanmadan onlara uyun.
—Bruce Lee
Başarısızlık ancak ideallerimizi, amaçlarımızı ve ilkelerimizi unuttuğumuzda gelir.
—Jawaharlal Nehru
Günümüzde, her mobil testçiye öğretilen ilk ders, “mobil test kullanıcılarının farklı bir zihniyeti yansıtması gerektiği ve mobil testin açıkça farklı bir yaklaşım gerektirdiğidir”. Hiç şüphe yok ki, ister kendiniz sağlam bir mobil test çerçevesi kuruyor olun, ister birileri bunu sizin için yapsın, bu size birçok fayda sağlayacaktır. Endişelenmeyin, size bütün faydaları açıklamayacağım çünkü bunu milyonlarca kez duyduğunuza ve yeni varsayımlar için yeriniz olmadığına inanıyorum. Bu yüzden size en temel mobil test tavsiyelerinden bazılarını vermeme ve bunlara dayalı olarak test stratejilerinizi tanımlamanıza yardımcı olmaya çalışmama izin verin. Bu ipuçlarını, uğraştığınız hemen hemen her mobil test projesine uyarlayabilirsiniz. Mobil test hakkında hiçbir fikri olmayan bir üst yöneticinin baskısı altındaysanız bunları kullanmaktan çekinmeyin.
1. Projelere erken katılarak erken test yapın ve mümkün olduğunca çok statik test yapmaya çalışın. Proje yöneticileri, tükettiği zaman nedeniyle bir veya iki günlük statik testi reddetme eğilimindedir. Öte yandan, aynı proje yöneticileri, statik test ile tanımlanabilecek doğrulanmamış hatalar nedeniyle dinamik testler gerektiği gibi bitmediği için aynı projeyi yirmi gün daha ertelemeye isteklidir!
2. Her şeyi test etmeyin. Bazı testçiler kahramandır ve her şeyi test etmeleri veya ürünü yüzde 100 test etmeleri gerektiğini söyler. Lütfen bu insanları sakinleştirin ve onlara yüzde 100 testin imkansız olduğunu söyleyin. Bunun yerine, çok daha iyi ve ulaşılabilir bir yaklaşım olan riske dayalı testler önerebilirsiniz.
3. Kendini adama önemlidir, bu nedenle mobil test kullanıcılarının uygulamalarınızı test etmesine izin verin. Herhangi bir ürünü test etmek için bir test cihazına ihtiyacınız olduğunu söylediğinizde iş analistlerinin rahatsız olmasını anlamakta zorlanıyorum. Ancak test zamanı geldiğinde, ondan uzak durmaya çalışıyorlar ve çok sayıda yüksek öncelikli görevleri olduğunu ve bunun yerine analiz/tasarım ödevlerine odaklanmalarının daha iyi olacağını söylüyorlar. Sonuçta timsah gözyaşlarına inanmayın; mobil test araçlarınızı kullanın.
4. Testçiler hata bulmaktan mutlular çünkü bunun için para alıyorlar. Karamsar, şüpheci ve sorgulayıcı karakterlerine farklı bir anlam yüklemeyin. Geliştiricilerin kovulması için değil, yaşamak için kusur buluyorlar.
5. Kusurlar ortak alanlarda kalmaz; bunun yerine unutulmuş yerlerde takılmayı ve hayatlarını sınırlarda yaşamayı severler. Bir mobil bankacılık uygulamasının açılış ekranında yanlışlıkla koşan bir at tespit etmeyi bekliyorsanız boşuna beklemeyin. İnsanlar size görünmeden önce atı algılar.
6. Bulunan kusurlar, diğerlerinin varlığının bir göstergesidir. Asla “X modülünde üç kusur buldum, hadi diğer modülleri test edelim” demeyin. X modülünde güvendeyiz. Böyle bir durumda karınca yuvalarını unutmayın. Yuvaya yukarıdan baktığınızda sadece birkaç karınca görürsünüz. Ancak toprağı kazdığınızda yüzlerce karınca görürsünüz. Kusurlar karıncalar gibidir. Çoğu zaman görünmezdirler ve birlikte kalıp hareket ederler.
7. Kusurlar her zaman program arızaları değildir; bazen sadece sizi rahatsız eden şeyler olabilirler. Bir mobil uygulamayı test ederken sadece işlevsel eksiklikler aramamalı; bazen kusurlar, program arızalarından ziyade can sıkıcı, aptalca şeyler olabilir. Bazı geliştiriciler, “Bu bir kusur değil; çalışıyor.” derler. Ancak bu tür illüzyonlara inanmayın. Hataları bildirin.
8. Mobil dünyada, diğer kategorilerden daha fazla kullanılabilirlik ve performans testi yapmanız gerekiyor. Kullanıcılar sabırsızdır ve öncelikli olarak işlevselliğe odaklanmazlar. Bunun yerine basit ve kullanıcı dostu ürünlerin arayışı içindedirler.
9. Her şeyi otomatikleştirmeye çalışmayın; çoğu durumda kullanıcı davranışına da öncelik verilmelidir. Mobil dünyada herhangi bir test senaryosu otomatikleştirilebilir, ancak gerçek geri bildirim arıyorsanız manuel test yapmanız gerekir. Üzülmeyin; bu dünyanın sonu değil ve saçma sapan bir test senaryosunu otomatikleştirirseniz kimse sizi terfi ettirmiyor.
10. Test uzmanlarınızı belirli bir süre içinde hazırladıkları test vakalarının sayısıyla övmeyin. Bunun yerine, bunları test senaryosu başına kusur oranına göre değerlendirmeniz gerekir. Bu durumda, daha büyük olmanın her zaman daha iyi olmadığını hatırlamalısınız (en azından testte değil!). Testçiler test senaryoları hazırlarken genellikle zamanla yarışırlar. Sonuç olarak, kusur tespit edilebilir test senaryoları hazırlamak, yüzlerce başarılı (geliştirici aşığı) test senaryosu hazırlamaktan çok daha iyidir. Test uzmanlarını daha az test senaryosu ile daha fazla hatayı tespit etmeye teşvik edin.
11. Test paketlerinize bazı olumsuz test senaryoları eklemeye çalışın. Mutlu yol testi, bir süre sonra size kusur bulmaz.
12. Kullanılabilirlik testi yaparken, “daha fazla, daha azdır” ifadesini tek başına konuşmanız gerekir. Bir uygulama çok sayıda alan, çok sayıda kullanılmayan/gizli işlevsellik ve çok sayıda kontrol içeriyorsa, kullanıcılarını mutsuz etme olasılığı yüksektir. Mobil uygulamalar, kullanıcıları tarafından kullanılırken herhangi bir seçim çelişkisi yaratmamalıdır. Bu arada, Barry Schwartz’ın Seçim Paradoksu kitabını okumanızı öneririm. Bunu yaparsanız, “daha fazla, daha azdır” olgusunu daha iyi anlayacaksınız.
13. Uygulama mağazası taleplerinin (uygulama açıklamaları) uygulamanın kendisi tarafından karşılanıp karşılanmadığını kontrol eden bir etkinlik olan talep testi yapmayı unutmayın. Dünyayı kurtardığını ve size cenneti göstereceğini iddia eden birçok uygulama biliyoruz, ancak gerçekte bu berbat. Bir mobil test kullanıcısı olarak bunu da ortaya çıkarmanız gerekiyor.
14. Test yaparken “karanlık taraftan” uzak durduğunuzdan emin olun. Star Wars: Bölüm III—Sith’in İntikamı filmini ve Anakin Skywalker karakterini hatırlayın. İyi tarafta (Jedi gücü) olmak için doğdu, ancak karanlık tarafa geçtikten sonra Darth Vader oldu. Bir mobil test kullanıcısıysanız, hataları bildirmeniz (öğleden sonraki sürümde düzeltilecek olsalar bile), geçerli ölçümleri bildirmeniz (sizi bazı gözetimsiz test durumlarına işaret etmelerine rağmen) bildirmeniz ve dürüst olmanız gerekir. Herhangi bir veriyi tahrif ederseniz veya bir geliştiriciye aşık olduğunuz için bir kusur bildirmezseniz, karanlık tarafa girersiniz. Ne yazık gerisi daha kolay olacak. Siz farkına bile varmadan, organizasyonunuzun Darth Vader’ı olacaksınız. Usta Yoda’nın dediği gibi, “Geliştiricilere karşı duygularınızın muhakemenizi bulandırmasına izin vermeyin”. Dikkatli olun!
15. Ne yazık ki mobil dünya, mobil test kullanıcılarından çok daha hızlı gelişiyor. Bu yetenekli mobil test kullanıcılarına her zamankinden daha fazla ihtiyaç duyulduğu ve kuruluşların test uzmanlarını eğitip gerekli yatırımları yapmadığı sürece mobil dünya ile test kullanıcıları arasındaki farkın daha da açılacağı anlamına geliyor. Ancak mobil test kullanıcısıysanız ve şirketinizin sizin için gerekli eğitimleri ayarlamasını ve gelişiminize sürekli yatırım yapmasını bekliyorsanız, hayali bir dünyadasınız demektir. Kimse sana senden daha fazla yatırım yapmaz. Bu yüzden uyanın ve kendi meydan okumanızı yaratmaya çalışın. Yepyeni bir akıllı telefon satın almak, her zaman mobil test eğitimi için ödeme yapmaktan daha iyi değildir. İkisini de yapmanız gerekiyor.
16. Herhangi bir test faaliyetine başlamadan önce test hedeflerinizi ve bunların iş gereksinimleriyle uyumunu kontrol ettiğinizden emin olun.
17. Dinamik olmaya çalışın ve kendinizi zaman baskısına, sık değişikliklere ve bütçe kısıtlamalarına hazırlayın.
18. Test metodolojinizi SDLC yaklaşımınıza uyarlayın. Test etme tamamen bağlam odaklı bir aktivitedir, bu nedenle çevik, şelale, spiral veya v-model geliştirme yapıyorsanız önemli bir fark yaratır.
19. Kusursuz bir uygulama, başarılı olduğunuz anlamına gelmez. Herhangi bir mobil uygulamanın ana başarı faktörü, yarattığı kullanıcı memnuniyetidir.
20. Ve son olarak, %100 test yanılsaması var. Hiçbir durumda “Uygulamayı %100 test ettik” demeyin. Bu mümkün değil! Bir mobil uygulamayı yıllarca test etmiş olsanız bile, hiç kimse ürünün yüzde yüz test edildiğinden emin olamaz. Verdiğim eğitimler sırasında bazen bu ilkeye itiraz edenler oluyor ve “Test senaryolarımızda tüm gereksinimlerin karşılandığından emin olabiliriz. Mevcut araçlar ve teknolojiler, yüzde yüz gereksinim kapsamı elde etmemizi sağlıyor.” Cevabım basit, yüzde yüz gereksinim kapsamı, ürünün yüzde yüz test edildiği anlamına gelmez. Bunun nedeni, gereksinimlerin hala insanlar tarafından yazılıyor olması ve hiç kimse bu eserlerin herhangi bir mobil ürünün tüm işlevsel ve işlevsel olmayan yönlerini kapsadığından yüzde yüz emin olamaz. Bu nedenle, “Tüm gereksinimler karşılandı” dediğinizde, ürünün yüzde yüzünün test edildiği anlamına gelmez. En azından akıllı insanlar aradaki farkı ayırt edecektir.
Mobil testlerde yukarıdaki ilke ve stratejilerin önemli olduğunu düşünüyorum. Yüzde yüz katılsanız da katılmasanız da, çoğunluğu fikirlerinizi, organizasyonlarınızı ve süreçlerinizi oluşturmanıza ve daha iyi kararlar almanıza yardımcı olabilir.
Victor Hugo’nun bir zamanlar dediği gibi, “Fikirlerinizi değiştirin, ilkelerinize bağlı kalın; yapraklarını değiştir, köklerini sağlam tut.”.