The document discusses software testing strategies and methods. It begins by defining software testing as executing a program with artificial data to check results for errors or anomalies. It then discusses testing goals of validating that software meets requirements and discovering defects. Different testing types are covered, including black box testing which focuses on functional requirements without viewing internal program structure. Specific black box techniques like equivalence partitioning, boundary value analysis, and robustness testing are described. The document emphasizes planning a thorough testing strategy to improve software quality.

1. Systems Analysis
and Design
By : Ajeng Savitri P, M.Kom
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley

2. Testing
2

3. • Learning the definition of software testing
• Learning testing strategy
• Learning Black box testing

4. Introduction
4

6. Definition
• Testing is intended to show that a program does what it is intended to do and to
discover program defects before it is put into use.
• When you test software, you execute a program using artificial data.
• You check the results of the test run for errors, anomalies or information about
the program’s non-functional attributes.
• Can reveal the presence of errors NOT their absence.

7. Testing
Is a set of activities that can be planned in
advance and conducted systematically.
For this reason a template for software testing—a set of steps into
which you can place specific test case design techniques and testing
methods—should be defined for the software process.

8. Testing Goals
• To demonstrate to the developer and the customer that the software meets its
requirements (leads to validation testing)
• To discover situations in which the behavior of the software is incorrect,
undesirable or does not conform to its specification (leads to defect testing)

9. Verification VS Validation
• Verification:
"Are we building the product right?”.
• The software should conform to its specification.
• Validation:
"Are we building the right product?”.
• The software should do what the user really requires.

10. A Model Of The Software Testing Process

11. Software
Under Test
Test
Data
Output
Result
?
Expected ?
Not
Expected ?
Test
CaseInputs that has been
developed to test the
system Inputs to the system and the predicted outputs from
operating system in these inputs, if the system
performs to its specification

12. Testing Strategy
12

13. Testing Strategy

14. Kind of Testing
Conventional Software Testing
• White-box testing
• Basis path testing
• Control Structure Testing
• Black-box testing
Object Oriented Software Testing
• Class level testing
• Inter class testing

15. You’re never done testing;
the burden simply shifts from you (the
software engineer) to the end user

16. Strategic Issues
• Specify product requirements in a quantifiable manner long before testing
commences.
• State testing objectives explicitly
• Understand the users of the software and develop a profile for each user category.
• Develop a testing plan that emphasizes “rapid cycle testing
• Build “robust” software that is designed to test itself.
• Use effective technical reviews as a filter prior to testing
• Conduct technical reviews to assess the test strategy and test cases themselves.
• Develop a continuous improvement approach for the testing process

17. Object Oriented Software Testing
Unlike conventional test-case design, which is driven by an input-
process-output view of software or the algorithmic detail of
individual modules, object-oriented testing focuses on designing
appropriate sequences of operations to exercise the states of a class.

18. Black Box Testing
18

19. Black Box
• Disebut juga dengan pengujian perilaku (behavioral testing) atau pengujian
fungsi (functional testing)
• Fokus pada kebutuhan fungsi (functional requirement) dari PL
• Sebagai pelengkap bagi white box testing (bukan sebagai alternatif)
• Jenis :
• Pengujian klas ekivalen (equivalence class testing)
• Pengujian batas (limit testing)
• Pengujian acak (robustness testing)
• Pengujian kebutuhan (requirements testing)

20. Aspek Pengujian
• Menemukan kesalahan dalam katagori :
• Fungsi – fungsi yang tidak benar atau hilang
• Kesalahan interface
• Kesalahan dalam struktur data atau akses database eksternal
• Kesalahan kinerja
• Inisialisasi dan kesalahan terminasi/penghentian

21. Equivalence Class Testing
• Dikenal juga sebagai Pengujian Partisi Ekivalen (equivalence partitioning
testing)
• Pengujian kotak hitam yang membagi domain masukan sebuah program
menjadi klas-klas data dimana kasus uji nantinya akan diturunkan
• Satu kasus uji men-cover satu klas kesalahan
• Kumpulan data dari setiap klas data memiliki pengaruh yang sama terhadap
program
• Mengurangi jumlah kasus uji : efisiensi
• Sebuah klas ekivalen merepresentasikan sebuah kondisi masukan yg mewakili
keadaan valid atau tidak valid

22. Limit Testing
• Dikenal juga sbg. Pengujian Analisis Nilai Batas (boundary value analysis testing
- BVA)
• Pengujian kotak hitam yg. menguji nilai-nilai yang terdapat di perbatasan (limit)
• Pedoman umum - jika suatu kondisi masukan adalah sebuah rentang antara a
dan b maka kasus ujinya (2 kasus valid dan 2 kasus tidak valid)

23. Robustness Testing
• Pengujian kotak hitam dengan memasukkan nilai-nilai yang diluar dari
kebutuhan yang ditentukan (requirement)
• Tujuan : untuk membuktikan bahwa tidak ada even yang kacau (catasthropic :
hang, shutdown, dll.) pada PL dengan dimasukkannya nilai-nilai yang tidak
normal

24. Requirements Testing
• Pengujian kotak hitam yang dilakukan untuk menguji apakah kebutuhan
(requirement : functional, performance, security, dll.) yang ditentukan selama
proses analisis kebutuhan terpenuhi atau tidak
• Setiap kebutuhan harus bisa dilacak ke kasus uji dengan menggunakan
traceability matrix

25. Contoh
Black Box Testing
25

28. Terima Kasih
ajeng.savitri@tekokrat.ac.id
https://teknokrat.ac.id/en/