Why We Need Stubs And Drivers?

Stubs and drivers handle in integration testing being a top down integration testing and bottom up integration Testing.

While doing Integration, if we don’t hold all the modules get covered and urge to test a particular module which is covered then We Use Stubs and Drivers.

Stubs are dummy modules that are distinguish as "called programs", that is handle in integration testing (top down approach), it used when sub programs are under construction.

Stubs are the dummy modules that simulate the low level modules.

Drivers are also form of dummy modules which are distinguished as "calling programs”, that is handled in bottom up integration testing, it used when main programs are under construction.

Drivers are the dummy modules that simulate the high level modules.

Example of Stubs and Drivers is given below:-

Considering example if we have modules login, home, user. Login module is ready and urges to test it, but we call functions from home and user (which is not ready).

To test at a selective module we write a short dummy piece of a code which simulates home and user, which will return values for Login, this piece of dummy code is always called Stubs in a top down integration.  

Resembling to the above example: If we have Home and User modules get ready and Login module is not ready, and we urge to test Home and User modules Which return values from Login module,

So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user, So these pieces of code is always called Drivers in Bottom Up Integration.

Acceptance Testing

This type of testing is done by the engineers sitting in the customer place just after the product is delivered.

Let say Wipro has signed a contract with Fedx to deliver a product on X th day. Assume that a critical bug has occurred just few days before the delivery of the product.
   Now if the company asks for more time from the customer, then the company will be accountable for the further billing i.e.company will be accountable/pay the expenses till the product is released.
But the project manager cant delivery the product having bugs on the release date bcoz the customer will not accept the product blindly, instead will the test the product in detail. This verification is done by test engineers. This kind of testing is called as Acceptance Testing.
     Almost every company will have its own IT division. If a company wants a software to be developed, it will send the requirements across companies and its own IT division will bid for it.
 The company with the best bid and good plan/layout will get the contract and the preference will be given to its own IT division if only it has the best bid or best bid will get the contract.
For Eg: Wipro will do only Functional testing, Integration Testing and System Testing. But Fedx will do Acceptance testing with the other 3 types of testing .

The acceptance testers will have domain knowledge on the product or will hire the domain experts or train them.

Case1: Engineers at the customer place will do acceptance testing based on the real time scenarios, these engineers will have enough domain knowledge.

Case2: If the project is too big and the IT division is too small. The customer doesn't have enough engineers to do acceptance testing, then the product is given to some of the staff of the Fedx (for whom the product is developed) for do testing it for a particular period of time(dummy implementation of real time business takes place). The staff is trained on the product and  then they start testing it or experiment it.
Here the acceptance testing is done by a user who is an end user.so it is called as UAT.

The end user uses the product in real time scenarios and tests the application or is the product is working fine without any error before release of the product on the production floor,

Case3: If the customer doesn't have sufficient staff to test the product once it released and customer doesn't have enough budget to hire new engineers or outsource the product for doing AT. In this case, customer will call the wipro engineers to do the acceptance testing who already on domain knowledge and have done testing on the product. The test lead of the customer monitors these engineers who will have to execute the real time scenarios.

Case4: Instead of calling the test engineers, the test lead will go to the company and monitors the test engineers by providing new real time scenarios for testing

Acceptance testing takes 2 to 3 cycles of testing.

What is Defect?
Deviation for requirement specification is called as Defect.

Difference between Defect, Bug, Error and Failure?

Deviation for requirement specification
Bug is an informal name given to defect.
Mistaken done in program resulting unable to compile or run.
Defect causes Failure. One defect can cause multiple failures.

Why Defect is rejected?

Case 1: Misunderstanding of requirement - if a feature is misunderstood as a bug or sometimes Dev may give justiifcation saying its a feature not a bug.

Case 2: Referring to an old requirement - if the feature is removed from the template and the tester is testing the module and raises a defect.

Case 3: Extra implemetation - extra feature is developed which is not there in the requirement specification.

Duplicate Bug:

For example Tester 1 and Tester 2 are testing some common application and find a defect with the application. Both the testers raise the defect for the same. If tester 1 has raised the defect first and tester 2 raises the defect second, then tester 2 defect become duplicate bug.

Case 1: Commom Features - Common features are tested among the testers.

Case 2: the above example

Case 3: Known bug - if tester1 has already raised a defect for the application1 and starts testing application2. Tester2 starts testing application1 and finds the same issue in app2 and raises a defects then this defect becomes duplicate bug.

Why a defect/bug cannot be fixed?

Case 1: Technology only is not supporting, there is no solution for fixing this bug in that programming lang.

Case 2: Its a minor bug and the technology itself is not supporting for fixing this defect.

Case 3: Cost of fixing the bug is more than cost of the bug.

Case 4: if the defect is present in the root of the product.
Eg: if youfind a defect in the root of java, then fixing that bug will affect the other features in java.

Defect is not able to Reproduce?


Case 1: Improper Defect Report - steps to reproduce the defect is not mentioned correctly

Case 2: Data Mismatch - login as abc and click on inbox page, results in blank page. So log a defect and the dev team will login as xyz and click on inbox page, pages opens. Here mismatch of account id)

Case 3: Inconsistent Defects  - Reproducing the defect is inconsistent.

Case 4: Platform Mismatch - OS / Browser mismatch


Why a defect is postponed/deferred?

Case 1:If the defect is minor one.

Case 2: Dev team accept the defects, but takes time in confirmation fromcustomer if this is valid or invalid.


Why a bug is RFE(Request for Enchancement)

When you find a defect and the feature is nto available in the requirement, but developer accepts the bug, so that can be RFE.  Getcutomer approval and fix the RFE.

cross scripting attack demo

click here to know about XSS attack