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:
| Duman testi | Fonksiyonel test | Entegrasyon testi |
| Sistem testi | Anlık test | Uyumluluk testi |
| Gerileme testi | Küreselleşme testi | Erişilebilirlik testi |
| Kullanılabilirlik testi | Performans testi |
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
Ö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:
…..
……
……
……
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.<
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.
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
| İşletim sistemi | Linux |
| Web sunucusu | Apaçi Tomcat |
| Uygulama sunucusu | Web küresi |
| Veritabanı sunucusu | Oracle veya MS-SQL Sunucusu |
Not: Yukarıdaki sunucular, test ekibi tarafından uygulamayı test etmek için kullanılan sunuculardır.
Müşteri
| İşletim sistemi | Windows XP, Vista 7 |
| Tarayıcılar | Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 ve Internet Explorer 8 |
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:
| İşlemci | Toplam2GHz |
| Veri deposu | 2 GB |
| …. | …. |
Not: Test ekibi olan test mühendislerinin sistemlerinin konfigürasyonunu sağlayacaktır.
……
…..
…..
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:
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.