| || |
Where is the focus when testing....?
When using any of the tools is the automation used to check as many paths through the application as possible (which you couldn't really do manually) or is the time spent checking the business process underlying the application.
The reason I ask is I am wondering if I would be better off trying to find errors in my app were the user switches from one place to the other and then tries to carry on or validate that a specific process works properly. Once a process is shown to work is there any further value in having that check until the next time the app changes.
My UI is not constant so the value of regression is low.
Re: Where is the focus when testing....?
"Once a process is shown to work is there any further value in having that check until the next time the app changes."
Technically, showing a process works is only part of the issue. You also have to try to make it not work.
But, let's assume that you have executed all your planned tests and have a high level of confidence in the code. If the application is not changing, then, generally speaking, your confidence in the app will not change. However, there could be value in running more tests, since the quality of the application is not dependant on your confidence in the application. Rerunning old tests could corroborate your previous findings (confirming your confidence) or find bugs (contrary to your confidence.) Running new tests would allow exploration for defects.
"My UI is not constant so the value of regression is low."
Actually, it's the other way around. Since the application is constantly being changed, it is important to validate that changes do not cause defects. You don't want one of these changes to cause the system to regress to a worse state.
What would probably be true, is that since your UI is not constant, the ROI for automated regression would be low. The test scripts would require constant maintenance to keep up with the changing UI.