Ürün yönetimi, senaryodan oyuna dönüşmesiyle, ekip yönetimi ve uzun hazırlık süreciyle sahneye oyun koymaya bir hayli benziyor. Ürün yöneticisi ise yazarın seyircide yaşatmak istediği duyguları sahnede oyuncular aracılığıyla vermek için çabalayan yönetmene… Benzer şekilde sahneye çıkmadan önce aylar alan provaların ürün yönetiminde karşılığı ise çeşitli testler oluyor. Peki ürün yöneticisinin bu testlerde rolü, payı ne kadar? Hatta daha net şekilde soracak olursak, ürün yöneticisinin test yapma gibi bir ödevi var mı?

‍

Ürün Yönetimi Boyunca Başvurulan Testler ve Sürece Sağladıkları

Ürün yönetimi yaşam döngüsünü zaman zaman lineer kabul etsek de, aslında farklı departmanlara bölünerek devam etmesi, departmanlar arası görev teslimi ve hem ileri hem geri ritimlerle çok yönlü bir süreçtir. Elbette burada insan hatası, hedef-çıktı uyumsuzluğu, trendlerde ve planlarda değişimler ve geri bildirimler ile daha iyisine erişme başta olmak üzere süreci çetrefilli hale getiren elementler mevcut. İşte ürün yönetimi bu anlarda kompleks hale gelirken düğümü çözecek olan araç ise çeşitli testler oluyor. Özellikle de  doğrulanabilir, hesap verilebilir, dataya dayalı bir sürecin sorumlusu olmak için Product Manager, elinde test sonuçlarını görmek ister.

‍

Peki Product Manager, bu testleri yürütmekle de sorumlu mudur?

Aslında ürüne dair testler kataloğuna dair göz attığınız noktada karşılaştıklarımız ağırlıklı olarak geliştirme süreçlerine ait. Bu da, ürün yöneticisinin test yapma görevi konusunda herkesi biraz daha şüpheyle yaklaşır hale getiriyor. Ancak ürün yöneticisinin de canlıya çıkmadan önce yapmasının tavsiye edileceği bazı testler var.

‍

QA Testleri

QA (Kalite Güvencesi) testi, bir tiyatro oyununun provası sırasında sahne arkasında çalışan teknik ekibin, sahne dekorunun sağlamlığını, ışık ve ses sistemlerinin sorunsuzca çalıştığını kontrol etmesine benziyor. Nasıl teknik ekip, oyunun sorunsuz bir şekilde sahnelenmesini sağlamak için her detayı kontrol ederse, QA testçileri de bir ürünün hedeflenen kalite standartlarına uygun olup olmadığını veya herhangi bir hata veya aksaklık içermediğini kontrol etmekle sorumlular.

‍

Kullanıcı Kabul Testleri (User Acceptability Testing)

UAT (Kullanıcı Kabul Testi), bir tiyatro oyununun genel provasında, oyunun gerçek seyirciler tarafından izlenmesini ve değerlendirilmesini sağlar. Tıpkı seyircilerin oyunun akışını, temalarını ve genel etkisini değerlendirerek oyunun başarılı olup olmadığına karar vermesi gibi, UAT'de, gerçek kullanıcılar ürünün canlıdaki halini kullanarak, hedeflenen ihtiyaçları giderip gidermediğini ve beklentilerini karşılayıp karşılamadığını değerlendirirler.

‍

Manuel Testler

Seyirciler oyun için yerini almadan önce, oyuncuların sahne değil, koltukların arasında dolaştığı, ışığı ve sesi kontrol ettiği aşamaları düşünün. Bir oyuncunun sahneye seyirci gibi bakması gibi, ürün yöneticisi de ürüne kullanıcı gözüyle bakıyor. Bu testler, kullanıcının ürünü kullanması gibi manuel şekilde yapılıyor. Ürünün özellikle ne kadar kullanılabilir olduğunu denemek, kullanıcının karşılaşacağı hataları ilk elden bulmak için yürütülen bu testlere manuel testler diyoruz. Her ne kadar bu testler yerine otomatikleştirilmiş olanları olsa da, ürün yöneticisinin bunları yürütmesi de bir artı sağlayacaktır.

‍

Ürün Yönetimindeki Önemli Testler Sorumuzu Ne Kadar Yanıtlıyor?

Ürün yöneticisi hataları bulmak ve ortadan kaldırılmasını sağlamakla yükümlü; ancak bu testleri yürütmekle yükümlü mü? Burada bir ikileme düşüyoruz. Çünkü bir önceki bölümde önemli testlerin ürün yönetiminde hangi perdede rol aldığını işledik. Ancak daha önce de ele aldığımız gibi, farklı takımlar ve farklı sayıda profesyoneller de bu süreçte görevli. Bu noktada ürün yöneticisinden ziyade diğer uzmanlar gerekli testleri uygulama ve sonuçları çıkarmakla meşgul olabilirler. Örneğin, ürün geliştirme takımında QA uzmanları hataları yakalamakla ya da UI/UX tasarımcıları bazı A/B testleri uygulamakla ödevli olabilir. Yani ürün yöneticisi için test yürütmek bir zorunluluk değil elbette. Peki, testlerle uğraşmayı kendine rol biçmiş ürün yöneticileri var mı? Ne aşamada, ne amaçla testler yürütüyorlar?

‍

Berkay Vuran‍

Evet, bence ürün yöneticisi test yapar; ama neyi test ettiği önemli. Ürün yöneticisinin test yapma amacı, teknik doğrulamadan çok, ürünün kullanıcıya hitap edip etmediğini anlamaktır.

Bence bir ürün yöneticisinin yaptığı & yapabileceği testler:

Kullanıcı Kabul Testleri (UAT): Ürünün iş hedeflerine uygun olup olmadığını kontrol etmek için uygulanır.

A/B Testleri: Yeni özellikler veya değişikliklerin kullanıcıya nasıl yansıyacağını ölçmek için kullanılır.

Prototip Testleri: Erken aşamada kullanıcı geri bildirimi almak için kullanılır.

Beta Testleri: Gerçek kullanıcılarla son dokunuşları yapmak için uygulanır.

Kısacası, ben bir Product Manager olarak test yaparım ama teknik değil, kullanıcı odaklı olma amacıyla... Çünkü kullanıcının yaşayacağı deneyimi anlamak benim işim.

‍

Işık H. Kara

Ürün yöneticisiyken manuel testing yapıyordum. Ama yaptığım şeyleri son bir kontrol etmek gibi düşünebiliriz. Zaten bunun için ekipte QA uzmanı var. Design detaylarını da design uzmanı sizden iyi görüyor olacaktır zaten.

Yeni sürümde çıkacak özelliklerin doğru çalışıp çalışmadığının kontrolünü yapmak: Sürüm iOS ise kendi telefonumdan, Android ise verilen test telefonundan

Yeni sürümde çıkacak özelliklerin analitik kontrolünü yapmak: Kullandığımız product analytics tool’undan kendi kullanıcı/device id’mi bulup yeni/değişen event ve parametrelerin doğru gelip gelmediğini kontrol etmek. Buraya belki en kritik eventlerinizin üstünden geçmeyi de dahil edebilirsiniz.

Üstteki 2 madde üzerine yeni sürüm için dashboard hazırlamak: Yeni özellikler & analitikleri düşüyor mu, kaldırdığımız özelliklerin analitikleri düşüyor mu vs.

Ürün yöneticisiyken bu kadarı bana yeterli oldu; elbette durum üründen ürüne şirketten şirkete değişebilir. Adanmış bir QA çalışanı yoksa ürün yöneticisinin kolları sıvayıp bulabildiği türlü cihazda yeni özellikleri kontrol etmesi gerekebilir.

‍

Deniz Albayrak

Olay ilk bizden başlıyor şöyle ki; müşterinin isteğini anlayarak geliştirme yapılması için ekibe veriyorum.

Doğal olarak bu talep ne ölçüde, hangi kalitede karşılanmış test etmem gerekli. Mantığı anlamışlar mı diye fonksiyonu zaten test ediyorum, bunun yanında CX sağlanmış mı (domain için çok önemli) diye bakıyorum.

Bazen "hoyrat kodlama" (adını sanırım ben taktım) olabiliyor. Kullanılabilirlikle kullanışlılık karıştırılıyor, bunu ilk başta isterlere dahil ederek anlatıyorum ve sonrada üründe görmek istiyorum.

Domain tecrübem nedeniyle hızlıca Exploratory Test ve Regresyon testi yapıyorum.

Tool kullanılabilir, manuel yapılabilir, otomasyon yapılabilir bu kısım öznel; ne şekilde olursa olsun test yapılmalı.

‍

Utku Açıkgöz

Ürün yöneticisi test yapmak zorunda mıdır, değildir. Ürün yöneticisi test yapmalı mıdır, kesinlikle. Belirli bir hipotezle bir fikrin ortaya çıkmasını amaçladığımız için o hipotezin son kullanıcıya ulaşmadan görmenin birkaç faydası var:

-kalite kontrolden emin olmak,

-işi sonuna kadar takip etmek (ownership)

-işin nasıl gördüğünü kavradıktan sonra bir sonraki iterasyonları düşünmek

-her şeyi teorik olarak planlayıp tüm çözümleri baştan belirlediğimiz bir ideal dünya olmuyor. Dolayısıyla test ile aslındaki bir sonraki gelişmenin fikir aşamasını da başlatabiliyoruz.

2. Ben genelde sunumunu yapacağım işleri doğrudan test ediyorum. Eğer bir analytics tool veya benim uzmanlık alanım olan bir konu varsa onun da testini yapıyorum. Bir de mobil çalışıyorsam iki platformda da test edip deneyimi kontrol ediyorum.

3. Fonksiyonaliteden ziyade karşı tarafa (son kullanıcıya, tasarımcıya, yazılımcıya) fikir ne kadar geçmiş onu anlamaya çalışıyorum. Genel olarak teste bir code review gibi yaklaşıp verdiğim requirementler ne kadar gerçekleşmiş - fikren neleri farklı yapabiliriz onu görmek faydalı oluyor.

Bir diğer faydası da bir feature geliştirirken onun çok içinden baktığın için genel akışta nasıl durduğu gözden kaçabiliyor (user flow) - dolayısıyla app konusundaki akışları kontrol etme adına çok faydalı oluyor.

Bazı çok kritik özelliklerde doğrudan UAT gibi yaklaşıp deployment erteletme kararı aldığım olmuştur. Testi sevelim, test yapalım.

‍

Metin Akın

Bunun biraz kaynak meselesi olduğunu da düşünüyorum.

Start-up seviyesindeki bir şirkette çalışırken kaynaklar kısıtlı olunca, manuel de otomasyon testi (rainforestqa.com ile başladık, fatura şişince RobotFramework’e geçtik) de yapıyordum. Scale-up seviyesindeki şirketlerde zaten bu işe odaklanmış arkadaşlar var ve bizden daha iyi sorunları yakalıyorlar. Benim yapacağım test onlarınkinin yanında kumda oynamak gibi kalıyor.

Sonuç olarak, her iki durumda da happy path’lerin kritik cihazlarda/ortamlarda çalıştığını tespit etmek bizim görevimiz.

Günün sonunda müşteriye söz veren veya piyasadaki eksikliği doldurmaya söz veren sizsiniz. Siz söylediniz. İşi teslimden önce kontrol etmek de doğal olarak bir parçası.

Mecbur yapacağız, az ya da çok.

‍

Utku Şengün

Ürün yöneticisi test yapar lakin neyi test ettiği önemlidir. Çok teknik içeren test gerçekleştirmez lakin kullanıcı odaklı testleri yapması elzemdir. Kullanıcı odaklı testler ise detaylandırılabilir.

‍

Kubilay Arkan

CX'in tutarlı bir şekilde devam edebilmesi için UAT'lerin tamamının product manager tarafından yapılması gerektiğini düşünüyorum. Teknik tarafta ise, product managerın yetkinliğine ve QA ekibinin ürün sahipliğine bağlı olarak, her task için olmasa da ürünün genelini etkileyecek özelliklerin teknik testlerinde de product manager katkısı önemli.

Sağlıklı bir süreç için test edilecek tüm adımların, Jira Xray gibi toollar kullanılarak şeffaf şekilde yazılması, QA ve Product ekipleri test kapsamında anlaştıktan sonra ilerletilmesi de faydalı oluyor.

‍

Sezen Turan

Testten Product'a geçmiş biri olarak ilk zamanlar normalinden biraz fazla test yapardım, eski alışkanlıklar kolay kırılmıyor. Bence bir ürün yöneticisi ya da sahibi çok derine dalmadan (bu biraz test ekibinin varlığı, deneyimi ve otomasyon toolarının ne derece aktif olduğuna göre değişebilir) bir happy path testi yapmalı. Ürünün sahibi ya da yöneticisi olarak, kullanıcı ihtiyaçlarını analiz etmiş, stakeholderlarla saatlerce konuşmuş, tasarımlarıyla birebir ilgilenmiş kişiler bizleriz. Dolayısıyla üzerinde bu kadar emek verilen ürünü canlıya çıkmadan ilk elden deneyimlemek ve özümsemek gerektiğini düşünüyorum.Bağlayacak olursam evet, bence test yapmak zorunda değiliz ama doğru ölçüde yapmamızın zararı yok, aksine faydası olacaktır.

‍

Yapay Zekaya Sorduk: Product Manager Test Yapar mı?

Ürün yöneticileri (PM'ler), yazılım kalitesini sağlamak için manuel test yapma sorumluluğuna sahip olmamalıdır. Bu durum, PM'lerin temel görevlerinden uzaklaşmasına ve mühendislerin kalite için onlara bağımlı hale gelmesine yol açar. Manuel testin ölçeklenebilir olmaması, zamanla verimliliği azaltır ve otomatik test geçişini geciktirir. PM'lerin, manuel testin verimsizliğini ekiplerine göstermesi, yeni geliştirmeleri azaltarak otomatik test yeteneklerine odaklanması ve zamanlarını daha etkili alanlara yönlendirmesi önerilir. Manuel test süresi ve kapsamı net bir şekilde belirlenmeli, bu süreçte değişiklikler aşamalı olarak gerçekleştirilmelidir.

Ancak bazı durumlarda, PM'lerin manuel test yapması, yazılım mühendisleriyle daha iyi ilişkiler kurmalarına ve müşteri deneyimini derinlemesine anlamalarına yardımcı olabilir. Bu, PM'lerin teknik becerilerini geliştirmelerine ve ekip içinde daha fazla değer katmalarına olanak tanır. Bu nedenle, PM'lerin manuel test yapma sorumluluğunu tamamen reddetmek yerine, bu süreci dengelemeleri ve otomatik test süreçlerine geçiş yapmaları önemlidir.

‍

Ürün yönetimine dair daha da fazlasını öğrenmek, haberleri ve trendleri takip etmek için blog sayfamızı ziyaret edebilirsiniz. Bir sonraki içerikte görüşünceye değin, hoşça kalın!

‍