Specifically, I normally incorporate text checks but when the text check fails, there is no information to find out why right? (unless you turn on extended logging which eats up processor time/memory on the hosts). That does'nt make any sense. I'm not very comfortable with this because I need to know why the user failed by knowing the error that has been generated on that page.
However, the scripts just continue on when an incorrect page appears if there aren't any text checks - there doesn't seem to be much point in doing the test if that is the case.
So did anyone included some kind of code or something which captures the error and send it to the output window during execution along with the verification point failure? Any help will be appreciated. Thanks.
Ideally, but not always, your app will have some kind of standard error page or text. If you have this, then you use a text check to find the contents of the error. This will be an additional text check to your 'expected' text.
There may be more than one type of error display, in which case add more checks. You may need to use the full logging to start with to capture format of the errors, so you can then code checks for them.
Most errors should have been caught in regreesion, functional testing, but as well all know errors occur because of load/stress being applied, so how do we find out the cause of the errors?
Logging is one way to go. Very handy if you do not mind reading through hundreds or thousands of lines of information looking for the point of failure. They are also very taxing on the systems performance. They are useful and very helpful, but can be tedious.
You can put checkpoints in your code and output them to the output screen so you know where you are when it fails. Could also be tedious and produce an over whelming amount of data.
Thirdly you could write exception functions, to look for specific points of failure. For example, if you are submitting an order and you normally check for some text to verify it was submitted properly and it does not appear you can have functions check for different types of possible responses: 404, 405, 500 errors. If you find one print to your output file the type of error and when it happened.
These are methods we have used here, I prefer method one and two. Three is a lot of work, for usually simple error(s).