Denklik Bölümlendirme

Denklik Bölümlerdirme: Program içerisine girilen değerler ile çıkış değerlerinin karşılaştırılmasına denir.

Test to Pass & Test to Fail

Tamamlanan Test: Yazılımın belirlenen test senaryolarında başarılı olduğunu gösteren durum.
Programın temel anlamda çalıştığından emin olmak.
Kapasitesini zorlamamak
Yapısını kolay ve yapıyı çok zorlamayan test durumları ile test etmek.
Programı çökertmeye çalışmamak.
Tamamlanamayan Test:
Yazılımın çalışmasını bozmak için daha komplike test durumları oluşturmak.
Yazılımın güçsüz olduğu noktaları seçmek ve buralara saldırmak.


Tartışma

Neden yazılımcı teste test to  pass ile başlar?
Zaman kaybı değil mi?
 Tess To pass’ın bize ne kazandırır?
Yazılım test uzmanı tess to pass yapmalımı?

Dinamik Black box Testi

Dinamik çünkü program çalıştırılırken yapılıyor.
Kara kutu çünkü kod ile ilgili hiçbir bilgi bilinmeden gerçekleştiriliyor.
Bu test davranış testi olarakta bilinmektedir.
Test için gerekenler
Çalışan bir program ve tanımlamalar( Kullanıcı klavuzu)
Belirlenmiş test durumları( Giriş ve değer testleri gibi)

Test Datası ve Test Durumları

Test Datası:Sistem için belirlenmiş ve seçilmiş olan  veriler.
Test Case(Durum): Belirlenmiş test senaryolarını kullanarak yazılımları çalıştırmak. Elde edilen verilere bakılarak durumları değerlendirmek.

Kara kutu testinin karakteristiği

Test Planı erkenden olmalı.
Program bir kara kutu gibi ele alınmalı.
Uygulamanın detayları sorun olmamalı.
İsterler son kullanıcı düşünülerek yapılmalı.
Kriterler kesin olamaz.

Bir hastane sisteminin oluşturulması ile ilgili isterleri belirleme.

Alt Süreç belirleme(Hasta ve Hasta istek takipleri modülü)

1.Adım: Birinci aşama(İnceleme için aktif tanımlamaları hazırla.)
Hangi kriterlere sahip olacağımızı düşün!
İyi bir yapı
Kolay
İşler için yeterli
Esnek
Pratik
Geliştirilmesi Kolay
Standardizyona sahip

2.Adım Dokümantasyonu Hazırla
Varsayımlar açık olun
Bir hastaya ait bilgileri kaydedebilirsiniz.
Bir hasta için tüm randevuları elde etmek mümkündür.
Sistem tarafından rezervasyon belirleyebilir ve randevu durumunu değiştirilebilir.
Bir  randevu aktif veya iptali durumuna karşı açıktır.
Yanlış kullanımı Varsayımlar
Randevu eklemek veya silme işleminden sonra öğeleri kaldırabilir miyim.
Randevu iptal edildiğinde, durumu tekrar aktif olarak ayarlanmış olamaz.
Bir öğe her zaman bir düzene göre eklenir.

3.Adım Tanımlamaları Belirle
Veri yeterliliği(İstenilen bütün dataların program tarafından elde edilip edilmediğine bak)
Verilerin istenilen şekilde alındığını kontrol et.


4.Adım İhtiyaçları Yorumla
Farklı bakış açıları ve uzmanlığa sahip kişiler yorumcular olarak gereklidir.
Programcılar  ve müşteriler , sisteminin diğer özellikleri üzerinde çalışmalı ve yapıyı analizetmelidir.
Programcılar ve analistler genelde hastane bilgi sistemleri ile ilgili bilgisi bulunan kişilerden olmalıdır.

5.Adım Tasarım Anketleri
Yorumcular aktif bir rol almalıdır.
Yorumcular  o ana kadar oluşturulan belgeleri kullanarak yorum oluşturmalıdırlar. Ayrıca sistem hakkındaki bilgileride kullanmalıdırlar.
İstisna durumlar var ise tasarım anketleri içerisinde belirlenmelidir.
Örneğin, yerine "oluşabilir istisnalar yazınız" her bir program için tanımlanan istisnaları var mı? "

Adım 6: Davranış inceleme
Şartname yazarları, doldurulan anketlerle inceleme ve sorularıçözmek için yorumcular ile buluşuyor.
Yorumcular gerektiği gibi özellikleri yazarlar ile toplantı, onların değerlendirmeleri tamamlandı.
Şartname yazarların belirlediği yeni sürümü üretmek.

Belirlediği nitelik kontrol listesi

Tamlık Doğruluk Hassas Tutarlılık Ilgi Fizibilite Kod / Tasarım-özgür Test edilebilir

Şartname terminoloji kontrol listesi
 
Her, hepsi, hiçbiri, hiçbir zaman her zaman ... (kesinlikle emin misin?)
Kesinlikle, bu nedenle, açıkça, belli ki, alışıldığı gibi, en ...
Bazı, bazen, sık sık, genellikle, normal koşullarda, geleneklere göre,en ... (belirsiz)
Vb, vb, vb, gibi ... (test edilebilir değil)
Hızlı İyi, ucuz, verimli, küçük, istikrarlı, ... (ölçülebilir mi?)Işlenmiş Kulplu, reddedilen atlanmış, yok ...Eğer ... sonra ... (başka eksik)


Yorumcular  için en iyi değerlendirme yeri onlara en   uygun olan  bölgelerdir.
Bu kısımlara odaklanmalıdırlar.
Bu sayede Zaman tüm katılımcılar için daha akıllıca kullanılır.
Daha fazla hata bulunması muhtemeldir.
Şartname yazarları ile Bire bir iletişim ve  konuşma çok önemlidir.
Birkaç hatanın bulunması mutlaka şartname iyi
olduğunu göstermez . (Belkide inceleme süreci etkili değildi.)

Şartnamenin Amacı

İşlenmeyen kullanıcı gereksinimleri genellikle şunlardır

Belirsiz
Çelişkili
Pratik veya uygulanması imkansız
Aşırı muğlak ifadeler
Şartnamenin amacı; hangi sistem gereksinimleri ile tasarlandığını bilmek. En az "sürpriz" ile gereksinimleri kullanışlı bir şekilde oluşturmak.

Şartname belge
Sistem geliştiricilerin kullanacakları yazılımın anlatımı içeren bir açıklama bulunmalıdır.
Sistem modelleri, gereksinimlerini tanımlama ve gereksinimleri özellikleri içermelidir.
Bir tasarım belgesi değildir.
fonksiyonel ve fonksiyonel olmayan gereksinimleri içermelidir.
Bakım için bir referans belgesi olarak hizmet vermektedir.


Şartnamedeki gereksimimler ile ilgili olarak.

Gereksinimleri değiştirmek için yapı kolay bir şekilde tasarlanmalıdır.
Sistem değişiklikleri gibi değişikliklere uygun olmalıdır.
Hangi işletim sistemi üzerinde çalışacak?
İşletim sisteminin sonraki versiyonları için uyum olacak mı?
Eskiden sahip olunan verileri dönüştürebilecek mi?

Spesifikasyon özeti

İşletin nasıl uygulanacağı ve ne şekilde yapılacağı belirlenmelidir.
Şartname’ye isterlerin doğru alınması zordur; iyi iletişim becerisi gerektirir.
Gereksinimler zaman içinde değişebilir. Yeni gereksinimler şartname içerisinde iterasyon gerektirir.
Müşteri çoğu zaman ne istediğini iyi bilmez ve kavrayamaz. Gereksinimler aşamasında oluşturulan Bugsların sonradan düzeltmek zordur.

Şartname yorumları
Şartname içerisindeki hatalar olabileceği düşüncesi ile (kusurları keşfetme amacı ile) şartname incelenmesi gerekmektedir.
Yazılım içerisinde ortaya sık çıkan hatalara dikkat edilmelidir. (Yazılım içerisinde ortaya çıkma olasılığı çoktur.)
Hataları keşfetmek için etkili yöntemdir.

Değerlendirme ve test
 
Kesin bir şartname mevcut olmalıdır.
Ekip üyeleri kuruluşun standartlara aşina olması gerekir.
Yönetim kadrosu değerlendirme için yorum kullanmamalıdır.

Belirtim incelemesi nedir?
Bir yazılım sisteminin şartnamede hataları belirleme işlemidir.

Gereksinim: Bir Bakış

Gereksinim: Bir Bakış
 
Temel amacı: Kullanıcı tarafından söylenen sorunu doğru anlamak.
Etkinlikler( Şartnamede sorun çıkartacaktır dikkat edilmelidir.)
Gereksiz ayrıntı ile şartname karmaşıklaştırılmamalıdır.
Önceden belirlediği tasarım kısıtlanmamalıdır.
Şartname yapıldıktan sonra, yazılım tasarımı yapın: çözüm odaklı olunmalı nasıl uygulamaya ne şekilde uygulayacağız sorularına ilk bakış şartname ile yapılmalı.
Gereksinimlerin düzgün olması için anahtar; yazılımcı ile müşterinin arasındaki iletişimin düzgün olmasıdır.
Kılavuz olarak hazırlanan belge varsa o belgedeki sıra ile gereksinimleri belirlemeye çalışın.


Gereksinim

Önerilen yazılım sistemi ile ilgili; tespit ve müşteri beklentilerini tam olarak belirleme sürecidir.
İki tür gereksinim
Işlevsel(Fonksiyonal): Hassas görevler veya fonksiyonlar içeren sistemler için yapmaktır. Örneğin, bir uçuş rezervasyon sisteminin ayrıntıları
Fonksiyonel olmayan(Nonfunctional): Genellikle, sistem ya da yapı üzerinde belirlenen bazı özellikler. örneğin, beklenen performans ve bellek gereksinimleri, süreç modeli kullanılmış, uygulama dil ve platform, diğer araçlar, son başvuru tarihleri ?? ile uyumluluk, ...

Şartname yapısı içerisinde neler olur?

Giriş (sistem için ihtiyaç açıklayın)
Fonksiyonel Gereksinimleri
Non-Fonksiyonel Gereksinimleri
Sistem Evolution (beklenen değişikliklerin açıklayın)
Sözlüğü (teknik ve / veya yeni jargon)
Ekler
Indeks

Çalışma Örnekleri