Para Tasarruf Ettiğinizi mi Düşünüyorsunuz? Kötü Test Kullanıcılarının Kesinti Süresinde 10 Kat Daha Fazla Maliyeti!

Basit bir test hatasının çok pahalı bir hataya dönüştüğünü gördüm. Zayıf bir test uzmanı başlangıçta genellikle ucuz görünür. Saatlik ücret daha düşük görünüyor, işe alım kolay görünüyor ve ekip hızlı hareket ediyor. Daha sonra ürün kaymaya başlar. Hatalar kullanıcılara ulaşır. Destek biletleri artıyor. Çıkış tarihi yeniden değişiyor. Ekiplerin gözden kaçan sorunları düzeltmek için başlangıçtan itibaren dikkatli testlere harcayacaklarından çok daha fazla para harcadığını gördüm. Bu nedenle kötü test uzmanları birçok takımın beklediğinden daha pahalıya mal oluyor. Bir ürünü piyasaya çıkmadan önce koruyan detaylara çok dikkat ederim. İyi testler yalnızca hataları bulmakla ilgili değildir. Önemli olan, doğru hataları, doğru aşamada, kullanıcı şikayetlerine, satış kaybına ve güvenin zedelenmesine dönüşmeden önce bulmaktır. Test zayıf olduğunda maliyet katmanlar halinde artar. Ödeme akışındaki bir hata, satın alma işlemini engelleyebilir. Bozuk bir form, potansiyel müşterilerin ekibinize ulaşmasını engelleyebilir. Küçük bir mobil düzen sorunu, kullanıcıları tek bir satırı bile okumadan uzaklaştırabilir. Bunun, bir tarayıcıda çalışıp diğerinde başarısız olan bir ödeme sayfasında gerçekleştiğini gördüm. Ekip sayfanın hazır olduğunu düşünüyordu. Test cihazı ana yolu kontrol etti, bir kez tıkladı ve oturumu kapattı. Lansmanın ardından ortak bir tarayıcıyı kullanan kullanıcılar ödemeyi tamamlayamadı. Düzeltmenin kendisi basitti. Gecikme, destek yükü ve kaybedilen siparişler hiç de basit değildi. Asıl sorun budur. Kötü testçiler her zaman yüksek sesle başarısız olmazlar. Daha sonra paraya mal olan sessiz sorunları özlüyorlar. Testlere iş korumasının bir parçası olarak bakıyorum. Güçlü bir test uzmanı, riski üç şekilde azaltmama yardımcı olur. Mutlu yolun ötesini düşünüyorlar. Pek çok zayıf test uzmanı yalnızca neyin çalışması gerektiğini test eder. İyi test uzmanları, bozulabilecek olanı dener. Tek girdiler kullanırlar. Sayfaları yeniliyorlar. Cihazları değiştiriyorlar. Ağ hızını değiştirirler. "Ya kullanıcı bunun yerine bunu yaparsa?" diye soruyorlar. Açıkça rapor veriyorlar. Bir hata raporu geliştiricinin hızlı hareket etmesine yardımcı olacaktır. Adımlar belirsizse ekip sorunu tekrarlamaya çalışarak zaman kaybeder. Beklenen sonuç eksikse düzeltme yavaşlar. Notları temizleyin, saatlerce tasarruf edin. Kullanıcı deneyimini önemsiyorlar. Bir ürün temel bir kontrolü geçse bile kullanımı kötü hissettirebilir. Düğmelere basmak zor olabilir. Hata mesajları insanların kafasını karıştırabilir. Bir form çok fazla şey isteyebilir. İyi test uzmanları bu noktaları fark eder çünkü bunlar dönüşümü ve elde tutmayı etkiler. Bir test uzmanının projeye yardımcı olup olmadığına karar vermek için basit bir yol kullanırım. Sorunu yeniden oluşturabilecekler mi diye soruyorum. Etkiyi açıklayıp açıklayamayacaklarını soruyorum. Tam adımları gösterip gösteremeyeceklerini soruyorum. Sadece tek hataları değil kalıpları fark edip etmediklerini soruyorum. Bu alanlarda yanıt zayıfsa ekibin daha sonra ödeme yapabileceğini biliyorum. Güçlü bir test süreci aynı zamanda gizli atıklardan kaçınmama da yardımcı oluyor. Hatalar üretime girdiğinde mühendisler planlı çalışmayı durdurur ve hasar kontrolüne geçer. Tasarımcıların ekranları yeniden ayarlaması gerekebilir. Destek ekipleri sinirli kullanıcılara yanıt verir. Yöneticiler aynı konuyu farklı kanallarda inceleyerek zaman kaybediyorlar. Gözden kaçırılan bir kusur, birçok kişiyi yararlı işlerden uzaklaştırabilir. Bu nedenle testleri yalnızca maaş veya sözleşme maliyetine göre değerlendirmiyorum. Bunu kaçırılanların maliyetine göre değerlendiriyorum. Daha iyi sonuçlar istiyorsam birkaç pratik adımı takip ediyorum. Test başlamadan önce ürün akışını tanımlarım. Çalışması gereken temel kullanıcı eylemlerini listeliyorum. Kritik yolları daha az acil olanlardan ayırıyorum. Cihaz, tarayıcı ve kullanıcı türü ayrıntılarını paylaşıyorum. Bu, testçiye net bir hedef verir. Ayrıca gerçek kullanıma uygun test senaryoları da istiyorum. Giriş testi yalnızca "kullanıcı adını ve şifreyi girin" değildir. Ayrıca boş alanları, yanlış şifreleri, şifre sıfırlamayı, kopyalama ve yapıştırma davranışını ve hesap kilitleme kurallarını da kapsar. Bu daha geniş bakış açısı sorunları erkenden yakalar. Hata raporlarını kısa ve faydalı tutuyorum. İyi bir raporda adımlar, sonuç, beklenen davranış, gerekiyorsa ekran görüntüleri ve ortam ayrıntıları bulunur. Bu format ekibin daha hızlı hareket etmesine yardımcı olur. “Başarısız oldu”yu yeterli bulmuyorum. Sorunu tekrarlamak için kanıta, bağlama ve yola ihtiyacım var. Ayrıca uç durumlarda test uzmanının nasıl düşündüğünü de gözden geçiriyorum. Yavaş interneti test ediyorlar mı? Eski verileri kontrol ediyorlar mı? Gerçek müşteri davranışlarını mı kullanıyorlar, yoksa yalnızca düzenli test verilerini mi kullanıyorlar? Sürüm incelemesi onları bulmadan önce sorunları buluyorlar mı? Bu sorular bana bir araç listesinin anlatabileceğinden daha fazlasını anlatıyor. Pratik bir örnek aklımda kalıyor. Birlikte çalıştığım bir ekip, masaüstünde iyi görünen bir kayıt sayfası başlattı. Test cihazı bir ekran boyutu ve bir tarayıcı kullandı. Daha küçük telefonlarda gönder düğmesi ekranın altına düşüyordu ve form hata mesajı şifre alanını kaplıyordu. Yeni kullanıcılar vazgeçti. Ekip ürünün tamamını kaybetmedi. Tam da güvenin başlaması gereken noktada güvenlerini kaybettiler. Bu nedenle test uzmanlarına yalnızca teknik desteğin değil, gelir korumanın bir parçası olarak davranıyorum. Test uzmanı zayıf olduğunda maliyet QA'da kalmaz. Destek, mühendislik, pazarlama ve kullanıcı davranışına yayılır. Bir testçi güçlü olduğunda ekip daha sakin bir şekilde yola çıkar. İnsanlar önlenebilir sorunları çözmek için daha az zaman harcıyorlar. Kullanıcılar daha az sürprizle karşılaşır. Ürün daha istikrarlı bir his veriyor ve iş günü daha az kaotik oluyor. Ben bu dengeye önem veriyorum. Yalnızca kontrol listesini değil, gerçek kullanıcıyı da gören testler istiyorum. Ekibin hızlı hareket etmesine yardımcı olacak raporlar istiyorum. Lansmandan sonra daha az sürpriz istiyorum. Bu, birçok ekibin yalnızca test uzmanının maliyetine baktığında gözden kaçırdığı kısımdır. Gerçek maliyet, işe aldığınız kişi değildir. Gerçek maliyet, yakalayamadığınız sorunlardır.

Takımlar arasında basit bir modelin tekrarlandığını gördüm. Bir şirket testlere küçük bir bütçe ayırmaya çalışıyor. Sürüm, zayıf kontroller, özensiz hata raporları ve zayıf takip ile yayınlanıyor. Daha sonra gizli maliyet artmaya başlar. Bozuk bir ödeme sayfası siparişleri kaybeder. Mobil form bir tarayıcıda başarısız oluyor ve kullanıcılar ayrılıyor. Küçük bir etiket hatası destek biletleri oluşturur. Kaçırılan bir son durum, para iadesine, şikayete ve yeniden inşası haftalar süren zarar görmüş bir güvene dönüşür. Kötü testçilerin yalnızca küçük gecikmelere neden olduğunu düşünürdüm. Şimdilik bunu öyle görmüyorum. Kötü bir test uzmanı hataları kaçırmaktan daha fazlasını yapar. Kötü bir test uzmanı tüm ekibi yavaşlatabilir, geliştiricilerin kafasını karıştırabilir ve bir ürünün gerçekte olduğundan daha az güvenilir görünmesine neden olabilir. Bunun gerçek işte gerçekleştiğini gördüm. Birlikte çalıştığım bir ekibin ana test yolunda iyi görünen bir ödeme akışı vardı. Testi yapan kişi mutlu yolu kontrol etti, imzaladı ve yoluna devam etti. Hiç kimse kargo değişikliği olan bir kupon kodunu denemedi. Bu küçük fark, sürekli alıcılardan oluşan bir grup için ödemelerin başarısız olmasına yol açtı. Düzeltmenin kendisi zor değildi. Maliyet, kaybedilen siparişlerden, öfkeli e-postalardan ve ekstra destek saatlerinden kaynaklandı. Pek çok takımın kaçırdığı kısım bu. Testçinin maaşını görüyorlar. Kaçan böceğin maliyetini göremiyorlar. Bence asıl sorun zayıf alışkanlıklarda başlıyor. Zayıf bir test uzmanı genellikle yalnızca kolay olanı kontrol eder. Zayıf bir test uzmanı uç durumları atlayabilir. Zayıf bir test uzmanı, adımların, cihaz ayrıntılarının veya açık kanıtların bulunmadığı raporlar yazabilir. Zayıf bir test uzmanı, görevi tamamlandı olarak işaretlemek istediği için sürümü aceleyle hazırlayabilir. Bu tür işler sahte bir güvenlik duygusu veriyor. Ürün test edilmiş görünüyor. Kullanıcılar boşlukları bulur. Test çalışmasını gözden geçirdiğimde birkaç işaret ararım. Net adımlar görmek istiyorum. Tam cihaz ve tarayıcı ayrıntılarını görmek istiyorum. Hata görsel olduğunda ekran görüntüleri veya kısa klipler görmek istiyorum. Neyin değiştiğini, neyin bozulduğunu ve nasıl bir sonuç gördüğümü açıklayan kısa bir not görmek istiyorum. Bu parçalar eksik olduğunda ekibin tahminde bulunmak için fazladan zaman harcayacağını biliyorum. Tahmin etmek pahalıdır. Bir geliştirici, iki satırda yazılması gereken bir hatayı yeniden oluşturmaya çalışarak yarım gününü harcayabilir. Bir yönetici bir toplantıyı neyin yanlış gittiğini sorarak geçirebilir. Bir destek temsilcisi aynı şikayete yanıt vermek için saatler harcayabilir. Güçlü bir test uzmanının koddan daha fazlasını koruduğunu öğrendim. Güçlü bir testçi zamanı korur. Güçlü bir test cihazı odağı korur. Güçlü bir test uzmanı güveni korur. Gizli kaybı önlemek istediğimde test işini şu şekilde ele alıyorum. Kullanıcı yolu ile başlıyorum. Kendime kullanıcının gerçekte ne yapmak istediğini soruyorum. Kullanıcı satın almak isterse aramayı, sepeti, kuponu, ödemeyi ve onayı test ederim. Kullanıcı kaydolmak isterse formu, şifre kurallarını, e-posta kontrolünü ve hata mesajı akışını test ediyorum. Kullanıcı bir dosya yüklemek isterse dosya boyutunu, dosya türünü, yavaş ağı ve işlemleri iptal etmeyi test ediyorum. Kolay yolda durmam. Ayrıca garip yolu da denedim. Kötü ağ. Yanlış giriş. Boş alan. Çift tıklayın. Geri düğmesi. Yenile. Bu küçük kontroller, aceleye getirilmiş testlerden kaçan birçok hatayı yakalar. Ayrıca test notlarını basit tutuyorum. İyi bir notun süslü bir dile ihtiyacı yoktur. Gerçeklere ihtiyacı var. Neye tıkladım. Ne bekliyordum. Ne gördüm? Hangi cihazı kullandım. Hangi yapıyı test ettim? Bu tür bir not herkes için zaman kazandırır. Geliştiricinin sorunu tahminde bulunmadan yeniden oluşturmasına olanak tanır. Yöneticinin uzun bir arama yapmadan riski görmesini sağlar. Daha sonra aynı sorun tekrarlandığında temiz bir kayıt tutmamı sağlıyor. Ayrıca ekiplerin "bitmiş"in ne anlama geldiği konusunda net bir standarda ihtiyacı olduğunu düşünüyorum. Bir testçi kısa bir geçişten sonra bir özelliği geçerse, ekip kendini çok erken güvende hissedebilir. Kontrol listesi yalnızca ana akışı kapsıyorsa salınım yine de risk taşıyabilir. Dikkatsizce yapılan uzun bir liste yerine, iyi bir şekilde yapılan daha az sayıda kontrolü tercih ederim. Pek çok takımın sıkışıp kaldığı nokta burası. Hızlı tahliye istiyorlar. Düşük maliyet istiyorlar. Kötü testlerin küçük bir tasarrufu büyük bir kayba dönüştürebileceğini unutuyorlar. Basit bir hatanın bir aylık test çalışmasından daha pahalıya mal olduğunu gördüm. Zayıf bir test raporunun tüm sprinti yavaşlattığını gördüm. Gözden kaçan bir sorunun, hiçbir yamanın aynı anda düzeltemeyeceği şekilde kullanıcının güvenini zedelediğini gördüm. Yani benim görüşüm doğrudan. Test kullanıcılarına işaretlenecek bir kutu gibi davranmayın. Testi, risk almadan sıkıştırabileceğiniz ucuz bir adım olarak görmeyin. Uç vakaları arayan test uzmanlarını seçin. Net raporlar yazan test uzmanlarını seçin. Yalnızca görev listesini değil, kullanıcı yolunu önemseyen test uzmanlarını seçin. Bu seçim paradan çok tasarruf sağlar. Zamandan tasarruf sağlar. Takımın enerjisinden tasarruf sağlar. Ürünü piyasaya sürüldükten sonra büyüyen sessiz hasarlardan korur. Basit bir nedenden dolayı iyi test uzmanlarına saygı duymaya başladım. Küçük şeyler büyük kayıplara dönüşmeden önce küçük şeyleri yakalarlar.

Bir test cihazının düşük fiyatının akıllıca bir satın alma olduğunu düşünürdüm. Numara dostça görünüyordu ve satın alma işleminin onaylanması kolaydı. Sonra bu seçimin diğer tarafını gördüm. Test cihazının karışık sonuçlar vermesi nedeniyle bir hat durduruldu. Geçmesi gereken kısımlar geride tutuldu. Başarısız olması gereken parçalar ileri doğru hareket etti. Ekip onları tekrar kontrol etti, destek istedi ve üretim dururken bekledi. Test cihazı faturada pahalı görünmüyordu. Yerde pahalı hale geldi. Birçok insanın kaçırdığı kısım bu. Ucuz bir test cihazı, hızla büyüyen küçük hatalar yaratabilir. Kötü bir okuma, bir kontrole daha yol açar. Bir kontrol daha vardiyayı yavaşlatır. Yavaş vardiyalar, üretimin kaçırılmasına, emeğin israfına ve hattın yakınındaki herkes için daha fazla strese neden olur. Testçilere farklı bir şekilde bakmayı öğrendim. Artık sadece “Ne kadara mal oluyor?” diye sormuyorum. “Bu araç her gün kullanıldığında bana ne kadara mal olacak?” diye soruyorum. İşin kendisinden başlıyorum. Bir test uzmanının ürüne, test noktasına ve işin hızına uyması gerekir. Ekipman görev için çok basitse ekibim bunun üzerinde çalışarak zaman harcıyor. Ekipman takım için fazla karmaşıksa hatalar hızla ortaya çıkar. Katalogda güzel görünen bir kurulumu değil, gerçek kullanıma uygun bir kurulumu tercih ediyorum. Tekrarlanabilirliğe de bakıyorum. Aynı parça tekrar kontrol edildiğinde test cihazının aynı sonucu vermesi gerekir. Eğer bir ekip sabah geçip öğleden sonra açık bir neden olmadan başarısız olursa, bu karışıklığın bedelini hattın ödeyeceğini biliyorum. İstikrarlı sonuçlar, düşük giriş fiyatından daha önemlidir. Fikstür kalitesi de önemlidir. Ucuz bir fikstürün tekrar tekrar kullanıldıktan sonra gevşediğini gördüm. Bu gerçekleştiğinde okumalar değişir ve operatör aletten şüphe etmeye başlar. Şüphe işi yavaşlatır. Güven bunu hızlandırır. Sağlam bir donanıma ve daha az sürprize sahip bir test cihazı seçmeyi tercih ederim. Destek, erken kontrol ettiğim başka bir nokta. Bir test cihazı çalışmayı bıraktığında yardım için uzun süre beklemek istemiyorum. Açık kurulum kılavuzu, bulunması kolay yedek parçalar ve aynı gün yanıt veren bir servis iletişim kişisi istiyorum. Zayıf desteğe sahip düşük maliyetli bir birim, takımı en kötü anda sıkışıp bırakabilir. Kalibrasyon ve eğitim de önemlidir. Bir test cihazının düzenli kalibrasyona ihtiyacı varsa, bu maliyeti en baştan planlıyorum. Personelin eğitime ihtiyacı varsa bunu da uygulamaya dahil ediyorum. Ekiplerin ekipman satın aldığını ve insani tarafı unuttuğunu gördüm. Sonuç daha fazla hata, daha fazla çağrı ve daha fazla kesintidir. Küçük bir örnek aklımda kaldı. Birlikte çalıştığım bir paketleme tesisi, her partiyi basit bir şekilde kontrol etmek için düşük fiyatlı bir test cihazı satın aldı. Ünite kısa bir süre iyi çalıştı, ardından okumalar kaymaya başladı. Operatörler kendilerini güvende hissetmek için testleri tekrarlamaya başladı. Hat her geçen gün hız kaybediyordu. Daha iyi desteğe sahip, daha istikrarlı bir birime geçişin ardından ekip, yeniden kontrol etmeye daha az, ürünü taşımaya daha fazla zaman harcadı. Yeni test cihazının maliyeti başlangıçta daha yüksekti ancak sürecin yürütülmesi daha kolay hale geldi. Benim kuralım basit. Bir test cihazını yalnızca satın alma fiyatına göre değerlendirmiyorum. Bunu stabilite, uyum, destek ve hat meşgul olduğunda tasarruf ettiği zamana göre değerlendiriyorum. Ucuz bir test cihazı bir anlaşma gibi görünebilir. Gecikmelere, ekstra kontrollere ve tekrarlanan çalışmalara neden oluyorsa sürecin maliyetli bir parçası haline gelir.

Ekiplerin aynı test çalışması için iki kez ödeme yaptığını gördüm. Ucuz bir test uzmanı tutuyorlar, oran konusunda iyi hissediyorlar ve lansmandan sonra hatalarla karşılaşıyorlar. Ürün ekibi düzeltmeler için fazladan saatler harcıyor. Destek daha fazla bilet alır. Kullanıcılar güvenini kaybeder. “Düşük fiyat” pahalı görünmeye başlar. İnsanların görmesini istediğim kısım bu. Test kullanıcısı yalnızca bir sayfayı tıklayan kişi değildir. Kullanıcı gibi düşünebilen, zayıf noktaları tespit edebilen ve sorunları sade kelimelerle anlatabilen birini arıyorum. Raporun belirsiz olması durumunda ekip zaman kaybeder. Test, ortak kullanıcı yollarını kaçırırsa ürün yine de en çok zarar verdiği yerden bozulur. Sadece faturadaki maliyeti değil, işe alım kararı sonrasındaki maliyeti önemsiyorum. Testçileri incelerken birkaç şeye bakarım. 1. Örnek hata raporları Geçmiş çalışmaların gerçek bir örneğini rica ediyorum. Yararlı bir rapor bana neyin bozulduğunu, nerede bozulduğunu, hangi cihazın veya tarayıcının kullanıldığını ve soruna hangi adımların yol açtığını söyler. Zayıf bir rapor yalnızca "İşe yaramıyor" diyor. Bu küçük boşluk önemlidir. Rapor net olduğunda mühendisler sorunu daha hızlı çözebilir. Rapor zayıf olduğunda tahmin etmeye zaman harcarlar. 2. Test düşüncesi İyi sorular soran bir testçi istiyorum. Kullanıcı yanlış kodu girerse ne olur? Sayfa yavaş yüklenirse ne olur? Sipariş küçük ekranlı bir telefondan verilirse ne olur? Bu sorular tasarruf etmenizi sağlar. Satış ekiplerinin ve destek ekiplerinin daha sonra uğraşmak istemeyeceği türden hataları yakalarlar. 3. Ürün uyumu Basit bir açılış sayfasında iyi çalışan bir test kullanıcısı, ödeme akışı, mobil uygulama veya büyük bir SaaS ürünü için doğru seçim olmayabilir. Bir keresinde küçük bir çevrimiçi mağazanın ödeme testi için düşük maliyetli bir test uzmanı kiraladığını gördüm. Testi yapan kişi akışı iki kez test etti ve sürecin iyi göründüğünü söyledi. Lansmandan bir hafta sonra kullanıcılar, bir mobil tarayıcıda indirim kodunun başarısız olduğunu fark etti. Ekibin şikayetleri yanıtlaması, geri ödemeleri işleme alması ve baskı altında olan sorunu düzeltmesi gerekiyordu. İkinci bir test uzmanı başka bir projede de aynı türden bir sorun buldu. Bu sefer tarayıcı türünü, cihaz boyutunu ve kupon mantığını birlikte kontrol etti. Hatayı müşterilerden önce buldu. Ekip saatlerce süren temizlikten tasarruf etti. Dikkat ettiğim fark bu. 4. İletişim tarzı Bir test uzmanı bir hata bulabilir ve mesajın okunması zorsa yine de zaman kaybedebilir. Kısa, net ve faydalı notlara ihtiyacım var. Takip edebileceğim adımlara ihtiyacım var. Sorunun açıklanması zor olduğunda ekran görüntüsüne veya ekran kaydına ihtiyacım var. Ayrıca bana sorunun ne kadar ciddi olduğunu dramatik bir şekilde değil, faydalı bir şekilde anlatacak bir test uzmanı istiyorum. Ödeme başarısız olursa bu, alt bilgideki yazım hatasıyla aynı şey değildir. Daha güçlü testçi aradaki farkı bilir. 5. Deneme çalışması Kısa süreli ücretli denemeyi severim. Küçük bir görev veriyorum ve sonucunu izliyorum. Testi yapan kişinin basit vakaları, uç vakaları ve nihai raporu nasıl ele aldığını görüyorum. Ayrıca kişinin ne kadar hızlı yanıt verdiğini ve ayrıntıların ürünle ne kadar uyumlu olduğunu da görüyorum. Kısa bir deneme bana uzun bir profil sayfasından daha fazlasını anlatır. Bu yaklaşımı kullanıyorum çünkü düşük kaliteli testler ucuz kalmıyor. Genellikle üç ekstra maliyet yaratır. İlk maliyet yeniden çalışmadır. İkinci maliyet ise kaybedilen zamandır. Üçüncü maliyet ise kullanıcı hayal kırıklığıdır. Bu maliyetler her zaman ilk günde görülmez. Serbest bırakıldıktan sonra, ekip yorulduğunda ve ürün zaten müşterilerin önüne geldiğinde ortaya çıkarlar. Özen, net düşünme ve sağlam alışkanlıklara para ödemeyi tercih ederim. Gösterişli sözlere ihtiyacım yok. Kullanıcıların gerçekte izlediği yolu kontrol edecek bir test cihazına ihtiyacım var. Küçük bir kırılmanın büyük bir soruna dönüştüğünü fark edecek birine ihtiyacım var. Ben böyle görüyorum. Dikkatli bir test cihazına biraz daha fazla harcarsam, daha sonra hataları düzeltmek için genellikle daha az harcarım. Yalnızca fiyata göre seçim yaparsam ilk faturada tasarruf edip lansmandan sonra daha fazlasını kaybedebilirim. Hataların bedelini tekrar tekrar ödemek yerine kaliteye şimdi ödeme yapmayı tercih ederim.

Bu sorunu birçok kez gördüm: Bir ekip bir ürünü hızlı bir şekilde gönderiyor, ardından özelliği geliştirmek için harcadığından çok daha fazlasını hataları düzeltmeye harcıyor. Zayıf bir test uzmanı yalnızca hataları kaçırmaz. Zayıf bir test uzmanı, ekstra destek bildirimlerine, daha fazla yeniden işleme, öfkeli kullanıcılara ve güven kaybına neden olur. Bir zamanlar uygun test kapsamı olmadan bir ödeme sayfası başlatan bir ekiple çalışmıştım. Kart formu masaüstünde iyi görünüyordu, ancak ortak bir mobil tarayıcıda bozuldu. Sorun, ekibin hızlı dahili kontrolünde ortaya çıkmadı. Kullanıcılar ödemeyi denedi, başarısız oldu, tekrar denedi ve bazıları ayrıldı. Düzeltmenin kendisi basitti. Çevresindeki maliyet değildi. Ekibin hatayı düzeltmesi, müşteri e-postalarını yanıtlaması, günlükleri incelemesi ve sorunu satış ekibine açıklaması gerekiyordu. Bu yüzden iyi test uzmanlarının paradan tasarruf ettiğini, kötü testçilerin ise parayı hızla tükettiğini söylüyorum. İyi bir test uzmanına, aynı anda hem kullanıcı hem de dedektif gibi düşünen biri olarak bakıyorum. Sadece düğmelere tıklamıyorlar. Neyin ters gidebileceğini, kullanıcının kafasının nerede karışabileceğini, gerçek bir müşterinin baskı altında hangi yolu seçeceğini sorarlar. Güçlü bir test uzmanı, ekiplerin sıklıkla gözden kaçırdığı ayrıntıları fark eder: - Kötü verileri kabul eden bir kayıt formu - Bir tarayıcıda başarısız olan bir ödeme sayfası - Bir anahtar düğmesini gizleyen bir mobil düzen - Aşamalandırmada çalışan ancak küçük bir veri değişikliğinden sonra bozulan bir oturum açma akışı - Kullanıcıya yararlı hiçbir şey söylemeyen bir hata mesajı Bunlar küçük sorunlar değildir. Bunlar maliyet noktalarıdır. Bir test sürecini gözden geçirdiğimde kullanıcı yolculuğuyla başlarım. Basit bir soru soruyorum: Para nereye hareket eder, güven nerede oluşur ve hayal kırıklığı nerede başlayabilir? Bu, en önemli yollara odaklandığım anlamına geliyor: - Kayıt ol - Giriş yap - Arama - Sepet - Ödeme - Hesap kurtarma - Destek ekibiyle iletişime geç Bu akışlar bozulursa, işletme bunu hemen hisseder. İyi bir test uzmanı, bu yolları lansmandan önce korur ve piyasaya sürüldükten sonra da izlemeye devam eder. Testlerin nasıl yazıldığına da dikkat ediyorum. Bazı ekipler, eksiksiz gibi görünen ancak gerçek riski gözden kaçıran uzun bir vaka listesine güveniyor. Paranın uçup gittiği yer orası. Daha iyi bir yaklaşım, yüksek riskli eylemleri net adımlarla ve net beklenen sonuçlarla test etmektir. Basit bir modeli seviyorum: 1. Ana kullanıcı yolunu tanımlayın 2. Başarısız olabilecek eylemleri listeleyin 3. Normal kullanımı test edin 4. Garip girişi test edin 5. Müşterilerin en çok kullandığı aygıtlarda ve tarayıcılarda test edin 6. Her düzeltmeden sonra yeniden test edin Bu basit gibi görünüyor. Çalışıyor çünkü ekibi gerçek kullanıma yakın tutuyor. Ayrıca test uzmanlarının hataları nasıl rapor ettiğini de izliyorum. Zayıf bir rapor ileri geri hareket yaratır. Güçlü bir rapor saatler kazandırır. Yararlı bir hata raporu şunları içerir: - Ne yaptım - Ne bekledim - Ne oldu - Hangi cihazı veya tarayıcıyı kullandım - Sorunu yeniden oluşturmaya yardımcı olacak adımlar - Gerektiğinde ekran görüntüsü veya kısa video Sade bir dil tercih ederim. Bir geliştiricinin ne demek istediğimi tahmin etmesine gerek yok. Örneğin "sayfa bozuk" demek yerine şunu yazardım: "iPhone Safari'de ödeme sayfasını açtım, geçerli bir kart girdim, Öde'ye dokundum ve düğme yanıt vermedi. Sayfa aynı ekranda kaldı. Adımı üç kez tekrarladım." Bu tür bir not takımın hızlı hareket etmesine yardımcı olur. İyi test uzmanları aynı zamanda ne zaman çaba harcamamaları gerektiğini de bilirler. Ekiplerin bozuk bir geri ödeme akışını kaçırırken küçük ekran sorunlarına saatler harcadığını gördüm. Bu, zamanın kötü kullanılmasıdır. İyi test, her şeyi eşit ağırlıkla test etmek anlamına gelmez. Risk taşıyan şeylerin test edilmesiyle ilgilidir. Ekiplere üç maliyet alanına bakmalarını söylüyorum: - Düzeltme maliyeti - Destek maliyeti - İtibar maliyeti Geç bulunan bir hatanın düzeltilmesi daha fazla maliyete neden olur. Kullanıcılar tarafından bulunan bir hata, destek çalışması oluşturur. Güveni etkileyen bir hata, düzeltme yayınlandıktan sonra da markaya zarar vermeye devam edebilir. Küçük bir örnek bunu açıkça ortaya koyuyor. Bir yemek dağıtım uygulamasında bir zamanlar zamanlayıcı hatası vardı. Kullanıcılar sipariş verebilir ancak tahmini teslimat süresi, bir bölge ayarında yanlış saati gösteriyordu. Uygulama hâlâ çalışıyordu ancak müşteriler hizmetin yavaş olduğunu düşünüyordu. Bazıları iptal edildi. Destek aynı soruyu tekrar tekrar yanıtlamak zorunda kaldı. Sorun dramatik değildi. Hala paraya mal oldu. Sürekli gördüğüm model bu. Test zayıf olduğunda küçük boşluklar büyük masraflara dönüşür. Benim görüşüm basit: İyi test yapmak bir iş alışkanlığıdır, lüks değil. Geliri korur, ekip içindeki stresi azaltır ve kullanıcılara daha sorunsuz bir yol sunar. Kötü testler başlangıçta daha ucuz görünür. Daha sonra tahmin edilmesi zor şekillerde pahalı hale gelir. Daha iyi sonuçlar istiyorsam daha fazla gürültü istemiyorum. Daha iyi odaklanma, daha net raporlar ve gerçek müşteri davranışlarıyla eşleşen testler istiyorum. Kaliteye para harcamak ile hataların bedelini sonradan ödemek arasındaki fark budur. Sektör trendleri ve çözümleri hakkında daha fazla bilgi edinmek ister misiniz? Fei Zhigang'a ulaşın: 13506728162@139.com/WhatsApp +8613506728162.

Boris Beizer 1995 Yazılım Test Teknikleri Cem Kaner 2002 Yazılım Testinde Öğrenilen Dersler Lisa Crispin ve Janet Gregory 2009 Çevik Test Michael Bolton 2015 Hızlı Yazılım Testi James Bach 2018 Kötü Testin Maliyeti Elisabeth Hendrickson 2020 Keşfedin Keşif Testiyle Riski Azaltın ve Güveni Artırın