Automated script review check points

Often we review the code,but will not be sure whether we are doing it right and doing it complete.So here is a checklist for automated script code review...

1. Automation coverage--Does the script automate each step of the test case?
2. Sequence--Does the script coded each step in the correct order as per the test case flow?
3. Validation--Does the script cover each and every validation as per manual test case?
4. Logic--Does the script logic call the correct functions? Are these functions called with the correct arguments?
5. Test data--Does the script take application input values from the correct input test data file(s)?
6. Object compatibility--Does the script execute user operations against the correct objects?
7. Synchronization--Does the script give the application sufficient time to transition to the correct test state e.g. the correct page/window/screen?
8. Output values--Does the script validate application output values/system generated data against the correct output test data file(s)?
9. Object validation--Does the script validate the state of the correct objects?
10. Object used--Does the script load only the necessary objects in memory?
11. Waits--Is the script free from unnecessary delays?
12. Error handling--Does the script handle application errors as designed?
13. Naming--Does the script have a unique identifier?
14. Unknown data--Is the script free of any magic numbers or magic strings?
15. Commenting--Is the script commented at each appropriate place in it? Is each comment correct?
16. Usage--Is the script free from unnecessary or extra code?
17. Reporting--Is the reporting correct? All the details are reported?
18. Documentation--All data like Developer,Date of scripting,Functions used, etc are
documented?

I think it helps...

Pesticide Paradox !!

I came across a term called as 'Pesticide Paradox' in testing.So just thought of sharing it.

What is the meaning?:
The immunity of the application under test increases !
The same tests (test cases) run over a period of time would start losing their effectiveness to find defects. The developers fix the bugs and the application might reach the saturation in that area or module or functionality.The easy to find and fix defects are discovered and fixed but in the process more subtler bugs are introduced into the system.

What is the solution for it?
To maintain the effectiveness and efficacy of the tests being performed, they need to be revisited time and again and re-written so that the unexposed code is also tested thoroughly.
There can be many permutations and combinations to test a particular system and it is never possible to test it in its entirety. Another effective technique is not to rely solely on the structured and formal techniques but also to perform ad-hoc and exploratory testing to uncover bugs.Think out of box !

Local or Shared Repository?

While using QTP,usually we will be not able to decide whether to to use the Local object repository or shared object repositories.Well, here is a quick reference to decide..

This	In these situations...
local object repository	You are creating single-action tests. You are creating simple tests, especially under the following conditions: You have only one, or very few, tests that correspond to a given application, interface, or set of objects. You do not expect to frequently modify object properties. You are new to using QuickTest. You can record and run tests without creating, choosing, or modifying shared object repositories because all objects are automatically saved in a local object repository that can be accessed by its corresponding action.
shared object repository	You are creating tests using keyword-driven methodologies (not by recording). You have several tests that test elements of the same application, interface, or set of objects. You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options. You expect the object properties in your application to change from time to time and/or you regularly need to update or modify object properties. If you are familiar with testing, it is probably most efficient to save objects in a shared object repository. In this way, you can use the same shared object repository for multiple actions—if the actions include the same objects. Object information that applies to many actions is kept in one central location. When the objects in your application change, you can update them in one location for all the actions that use this shared object repository.

Courtesy: QTP Help

Hell World..

Hi All !!
I welcome you to my blog. I will try to write based on my experience and the readings..
Happy reading :)