Menü

Yazılımın Devreye Alınması İçin Hangi Kusurların Kabul Edilebilir Olduğuna Nasıl Karar Verirsiniz?

how do you decide which defects are acceptable

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Software Go-Live, herhangi bir yazılım ürünü için her zaman büyük bir olaydır. Her şeyin çalıştığından ve bizden kesinlikle emin olmak önemlidir. kullanıcılara kaliteli yazılım yayınlamak .

Kötü veya erken veya dengesiz veya kullanımı zor bir ürün, finansal olarak çok fazla kayba neden olabilir ve ayrıca kullanıcının markaya olan güvenini kaybetmesine neden olabilir.

Çoğu zaman, çıkış kriterlerini karşılayana kadar testin yapılması gerektiğini duyarız. Ayrıca kusurların kabul edilebilir bir düzeye getirilmesi gerektiğini de duyuyoruz.

Bunlar kulağa harika gelen kurallar olsa da belirsizdirler.

yazılım hayata geçirme kriteri

Daha spesifik olmak gerekirse:

  • Yazılımın devreye girmesi için kabul edilebilir kusur yüzdesi nedir?
  • Yazılımın birlikte yaşayabileceği açık kusurlara nasıl karar veriyorsunuz?
  • Ne kusur türleri diğerlerinden daha ciddi mi?

Önerilen okuma => Testi ne zaman durdurmalı?

Hiç bu soruların oldu mu? Ardından, bu makale onlara cevap vermenize yardımcı olacak. Okumaya devam etmek…

Karmaşık yazılımlar hatasız değildir ve çalışan yazılıma göre kusurların kapatılmasına ilişkin bir tavuk ve yumurta hikayesidir.

Kusurları ne kadar çok düzeltirseniz, kusur kapatılırken yeni bir kusurun enjekte edilmesi olasılığı artar. Yani,

  • Kusurların kapsamına ve yaşayabileceğiniz kusurların türüne nasıl karar verirsiniz?
  • Yayına alınacak yazılımı nasıl temel alırsınız?
  • UAT koordinatörleri canlı yayına geçme ya da olmama çağrısını nasıl yapıyor?
  • Yazılım hangi parametrelere göre değerlendirilmelidir?
  • Nasıl cevap vereceğiz - Yazılım kullanıma uygun mu ve paydaşlara değer katacak mı?

Üretime canlı geçiş, genellikle ödeme kilometre taşlarıyla bağlantılı olduğu için hem müşteri hem de Satıcı için önemli bir kilometre taşıdır. Her ikisi de büyük dönüşüm projelerinin başarılı olmasını sağlamakta eşit sorumluluğa sahiptir.

Deneyimlerim, müşterilerin paralarının karşılığını istediklerini ve çıkış kriteri UAT'nin birlikte yaşaması için.

Söz konusu çıkış kriterleri, uygulamanın tüm alanlarında, aşağıdakiler gibi, sorunların kabul edilebilir kapsamını aşağı yukarı tanımlayacaktır:

  1. İşlevsel
  2. Performans ve Yük
  3. Kullanılabilirlik
  4. Güvenlik
  5. Dış sistemlerle entegrasyon
  6. Raporlar
  7. Veri göçü

Bu tür kusurların her birinin daha fazla açıklanması gerektiğine inanıyorum. Ve şimdi yapacağımız tam olarak bu:

Windows 10 için en iyi ücretsiz temizleme yazılımı

# 1. Fonksiyonel Kusurlar:

Yazılım, müşteri tarafından verilen teknik özelliklere göre oluşturulmuşsa, gereksinimleri karşılaması gerekir. Herhangi bir sapma, fonksiyonel kusurlar olarak kaydedilir.

Fonksiyonel kusurlar daha sonra göre sınıflandırılır önem ve öncelik .

Aşağıdakiler önemli hususlardır:

  • Yüksek önem derecesi ve öncelikli kusurlar, genellikle yazılımın günlük kullanımını etkileyecek olanlardır. Bu tür kusurlar, hayata geçirilmeden önce düzeltilmesi gereken kusurlardır. İstisna yok.
  • Bazen İşlevsel kusurlar, başlangıçta verilen gereksinimlerin bir parçası olmadığından Değişiklik İstekleri olarak sınıflandırılır. İşletmenin Devreye Alındıktan sonra çalışması için bir zorunluluk olan bu tür CR'lerin de uygulanması zorunludur.
  • Kusurların sınıflandırılması ve işlevsel kusurların önceliklendirilmesi, iş kullanıcıları ve İş analistleri ile işbirliği içinde UAT koordinatörleri tarafından yapılır. Genellikle müşterinin, kusurların% ne kadarının devreye alınmaya açık olabileceğine dair bir çıkış kriteri vardır.

# 2. Performans ve Yük Kusurları:

Performans kusurları yazılım harici kullanıcılar tarafından kullanılacaksa, yayına geçiş için ve daha fazlası için dikkate alınması önemlidir.

Yazılım belirli sayıda kullanıcı için yavaşsa, kullanıcılar yazılımı kullanmaktan kaçınırlar çünkü yüklenmesi çok zaman alır. Yazılım çok yavaşsa ve dolayısıyla iş kaybediyorsa kullanıcılar rakibin sitesine geçme eğilimindedir.

Bazen uygulamanın müşteriyle yüz yüze gelmeyen kısımları da performansı etkileyebilir.

Örneğin: Her günün sonunda çalışan bir toplu işlem varsa ve bu devam ederken uygulamanın yanıt süresi kötüleşirse, toplu işin performansı da dikkate alınması gereken bir faktördür.

  • Performans genellikle, sistemde belirli sayıda eşzamanlı kullanıcı varken ekranların görüntülenmesi ve kullanıcıların kullanımına sunulması için yanıt süresi cinsinden ölçülür.
  • Performans testleri, aşağıdaki gibi araçlar kullanılarak yapılır: LoadRunner , WebYükleme , Neoload vb.
  • Yazılımın belirli bir yükte ve gelecekteki tahmin edilen bir yükte performansı genellikle sözleşmede belgelenir ve canlıya geçmeden önce gösterilmesi gerekir.
  • Uygulamanın kullanıcılar tarafından daha az kullanılan ekranları veya bölümleri canlıya geçtikten sonra değerlendirmeye bırakılır.
  • Performans aynı zamanda donanımın türüne ve yazılımın dağıtıldığı ağ koşullarına da bağlıdır.
  • Performans testleri, belirtilen donanımda, performans araçları kullanılarak UAT sırasında yapılır ve kusurları, işlevsel kusurlara benzer bir şekilde izlenir. Bunlara da öncelik verilir ve canlıya geçiş için çıkış kriterlerinin karşılanması konusunda fikir birliğine varılır.
  • Genellikle, UAT'de performans ve yük testleri, iş kullanıcıları tarafından fonksiyonel UAT tamamlandıktan ve fonksiyonel kusurlar için kabul edilebilir bir çıkış kriterine ulaşıldıktan sonra yapılır.

# 3. Kullanılabilirlik kusurları:

Yazılım oluşturuldu son kullanıcılar tarafından kolayca kullanılabilmelidir farklı kısayol tuşları, kısayollar, minimum sayıda ekranda gezinme, sayfalandırma vb. yazılım akıllı ve sezgisel olmalıdır.

Uygun ekrana geçmeden önce sayfada çok fazla hareket varsa, kullanıcılar genellikle yazılımı kullanmaya daha az ilgi gösterir.

  • Kullanılabilirlik kılavuzları, yazılım geliştirilmeden önce oluşturulur. Yazılımın bu yönergelere uyması gerekir.
  • Yazılım oluştururken, yazılımın son kullanıcılar tarafından kullanılabilmesi için akıllıca aşılması gereken araç kısıtlamaları da olabilir.
  • Oldukça kullanışlı bir yazılımla, bir son kullanıcı normal yazılımın 5 katı kadar veri girişi yapabilir.
  • Yazılımın görünüşü ve verdiği izlenim net olmalı ve ayrıca yasal konular da canlıya geçmeden önce çözülmelidir.
  • Çoğu zaman, kullanıcılara sorunsuz bir kullanılabilirlik deneyimi sağlamak için bir kullanılabilirlik danışmanı atanır.
  • Yazılım uygulamasıyla birlikte gönderilmesi gereken belgeler, yasal olarak kullanılabildikleri için katı kullanılabilirlik kurallarına da uymalıdır.
  • UAT test uzmanları / harici test uzmanları tarafından kaydedilen kullanılabilirlik kusurları da işlevsel ve performans kusurları olarak önceliklendirilir ve canlı kullanıma geçiş için çıkış kriterlerini karşılamalıdır.

# 4. Güvenlik kusurları:

Güvenlik Yazılım uygulaması saldırıya uğrayabileceği ve müşteriye ait hassas veriler hiçbir zaman çalınamayacağı için yazılımın önemli bir sorundur.

Bu nedenle, güvenilir yazılım, çok yetkin bir bilgisayar korsanının bile uygun ayrıcalıklar olmadan uygulamaya girmesine izin vermemelidir.

  • Güvenlik testi, hacklenebilir olmadığından emin olmak için yazılıma belirli girdilerle UAT'de yapılır.
  • Güvenlik testi, yazılımın savunmasız olup olmadığını kontrol etmek için yazılımı hacklemeye çalışan yasal bilgisayar korsanları tarafından yapılır.
  • Sistem devreye girmeden önce tüm güvenlik kusurlarının kapatılması gerekir.
  • Güvenlik ayrıca uygulamaların farklı bölümlerini kullanmak ve ayrıca veri oluşturmak ve onaylamak için Oturum Açma ve çeşitli kullanıcılara (harici ve dahili) roller ve ayrıcalıklar anlamına gelir.

# 5. Harici yazılım sistemleriyle entegrasyon:

Genellikle, müşterinin sitesinde devreye alınacak bir yazılım uygulamasının, orada mevcut olabilecek herhangi bir mevcut yazılımla arayüz oluşturması gerekir.

Örneğin: Baskı sistemi ile kullanımdadırlar veya faturalama uygulaması veya veri ekran sistemleri gibi harici sistemler olabilir. Konuşlandırılan yazılım uygulaması bu harici sistemlerle sorunsuz bir şekilde entegre olmalıdır. Bu sistemlere tüm giriş ve çıkışlar senkronize olarak çalışmalıdır. Günümüz teknolojisi, mobil uygulamaları ve uygulamanın olması gereken farklı yazılım platformlarını kapsamaktadır. ile uyumlu .

Harici sistem arayüzünün kontrol edilmesi, sistem ve UAT aşamalarında kapsamlı bir şekilde yapılmalıdır. Canlıya geçmeden önce karşılanması gereken çıkış kriterlerinde bir zorunluluk olmalıdır.

# 6. Raporlar:

Yazılım uygulamasından gelen raporlar, uygulama içindeki verilerin sayılmakta olduğunu göstermenin kritik bir yoludur.

Örneğin: faturalandırmayla ilgili tüm veriler, alacak ve borç bakiyelerinde hesaplanmalıdır.

  • Yazılımdaki tüm veriler uzlaştırılmalıdır. Yazılım içindeki verilerin bu mutabakatı, raporlar aracılığıyla gösterilir ve amaçlandığı gibi çalışmalıdır.
  • Bu, özellikle eski bir sistemden yeni bir sisteme veri geçişinin mevcut sürümün birincil amacı olması durumunda geçerlidir.

# 7. Veri göçü:

Eski bir sistem yenisiyle değiştiriliyorsa, eski sistemdeki veriler yenisine taşınır (yeni sistem kullanılarak bir sonlandırma tarihine ulaşıldıktan sonra). Taşınan veriler desteklenmelidir yeni sistem tarafından ihtiyaç toplama sırasında tanımlandığı gibi.

Yeni sistemde tüm eski veriler mevcut olmayabilir; ancak, eski verilerin anlık görüntüsü yeni sistemde mevcut olabilir. Bu veriler kararlaştırıldığı şekilde mevcut olmalıdır.

Not : Yukarıdaki liste kapsamlı değildir. Uygulamanın türüne bağlı olarak, doğrulamanız gereken daha fazla şey olabilir veya yukarıdaki her şey geçerli olmayabilir. Bu nedenle, kapsamlı çıkış kriterleri geliştirmek için yazılımın, iş amacının, kullanıcı beklentilerinin ve mimari veya donanım bağımlılıklarının tam olarak anlaşılması bir zorunluluktur.

Canlı yayına geçiş için örnek bir çıkış kriteri:

Bu sadece bir örnek. Projeden projeye değişebilir.

  • Öncelik 1 kusurlarının% 100'ü kapalıdır (Önem Derecesi Kritik ve öncelik 1)
  • Öncelik 2 kusurlarının% 90'ı kapatılır (Önem derecesi yüksek ve öncelik 2), kusurların geri kalan% 10'unun geri kalanı için mantıksal bir çözüm mevcuttur. Ve kusurların geri kalan% 10'unu kapatmak için bir plan mevcuttur.
  • Üretim dağıtımı ve akıl sağlığı kontrol listesi hazır.
  • Üretim destek ekibi oluşturuldu ve biletleri kapatmaya hazır.
  • Öncelikli 3 kusurun% 70'i kapalıdır ve düşük kusurların% 30'unun geri kalanının kapatılması için bir plan mevcuttur.

Dikkat edilmesi gereken birkaç nokta:

  • Tüm önem ve öncelik tanımları, programın başlangıcında müşteri ve satıcı arasındaki iş toplantılarında kararlaştırılır.
  • Tüm UAT kusurları kaydedildikten ve diğer tüm kusurlar kapatıldıktan sonra, UAT koordinatörleri ve İşletme sponsorları, bekleyen ve açık kusurları değerlendirmek için toplanır. Gün-1'in devreye alınması için gerekli olan tüm kusurlar kapatılırsa, işletme sponsorları canlı yayına geçmeye hazır olduklarını görür ve yazılımı üretime alır.

Sonuç olarak

Umarız bu makale, yazılımı üretimdeki olası hatalardan koruyan kaya gibi sağlam çıkış kriterleri oluşturmaya giden önemli hususlardan bazıları hakkında size bazı bilgiler vermiştir.

Yazar hakkında: Bu, Krishnan Venkatraman'ın konuk makalesi. Yazılım testlerinde yaklaşık 18 yıllık deneyime sahiptir. Birçok büyük ve karmaşık yazılım test projesinde çalıştı.

Sorularınızı / yorumlarınızı aşağıya göndermekten çekinmeyin.

Önerilen Kaynaklar

^