Test planı, yazılım test alanlarını ve faaliyetlerini açıklayan ayrıntılı bir belgedir. Test stratejisini, hedeflerini, test programını, gerekli kaynakları (insan kaynakları, yazılım ve donanım), test tahminini ve test çıktılarını ana hatlarıyla belirtir.

Test planı her yazılımın testinin temelini oluşturur. Planlanan tüm faaliyet listelerinin uygun bir sırayla elde edilmesini sağlayan en önemli faaliyettir.

Test planı, yazılım test faaliyetlerini, test yöneticisi tarafından tamamen izlenen ve kontrol edilen, tanımlanmış bir süreç olarak yürütmek için bir şablondur. Test planı Test Lideri (%60), Test Yöneticisi (%20) ve test mühendisi (%20) tarafından hazırlanır.

Test Planı Türleri

Üç tür test planı vardır

• Ana Test Planı
• Faz Test Planı
• Test Türüne Özel Test Planları

Ana Test Planı

Ana Test Planı, birden fazla test düzeyine sahip bir test planı türüdür. Tam bir test stratejisi içerir.

Faz Test Planı

Aşama test planı, test stratejisinin herhangi bir aşamasını ele alan bir test planı türüdür. Örneğin, araçların bir listesi, test senaryolarının bir listesi vb.

Özel Test Planları

Güvenlik testi, yük testi, performans testi vb. gibi ana test türleri için tasarlanmış özel test planı. Başka bir deyişle, işlevsel olmayan testler için tasarlanmış özel bir test planı.

Test Planı nasıl yazılır?

Test planı yapmak, test yönetimi sürecinin en önemli görevidir. IEEE 829'a göre bir test planı hazırlamak için aşağıdaki yedi adımı izleyin.

• İlk olarak ürün yapısını ve mimarisini analiz edin.
• Şimdi test stratejisini tasarlayın.
• Tüm test hedeflerini tanımlayın.
• Test alanını tanımlayın.
• Kullanılabilir tüm kaynakları tanımlayın.
• Tüm faaliyetleri uygun bir şekilde planlayın.
• Tüm Test Çıktılarını belirleyin.

Test planı bileşenleri veya nitelikleri

Test planı, tüm test faaliyetini elde etmemize yardımcı olan çeşitli bölümlerden oluşur.

Hedefler: Uygulamanın amacını, yani uygulama davranışını, hedefini vb. belirten modüller, özellikler, test verileri vb. hakkında bilgilerden oluşur.

Kapsam: Bir uygulamayla ilgili olarak test edilmesi gereken bilgileri içerir. Kapsam ayrıca iki bölüme ayrılabilir:

• Kapsamında
• Kapsam dışı

Kapsamında: Bunlar titizlikle (detaylı olarak) test edilmesi gereken modüllerdir.

Kapsam dışı: Bunlar titizlikle test edilmesi gerekmeyen modüllerdir.

Örneğin , Diyelim ki test edecek bir Gmail uygulamamız var; test edilecek özellikler örneğin Posta oluşturma, Gönderilmiş Öğeler, Gelen Kutusu, Taslaklar ve test edilmeyen özellikler örneğin Yardım , vb. anlamına gelir; bu, planlama aşamasında üründe verilen zaman sınırına göre hangi işlevselliğin kontrol edilmesi gerektiğine veya kontrol edilmeyeceğine karar vereceğimiz anlamına gelir.

Şimdi Hangi özelliklerin test edilmeyeceğine nasıl karar vereceğiz?

Hangi özelliğin test edilmeyeceğine karar verebileceğimiz aşağıdaki yönlere sahibiz:

• Yukarıda gördüğümüz gibi Yardım Teknik yazar tarafından yazıp geliştirildiği ve başka bir profesyonel yazar tarafından incelendiği için özellikler test edilmeyecektir.
• sahip bir uygulamamız olduğunu varsayalım. P, Q, R ve S İhtiyaçlara göre geliştirilmesi gereken özellikler. Ancak burada S özelliği zaten başka bir şirket tarafından tasarlanıp kullanılıyor. Yani geliştirme ekibi bu şirketten S satın alacak ve P, Q ve R gibi ek özelliklerle entegre olacak.

Artık S özelliği üzerinde işlevsel testler yapmayacağız çünkü bu özellik zaten gerçek zamanlı olarak kullanılıyor. Ancak P, Q, R ve S özellikleri arasında entegrasyon testi ve sistem testi yapacağız çünkü aşağıdaki görüntüde görebileceğimiz gibi yeni özellikler S özelliğiyle düzgün çalışmayabilir:

• Ürünün ilk sürümünde geliştirilen unsurların olduğunu varsayalım. P, Q, R, S, T, U, V, W…..X, Y, Z . Artık müşteri, ikinci sürümde ürünü geliştiren yeni özellikler için gereksinimleri sağlayacak ve yeni özellikler eklenecek. A1, B2, C3, D4 ve E5.

Bundan sonra test planı sırasında kapsamı şu şekilde yazacağız:

Kapsam

Test edilecek özellikler

A1, B2, C3, D4, E5 (yeni özellikler)

P, Q, R, S, T

Test edilmeyecek özellikler

W…..X, Y, Z

Bu nedenle, önce yeni özellikleri kontrol edeceğiz ve ardından eski özelliklerle devam edeceğiz çünkü yeni özelliklerin eklenmesinden sonra bu etkilenebilir, bu da etki alanlarını da etkileyeceği anlamına gelir, dolayısıyla P, Q için bir tur regresyon testi yapacağız. , R…, T özellikleri.

Test metodolojisi:

Uygulamada İşlevsel test, Entegrasyon testi ve Sistem testi vb. gibi farklı türde testlerin gerçekleştirilmesine ilişkin bilgiler içerir. Bunda ne tür test yapılacağına karar vereceğiz; Uygulama gereksinimine göre çeşitli özellikler üzerinde performans göstereceğiz. Ve burada test terimleri standart olmadığı için yönetim, geliştirme ekibi, test ekibi gibi herkesin kolayca anlayabilmesi için test metodolojilerinde ne tür test kullanacağımızı da tanımlamalıyız.

Örneğin, gibi bağımsız uygulamalar için Adobe Photoshop aşağıdaki test türlerini gerçekleştireceğiz:

Duman testi → Fonksiyonel test → Entegrasyon testi → Sistem testi → Adhoc testi → Uyumluluk testi → Regresyon testi → Küreselleştirme testi → Erişilebilirlik testi → Kullanılabilirlik testi → Güvenilirlik testi → Kurtarma testi → Kurulum veya Kaldırma testi

Ve varsayalım ki test etmemiz gerekiyor https://www.jeevansathi.com/ Bu nedenle aşağıdaki test türlerini gerçekleştireceğiz:

Yaklaşmak

Bu öznitelik, test gerçekleştirirken ve gelecekte referans olması amacıyla uygulamanın akışını tanımlamak için kullanılır.

Uygulamanın akışını aşağıdaki hususların yardımıyla anlayabiliriz:

Üst düzey senaryolar yazarak Akış grafiğini yazarak

Üst düzey senaryolar yazarak

Örneğin varsayalım ki test ediyoruz Gmail başvuru:

• Gmail'e giriş yapın - bir e-posta gönderir ve bunun Gönderilmiş Öğeler sayfasında olup olmadığını kontrol edin
• Giriş …….
• ……
• .......

Bunu, ürünü test etmek için izlenmesi gereken yaklaşımları anlatmak ve yalnızca üst düzey senaryoları yazacağımız kritik özellikler için yazıyoruz. Burada tüm senaryoları kapsamaya odaklanmayacağız çünkü hangi özelliklerin test edilip edilmeyeceğine belirli bir test mühendisi tarafından karar verilebilir.

Akış grafiğini yazarak

Aşağıdaki resimde görebileceğimiz gibi, üst düzey senaryoların yazılması biraz zaman alan bir süreç olduğu için akış grafiği yazılmıştır:

Aşağıdaki faydaları sağlamak için akış grafikleri oluşturuyoruz:

• Kapsama kolaydır
• Birleştirme kolaydır

Yaklaşım aşağıdaki gibi iki bölüme ayrılabilir:

• Yukarıdan aşağıya yaklaşım
• Aşağıdan yukarıya yaklaşım

Varsayım

Test süreci sırasında meydana gelebilecek bir sorun veya konu hakkında bilgi içerir ve test planlarını yazarken kaynaklar ve teknolojiler vb. gibi garantili varsayımların yapılacağına dair bilgiler içerir.

Risk

Bunlar, uygulamayı mevcut sürümde test etmek için yüzleşmemiz gereken zorluklardır ve eğer varsayımlar başarısız olursa o zaman riskler de söz konusudur.

Örneğin, Bir uygulamanın etkisinden dolayı yayın tarihi ertelenir.

Etki Azaltma Planı veya Acil Durum Planı

Risklerin veya sorunların üstesinden gelmek için hazırlanan bir yedekleme planıdır.

Varsayım, risk ve acil durum planına ilişkin bir örneği bir arada görelim çünkü bunlar birbirleriyle ilişkilidir.

Herhangi bir üründe, varsayım Yapacağımız şey, 3 test mühendisinin de ürün tamamlanana kadar orada olması ve her birine P, Q ve R gibi farklı modüllerin atanmasıdır. Bu özel senaryoda, risk test mühendisi projeyi yarıda bırakırsa bu mümkün olabilir.

bu yüzden acil eylem planı her özelliğe bir birincil ve ikincil sahip atanacaktır. Yani bir test mühendisi ayrılırsa, alt sahip bu spesifik özelliği devralır ve aynı zamanda yeni test mühendisine atanan modülleri anlayabilmesi için yardımcı olur.

Varsayımlar, risk ve azaltma veya acil durum planı her zaman ürünün kendisinde kesindir. Çeşitli risk türleri aşağıdaki gibidir:

• Müşteri perspektifi
• Kaynak yaklaşımı
• Teknik görüş

rol ve sorumluluk

Tüm test ekibi tarafından gerçekleştirilmesi gereken görevin tamamını tanımlar. Büyük bir proje geldiğinde Test Yöneticisi test planını yazan kişidir. 3-4 küçük proje varsa test yöneticisi her projeyi her Test Liderine atayacaktır. Daha sonra test lideri kendisine atanan projenin test planını yazar.

Test yöneticisinin, test liderinin ve test mühendislerinin rollerini ve sorumluluklarını anlayacağımız bir örnek görelim.

Rol: Test Yöneticisi

İsim: Ryan

Sorumluluk:

• Test planını hazırlayın (yazın ve gözden geçirin)
• Geliştirme ekibiyle toplantıyı yürütmek
• Test ekibiyle toplantıyı yürütmek
• Müşteriyle toplantıyı yürütmek
• Aylık bir stand-up toplantısı düzenlemek
• Sürüm notunu imzala
• Eskalasyonları ve sorunları ele alma

Rol: Test Lideri

İsim: Harvey

Sorumluluk:

• Test planını hazırlayın (yazın ve gözden geçirin)
• Günlük stand-up toplantısı düzenlemek
• Test senaryosunu inceleyin ve onaylayın
• RTM ve Raporların Hazırlanması
• Modülleri ata
• İşleme programı

Rol: Test Mühendisi 1, Test Mühendisi 2 ve Test Mühendisi 3

İsim: Louis, Jessica, Donna

Modülleri atayın: M1, M2 ve M3

Sorumluluk:

• Test senaryosu ve test senaryolarından oluşan test belgelerini yazın, inceleyin ve yürütün
• Gereksinimi okuyun, inceleyin, anlayın ve analiz edin
• Uygulamanın akışını yazın
• Test senaryosunu yürütün
• İlgili modüller için RTM
• Kusur takibi
• Test yürütme raporunu hazırlayın ve bunu Test Liderine iletin.

Takvim

Çalışmanın zamanlamasını, hangisinin yapılması gerektiğini açıklamak için kullanılır veya bu özellik, her test faaliyetinin tam olarak ne zaman başlaması ve bitmesi gerektiğini kapsar? Ayrıca belirli bir tarih için her test faaliyeti için kesin verilerden de bahsedilir.

Bu nedenle aşağıdaki resimde görebileceğimiz gibi, belirli bir aktivite için bir başlangıç ​​tarihi ve bitiş tarihi olacaktır; Belirli bir yapıya yapılan her test için belirtilen tarih olacaktır.

Örneğin

• Test senaryolarının yazılması
• Yürütme süreci

Kusur takibi

Her bir hatanın durumunu manuel olarak takip edemediğimiz için genellikle araçlar yardımıyla yapılır. Ayrıca test sürecinde tespit edilen hataları geliştirme ekibine nasıl ileteceğimizi ve geliştirme ekibinin nasıl yanıt vereceğini de yorumluyoruz. Burada ayrıca yüksek, orta ve düşük gibi hataların önceliğinden de bahsediyoruz.

Aşağıda kusur takibinin çeşitli yönleri yer almaktadır:

Hatayı takip etme teknikleri
…..
……
……
……Hata izleme araçları
Hataları takip etmek için kullanacağımız aracın adı hakkında yorum yapabiliriz. En sık kullanılan hata izleme araçlarından bazıları Jira, Bugzilla, Mantis ve Trac vb.'dir.<Şiddet
Ciddiyet aşağıdaki gibi olabilir:
Engelleyici veya gösteri durdurucu
…..
….. (Test planında bir örnekle açıklayınız)
Örneğin modülde bir kusur olacaktır; diğer modülleri test etmek için daha ileri gidemeyiz çünkü hata engellenirse diğer modülleri kontrol etmeye devam edebiliriz.
Kritik
……
….. (Test planında bir örnekle açıklayınız)
Bu durumda kusurlar işletmeyi etkileyecektir.
Ana
….
…. (Test planında bir örnekle açıklayınız)
Küçük
…..
….. (Test planında bir örnekle açıklayınız)
Bu kusurlar uygulamanın görünüşünü ve verdiği hissi etkileyen kusurlardır.Öncelik
Yüksek-P1
…..
Orta-P2
…..
Düşük-P3
…..
…..
P4

Bu nedenle hataların yüksek, orta ve düşük önceliğine göre P1, P2, P3 ve P4 olarak sınıflandıracağız.

Test Ortamları

Bunlar uygulamayı test edeceğimiz ortamlar ve burada iki tür ortamımız var; yazılım Ve donanım konfigürasyon.

yazılım yapılandırması farklı şeylerle ilgili ayrıntılar anlamına gelir İşletim sistemleri örneğin Windows, Linux, UNIX ve Mac ve çeşitli Tarayıcılar beğenmek Google Chrome, Firefox, Opera, Internet Explorer , ve benzeri.

Ve Donanım yapılandırması farklı boyutlardaki nesneler hakkında bilgi anlamına gelir RAM, ROM ve İşlemciler .

Örneğin

• Yazılım aşağıdakileri içerir:

Sunucu

Not: Yukarıdaki sunucular, test ekibi tarafından uygulamayı test etmek için kullanılan sunuculardır.

Müşteri

Not: Yukarıdaki ayrıntılar, test ekibinin uygulamayı test edeceği çeşitli işletim sistemlerini ve tarayıcıları sağlar.

• Donanım aşağıdakileri içerir:

Sunucu : Sun StarCat 1500

Bu özel sunucu, test ekibi tarafından uygulamalarını test etmek için kullanılabilir.

Müşteri:

Aşağıdaki konfigürasyona sahiptir:

Not: Test ekibi olan test mühendislerinin sistemlerinin konfigürasyonunu sağlayacaktır.

Yazılımı yükleme işlemi
……
…..
…..

Geliştirme ekibi, yazılımın nasıl kurulacağına ilişkin yapılandırmayı sağlayacaktır. Eğer geliştirme ekibi süreci henüz sağlamayacaksa o zaman test planında Görev Tabanlı Geliştirme (TBD) olarak yazacağız.

Giriş ve Çıkış kriterleri

Test sürecini başlatmadan ve durdurmadan önce karşılanması gereken gerekli bir koşuldur.

Giriş kriterleri

Giriş kriterleri aşağıdaki koşulları içerir:

• Beyaz kutu testinin tamamlanması gerekiyor.
• Gereksinimi anlayın ve analiz edin ve test belgelerini hazırlayın veya test belgeleri hazır olduğunda.
• Test verileri hazır olmalıdır.
• Derleme veya uygulama hazırlanmalıdır
• Modüllerin veya özelliklerin farklı test mühendislerine atanması gerekir.
• Gerekli kaynağın hazır olması gerekir.

Çıkış kriteri

Çıkış kriterleri aşağıdaki koşulları içerir:

• Tüm test senaryoları yürütüldüğünde.
• Test senaryolarının çoğunun olması gerekir geçti .
• Hataların ciddiyetine bağlıdır; bu, herhangi bir engelleyici veya büyük bir hatanın olmaması gerektiği anlamına gelir, oysa bazı küçük hatalar mevcuttur.

Fonksiyonel testi gerçekleştirmeye başlamadan önce yukarıdakilerin tümü Giriş kriterleri takip edilmelidir. Fonksiyonel testi gerçekleştirdikten sonra ve entegrasyon testini yapmadan önce, Çıkış kriterleri fonksiyonel test takip edilmelidir çünkü çıkış kriterlerinin yüzdesi hem geliştirme hem de test yöneticisi ile yapılan toplantıda belirlenmektedir çünkü onların işbirliği bu yüzdeye ulaşabilir. Ancak fonksiyonel testin çıkış kriterlerine uyulmazsa entegrasyon testine geçemeyiz.

Burada ciddiyetine göre Hatanın ortadan kalkması, test ekibinin sonraki aşamalar için daha fazla ilerlemeye karar vereceği anlamına geliyor.

Test Otomasyonu

Bu konuda aşağıdakilere karar vereceğiz:

• Hangi özelliğin otomatikleştirilmesi gerekiyor ve otomatikleştirilmemesi gerekiyor?
• Hangi otomasyon çerçevesinde hangi test otomasyon aracını kullanacağız?

Test senaryosunu yalnızca ilk sürümden sonra otomatikleştiririz.

Burada şu soru ortaya çıkıyor: neye dayanarak? Biz irade Hangi özelliklerin test edilmesi gerektiğine karar veriyor musunuz?

Yukarıdaki görselde en sık kullanılan özelliklerin tekrar tekrar test edilmesi gerektiğini görmekteyiz. Temel özelliklerin bulunduğu Gmail uygulamasını kontrol etmemiz gerektiğini varsayalım. Posta, Gönderilmiş Öğeler ve Gelen Kutusu oluşturma . Dolayısıyla bu özellikleri test edeceğiz çünkü manuel test yaparken hem daha fazla zaman alıyor hem de monoton bir iş haline geliyor.

Şimdi, Hangi özelliklerin test edilmeyeceğine nasıl karar vereceğiz?

Sanmak yardım Gmail uygulamasının özelliği bu özellikler düzenli olarak kullanılmadığı için tekrar tekrar test edilmiyor dolayısıyla sık sık kontrol etmemize gerek kalmıyor.

Ancak bazı özellikler kararsızsa ve çok sayıda hata içeriyorsa Bu, manuel test yaparken tekrar tekrar test edilmesi gerektiğinden bu özellikleri test etmeyeceğimiz anlamına gelir.

Eğer sık sık test edilmesi gereken bir özellik var , ancak bu özellik için gereksinim değişikliği bekliyoruz, bu nedenle manuel test senaryolarını değiştirmek, otomasyon test komut dosyasındaki değişiklikle karşılaştırıldığında daha rahat olduğundan kontrol etmiyoruz.

Gayret tahmini

Bunda her ekip üyesinin uygulaması gereken çabayı planlayacağız.

Test Çıktısı

Bunlar ürünle birlikte müşteriye teslim ettiğimiz test ekibinin çıktısı olan belgelerdir. Aşağıdakileri içerir:

Test planı Test Durumları Test Komut Dosyaları RTM(Gereksinim İzlenebilirlik Matrisi) Kusur Raporu Test Yürütme Raporu Grafikler ve ölçümler Sürüm notları

Grafikler ve Metrikler

Grafik

Bu yazıda türleri hakkında konuşacağız. grafikler göndereceğiz ve ayrıca her grafiğin bir örneğini de sunacağız.

Görebildiğimiz gibi test sürecinin çeşitli yönlerini gösteren beş farklı grafiğimiz var.

Grafik1: Bunda her modülde kaç tane hatanın tespit edildiğini ve kaç tane hatanın giderildiğini göstereceğiz.

Grafik 2: Şekil 1, her modül için kaç tane kritik, büyük ve küçük kusurun tanımlandığını ve ilgili modüller için kaç tanesinin düzeltildiğini göstermektedir.

Grafik3: Bu özel grafikte, temsil ediyoruz akıllıca grafik oluştur Bu, her yapıda her modül için kaç tane kusurun tanımlandığı ve düzeltildiği anlamına gelir. Modül bazında hataları belirledik. ekleyeceğiz R P ve Q'daki kusur sayısını göstermek için ayrıca şunu da ekliyoruz: S P, Q ve R'deki kusurları göstermek için.

Grafik4: Test lideri şunları tasarlayacak: Hata Eğilimi analizi Her ay oluşturulan grafiğin Yönetime gönderilmesini de sağlar. Ve bu tıpkı ürünün sonunda yapılan tahmin gibidir. Ve burada şunu da yapabiliriz: hata düzeltmelerini derecelendirin bunu gözlemleyebildiğimiz gibi yay bir var yükseliş eğilimi aşağıdaki resimde.

Grafik5: Test Yöneticisi bu tür bir grafik tasarladı. Bu grafik, hataların değerlendirilmesindeki boşluğun ve meydana gelen gerçek hataların anlaşılmasını amaçlamaktadır ve bu grafik aynı zamanda gelecekte hataların değerlendirilmesinin iyileştirilmesine de yardımcı olmaktadır.

Metrikler

Yukarıdaki gibi şekil 1’deki hata dağılım grafiğini oluşturuyoruz ve yukarıda bahsettiğimiz veriler yardımıyla metrikleri de tasarlıyoruz.

Örneğin

Yukarıdaki şekilde, belirli bir projedeki tüm test mühendislerinin kayıtlarını ve kaç tane kusurun tespit edilip düzeltildiğini saklıyoruz. Bu verileri gelecekteki analizler için de kullanabiliriz. Yeni bir gereksinim geldiğinde, yukarıdaki metriklere göre daha önce buldukları kusur sayısına göre test için zorlayıcı özelliği kime sağlayacağımıza karar verebiliriz. Ve kimin problemli özellikleri çok iyi ele alabileceğini ve maksimum sayıda kusur bulabileceğini bilmek için daha iyi bir durumda olacağız.

Sürüm notu: Ürünün piyasaya çıkışı sırasında hazırlanan ve Test Yöneticisi tarafından imzalanan bir belgedir.

Aşağıdaki görüntüde nihai ürünün geliştirilip müşteriye dağıtıldığını ve en son sürüm adının şu şekilde olduğunu görebiliriz: Beta .

Sürüm notu aşağıdakilerden oluşur:

• Kullanım kılavuzu.
• Bekleyen ve açık kusurların listesi.
• Eklenen, değiştirilen ve silinen özelliklerin listesi.
• Ürünün test edildiği platformun (İşletim Sistemi, Donanım, Tarayıcılar) listesi.
• Ürünün test edilmediği platform.
• Geçerli sürümde düzeltilen hataların listesi ve önceki sürümde düzeltilen hataların listesi.
• Kurulum süreci
• Yazılımın sürümleri

Örneğin

Farz et ki Beta uygulamanın ilk sürümünden sonraki ikinci sürümüdür Alfa serbest bırakılır. İlk sürümde tespit edilen bazı kusurlar daha sonraki sürümlerde düzeltildi. Burada ayrıca alfa sürümünden beta sürümüne kadar yeni eklenen, değiştirilen ve silinen özelliklerin listesine de değineceğiz.

Şablon

Bu bölüm, üründe kullanılacak belgelere ait tüm şablonları içerir ve tüm test mühendisleri, ürünün tutarlılığını sağlamak için projede yalnızca bu şablonları kullanacaklardır. Burada, tüm test süreci boyunca kullanılan farklı şablon türlerine sahibiz:

• Test senaryosu şablonu
• Test senaryosu inceleme şablonu
• RTM Şablonu
• Hata Raporu Şablonu
• Test yürütme raporu

Bir test planı belgesi örneğini görelim

Sayfa 1

Sayfa3-sayfa18

Sayfa-20

Sayfa 1'de öncelikle yalnızca Sürümler, Yazar, Yorumlar ve İnceleyen alanları, yönetici onayladıktan sonra ayrıntıları bölümde belirteceğiz. Onaylayan ve Onay Tarihi alanlar.

Çoğunlukla test planı Test Yöneticisi tarafından onaylanır ve test mühendisleri bunu yalnızca inceler. Ve yeni özellikler geldiğinde test planında değişiklik yapıp gerekli değişikliği yapacağız. Sürüm alanı, daha sonra yöneticinin daha fazla incelemesi, güncellemesi ve onayı için tekrar gönderilecektir. Herhangi bir değişiklik meydana geldiğinde test planı güncellenmelidir. 20. sayfada, Referanslar Test planı belgesini yazmak için kullanacağımız tüm belgelerle ilgili ayrıntıları belirtin.

Not:

Test planını kim yazıyor?

• Test Ucu→%60
• Test Yöneticisi→%20
• Test Mühendisi→%20

Dolayısıyla yukarıdan da görebileceğimiz gibi ürünün %60'ında test planı Test Lideri tarafından yazılmaktadır.

Test Planını kim inceliyor?

• Test Lideri
• Test Yöneticisi
• Test mühendisi
• Müşteri
• Geliştirme Takımı

Test Mühendisi, Test planını kendi modül perspektifine göre inceler ve test yöneticisi, müşteri görüşüne göre Test planını inceler.

Test Planını kim onaylıyor?

• Müşteri
• Test Yöneticisi

Test senaryosunu kim yazıyor?

• Test Lideri
• Test mühendisi

Test senaryosunu kim inceliyor?

java'da bir dizi nasıl başlatılır

• Test mühendisi
• Test Lideri
• Müşteri
• Geliştirme Takımı

Test senaryolarını kim onaylıyor?

• Test Yöneticisi
• Test Lideri
• Müşteri

Test Planı Yönergeleri

• Test planınızı daraltın.
• Çakışmalardan ve fazlalıklardan kaçının.
• Yukarıda bahsedilen bir bölüme ihtiyacınız olmadığını düşünüyorsanız o bölümü silin ve devam edin.
• Açık ol. Örneğin, test ortamının parçası olarak bir yazılım sistemi belirttiğinizde yalnızca ad yerine yazılım sürümünü belirtin.
• Uzun paragraflardan kaçının.
• Mümkün olan her yerde listeleri ve tabloları kullanın.
• Gerektiğinde planı güncelleyin.
• Güncelliğini yitirmiş ve kullanılmamış bir belgeyi kullanmayın.

Test Planının Önemi

• Test planı düşüncemize yön verir. Bu uyulması gereken bir kural kitabı gibidir.
• Test planı, test kapsamındaki yazılım uygulamasının kalitesini doğrulamak için gerekli çabaların belirlenmesine yardımcı olur.
• Test planı, bu kişilerin geliştiriciler, işletme yöneticileri, müşteriler vb. gibi dışarıyla ilgili test ayrıntılarını anlamalarına yardımcı olur.
• Test programı, test stratejisi, test kapsamı vb. gibi önemli hususlar, yönetim ekibinin bunları inceleyebilmesi ve diğer benzer projeler için yeniden kullanabilmesi için test planında belgelenmiştir.