Menü

Pratik Yazılım Testi QA Süreç Akışı (Yayınlanma Gereksinimleri)

practical software testing qa process flow

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

Uçtan Uca KG Yazılım Test Süreci Akışına Tam Bir Genel Bakış:

Not - Bu yararlı gönderiyi güncellenmiş içerikle yeniden yayınlıyoruz.

Yazılım test uzmanının işi kolay değildir. Aynı derecede zorlu olan zorluklarla doludur. Test uzmanlarının, uygulama yaşam döngüsünün her aşamasında uyanık ve hevesli olmaları beklenir.

Zorluklar olsa da, test metodolojilerinin, süreçlerinin ve elbette yazılımın çeşitli yönlerini ayrıntılı olarak öğrenmek ve keşfetmek için birçok muazzam fırsat vardır.

Bir test mühendisinin rolü çok erken başlar. Ve projenin kavramsallaştırılmasından itibaren, test uzmanları ürün sahibi, proje yöneticisi ve çeşitli paydaşlarla tartışmalara dahil olur.

Serbest Bırakma Gereksinimleri

'Yazılım Test Süreci akışı' hakkındaki bu öğretici, STLC'deki çeşitli aşamaların yanı sıra ilgili zorluklar ve bu zorlukların kolayca anlaşılabilir bir şekilde üstesinden gelmek için en iyi uygulamalar hakkında eksiksiz bir genel bakış sunar.

Ne öğreneceksin:

Serbest Bırakma Gereksinimi - Tam Bir Genel Bakış

Yazılım Testi Yaşam Döngüsü

Gereksinimden Serbest Bırakılmasına kadar her aşama net bir şekilde açıklanmıştır. Onlara ayrıntılı bir şekilde bakalım.

# 1) Gereksinim

Bir proje, açık bir gereklilik olmadan başarılı olamaz. Bu, fikirlerin iyi anlaşılabilir ve biçimlendirilmiş bir belgeye yazılması gereken en önemli aşamadır. İhtiyaç toplama aşamasına katıldığınız projenin bir parçasıysanız, kendinizi şanslı sayın.

mac'da .dat dosyası nasıl açılır

Nedenini merak etmek? Çünkü sıfırdan bir projeye şahit oluyorsunuz. Başlangıcından bu yana gurur duymakla birlikte, bazı sorumluluklar ve zorluklar da beraberinde geliyor.

Zorluklar

Tek bir oturuşta bir araya gelmek için tüm gereksinimleri hayal edemezsiniz. Yeterince sabırlı olun.

Bazıları sadece projenizle ilgisiz olabilecek ancak o zaman bile projeniz için bazı hayati bilgiler içerebilecek birçok tartışma olacak. Bazen tartışmaların hızı kavrama yeteneklerinizi aşabilir veya ürün sahibine dikkat etmezsiniz.

Aşağıdaki resim, gereksinim toplamada yer alan önemli adımları vurgulamaktadır:

Gereksinimler Yaşam Döngüsü

Kaçırılan her bilgi parçasının, projenin genel olarak anlaşılması ve test edilmesi üzerinde büyük bir etkisi vardır. Bunun üstesinden gelmek için, bu aşamada izlenmesi gereken bazı en iyi uygulamaları burada bulabilirsiniz.

En İyi Uygulamalar

  • Zihninizi açık tutun ve ürün sahibinin her kelimesine dikkat edin.
  • Ne kadar küçük görünürse görünsün sadece dinlemeyin, şüphenizi ortadan kaldırın.
  • Hızlı not tutmak için daima not defterleri kullanın. Bir dizüstü bilgisayar kullanmalısınız, ancak gerçekten makul bir hızda yazabiliyorsanız.
  • Cümleleri tekrar edin ve anladığınızı düşündüğünüz PO'dan açıklığa kavuşturun.
  • Daha sonraki bir dönemde gereksinimleri daha net hale getirmek için blok diyagramları, bağlantı metni vb. Çizin.
  • Ekipler farklı yerlerde ise, bunu bir WebEx veya benzer bir kayıt yapmaya çalışın. Tartışmalar bittikten sonra bir şüpheniz olduğunda her zaman yardımcı olacaktır.

Her aşama için ayrı bir duvar olmamasına rağmen, ihtiyaçlar çok geç gelişmelerde bile değişmektedir. Dolayısıyla fikir, gereksinimin çoğunu kapmak ve bunu doğru şekilde belgelendirmektir.

Gerekli tüm noktalar ile belgelendikten sonra, tüm paydaşları dağıtın ve tartışın, böylece herhangi bir öneri veya değişiklik erkenden yakalanır ve devam etmeden önce herkes aynı sayfada olur.

# 2) Test Stratejisi

Test uzmanlarının, yalnızca yazılımı daha iyi test etmek için yeterli olmakla kalmayıp, aynı zamanda ürünün kalitesi konusunda her paydaşta güven aşılaması gereken bir test stratejisi geliştirmeleri beklenir.

Test Stratejisi

Zorluklar

Bu aşamanın en önemli yönü, üzerinde çalışıldığında hatasız, sürdürülebilir ve son kullanıcıları tarafından kabul gören bir yazılım ürünü sunması gereken bir strateji oluşturmaktır.

Test stratejileri, her geçen gün değiştirmeyeceğiniz bir şeydir. Bazı durumlarda, test stratejilerinizi müşterilerle de görüşmeniz gerekir. Bu yüzden bu bölüm yüksek önemle ele alınmalıdır.

En iyi uygulamalar

  • Aşağıda, takip edildiğinde size büyük bir rahatlama sağlayabilecek ve sorunsuz testlerle sonuçlanabilecek en iyi uygulamalardan bazıları verilmiştir.
  • Gereksinim belgesini bir kez daha gözden geçirin. Hedef yazılımın ortamına göre içe aktarma noktalarını vurgulayın.
  • Yazılımın gerçekten konuşlandırılacağı ortamların bir listesini yapın.
  • Ortamlar, bir tür İşletim Sistemleri veya Mobil Cihazlar olarak anlaşılabilir.
  • İşletim sistemi Windows ise, yazılımınızı test edeceğiniz pencerenin tüm sürümlerini listeleyin. Sürümler yani. Windows 7, Windows 10 veya Windows Sunucuları, gereksinim belgesinde hala tanımlanmamıştır, bu durumda bunların tartışılması gereken en yüksek zamandır.
  • Benzer bir şekilde, AUT web tabanlı bir sistemse, tartışılan ve belgelenen sürümlere sahip hedef tarayıcıları edinin.
  • Uygulamanın ihtiyaç duyacağı tüm üçüncü taraf yazılımların bir listesini yapın (Gerekirse / destekleniyorsa). Bunlar Adobe Acrobat, Microsoft Office, herhangi bir eklenti vb. İçerebilir.

Burada arkasındaki fikir, kapsamlı bir stratejinin formüle edilebilmesi için uygulamamızın önümüzde çalışması gereken her gerekli ve gerekli platformu, cihazı ve yazılımı korumaktır.

Agile projesi üzerinde çalışıyorsanız aşağıdaki şekil, test stratejisinin ana hatlarını anlamanıza yardımcı olacaktır:

Test Stratejisi

# 3) Test Planlama

Test uzmanları, AUT ile ilgili tüm bilgilerle donatıldıktan sonra, planlama aşaması Stratejinin uygulandığı yerdir.

Bir test stratejisi gibi, test planlaması da çok önemli bir aşamadır.

Test planı

Zorluklar

AUT'nin başarısı (veya başarısızlığı) büyük ölçüde testlerin nasıl yapıldığına bağlı olduğundan, bu aşama tüm test yaşam döngüsünün önemli bir yönü haline gelir. Neden? Çünkü bu aşamada testin bir parçası tanımlanır.

Bazı zorlukların üstesinden gelmek için bu en iyi uygulamalar gerçekten yardımcı olabilir.

En iyi uygulamalar

  • Uygulamanızı test etmek söz konusu olduğunda herhangi bir taşı çevrilmemiş halde bırakmamayı her zaman aklınızda bulundurun.
  • Bir test stratejisi oluşturma zamanı.
  • Yazılımın tüm platformlarda test edilmesi için bir ortam matrisi oluşturun.
  • Windows 10 + Internet Explorer 11+ Windows Office 2010+ gibi.
  • Android 4.2.2+ Chrome tarayıcısı gibi.
  • Uygulamanız birden çok veritabanıyla çalışıyorsa (belgelenmişse), veritabanlarını (MySQL, Oracle, SQLServer) bazı testlerle fazla entegre olacak şekilde test matrisinde tutun.
  • Test makinelerini uygun şekilde yapılandırın ve onları Kurulum1, Kurulum2 vb. Olarak adlandırın.
  • SetUp1, Windows 7+ IE 10+ Office 2007+ sürümüne sahip olacaktır.
  • SetUp2, Windows 10+ IE Edge + Office 2013+ sürümüne sahip olabilir.
  • SetUp3, .apk dosyanızın yüklü olduğu bir Android telefona sahip olabilir.
  • Tebrikler! Test kurulumunuz hazır ve ayrıca uygulamanızın üzerinde çalışacağı olası tüm platform kombinasyonlarını dahil ettiniz.

# 4) Test Etme

Hataları Bulmak

Son olarak, uygulama derlemeniz bitti ve hataları bulmaya hazırsınız! Şimdi test planlaması üzerinde çalışma ve olabildiğince çok hata bulma zamanı. Çevik bir ortamda çalışıyorsanız, aralarında bazı aşamalar olacaktır, o zaman bu scrum yöntemlerini takip edin.

Aşağıdaki şema, çeşitli test türlerinin sınıflandırılmasını göstermektedir:

Test Türleri

Zorluklar

Test, kendi başına hataya açık olan külfetli bir süreçtir! Bir uygulamayı test ederken birçok zorluk bulunur. Kurtarma için en iyi uygulamalardan bazıları aşağıda verilmiştir.

En İyi Uygulamalar

Neşelendirmek! Koddaki hataları bulmaya çalışıyorsunuz. Yazılımın genel çalışmasına dikkat etmeniz gerekir.

  • TEST DURUMLARINA GEÇMEDEN uygulamaya her zaman yeni bir görünümle bakmanız tavsiye edilir.
  • Yazılımınızın (AUT) navigasyon yolunu takip edin.
  • AUT'ye aşina olun.
  • Şimdi herhangi bir modülün (Belki sizin seçiminize göre) test senaryolarını (Tümü) okuyun.
  • Şimdi AUT'ye gidin ve bulguları test senaryolarının beklenen bölümünde belirtilenlerle eşleştirin.
  • Bunun arkasındaki fikir, bahsedilen her özelliği desteklenen her platformda test etmektir.
  • Ne kadar önemsiz görünse de her sapmayı not edin.
  • Herhangi bir sapmaya nasıl ulaştığınıza, ekran görüntülerini nasıl aldığınıza, hata günlüklerini, sunucu günlüklerini ve kusurların varlığını kanıtlayabilecek diğer destekleyici belgeleri nasıl yakaladığınıza ilişkin adımları yazın.
  • Sormaya tereddüt etmeyin. İhtiyaç belgesine sahip olmanıza rağmen, şüphe duyacağınız zamanlar olacaktır.
  • Ürün Sahibi'ne ulaşmadan önce şüpheyle geliştiricilere (yanınızda oturuyorlarsa veya ulaşılabilirlerse) ulaşın. Yazılımın çalışmasına ilişkin geliştiricinin bakış açısını anlayın. Onları anla. Bu uygulamanın gerekliliğe uygun olmadığını düşünüyorsanız, test yöneticisini bilgilendirin.

# 5) Yayınlanmadan Önce

Herhangi bir ürünü piyasaya sürmeden önce, ürünün kalitesinin sağlanması gerekir. Yazılımlar bir kez geliştirilir, ancak değiştirilene veya kaldırılana kadar aslında test edilirler.

Zorluklar

Yazılımın birçok parametresi için titizlikle test edilmesi gerekir.

Parametreler aşağıdakilerle sınırlı olamaz:

  • İşlevsellik / Davranışsal.
  • Verim.
  • Ölçeklenebilirlik.
  • Söz konusu platformlarla uyumludur.

Zorluk ayrıca, gerçekleştirilen testin birçok yinelemesine bağlı olarak bir uygulamanın başarı oranını tahmin etmektir.

En İyi Uygulamalar

  • Tüm platformlardaki tüm özelliklerin test edildiğinden emin olun.
  • Test edilmeyen alanları veya daha fazla test çalışması gerektiren alanları vurgulayın.
  • Yayınlanmadan önce tüm test sonuçlarının bir matrisini tutun. Test matrisi, ürünün stabilitesinin genel bir resmini verecektir. Ayrıca yönetimin çıkış tarihlerinde bir telefon görüşmesi yapmasına da yardımcı olacaktır.
  • Ürünü test ederken deneyimleriniz hakkında ekibe girdi / önerilerinizi sağlayın.
  • Kendinizi son kullanıcı olarak kabul eden girdiniz yazılıma büyük ölçüde fayda sağlayacaktır.
  • Zaman sıkıntısı veya benzeri başka bir durum nedeniyle, ya bazı testleri kaçırırız ya da bu konuya derinlemesine girmeyiz. Müdürünüze test durumunu söylemekten çekinmeyin.
  • Uygulama sağlık kartını paydaşlara sunun. Sağlık kartlarında, ciddiyet ve öncelikleriyle birlikte günlüğe kaydedilmiş, açık, kapalı, aralıklı kusurların bir kısmı bulunmalıdır.
  • Bir sürüm belgesi hazırlayın ve bunu ekip içinde paylaşın.
  • Hazırlanan sürüm belgesi üzerinde çalışın.
  • Yönetim / ekip tarafından önerilen alanları iyileştirin.

Aşağıdaki resim, yazılım yayın yaşam döngüsü haritasını göstermektedir:

Yayınlanmadan Önce

# 6) Yayın

Son olarak, ürünü hedeflenen kullanıcılara teslim etmemiz gereken zaman gelir. Ekip olarak hepimiz ürünü imzalamak ve yazılımın kullanıcılarına yardım etmesine izin vermek için çok çalıştık.

Zorluklar

Yazılım test mühendisleri, herhangi bir yazılımın yayınlanmasından birincil derecede sorumludur. Bu aktivite, süreç odaklı bir iş akışı gerektirir. İşte bu aşamada yer alan en iyi uygulamalardan bazıları.

En İyi Uygulamalar

  • Her zaman unutmayın, GERÇEK SÜRÜM tarihinde sürüm belgesi üzerinde çalışmıyorsunuz.
  • Yayın etkinliğini her zaman gerçek çıkış tarihinden önce planlayın.
  • Belgeyi şirket politikalarına göre standartlaştırın.
  • Yayın belgeniz, yazılımdan olumlu beklentiler oluşturmaya çalışmalıdır.
  • Belgede, sürümlerine özgü tüm yazılım ve donanım gereksinimlerinden açıkça bahsedin.
  • Tüm açık kusurları ve bunların ciddiyetini dahil edin.
  • Açık kusurlar nedeniyle büyük etkilenen alanları gizlemeyin. Onlara Sürüm belgesinde bir yer verin.
  • Belgeyi gözden geçirin ve dijital olarak imzalayın (şirket politikasına göre farklılık gösterebilir).
  • Kendinize güvenin ve sürüm belgesini yazılımla birlikte gönderin.

Gerçek Bir Projede QA Test Süreci - Şelale Yöntemi

Bir okuyucudan ilginç bir sorum var, Bir şirkette, yani pratik bir ortamda test nasıl yapılır?

Üniversiteyi yeni bitirip iş aramaya başlayanlar bu merakı yaşıyor - bir şirketteki gerçek çalışma ortamı nasıl olurdu?

Burada gerçek çalışma sürecine odaklandım Şirketlerde Yazılım Testi .

Şirketlerde gerçek test süreci

Yeni bir proje aldığımızda ilk proje aşinalık toplantısı olur. Bu toplantıda, temel olarak müşterinin kim olduğunu tartışıyoruz? Proje süresi ne kadardır ve ne zaman teslim edilir? Projeye kimler dahil oluyor, yani yönetici, Teknoloji liderleri, QA liderleri, geliştiriciler, testçiler vb.

SRS'den (yazılım gereksinimi belirtimi) proje planı geliştirilir. Test uzmanlarının sorumluluğu, bu SRS'den ve proje planından bir yazılım test planı oluşturmaktır. Geliştiriciler kodlamaya tasarımdan başlar. Proje çalışması farklı modüllere ayrılmıştır ve bu proje modülleri geliştiriciler arasında dağıtılır.

Bu arada, bir test uzmanının sorumluluğu, bir test senaryosu oluşturmak ve atanan modüllere göre test senaryoları yazmaktır. SRS'den neredeyse tüm işlevsel test durumlarını kapsamaya çalışıyoruz. Veriler, bazı excel test senaryosu şablonlarında veya hata izleme araçlarında manuel olarak tutulabilir.

Geliştiriciler tek tek modülleri bitirdiğinde, bu modüller test uzmanlarına atanır. Bu modüllerde duman testi yapılır ve bu testte başarısız olurlarsa, modüller bir düzeltme için ilgili geliştiricilere yeniden atanır.

Başarılı modüller için, yazılı test durumlarından manuel test yapılır. Modül geliştiricisine atanan ve oturum açan herhangi bir hata bulunursa hata izleme aracı . Hata düzeltmesinde, bir test uzmanı ilgili tüm modüllerin hata doğrulamasını ve gerileme testini yapar. Hata doğrulamayı geçerse, doğrulanmış olarak işaretlenir ve kapalı olarak işaretlenir. Aksi takdirde yukarıda belirtilen hata döngüsü tekrarlanır. (Hata yaşam döngüsünü başka bir gönderide ele alacağım)

Ayrı modüller üzerinde farklı testler ve modül entegrasyonunda entegrasyon testleri gerçekleştirilir. Bu testler Uyumluluk testini, yani farklı donanım, işletim sistemi sürümleri, yazılım platformları, farklı tarayıcılar vb. Üzerindeki uygulamaları test etmeyi içerir.

Yük ve stres testleri de SRS'ye göre yapılır. Son olarak, sanal bir istemci ortamı oluşturularak sistem testi gerçekleştirilir. Tüm test senaryoları yürütüldükten sonra bir test raporu hazırlanır ve ürünün serbest bırakılmasına karar verilir!

Serbest Bırakma Gereksinimlerindeki Adımlar

Aşağıda, her bir yazılım kalitesinde gerçekleştirilen her bir test adımının ayrıntıları ve aşağıda belirtilen test yaşam döngüsü verilmiştir. IEEE ve ISO standartları.

# 1) SRS İncelemesi : Yazılım gereksinimi özelliklerinin gözden geçirilmesi.

# 2) Hedefler Büyük sürümler için ayarlanmıştır.

# 3) Hedef Tarih Sürümler için planlanmıştır.

# 4) Ayrıntılı Proje Planı inşa edildi. Bu, Tasarım Özellikleri kararını içerir.

# 5) Test Planı Geliştirin Tasarım Özelliklerine dayanmaktadır.

# 6) Test Planı: Bu, hedefleri, test sırasında benimsenen metodolojiyi, test edilecek ve test edilmeyecek özellikleri, risk kriterlerini, test programını, çoklu platform desteğini ve test için kaynak tahsisini içerir.

# 7) Test Özellikleri: Bu belge, testten önce gerekli olan teknik ayrıntıları (Yazılım gereksinimleri) içerir.

# 8) Test Vakalarının Yazılması

  • Sigara içmek ( BVT ) test durumları
  • Sanity Test vakaları
  • Regresyon Testi Durumları
  • Negatif Test Durumları
  • Genişletilmiş Test Durumları

# 9) Geliştirme: Modüller tek tek geliştirilir.

# 10) Yükleyici Bağlantısı: Kurulumcular, bireysel ürün etrafında oluşturulur.

Java'da dizge dizisi nasıl oluşturulur

#eleven) Oluşturma Prosedürü : Bir yapı, mevcut ürünlerin Yükleyicilerini içerir - birden çok platform.

# 12) Test: Duman Testi (BVT): İleri testlere karar vermek için temel uygulama testi.

  • Yeni özelliklerin test edilmesi
  • Çapraz tarayıcı ve çapraz platform testi
  • Stres testi ve bellek sızıntı testi.

# 13) Test Özeti Raporu

# 14) Kod dondurma

  • Bu noktada daha fazla yeni özellik eklenmez.

# 15) Test: Derleme ve Regresyon testi.

# 16) Ürünü serbest bırakma kararı.

# 17) Yayın sonrası senaryo daha ileri amaçlar için.

Bu, bir şirket ortamında gerçek bir test sürecinin özetiydi.

Sonuç

Bir yazılım testçisinin işi zorluklarla dolu, ancak eğlenceli bir iştir. Bu, eşit derecede tutkulu, motive ve şevk dolu biri içindir. Birinde hata bulmak her zaman kolay bir iş değildir! Bu, çok sayıda beceri ve kusurlara tam anlamıyla hakim olmayı gerektirir.

Tüm niteliklerin yanı sıra, bir test uzmanı aynı zamanda süreç odaklı olmalıdır. Diğer tüm endüstriler gibi, BT'deki projeler de her aşamanın bazı iyi tanımlanmış hedeflere sahip olduğu aşamalar halinde çalışmaktadır. Ve her hedefin iyi tanımlanmış bir kabul kriteri vardır. Bir test mühendisi omuzlarında birçok yazılım kalitesi taşımak zorundadır.

Yazılımın herhangi bir aşamasında çalışırken, test uzmanlarının en iyi uygulamaları izlemesi ve ilgili aşamalarda yer alan süreçle uyumlu olması gerekir. En iyi uygulamaları ve iyi formüle edilmiş süreci takip etmek sadece test uzmanlarının işini kolaylaştırmaya yardımcı olmakla kalmaz, aynı zamanda yazılımın kalitesini sağlamaya da yardımcı olur.

Yukarıdaki aşamalardan herhangi birinin parçası oldunuz mu? Aşağıda deneyimlerinizi paylaşmaktan çekinmeyin.

Önerilen Kaynaklar

^