Certified Tester ISTOB Internationa Advanced Level Syllabus-Test Analyst Qualifications Board he d traceable back to the test basis(e.g..requirements)as Test c 。 Preconditions.such as either project or localized test environment requirements and the plans for their delivery,state of the system,etc (both ata for the test case as well as data that must exist in the ected results Post-conditions,such as affected data,state of the system,triggers for subsequent processing,etc. The level of detail of the test cases.which impacts both the cost to develop and the level of rep eatability during execution,should be defined prior to actually creating the test cases.Less detail the tes e reproducibility. is often tecpeatoeoe esult of a test.Co n idenifying the expected I result,te ers are c t only with outputs on th e screen.but alsc if th e ofy de e coverage of key areas.or missing entirely.In such cases.a Test Analyst must have.or have acces to,subject matte xpertise.Als even nere th is well-sp d,con test pracle is esse tial Test case cution without any w ay to determine correctness of res sults has a very low added value or benefit.often generating spurious failure reports or false confidence in the system The activities described above may be applied to all test levels.though the test basis will vary.For example user accep may be based primarily on the requirements specification,use cases specifications.user store and the code itseif.It is important to remember that these activities occur test levels although the rge of the test may vary. the detailed de for that ompal tes a at the tion le efifimngthatconmponentsnteractiogehe and provide functionality thro ugh their interaction. At the y shou the te ng.W helps to determine the level of detail required as well as any tools that may be needed (e.g..drivers and stubs at the component test level). During the development of test conditions and test cases.some amount of documentation is typically created, in test work products.In ly.I nis can be Standards to be followed and/or regulations to be met Lifecycle model used(e.g.,an Agile approach aims for "just enough"documentation) The requirement for traceability from the test basis through test analysis and design Version 2012 Page 14 of 64 19 October 2012Certified Tester Advanced Level Syllabus - Test Analyst International Software Testing Qualifications Board Version 2012 Page 14 of 64 19 October 2012 © International Software Testing Qualifications Board test cases should be repeatable, verifiable and traceable back to the test basis (e.g., requirements) as dictated by the test strategy that is being used. Test case design includes the identification of the following: Objective Preconditions, such as either project or localized test environment requirements and the plans for their delivery, state of the system, etc. Test data requirements (both input data for the test case as well as data that must exist in the system for the test case to be executed) Expected results Post-conditions, such as affected data, state of the system, triggers for subsequent processing, etc. The level of detail of the test cases, which impacts both the cost to develop and the level of repeatability during execution, should be defined prior to actually creating the test cases. Less detail in the test case allows the Test Analyst more flexibility when executing the test case and provides an opportunity to investigate potentially interesting areas. Less detail, however, also tends to lead to less reproducibility. A particular challenge is often the definition of the expected result of a test. Computing this manually is often tedious and error-prone; if possible, it is preferable to find or create an automated test oracle. In identifying the expected result, testers are concerned not only with outputs on the screen, but also with data and environmental post-conditions. If the test basis is clearly defined, identifying the correct result, theoretically, should be simple. However, test bases are often vague, contradictory, lacking coverage of key areas, or missing entirely. In such cases, a Test Analyst must have, or have access to, subject matter expertise. Also, even where the test basis is well-specified, complex interactions of complex stimuli and responses can make the definition of the expected results difficult; therefore, a test oracle is essential. Test case execution without any way to determine correctness of results has a very low added value or benefit, often generating spurious failure reports or false confidence in the system. The activities described above may be applied to all test levels, though the test basis will vary. For example, user acceptance tests may be based primarily on the requirements specification, use cases and defined business processes, while component tests may be based primarily on low-level design specifications, user stories and the code itself. It is important to remember that these activities occur throughout all the test levels although the target of the test may vary. For example, functional testing at the unit level is designed to ensure that a particular component provides the functionality as specified in the detailed design for that component. Functional testing at the integration level is verifying that components interact together and provide functionality through their interaction. At the system level, end to end functionality should be a target of the testing. When analyzing and designing tests, it is important to remember the target level for the test as well as the objective of the test. This helps to determine the level of detail required as well as any tools that may be needed (e.g., drivers and stubs at the component test level). During the development of test conditions and test cases, some amount of documentation is typically created, resulting in test work products. In practice the extent to which test work products are documented varies considerably. This can be affected by any of the following: Project risks (what must/must not be documented) The “value added” which the documentation brings to the project Standards to be followed and/or regulations to be met Lifecycle model used (e.g., an Agile approach aims for “just enough” documentation) The requirement for traceability from the test basis through test analysis and design