Ürün Testi (Crema’dan Erin Hess ile)

Michael Luchen

Ürün geliştirme hakkında konuşmaya çok zaman harcanıyor; peki ürünün test edilmesine ne demeli? Bir ürünün, geliştirildiği kullanıcıları desteklemesini sağlamak için kapsamlı biçimde test edilmesine hangi yaklaşımlar, tutumlar ve disiplinler katkıda bulunur? Bugünkü programımıza, test mühendisliği alanında uzman bir konuğu davet ettik. Bir ürün ekibindeki bu kritik rolün ne anlama geldiğini, test mühendislerinin ürün yöneticileriyle nasıl iş birliği yaptığını ve neden ürün ekibindeki önemli bir empati savunucusu olabileceklerini derinlemesine inceleyeceğiz. Bizi dinlemeye devam edin.

Bu, ürün yönetimi, geliştirme ve strateji için yol haritasını oluşturan topluluğun seslerini bir araya getiren The CPO Club podcast’i. Programın sponsoru, bireylerin ve şirketlerin yaratıcılık, teknoloji ve kültür yoluyla gelişmesine yardımcı olan dijital ürün ajansı Crema’dır. Daha fazla bilgi için crema.us adresini ziyaret edin. Ürün yönetimi dünyasında başarılı olmanıza yardımcı olacak pratik ve özgün içgörüler için dinlemeye devam edin.

Herkese merhaba. Bugün Erin Hess’i programımıza davet etmekten büyük heyecan duyuyorum. Erin kısa süre önce yeteneklerini Crema’daki ekibimize Kıdemli Test Mühendisi olarak kattığında kendisini tanıma fırsatı buldum. Erin, yazılım geliştirme ve mühendislik alanlarında birden fazla rolde 12 yılı aşkın deneyimle edindiği benzersiz yaratıcı ve teknik yeteneklere sahip.

Kariyerine müşteri destek temsilcisi olarak başladı; daha sonra kendi kendine kod yazmayı öğrenen ve yazılım test etmeye tutkuyla bağlanan bir geliştirici oldu. Özünde bir kullanıcı savunucusu olan Erin’in temel güçlü yönleri arasında empati, görselleştirme ve davranışları ve iletişimi öngörme yer alıyor. Erin süreç haritaları oluşturmayı ve sorun noktalarının nerelerde ortaya çıkabileceğini hayal etmeyi seviyor. Başkalarının yerine kendini koyarak, sorunlara birden fazla açıdan bakarak ve bugünkü eylemlerin uzun vadeli sonuçlarını ve faydalarını görerek katıldığı her ekipte ve üründe fark yaratmayı başardı.

Erin ayrıca kapsayıcı tasarım uygulamalarının benimsenmesine ve hayata geçirilmesine yardımcı oluyor; evrensel kullanılabilirliğin önündeki engeller hakkında farkındalık yaratıyor ve bu farkındalığı yayıyor. Erişilebilirliğin güçlü bir savunucusu olan Erin, sürekli büyüyen çevrim içi test topluluklarına kaynak materyaller sunmaya devam ediyor.

Merhaba Erin. Programa hoş geldin.

Erin Hess

Bu harika tanıtım için çok teşekkür ederim Michael. Burada olmaktan mutluyum.

Michael Luchen

Harika. Bu sohbet için kişisel olarak gerçekten heyecanlı olduğumu söylemeliyim. Test mühendisi ile ürün yöneticisi arasındaki iş birliği en iyi sonuçlardan bazılarını ortaya çıkarabilir; ancak bu konu aslında çok fazla konuşulmuyor.

Başlayalım mı?

Erin Hess

Kesinlikle.

Michael Luchen

Pekâlâ.

Ekibinde test mühendisi bulunmayan ve bu rolü anlamaya çalışan dinleyicilerimiz için konuyu biraz genel bir çerçevede ele alarak başlamak istiyorum. Test mühendisi olarak yapmayı en sevdiğin etkinliklerden bazılarını anlatabilir misin?

Erin Hess

Elbette. Çok fazla etkinlik var ve bu konu hakkında uzun uzun konuşabilirim. Test uzmanı olarak yapabileceğin o kadar çok şey var ki. Genel olarak en sevdiğim şeylerden biri ilişkiler kurmak ve birlikte çalıştığım ekipleri tanımak. Buna geliştirici, tasarımcı, ürün yöneticileri, diğer mühendisler, müşteri destek ekibi ve hatta bazen pazarlama ekibi de dâhil.

Örneğin farklı projelerde, bir iş birliği projesinde çalışırken müşteri tarafındaki kaynakları da tanımak. Ayrıca teknik dokümantasyon yazma konusunda kendime bir alan buldum. Bu nedenle doğru miktarda ayrıntı ve açıklama sunmak, bunu yararlı görsel yardımcılarla desteklemek için zaman ve alan bulmayı gerçekten önemsiyorum.

Bir bilgisayarın önünde oturan bir kedinin resmini ekleyerek yaratıcı olabiliyorsam bunu yaparım. Yeni araçlar öğrenmeyi ve diğer mühendislerle birlikte çalışmayı da seviyorum. Bunlar gerçekten dört gözle beklediğim şeyler.

Michael Luchen

Özellikle bir test mühendisinin sahip olması gereken bakış açısından, ekiplerinle ilişki kurmaya nasıl yaklaşıyorsun?

Erin Hess

Çok açık fikirliyim ve herkesin biraz farklı olduğunu biliyorum. Tasarımcıyla geliştiriciyle yaptığım konuşmanın aynısını yapmayacağım; ürün sahibi için de aynı durum geçerli. Bu nedenle çok açık fikirli olmaya ve ekip için mümkün olduğunca fazla alan ve empati sağlamaya çalışıyorum.

Michael Luchen

Herkesin farklı olduğu, kendi becerilerini ve disiplinlerini ürün ekibine getirdiği bir ortamda bu alanı ve empatiyi yaratmak arasındaki dengeyi nasıl buluyorsun?

Erin Hess:

Benim için bu disiplin sabırlı olmak ve pratik yapmaktı. Kendime ve ekibime, birbirimize nasıl davrandığımızı ve sprint boyunca nasıl ilerlediğimizi değerlendirdiğimiz retrospektifler sunuyorum. Sadece işin kendisi değil, insan olarak bizim için hangi şeylerin zor olduğunu da konuşuyoruz ve onların benimle bu tür konuşmaları yapabilmeleri için alan tanıyoruz.

Michael Luchen

Harika. Bir an için biraz genel düzeye çıkalım. Bir test mühendisi ürün ekibinde hangi tipik etkinlikleri gerçekleştirir? Bunun yalnızca ürünün yayımlanabileceğini söylemekten ibaret olmadığını biliyorum; bu bir şaka ama kesinlikle sadece bundan ibaret değil.

Erin Hess

Hayır, değil. Elimde geçer veya kalır damgası olan bir mühürle oturmuyorum. Teknik bir rol olmasına rağmen işin içinde tahmin edebileceğinden çok daha fazla ayrıntı ve ilişki kurma var. Ekibin farklı bölümleriyle çok fazla çalışmak ve iş birliği yapmak gerekiyor. Örneğin geliştiriciyle eşleşerek çekme istekleri oluşturma ve inceleme konusunda daha iyi hâle gelmek.

Ürün yöneticisiyle eşleşerek kabul kriterlerinde doğru ayrıntı düzeyini belirlemek ve kabul kriterlerinde nelerin bulunacağına ilişkin standardı ve beklentiyi oluşturmak.

Tüm kullanıcı hikâyeleri ve özellikler yalnızca tasarımcılar, geliştiriciler ve diğer ekip üyeleri tarafından değil, paydaşlar tarafından da incelenmeli. Test mühendisi olarak bunların tamamının bir parçasısın. Tüm bu kişilerle iletişim kurmalı ve süreci takip etmelisin; aksi hâlde bir şeyi kaçırır ve ürünün gereksinimleri karşılamama riskini artırırsın.

Michael Luchen

İlginç. Teknik dokümantasyonda kendine bir alan bulmandan bahsederken aslında tüm bu bağlamı bir araya getirmeyi kastettiğini düşünüyorum.

Erin Hess

Ben bunu ikinci beynim olarak da kullanıyorum. Her şeyi hatırlamamı beklemiyorum; ancak dokümantasyonumun oldukça iyi olduğunu biliyorum. Bu nedenle bir projede ihtiyaç duyduğumda ya da başka biri kullanmak istediğinde ona başvurabiliyorum.

Michael Luchen

İkinci beyin derken, tüm bu dokümantasyonu ürün ekibinin erişimine açık biçimde tuttuğunu görüyorum, doğru mu?

Erin Hess

Evet.

Michael Luchen

Bu gerçekten… özür dilerim, devam et.

Erin Hess

Sadece orada duruyor demek istiyordum. Gizlenmiş, kilitlenmiş veya tuhaf bir ödeme duvarının arkasına konmuş değil. Ekip kullanabilsin diye herkesin erişimine açık. Bir şey oluşturduğumda kesinlikle paylaşıyorum.

Michael Luchen

Bu gerçekten harika. Şeffaf dokümantasyonun, ürün ekiplerinin henüz uygulamıyorsa kendilerini gerçekleştirmeye zorlaması gereken bir şey olduğunu düşünüyorum. Bu yalnızca test mühendisliği için değil, ürün ekibini oluşturan tüm disiplinler için geçerli. Çünkü bununla birlikte bağlam ortaya çıkıyor ve rolünün gelişmesini sağlayan şey de iletişim kurduğun bağlamdır.

Test mühendisliği rolünde yeni olan ve ekibinde bir test mühendisiyle çalışma fırsatı bulmamış dinleyiciler için test mühendisi ürün ekibiyle ne zaman iş birliği yapmaya başlamalı? Ürün çalışması başladıktan sonra mı, sonlara doğru mu, yoksa başka bir zamanda mı?

Erin Hess

Zaman içinde şunu öğrendim: Test mühendisini ne kadar erken dâhil edersen o kadar iyi olur. Bazı şirketlerde test mühendisinin yalnızca bir görevi yerine getirmek, test yazmak ve geçip geçmediğini kontrol etmek için orada olduğu düşünülüyor. Ancak masaya yalnızca test becerilerinden fazlasını getirecek iyi test mühendislerini istiyorsan onları ön başlangıç toplantısına, bağlam haftasına dâhil etmelisin. Ne üzerinde çalışacaklarını görmelerini sağlarsan en başından itibaren pek çok şeyi hayal etmeye başlayabilirler.

Daha en başta, test edilebilirlik için tasarımları etkilemeye, geliştirmeyi yönlendirmeye ve erişilebilirlik testlerini sonradan akla gelen bir konu olmaktan çıkarmaya katkıda bulunabilirler.

Michael Luchen

Harika. Kesinlikle katılıyorum. Test mühendisi olmadan başlayan bir ekip gördüğümde bunun benim için büyük bir risk hâline geldiğini fark ettim. Farklı açılardan topladığın bağlam, kullanıcı ihtiyaçlarını karşılayan, kaliteli ve test edilmiş bir ürüne sahip olmamızı sağlamak açısından çok önemli. Bu, bazen elden ele dolaşan bir onay damgasından çok daha fazlası.

Peki test mühendisi olarak sprint sırasında akılda tutulması gereken şeyler neler?

Erin Hess

İyi soru. Bunun için birkaç önerim var. Öncelikle bilmediğin şeyleri bilemezsin; bu nedenle bir şüphen veya endişen olduğunda, ne kadar ciddi olduğunu düşünürsen düşün ekibine ulaşmaktan korkma. Küçük bir endişe zamanla önemli bir iyileştirmeye dönüşebilir. Ayrıca konuşmak, bir sorunun gözden kaçıp yayımlanması hâlinde onu düzeltmenin riskini ve maliyetini azaltır.

Ürün geliştirmede tek başına hareket etmek yoktur; takımda da tek başına bir kişi yoktur. Bunu kendi başına yapmıyorsun, ekibin bir parçasısın. Zorlandığını söylemediğinde ekibe fayda sağlayamazsın. Yapabileceğin en kötü şeylerden biri sprintin sonuna kadar bekleyip bir şeyi yapamadığını ekibine bildirmektir. Bu yüzden sesini çıkar.

Michael Luchen

Evet, bu çok önemli. Özellikle ürün yönetimi tarafından baktığımda, sprintte büyük riskler olup olmadığını erkenden belirlemeye yardımcı oluyor. Tam bir ürün ekibi olarak sprint başlattığımızda, karşılaşacağımız risklere ilişkin varsayımımız sınırlı oluyor. Ancak test mühendisi açısından sprintin başlarında işaretlenen bir şey, sprintin yönünü çok olumlu bir amaçla değiştirebilir.

Erin Hess

Evet.

Michael Luchen

Biraz disiplinler arası iş birliğine geçelim. Test mühendisleri, tasarımcılar ve geliştiriciler birlikte başarılı olabilmek için nasıl hazırlanmalı?

Erin Hess

Tasarım ve geliştirme ekiplerinin, mümkün olduğunda kullanıcı hikâyelerinin tasarımı ve geliştirilmesi sırasında test mühendisleriyle eşleşmesi kesinlikle faydalı olur.

Deneyimlerime dayanarak söyleyebilirim ki projenin erken aşamalarında tasarım ve geliştirme ekipleriyle eşleşme fırsatları var. Bu bana test senaryoları hazırlamak, test dosyaları oluşturmak ve otomasyon betikleri yazmak için daha fazla bilgi sağlıyor. Şu anda kabul kriterlerimizi ve gereksinimlerimizi Gherkin dâhil ederek geliştiriyorum; böylece otomasyona hazır olduğumuzda işin büyük kısmı tamamlanmış oluyor.

Michael Luchen

Bu ilginç. Test senaryoları gibi birkaç kavramdan bahsettin. Bunlar nedir? Ürün yöneticisi olarak yazdığım kabul kriterlerinden mi geçmek anlamına geliyor, yoksa daha ayrıntılı bir şey mi?

Erin Hess

İkisi de. Ekibin ve ürün geliştirme yöneticisinin birlikte ele alıp geliştirdiği kabul kriterlerini alıyoruz. Test senaryolarında ise şu sorular yer alıyor: Bu tür kullanıcı, bu tür cihazda ne yapıyor? Beklenen sonuç ne? Riskler neler? Kullanıcının ürünü yanlış kullanmak için deneyebileceği şeyler neler? Kullanıcının test sırasında yapabileceği farklı uçtan uca akışları oluşturuyoruz.

Michael Luchen

Bir ürünü yayımladığımızda kullanılabileceği çok fazla yer var: farklı web tarayıcıları, ekran çözünürlükleri, cihazlar ve daha fazlası. Test senaryolarında ürünü zor bir duruma sokmak istediğini söylüyorsun. Bu büyük kapsam içinde çabalarını nereye yoğunlaştıracağını nasıl belirliyorsun?

Erin Hess

Testte aşırıya kaçmak mümkün. Erişilebilirlik testlerinde, aslında o şekilde test edilmesi gerekmeyen sayfalarda çok sık ve çok fazla test yaparak aşırıya kaçabilirsin.

Test konusunda kendini kaptırabilirsin. Bunu sınırlandırmak zaman ve pratik gerektiriyor. Önceden düşünerek elindeki projenin türünü belirlemelisin. Bu bir web uygulaması mı, yerel bir uygulama mı, yalnızca iPhone’larda mı çalışacak? Test edebileceğin tüm yolları düşündüğünde ihtiyacın olmayan testleri elemeye başlarsın. Daha sonra hangi kullanıcı türü için hangi cihaz ve tarayıcıya ihtiyaç duyduğunu belirleyerek test matrisini oluşturursun.

Michael Luchen

Test senaryolarını ve odaklanacağın noktaları belirlerken tarayıcı kullanım istatistiklerine, cihaz kullanım istatistiklerine ve benzeri verilere düzenli olarak bakıyor musun? Üzerinde çalıştığın ürün için nelerin geçerli olduğunu nasıl belirliyorsun?

Erin Hess

Hangi platformlarda test yapmanın en pratik olduğunu belirlememize yardımcı olan çok sayıda kaynak var. Belirli bir cihazda veya tarayıcı sürümünde tarayıcı kullanımı ne durumda? Bu tür uygulamaları, ürünleri ve hizmetleri kaç kişi kullanıyor? Bu verileri kullanarak Safari ve Chrome’u, iOS ve Android’i kesinlikle kontrol etmek istediğimize karar veriyoruz. Zamanımız kalırsa daha düşük riskli seçenekleri de test ediyoruz; örneğin Edge ya da uygulamanın çalışıp çalışmadığını bilmenin yararlı olacağı başka bir tarayıcı.

Michael Luchen

Kullanıcı testleri veya anketler de nerede test yapılması gerektiğini belirlemeye yardımcı oluyor mu?

Erin Hess

Kullanıcı anketleriyle çok fazla çalışmadım; ancak anketleri doldurmayı ve geri bildirim vermeyi seviyorum. Gerçek kullanıcıların geri bildirimlerini bu şekilde almak gerçekten değerli olabilir. Ayrıca belirli bir uygulama türü için ortalama kullanıcı deneyiminin nasıl olması beklendiğini dikkate alıp oradan ilerliyorum.

Michael Luchen

Otomasyon betikleri yazdığından da bahsetmiştin. Bir üründe otomasyonun değeri nedir ve ne zaman başlatılmalıdır?

Erin Hess

Bu, duruma bağlı bir konu. Proje uzun vadeli ve devam eden bir projeyse, güçlü bir ekibe sahipse ve bitişi görünmeyen büyük bir projeyse otomasyon için uygun olabilir. Önce manuel testlerinle başlayabilir, bunları risk ve özellik temelinde sıralayabilirsin.

Ardından hangi otomasyon çatısını kullanmak istediğini veya düşük kodlu, web tabanlı bir çözümü tercih edip etmediğini düşünebilirsin. Otomasyon konusunda çok fazla seçenek var. Önemli olan önce ne yapmanın en mantıklı olduğunu belirlemek.

Proje sıfırdan başlayan yeni bir projeyse otomasyonu düşünmek yine de faydalıdır. Geliştirme ve tasarım öncesi aşamalarda ekiplerle birlikte çalışabileceğin fırsatlar vardır. Örneğin bileşenlere erişilebilirlik etiketleri eklemek. Şu anda Gherkin’de bunu yapıyoruz; böylece ortada henüz bir ürün yokken bazı kod ve betikler hazır oluyor.

Bu zaman kazandırır ve tasarım, geliştirme ve test süreçleriyle paralel yürütüldüğünde daha iyi planlama yapmana yardımcı olur. Test mühendislerinin her sprintte yaptığı işlere başka bir karmaşıklık katmanı ekler. Kabul kriterlerinin yanı sıra test senaryolarını yazıp incelerken, otomasyon betiklerin için de yazılmış kabul kriterlerini gözden geçirerek küçük ölçekte bir geliştirici gibi çalışırsın.

Erken başlamak harikadır; ancak genellikle test sürecini hızlandırmak ve testleri daha kararlı hâle getirmek istediğinde otomasyona ihtiyaç duyarsın.

Michael Luchen

İlginç. Şimdi ekipteki başka bir role geçmek istiyorum. Ürün yöneticileriyle iş birliğine nasıl yaklaşıyorsun?

Erin Hess

Bu eğlenceli. Daha önce söylediğim gibi ekibimle ilişkiler kurmayı seviyorum. Bu hiyerarşiye dayanmıyor; ekipteki herkesin birbiriyle iş birliği yapmasını ve çalışmasını istiyorum. Bu süreci desteklemeyi seviyorum. Bu yüzden ürün yöneticileriyle çalışmayı geliştiriciler ve tasarımcılarla çalışmayı sevdiğim kadar seviyorum.

Bunun bir bölümü kabul kriterleri üzerinde iş birliği yapmak ve yardımcı olmak ya da araştırma yürütmek, bir konu hakkında bilgi toplamak gibi şeylerden oluşuyor. Belki belirli bir test türü için farklı bir yaklaşım deneyebiliriz. Ürün yöneticisinin ihtiyacı olan ve benim yardımcı olabileceğim herhangi bir görev varsa devreye giriyorum.

Michael Luchen

Daha önce de ima ettiğim gibi test mühendisi ile ürün yöneticisi arasındaki ortaklığın ürün ekibindeki en etkili iş birliklerinden biri olduğunu düşünüyorum. Özellikle kabul kriterlerine ve bir şey kullanıcıya sunulmadan önce nasıl doğrulanacağına odaklanması nedeniyle.

Ürün yöneticileri ve test mühendisleri kabul kriterleri üzerinde erken çalıştığında güzel bir denge ortaya çıkıyor. Ürün yöneticileri, ulaşmaya çalıştığımız kullanıcı sonuçlarına odaklanma duygusunu getiriyor. Test mühendisi ise ayrıntıları ve tüm boşlukların uygun düzeyde kapatıldığını, ürün ekibinin geri kalanının yaratıcılığını sürdürebileceğini ve kullanıcı ihtiyaçlarını destekleyen kaliteli bir ürünün yayımlanıp test edilebileceğini güvence altına alıyor.

Bu dengeye katılıyor musun?

Erin Hess

Kesinlikle katılıyorum. Test mühendisi olmadan çalışılan ve erken dâhil edilen ekiplerde yer aldım. Bu nedenle sürecin en başında dâhil edilmenin değerini gerçekten biliyorum.

Michael Luchen

Bir ürün ekibinin test mühendisi olmadan çalışmasını deneyimlediğinde, işlerin ne kadar kötüye gidebileceği çok açık hâle geliyor.

Erişilebilirliğin büyük bir savunucusu olduğunu da biliyorum. Erişilebilirliğin ne anlama geldiğinden biraz bahsedebilir misin?

Erin Hess

Erişilebilirlik kelimesi bugünlerde çok sık kullanılıyor. Gündemde olan bir konu. A11Y olarak da biliniyor; çünkü erişilebilirlik kelimesindeki A ile Y arasında 11 harf var. Savunucu olmak, farklı son kullanıcıların sesi olmak anlamına geliyor. Özelliklerin, ürünlerin ve hizmetlerin herkes tarafından erişilebilir olması için mücadele ediyorsun. Kapsayıcılık, konuşmak ve sesimi başkalarına yardımcı olacak şekilde nerede kullanabileceğimi bulmak bunun büyük bir parçası.

Michael Luchen

Bazı paydaşların erişilebilirlik konularına öncelik verme imkânımız olmadığını söylediğini görebiliyorum. Buna nasıl karşılık veriyorsun?

Erin Hess

Bunu birkaç farklı yöntemle yaptım. Bazı paydaşlar için en başarılı yöntem, uyumlu bir web siteleri olmazsa işletme açısından ne kadar pahalı olabileceğini rakamlarla göstermek. Dava açılması riski oldukça ciddi. Bu durum karmaşık ve toparlanması zor. Ayrıca başka bir son kullanıcı grubunu umursamadığınızı öğrenen insanlarda kötü bir izlenim bırakıyor. Gerçekte durum böyle olmayabilir; ancak onların düşüneceği şey bu oluyor.

Michael Luchen

Testin temeli olarak empati hakkında biraz daha konuşabilir misin?

Erin Hess

Çoğu kişi “başkasının ayakkabılarıyla yürümek” ifadesini duymuştur. Bu, empatiyi anlatan başka bir ifade. Empati, başka bir kişinin yaşadıklarını onun bakış açısından anlama veya hissetme kapasitesidir. Empati tanımı çok geniş bir duygu aralığını kapsayabilir.

Bu konu hakkında, özellikle empati ve test üzerine bir sunum da yaptım. Bu yılın başlarında Ministry of Testing’in TestBash Home etkinliğinde arkadaşım Jenny Bramble ile birlikte sunum yaptık. Duygularımızı, “Empati Testin Temelidir” ifadesinin ne anlama geldiğini ve geçmiş deneyimlerimizin bizi empati ve müşteri ihtiyaçları hakkında konuşmak için nasıl benzersiz bir konuma getirdiğini ele aldık.

Michael Luchen

Kısaca söylersek, empatiyi testin temeli yapan şey nedir?

Erin Hess

Test ve empati arasında bir kesişim var. Birinin deneyimini bilmiyorsan beklentilerini de bilemezsin. Başkasının deneyimine adım atmak testin önemli bir parçası ve bunu sürekli yapıyoruz; bazen yaptığımızın farkında bile olmuyoruz. Yüksek kontrastlı bir temayı veya disleksi dostu bir yazı tipini test etmek buna örnek. Bunlar belirli bir nedenle var. Sonuç olarak test ve empatinin kesişimi doğrudan erişilebilirlik testi alanına giriyor.

Michael Luchen

Son 25 dakika boyunca seninle konuşurken birkaç temanın ortaya çıktığını görmek ilginçti: erişilebilirlik savunucusu olmak, empatinin test mühendisi olarak yaptığın her şeyin içinden geçmesi ve test mühendisinin rolünde iş birliğinin ne kadar önemli olduğu. Bu yalnızca ürün yöneticisiyle değil, bir bütün olarak ürün ekibiyle iş birliği yapmak anlamına geliyor.

Programı bitirmeden önce birkaç kişisel hızlı soru sormak istiyorum.

Erin Hess

Sor.

Michael Luchen

Başarına en çok katkıda bulunan kişisel alışkanlığın hangisi?

Erin Hess

Büyük miktarlardaki bilgiyi oluşturma, yapılandırma ve düzenleme becerim olduğunu söyleyebilirim. Bu zaman içinde gelişti. Süper güçlerimden biri gibi. Genel olarak düzenlemeye ve iyi, yararlı, anlamlı dokümantasyon yazmaya duyduğum tutkudan kaynaklandığını düşünüyorum.

Michael Luchen

Düzenli olarak kullandığın en sevdiğin araç hangisi?

Erin Hess

Kesinlikle Chrome Geliştirici Araçları. Çok fazla nedeni var; ancak mobil cihazları simüle etmek, duyarlılığı ve farklı görünüm alanlarını test etmek için kullanabileceğin Cihaz Modu’nu özellikle belirtmek isterim. Ağ panelleri en iyi arkadaşım. Bir hata bulduğumda bunu bildirmek için geliştirici araçlarına girdiğimde ilk olarak orayı inceliyorum. Erişilebilirlik testleri için de Lighthouse ve Axe’i kullanıyorum.

Michael Luchen

Ürün alanındaki yolculuğunun başında olan birine vereceğin tek tavsiye nedir?

Erin Hess

Her şeyi ve kimden gelirse gelsin her şeyden öğrenmeye açık ol. Bir geliştirici, tasarımcı veya ürün yöneticisi senden zamanını ya da dikkatini istediğinde bunu değerlendir. Bunu bir öğrenme deneyimi olarak kullan ve bundan faydalan.

Michael Luchen

Çok güzel söyledin. Bugün gerçekten çok şey öğrendim. Programa katıldığın için çok teşekkürler Erin.

Erin Hess

Rica ederim. Beni davet ettiğin için teşekkürler. Erişilebilirlik testi ve genel olarak test mühendisliği hakkında daha fazla konuşmayı sabırsızlıkla bekliyorum.

Michael Luchen

Ben de bunu sabırsızlıkla bekliyorum. Erin’den daha fazla bilgi edinmek isteyen dinleyicilerimiz, çalışmalarına crema.us adresinden ulaşabilir. Kendisine LinkedIn’den ulaşabilirsiniz. Erin Twitter’da da aktif; @QueenTester kullanıcı adıyla bulabilirsiniz.

Programı beğendiyseniz, otomasyon ve test alanındaki en yeni ve en iyi gelişmeleri incelediğimiz ilgili yayınımız QA Lead’e göz atın. theqalead.com adresinden ziyaret edebilirsiniz.

Bugünkü programa katıldığın için tekrar çok teşekkürler Erin. Harika bir bölümdü. Dinleyen herkese teşekkürler. Lütfen bu podcast için bir değerlendirme bırakmayı unutmayın. Geri bildirimlerinizi duymaktan memnuniyet duyarım. Ayrıca theproductmanager.com adresinden topluluğumuzu takip edip katılmayı unutmayın. Teşekkürler.