Menü

Test Stratejisi Belgesi Nasıl Yazılır (Örnek Test Stratejisi Şablonuyla)

how write test strategy document

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

Test Stratejisi Belgesini Etkili Bir Şekilde Yazmayı Öğrenin

Test yaklaşımını, neyi başarmak istediğinizi ve bunu nasıl başaracağınızı tanımlamak için bir strateji planı.

Bu belge, test hedeflerine ulaşmak için net bir yaklaşım planıyla tüm belirsizliği veya belirsiz gereksinim ifadelerini ortadan kaldırır. Test Stratejisi, QA ekibi için en önemli belgelerden biridir.

=> Tam Test Planı Eğitim Dizisi İçin Buraya Tıklayın

Test stratejisi belgesi nasıl yazılır

Ne öğreneceksin:

Test Strateji Belgesi Yazma

Test Stratejisi

Etkili bir Test Stratejisi yazmak, her test uzmanının kariyerinde başarması gereken bir beceridir. Başlatır düşünce süreci Bu, birçok eksik gereksinimi keşfetmeye yardımcı olur. Düşünme ve test planlama faaliyetleri, bir ekibin Test kapsamını ve Test kapsamını tanımlamasına yardımcı olur.

Test yöneticilerinin herhangi bir noktada projenin net durumunu almasına yardımcı olur. Uygun bir test stratejisi mevcut olduğunda herhangi bir test aktivitesini kaçırma şansı çok düşüktür.

Herhangi bir plan olmadan test yürütme nadiren işe yarar. Strateji belgesi yazan ama testi yürütürken asla geri dönmeyen ekipler tanıyorum. Test Stratejisi planı, ekibin yaklaşım ve sorumluluklarla tutarlı olması için tüm ekip ile tartışılmalıdır.

Kısa teslim tarihlerinde, zaman baskısı nedeniyle herhangi bir test faaliyetinden feragat edemezsiniz. En azından bunu yapmadan önce resmi bir süreçten geçmesi gerekir.

Test Stratejisi Nedir?

Test stratejisi 'Uygulamayı nasıl test edeceksiniz?' Anlamına gelir. Test için başvuruyu alacağınız zaman izleyeceğiniz süreci / stratejiyi tam olarak belirtmeniz gerekir.

Pek çok şirketin Test Stratejisi şablonunu çok sıkı bir şekilde takip ettiğini görüyorum. Herhangi bir standart şablon olmasa bile, bu Test Stratejisi belgesini basit ama yine de etkili tutabilirsiniz.

Test Stratejisi Vs. Test planı

Yıllar geçtikçe, bu iki belge arasında çok fazla kafa karışıklığı görüyorum. Öyleyse temel tanımlarla başlayalım. Genelde hangisinin önce geldiğinin önemi yoktur. Test planlama belgesi, genel bir proje planı ile birleştirilen bir strateji kombinasyonudur. IEEE'ye göre Standart 829-2008, Strateji planı, bir test planının bir alt maddesidir.

Her kuruluşun bu belgeleri korumak için kendi standartları ve süreçleri vardır. Bazı kuruluşlar, test planının kendisine strateji ayrıntılarını ekler (burada iyi bir örnek bu). Bazı kuruluşlar, stratejiyi bir test planında bir alt bölüm olarak listeler, ancak ayrıntılar farklı test stratejisi belgelerinde ayrılmıştır.

Proje kapsamı ve test odağı, test planında tanımlanır. Temel olarak, test kapsamı, test edilecek özellikler, test edilmeyecek özellikler, tahmin, programlama ve kaynak yönetimi ile ilgilenir.

Test stratejisi, test hedeflerine ulaşmak ve test planında tanımlanan test türlerinin yürütülmesi için izlenecek test yaklaşımı için yönergeleri tanımlar. Test hedefleri, yaklaşım, test ortamı, otomasyon stratejisi ve araçları ve acil durum planı ile risk analizi ile ilgilenir.

Test Planını özetlemek, neyi başarmak istediğinize dair bir vizyondur ve Test Stratejisi bu vizyona ulaşmak için tasarlanmış bir eylem planıdır!

Umarım bu, tüm şüphelerinizi giderir. James Bach'ın bu konu hakkında daha fazla tartışması var İşte .

İyi Bir Test Strateji Belgesi Geliştirme Süreci

Projeniz için en iyi olanı anlamadan sadece şablonları takip etmeyin. Her müşterinin kendi gereksinimleri vardır ve sizin için mükemmel çalışan şeylere bağlı kalmanız gerekir. Herhangi bir kuruluşu veya herhangi bir standardı körü körüne kopyalamayın. Bunun size ve süreçlerinize yardımcı olup olmadığından daima emin olun.

Aşağıda, bu planda nelerin kapsanması gerektiğini özetleyen örnek bir strateji şablonu ve her bir bileşenin altında nelerin ele alınmasının mantıklı olduğunu gösteren bazı örnekler verilmiştir.

STLC'de Test Stratejisi:

STLC

(resim kaynak )

android telefon için ücretsiz mp3 indirici uygulaması

Test Stratejisi Belgesinin Ortak Bölümleri

Adım # 1: Kapsam ve Genel Bakış

Bu belgeyi kimin kullanması gerektiğine dair bilgilerle birlikte projeye genel bakış. Ayrıca, bu belgeyi kimin inceleyip onaylayacağı gibi ayrıntıları da ekleyin. Test planında tanımlanan genel proje zaman çizelgelerine göre zaman çizelgeleri ile gerçekleştirilecek test faaliyetlerini ve aşamalarını tanımlayın.

Adım # 2: Test Yaklaşımı

Her ekip üyesinin test sürecini, test düzeyini, rollerini ve sorumluluklarını tanımlayın.

Her biri için test tipi Test planında ( Örneğin, Birim , Entegrasyon, Sistem, Regresyon, Kurulum / Kaldırma , Kullanılabilirlik, Yük, Performans ve Güvenlik testi) ne zaman başlatılacağı, test sahibi, sorumluluklar, test yaklaşımı ve varsa otomasyon stratejisi ve aracın ayrıntıları gibi ayrıntılarla birlikte neden yapılması gerektiğini açıklar.

Test uygulamasında yeni hatalar ekleme, hata triyajı, hata atamaları, yeniden test etme, regresyon testi ve son olarak test imzalama gibi çeşitli etkinlikler vardır. Her aktivite için izlenecek tam adımları tanımlamalısınız. Önceki test döngülerinizde sizin için çalışan aynı süreci takip edebilirsiniz.

Bir dizi test görevlisi ve kimin hangi etkinlik üzerinde çalışacağı dahil olmak üzere tüm bu etkinliklerin bir Visio sunumu, ekipteki rolleri ve sorumlulukları hızlı bir şekilde anlamak için çok yararlıdır.

Örneğin, hata yönetimi döngüsü - yeni hatayı kaydetme sürecinden bahsedin. Nerede oturum açmalı, yeni kusurlar nasıl kaydedilir, kusur durumu ne olmalıdır, hata triyajını kim yapmalı, triyajdan sonra kusurları kime atamalı vb.

Ayrıca, değişiklik yönetimi sürecini tanımlayın. Bu, değişiklik talebi gönderiminin, kullanılacak şablonun ve talebi işleme sürecini tanımlamayı içerir.

Adım # 3: Test Ortamı

Test ortamı kurulumu, bir dizi ortam ve her ortam için gerekli kurulum hakkında bilgi vermelidir. Örneğin, İşlevsel test ekibi için bir test ortamı ve UAT ekibi için başka bir test ortamı.

Her ortamda desteklenen kullanıcı sayısını, her kullanıcı için erişim rollerini, işletim sistemi, bellek, boş disk alanı, sistem sayısı gibi yazılım ve donanım gereksinimlerini tanımlayın.

Test verisi gereksinimlerinin tanımlanması da aynı derecede önemlidir. Nasıl yapılacağına dair net talimatlar sağlayın test verisi oluştur (gizlilik için alanları maskeleyerek veri oluşturun veya üretim verilerini kullanın).

Test verisi yedekleme ve geri yükleme stratejisini tanımlayın. Test ortamı veritabanı, koddaki işlenmeyen koşullar nedeniyle sorunlarla karşılaşabilir. Tanımlanmış veritabanı yedekleme stratejisi olmadığında ve kod sorunları nedeniyle tüm veriyi kaybettiğimizde projelerden birinde karşılaştığımız sorunları hatırlıyorum.

Yedekleme ve geri yükleme işlemi, kimlerin yedeklemeleri ne zaman alacağını, veritabanını ne zaman geri yükleyeceğini, veritabanını kimin geri yükleyeceğini ve veritabanı geri yüklenirse izlenecek veri maskeleme adımlarını tanımlamalıdır.

4. Adım: Test Araçları

Test yürütme için gerekli test yönetimi ve otomasyon araçlarını tanımlayın. Performans, yük ve güvenlik testi için gerekli test yaklaşımını ve araçları tanımlayın. Açık kaynak mı yoksa ticari bir araç mı olduğunu ve kaç kullanıcının desteklendiğini belirtin ve buna göre plan yapın.

Adım # 5: Kontrolü Bırakın

Sonumuzda belirtildiği gibi UAT makalesi planlanmamış yayın döngüsü, test ve UAT ortamlarında farklı yazılım sürümlerine neden olabilir. Uygun sürüm geçmişine sahip sürüm yönetimi planı, o sürümdeki tüm değişikliklerin test yürütülmesini sağlayacaktır.

Örneğin, Yeni derlemenin nerede kullanıma sunulması, nerede devreye alınması, yeni yapının ne zaman alınacağı, üretim derlemesinin nereden alınacağı, harekete kimin geçeceği, üretim sürümü için devam sinyali verecek olan derleme yönetimi sürecini ayarlayın. , vb.

Adım # 6: Risk Analizi

Öngördüğünüz tüm riskleri listeleyin. Bu riskleri hafifletmek için net bir plan ve ayrıca bu riskleri gerçekte görüyorsanız bir acil durum planı sağlayın.

7. Adım: İnceleme ve Onaylar

Tüm bu faaliyetler test stratejisi planında tanımlandığında, proje yönetimi, iş ekibi, geliştirme ekibi ve sistem yönetimi (veya çevre yönetimi) ekibinde yer alan tüm varlıklar tarafından imzalanmak üzere gözden geçirilmesi gerekir.

İnceleme değişikliklerinin özeti belgenin başında onaylayanın adı, tarihi ve yorumu ile birlikte takip edilmelidir. Ayrıca, canlı bir belgedir, yani sürekli olarak gözden geçirilmeli ve test süreci geliştirmeleriyle güncellenmelidir.

Test Stratejisi Belgesi Yazmak İçin Basit İpuçları

  1. Test stratejisi belgesine ürün arka planını ekleyin. Test stratejisi belgenizin ilk paragrafında cevabınız - Paydaşlar neden bu projeyi geliştirmek istiyor? Bu, olayları hızlı bir şekilde anlamanıza ve önceliklendirmenize yardımcı olacaktır.
  2. Test edeceğiniz tüm önemli özellikleri listeleyin. Bazı özelliklerin bu sürümün parçası olmadığını düşünüyorsanız, bu özelliklerden 'Test edilmeyen özellikler' etiketi altında bahsedin.
  3. Projeniz için test yaklaşımını yazın. Açıkça, ne tür testler yapacağınızı belirtin?
    yani Fonksiyonel test, UI testi, Entegrasyon testi, Yük / Stres testi, Güvenlik testi vb.
  4. İşlevsel testi nasıl yapacağınız gibi soruları yanıtlayın. Manuel mi yoksa otomasyon testi mi? Test yönetim aracınızdan tüm test senaryolarını yürütecek misiniz?
  5. Hangi hata izleme aracını kullanacaksınız? Yeni bir hata bulduğunuzda süreç nasıl olacak?
  6. Test giriş ve çıkış kriterleriniz nelerdir?
  7. Test ilerlemenizi nasıl takip edeceksiniz? Testin tamamlanmasını izlemek için hangi ölçümleri kullanacaksınız?
  8. Görev dağıtımı - Her ekip üyesinin rollerini ve sorumluluklarını tanımlayın.
  9. Test aşaması sırasında ve sonrasında hangi belgeleri üreteceksiniz?
  10. Testi tamamlamada ne gibi riskler görüyorsunuz?

Sonuç

Test Stratejisi bir kağıt parçası değildir. Yazılım testi yaşam döngüsünde tüm kalite güvence faaliyetlerinin yansımasıdır. Test yürütme sürecinde bu belgeye zaman zaman başvurun ve yazılımın yayınlanmasına kadar planı izleyin.

Proje yayınlanma tarihine yaklaştığında, test stratejisi belgesinde tanımladığınız şeyleri göz ardı ederek test faaliyetlerinde kesinti yapmak oldukça kolaydır. Ancak, belirli bir faaliyette kesinti yapıp yapmayacağınızı ekibinizle görüşmeniz tavsiye edilir.

Agile ekiplerinin çoğu, takımın odak noktası dokümantasyondan ziyade test yürütme olduğu için strateji belgeleri yazmayı azaltıyor. Ancak temel bir test stratejisi planına sahip olmak her zaman projeyle ilgili riskleri net bir şekilde planlamaya ve azaltmaya yardımcı olur. Çevik ekipler, test yürütmesini herhangi bir sorun olmadan zamanında tamamlamak için tüm üst düzey etkinlikleri yakalayabilir ve belgeleyebilir.

Eminim iyi bir Test Stratejisi planı geliştirmek ve onu takip etmeyi taahhüt etmek, yazılımın test sürecini ve kalitesini kesinlikle iyileştirecektir. Bu makale, projeniz için bir Test Stratejisi planı yazmanız için size ilham verirse benim için zevk olur!

Bu gönderiyi beğendiyseniz lütfen arkadaşlarınızla paylaşmayı düşünün!

=> Tam Test Planı Eğitim Dizisi İçin Burayı Ziyaret Edin

Önerilen Kaynaklar

^