Importance of Software Testing in the Tech World

We have reached a stage in human evolution where we can safely say that it is the various software used by service providers corporations that rule the world. Software companies spend a lot of money and manpower in creating software that satisfies the requirements that were specified by their clients which include individuals or enterprises. Along with the development of software, these companies are also required to ensure that the software performs as desired by the client. Like any other product that is manufactured, software can also have defects in the form of bugs in the program and they need to be tested rigorously before deploying. If the software does not perform as promised the company will face loss of its reputation in the market. Software testing can include general testing, load testing, functional testing, and regression testing.

General testing is a test that is carried out to ensure the functionality of the new software. The usual parameters that are tested include web performance and usability testing. The performance of an application online is the factor that is tested in general testing. The usability of the software in a given set of circumstances is also tested in order to help the engineers understand the areas where there is a scope of improvement. The general testing is a very important step that not only helps in testing the software and assessing the ability of the development team but also ensures that the end product that reaches the client is according to the specifications set by him.

Load testing is also a software testing process that checks the impact on the software during periods of higher than normal load. This is done by simulating operating conditions that exceed the normal load than what is prescribed for the software. This is different from stress testing in the fact that it checks the operational capabilities in normal and high load capacities while the stress testing checks the capabilities in events where errors are induced in normal operations. Load testing helps the developer gauge the multi-user support capabilities of the software. Load testing is very useful because it can find out the reasons for low performance.

Functional testing is done by identifying the functions of the software and creating input data that matches the identified function. The output is also determined and it is compared with the expected output. The obtained output and expected output are compared. Regression testing is performed to identify the bugs that are present in the functional and non functional areas of a system. It is done to ensure that using a patch or upgrade will not lead to the introduction of a new bug into the system. Repeated regression testing needs to be done to ensure that the software is glitch free during operation. Each of these testing methods has been designed to ensure that the software that reaches the client is as perfect as possible and satisfies the client to the maximum. They are an unavoidable part of quality assurance of software products in today’s world.

Author Bio: Frank Olson is a veteran freelancer and is currently working as special reviewer at, an online portal to find out best essay writing service reviews.

How to write Test Cases?

In Manual Testing, Testers will test the Application  by executing the Test cases manually  without requiring  any automation tools.  Manual testing will take significant time to cover all the requirements. So, it is very important to write test cases effectively to cover all the requirements while keeping number of test cases at  minimum level.  Let us  see how to write test cases  for testing an application.

What is  Test Case ?

Test case is “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” The  purpose of Test Case  is to divide the software function into small units of function that is testable with input, and producing result that is measurable.

i-e  A test case is a feature/function description that should be executed with a range of input, given certain preconditions, and the outcome measured against expected result.

These are the  fields commonly present in the Test Cases :

  • Test case id
  • Test Case Description
  • Procedure / Test Steps
  • Test data
  • Expected result
  • Actual result
  • Status ( Pass/ Fail)
  • Comments

Test cases should be simple and easy to understand for Developers.

Test Case ID :

This ID should be Unique throughout the Testing Application and not to change at any moment.

Test Case Description:

Explain the function under test. Clearly state exactly what attribute is under test and under what condition.

Prerequisites– Every test needs to follow a sequence of actions, which lead to the function under test. It could be a certain page that a user needs to be on, or certain data that should be in the system . For example  registration step should be completed before start testing login.


Sequence of steps to execute the specific function.

Test data:

Specify the data used for a particular test or if it is a lot of data, mention the path of a file where this data is stored.

Expected Result:

Clearly specify the expected outcome in terms of the page/ screen that should appear after the test, changes that should happen to other pages, and if possible, changes that should happen to the database..

Actual Result :

State the actual result of the function execution. Especially in case the test case fails, the information under ‘actual result’ will be very useful to the developer to analyse the cause of the defect.


In this section you can add your reviews, suggestions and ideas to developers for the bug how we fix that.  Especially this section made to communicate with developers.

Test case writing procedure

  • Get as much information about the application as possible through available documentation (requirement specs, use cases, user guides) , tutorials, or by exercising the software itself (when available)
  • Determine a list of features and different user roles.


Say for example, if you are writing Test Cases for testing  this Timesheet Application.

First you should understand the features available in this timesheet application by reading the help files and other available documents about this timesheet application.

You should know about different user roles (e.g user, admin) involved in this application.

Once you gather all the details about this application, you can start writing test cases. Find below one sample, and you can show/test your test case writing skills by adding more test cases thro’ the comments section.

  • Test case id – LG01 (LG refer as Log In)
  • Test Case Description -Check Case sensitivity in  Log In Functionality
  • Procedure
  1. Load login screen by visiting
  2. Enter valid username and password in Upper case.
  3. Click “Login button”
  • Test data – Username as user || Password as USER
  • Expected result – Alert box like CAPS LOCK on to warn the user
  • Actual result – But its not visible and accessing with uppercase letters.
  • Status ( Pass/ Fail) – Fail
  • Comments –  Password is an user’s choice so we can’t restrict so we have to give the warn or alert box or format that password should be like this.
Like wise, for each and every action we have to write test cases.

At the time crunch of any project, the testers simply go with the Adhoc Testing and Exploratory testing.


Various Skills required for Software Testers

Starting your career as “Software Tester” requires various skill sets apart from having Testing Skills.

Previously I had published a Post about the importance of the Domain Knowledge for the Software Testers.

Some people are arguing that hiring Software Testers with Domain knowledge may drive them to change the ambiguous  requirements by themselves without discussing with the Business Analyst.  It will lead to poor quality. Anyway, the companies especially BFSI (Banking, Financial Services and Insurance) domain companies give high priority to Domain knowledge while hiring Software Testers.

Apart from BFSI applications few other things such as,  Mobile application testing, VoIP applications, Gaming testing, Network testing, Wireless application testing and Protocol testing are also requiring domain knowledge for the software Testing professionals.

So, the Software Testers need to have below skills.

  • Testing skill
  • Domain knowledge
  • Technical skills
  • Communication skill
  • Automation skill
  • programming skill

If I missed to mention any other important skills, you can say it thro’ the comments.

Software Test Automation tool evaluation

In this chapter I will explain about evaluating Automation test tool and selecting appropriate tool suitable for our requirements.
Before start evaluating tool we should analyze whether automating software testing will really give any benefit over manual testing for your needs.
Actually, Software Test Automation is a good way to cut down time and cost.
But, it will reduce the cost and time only when it is really necessary or it is used effectively.

Test Automation is not required if you are going to use your application one time only or for short period only. For example, assume that you are having a website developed in ASP, and you are making some changes in this website. And, assume you are having solid plan for converting/migrating this ASP site into either ASP.NET or PHP in near future.

In this situation, it is not advisable to automate the testing of the new changes done in the ASP site.
In this case, simply you can complete the testing manually and then you can start your automation testing preparation once after the migration is done.

So, basically we need to automate our testing procedure when we have lot of regression work.Once after taking decision to do the test automation, the next step is selecting appropriate automation tool.

There are hundreds of tools available for automating the software testing and some of them are Free.
Test complete, SilkTest, SilkPerformer, QARun, QALoad, TestPartner, WinRunner, LoadRunner, QTP, Rational Robot,Selenium,WATIR and openSTA are some of them.

Some of these Tools (e.g Selenium) are open-sourced.We need to select appropriate tool based on below factors.

Budget allocated for the Testing process – Price for each automation tool will vary. Some of them are costly, and some of them are even free.License pattern will be varying for each tool. License cost of some tools will vary according to geography location also. And, some tool vendors will fix different price for seat license and floating license.

So, first we need to decide about our licensing needs. i-e Ask below questions,
– In case the tool price changes according to geographic location, whether it will be cost effective for your location.
– How many Automation Test engineers will simultaneously work in your automation project?
– Whether you need separate set up for developing the scripts and for executing the scripts?
– Whether you are having plan to automate your any other testing activities? Whether the selected tool can be used for other projects also?

Support available for the Automation Tool. We need to evaluate whether the Tool provider will provide enough support and bug fix releases. And, we need to think about the support provided by the Forum community also.

Analyze whether the execution speed of the automation tool matches with your requirements.

Check the installation requirements (both Software and Hardware) for installing the automation tool in your test script development environment.

List down current skill set of your testers and check whether the tool can be effectively used by your testers. For example QTP will support vbscript, if your testers know vbscript they can easily learn using QTP.

Feasibility study is very important before finalizing the Tool. Most of Tools will provide evaluation or Trail offer. For example QTP can be downloaded from HP site and we can use it for 14 days. During this trial period try to automate different portions of your application to make sure that the Tool can be used for automating your Testing needs.

Analyze the Market Share and financial Stability of the vendor of the tool. It will get significance if you are going to use the Automation tool for long term regression testing purpose.

Check whether the Tool can be easily integrated with bug tracking tools. For example, QTP will be closely integrated with Quality Center (Test Director) which is a Test Management Tool.

The best approach is, we can prepare a list with all these factors and add remarks for each tool. And, we can select the tool by analyzing this list.

Object Spy in QTP

QTP is having a Tool called as “Object Spy” for viewing the properties and methods of any object in an open application.

We can use the Object Spy pointer (a button with hand symbol) to point to an object in the application.



Object Spy Dialog window is having Two Tabs. One is “Properties Tab” and another is “Methods Tab“.

Each tab is having radio button to choose one of two options “Run-Time Object” and “Test Object”.

The Object Spy displays the selected object’s hierarchy tree and its properties and values in the Properties tab of the Object Spy Dialog box.

The Object Spy enables you to view both the run-time object methods and the test object methods associated with an object in the Methods tab of the Object Spy dialog box.

And, we can to view the syntax for a selected method.

We can bring the “Object Spy” by clicking the Tools->Object Spy… menu or by clicking a toolbar button (an icon showing a person with hat). This icon can be accessed from Object Repository window also.

To see the properties of an object, first click on the button showing hand symbol in the Object spy Dialog.

The mouse pointer now changes in to a hand symbol and we have to point out the object to spy the details about the object.

If the required object is not visible, or window is minimized then hold the Ctrl Key and activate the required window to bring the required window to the front.

Then release the Ctrl button to make the cursor again hands symbol so that you can point the required object.

You can watch the below Video explaining Object Spy.

Managing Object Repositories in QTP

QTP is having separate window named as “Object Repository Manager” for managing various object repositories.

You can open this window from the Menu “Resources->Object Repository Manager…

The Object Repository Manager enables you to manage all of the shared object repositories used in your organization from a single, central location.
It will be used for adding and defining objects, modifying objects and their descriptions, parameterizing repositories to make them more generic, maintaining and organizing repositories, merging repositories, and importing and exporting repositories in XML format.

The Object Repository Manager window will look like below one.


You can create new shared repository from this window and can store it as .tsr file.

While adding objects, you will be provided with two options. Either you can choose to add only the selected Object or you can choose to add the selected object and its descendants.

You can store the object repositories  either in file system or in Quality Center project.

The Object Repository(OR) Manager enables you to open multiple shared object repositories and modify them as needed.

This Object Repository Manager provides the options such as  “Add objects”, “Highlight in Application”,  and “Locate in Repository”  for the Shared object repository. It is similar to the local object repository. I will be explaining them in separate post.

By default this OR Manager will be in readonly mode. i-e you can not edit anything in this mode.

We need to choose File>Enable Editing for making it editable.

Update from Local Repository option in the OR Manager (Tools > Update from Local Repository) can be used for merging objects from the local object repository of one or more actions to a shared object repository.

And, it provides Object Repository Merge Tool for merging two shared object repositories.

At the end of the merge process, the Object Repository Merge Tool provides a graphic presentation of the original objects in both repositories, which remain unchanged, as well as the objects in the merged target object repository.

Objects that had conflicts are highlighted. The conflict of each object that you select in the target object repository is described in detail. The Object Repository Merge Tool provides specific options that enable you to keep the suggested resolution for each conflict, or modify each conflict resolution individually, according to your requirements.

And note that while the Object Repository Merge Tool is open, you cannot work with the Object Repository Manager.

Apart from this OR Manager, QTP is having “Associate Repositories” option for  enabling you to associate one or more shared object repositories with one or more actions in a test.


Required Steps/Processes in QTP Automation

  • Before starting actual automation task, we should do tool evaluation and feasibility study to make sure QTP is the appropriate tool for automating test cases of our application. It can be done by selecting few sample modules/screens/flow from the application/test cases and create simple QTP scripts to make sure QTP will recognize the objects in our application
  • As part of Test driven development, we can ask the application development team to give proper name or any other identification properties for the objects, if our feasibility study reveals some difficulty for QTP to recognize the objects.
  • As I mentioned earlier, we should start our actual automation work only after completing some basic manual testing to make sure the application is stable and in working condition.
  • QTP developers should review the Test cases and update it to specify which test cases can be automated and which can not be automated. Because ideally it is not possible to automate all the test cases.  Difficulty in navigation or object identification issue or difficulty in verifying the result will prevent automation. If possible, the manual test cases can be rearranged to have separate automation test cases.
  • Once after reviewing all the test cases and after getting familiar with the application we can design the automation frame work for our need.
  • Keep separate instance of application specifically for the purpose of developing automation scripts. It will avoid any unnecessary mess up with manual testing processes.
  • Set up proper QTP development environment with required Add-in and with any add-in extensibility. If many people are going to involve in the development activities then we need to clearly document the responsibility of each person and the approach for sharing the scripts. If application is installed in remote machine then QTP also should be installed in remote machine. Because QTP will not recognize the objects of application in remote session.
  • Set up proper object identification properties in QTP IDE.
  • Once after completing all the above basic steps, the first development task should be adding all the required Test Objects/properties to the Object repository. It can be done by recording or by manually adding the objects to Object repository. If you specify any object using DP (Descriptive Programming) remember to document it.
  • Once after adding all the objects, rename them to have unambiguous/meaningful name.  Doing renaming from object repository will automatically change the name of the object in the script also. But reverse is not true. I-e Renaming a object from script won’t automatically change it in Object repository.
  • Based on your design of automation framework, create reusable actions and vbscript functions using step generator or keyword view or expert view or using Active screen.
  • Using these reusable actions prepare a sample/base script for executing few test cases. And then test it to make it error free.
  • Once after completing the above mentioned sample script, do parameterization (data driven testing) for executing multiple iterations.  Parametrization can be easily done from both keyword view and expert view.
  • Add checkpoints to verify the expected results. Make sure that your checkpoints will work with different data. i-e use regular expressions if some part of expected value will change based on the input data during each iteration of test execution. And, editing checkpoint in QTP is having some issues. So, take care when editing the checkpoint. Mostly changing checkpoint in one place will affect the other checkpoints also. Or, you can create your own functions for creating checkpoints.
  • Use appropriate Regular expression to make sure the script runs in all scenarios even when some properties are getting changed dynamically in particular pattern. For example if your screen page title changes based on the username of the logged in user, the script will not work correctly for all users. (By assuming that the script uses the page title for identifying the screen). You can refer the QTP help files if you don’t know how to add Regular expression.
  • Add the Recovery scenarios to handle any unexpected behavior of the application. Recovery scenario manager and wizards.
  • Use Environment variables to avoid any hard coded values in the script.
  • Do dry run for this sample script and debug the issues in the automation script and fix them.
  • Do the above steps for all the test cases.
  • Create a Driver script which will call all the test scripts. Need to take additional care about deciding whether driver script should take data from its own datasheet or whether it should read data from datatable of the called action.
  • Complete dry run for the Driver script. It is really a challenging task. Because most of the Actions within the Driver script will depend each other and it will take very long time to complete the dry run if we start the dry run from starting point every time whenever the script fails in between the execution. I will explain with one example. Assume that your driver script calls three Tests. First Test will create a user account, second will test the Profile update feature, and third one will test the user deletion feature.  And, assume that the second Test will use the user name created by First test, and the third test deletes the account created by first Test. In this scenario, if you face any difficulty while calling second test we need not always start the dry run from beginning. Since one user account was already created by first Test successfully, we can just comment out the calling of first Test and then continue the debugging of second Test using the already created account.
  • Prepare .vbs script using Automation Object Model to run the QTP scripts in other environments also with same settings. It can be easily done by using “Generate script” option in QTP IDE.
  • Run the scripts in desired environment.
  • Analyze the test results.
  • Report the bugs/defects in the application once after completing the analysis.
  • Once after completing functional testing, select few essential scripts and store them separately for the future Regression Testing.

Handling Passwords in QTP Scripts

Most of the applications/websites will require a password for getting into them.

So, automation tools such QTP should be able to handle the passwords. But anyway, it is not a good practice to keep the password as it is in the scripts.

By default QTP will encrypt the password while recording. The recorded step will look like the below statement.
Dialog(“Login”).WinEdit(“Password:”).SetSecure “49ff257067d53a774881c348da151ccf9282c2109b60”

SetSecure method will be specifically used for handling passwords.
This recording approach will be useful only when you are going to use one or few passwords in your script.

If you want to use many number of different passwords for executing many iterations, this recording approach won’t be much useful.In this case we can use password encoder utility provided by QTP.
It can be accessed from start menu (e.g Programs->Quick Test Professional->Tools->Password Encoder)
It will look like below screenshot.

We need to enter the password text, and clicking “Generate” button will provide the encoded password string.
We can put this string in the Datatable for executing multiple iterations with different passwords.
It will be useful not only for automating the testing, but also in below scenario.
– you want to allow a person available in a remote place to get into your application/site for doing some testing or for some other purpose, and you don’t want to share the password with him. In this case you can just create a QTP script to log into the application.

Some people may not be willing to store the password in the QTP script even in the encrypted form also.In this case, we can create a simple HTML form and call it from QTP script to show as a pop-up window for getting password from user while executing the Script.

It is possible to see the encrypted password in plain text format. So, don’t store your important passwords in encrypted format also. Instead of storing the password, you can create a simple HTML form and call it from QTP script to show as a pop-up window for getting password from user while executing the Script.

Below lines of code were created while recording the login window of the sample flight application using QTP.

Dialog(“Login”).WinEdit(“Agent Name:”).Set “quality”  

Dialog(“Login”).WinEdit(“Password:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”  

Dialog(“Login”).WinEdit(“Agent Name:”).Set “quality”

Dialog(“Login”).WinEdit(“Password:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”
Here we can see the encrypted value “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7” for the password “mercury”
But, when I run the QTP script after just changing the code like below, I was able to see the plain text password “mercury” in the Agent Name field.

Dialog(“Login”).WinEdit(“Agent Name:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”  

Automation Object Model

Just as we use QTP to automate testing of our application, we can use Automation Object Model (AOM) of QTP to automate QTP operations.

Using the objects, methods, and properties exposed by the QuickTest automation object model, we can write programs that configure QuickTest options and run tests or components instead of performing these operations manually using the QuickTest interface.

 We can see Generate Script button in the Properties tab of the Test Settings dialog box, the General tab of the Options dialog box, and the Object Identification dialog box. Clicking this button generates an automation script file (.vbs) containing the current settings from the corresponding dialog box.

The generated script will follow the Automation Object Model and it will be useful for transferring setting in one instance of QTP into other instances.

 For example, assume that you are working in your local computer , and you made some changes in the QTP interface.  Once you complete your development in your local machine I will move the scripts to your customer machine. The script may NOT work in your customer machine.

 In this case we need to use this generated script to keep same settings in your customer machine also.

 AOM scripts are useful for scheduling QTP script executions. We will see about this in another chapter.


It is required to match execution speed of QTP with the loading/responding speed of application. Otherwise the test execution may fail at unexpected ways.

 If you do not want QuickTest to execute  a step or checkpoint until particular object in your application appears, you should insert a synchronization point to instruct QuickTest to pause the test until the object appears (or until a specified timeout is exceeded).

 You can add synchronization point from menu (Insert > Synchronization Point) after start recording the test.

 And,  we can use Exist or Waitproperty statement for providing synchronization.