Yayın Sonrası Testleri Etkin Bir Şekilde Nasıl Gerçekleştirilir ve Sürümün Canlı İstemciler Üzerindeki Etkisi En Aza İndirilir

how perform post release testing effectively

Kariyerime QA olarak başladığımda, ürünlerini SaaS olarak sunan bir şirketle çalışıyordum. Üretim sürümleri kritikti ve canlı istemciler için işlevselliği etkileme olasılığı vardı.

Müşteri tabanımız büyüdükçe, riski yönetmek ve sürümün canlı müşteriler üzerindeki etkisini en aza indirmek için QA ekibi, yayın sonrası test uygulaması.

Bunların hepsi benim için yeniydi ve aklımda pek çok soru ve şüphem vardı:

• Yayın sonrası test nedir?
• Her şeyi doğru bir şekilde test ettim, neden yayın sonrası testler yapmamız gerekiyor?
• Her şeyi yeniden mi test ediyorum? Sürüm sonrası doğrulamada tam olarak ne yapmalıyım?
• Bir sorun bulursam ne olur? Vb.

Tüm yanıtlarımı ilk birkaç prodüksiyon sürümümde bulduğumu itiraf etmekten mutluluk duyuyorum.

İşte bu bilgiyi hepinizle paylaşıyorum. Size cevapları nasıl keşfettiğimi göstermek için makaleyi soru cevap formatında yazmayı seçtim.

Ne öğreneceksin:

• Üretim Sonrası Sürüm Doğrulaması nedir?
• Sürüm sonrası doğrulama aşamasına hangi görevler ve etkinlikler dahildir?
• Her şeyi baştan test etmem gerekiyor mu?
• Üretim sonrası sürüm doğrulama stratejisini nasıl formüle ederim?
• Üretim sonrası sürüm test planını kim oluşturur?
• Üretim sonrası sürüm test planını kim onaylar?
• Üretim sonrası sürüm doğrulama planını ne zaman oluşturabilirim?
• Üretim sonrası sürüm doğrulamasını tamamladım. Sıradaki ne?
• Bir sorun bulursam ne olur?
• Üretim sonrası sürüm doğrulama süreci hakkında başka ne bilmem gerekiyor?
• Sonuç:
• Önerilen Kaynaklar

Üretim Sonrası Sürüm Doğrulaması nedir?

Tanım olarak, İleti anlamına geliyor Sonra , Üretim serbestisi dağıtımı ifade eder CANLI / üretim ortamlarına ve Doğrulama içerir yayınlanan özelliklerin gereksinimleri karşıladığından emin olmak .

Önerilen okuma=> Teste başlamadan önce 'Test Ortamını' Etkili Şekilde Hazırlama

Amaç, üretim / CANLI ortamlarda sürümü doğrulamaktır.

sabit diski ssd yazılımına klonla

Ama sonra sorular ortaya çıkıyor:

• QA ortamında her şeyi test ettiğimde neden üretim sonrası sürüm testi yapmamız gerekiyor?
• Sürümü test ortamında kapsamlı bir şekilde test etmemize rağmen, neden üretimde sorun çıkacağını tahmin ediyoruz?

Tamamen takip etsek bile üretim konusunda sorun yaşamamızın birçok nedeni var. Kalite güvence süreci (yani test planlaması , test planı incelemesi, test döngüsü, regresyon testleri vb.)

Üretim konusunda sorun yaşamamızın nedenleri:

1) Veri Sorunu - Üretim ve test ortamlarına ilişkin mevcut veriler değişiklik gösterebilir. Bu, test ortamlarında bazı önemli sorunların gözden kaçmasına neden olabilir.

2) Dağıtım sorunu - Şirketinizin manuel derleme dağıtım süreci varsa, sürümünüz dağıtım sorunlarına daha yatkın olabilir. Bazı yaygın senaryolar, eksik yapılandırma veya site ayarları, eksik DB komut dosyaları, izlenmeyen dağıtım sırası (önce kod, sonra DB vb.), Yanlış kurulmuş bağımlılıklar vb. Olabilir.

Ayrıca oku=> QA Test Kullanıcısının Dağıtım süreci Hakkında Bilmesi Gerekenler

3) Tanımlanmamış etki alanları - Etkilenen alanların ekip tarafından doğru ve tam olarak belirlenemediği bazı senaryolar olabilir.

Örneğin, bir düşünün SaaS çevre.

Ekip, yeniden faktörlü bir DB tablosunun eski tablo şemasını kullanan bir istemci üzerindeki etkisini belirlemediyse (ör. Veri kaybı, ihtiyaç veri göçü vb.), vb. Bu sorunun, kesin gereksinimleri olan iyi planlanmış projelerde ortaya çıkma olasılığı daha düşüktür. Ancak olasılık hala mevcuttur.

4) Bilinmeyen Etki alanları - Bu, yayının kapsamı ve etkilenen alanları bilinmiyorsa meydana gelebilir. Örneğin, ortak DB ve mimariyi paylaşan birkaç yazılım ürününe sahip bir şirkette, küçük bir değişiklik bile birçok ürünün işlevselliğini bozabilir.

Sürüm sonrası doğrulama aşamasına hangi görevler ve etkinlikler dahildir?

Üretim sonrası sürüm görevleri ve etkinlikleri genellikle şunları içerir:

• Üretim sonrası sürüm doğrulaması
• Doğrulama sonuçlarını bildir
• Üretimde bulunan sorunları bildirme
• Yayın sonrası doğrulama verilerini temizleme
• Yayın sonrası izleme (varsa)

Her şeyi baştan test etmem gerekiyor mu?

Şart değil. Bu, yayınlanacak yapıya ve etki analizine bağlıdır.

Düzenli KG döngüsü sırasında ayrıntılı test yapılmalıdır. Yayın sonrası doğrulama, söz konusu sürüm için tam Test Planının türevi olması gereken bir Üretim sonrası sürüm doğrulama test planı izlenerek yapılmalıdır.

Üretim sonrası sürüm doğrulama stratejisini nasıl formüle ederim?

Üretim sonrası sürüm doğrulama planlamasının, normal test planlamanıza benzer şekilde yapılması gerekir.

Strateji Kalite Güvencesi döngüsü sırasında izlenen test akışı ile aynı hatlarda olmalıdır. Maksimum işlevsellik kapsamına izin veren en önemli ve kritik adımları dahil etmek önemlidir.

masaüstü desteği mülakat soruları ve cevapları

İyi bir post prodüksiyon yayın stratejisi şunları sağlamalıdır:

• Yeni özelliklerin yanı sıra önemli mevcut özellikleri test etmek için adımlar ekleyin
• Başlıca etki alanlarını doğrulayın
• Maksimum işlevsellik kapsamına izin verin
• İsteğe bağlı: Test ortamında bulunan tüm kritik hataları dahil edin
• İsteğe bağlı: Test senaryolarının önceliğini dahil edin

Üretim sonrası sürüm test planını kim oluşturur?

Bu, şirketler arasında farklılık gösterecek ve organizasyon yapısına bağlı olacaktır.

Aşağıdaki QA ekibi organizasyonuna bir örnek verelim.

Bu senaryoda, belirli bir proje üzerinde çalışan QA, ilk üretim sonrası yayın testi planını formüle edecektir.

Üretim sonrası sürüm test planını kim onaylar?

Bu, şirketler arasında farklılık gösterecek ve organizasyon yapısına bağlı olacaktır.

Yine, önceki soruda gösterilen aynı organizasyon yapısı dikkate alınarak, üretim sonrası sürüm test planı gözden geçirilmeli ve onaylanmalıdır. Test Lideri veya QA Yöneticisi .

Üretim sonrası sürüm doğrulama planını ne zaman oluşturabilirim?

Üretim sonrası sürüm test planı, gereksinimler, geliştirme kapsamı ve etki alanları belirlendikten ve kilitlendikten sonra yazılım geliştirme döngüsü sırasında herhangi bir zamanda oluşturulabilir. Kalite Güvencesi için üretim sonrası yayın test planını sprint'in ortasında oluşturmak genellikle daha kolaydır. Bu, inceleme ve onay için yeterli zamanın olmasını sağlar.

Bu test planının herhangi biriyle birlikte dahil edilmesi iyi bir uygulamadır. resmi KG imzalama belgeleri proje dağıtım ve yayın aşamasına girmeden önce.

Üretim sonrası sürüm doğrulamasını tamamladım. Sıradaki ne?

Yayın sonrası doğrulama tamamlandıktan sonra, sonraki adımlar

1) Doğrulama sonuçlarının iletilmesi - Doğrulama sonuçları, üretimde bulunan her türlü sorun dahil olmak üzere paydaşlara iletilmelidir.

2) Kusur Yönetimi aracında üretimle ilgili bulunan sorunları bildirme - kök neden analizini kolaylaştırmak ve izlenebilirlik .

3) Yayın sonrası doğrulama veri temizliği - Veri temizliğinin doğrulama tamamlandıktan sonra yapılması gerekir.

Örneğin, bir düşünün bir e-Ticaret uygulaması için sürüm ve üretim üzerinde bir test siparişi oluşturduğunuzu varsayalım. Doğrulama tamamlandıktan sonra bu test siparişinin iptal edilmesi gerekiyor.

4) Üretim sonrası yayın izleme (varsa) - Bazı sürümler üretimde izlemeyi gerektirir.

Örneğin, eğer ekip Uygulamadaki sayfa yükleme sürelerini iyileştirmek için iyileştirmeler yaptıysa, geliştirmenin gerçekten de yayınlandıktan sonra görülmesini sağlamak için bunun belirli bir süre boyunca izlenmesi gerekecektir. İzlemeden sorumlu kişi (ler) açıkça belirlenmeli ve onlara iletilmelidir.

Bir sorun bulursam ne olur?

Herhangi bir sorun şurada bildirilmelidir: Hata yönetimi aracı ve paydaşlara iletildi. Üretimle ilgili herhangi bir kritik sorun bulunursa, sorunun daha fazla araştırılması için yapının geri alınması gerekiyorsa bir karar verilmesi gerekeceğinden, sonuçların iletişimi derhal yapılmalıdır.

Bulunan tüm sorunların Kusur İzleme Aracında rapor edilmesi önemlidir. Normal kalite güvence döngüsü hatalarından ayrılmayı göstermek için bunların ayrı sorun türü (ör. Üretim Sonrası Hata) olarak gündeme getirilmesi önerilir. Bu sorunlar, kök neden analizi amacıyla gerekirse kolayca filtrelenebilir.

Üretim sonrası sürüm doğrulama süreci hakkında başka ne bilmem gerekiyor?

Gerçek üretim sonrası yayın doğrulama süreci, planı ve stratejisinin yanı sıra, aşağıda bazı ipuçları verilmiştir:

• Yayın sonrası doğrulamanın kapsamı ve amacı ile ilgili net beklentiler belirlemek önemlidir. Paydaşlar (iç ve dış) aşağıdakilerden haberdar edilmelidir:
  • Ekip üretimde her şeyi test edemez
  • Ekip, test günlerini, sürüm sonrası doğrulama için ayrılan birkaç saate sığdıramaz

Bu nedenle, üretim testi, esas olarak onaylanmış üretim sonrası sürüm test planına dayanacaktır.

Sınırlamalar:

Gerekli özen gösterilmelidir üretim sonrası sürüm testinin kapsamına karar verirken. Üretimde neyi ve ne kadarını gerçekten test edebileceğimiz konusunda sınırlamalar var. Üretim ortamı canlı müşteri verilerine sahiptir ve çok dikkatli kullanılması gerekir. Veri taşıma, güncelleme, silme vb. İçeren değişiklikler için ek planlama yapılmalıdır.

Örnek 1): Bir eSurvey şirketi için, test, ankete cevap vermeyi ve göndermeyi içeriyorsa, QA, müşteri anket toplama verilerini ve istatistiklerini etkilememek için doğrulamadan sonra test anketini silmek için bir istek göndermelidir.

DIR-DİR Örnek 2): Bir e-ticaret şirketi için, bir fiyatlandırma güncellemesinin her gün gece yarısı çalıştığını ve kesinleşmiş fiyatı web sitesine yüklediğini varsayalım. Bu SQL'i isteğe bağlı olarak, yayın sonrası doğrulama amacıyla birden çok kez çalıştıramayız çünkü bu, sonlandırılmamış verilerin üretime gönderilmesine neden olabilir.

Üstelik şansı artırabilir DB kilitlenmeleri ve en yoğun iş saatlerinde yüksek CPU ve bellek kaynakları tüketimi, istemci uygulama performansını etkileyebilir.

• Yayın sonrası testler ve ilgili tüm faaliyetler için gereken çaba dahili olmalı ve Proje Planına dahil edilmelidir. İş kurallarına ve proje özelliklerine bağlı olarak bu, proje ek yükü olarak düşünülebilir veya kalite güvence döngüsüne dahil edilebilir veya sürüm yönetim planının bir parçası olarak dahil edilebilir.
• Yayın sonrası doğrulama sırasında bildirilen sorunlar için, sorunun neden erken tespit edilmediğini ve bir dahaki sefere sorunla yüzleşmekten kaçınmak için nelerin daha iyi yapılabileceğini bulmak için temel neden analizi yapılmalıdır. Kök neden analizi, ekibin bu geçmiş sorunlardan öğrenmesine ve uygulamadaki boşlukları doldurmasına yardımcı olabilir. Organizasyon yapısına bağlı olarak, Test Lideri veya QA Yöneticisi, proje ekibinden gelen girdilerle Kök neden analizini tamamlayabilir. Bazı yaygın temel nedenler bir Kodlama sorunu, gereksinim sorunu, tasarım sorunu, veri sorunu, üçüncü taraf sınırlamaları, eksik test senaryosu vb. Olabilir. İlgili Düzeltici ve Önleyici Eylemler oluşturulabilir ve izlenebilir.
• Sunucu Günlükleri yayınlandıktan sonra yapıyı izlemek için de kullanılabilir. Sunucu günlüğü müşteri tarafından görülemeyen, ancak arka uçta sorunlara neden olabilecek olaylar veya sorunlar içerebilir. Bu izleme, Dev liderine ve DevOps ekibine bir eylem öğesi olarak atanabilir.

Bir örnek:

Projeye Genel Bakış:

Bir sosyal medya uygulamasında, özellikle de kayıt işleminde aşağıdaki değişikliklerin yapılması gerekiyor

1. Soyadı alanı doğrulamasının kaldırılması gerekiyor. Daha önce 'Soyadı en az 4 karakter olmalıdır' şeklinde uygulanmıştı (Mevcut alan için iyileştirme)
2. E-posta adresinin yanındaki geçiş düğmesini uygulayarak kullanıcının profilinde gösterilecek e-posta adresinin gizlilik ayarlarını belirleyebilmesi için (yeni özellik isteği)
3. Kullanıcı avatarını seçebilmelidir (yeni özellik isteği)
4. Uygulama performansını iyileştirmek için Kaydolma işlemi sırasında API çağrılarını azaltın (İyileştirme)

Üretim sonrası sürüm doğrulama Planı:

Sonuç:

Yazılım şirketlerinin çoğu ile artık Çevik metodolojiyi benimsemek , üretim sürümlerinin sayısı arttı.

Örneğin, kullanırken Şelale Modeli , bir takım her 1,5 ayda bir üretim sürümüne sahip olabilir, ancak Agile süreciyle aynı takım artık her 2-3 haftada bir üretim sürümüne sahip olabilir.

Her üretim sürümüyle birlikte, canlı müşterilerin işlevselliğini bilerek veya bilmeyerek etkileme olasılığımız var. Yayınlandıktan hemen sonra üretim sonrası sürüm doğrulamasının benimsenmesi, sürümle ilgili ek güven sağlayabilir, aynı zamanda canlı müşterilerimiz bazı sorunlarla karşılaşmadan önce sürümü geri almanın güvenlik ağını sağlar.

Yüksek etki / riskli projeler için üretim sonrası sürüm doğrulama planı, test senaryosunun önceliğine göre yapılandırılabilir. Öncelikle kritik öncelik testi yürütülebilir ve sonuçlar ve herhangi bir konu hakkında paydaşlara iletişim gönderilebilir. Kritik bir sorun bulunmazsa, üretim sonrası sürüm doğrulaması devam edebilir, aksi takdirde, uygulama kesinti süresini ve canlı istemcileri etkilemeyi en aza indirmek için geri alma kararının verilmesi gerekir.

Bunlara ek olarak, üretim sonrası sürüm testi otomatikleştirilebilir ve test komut dosyaları her sürümden sonra bir Regresyon testi olarak talep üzerine çalıştırılabilir. Canlı müşteri verilerini ve işlevselliğini etkileyebileceğinden, üretimde otomatik test komut dosyalarını çalıştırırken yine gerekli özen gösterilmelidir.

bulut bilişim sağlayıcıları, hizmetlerini şu şekilde sunar:

Üretim sonrası sürüm doğrulaması, son savunma hattı herhangi bir yazılım şirketi için. Sorunları yakalayamazsak, müşterilerimiz olacaktır ve bu, herhangi bir Yazılım şirketinin itibarına zarar verebilir.

Ürünün güvenilirliğini korumak için, dağıtımdan hemen sonra üretime uygulanan değişiklikleri doğrulamamız çok önemlidir.

Yazar hakkında: Bu faydalı makale Neha B tarafından yazılmıştır. Şu anda Kalite Güvence Müdürü olarak çalışmaktadır ve şirket içi ve Offshore QA ekiplerini yönetme ve yönetme konusunda uzmanlaşmıştır.

Üretim sonrası sürüm testi stratejinizi / ipuçlarınızı / deneyiminizi okuyucularımızla paylaşın.

Önerilen Kaynaklar

• En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
• Primer e-Kitap İndirmeyi Test Etme
• Üretim Sürümünden Önce Manuel Testin 7 Adımlı Pratik Uygulaması
• HP LoadRunner Öğreticileriyle Yük Testi
• Pratik Yazılım Testi QA Süreç Akışı (Yayınlanma Gereksinimleri)
• Masaüstü, İstemci Sunucu Testi ve Web Testi arasındaki fark
• Gama Testi nedir? Son Test Aşaması
• Erken Test Nedir: Erken Test Edin, Sık Sık Test Edin ANCAK Nasıl? (Pratik Bir Kılavuz)