TestRoot

Bir kaç arkadaş sorduda bir test plan örneği varmı diye, kendi kullandığım kullanılan şirkete uyarlandığı için örnek göstermek istemedim. Bunun yeri olması gerektiği gibi bir plan outlineı vereceğim, kendi işleyişinize göre uyarlama yapılırsa oldukça kullanışlı olabilir.

1. SCOPE
1.1 Identification
1.2 System overview
1.3 Document overview
1.4 Relationship to other plans
2. REFERENCED DOCUMENTS
3. SOFTWARE TEST ENVIRONMENT
3.x [Name of test site(s)]
3.x.1 Software items
3.x.2 Hardware and firmware items
3.x.3 Other materials
3.x.4 Proprietary nature, acquirer’s rights, and licensing
3.x.5 Installation, testing, and control
3.x.6 Participating organizations
3.x.7 Personnel
3.x.8 Orientation plan
3.x.9 Tests to be performed
4. TEST IDENTIFICATION
4.1 General information
4.1.1 Test levels
4.1.2 Test classes
4.1.3 General test conditions
4.1.4 Test progression
4.1.5 Data recording, reduction, and analysis
4.2 Planned tests
4.2.x (Item(s) to be tested)
4.2.x.y (Project-unique identifier of a test)
5. TEST SCHEDULES
6. REQUIREMENTS TRACEABILITY

Örnek üzerinden anlatırsak daha kolay olacak sanırım

Örnek kodumuz;( bu illa white box olmak zorunda değil iş kuralıda olabilir)
if (input >=10 AND input <50) then
do some
else do some thing else

Yani 10 ve 49 rakamları arasındaki inputlar valid olması gerekir, böyle bir kod için aşağıdaki hata olasılıkları mevcuttur.

input >10 AND input <50 ——-> 10 invalid olur
input <=10 AND input <50 ——-> 9 valid olur
input >=10 AND input <=50 —–> 50 valid olur
input >=10 AND input >50 —–> 49 invalid olur

Yapılan işlemin uç sınır noktaları denendiğinde tüm olasılıklar cover edilmiş olur.
Bu örnek için minumumda 9, 10, 11 ve 48, 49, 50 değerleri denendiğinde tüm olasılıklar cover edilmiş olur.

Ben neden usability test yapmıyorum derken , bir ayarayüz standardımızın olmadığını farkettim. Dolayısıyla testi gerçekleştirebilmek için bir arayüz standartı üfürmem gerekti, normalde is analistlerinin işi olmasına rağmen bişiyler salladım , hiç yoktan iyidir.
Aşağıda ki maddeler genel kavramlar olup değişik projeler için biz bu maddeyi şu şekilde gerçekliyeceğiz gibi projeye özel kararlar verilebilir.

Sayfa Düzeni
• Anasayafaya her sayfadan kolay ulaşım olmalı
• Tüm önemli tıklanabilir itemlar aynı yere konulmalı, birbirine
yakın ve sayfanın üst tarafında tahmin edilebilir bir yerde olmalı
• Önemli seçimler sayfanın üst tarafında olmalı
• Ekrandaki itemlar align edilmeli
• Fluid Layout
• Yatay scroll olmamalı
• Dikey scroll yerine paging tercih edilmeli

devamını oku…

Pazarın bugünkü durumu
Test otomasyonu yazılımları firmalara test oluşturma, testlerin koşulması ve bakımı alanlarında şu şekillerde
yardım eder:

- Skript yaratma ve geliştirme: Test otomasyonu yazılımları; kullanıcıların program kullanım şekillerini
kaydederek (record-play), manüel kodlamayla, parametre ekleyerek ve var olan hazır skriptlerin
uyarlanması ile skript yaratımını ve geliştirmesini destekler. Test otomasyonu yazılımları artık record – play
işlemini artık çok ayrıntılı (arkada skript oluşturma) bir hale getirmiştir. Kullanıcının kendisinin yazacağı bir
skriptin tabii ki de çok daha etkili olmasını beklerizfakat programlama veya skript yazmayla alakası
olmayan insanlar için araçların bu yenilikleri tamamen kullanıcı yararına gelişmektedir.

devamını oku…

Bu tabir , ful otomatik arayüz test tooları için kullanılır. Bu toollar uygulamanın nasıl kullanılacağını bilmezler, bu yüzden temel işlevi rastlantısal olarak ekran üzerinde mouse click yapmak yada yine rastlantısal olarak klavyeden input yapmak. Conduct stochastic test adı ile black box test tipinin altında sayılabilir.Bu sayade bir insanın düşünemeyeceği olasılıklarda test edilmiş oluyor .
Bu toollarında 2 çeşidi bulunmakda ;
Dumb monkeys: Düşük bir IQ seviyesiyle, testin ne durumda olduğunu bilmeden , inputların legal yada illlegal olduğu farketmeksizin girer. Bug la karşılaştığı zaman tanımlayamaz yada tekrarlıyamaz.
Smart Monkeys:Bu toollar öncekine göre biraz daha aklı başındadır, verilen state table yada modeline göre inputlar generate edip kullanır. Test altındaki uygulamanın akışına göre davranır.
Test Seviyesi
Düşünüldüğü gibi teste giren bir uygulama prod’a hatasız çıkıcak diye bir kural yoktur, test başlamadan bir seviye belirlenmeli ve bunu sağlıycak kadar teste maliyet harcanmalıdır, kısacası bu test yaparkende suyu çıkarılmamalı.
Örnek üzerinden anlatmak gerekirse , bir blog sayfasının testiyle , uzaya roket gönderdiğin bir projenin testi aynı algılanmamalı, hata durumunda oluşabilecek etkiler belirlenmeli, test de bu etkiler kabul edilebilir dereceye çekilene kadar devam etmeli. bu yüzden bi ürünü test etmeniz istendiğinde önce sorulması gerek ken şey test seviyesi ne olmalı sorusunun cevabıdır. Bu cevabı proje yöneticisinden isteyebilirsiniz ki, proje yöneticisi klanında bütün projeler çok önemli statusune girer, dolyısıyla doğru cevabı alamzsınız genelde , o zaman yapılması gereken şey proje yöneticisini kenara çekip , işi yapmak için bu cevaba ihtiyarç duyulduğunu belirtip, nasıl cevap verilebileceğine dair yönlendirmeler yapabilirsiniz. Cavaba ulaşmak için gereken bilgiler; zaman, kaynak planlaması, proje sponsorunun görüşü, müşterinin görüşü vb.. bilgiler incelenerek bir karara bağlanabilir.