D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Fig. 1. Security Engineering Process<br />
manual test execution or test automation (implementation of keywords). This interaction<br />
process is highly iterative. The model-driven testing process involves three main<br />
roles:<br />
– The Business Analyst is the reference person for the System-Under-Test (SUT) requirements,<br />
business processes and business needs, and he/she communicates with<br />
the Test Analyst to clarify the specifications and testing needs.<br />
– The Test Analyst interacts with the Business Analysts and system experts regarding<br />
the requirements to be covered, and then designs test generation models. He then<br />
uses test generation tools to automatically generate tests and to produce a repository<br />
of test suites that will satisfy the project test objectives.<br />
– A Tester is responsible for (manual) test execution on the basis of the test repository<br />
while a Test Automation Engineer is responsible for connecting the generated<br />
tests to the system under test so that the tests can be executed automatically. The<br />
input for both Tester and Test Automation Engineer is the test repository generated<br />
automatically by the test analyst from the test generation models.<br />
For this process to work smoothly in presence of changes we need to orchestrate the<br />
work of the requirement engineer with the work of the testing engineer. In many cases,<br />
requirements evolution can have impact on a confined part of the system. In such cases<br />
it would be beneficial to clearly identify only those parts of the system that have been<br />
affected by the evolution and that need to be re-tested for compliance with requirements.<br />
In this way re-running all test cases is avoided because it is possible to identify which<br />
new test case need to be added to the test suite and which test cases can be discarded as<br />
obsolete.<br />
2