Software test process model
The figure below depicts a common test process.
For each test level, the following activities will be appropriately implemented:
First, create test strategies:
enter:
· Detailed description of hardware and software components, including test tools (test environment, test tool data).
· The role and responsibilities of resources required for testing and progress constraints (personnel, schedules)
· Test method (standard)
· The functionality and technical needs of the application (demand, change request, technical and functional design document)
· The system is not available (system limit)
Output:
· Approved and signed test policy document, test plan, test case
· Test items that need to be solved (usually required to be coordinated by customer project)
process:
· The test strategy is about how to test the formal description of XYZ, requiring development of test strategies for all test levels. Test team analysis requirements, write test strategies and review the project with the project team.
· Test programs should include test cases and conditions, test environments, and tested tests, guidelines and test risk assessments. The test schedule will identify all the requirements for successful test results, the progress and resource requirements of the activity.
Second, create test plan / design
enter:
· Approved test policy documentation.
· If the test tool is applicable, automated test software and previously developed test scripts
· As a result of a test (test document question), there is no explanation in the test documentation
· Understanding of software complexity and module path override from profile and detailed design document (software design, code, complex data)
Output:
· Problems found when designing feedback to developers (software design, code issues)
· Approved test scenarios, conditions and scripts (test design, use cases and scripts)
· Test Data
process:
• Prepare test scenarios and use cases by reviewing the functional requirements for the release of the release version and prepare to better split into test scripts. Test will be defined as test conditions, data and desired results for testing (database update, file output, report results, etc.). It is possible to describe the general and abnormal cases that appear in the application as test scenes.
· Project developers will define the unit test requirements and unit tests of unit testing. Developers are also responsible for performing unit test cases before integration and system testing.
· With the assistance of developers and customers, the test team will develop integration and system testing test scenarios, use cases. Acceptance test cases will be developed by customers with the help of projects and test teams.
· Execute the test scene by using the test script. The script will define a series of steps used to perform one and multiple test scenarios. Test scripts typically depict transactions or processes that occur in general system operations. Test scripts include specific data for testing or transactions. The test script will overwrite multiple test scenarios and include run / execute / cycle information. Test script map demand and to ensure that any tests are trace matrices within the range.
• Capture and baseline test data before testing. These data will be the basis of unit and system testing and system functionality in a controlled environment. For future controls, some output data is also baselined. When the regression test, the baseline data is used to support the subsequent system maintenance. • Test preparation meetings should be held for assessing the application's ready-on-intement, environment and data. In order to point out the entry standard status of this version, the test ready document should be created.
Third, execute test
enter:
· Approved test document (test plan, use case, program)
· If you apply test tools, automation test software and write good scripts
· Design changes (change requests)
· Test Data
· The availability of test and project group (project personnel, test team)
· Summary and detailed design documentation (demand, software design)
· The development environment that can be fully transferred to the test environment (unit test code) through configuration / build personnel
· Test ready document
· Revised documentation
Output:
· Code changes (test fixes)
· As a result of a test (test document problem), there is no explanation of the test documentation
· The problem found when designing, feedback to developers and customers (demand, design, code issues)
· Test accident formal record (problem tracking)
· Baseline package prepared to transfer next level (source code and object code)
· Logs and summary of test results
· Approve and sign documentation with revised test delivery (updated delivery)
process:
· The Checkpoint meeting should be held in the implementation phase. (If necessary,) issues, status, and activities in the test, status, and discussion tests should be held daily.
· Finish the test execution by following the test documentation by using the system's means. When performing each package of the test program, in order to record any defects identified by the execution of the program, the problem should be recorded in the test execution log. The output after the test program is executed as a test result.
• In order to determine if the expected result can be obtained, the test results should be evaluated by the appropriate project team members (, all levels suitable for testing). Record and software development managers / programmers discuss all differences / exceptions, for future investigations and resolutions, it should be documented (each customer may have different record logs and report bug / defect process, through Configuration Management (cm) Group checks these processes). By / fail criteria is used to determine the serious level of the problem, and the results are recorded in the test summary report.
• Define the problem of problems found in system testing in system testing and logging into the tracking tool they choose.
· Repair and submit it to the test environment based on the problematic level of problem. The modified question should be tested and transferred to the new baseline without problems. After the test is complete, the members of the test group should prepare a summary report. Summary reports must be reviewed by project managers, customers, sqa, and / or testing groups.
· After confirming a specified test level, the configuration manager should organize the published software component according to the requirements in the configuration management plan and transfer to the next test level. The software can only be transferred to the production environment after the official acceptance of the customer. · Test team reviews the test documentation found when testing and updating documents. Some problems may be inconsistent or modified between technical and functionality.
