Monthly Archives: April 2014


by Leave a comment

Is Pairwise Testing All It’s Cracked Up To Be?

By Morgan McCollough, Senior Software Engineer

Morgan McCollough Bridge360Testing software can be a very complicated, time-consuming process. The number of possible inputs to a system and the ways in which they interact can quickly create a situation where the set of possible test cases is, for all practical purposes, unbounded.

In order to find the problems in a piece of software, a tester’s job is in large part about finding intelligent ways to pare down the possible test scenarios in such a way that the majority of problems are found in a reasonable amount of time.

To this end many techniques have been proposed over the years as shortcuts to finding the best set of test cases for locating the most software bugs in a time-efficient manner. One such technique that seems to be gaining in popularity is Pairwise Testing, also referred to as “All Pairs”. Continue reading →


by Leave a comment

Learning Test Automation: Choice? Or Compulsion?

by Lakshmi Kirthivasan, software QA engineer

Lakshmi_KOur team at Bridge360 is very focused on quality in the software production process. Expertise in all forms of testing helps us provide our customers with a higher quality product, so it’s critical that we have expertise in testing.

I have some programming skills and years of manual testing experience, but decided I wanted to become more skilled at automatic testing. Because all of the projects I’ve worked on over the last six years required only manual testing, I was mostly unfamiliar with the current tools available for automatic testing. This prompted me to do some research to see which tools were available and most widely used.

My research on job boards in both the US and India led me to the conclusion that seemingly everyone in my industry is embracing the fascinating world of automation. It was rare for me to find any job which focused only on manual testing. Today’s testers are expected to know one or more automation tools like Selenium, Watir, Cucumber, Test Complete and FitNesse. Numerous testing tools are loaded with standard functions and options but still don’t provide a complete solution for many testing situations. Typically, some tweaks to provide added functionality are needed to fit the requirement. Continue reading →


by 2 Comments

How a QA Team Fits into an Agile, TDD/BDD World

by Chris Durand, CTO

ChrisDurand-B360Let’s be honest, Quality Assurance is a necessary evil. Many of you have probably wondered why developers can’t just get it right the first time. Why do we pay developers to write bugs, and then pay testers to go and find them?

The answer simply stated is — writing software is hard. Software developers need to be extremely detail oriented, yet also keep the big picture in mind. They must balance short-term tradeoffs with long-term considerations. They often have to learn new tools and technologies with each project while balancing the demands of outside influencers. Oh, you needed that feature or bug fix done yesterday? And you want that application to work on all browsers released in the last 3 years (that’s 24 versions of Google Chrome alone since March 2011), plus mobile? It’s no wonder developers struggle to write perfect code every time.

While it can produce quality results, the old model of throwing code over the wall from the development team to the QA team is inefficient. We that build software have to do more for less, faster, and in a more complex environment than ever before. The rise of automated unit testing and Test- or Behavior-Driven Development (TDD and BDD) is an attempt to realize improvements. By testing at the core (that is, with the developer), we find bugs as early as possible (which yields tremendous savings as discussed in the post https://bridge360blog.com/2013/12/04/5-ways-qa-supports-development/). Automated unit testing also makes it easier to update the application going forward by identifying unexpected broken dependencies in the code before they get in front of a customer. Continue reading →