Importance of Planned Testing Activities

When testing, there are specific project phases, these are all very well-known and well documented. However, software testing is not a single activity per se, but a concatenation of planned activities that need to be executed, along with the software development activities to ensure that a product is delivered to cost and time, without any errors. The following article aims to explain how testing fits within the life cycle of a project and the benefits of early testing and shifting left the quality as early as possible in the software testing life cycle. The following provides a high-level overview as how to plan your testing activities.

Whether developing using an Agile or Waterfall methodology you will always have some sort of business requirements and business goals. In the requirements analysis phase, you can start to interrogate and test the business requirement, studying and verifying the requirements document, looking out for ambiguity and correctness of language to ensure you fully understand what is required and the desired outcomes. For example, if you are requesting a new button on the screen, you would expect to see details of size, shape, colour, location and attributes (what it should do).

Once requirements are understood and confirmed you can then assign a unique reference number to each requirement (ideally suited to Waterfall development) so that the reference number can be traced through each of the subsequent documents like the functional, technical and program specs to ensure each requirement has been addressed. The reference number can then be mapped to the corresponding test cases, whether they’ll be at Unit, System, System Integration or User Acceptance Test level.

Prioritising of the test can also be performed earlier based on the priority of the business requirements, this would aid in deciding the test approach. You may also perform automation testing feasibility exercises to see if there is any opportunity to save time and cost by automating tests that will be continuously used throughout the development lifecycle.

When you start the test planning, you will first have to evaluate the various testing methodologies available in order to decide which approach will suit the project best. If you need a project launched to market quickly, then you may choose Agile, if you have a compliance release, then Waterfall will provide you with a good audit trail.

Once you have decided on the test methodology then you’ll need to create the test strategy plan. This document will include the test approach, resources required, any test management tools, defect management tool and the full schedule details, along with detailing entry and exit criteria.

When you have the test strategy document and requirements specification document created, you can begin to write the associated test plan and test cases. Typically, when you have the business requirements in place the UAT scripts can be produced, once functional and technical specs are reviewed and complete then both the System and System Integration scripts can be generated. Unit test scripts can be produced on completion of the program specs.

If you write your test scripts to a good standard, ensuring detailed expected results, then you can consider them for automation. Typically you would execute the test manually first before automation to prove them, however this doesn’t need to be true if you’ve carried out a full automation PoC previously to ensure all conditions can be automated. Choosing the right test tool, and one that is future proof, is essential to ensure that your automation remains used and relevant.

Functional and Non Functional Requirements

You can’t automate or do functional manual testing without creating or using some data. Additionally, you will need a relevant environment to test; again, the type of environment requested will be linked to which test phase you are testing within, you would expect user acceptance testing to be as like live as possible, whereby the system test environment setup may not link to certain interfaces and they may be replicated by stubs or harnesses. 

Once the test cases, test data and environments are ready, the next thing to do is execute the test cases and monitor the results. It is essential to set up the test environment correctly, perform some smoke tests to ensure it is correctly configured and ensure that the basic functionalities of the system work as expected. Depending upon the smoke test results, you then accept or reject the application. If the smoke test results are good enough for the product to be tested, you can commence the planned testing activities.

When in the test execution phase, you may find defects, issues or may need some help to explain the output results, all these instances are logged in to the test management tool and the defects are raised and passed on to the development team. When the defect is fixed by the developer you will need to retest the function. After execution you will either close the defect, if it passed and expected results were observed, or reopen it if not and pass it back to the developer. You will be responsible for tracking every defect to its closure unless the defect has little impact on the system (say a cosmetic issue) and it is agreed that you can go live with it. Approval will be required if this is the case.

The suite of tests you have created will form your regression testing pack. With every new release of the software, you ideally must do a round of regression testing to ensure that no new defects are introduced into the system.

Once all testing has concluded successfully, the end of the software testing life cycle stlc has been reached. You should now prepare a test metrics report with the details including overall software quality and test coverage attained, ensuring all critical business objectives are met and detail of the cost and time of testing against budget.

A Test Closure report, which gives a chart representation of all the defects by its severity and/or type, must be prepared. This is the final report about the system that was tested to help the client make a decision on whether to go live or not. The Test Closure report must be signed off, usually by the client, to officially end the testing cycle.

Remember that it is essential for you to start the software testing activities alongside the development activities, rather than waiting for the development cycle to end. It minimizes the overall cost and effort that is spent on both testing and development activities, and also shifts left the QA process, so that defects are found early and can be rectified cheaply.