How do you execute tests?

Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities.

. The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing.

. A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool.

. Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead.

. After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager's formal acceptance.

. The test team reviews test document problems identified during testing, and update documents where appropriate.

Inputs for this process:
. Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.
. Test tools, including automated test tools, if applicable.
. Developed scripts.
. Changes to the design, i.e. Change Request Documents.
. Test data.
. Availability of the test team and project team.
. General and Detailed Design Documents, i.e. Requirements Document, Software Design Document.
. A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager.
. Test Readiness Document.
. Document Updates.

Outputs for this process:
. Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables.
. Changes to the code, also known as test fixes.
. Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems.
. Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues.
. Formal record of test incidents, usually part of problem tracking.
. Base-lined package, also known as tested source and object code, ready for migration to the next level.