In software testing manual testing is the process of manually reviewing and testing software for defects. The objectives of manual testing are: the improvement of software quality through finding defects and re-testing defect fixes, reducing the risk to the company by executing tests that prove the functionality work as intended and to provide test metrics to stakeholders so they can make the decision on the software release.
Phases of delivery:
- Test Preparation
- Test Execution
- Test Closure
Test preparation ensures that all documentation and procedures are in place to begin commencing test execution as soon as the first software build is ready. Typical test preparation tasks include: clearly defining roles and responsibilities for the team during test execution, completing any test collateral, engaging scheduling and assigning tasks to test and setting up provisions for test environments. Deliverables include: the test plan, the test conditions, the test cases, test charters and test execution schedule.
The purpose of test execution is to execute all tests on the application and ensure that the project stakeholders are kept informed on all the important test metrics i.e. tests executed, defects raised, defects fixed. Test execution includes re-testing and regression testing on software fixes, raising defects, defect triage meetings with business stakeholders and developers and the evaluation of progress against test exit criteria. Typical deliverables include defect summary reports, test progress reports and test execution results
Test closure documents the final state of the application including metrics referencing test cases executed, tests passed defects outstanding and prepares for any testing that may be conducted after test closure. Tasks include the test closure report, the go-no go decision and the pre and post release of testing needs.
A test plan is created to outline how testing activities will be co-ordinated and delivered. The format and contents of the test plan should be based on the needs of the project. A formalised fully detailed approach may be required for complex code changes while a simple BAU (Business As Usual) change may only require a short presentation to outline key elements of the delivery. A walkthrough of the test plan with all project stakeholders should always take place to ensure that everything has been covered and fully understood. IEEE 829 defines the headers for the test plan.
User acceptance is testing conducted by the actual users of the system to confirm that the software can handle required in real world scenarios. Performance testing is the process of testing an application often including the hardware and back end architecture to assess whether a system still functions correctly under real world usage.
Load testing: can the system handle real world load? A typical requirement of a system or application is that it must be able to be used by a set amount of users. Load testing places a real world load on a system to ensure performance is adequate. By recording response times it is possible to determine whether requirements have been met or not.
Stress testing: what is the system’s breaking point? The objective of stress testing is to increase load over time so that we can find the systems breaking point. Stress testing can be used to discover the level of load at which performance begins to degrade. Once defined organisations can then understand what the potential impact of this breaking point is and whether further optimisations need to be made.
Volume testing: does performance degrade over time? Volume testing can ensure that the system is able to handle a full day of use without fault. This type of testing serves as a system stability test. Often this type of test can only be carried out a limited number of times with each incremental release; it therefore serves as a final check for system reliability.
Operational acceptance testing is assessing whether the system that has been developed is capable of being supported operationally, this may include things such as: data system recovery, disaster recovery, maintainability, portability, supportability.
Test estimation is important to the SDLC and testing lifecycle, it provides an expectation on how many tests are required for a given piece of work and also how long these tests will take to create and execute. In providing this, the test team can give the stakeholders an idea of whether testing is feasible within the budget.
Test driven development
Test driven development is a process in which improvements are made on the results of running test scripts, these scripts are derived from the requirements
||Test Case ID
| Test that a user can log in to the application with valid details
When creating test conditions ensure that the following questions are considered
- Are the requirements objective?
- Are the requirements clear and unambiguous?
- Are any business terms used within the requirement specification defined and explained?
Identify business requirements:
Pick out functionality from documents to ensure each is uniquely identifiable, clear and precise and objective and unambiguous. A test condition describes the characteristics of an individual requirement that can then be verified by a test case. A test condition is also known as a test title, there must be at least one test condition associated with each requirement (via requirement ID).
Rules of thumb:
- Use absolute language, no “ifs”
- Test conditions should always start with “test that”
- Be to the point and concise.
- Every positive test should have a negative counterpart