1 Comment

Tuning a Linux Server for High Performance Applications

By John Cavazos, Senior Performance Test Engineer

John CavazosIf you recently installed a new OS onto your brand new high-performance server for production or even just for performance testing and are not seeing the results in your application you were expecting, there is likely a good explanation. If you have not tuned your server from the default setting, you are likely hitting some of the default limits of the OS. Regardless of what OS you have installed, it is still necessary to tune the server to get the best performance out of your machine.

Typically, this job is performed by a system’s administrator. However, in smaller companies or start-ups that may not have such a support role, the task may fall to others. If that’s you, and you’re looking for a little guidance in getting it done, keep reading. By no means is this an exhaustive set of tuning that can be done, but more a general guide to the most common settings that we typically tune for performance testing. This article will also be limited to Linux systems for space and time considerations, saving Solaris and Windows for later discussions to come.

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

How to Quickly Solve Technical Problems With “Straw Man” Technique

by Chris Durand, CTO

ChrisDurand-B360Are you looking for new way to solve pressing technical problems? Well, I’ve found one, and I recommend it for anyone looking for a fast way to start a problem-solving process. I call it the “straw man” technique, and it’s pretty straightforward:

  • Think of the simplest possible solution or partial solution for a problem. This is the “straw man.”
  • Discuss with your team reasons why you think the solution will work or not. My favorite question to ask is, “Why won’t this work?”
  • Modify the straw man accordingly and repeat until you have a useful solution.

That’s it! I find myself using the straw man technique often; you can, too. Imagine you and your team are looking for answers on how to solve a challenging problem or implement what appears to be a complex feature. Think of a super simple solution that addresses at least 50-60% of the problem and ask the team why it won’t work. Then iterate from there until you reveal an acceptable solution. Continue reading


1 Comment

The Exciting Potential Of Agile Software Development

by Morgan McCollough, Senior Software Engineer

Morgan McCollough Bridge360In the first week of June, I made the trek to Caesar’s Palace in Las Vegas to attend the Agile Development and Better Software Conference. The conference itself was only two days, but I attended a three-day Agile scrum master training class beforehand. It rounded out a full week immersed in all things Agile.

I’ve worked with a number of clients who claimed to have adopted Agile in one form or another. I’ve also read quite a bit about it, but prior to my week in Las Vegas, I had never received any formal training. The trip was eye opening, and it was a great opportunity to talk with people from across the industry.

What really became obvious was just how many companies are successfully implementing Agile processes at both the software development and program management levels. Some are achieving pretty dramatic results, with up to 30% shorter schedules and 75% fewer defects on average! However, learning the formal practice of Agile also made it clear how much dysfunction still exists, even in companies claiming the Agile moniker. 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


2 Comments

Top 5 Ways Software Quality Assurance Supports the Development Team

by Chris Durand, CTO

ChrisDurand-B360Are you thinking Development and Quality Assurance are separate, independent activities? Think again. Development and QA go hand in hand, and the better (and earlier) both teams are engaged in solid quality processes, the stronger your software will be. Here are five ways software quality supports your development team.

1. Software Quality Reduces the Cost of Fixing Bugs

At the risk of beating a dead horse, if you are not familiar with the cost of fixing a bug at various stages in the software lifecycle, this graph is crucial:

Adding more to my investment

As you can see, the later in the development cycle a bug is discovered, the more it costs to fix. If you find a problem in the requirements analysis phase, you simply change the requirements document to fix it. If you don’t discover that same issue until you are testing your beta release, you have to change the requirements document and rewrite code and retest. A good QA process will find defects earlier in the development process and reduce the cost of fixing those defects.

2. Software Quality Improves Requirements

Doing requirements well is hard without a strong software quality process in place. In many projects, testing begins too late since testers don’t start writing test cases until they have (hopefully) working code in their hands to break. If this is your process, you are missing out on the benefits of having the QA team engaged early on in the process. Strong QA professionals have an eye for detail and ensure your requirements are clear and testable. If your QA team cannot start writing test cases based on requirements, it is likely you have insufficient detail in your requirements documentation. This means you are leaving it up to a developer to self-determine many details of how your application should work instead of building a customer-driven application. So if your QA team says they cannot start writing test cases until they have a working application to reference, get them involved early and shore up those requirements.

3. Software Quality Improves Predictability of Releases

Predicting time to completion is challenging on poor quality projects with loose processes and parameters. Again, testing early is key. Feature development has a finite list of things to do, but the number of bugs in an application is unknown until you start testing. A strong QA process tests early and often, so at all stages in the development process you have an idea of where you stand. A weak QA process tests too late or not very thoroughly, and you find your dates slipping because you are still finding more and more bugs with no end in sight. High quality software also has fewer customer support issues and therefore your team can stay focused on new features instead of getting randomly pulled off to deal with the latest customer crisis and torpedoing your release schedule.

4. Software Quality Allows You to Refactor with Confidence

Writing software is a lot like gardening. Old plants must be removed, new plants added, existing plants trimmed and dead growth removed. Failing to keep your software well-groomed results in buggy software that is difficult to understand and expensive to maintain. You find you can’t easily add a simple feature because it breaks something elsewhere. To avoid this you must constantly keep your software pruned, and restructure parts that no longer make sense. Strong software quality allows you to do this with confidence since you know how the software was supposed to work before you made changes, and you can verify the software still works after your changes. If you have an automated unit or functional test infrastructure in place, that’s even better.

5. Software Quality Improves Team Morale

No one likes working on projects that have a bad reputation within the company or with customers.  High quality software improves the morale of everyone from the sales team to the support team. The sales team has confidence that the product won’t blow up in their faces during a demo and that they won’t be damaging future sales opportunities by selling the customer a “lemon”. Developers feel more pride in their work and perform better since they want to maintain the good reputation for the project or team. The support team does not dread yet another call from an upset customer due to issues that clearly should have been caught during the development process.

In summary, if you don’t have strong quality practices in place, your development team (and the rest of the company) is missing out! Get your QA team involved early and often in your development process and watch your development costs shrink, schedules become shorter and more predictable, and customer satisfaction soar. Happy testing!