Theme images by Storman. Powered by Blogger.

Software Testing

[best practices][feat1]






Most Recent

Random Posts




Wednesday, April 27, 2016

How to verify if a checkbox is checked using Selenium Webdriver

- No comments

It's quite a common scenario that we may come across where we need to verify if a particular check box is checked. If not checked we may want to mark it as checked. In this post let's see 

how to check if a checkbox is selected in Selenium WebDriver with C#

First of all make the check-box as a web-element.

Or using findElements code You could instead do as shown below,

What do you think on above selenium topic. Please provide your inputs and comments. You can write to me at

Thursday, April 21, 2016

Challenges and Benefits of Adapting to Agile Methodology

- No comments

It's always a nightmare when we usually think about getting and setting a team to work together. A team comprises of resources with different attitudes, personalities and roles, working in a similar environment and that is the reason you are in need of some guidelines  and processes in place to keep thing always good and move forward. But trust me, in the long run still you will come across so many challenges. 

Agile Is Fast, Flexible and Iterative.

Today, “agile” is a common usage /practice in many of the software companies. As we all know it's main purpose is to solve many of the problems software teams encounter using the traditional waterfall methodology. In contrast to waterfall, agile is an iterative, responsive approach to building software. It is meant to provide more freedom for the designers and developers as they work on individual modules.

In agile, usually the teams work in sprints (may be short or long), instead of implementing the whole software applications from scratch to finish. The duration of a sprint varies from 1-2 weeks based on the requirements. The main advantage is that, by using an approach like this, both the software testing and customer feedback happen simultaneously rather than waiting for the completion of entire software for attaining these things. 

Waterfall to Agile - What made the transition ?

As we all know, every project or products is entirely different in the world of software development. There is a traditional approach of sequential process  followed by the software teams which was called “Waterfall”.

But in the past several years most of the companies have moved away from the waterfall model. There are a number of reasons for this shift. Mainly this approach was not flexible enough for the fast paces ever changing world of software.

With this approach you will define all the requirements up front and chances are there you stuck with them for the duration of the project. That means, literally you could be building something that was conceived several months before and it may not even be relevant anymore in the current context.

This linear approach has always restricted the software teams and the products they were building. But still, waterfall remained the norm for many decades.

Challenges in adopting agile methodology and how to overcome them. 

 I would say Agile is always a new way of thinking, managing and working. But it's a fact that just like any shift or change in process, many teams have struggled to adopt agile.

However, like any change or shift in process, many teams have struggled to adopt agile. It requires a new way of thinking, managing, and working. Here are some of the common challenges in adopting agile methodology and how to overcome them.

Challenge #1: Getting your client on-board with agile.

For many of the clients, Agile is quite an unfamiliar way of working together which could eventually be really uncomfortable. As in the case of software teams, Clients/Customers are also resistant to change. But there are ways you can overcome this fear of adopting agile though.

Solution: Build trust.

It’s really important to build trust from the beginning, and continue building it after each sprint. By engaging the customer the right way, you’ll build that trust and they will become more comfortable and excited about working with you in this capacity. Worst case scenario is they don’t get comfirtable with agile and you continue to practice agile internally, while bringing in the traditional project or account manager to take on the role of product owner.

Challenge #2: Agile is a cultural shift.

Agile methodology requires your organization to encompass certain values and beliefs. It always require a lot of trust from management side that your team can not only do the work required, but also do it in the best way possible. Your team needs to believe in providing value to both the customer and the product, and you need to empower your team to be creative, make decisions, and work together. Conversely, your team needs to be independent and there by should be able to do these things – make decisions, work well together, and think outside the box.

Solution: Hire an agile coach.

If you’re new to agile or finding that your team is struggling with the shift, it might be worth bringing in an experienced agile coach to avoid some of the issues. If that’s not an option for whatever reason, empower your team to get out in the community and learn from other agile experts.

Challenge #3: Many people think agile should be done exactly a certain way.

It’s often thought that in order to be agile, you need to follow every rule and guideline as instructed. Sure there are a lot of ideas, techniques and practices that go into “agile”, but the perception that there is only one way to be agile is not correct. In fact, it’s far from the truth.

As Anjuan Simmons says,

“Agile is not a one-sized-fits-all methodology that works for every situation. It is a framework that is meant to be flexible.”

Solution: Try different approaches.

In agile itself there are many approaches. Select the one that suits you and go for it. Scrum is by the most popular. But others are also fairly popular today. Search and find these approaches and see which one suits your team the most. Once you settle on one, feel free to change it so that it works with you and your team. It’s ok to only implement some of the techniques.

For example, Maybe one week sprints are too short…try two weeks, or four weeks…whatever works for you team. Likewise, if work break down structure or planning poker isn’t working for estimation, try a different estimation technique.  If daily stand-ups are getting stale and lacking value, move to every other day. Try new things until you find what works for you.

In Conclusion

In short agile enables us to move quickly and easily. Lots of advantages are there to working this way, but it can be a big undertaking and a significant shift in the way teams think and work together. Always know that while adopting agile, the more you prepare and the more you experiment with different ideas and techniques, the better off you’ll be. Never ever try to force it on your team – find what works for you, your team, your customers, and I would say for sure, With this new way of thinking, managing and working, you’ll be on your way to a fast, flexible way of working.

I hope, you might have found these tips to avoid challenges in adopting agile methodology useful. Please lemme know your views and comments .

Wednesday, April 13, 2016

20+ Must have tools for any Software Tester to make their job easier

- No comments
I’ve been working as a tester for more than 6 six years. During this period quite a lot has changed in the common QA practices, and I’ve always tried to keep up with times. As I have quite a decent experience in various types of testing, from time to time my colleagues ask me of some advice concerning various tools that simplify performing their routine tasks. This finally brought me to the idea of writing this blog post.

So, I’ve decided to make a list of 20+ Must have tools for any Software Tester to make their job easier.  

Spread Sheet: The most important tool which could be used for Test planning, test case writing, Test analysis etc.

FreeMind - A brain storming tool which have better features for a detailed ideaation.

Jing Fastone Capture /  - Capture, Edit and upload Screenshots.

Screencast-o-maticThis is a screen and webcam recorder, to record on-screen activity for short tutorials, visual presentations, and communicate with complex bugs while you demonstrate!

Measure It - A mozilla/chrome addon which could be used for the verification of pixel perfect designs. 

Texter - Writing test cases or defects , Text substitution app Texter saves you countless keystrokes by replacing abbreviations with commonly used phrases you define

Bubbl - Mind mapping tool , great for brainstorming / idea / sharing information

EtherPad / - is an online document collaboration tool which works in real time. In other words, EtherPad has allowed multiple people to work on the same document at the same time over the Internet.

Log-Watch - creates a log file as it goes, reporting strange events and possibly errors that might not appear through the UI

PerlClip - This will generate text , text count and more

Rapid Reporter - Can be used for Session based testing / Exploratory testing

Color Cop - returns RGB values

WebWait - check the speed of your web application

Firebug - Xpaths and JavaScript errors!

Pingdom - Test your page load speeds The Full Page Test gives you a detailed visual report on the load time of each element (images, CSS, JavaScripts, RSS, Flash and frames/iframes). Objects included in javascript are ignored

GTMetrix:  GTmetrix gives you insight on how well your site loads and provides actionable recommendations on how to optimize it.

METS - Minimal Essential Test Strategy (METS) - These are Excel spreadsheets but help in planning and estimating tests.

Beyond Compare - Comparison tool

Sikuli - Sikuli is a visual technology to automate and test graphical user interfaces (GUI) using images (screenshots)

Paloma Print Perfect - STREAMDiff - Comparison of PDF docs

IcuTest - GUI Unit Testing for WPF -

LucidChart which is another Visio alternative which is web-based. It has real-time collaboration so lots of people can work simultaneously.

Dia (Visio alternative, helpful for drawing process flow diagrams, etc for test planning) -

Test Data Generation - This is a really cool web script that you can use for free and even download the script for use on your own server.

Selenium IDE: We can use this tool to generate locators of web elements quickly and easily. This powerful Firefox extension is really helpful in test automation. You can use this tool also for finding and testing already generated locators, which you use in your automated tests, for checking XPath existence on the page, testing the work of Selenium methods with them.

Xenu’s link Sleuth: This is a great tool for checking links. It was named the fastest link-checking software by industry authorities. Apart from checking for broken links, the tool provides a much broader functionality, which is useful primarily for website optimization.

Feel free to add more tools that make your testing Smarter!

Monday, April 11, 2016

How to download PDF files automatically in Firefox using Selenium WebDriver

- No comments

Here I am trying to explain you, how to download PDF files automatically in Firefox using Selenium WebDriver.

I always believe that learning through examples are the right and easiest way and hence let's see a  complete example of how to save PDF files automatically in Firefox using Selenium WebDriver.

1:  # Environment Tested:  
2:  # Windows 7, Ruby 2.0.0p451, Selenium 2.41.0, Firefox 29.0.1  
3:  require 'selenium-webdriver'  
4:  profile =  
5:  profile[""] = 2  
6:  profile[""] = 'C:\\'  
7:  profile["browser.helperApps.neverAsk.saveToDisk"] = 'application/pdf'  
8:  # disable Firefox's built-in PDF viewer  
9:  profile["pdfjs.disabled"] = true  
10:  # disable Adobe Acrobat PDF preview plugin  
11:  profile["plugin.scan.plid.all"] = false  
12:  profile["plugin.scan.Acrobat"] = "99.0"  
13:  driver = Selenium::WebDriver.for :firefox, :profile => profile  
14:  driver.get('')  

A walk-through

Prevent Firefox from popping up "Save file" dialog

You may know that Selenium itself doesn't interact with system-level dialogs, in order to download PDFs as part of the browser automation process, it requires the help from either additional 3rd party frameworks or a better approach that could handle the downloading automatically.

Firefox's download manager preferences are controlled by some properties defined in about:config page, which can be set programmatically while instantiating FirefoxDriver using Selenium WebDriver.
  • controls the default folder to download a file to. 0 indicates the Desktop; 1 indicates the systems default downloads location; 2 indicates a custom folder.
  • holds the custom destination folder for downloading. It is activated if has been set to 2.
  • browser.helperApps.neverAsk.saveToDisk stores a comma-separated list of MIME types to save to disk without asking what to use to open the file.
1:  profile =  
2:  profile[""] = 2 # use the custom folder defined in "" below  
3:  profile[""] = 'C:\\'  
4:  profile["browser.helperApps.neverAsk.saveToDisk"] = 'application/pdf'  

It is worth noting that the MIME type defined here is application/pdf, which is a type that most PDF files use. However, if the target PDF file has a non-standard MIME type, then "Save file" dialog might still show up. In order to fix this issue, the actual MIME type has to be added into browser.helperApps.neverAsk.saveToDisk property, which can be checked out using either of the following approaches:
  • Upload file to online tools like What MIME?
  • Download file and monitor MIME type in Chrome's developer tool or web debugging proxy like Fiddler, Charles, etc.

Prevent Firefox from previewing PDFs

For built-in PDF.js viewer

With the release of Firefox 19.0, PDF.js has been integrated into Firefox to provide built-in ability of displaying PDF files inside browser. It tries to parse and render PDFs into HTML5, which can be automated using Selenium WebDriver in theory. However, to download PDFs instead of preview in Firefox, another about:config entry needs to be changed to disable PDF.js.
1:  profile["pdfjs.disabled"] = true  

For third party PDF viewers

Except for Firefox's built-in PDF viewer, there might be other third party plugins preventing Firefox from downloading PDFs automatically. If a machine has Adobe Reader installed, then default PDF viewing setting in Firefox might have been set to Adobe Acrobat without notice.
To avoid previewing PDFs with those plugins, two more about:config entries need to be configured when starting WebDriver instance.
  • plugin.scan.plid.all needs to be false, so that Firefox won't scan and load plugins.
  • plugin.scan.Acrobat is a key that holds the minimum allowed version number that Adobe Acrobat is allowed to launch. Setting it to a number larger than currently installed Adobe Acrobat version should do the trick.
1:  profile["plugin.scan.plid.all"] = false  
2:  profile["plugin.scan.Acrobat"] = "99.0"  

Friday, April 1, 2016

5 things to remember while going for Software Test Automation

- No comments

Usually in testing, there is a saying that: 'if you do something more than once – automate it'. Software testing, where we routinely perform similar actions, is a perfect base for automation. In the modern software development, with the use of continuous deployment approach and microservices, everyone wants to deliver features fast and often. Therefore, test automation becomes even more important, yet still facing some common problems. Based on my experience, here is my list of top 5 things to remember while going for Software Test Automation.


Always-red ? False Fails? We all know that. Stability of automated tests is one of the most obvious issues, yet most difficult to obtain. Even big players like LinkedIn or Spotify admit to have struggled with it. While designing your automation, you should put extra attention to stability, as it is the most frequent cause of failure and test inefficiency. Writing tests is just a beginning, thus you should always plan some time in sprint for maintenance and revisions.

UI perspective

Majority of modern applications are web-based, therefore the most preferable way for functional testing is from the UI perspective. Despite their usefulness, browser tests also have some substantial problems like slow execution time or stability randomness.  Since we’re in the world of microservices, it’s worth to consider dividing tests into layers – testing your application features directly through webservices integration (or backend in general) and limiting UI tests to a minimal suite of smoke tests would be more efficient.


Because of many dependencies over the systems, mocking services become a popular pattern and are also often forced over test environment limitations. However, you should pay great attention to the volume of your mocked checks – mocks can miss the truth or be outdated, so your development would be held on false assumptions. There’s a saying: “Don’t mock what you don’t own”, which means you can stub only these pieces of architecture that you’re implementing. This is a proper approach when you test integration with the external system, but what if you want to assume stable dependencies and test only your implementation? Then yes, you mock everything except what-you-own. To sum up, the mocking and stubbing strategy can differ depending on test purposes.

Tight coupling with framework

That’s a tricky one. Developers often tend to choose frameworks and tools based on the current trends. The same applies to test frameworks where we have at least a few great frameworks to use just for a test runner, not to mention the REST client, build tool and so on. While choosing a technology stack, we should bear in mind the necessity to stay as much independent from tools as we can – it’s the test scenario that is the most important, not the frameworks.

Keep it simple

Depending on your team structure, acceptance tests are implemented by developers or testers. Usually the developers are better in writing code, while the testers have a more functional approach (it’s not a rule, though). Automated test are not a product itself, but rather a tool, therefore I would put functionality over complexity. Your test codebase is nearly as big as the tested system? Try to categorize tests according to their domain or type. Adding new tests requires a time-consuming code structure analysis? Sometimes a more verbose (but more readable) code is better for your tests than complex structures.


It takes proper planning, realistic expectations and a solid commitment to make test automation work. The worst-case scenario that can happen to your automated tests is abandoning them due to relatively simple, yet common issues. Time saved by automating simple test cases can be used for executing more complex scenarios manually, and that leads to better software quality and higher employee motivation in general.

If you have some other interesting experiences with test automation, please comment below!