siddhartham

 Profile Answers by siddhartham 

• Nov 22nd, 2007

 

1.Automation helps us in time saving and Helps to know the Stability of the Application.(ie., take ex web login Application , how many Users can Login at a time and Upto how many users DB can maintain and the application will be stable) these all can be easily done by Automation Processes.accuracy will be obtained.
2.QTP is the best practice for Scripting , Easy to learn and Understand .Present Market is based on it. Even Load Runner is also Important.
3.Intially we give some inputs and record it . Then the Automated tool will Run the application accordingly (as per inputs given by you) . For larger application you need to write code to Run the Application.
4.FSD , BRS , SRS .

sharath_hr

 Profile Answers by sharath_hr 

• Apr 16th, 2008

 

For the first question:

Automation helps in regression of the test cases so, its critical to have the automation setted up for any project

For the second question:

The best practice of scripting for the new automation engineers is by sequencial approach.
which means scripting step by step according to the test case.

nix18

 Profile Answers by nix18 

• Jun 30th, 2008

 

The most important part before automating would be knowing the project's budget and other resources - automation engineers/hardware/software, etc.


3 Main Requirements:
- User Requirements
- Business Requirements
- Functional Requirments

psh2008

 Profile Answers by psh2008 

• Sep 11th, 2008

 

1. Establish scripting/coding standards and conventions so everyone on the team knows what's expected, so the whole team codes with the same goal in mind: Good organization, clear scripts, common functions, procedures and approach.
This is a _development_ effort so treat it like one: Use source control, like ClearCase or PVCS to check in/out modules of code to avoid conflicts and "too many versions".

Plan for re-usability everywhere. Plan for forever. If your setup doesn't stand the test of time and you're constantly re-writing things, than back up and think: Am I building a good foundation on what I am writing ?
Keep it simple and straightforward so the "new hire" can follow it.

2. Establish Test Case documentation standards (the other guy got this right! this is really #1) so that the scripters can follow the documented Test Cases easily. There may be old test cases and new test cases being written by a variety of people from different backgrounds with odd or bare-bones approaches. You need Test Case description, purpose, test steps, pass/fail criteria clearly written down.
TRACEABILITY from the Test Cases to the scripts is vital.
If you think your scripts are testing what you wrote in the manual Test Case, you better know how to validate that assumption.
Use source control, like ClearCase or PVCS to check in/out modules of code to avoid conflicts and "too many versions", and so there is one central place for storing the "reviewed" Test Cases and Test Specifications.
These are the official intellectual property documents of your QA business.

This is just for setting up, the foundation.
Good luck!