1 Comment

Binding a Floating Point Property to a TextBox With a StringFormat in WPF

By Ken Walker Senior Software Engineer

Microsoft’s WPF bindings are a fine piece of technology. They are flexible and powerful, allowing changes to your objects’ properties to ripple through the rest of your application with a minimal amount of coding effort.
Continue reading


2 Comments

Adding and Handling Click Events for NVD3 Graph Elements in Angular Applications

Larry Van Sickleby Larry Van Sickle, Senior Software Engineer

NVD3 is an easy-to-use JavaScript library for building charts and graphs. Very often designers want to have a chart be interactive, letting user drill down on data by clicking on elements of the charts. For example, on a bar chart of votes by state, the user could click on the bar for Texas and see a new chart with the votes by region for the state.

AngularJS is a versatile toolset for building browser-based applications.

How can a developer make the elements of a chart clickable using NVD3 in an Angular application?

Continue reading


Leave a comment

Agile Testers Can Increase Their Value by Donning Many Hats

by Rema Sreedharakurup, Senior Quality Assurance Engineer

Rema_Pic_BlogIt seems today that no discussion about software development is done until someone brings up ‘Agile.’ And for good reason, as Agile is all about agility – an Incremental and iterative delivery model which focuses on business value, encourages flexibility and rapid adoption to change. It’s based on collaborative efforts to achieve common goals.

The agile principles & values are very short and sweet, but in the real world, Agile is not that simple. Remember, it’s a collaborative effort that requires people – Developers, Testers, all the folks involved in the product development who are trying to perform their best in this transforming phase and get things DONE… all the while trying to get accustomed to new processes that get introduced to improve delivery, and where output is expected quickly. Though, as Albert Einstein once said, “in middle of difficulty lies opportunity.” Hence for me as a Test Engineer, this transition to Agile opened up a wide array of opportunity where I could wear many hats – as a developer, as a tester, a customer advocate, a constant learner, and much more.

Here’s how I see each of these hats fitting my head, and perhaps yours, too. Continue reading


Leave a comment

Codeception: A Clean and Simple Solution for Web Test Automation

by Troy Rudolph, Senior Software Engineer

troy-rudolphThe market certainly offers many test automation tools for testing in a variety of environments, but there is a relatively new one I particularly like for automated testing in web applications. While Codeception is intended primarily for testing PHP applications, the UI testing tools may also be used to easily create automated tests for web applications, as well.

In Codeception, these tests are referred to as acceptance tests. These tests are based on the notion of Behavior Driven Development (BDD). Essentially, BDD states that tests should be specified in terms of desired behavior. In the case of BDD, the behavior described is that of a user (or tester). To learn more about BDD, I would encourage reading the inventor’s article at http://dannorth.net/introducing-bdd.

A simple test might look like… Continue reading


Leave a comment

3 High-Octane Tools for Performance Testing

By John Cavazos, Senior Performance Test Engineer

John-Cavazos_cropAt one time, it was very common for companies to use a homegrown solution to performance test their software. This was mainly due to two factors:

  • the lack of available, cost-effective commercial testing tools
  • the complexity of their software

The situation is different today as it is common to find excellent, free, open-source tools online. These high-quality, stable, easy-to-use tools don’t have the inherent maintenance costs associated with using homegrown solutions.

There are now several industry standard tools available that can be used to performance test most, if not all of the features a company might need. What isn’t readily available can typically be added to these tools with minimal effort due to their open-source nature. Here are a few I have used: Continue reading


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


Leave a comment

An Introduction to Property-Based Testing

By Paul Bostrom, Senior Software Engineer

Paul-BostromDo your software testing teams ever discover bugs that seemingly should have been found by the developers’ unit tests? Quite often, the developer actually did unit test the software, but perhaps simply failed to think of scenarios using the problematic inputs. What if we could tell the computer to “think” of all the values used in our unit tests? This is the approach of property-based testing.

Instead of specifying a limited number of inputs and outputs for testing a unit of software, property-based testing specifies properties that a unit of software must hold, and then relies on the computer to generate the test values.

The authoritative library for property-based testing is called QuickCheck (http://en.wikipedia.org/wiki/QuickCheck), created for the Haskell programming language, but implementations of the library exist for many other popular programming languages. To illustrate the differences in these two testing approaches, we will use a simple example — testing a square root function. Continue reading