Test kullanıcıları sürümleri onaylamalı mı yoksa sadece testler hakkında rapor vermeli mi?

20

Test kullanıcılarına imza yetkisi vermek mantıklı mı? Bir test ekibi olmalı

Sadece özellikleri, sorunları vb. Test edin ve başarılı / başarısız olarak raporlayın, bu sonuçlara göre hareket etmesini sağlayın veya
Bu sonuçlara dayanarak kendilerini serbest bırakma yetkiniz var mı?

Başka bir deyişle, test kullanıcılarından sürümlerden çıkış yapmaları gerekir mi? Birlikte çalıştığım test ekibi bunu yapıyorlar ve "test kapsamı sürünmesi" nedeniyle bununla ilgili bir sorun yaşıyoruz - sürümlerin onaylanmasının reddedilmesi bazen söz konusu sürümde açıkça ele alınmayan sorunlara dayanmaktadır.

testing release-management process

— Ernest Friedman-Tepesi
kaynak

2

Lütfen sorunuzu bir anket olmaması için yeniden ifade edin. Çözmeye çalıştığınız sorun nedir?

— M Dudley

5

"gerekir" büyük ölçüde şirketin organizasyon yapısına bağlıdır. Üretimde bulunan böcekler üzerinde ölçülürlerse, buggy salımını tutabilmek önemli bir araçtır.

Mükemmel nokta, @MichaelT. Kuruluşumda test, iş tanımından ziyade bir roldür ve değerlendirme daha ad hoctur ve nicel değildir. Başarılı dağıtımlar olumlu eleştirilerle beslenir, ancak üretimdeki hatalar, takımdaki diğer herkesten daha fazla, belirli negatifler olmazdı.

— Ernest Friedman-Hill

5

Test uzmanlarının, ele alınması planlanmayan sorunlara dayalı olarak yayınları onaylamayı reddetmesi konusunda sorun yaşıyorsanız, iletişim sorununuz (sorunların ele alınmayı planlanmadığını bilmiyorlar) ya da insan sorunu (kendilerini önemli kılar; serbest bırakmak nihayetinde ticari karardır).

— Jan Hudec

27

QA çalışanlarıyla çalıştığım çoğu yerde bir çeşit imzalama adımı var, ancak sürümün devam edip etmediği konusunda nihai yetkiniz yok. İmzaları, sürümün kusursuz olmadığını değil, sürüm planı tarafından beklenen testi tamamladıklarını gösterir.

Sonuçta QA! = İşin ve işletmenin, kodu geçerli durumda konuşlandırmaya uygun olup olmadıklarına veya yararın olumsuz ya da herhangi bir ağırlığa ağır basıp basmadığına karar vermeleri gerekir. Bu genellikle dağıtımdan hemen önce müşteriler veya paydaşlar tarafından yapılır ve genellikle Kullanıcı Kabulü olarak adlandırılır.

KG'niz aynı zamanda Kullanıcı Kabul grubunuzsa, sürüm adayınızı kabul edilemez olarak tanımlama yetkisine sahip olma potansiyeli vardır, ancak bunu bugfix / iteration / sprint / change kapsamının dışında kalan konulardan alıyorsanız talep / zaman ayırdığınız ne olursa olsun, Proje Yöneticisi veya iş hattı paydaşlarının QA ekibi ile İsa toplantısına gelmeleri gerekir.

Önceden var olan kusurlar veya yeni gereksinimlerin istenmeyen sonuçları hakkında rapor vermek iyidir, ancak kapsam dışı ve felaket dışı ise, bunu engelleme sorunu olarak etiketlemek genellikle kabul edilemez. Ürün sahibinin diğer her şey gibi öncelik sırasına koyması iş yüküne gider.

— fatura
kaynak

Müşteriyi yapı 1234'te bir kabul testi yapmaya davet edip etmeyeceğinize veya kabul testi için yeterince iyi olmadığına kim karar verir?

— Bart van Ingen Schenau

3

@BartvanIngenSchenau: Ürün sahibinin / proje yöneticisinin bu konuda son sözü olması gerekiyor. Çünkü kabul testleri bile gerektiğinde sık sık yükselecektir (Y'yi onunla çalışmamamıza rağmen şimdi X özelliğini istiyor musunuz, yoksa biz düzeltene kadar 2 ay daha beklemek istiyor musunuz?) Ve ürün sahibi bunu müzakere ediyor.

— Jan Hudec

Jan'ın söylediklerine ek olarak, birçok metodolojide burada zamanlama veya kadans olacaktır. bazı insanlar ilk duman testinden kurtulan her adayı UAT'a dağıtır, bazıları otomatik olarak aday dalına kontrol edilen herhangi bir şeyi konuşlandırır, bazıları ana kontrol edilir. ideal olarak, bir şekilde giderken paydaşların ilerlemesini göstermiş olursunuz, bu yüzden sonunda çok fazla sürpriz olmamalıdır. bu vakaların bazılarında paydaşlara QA halkının sizi kömürlerden geçirdiğini göstermeye başlıyorsunuz ve sadece "kimin umurunda" olduğunu söylüyorlar ve bitti.

— Bill

Sürekli konuşlandırmalı modern SaaS'ta, kod (hizmet) konuşlandırma döngüsü özellik (iş) yayın döngüsünden ayrı olabilir. Bu özellik yayın döngüsü, alfa (dahili) ile beta (kaydolma) arasında genel kullanılabilirliğe kadar özellik bayrakları veya geçiş düğmeleri kullanılarak uygulanabilir. Bu, belirli kod veya hizmetlerin dağıtılabilirliğinden ayrı olarak ve bunlardan bağımsız olarak ne olursa olsun, daha resmi iş çıkışını içermenin bir yoludur. Karşılıklı bağlama özelliği, servis dağıtımlarına bırakılır, özellik bayrağı tekniği ile önlenebilecek sürece bağlantı ve risk getirir.

— Will

@ katılmıyorum, ama birisi hala bu gizli özellikler ilk dağıtımda beta ekibi dışındaki kullanıcılar tarafından fark edilmeyecek kadar gizliyse ve sonuçta sıra oyunlarına yaklaştığım herhangi bir yerde karar verir. aşağı yukarı aynı, ancak hareketli parçalar üzerinde farklı etiketler ve risk biraz değişti. Açıkladığınız durumu tercih ediyorum, ancak önceden mevcut bir şey bulan KG ekibi veya yine de devam etmeye karar veren ürün yöneticisi bu modelde deneyimlerimdeki diğer şeyler kadar önemli.

— Bill

6

Birisinin bu otoriteye ihtiyacı var . Test kullanıcısı, test takımı, test takımının lideri veya geliştirme organizasyonunun lideri olsun, biraz ilgisizdir. Ya da daha doğrusu, organizasyona bağlıdır.

Sonuç olarak, yazılımı serbest bırakma seçeneği bir iş işlevidir. İşletme kalitenin uygun olup olmadığına karar vermek zorundadır. Muhtemelen, kalite güvence müdürü bu kararı vermeli veya bu kararı uygun iş birimine beslemelidir. Her şey şirketin büyüklüğüne, kalitenin göreceli önemine vb.

Tüm söylenenler, karar vermek için kullanılan bilgiler test kullanıcısı ile başlar . Bir sürümü durdurma gücü olsun ya da olmasın, sürümde gecikmeye neden olacağını düşündükleri bir şeyi gördüklerinde karar vericilere bilgi verme sorumluluğunu hissetmelidirler.

— Bryan Oakley
kaynak

6

Test kullanıcılarına salıvermeler için imza yetkisi (yani veto hakkı) vermek, geliştiricilere bu hakkı vermek kadar mantıklıdır: hiçbiri.

Testçiler ve geliştiriciler öncelikle teknik kişilerdir, bu nedenle kararlarını çoğunlukla teknik gerekçelerle vermeleri muhtemeldir. Ancak, bir sürüm yayınlanırken tartılması gereken endişeler hem teknik hem de ticari kaygılardır. Açıkçası, hataya neden olan bir ürün teslim ederseniz müşteri mutlu olmayacaktır, ancak üründe hala açık sorunlar olduğu için bir sürümü ertelemeye devam ederseniz müşteri eşit derecede mutsuz olacaktır.

Birinin iyi bir ürün ile müşteriye vaat edilen programa uyması arasında doğru dengeyi bulması gerekir. Bunu yapmak için, gereken değil tamamen teknik rolde projede yer alan, ancak daha ziyade proje yöneticisi veya ürün sahibi ve test ve geliştiriciler adresinin giriş almak gibi daha iş / yönetim odaklı rolde.

— Bart van Ingen Schenau
kaynak

1

Buna oy verdim çünkü yaptığınız çeşitli noktalara ve varsayımlara temelde katılmıyorum. QA'nın bir serbest bırakma veto etme yetkisine sahip olmaması gerektiğini kabul etmiyorum çünkü birçok QA grubu da Kullanıcı Kabul rolünde de çalışıyor. Dahası, test uzmanlarının teknik insanlar olduğu varsayımına katılmıyorum. Her zaman böyle değil, yazılım yayınlayan her grup tam bir KG ekibini karşılayamaz, bu nedenle bu rol hiç teknik olmayan iş analistlerine düşebilir.

— maple_shaft

1

maple_shaft'ın noktasına ek olarak, korkunç bir şey belirlenmedikçe, bu solda müşteri rolündeki herkese son çağrıyı sık sık görüyorum. sonuçta bunların çıktılarıdır ve onlara doğru bilgi sağladığınızı varsayarak risk konusunda doğru bakış açısına sahip olmaları muhtemeldir.

— Bill

5

'Serbest bırakma' veya 'serbest bırakmama' kararı, günün sonunda, katı bir risk / ödül analizinin yapılması gereken bir iş kararıdır.

Herhangi bir kuruluşun test ekibinden bu sorumluluğu üstlenmesini istemesi ya da test ekibinin bu sorumluluğu kabul etmesi çılgınca bir durumdur.

Test ekibinin rolü, yazılımın kalitesinin, piyasaya sürülmeye hazırlığının ve piyasaya sürülüp bırakılmayacağına ilişkin iş kararına girdi olarak tanımlanan risklerin bir analizini sağlamaktır.

Diğerlerinin de belirttiği gibi, _ biri _ (ve bunun bir birey olduğuna inanıyorum) 'serbest bırakma' ya da 'serbest bırakmama' kararını verme yetkisine ihtiyaç duyar. Aynı kişi bu kararı belirli koşullar altında devredebilir (yani P1 veya P2 Hatası yok)

— Ürdün
kaynak

3

Risk değerlendirildiğinde, üretimde gerçekleşmesi inanılmaz derecede olası olmayan bir sistemi kırmanın test edicilerini daha fazla ulaşan ve daha yaratıcı yollar icat eden aynı test uzmanlarıyla çalıştım.

Test ekibini kusurlu sürüm göndermek istemediğinden anlıyorum ve takdir etsem de, "kabul edilebilir risk" in ne olduğunu tanımlamak için güçlü bir ürün sahipliği gerektiriyor.

Deneyimlerime göre, test ekibine yazılımı serbest bırakma konusunda bir veto verilmelidir, ancak bu veto, ürün sahibi tarafından geçersiz kılınmalıdır, ancak yalnızca lider testçilerle tartışmadan sonra.

Yazılım asla mükemmel olmayacaktır, eğer test sürünmesinden muzdaripseniz, büyük bir üretim sorunu (doğru test edilmeyecek) olana ve koşana kadar asla hiçbir şey yayınlamayacaksınız.

— Michael
kaynak

1

Bu gerçek bir problem ama mutlaka OP'nin sorunu olup olmadığından emin değilim. Benim yorumum, testçilerin bir şekilde orijinal olarak tanımlanmamış yeni gereksinimleri yorumlamalarıdır.

— maple_shaft

2

Test ekipleriyle yaşadığım deneyim bunun diğer tarafına düşmemi sağladı. Bana göre QA, ekibin geri kalanına dava açmadan veya sahibini ekibi geçersiz kılacak şekilde dağıtmayı engelleme beklentisi olmamalıdır.

— Bill

1

Doğru - Muhtemelen yeterince açık değildim, aynı sorunlar test uzmanları kusurları yükselttiğinde ortaya çıkıyor ve aynı hikayeye yol açan "hikayenin coşkusu" nda alıntı yapıyorum - hiçbir şey yayınlanmıyor.

— Michael

Benim durumumda, bu daha çok map_shaft'ın yorumu; açıkça desteklenmeyen durumları ele almada başarısızlık bildirme olarak, yazılımı kırmanın yollarını bulmakta bu kadar sadakatsiz değil.

— Ernest Friedman-Hill

1

@ ErnestFriedman-Hill Negatif Gereklilikleri tanımladığınız anlaşılıyor ve bunlar fonksiyonel gereksinim belgelerinizde eksik olan şeyler. Negatif Bir Gereksinim, bir sistemin ne YAPAMAZ olduğuna dair açık bir ifadedir ve normal gereksinimler kadar kabul edilebilir olabilir. Bunlar beyan edilirse, Negatif Gerekliliklere karşı test davaları geçerli değildir.

— maple_shaft