gt.bharath@siemens.

com

WR testing Process - 6 steps

WR running the scripts 3 types
WR recording modes
WR GUI map 2 types
WR Checkpoints 3 types(in detail)
WR Exception Handlings 2 types (i hope, object & bitmap)
WR Break Points
WR Commands
WR File comparision, srting comparision, string in a file comparision
WR data driven wizard & comments inserted due to this
WR commands for clicking button, editing the text, selecting the list items, status of
buttons (enable, disable, focussed, non focussed)
WR Scripting for verifying an image (Use Case: enter the path/select from the list, image
is displayed on the same window, verify the image)
WR Advantages & disadvantages
WR running a script - 3 ways step, step in, step out
WR Test results, format
WR database- connecting, fetching a row, counting rows/columns, closing the
connection, 2 types of db (ODBC & Data Junction)
WR printing the messages
WR

Testing Concepts
Testing techniques 2 type and explain them in brief
Testing types - unit, integration, system, smoke, performance...etc
SDLC min 3 type & 1 to explain in detail(Waterfall, spiral, V model)
Bug life cycle
CMM Level in brief
Usability
Hello Vidya...

Thanks for excellent reply.

The example given really precise the definition.

Will be grateful if you can clear bit more on this. Actually i have some
contradict queries.
Can i ping you in id (You need to give me) to clear my doubts.

My ID: manas.patra@rmsi.com

Best Regds
Manas Patra

vidya kulkarni
<vidyasj2@yahoo.co To: Testingkings@yahoogroups.com
m> cc:
Sent by: Subject: RE: [TESTINGKINGS] [Help] Difference between stubs and
Testingkings@yahoo drivers....ASAP
groups.com

08/02/2006 06:27
AM
Please respond to
Testingkings

Hi,

While doing integration testing,if we do not have all the modules available
which are required for testing then we use stubs and drivers.

Basically stubs and drivers are the piese of code that simulate the
activity of missing modules.

For eg: If you have module X and calls functions from module Y and Z.And
you asked to test module X but Yand Z modules are not available to you.

Then you need to come up with some sort of dummy code to mimick module Yand
Z.This dummy piece of code is called stub.

So stubs are "called functions" used in Top-Down Integration Testing.

Similar to above example,Now if you have Y and Z modules are available But
X module is not availble and asked to test Yand Z modules.

Now you need to come up with some dummy code to drive Yand Z.This piece of
code is called driver.

So drivers are "calling functions" used in Bottom -Up integration Testing.

Rgds
Vidya

"Gunasekaran, Sureshkumar" <sureshkumar.gunasekaran@sciatl.com> wrote:

Hi,

Stubs

In Top? Down integration testing we use dummy modules to do the

integration testing. Those dummy modules are called as stubs

Drivers

In Bottom? Down integration testing we use dummy modules to do the

integration testing. Those dummy modules are called as drivers.

For more detail

Stubs and Drivers

A software application is made up of a number of 'Units', where output
of one 'Unit' goes as an 'Input' of another Unit. e.g. A 'Sales Order
Printing' program takes a 'Sales Order' as an input, which is actually
an output of 'Sales Order Creation' program.
Due to such interfaces, independent testing of a Unit becomes
impossible. But that is what we want to do; we want to test a Unit in
isolation! So here we use 'Stub' and 'Driver.
A 'Driver' is a piece of software that drives (invokes) the Unit being
tested. A driver creates necessary 'Inputs' required for the Unit and
then invokes the Unit.
A Unit may reference another Unit in its logic. A 'Stub' takes place
of such subordinate unit during the Unit Testing. A 'Stub' is a piece
of software that works similar to a unit which is referenced by the
Unit being tested, but it is much simpler that the actual unit. A Stub
works as a 'Stand-in' for the subordinate unit and provides the
minimum required behavior for that unit.
Programmer needs to create such 'Drivers' and 'Stubs' for carrying out
Unit Testing.
Both the Driver and the Stub are kept at a minimum level of
complexity, so that they do not induce any errors while testing the
Unit in question.
Example - For Unit Testing of 'Sales Order Printing' program, a
'Driver' program will have the code which will create Sales Order
records using hard coded data and then call 'Sales Order Printing'
program. Suppose this printing program uses another unit which
calculates Sales discounts by some complex calculations. Then call to
this unit will be replaced by a 'Stub', which will simply return fix
discount data.

Integration testing is to test the data flow between the two modules,
If the data flow between the two modules is ok than integration test pass.
Types of integration
1.Top down
2.Bottom-up
3 Umberila approach (Big-Bang Approach)

Do u have the description of Big-Bang Approach?

No. But it’s nothing but combination of Top down& Bottom up approach....
Where all the modules are integrated at a time... & tested....

Test Life Cycle: -

1.Understding Requirement (SRS, BRS, BDD etc)
2.Writing the Test cases.
3.Review the Test Cases
4.Execute the Test Cases
5.Defect Tracking
6.Regression Testing
7.Test Report.