A data driven transactional application supports the execution of business processes. Each business process (such as book sale, update employee status, submit work hours, etc.) is comprised of multiple business transactions. A business transaction is described as the interaction and managed outcome of a well-defined step within a business process. A transaction is usually triggered by user interaction and its outcome can be measured and verified. The following is an example of a business process for updating an employee record and its underlying transactions as it is presented as part of a test plan for that business process:
Business Process Test Plan – Update employee record
| Transaction name | Trigger | Expected outcome | Response time for a remote user | Service Level Objective |
| Sign in | User enters his credentials into the sign in page and clicks submit | The user is signed in and the application displays the home page | 7 seconds | |
| Navigate to company address book | Click on “Company address book tab” | The company address book page is displayed | 3 seconds | |
| Find employee | Enter employee name in the search box | Employee search results are displayed | 7 seconds | |
| Select employee | Click on employee link | Employee data page is displayed | 7 seconds | |
| Edit employee data | Click on edit | Employee edit data page is displayed | 3 seconds | |
| Update employee records | Click on submit | Employee records are updates | 7 seconds | |
| Sign out | Click on sign out | Sign in page is displayed | 3 seconds |
0 Comments For This Post
1 Trackbacks For This Post
November 5th, 2009 at 2:15 pm
[...] also a lot of different answers to these questions. In the next couple of posts we will focus on enterprise-data-driven- transactional applications and their performance flaws over the network (ignoring for a moment back-end or desktop [...]
Leave a Reply