The cloud moves information technology to business technology. Testing cloud applications is in line with that. With software testing were not testing the IT anymore, but the BT. But how do you test BT? As the ‘B’ in BT stands for business a business approach should be used with testing. With using BDTM the business is put in the driving seat with BDTM. But is that enough for testing SaaS solutions?
When testing BT the business scenarios are the most important part for what to test with. The application should fit the business in doing their work. So setting up the test using the user scenarios or using the Real Life Test technique is what is needed while testing SaaS applications. The user scenarios are worked out into test scripts that are easy to read for the business and are, preferably, executed automatically.
To create these scripts multiple options are valid, but the two most available are using the test technique Real Life Test and creating a (test) model based on the user scenarios from where test scripts are derived using Model Driven Quality Improvement (MDQI). As the business technology is tested, the testing should connect with the business; connect with the business processes.
When testing the business technology the business plays a key part in how good there is tested. If the business doesn’t have the time to look at a system en help with setting up the test scripts and executing them it’ll be very difficult for testers do a adequate assessment of the system’s quality. Although the business can only help with the checking and approving of the system it plays a vital part in the final outcome of the tests.
To help the business testers also should focus on the business aspects of the system. That can be done by using test design techniques that are appropriate for creating test scripts from a business standpoint. Test design techniques like the Process Cycle Test (PCT), Use Case Test (UCT) and Real-Life Test (RLT) are of great use when creating the test scripts. These test scripts focus more on the business use of the system than others. This focus provides the testers with the tools they need to execute tests on the business technology because they are in line with the needs of the business.
Therefor the testing can start at the moment the project starts. When the business requirements or scenarios are defined the testing can start with creating the test scripts from these scenarios; the testers don’t have to wait until the code is written. The code is already written and tested functionally by the supplier, but the integration with the system is needed for this application. That integration starts with the business’ use of the system. As that is defined at the start of the project testing can also start at that moment, it is even necessary to start thinking of quality right from the start with testing ideas, concepts and documents; start at PointZERO®. However, our current way of working does not always accommodate this concept. And in most cases it will require some time to grow into it.
How can we leverage this? When communicating with the business always ask them what they feel is important, in creating the test strategy and specifying test cases. Integrating users in test teams during acceptance testing is already a common feature, but more interference from the business on what to test can be of mayor assistance when creating tests for business technology, especially with managing defects. The business knows what it really wants and what not, they can help give priority to the defects of what to solve and what not. Integrating the business within the testing will create more influence for the business in IT, helping it move to BT.