Basic VBScript For QTP

Hi All,

As you all know 80% of coding in QTP is through VB Scripting.So here i will be explaining basic functions in VBScripting.


DataTypes

The Primary  Data type of VB Script is Variant.But it has many subtypes.The major sub types are Boolean,Byte,Currency,Date,Integer,Long,String.Functions to convert from one datatype to another is present.We will discuss about those conversion functions in later sections.

Dim

Unlike Java or C it is not necessary to declare a variable before using it in VBS.It will not throw an error if we are using a variable without declaring.To declare a variable the keyword used is Dim.

Syntax:Dim variable_name

Option Explicit

Option Explicit can be used to force declaration of the variable.this should be the first non-comment line of the script.On using the OptionExplicit ,every variable should be declared using the Dim keyword.On Failure of this the system will throw an error."Variable is undefined".

Syntax:Option Explicit
           Dim num

Another important aspect which we need to keep in mind is VBS is not a case sensitive language.
So the following statements will display the result Test

Option Explicit
Dim st
ST="Test"
msgbox(ST)

Defect Life Cycle

The duration or time span between the first time bug is found (‘New’) and closed successfully (status: ‘Closed’), rejected, postponed or deferred is called as ‘Bug/DefectLife Cycle’

In the mean time it is assigned various statuses, which are

New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed.

The procedure for the above mentioned activities is described below:

·         The QA team will report the bugs/issues found while testing the build With defect status as New/Open.

·         The QA team will then assign the bug to the Offshore Technical Lead/Module Lead.

·         The Offshore Technical Lead/Module Lead will review the bug and reassign it to the appropriate developer

·         The developer attends to the bug and changes the status to Fixed/Deferred/Rejected, along with appropriate remarks

·         The Offshore Technical Lead/Module Lead will then reassign the Fixed and Rejected bugs to the QA team

·         The QA team verifies the bug during Regression Testing. If the status of the bug set by the developer is found to be accurate, the QA team Closes the bug; if the bug still exists the QA team Reopens the bug and reassigns it to the Lead, along with appropriate remarks.

·         After Regression Testing and before Build Release, the QA team will prepare a Test Summary Log, which shows a summary of the status of all the bugs found in the build. 

Database Testing

Database is the core and critical part of almost every software application. So DB testing of an application demands keen attention, good SQL skills, proper knowledge of DB structure of AUT and proper training.

1. Create your own Queries

In order to test the DB properly and accurately, first of all a tester should have very good knowledge of SQL and specially DML (Data Manipulation Language) statements. Secondly, the tester should acquire good understanding of internal DB structure of AUT. If these two pre-requisites are fulfilled, then the tester is ready to test DB with complete confidence. (S)He will perform any CRUD operation from the UI of application, and will verify the result using SQL query.

This is the best and robust way of DB testing especially for applications with small to medium level of complexity. Yet, the two pre-requisites described are necessary. Otherwise, this way of DB testing cannot be adopted by the tester.

Moreover, if the application is very complex then it may be hard or impossible for the tester to write all of the needed SQL queries himself or herself. However, for some complex queries, tester may get help from the developer too. I always recommend this method for the testers because it does not only give them the confidence on the testing they have performed but, also enhance their SQL skill.

2. Observe data table by table

If the tester is not good in SQL, then he or she may verify the result of CRUD operation, performed using GUI of the application, by viewing the tables (relations) of DB. Yet, this way may be a bit tedious and cumbersome especially when the DB and tables have large amount of data.

Similarly, this way of DB testing may be extremely difficult for tester if the data to be verified belongs to multiple tables. This way of DB testing also requires at least good knowledge of Table structure of AUT.

3. Get query from developer

This is the simplest way for the tester to test the DB. Perform any CRUD operation from GUI and verify its impacts by executing the respective SQL query obtained from the developer. It requires neither good knowledge of SQL nor good knowledge of application’s DB structure.

So, this method seems easy and good choice for testing DB. But, its drawback is havoc. What if the query given by the developer is semantically wrong or does not fulfill the user’s requirement correctly? In this situation, the client will report the issue and will demand its fix as the best case. While, the worst case is that client may refuse to accept the application.

Graphical User Interface(GUI) Testing

Windows Application

For each Application

1. Start Application by Double Clicking on its ICON
2. The Loading message should show the application name, version number, and a bigger pictorial representation of the icon.
3. The main window of the application should have the same caption as the caption of the icon in Program Manager
4. Closing the application should result in an "Are you Sure" message box
5. Attempt to start application Twice.This should not be allowed - you should be returned to main Window
6. Normally F1 button is used for help. If your product has help integrated, it should come by pressing F1 button

Software Testing Interview Questions

1. What are the differences between SDLC and STLC?
2. What is Agile Methodology?
3. If you find a bug and the developer says No,then what will you do in this situation?
4. What will you do if you get a single line bug?
5. What all do you have in a Test Plan Template ?
6. What are the contents in a Bug Report Template
7. Explain Bug Life Cycle?
8. Write 3 Test cases of MS-Excel and MS Word
9. What is white box testing?
10. What is usability testing?
11. What is the difference between validation and verification?
12. What is the difference between Quality Control and Quality Process?
13. What is the Difference between Usability testing and UserInterface Testing?
14. What is negative testing?
15. What is Regression testing?
16. What is Re-testing?
17. What are the different levels of testing?
18. What are the different testing techniques?
19. What is priority?
20. What is severity?
21. Give an example of a high priority ,low severity bug?
22. Give an example of a high severity,low priority bug?
23. Who closes a bug?
24. What is boundary value analysis?
25. Explain the V-model?
26. What is the difference between a requirement and an Usecase?

Basics of software Testing

Software testing

Software testing is the process of analysing a software for the purpose of finding defect.

The fundamental objective of testing is to find defects,as early as possible and get them fixed.

Software has bugs because of the following reasons

• Increased complexity of softwares
• Unclear Requirement specificatons
• Programming errors
• Poor Knowledge transfer
• Deadlines

Principles of software testing

1. Testing shows presence of defects :-testing cannot prove that the software is defect free. Even if no defects are found,its not a proof of correctness.Testing only reduces the probability of undiscovered defects in the software
2. Exhaustive testing is imposible :-Exhaustive testing means executing a program with all possible combination of inputs or values of program variables.Testing everything is not feasible and is impossible.
3. Early Testing:-Finding defects early will reduce the cost so need to introduce testing in the early stages of SDLC .
4. Defect Clustering:-A small number of modules usually contains most of the defects discovered during testing.
5. Pesticide paradox:-If the same tests are executed over and over again ,eventually the same set of test cases will no longer find any new defects.To overcome this,test cases need to be regularly reviewed and revised.
6. Testing is Context dependent:-Testing is done differently in different context
7. Absence of Error fallacy:-Finding and fixing defects does not help if the system built is unstable.