Test Objectives for Test Strategy<\/h4>\n
One of the common software testing job interviewing questions is which one is prepared first, Test Strategy or Test Plan. Other variant of this is, which is the higher level document. To me it doesn’t really matter, commonly Test Strategy is seen as subsection within Test Plan but almost equally often it is a separate document. Different organisations use these terms differently, so just make sure you ask questions to understand how to document these and how these documents are\u00a0really used for.<\/p>\n
Assuming\u00a0that the Test Strategy document is understood as over arching document for test department or test\u00a0team,\u00a0then you should consider the main Test Objectives to be preventing defects<\/strong> and assuring that the end result does meet customer business and user requirements<\/strong>.<\/p>\n Test Plan is one of the most common test team deliverable, and therefor it\u00a0is also very well documented on multitude of books, website and blogs. Similarly\u00a0IEEE 829-2008<\/b><\/a> standard defines the usual layout and content of the software test plan in detail.\u00a0Test objectives for Test plan can range from very specific to broad statements, the reason for this is that the term “Test plan” is again used in many different ways depending which organisation you work for.<\/p>\n The common test objectives for test plan are detecting software implementation deviations<\/strong> from requirements or from design specifications, which is just a fancy way of saying, finding\u00a0defects<\/strong>. Similarly a common test objective is to build confidence by providing statistical information about the level of quality<\/strong>.<\/p>\n The test plan is usually split into different test phases or levels. You might have component level test\u00a0phase and system level test\u00a0phase which are the most common ones. Each test phase usually has\u00a0specific test objectives defined. These\u00a0test objectives are commonly expressed in a way of quality targets. \u00a0Quality targets can be measured in many ways, for example as number of test cases passed \/ failed, or number of defects found in each severity group. All these aim to quantify quality in some objective statistical terms. Test Objectives for test plan should define these quality targets.\u00a0The defect density is also a very common way to measure quality within a certain component or system. The defect density is measured by dividing the total number of confirmed defects with the size of the component. Size of the component is commonly measured as lines of codes or as function points.<\/p>\n When we continue to zoom in we start to get into area what this web site is really for,\u00a0tips for writing test objectives for common User Interface elements<\/strong>.\u00a0You will most of the time\u00a0have design specifications and\/or requirement specifications available that\u00a0are used to define the test scope in your test\u00a0strategy or test plan but when it comes to the common user interface (UI) elements those are not included or not described in detailed manner. For example common UI elements like date fields, password fields or even simply monetary value field, those usually do not have any\u00a0specific requirements. There can be high level statements like, “Date should be valid” <\/em>but nothing more. This sounds OK initially, but when you really start to think about it, how do you define what is “valid”? When you ask that question from yourself, you are on the right track, because indeed there are multitude of different common test objectives\u00a0that end users expect to work, even if those are not captured in a requirement\u00a0or design specification.<\/p>\n Check out the following example\u00a0Test Objectives for common UI elements:<\/p>\nTest Objectives for Test Plan<\/h4>\n
Test Objectives for Test Phase<\/h4>\n
Test Objectives for Common elements<\/h4>\n
\n
![\"Click](\"http:\/\/www.mytipsfor.com\/writing\/testobjectives\/wp-content\/uploads\/2015\/03\/click_here.jpg\")
<\/a><\/p>\n