| COLUMN |
Six software test planning tips for better QA testing ROI |
 |
By John Scarpino
30 Mar 2009 | SearchSoftwareQuality.com
|
Software test data, sometimes called a "testbed," can often take days or even weeks to create -- especially if a software application has many permutations and records that need to be tested. IT organizations that recognize this tend to be successful, because they invest time in planning their test procedures and test automation.
But some companies overlook the importance of setting up a viable environment in which to conduct software testing. Software data may be intricately embedded within other systems that hold separate data of their own, or a single system may hold high amounts of lower-level functionality data within a multitude of data pockets. Either
way, the data needs to be managed. So, for any company or organization faced with this problem, it is best to implement a procedure that can speed up the process.
Follow these six test preparation steps to increase software testing ROI:
- Review the data schema to find out all of the required and nonrequired fields for each area of functionality that your testing will affect.
- Talk with the groups or departments who are responsible for maintaining and/or creating those functionalities. For example, a business analyst would be a good person to contact in a department where test data is created, as they would have a wide breadth of knowledge about what exactly is being tested.
- Find out which tests from your set of requirements are being run and which ones are not. Sometimes, aspects of the software that were not originally on the test plan may still need to be tested so that a particular transaction can be completed.
- Create a unified testbed structure that can be reused and built upon. Since testing will only increase as time goes on, it makes sense to create a data structure that can be used throughout the company. Such a testbed can then be refashioned and customized according to the needs of individual departments.
- Changes that are made to the system's structure, both within the database and the system's interface, need to be consistently communicated to the person or group that is responsible for maintaining the testbed. The reason for this is that all changes must align with the software's functionality requirements, and nothing's worse than receiving a system that has changes to its interface and architecture without knowing about it. When this occurs, more time needs to be taken to find out what in the testbed should be changed, and how the change will affect other parts of the system.
- Run multiple types of data transactions or functional tests within the testbed to assure the quality of all permutations in the test plan. After the testing is completed, more data can be entered for each of the test plans to test against the system.
It is important to plan ahead for testing time and accurate data setup, before the test data is pushed onto a system. If an application has a variety of functionalities crossing multiple systems, investing in a well thought-out procedure may increase the application's ROI. Test plans and test scenarios alone do not encompass the fullness of testing. Test preparation is also needed to assure the quality of the process. Thus, when a global testbed of data is created and maintained properly, it can be recycled and reused throughout the organization.
About the author: John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
|
|
|
|
