how improve test release process
Yazılımın 'geliştirme aşaması' ndan 'test aşaması' na kadar teslim edilmesiyle ilgili tipik süreci görelim. üretim / istemciye başarılı hatasız yazılım sürümü .
Yazılım şirketleri tarafından bu süreçler ya gözden kaçar ya da atlanır, bu da zayıf test yönetimine ve dolayısıyla ' buggy 'Yazılım müşteriye yayınlanır ve bu da' tatminsiz müşteriler ”.
Buna rağmen Her sürüm için test ekibi tarafından çok fazla zaman ve büyük çaba harcanıyor Yayınlanan yazılım, tanımlandığı veya kıyaslandığı gibi kaliteye sahip olmadığında veya beklenen kriterleri karşılamadığında, yalnızca şirketin müşteriler nezdindeki itibarını etkilemekle kalmaz, aynı zamanda proje ekibinin motivasyonunu düşürür ve en önemlisi test ekibini bir bütün olarak moralini bozar. .
Bu senaryoda bir test ekibinin parçasıysanız, 'test yeteneklerimi nasıl geliştirebilirim ve bu durumun üstesinden gelmenin daha iyi bir yolu var mı' diye kendi kendinize düşünmeye devam edebilirsiniz.
Yazılım uygulamalarında ve kurumsal ürün sürümlerinde yer alan çeşitli test ekipleriyle, birden çok etki alanı ve platformda ve birden çok test çerçevesiyle ilgili deneyimlerime dayalı olarak bazı ipuçları ve önerilerde bulunmak istiyorum. test sürüm süreçleri nasıl iyileştirilir , birinci sınıf yazılımlar sunmak için bir test mühendisi veya bir test yöneticisi olarak profesyonel hayatınızı kolaylaştıracak.
Ne öğreneceksin:
- Test Yayın Süreci
- Test Yayın Süreci İyileştirme:
- Test yayın içeriğini yönetme ve kontrol etme
- Örnek Yayın Raporu Şablonu:
- Sonuç:
- Önerilen Kaynaklar
Test Yayın Süreci
Aşağıdaki tablo Giriş, İşlem ve Çıktı gibi üç evrensel aşama içeren bir test yayınlama sürecine genel bir bakış sunar.
web uygulama testi mülakat soruları ve cevapları
GİRİŞ | PROSES | ÇIKTI |
---|---|---|
7 | Kod inceleme kontrol listesi güncellendi ve VSS'de mevcut mu? | |
Önceki İşlem Geliştirme | Süreç Başlıyor • Test Sunucusunda Yayınlanan Yazılımın Kurulumu | Sonraki İşlem İhtiyaçları • Duman / Sanity Testini geçen yazılım |
Bilgi / Belge Referansı • Kullanıcı Gereksinimleri Belgesi • Yazılım Gereksinimleri Spesifikasyonları • Birim Test Planı • Kodlama Standartları • Kod İnceleme Kontrol Listesi • Kalkınma Planı • Kalite Güvence Planı • Görev tahsisi • Calisma paketi • Proje takvimi • Proje Planı • Yapılandırma Yönetim Planı • Risk yönetim Planı. | Alt Süreçler • Tüm Üniteler için Test Durumlarının Hazırlanması • Geliştirme ve Birim Testi • Uygunsuzluk Prosedürlerinin Uygulanması • Yapılandırma Yönetim Planının Uygulanması. • Risk Yönetim Planının Uygulanması • Proje İlerleme İzleme • Hata Düzeltme ve İncelemeler | İç Müşteri İhtiyaçları • Sürüm Numarası ile Yazılım Oluşturma • Sürüm Raporu • Test Durumları / Test Paketi Dokümanı • Test Yürütme Planlaması • İzlenebilirlik Matrisi • Test verisi |
Gelen Giriş Doğrulaması • Proje Belgeleri İncelendi ve Onaylandı mı? • Kodlama Standartları, Kod İnceleme Kontrol Listesi Referans için mevcut mu? • Görev Atandı ve Çalışma Paketi Güncellendi mi? • Fonksiyonel Özellikler, Geliştirme Planı ve Kalite Planı İncelendi ve Onaylandı mı? • Risk Yönetim Planında Riski ele almak için Azaltma ve Beklenmedik Durum var mı? • Ürünü Zamanında Teslim Etmek İçin Proje Programının Etkinliği? | Proses Spesifikasyonu • Birim Test Durumları tüm Giriş ve Çıkış Kriterlerinden oluşmalıdır • Kodun Kodlama Standartlarına Uyumu • NCP, Yönerge'ye göre ele alınmalıdır • Konfigürasyon Yönetimi adımları Konfigürasyon Yönetim Planına uygun olmalıdır • Risk yönetimi, Risk Yönetim Planına uygun olmalıdır • Duman Testi tüm önemli Özellikleri ve İşlevleri geçer | Dış Müşteri İhtiyaçları • Hatasız Yazılım |
Destekleyici Süreçler • İnsan / Donanım / Yazılım / Kaynak Tahsisi • Donanım Arıza Bakımı • Ekip Üyelerine Eğitim | Süreç Şununla Biter: • Yayınlanan Yapıda Duman / Sanity Testinin Yürütülmesi | Verimlilik Parametreleri • Her Birim, Testin ilk turunu geçmelidir • Proje Programına göre tamamlanacak görevler • Serbest Bırakılmadan önce Duman Testi geçilmelidir • Yazılımı Test Etme Tutkusunu Test Etme |
Her test ekibi bir benzersiz kontrol listesi yazılım sürümü için, Yazılımın etki alanı ve platformu ve proje yönetimi metodolojisi (Çevik Scrum vb. gibi) ve manuel / otomatik test çerçevesi uyarınca, zaman ve emekten tasarruf etmek için test yürütmeye başlamadan önce yayımlanan yapıyı kabul etmek.
Bu, test sürüm aşamasındaki en önemli verimlilik parametrelerinden biridir.
Test Yayın Süreci İyileştirme:
1) Sürüm Raporunu İnceleyin Yeni işlevsellik, mevcut işlevselliğin özelleştirilmesi / değiştirilmesi, Duman Testi veya Sanity Testinin veya her ikisinin bir kombinasyonunun başlatılmasına karar verecek önceki yapıdaki hata düzeltmeleri için.
iki) Güncellemeyi İnceleyin Test Belgeleri yeni işlevsellik ve hata düzeltmelerine göre, henüz güncellenmemişse. Normalde, yazılım geliştirme yaşam döngüsü boyunca bu belgeler, düzenli haftalık proje inceleme toplantılarına göre test ekibi tarafından güncellenir.
3) Yapılandırma Havuzundaki Yazılım Derlemesini İnceleyin proje planında tanımlanan standartlara göre sürüm adı ile etiketlenmiş veya yorumlanmış yapı numarası, sürüm numarası için güncellenir. Ayrıca, yapının başarıyla derlendiğinden ve test sunucusuna yüklendiğinden emin olun.
4) Yayınlandıktan Sonra Hızlı Proje İnceleme Toplantısı Planlayın yayınlanmış yapının artılarını ve eksilerini, bilinen hataları ve kritik işlevselliği vb. tartışmak, herhangi bir yanlış iletişimden kaçınmak ve önemli müşteri gereksinimlerini gözden geçirmek. Yazılım sürümünün kalitesini büyük ölçüde etkilediğinden, geliştirme ve test ekipleri arasındaki herhangi bir sözlü iletişimden kesinlikle kaçının.
5) Hata İzleme Aracının Doğru Yapılandırıldığından emin olun , tahsis edilen test ekibi ve projenin geliştirme ekibi için, yazılım oluşturma ve yayınlama numaraları ile yazılımın modülleri / işlevselliği, hataların verimli bir şekilde günlüğe kaydedilmesine yardımcı olacaktır. Değilse, yüksek öncelikli olarak proje yöneticisine veya test yöneticisine iletilmelidir.
6) Yapıyı Geliştirme Takımına Geri Verin Yapı Duman veya Sanity Testlerinde başarısız olursa hiçbir ödün vermeden. Sistem Duman Testinde başarısız olduğunda kesinlikle teste devam edilmemelidir. Bu, çok fazla zaman ve çaba tasarrufu sağlayacak ve sonraki sürümlerde yayınlanan yazılımın kalitesini artıracaktır.
7) 1'de Proje Yayınını PlanlayınstHaftanın günü Bu, test yöneticisinin gelecek test döngüsünü yapı kararlılığına göre planlamasına ve ayrıca proje yöneticisine yazılımın kalitesini çok önceden artıracak hızlı bir test raporu göndermesine yardımcı olacaktır. Geliştirme ekibi proje yayınını Cuma günü planlarsa, hafta sonu, manuel veya otomatik bir derleme çerçevesindeki herhangi bir derleme sorunlarının yanı sıra herhangi bir hata için de kullanılabilir.
8) Test Uzmanlarının Etki Alanında Uygun Şekilde Eğitildiğinden Emin Olun bu, test ekibinin test programına uymasına ve bir sonraki test turu için zaman kazanmasına yardımcı olacaktır. Ayrıca, test ekibi eğitilmeli ve proje beyaz kutu gerektiriyorsa Scripting ve SQL gibi gerekli teknolojilere maruz kalmalıdır.
9) Birden Fazla Projede Test Uzmanlarının Yerleştirilmesinden Kaçının Gerçek zamanlı olarak test yürütme kalitesini büyük ölçüde etkilediği için. Uygulamada, deneyimli test uzmanları bile özellikleri ve işlevselliği gözden kaçırır ve bazı test senaryolarının işle aşırı yüklendiğinde veya son teslim tarihleri olan birden fazla projeye tahsis edildiğinde asla başarısız olmadığını varsayarak test durumlarını atlar.
10) Test Ekibinin Tutkulu Olması İçin Takdir Edin zira test uzmanları 'Gün' için çalışmamalı veya 'Bir Gün Arayın' yorumunda bulunmamalıdır. Yazılım birden fazla modüle sahip olduğunda ve işlevselci tamamen veya kısmen entegre veya birbiriyle ilişkili olduğunda, test uzmanları, nihai yazılımın / ürünün kalitesini hedefleyen, büyük kapsam ve izlenebilirlik matrisi ile test senaryolarını yazma / yürütme tutkusuna sahip olmalıdır. Çünkü kozmetik bir sorun bile bir 'hata' dır ve '1 hata' olarak sayılır.
on bir) Yazılım Kurulumunun Kolay ve Anlaşılır Olmasını Sağlayın geliştirme yöneticisinin veya bir kurulum yöneticisinin aynı işi yapmasını beklemek yerine test ekibinin gerektiğinde yazılımı yeniden yüklemesine yardımcı olduğundan, mevcut test süresini gereksiz yere öldürür. Örneğin, Windows tabanlı kurulum kolay olsa da, ancak çok katmanlı bir test ortamında birden çok web sunucusunu ve geniş alan ağını içerdiğinde, test uzmanlarının yazılımı kurması saatler sürebilir. Eğer yazılım testi kapakları ve kurulum, kaldırma Yazılım yamaları veya güncellemeleri, test senaryolarının yürütülmesi sürecinin test ekibi ile ayrıntılı olarak tartışılması daha olasıdır.
12) Otomatik Araçların Lisansla Kullanılabilmesini Sağlayın bir ... için otomasyon test çerçevesi . Otomatikleştirilmiş araçların birden çok kullanıcı için uygun şekilde yapılandırılması ve lisanslanması koşuluyla, otomatikleştirilmiş bir çerçevede test senaryolarının yürütülmesi, manuel bir test senaryosuna kıyasla kolaydır. Özellikle, test planı, düzenli test senaryosu yürütme ve regresyon testinden ayrı olarak performans ve yük testini içerdiğinde, test uzmanları, birden çok sunucu, birden çok tarayıcı, birden çok kullanıcı vb.
13) Hayaletli Makinelerin Test İçin Ayarlandığından Emin Olun test yürütmeye başlamadan önce. Ghosted makineler, farklı test ortamlarına sahip makinelerdir. Örneğin, bir web uygulama yazılımının Chrome, Firefox, Internet Explorer gibi tüm Tarayıcılarla Windows 7 & Access DB veya Windows 2008 & SQL Server veya Windows 8 & Oracle veya Mainframe & DB2 gibi birden çok ortamda test edilmesi planlanabilir. , Safari vb. Bazı 'Sistem Testleri' hatta sabit diski tamamen formatlamayı ve yeni bir yazılım yüklemeyi veya mevcut yazılımı yamalar ve güncellemeler vb. ile güncellemeyi gerektirir.
14) Yeni Özellikleri / Değişiklik İsteğini Uygulamadan Kaçının test yürütmeyi durdurarak ve test aşamasını tekrar belirtmek için yazılımı yeniden yayınlayarak. Bu, birçok yazılım kuruluşunda, dış müşterileri tatmin etmek veya en azından yönetim yürütme komitesi veya bazen satış / pazarlama ekiplerinin taleplerini karşılamak için iş gereksinimlerine göre çok kötü bir uygulamadır. Müşterilerden gelen değişiklik talepleri her zaman 'Çevik' bir proje ortamında teşvik edilse de, yazılımın test ekibine yayınlanmasından önce uygun şekilde planlanmalı ve uygulanmalıdır.
Test yayın içeriğini yönetme ve kontrol etme
Test sürüm içeriğini yönetmek ve kontrol etmek, aşağıdaki şekilde gösterilecek olan herhangi bir BT yazılımı ve hatta BT dışı herhangi bir yazılım ortamı için çok önemlidir.
- Proje yöneticileri ve / veya proje yönlendirme komitesi, organizasyon matrisinin yetkisine bağlıdır ve her bir sürüm için içeriği seçmekten sorumludur.
- Hatalar ve / veya yeni özellikler ve müşterilerden gelen değişiklik talebi belirlendikten ve onaylandıktan sonra, geliştirme / uygulama başlamadan önce proje paydaşlarına anlatılması gereken geliştirme ekibi tarafından uygulanacaktır.
- Uygulanan son sürüme bağlı olarak, test ekibi ilgili belgeleri güncelleyecek ve buna göre teste hazırlanacaktır.
- Test ekibi, sürüm raporunda tanımlanan gereksinimlere göre Duman / Sanity testine başlayacaktır.
- Sanity geçtikten sonra, test ekibi programa ve tahsis edilen görevlere göre, yani Fonksiyonel Test, Fonksiyonel Olmayan Test, Güvenlik Testi, Sistem Testi, Performans Testi, Yük Testi, Kullanıcı Kabul Testi vb. Gibi test yürütmeye başlayacaktır.
- Test döngüsünün ilk turu tamamlandığında, test raporları bir sonraki test yürütme yinelemesini planlamak için tüm paydaşlara ve geliştirme ekibi yöneticisine gönderilecektir.
- Test raporlarının durumuna ve hata ciddiyetine ve karmaşıklığına bağlı olarak, kullanıcı kabul testiyle birlikte ikinci bir test yürütme turu veya regresyon testinin tam döngüsü planlanacaktır.
- Planlanan test yürütme döngüleri tamamlandıktan sonra, test raporları, özelliklerin, işlevlerin ve hata düzeltmelerinin başarılı / başarısız / kaçırılmış durumları için projenin tüm paydaşlarına gönderilecektir.
Örnek Yayın Raporu Şablonu:
Not : Sürüm raporu için örnek MS Word şablonu da aşağıdan indirilebilir.
Aşağıda ' Örnek Sürüm Raporu Tüm proje ekibinin profesyonel yaşamını her zamankinden çok daha mutlu kılan sürüm sürecinin ana yönlerini kapsayan ”.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Kapsam
XYZ Company Limited için GPS Navigasyon, dahili testler için piyasaya sürülüyor. Yayınlanan sürüm 1.0.7, sürüm numarası 14.0 ve yapı numarası 105.25.03. Bu yazılım sürümü, yeni özellikleri ve önceki sürümdeki başlıca hata düzeltmelerini içerir. Duman testi geliştirme aşamasından geçer, ancak Regresyon Testine gitmeden önce bir Duman ve Sanity gereklidir.
# 2) Referanslar
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Sürüm Açıklaması
Bu sürüm, GPS Navigasyonunun kontrollü bir sürümüdür ve aşağıdaki özellikleri ve işlevleri içerir.
* İle işaretlenen özellikler bu sürümde yenidir.
Aşağıdaki özellikler bu sürümde uygulanmamıştır.
1. Modül 1
1.1 Özellik 1
1.1.1 İşlevsellik 1
# 4) Yapılandırma Yönetimi
Yapılandırma yönetimi aracı olarak Visual Source Safe kullanıyoruz. Yapı aşağıdaki yolda mevcuttur.
Dahili Bağlantı: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Harici Bağlantı: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Kurulum Talimatları ve Adımları
Yapının kurulumu için ayrıntılı bilgileri QA / Testing ekibine verin.
# 6) Sorunlar / Hatalar Düzeltildi
Hata takip sisteminde hataların durumu güncellenir.
# 7) Düzeltilecek Sorunlar / Hatalar
# 8) Teslimat
# 9) Bilinen Hatalar / Sorunlar
# 10) Kontrol Listesi Yayınla
Evet Hayır / | Açıklama | E / H |
---|---|---|
1 | Tüm dosyalar Visual Source Safe'de kontrol edildi mi? | |
iki | Etiket, dahili standartlara göre VSS'de uygun klasöre yerleştirildi mi? | |
3 | Sürüm, VSS'de 'harici' / 'dahili' sürüm olarak tanımlanabilir mi? | |
4 | Yorumlarda, versiyon VSS'de belirtildi mi? | |
5 | Yorumlarda, VSS'de kısa bir açıklamadan bahsedildi mi? | |
6 | Kod gözden geçirildi ve kod gözden geçirme sorunları Clear Quest'e kaydedildi mi? | |
8 | Birim test belgesi hazırlanmış ve incelenmiş mi? | |
9 | Durum için birim test senaryoları yürütüldü ve sonuçlar güncellendi mi? | |
10 | Güncellenmiş birim test durumu belgesi VSS'de mevcut mu? | |
on bir | Bunun için yayınlanan tüm Clear Quest sorunları çözüldü / kapatıldı mı? | |
12 | VSS'de tüm iş paketi görevleri tamamlandı ve güncellendi mi? | |
13 | Duman testi yapıldı ve geçti mi? |
=> İndir: Örnek Sürüm Raporu Şablonunu İndirmek İçin Buraya Tıklayın MS Word formatında.
Sonuç:
Test Yayın Süreci Sürekli Olarak Nasıl İyileştirilir
İpucu 1) Yazılım sürümlerini ve derlemelerini sürdürmenin kritik faktörleriyle ilgilenecek ve merkezi yazılım konfigürasyon yönetim sistemlerinden sorumlu olacak bir sürüm mühendisliği ekibi kurun.
2. İpucu) Proje ekiplerini Yazılım Geliştirme Yaşam Döngüsü, Ürün Geliştirme Yaşam Döngüsü ve Yazılım Testi Yaşam Döngüsü ile ilgili süreci takip etmeleri için motive edin ve takdir edin. Süreci tanımlayabiliriz, ancak ilgili kişiler tarafından takip edilmedikçe, süreci tanımlamanın bir faydası yoktur.
3. İpucu) Deneyimlere ve önceki geçmişe dayalı olarak test çabasını tahmin edin. Test senaryoları yazmak, aynı şeyi yürütmekten tamamen farklıdır. Test uzmanları neyin test edileceğini, nasıl test edileceğini ve ne zaman test edileceğini anlamalıdır, aksi takdirde, test döngüsünün birden fazla turu gerçekleşse bile test döngüsüne verilen çabalar boşa gider.
4. İpucu) Son olarak, eğer mümkün ve uygunsa, evrensel olarak kabul edilmiş bazı test araçlarını kullanarak test aşamasını otomatikleştirin. Otomatikleştirilmiş derleme araçlarının ve otomatikleştirilmiş test araçlarının kullanımı, yazılım kalitesini% 50'den fazla artırarak test çabalarını azaltır ve otomasyon çerçevesi uygun şekilde tasarlanırsa% 100 kalite sağlar.
İpucu 5) Son fakat en az değil, test sürümü sadece bir iş değil, tüm paydaşların bir projedeki hayatını daha kolay ve daha rahat hale getirme sanatıdır.
Yazar hakkında: Balu A., Microsoft, Oracle, Java ve Mobil teknolojilerini kullanan alanlarda kurumsal uygulamalar ve mobilite çözümleri sunan yirmi yılı aşkın BT yazılım deneyimi ve on yıllık proje ve test yönetimi deneyimine sahip deneyimli bir tekno-işlevsel BT uzmanıdır. İnsanları doğru tavırla lider olmaya teşvik etme tutkusuna sahip bir liderdir ve süreç odaklı bir ortamda çalışmayı sever ve sürecin çalışan verimliliğini, kalitesini ve üretkenliğini artırdığına inanır.
İçindesonraki eğitim, öğreneceğiz - Nasıl yapılır Test Durumu Verimliliğini Artırın.
Aşağıdaki yorumlarda düşüncelerinizi / sorularınızı bize bildirin.
Süreç uyarınca bir Yazılım Sürümüne Sahip Olun!
Büyük Verimlilik ve Çabalarla Programa Göre Testleri Tamamlayın !!
Hatasız, Kalite Güvenceli Yazılım Teslimatına Ulaşmaya Çalışın !!!
Bu makaleyi beğendiyseniz arkadaşlarınızla paylaşmayı düşünün!
Önerilen Kaynaklar
- Yazılım Test Kursu: Hangi Yazılım Test Enstitüsüne katılmalıyım?
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- Yazılım Testi QA Yardımcısı İşi
- Yazılım Testinde Maymun Testi Nedir?
- Kariyeriniz olarak Yazılım Testini Seçme
- Yazılım Testi Teknik İçerik Yazarı Serbest Çalışan İş
- Örnek Hata Raporu
- Pratik Yazılım Testi QA Süreç Akışı (Yayınlanma Gereksinimleri)