Thursday, 18 August 2016

Automation Testing using SOAP UI

Thank you for making my blog successful. I am writing this post for those who have requested to write on SOAP UI.

SOAPUI is an open source tool for testing web services and SOA (Service Oriented Architecture). This functional testing tool is used for functional, regression and load testing.

SOAPUI is useful to create XML request and send it to server and get the response from Server.
We need WSDL to test using the SOAPUI. WSDL URL is nothing but the end point URL provided to test the web service. These endpoints are operating on messages containing information. The operations and messages are described and then bound to network protocol and message format to define and endpoint.

Once the SOAPUI is installed follow the steps given below to create test case -

1. Create New Soap Project from File Menu (Shortcut is Ctrl -N)

2. Enter Project Name

3. Enter WSDL and click OK (This is endpoint URL for testing. During actual work you may have your project specific)

4. This will create your first project to test and learn

5. Double click on Request 1and Click on (+) to add the test suite

6.  Enter name to create Test Suite and Click OK

7. Enter test case name and Click OK

8. This will ask you to enter request to test case. Enter the name. Click OK

Once the test case is created click on the RUN (Green Arrow). This will execute the test case. This will take few seconds. The request will send to the WSDL end point and the response will be received.

Now we will add some assertions. Assertions are nothing but validations. If assertion fails then the test case fails.

Once we have created all the test cases as mentioned above under the regression suite then we can run them from command prompt as well.

Testrunner.bat “C:\ParagTestBlog\SOAPTestProject.xml”

Thursday, 11 August 2016

Automating Devops

Thank you all for visiting my posts frequently.

Let's see the process of Automating Devops and how testing blocks fits in the process.

Devops is development operations; which means once the code is written by developers then we need to collect the code and combine it to make larger functionality. This code is then built to make executable version and deployed in the environment i.e Test or Production. In a very simple language these all operations comes under Devops or Development Operations.

This process is repetitive and requires automation. Also, due to the changing requirements and iterative development code drop is frequent. So we need to run the code-integrate-build-deploy cycle frequently within small window.

There are two major concepts CI (Continuous Integration) and CD (Continuous Delivery). All the code when combined by the tool and sent out for build and deploy is called as Continuous Integration.  The build and deployment cycle may be manual or automated. And CD will be achieved once the code is integrated and if the build is deployed to make sure that application is ready to use after every build.

Automation testing is an essential and integral part of CI and CD. In our previous posts we have seen how Jenkins - open source tool can be used to implement CI and CD.

Selenium allows to write tests in most popular languages like Java and makes it possible to create test suites for unit testing, functional or integration testing. While automating Devops Selenium tests are triggered to make sure the functionality is working as expected. Any integration issues are not passed through and regression suite to confirm that nothing else has broken by the new code.

Any failure to the automated tests will revert the changes and inform all the stake holders. To achieve the most ideal automated system of Devops, requires expertise and willingness to provide enough time on designing the system.

Once the system is in place the maintenance of the system involves but not limited to maintaining Selenium Automation Scripts. Here if automation framework is built then it becomes easy to manage automation scripts for quick maintenance.

Hope you find this information useful.

Keep Automating!  

Thursday, 4 August 2016

Quick Guide for Selenium issues

Thank you for your response. I received a few questions on Selenium so thought of answering them in this post -

Issue 1) How to handle the dynamic objects?

The first solution is to check if you have another locator. e.g. If you are using name locator try to use xpath.

If you do not have another useful locator then try to find out its parent locator and you can come down to the dynamic locator.  

You can also use CSS pseudo classes to walk to the dynamic object. If CSS is not a solution then last but the effective solution is to talk to developer and request to name the object. Here your good communication skills play an important part. 

Issue 2) Application is showing pop up messages?

Operating System level messages like print dialog box, file download dialog box etc. are outside of Selenium’s control. However most of the times you will find the controls are created for browser only and such controls are handled by Selenium. Browsers based pop up messages are easy to handle.
Send keys are not very good to use, however you may find Send keys are the only solution when other solutions don't work for pop up messages.

Issue 3) Application opens a different tab (Multi tab applications)

Usually if we click on hyperlink it opens into a new Window, however few applications open up a tab, for such applications you need to use send keys “Ctrl + Tab”.

Issue 4) Complex selenium scripts, difficult to maintain

If you have complex selenium scripts then break it in small functions. Small functions typically perform one single action like click on button / enter some value / get some elements property.

You can also add all the critical elements to repository (e.g. text file, xml file) for maintaining them outside the script. This is the simplest way of handling the object properties which keep changing frequently. Sometimes element names are different in SIT and UAT, in such cases you can make the changes to text or xml file out of the script.

Issue 5) Reporting

Selenium does not provide you with the reports. Hence this is the best opportunity to create your custom build reports like HTML, XML reports. Or you can use Junit / TestNG reports.

About reports, most important part is to make them very simple and user friendly. Always add date, time, and project information with environment details to your reports. You can also use SMTP emailing option to email reports. Email reports always have summary in email body and effective subject line.

Issue 6) Selenium support

Selenium support is available through forums so if you have issues with your code then post it to Selenium forums. And provide all details like what you are trying to do, your code and what error message you get if any. Don’t give out your conclusion and don’t expect immediate response.

Most of the time on forums you will find someone responding immediately however you can assure yourself to get the right solution you may need to wait for a day or some times for a week depending upon complexity involved.

Keep discussing!

Wednesday, 27 July 2016

Tester’s role in Agile

Thank you for all the responses and requests. This post is for all of them who have requested to share some more information on “Agile” projects as well as the tester's role in the project.

While working on different projects in Agile, I have understood that the testing skills required for agile projects are tested more with in very little time. In my previous post, we have seen the skills required for testing and now we will see how these skills are applied in Agile.


In agile testing, tester is a part of development team. He will be closely working with development team to help them improve quality of the deliverables. This is a critical task and required good communication. Usually communicating to the development team and communicating to agile team is different.
Agile manifesto - Individuals and interactions over processes and tools.
Agile teams are expected to work as one unit and hence the communication between each individual team member becomes paramount important.

Business Knowledge

Within team, most of the time development team rely on the tester for quality. In agile due to quick deliveries and shorten cycles development team expects that tester should provide good reasoning for any quality issues identified. Hence business knowledge required for tester to work in Agile is less important to none.

Technical Knowledge

As tester is closely working with developers and tester is a part of the team, it becomes essential that tester understands the technical discussions. Most of the time testers are exposed to all such technical discussion and then expected to provide some thoughts from improving quality. If tester is very well aware of the technology then it is very useful to help developers to understand the quick quality issues which may otherwise surface.

Issue Resolution

Sometimes in Agile developers are ready to fix the issues within given time if the issues are recognized early in development stage. Well experienced tester can point out issues in the functionalities, design or code and also have courage to explain it to the development team.  The tester helps team to make the demo successful for acceptance of the deliverables by product owner. Any issues if found should be recorded and should have a proper schedule for rework. The success of agile team depends on the tester and his involvement in issues resolution.


All the repetitive task should be automated at the earliest possible to utilize all the available time for process improvements and quality deliverables. Most of the time functional testers involved in the Agile with no or less automation appetite will results in time consuming testing process. The overall result is not so good which is otherwise possible. Automation can be as simple as checking if the environment is ready with the automated scripts rather than manually accessing the environment. Also running sanity scripts as soon as the code is deployed.

In Agile, testing is quite different than otherwise. Tester is individual contributor as well as responsible for team’s quality deliverable.

We will see more on testing in upcoming posts. Till then,   

Keep Agile!

Thursday, 21 July 2016

Myths of Software testing

Following are the some common myths of Software testing –

1. Anyone can test the application and couple of hour’s session is enough to start testing

Reality – Testing is a skill and an art. Testing is not as easy and as pie. Tester becomes great tester with experience. The tester should have qualities like Observation, Reading between the lines, Probing, Patience, Understanding perspectives, Knowledge about testing practices, Ready to dig deep,  Fearless and Strict follower of quality process.

2. Everything can be tested and application will be 100% bug free

Reality - The testing is to uncover the defects or bugs in the applications. Testing is related to cover the application functionalities with some definite scenarios. This is also called as coverage. With all the possible coverage only critical defects will be uncovered from the possible finite paths. There are always possibilities of having more combinations of inputs, process and could be different negative scenarios. These may uncover more defects and still it is not possible to assure 100% bug free applications.

3. Testing is less important than development and testing can be done any time during development lifecycle by any developer

Reality – In real world testing is as important as development or sometimes carries more value than the development. There are many examples of great looking software failing due to inadequate testing and quality checks. Developer as mentioned above will not have the art of testing and more important will not have the objective of testing. Hence developers cannot be testers unless formally trained and worked on couple of projects with actual testers. There are a few real life examples where developers who tried to enter in testing failed miserably. Testing starts early in the lifecycle, as early as the requirements are drafted. The static testing will uncover the requirement defects; here the domain experienced tester plays a critical role.

4. Everything can be automated and will not require manual testers. Any automation tool can be used to automate and QTP / Selenium are the only options to automate.

Reality – Purpose of Automation is to avoid repetitive manual tasks. If the task is not repetitive then investment on automation is not worth. For example one of the web applications required a few field validations on one of the form which manually takes 2-4 minutes, if this is automated it will take a day’s efforts, and automation tool. Such single features cannot be a candidate for automation. Technically functional testing alone cannot be considered for automation. However the regression suite can be a good candidate of automation. Manual testers will test the application manually and then those functional test cases which are critical to business will become a part of regression suite. This suite can be automated. Apart from automating regression suite few other repetitive tasks like smoke test and sanity tests can be automated.
Automation can be only feasible once the application feasibility test is done. There are many tools available in the market. Few tools are free to use and others may have some licensing fees. The application feasibility to involve but not limited to checking application technology, application environment, application architecture, deployment frequency and regression test cases are available.


Thursday, 14 July 2016

Protractor – Open Source - End to End testing

I would like to thank each one of you for your responses to all my earlier posts. Let’s continue our journey to open source testing tools.

Recently I got a request to write on Protractor. In one of my earlier projects I got an opportunity to work on Protractor. So I am writing on Protractor in this post.

Protractor is an open source end to end Node.js framework, primarily for Angular.js web applications testing. Before we get into details of Protractor, let’s quickly look at Angular.js.  

To know Angular.js, we must know HTML, CSS and JavaScript. If you have followed my earlier post on BDD then that will help to understand the Angular.js and Protractor.

Typical webserver request – response is as given below -


However, the request response will load the network with heavy traffic and will result in slow websites. The solution is instead of requesting for every time for each user action; add little functionality on client side. To achieve this we have JavaScript and one of the client sides JavaScript framework is Angular.js. This way we can have interactive and fast responding webpages.

Above diagram simplifies the concept of fast responding web page. Within HTML pages where ever it finds directive (marker of html tag) it tells Angular to run or reference java script code. I need to stop Angular.js here as we are interested to know Protractor.

 However if you are more interested in Angular then please take a free course on Angular.js -

Now let’s move on to Protractor. As we discussed in the beginning, Protractor is an open source end to end testing framework. It will test how users will see the web application, is the communication right between backend and front end etc. This is BDD with more of a white box testing. So as shown in below diagram we will use Cucumber to write high level scenarios. These scenarios will be further using Protractor tests. Protractor tests will then send requests to Selenium server. Selenium server controls the local browser.  

Webdriver (Selenium)
AngularJS App

Protractor needs following files
          1.  Spec file
          2.  Configuration file

Protractor communicates with Angular.js and waits for browser to finish the task. Hence Protractor does not need to wait or sleep. This makes it most optimized approach for automation.
Protractor allows tests to be organized based on Cucumber, thus allowing you to write both unit and functional tests on Cucumber as discussed in my previous post.

We can use Protractor on real browsers (Chrome, Firefox, and IE etc.) and headless browsers. For Protractor we need to have Selenium standalone server.
Protractor is useful if you want to test end to end however if anything fails during end to end tests, it is difficult to debug and find the issue.  

Protractor basic code is available at-