Here is the fourth part of my testing blog. Define Test Subjects Since the typical application is too large to test as a whole, it is necessary to break it down into more manageable units. This breakdown can be extended several levels into sub-systems, and should be based on the testing goals and the functional units of the application. To help determine how to break down your application into test subjects, you can look at the user interface of the application, or refer to system specifications or business requirement documents. But in most cases, a familiarity with your application will suffice. Define Tests During this stage, you further break down each test subject and sub-subject into individual tests (or test cases). Each test should have a distinct objective, such as to verify a specific function or system requirement. The tests you define should be based on the testing goals you determined at the beginning of the process. You can derive tests by examining various design documents, such as data-flow diagrams (DFDs), entity relationship diagrams (ERDs), structure charts, functional specifications, business requirements, or user documentation. If no formal documentation exists, you can collect input from subject matter experts, developers, and project leaders. As a last resort, you can perform reverse engineering and write system specifications by examining the software.