Yayınlanmadan hemen önce binlerce kusurun sipariş edilmesi / ele alınması
Bu soru bana gerçekten iyi bir şirket ile yapılan bir röportajda soruldu.Aşağıda soruyu etkileşimimiz şeklinde sunacağım (M: ben ve ben: görüşmeci) Kesin bir cevap olmamasına rağmen ne olduğunu bilmem gerekiyor görüşmecinin gerçekten istediği fikir / cevap :
I: Senaryo siz ve diğer 2 kişi test ekibinden oluşuyor. Otomasyonu yapabilen tek kişi sizsiniz, diğerleri sadece manuel test yapabilir. Yaklaşık 10.000 hatanız var ve bu ürün teslim edilmeden önce 4-5 hafta veya daha az süreniz var. Ürünün zamanında teslim edilmesini sağlamak için ne yapacaksınız?
M: Hataları öncelikli olarak filtreleyin ve yeniden test edin. Bu arada, hangi işlevlerin daha fazla gerilemeyle karşı karşıya olduğu hakkında bir günlük tutun ve böylece bunları otomatikleştirmeye başlayın. Benzer veya ilgili hatalar, daha ileri testler için başkalarına verilecektir.
I: Diyelim ki böceklerden hiçbirinin öncelikli olarak işaretlenmemiş. Ne yapacaksın?
M: Tarihlerle filtreleyeceğim.Her türlü SDLC'de, hatta çevik olanında bile, çekirdek bileşenler önce geliştirilir, çekirdek hatalar varsa önce bunların düzeltilmesi gerekir.
I: (Onaylanmayarak) Daha sonraki bir sprintte çok önemli bir işlev eklenirse ne olur? Ayrıca takım arkadaşlarınızdan ve otomatikleştirme yeteneğinizden nasıl yararlanacaksınız.
M: Tarihin yanı sıra, bir testçi olarak ürünün temel ve önemli işlevlerini bugüne kadar bilmem gerekecek.Bu nedenle, her bir sprint'in üzerinde çalışılacak temel alanlarını bulacağımı aklımda tutarak (takım arkadaşı hakkında aynı şeyi yanıtladı) eskisi gibi).
I: Diyelim ki, hatalar her sprint için zaman çizelgesiyle işaretlenmemiş. Ne yapacaksın?
M: Hataların listesini, ürünün onsuz serbest bırakılamayacağı önemli işlevleri temsil eden anahtar kelimelerle arayacağım. Böcekleri oradan seçeceğim.
I: (Yine onaylamayarak) Bir anahtar kelimeyle o kadar çok sonuç alırsınız ki, bunları tek tek gözden geçirir misiniz?
M: (yavaş yavaş umudumu kaybederek) Sadece başlığın üzerinden geçip karar vereceğim.
I: Genel olarak başlıklar o kadar açıklayıcı değil, nasıl başa çıkacaksınız?
M: Ürün teslimi için karar vermem gerektiği için hataların üstesinden gelmeye çalışmak yerine ürünü kendim test etmeye ve karşılaştığım benzer hatalarla aramaya başlayacağım.
I: Yani bu birçok hatayı görmezden mi geleceksiniz? Paydaşlar aynı fikirde olmayabilir. (Bundan sonra tamamen kaybettim ve dedikodu yapmaya devam ettim ve başka ne sorulduğunu hatırlamıyorum, ayrıca her yerde diğer 2 manuel test edicinin yönetimi / çalışması soruldu)
Bu, Sr SDET için bir röportajdı.
Yanıtlar
Diğer cevapların söylediklerine ek olarak, görüşmeyi yapan kişinin, bir takıma yeni bir üye olarak kazanılamayan bir durumla nasıl başa çıkacağınızı aradığını söyleyebilirim. Açıkçası, en azından şirketin geçmişte kendisini bu tür bir durumda bulduğundan şüpheleniyorum. En kötüsü (alaycı olduğumu özgürce itiraf ediyorum), pozisyonu kim alırsa alsın benzer bir şeyle karşı karşıya kalacaktır.
Bir görüşmeci olarak, görüştüğüm kişiden şöyle bir şey isterdim:
İlk olarak, bu hataların nasıl organize edildiğini, özellikle de öncelik, önem derecesi ve riski bilmek isterdim. Bu duruma girdiğimi ve en başından beri dahil olduğumu varsaymıyorum, çünkü bu tür bir durum bir yerlerde işlerin çok kötü gittiğini gösteriyor.
Hatalar öncelik, ciddiyet ve risk içeren bir şekilde düzenlenmemişse, diğer testçilerle, proje yönetimiyle ve geliştirmeyle görüşmek ve bunların tahmin edilen dağıtım için en büyük riski oluşturduğunu bildiklerini belirlemek isterim. tarih.
Böyle bir organizasyon varsa, en yüksek riskli hataları teyit etmek için test uzmanları, proje yönetimi ve geliştirme ile konuşmak isterim. İdeal olarak, ürün piyasaya sürülmeden önce düzeltilmesi gereken hataların bir listesini oluşturmanın bir yolunu arıyorum. 10.000 hatayla, bu listenin oluşturulması biraz zaman alacak ve bu, rapor edilen hataların onları gizlediği veya engellediği için testçilerin bulamadığı hiçbir hata olmadığını varsayar.
Durumun ne kadar kötü olduğuna dair bir fikrim olduğunda, bence uygulamayı planlandığı gibi yayınlamanın mümkün olup olmadığına karar verebilirim. Hataların çoğu nispeten düşük riskliyse ve yüksek riskli hatalar makul ölçüde kolayca düzeltiliyor gibi görünüyorsa, ekibimi yüksek riskli hatalara odaklayabilir ve en yüksek riski elde etmek için proje yöneticisi ve diğer ekiplerle birlikte çalışırım (yüksek şiddette, büyük olasılıkla sahada ve / veya uygulamanın bloke alanlarında) hatalar düzeltildi ve test edildi.
Ürünü zamanında yayınlamanın bir yolunu göremezsem, proje yöneticisi ve patronumla, katı işlevselliğin sınırlı bir beta sürümünü yapmanın veya sürümü geciktirmenin bir yolu olup olmadığını görmek için konuşmaya başlardım. Pozisyonda yeni olduğum için, tahliye tarihini taşınmaz olmaya zorlayabilecek herhangi bir sözleşme gerekliliği veya kontrolüm dışında başka faktörler olup olmadığını bilmiyorum.
Ayrıca, serbest bırakıldıktan sonra dahil olan tüm ekiplerin liderleriyle böyle bir durumun nasıl ortaya çıktığını ve tekrar olmasını önlemek için hangi önlemleri alabileceğimizi ve birlikte nasıl çalışabileceğimizi anlamak için aldığımdan da emin olurdum hata birikimini ortadan kaldırın.
Bunların hiçbirinin SDET rolü ile ilgisi olmadığını unutmayın. Görüşmeyi yapan kişinin bir SDET'in aynı zamanda bir test lideri olarak hareket etmesini beklediği sorudan açıkça anlaşılıyor - bunun özellikle iyi bir şey olduğunu düşünmüyorum ve açıkçası, bunun şirketin kendisinden beklediği bir şey olup olmadığını bilmek isterim. SDET'ler.
Röportajlar yüksek stresli durumlar olsa da, dalmak yerine yana doğru düşünmeye ve sorulan soruların sonuçlarına bakmaya çalışmak. Stresli olduğunuz ve elinizden gelenin en iyisini yapmaya çalıştığınız için bunu yapmak zordur. ancak zihinsel olarak kendinize mülakatı yapan kişinin soruyla ne aradığını sormak için biraz zaman ayırabilirseniz, genellikle daha iyi bir cevap verebilirsiniz.
Akla gelen ilk şey - bu testler daha önce işe yaradı mı? Öyleyse panik yapmayın. Kod tabanında veya test çerçevesinde muhtemelen grupların başarısız olmasına neden olan bir şey değişti. Bunu takip edin ve bir seferde birkaç bin arızayı giderip gideremeyeceğinizi görün. Yine de geçenler manuel olarak tekrar okumanız ve tekrar kontrol etmeniz gerekecek, ancak bu sadece birkaç gün sürecek.
Daha önce hiç kontrol edilmemişlerse, yine de benzer bir şey yapardım - büyük grupları aynı anda düzeltmenize izin verebilecek ortak noktaları arayın.
Aksi takdirde, orada o kadar çok gürültü vardır ki, başarısız olan kritik bir şeyi kaçırmanıza neden olabilir.
Bundan sonra her şeye ulaşamayabileceğinizi ve para yapıcı kod yoluna odaklanamayacağınızı kabul edin. İşe yaraması gereken şeyler ya da iş kıvrılıyor. Sonra bunlardan birkaçını daha temizledikten sonra, her gün veya üç günde bir bakın ve daha önce bahsedildiği gibi gruplanmış başarısızlıklar olup olmadığına bakın ve birkaç grubu daha temizlemeyi deneyin.
Not: Buna bir SDET bakış açısından cevap vermek - sorun teşkil eden kod tabanını kendisi düzeltebilecek biri.
Görüşmeci hatalardan bahsediyor ve test başarısızlığından bahsetmiyorsa (test hatasıysa @Lewis tarafından verilen yanıta bakın)
Öncelikle bir üründe 10000 aktif hata olması gerçekten büyük bir kırmızı bayraktır.
Ve asla böyle bir ürünü piyasaya sürmemelisiniz. Ancak yönetim kararı hala açıklanacaksa,
Görüşmecinin beklediği cevap " ciddiyet " olacaktır
Ekip, öncelik yoksa önce yüksek öneme sahip hataları gidermeye odaklanmalı ve acil bir gereklilik değilse ve gerçek iş mantığını etkilemiyorsa beklemede bir kez düşük tutmalıdır.
Ve başlangıçta duman testini otomatikleştirmeye odaklanın, ardından tüm regresyon süitlerini otomatikleştirmeye başlayın
Hataları gruplayın ve hata kümelemesinin nerede gerçekleştiğini görün ve düzeltme yapıldıktan sonra bu modülü titizlikle test edin.
Serbest bırakmadan önce tüm duman testi senaryolarını manuel olarak test edin (Kritik işletme mantığı)
Ayrıca, 10000 hataya sahip olmak, bu hataların ürün içindeki bazı kritik hataları maskelediği yerlerde kusur maskelemesine neden olabilir .
Bu nedenle, düzeltme yapıldıktan sonra, daha kritik hataları bulmak için modüller etrafında daha titiz testler yapılmalıdır.
yani röportajda olsaydım şöyle cevaplardım:
- Herhangi bir projedeki 10000 hata büyük bir kırmızı bayrak olurdu, bu da uygun bir hata düzeltme süreci ve yerinde tahmin olmadığını gösterir. Kusur kümeleme ve kusur maskeleme konusunda kesinlikle endişelenirim, yani hataların çoğunun tek bir modülde yoğunlaşması olasılığı vardır ve bu kadar çok hata, yalnızca modülü titizlikle sabitleyip yeniden test ettikten sonra tespit edilecek diğer kritik hataları maskeliyor olabilir. . Ve bu nedenle yayın tarihini daha ileri götürmenizi tavsiye edecektir.
Bu arada, geliştirme ekibi hataları düzeltmekle meşgulken, duman testi kullanım durumlarını ve hata kullanım durumlarını otomatikleştirmeye başlayacağız. Düzeltme geldiğinde, yeniden test görevlerini manuel test uzmanlarına atayacak ve maskelenmiş kritik hataları bulmak için modül üzerinde titiz geçici testler yapıyoruz.
- Bir öncelik yoksa, o zaman önce kritik veya yüksek önem derecesine sahip hataları tekrar gözden geçirmek ve ayrıca hataların ömrünü araştırmak ve gelecekte genel süreci iyileştirmeye yardımcı olmak için neden bu kadar uzun süre düzeltilmediğini anlamak için boşta olacaktır.
Önem düzeyi düşük hatalar hakkında, zaman çizelgesine ve bu hatalarla ilk sürümü yayınlayıp yayınlamama kararına ilişkin bir ekip kararı vermemiz gerekir, ancak yine de aynıları ve gerektiğinde geçici çözümleri belgelemeliyiz. Ayrıca mümkünse olası düzeltme için bir sonraki yayın tarihini de sağlayın.
Bu nedenle, kıdemli bir QA olarak, kırmızı bayraklar gördüğünüzde "HAYIR" olarak kalmak için güçlü fikrinizi ortaya koymalısınız. Çok esnek olma
Buradaki diğer cevaplar, sorunun amacı somut bir cevap vermekse iyidir.
Bununla birlikte, birçok görüşmeci, belirli bir cevap olmadan belirsiz sorular sorar çünkü nasıl düşündüğünüzü bilmek veya soru hakkında varsayımlarda bulunup bulunmadığınızı anlamak isterler. Ayrıntıları öğrenmek için onlara açıklayıcı sorular sormanızı istiyorlar. Bu, cevabınızı yönlendirmeye yardımcı olur.
Senaryo siz ve diğer 2 kişinin test ekibinden oluşmasıdır. Otomasyonu yapabilen tek kişi sizsiniz, diğerleri sadece manuel test yapabilir. Yaklaşık 10.000 hatanız var ve bu ürün teslim edilmeden önce 4-5 hafta veya daha az süreniz var. Ürünün zamanında teslim edilmesini sağlamak için ne yapacaksınız?
Sorulacak bazı sorular:
- Manuel qa test cihazları ne kadar deneyimlidir?
- Manuel test uzmanları bu projede deneyimli mi? Yoksa onlar da projede yeniler mi?
- 10.000'in tamamının teslimat tarihinden önce düzeltilmesi gerekiyor mu?
- Ekiplerin kullandığı bir hata izleme yazılımı var mı? Öyleyse ne olmuş?
- Bilinen hatalar nasıl takip ediliyor? Listelenmiş bir öncelikleri var mı? Özelliğe göre gruplanmış / etiketlenmiş mi?
- Şu anda yazılım için kullanılan otomatik testler var mı? Varsa kaç birim testi, entegrasyon testi, UI testi var? Veya tüm otomatik testleri / çerçeveyi 4-5 haftalık zaman diliminde sıfırdan oluşturmam gerekiyor mu?
- Geliştiriciler ne kadar testten sorumludur? Birim / entegrasyon testleri oluşturuyorlar mı?
- 10.000 hata UI hatası mı? Veya birim testleri, entegrasyon testleri, UI testleri kullanılarak test edilebilecek bir hata karışımı mı?
- Test için hangi cihazların kullanılması gerekiyor?
- Kullanıcıları ve paydaşları memnun etmek için ulaşmamız gereken kalite düzeyi nedir? Paydaşlar kaliteyi nasıl algılar?
- Paydaşlar başarılı bir proje başlangıcını nasıl belirler?
- Ekiplerin tanımı nedir?
- Ekibin proje yayınlandıktan sonra hataları düzeltmek için zamanı olacak mı? Yoksa bir sonraki projeye mi geçiyoruz? Zamanımız olursa ne kadar zamanımız olacak?
- Ekip, Agile SDLC veya Waterfall SDLC kullanıyor mu?
İyi düşünülmüş bir cevap vermeniz için ihtiyacınız olan açıklığa kavuşmak için sorabileceğiniz sonsuz sayıda soru vardır.
Ve yukarıdaki ayrıntılı görüşmeden, görüşmeci, manuel test uzmanlarını planınıza nasıl dahil edeceğiniz konusunda ayrıntılar sormaya devam etti. Bu size görüşmecinin ne aradığına dair büyük bir ipucu verir: bu projeyi test etmenin tüm yükünü sizin üstlenmenizi istemiyorlar; Onlar, bir Kıdemli SDET / QA Mühendisi olarak, genç seviyedeki test uzmanlarından oluşan bir ekibe nasıl rehberlik edeceğinizi / yönettiğinizi bilmek istiyorlar.
Unutmayın, röportajlar sadece onların sorularını cevapladığınız bir sorgulama olmamalıdır. Görüşmeler, sorularını netleştirmeye yardımcı olacak her şeyi sorabileceğiniz bir konuşma olmalıdır.