Giriş
International Software Testing Qualifications Board (ISTQB) Chapter 4 - Test Design Techniques ile ilgili notlarım şöyle.
Bir önceki bölümün ismi Static Techniques. Bu bölümün de ismi "Dynamic Techniques" olmalıydı.
Test Condition
Test koşulu olarak çevrilse de aslında "test edilen şey" diye düşünmek daha iyi. Test condition'ı test etmek için birden çok "test case" geliştirilebilir.
Test Case
Test durumunda girdi ve beklenen sonuçlar (expected result) belirtilir. Testin detaylı adımları yoktur. Daha çok özet gibidir.
Test Procedure
Test adımlarının detaylı belirtimidir.
Not : İlginç olan şey ISQB'nin Test Case ve Test Procedure diye iki ayrı başlık altında sunduğu şey, bir çok şirket tarafından tek bir dokümanda hallediliyor. Şimdiye kadar hiçbir şirkette "Test Case" ve "Test Procedure" diye iki farklı dokümanın hazırlandığını görmedim.
Sıra sanırım şöyle
Test Design Techniques
Test tasarım teknikleri Static ve Dynamic olarak 2 ana gruba ayrılır. Statik teknikler Chapter 3 - Static Techniques'te anlatılıyor. Bu Chapter'da Dinamik Test Teknikleri anlatılıyor.
Dynamic Test Teknikleri
Test tekniklerinin farkını anlatan genel bir açıklama şöyle.
1. Black Box
Bu test tekniği "based on system specifications" olarak niteleniyor. Yani gereksinimlere göre test tasarlanıyor. Bu alandan mutlaka soru gelir.
1.1. Equivalance Partitions
1.2. Boundary Value Analysis
1.3. Decision Tables
1.4. State transition
1.5. Use cases
Use case testi daha sonra "Acceptance Test" için kullanılabilir. Ayrıca farklı componentler arasında entegrasyonu test etmek için de kullanılabilir.
2. Structure Based
White Box veya Structure Based Testing yazısına taşıdım
International Software Testing Qualifications Board (ISTQB) Chapter 4 - Test Design Techniques ile ilgili notlarım şöyle.
Bir önceki bölümün ismi Static Techniques. Bu bölümün de ismi "Dynamic Techniques" olmalıydı.
Test Condition
Test koşulu olarak çevrilse de aslında "test edilen şey" diye düşünmek daha iyi. Test condition'ı test etmek için birden çok "test case" geliştirilebilir.
Test Case
Test durumunda girdi ve beklenen sonuçlar (expected result) belirtilir. Testin detaylı adımları yoktur. Daha çok özet gibidir.
Test Procedure
Test adımlarının detaylı belirtimidir.
Not : İlginç olan şey ISQB'nin Test Case ve Test Procedure diye iki ayrı başlık altında sunduğu şey, bir çok şirket tarafından tek bir dokümanda hallediliyor. Şimdiye kadar hiçbir şirkette "Test Case" ve "Test Procedure" diye iki farklı dokümanın hazırlandığını görmedim.
Sıra sanırım şöyle
Test Condition -> Test Case (Expected Results) -> Prioritize Test Cases -> Test Procedure
Test Design Techniques
Test tasarım teknikleri Static ve Dynamic olarak 2 ana gruba ayrılır. Statik teknikler Chapter 3 - Static Techniques'te anlatılıyor. Bu Chapter'da Dinamik Test Teknikleri anlatılıyor.
Dynamic Test Teknikleri
Test tekniklerinin farkını anlatan genel bir açıklama şöyle.
A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used.
Bu test tekniği "based on system specifications" olarak niteleniyor. Yani gereksinimlere göre test tasarlanıyor. Bu alandan mutlaka soru gelir.
1.1. Equivalance Partitions
1.2. Boundary Value Analysis
1.3. Decision Tables
1.4. State transition
1.5. Use cases
Use case testi daha sonra "Acceptance Test" için kullanılabilir. Ayrıca farklı componentler arasında entegrasyonu test etmek için de kullanılabilir.
2. Structure Based
White Box veya Structure Based Testing yazısına taşıdım
3. Experience
Bu test tekniği "based on experience of testers" olarak niteleniyor. Belirli bir gereksinim setine dayanmıyor.
3.1 Exploratory Testing
Expoloratory Testing yazısına taşıdım.
3.2 Attacks
Saldırı. Saldırı kasten veya kaza ile olabilir. Açıklaması şöyle.
Some people enter random by accident and others do it intentionally trying to break the application. In both cases, you don't want the application to crash or exhibit other unwanted behavior.3.3 Taxonimies
For the first type of user, you don't want that because it gives them a bad experience and might turn them away.
For the second type of user, they usually don't have honorable intentions and you don't want to let them have access to information that they shouldn't be able to access or allow them to deny genuine users access to your services.
Buna dokümanda "Defect Taxonomies" de deniyor. Eş anlamlı kullanılmış. Taxonomy sınıflandırma demek. Hataları sınıflandırıp bu gruplara göre test tasarlanır.
Hiç yorum yok:
Yorum Gönder