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

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

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


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

Leave a comment

How QA Helps Nurture Long-Term Customer Relationships

By Rema Sreedharakurup, Senior Quality Assurance Engineer

Rema_Pic_BlogI have recently facilitated discussions with both peers and clients about the value that software quality assurance brings to a customer’s business.

Although it is clear that a QA engineer’s job is to accurately report product quality, there are opportunities to deliver value beyond what is expected and in the process nurture a long-term customer relationship.

During a client engagement, we select our testing approach based on factors ranging from budget, scope, team dynamics, release schedules, and in many cases alignment with customer demands.

Over time, the selected approach matures and becomes optimized to suit the nuances that exist within the customer’s business model. The time period in which the approach becomes more mature offers our QA team opportunities to engage with the client at a new level, where we help them with their business and with their software delivery process. Once this normalization period is complete, our QA engineers have learned the business and are capable of identifying additional opportunities to increase the value that the QA efforts can bring to the business. Continue reading

Leave a comment

Making Automated Tests Data Driven

By Nadine Parmelee

Nadine-Parmelee1-bSo you’ve decided to start an automation project and your team has taken the time to do the tool analysis. Let’s also assume you’ve gotten your team trained on the tool of choice. What comes next? Now is the time to sort out the best way to set up an automation project for the cleanest data and project timeline. Hopefully, the automation and manual test teams have been analyzing which tests should be automated first, and now the automation scripting can begin. Many projects start with automating the manual test cases as they are written and then later expanding on those tests and making them more efficient. I would suggest that there is an even better way to start the automation project.

When analyzing the tests to be automated, analyze the data used for those test cases as well. Are there different expected results or different application features for different data types or options used in the test cases? Does selecting one set of data options create a different selection of data options for another field or dialog? Do the manual tests only cover a limited amount of test data? Now is a good time to enhance these tests and determine how the automation project can enhance your overall testing effort. For situations where the manual tests cover the basic application functionality but a limited set of data points, data driven tests may be a key benefit to your automation effort.

An example of this could be a manual test case for an application that has different data choices presented if a different region is selected:

Region: North America
Size Options: 2, 4, 6, 8, 10, 12, 14, 16, …
Color options then based on size selected

Region: Europe
Size Options: 34, 36, 38, 40, 42, 46, 48, …
Color options then based on size selected

Very often the manual tests will only hit one or two of the size options and some of the color options that flow down the decision tree from there. The automated tests can validate each region, size and color combination in probably the same amount of time as the more limited manual tests. This can be a quick expansion of the testing that is already planned which yields a higher return on investment as well as an increased quality level. This type of automation also frees up the manual testers to concentrate on other investigative testing that can be done. Try data driven tests in your automation project, and let us know how much time and effort you saved.


Do Software Testers Need Engineering Ethics?

By Jerry Cavin, Senior Software Engineer

Jerry Cavin is also an Adjunct Professor of Computer Science and Astronomy at Park University.

When I was student learning to become an engineer, one course not required for my degree was Ethics. But because of my curiosity (and friends that were Philosophy majors) I took some classes in Logic and Ethics. The study of Ethics is the branch of Philosophy that examines the principles upon which something is determined to be right or wrong; and I quickly became fascinated with its history and the many debates on ethical issues. But, I was also surprised to learn of the links between the ancient philosophy of ethics and modern day engineering.

One of the most important Philosophical works on Ethics is Aristotle’s collection of scrolls called Nicomachean Ethics, which became the foundation in the study of theology and law from medieval times and is still relevant today. Aristotle asserts that the highest aim in life is happiness, which is attainable by living a life of virtue. He identified two types of virtue that must be realized. The first is moral virtue, which is developed by the daily repetition of moral acts. Moral virtues are an individual’s positive acts as defined by their societal system of beliefs. They were implemented as judicial laws and theological laws.

The other type of virtue Aristotle declared is intellectual virtue, which is developed through education. Aristotle’s intellectual virtue rose to prominence during the medieval times in the form of Guilds — a word derived from the Saxon word “gilden” which means “to pay”. Guilds were originally established to provide its members in a small geographic area with a stronger voice to protest the excessive taxes levied by the lords and land owners. Members of each profession would often create their own guilds. From Apothecary Guilds to Writer Guilds, these Guilds created the first ethical guidelines for the professional worker. In addition, the guilds also regulated pricing policies and quality of workmanship to protect the end consumer.

As the free market expanded geographically, the localized medieval guilds became impediments to rapid economic growth. Trade over vast regions could not be controlled by the guilds whose members were confined to cities and villages. During the Industrial Age the field of engineering experienced rapid growth and the guilds were replaced by trade unions to represent the workers. And professional qualifications became managed by universities and professional societies. Professional societies were created for many occupations including architecture, law, medicine, and engineering. During the 19th century, engineering evolved into its own distinct profession, as well, and professional societies soon followed. In the United States, the American Society of Civil Engineers was formed in 1851, the American Society of Electrical Engineers in 1871 and the American Society of Mechanical Engineers in 1880. However, in the early professional societies, ethics were more commonly regarded as a personal responsibility rather than a professional one.

At the beginning of the 20th century there were a number of catastrophic failures with significant loss of life due to poor quality of engineering practices. In 1904 a train was crossing the Eden Colorado Bridge when the bridge collapsed killing 111 people. In 1907 and 1916 there were two Quebec City Bridge collapses with a combined total of 86 people killed, and the Division Street Bridge in Spokane Washington collapse with 5-7 (reports vary) people killed. These are a few of the major structural failures that had a profound effect on the engineers and professional societies. In response to these failures they established a set of formal qualifications for professional engineers that involved a combination of education and experience.

Today’s professional societies continue a long and noble goal of protecting the public by establishing a standard of intellectual knowledge and ethics of their members. In addition, these professional societies established and adopted the first ethical guidelines for engineers. Societies such as the ACM Codes of Ethics, the IEEE Code all have created ethical guidelines for software engineers and electrical engineers. The professional society for software testers is the Association for Software Testers, which has simply adopted the ACM Code of Ethics. Consequently, some software testers are concerned that existing ethical guidelines for testers are not specific enough. One of them is James Bach – software tester, author and lecturer – and I encourage you to read his thoughts on the subject and his list of ethical principles.

At the turn of the 19th century the establishment of ethical guidelines for engineers was produced after a series of catastrophic events that resulted in loss of life. Recently we have witnessed a series of catastrophic software failures. After spending millions of dollars the government rollout of the Healthcare website has been a total flop. In 2007 software bugs that were found in medical devices caused tens of thousands of the devices to be recalled. In 2004 the Air Traffic Control System in the Los Angeles airport lost contact with 400 airplanes when software caused the voice communication system to shut down. In 1999, the NASA Mars Orbiter, a $125 million spacecraft, was sent crashing into Mars because of a simple mathematical software mismatch. In light of these events, perhaps it’s time again to remind the next generation of test engineers of their ethical responsibilities to protect the safety, health, and welfare of the public. As Aristotle put it, “we are what we repeatedly do; excellence, then, is not an act but a habit.”

Leave a comment

Analyzing and Selecting the Right Software Automation Tool

By Nadine Parmelee, Senior Quality Assurance Engineer

Nadine-Parmelee1-bWith all the tool choices available today, selecting an automation tool is a project all on its own. There are a number of variables to consider when selecting an automation tool, as the upfront cost of the tool is not the only consideration. There are potential costs in tool configuration requirements as well as resource training. Next you have to identify the resources you need and how long they will be needed for your project. Taking the time to do the research for selecting the right tool is essential for both tactical and strategic success. Below is a list of elements to take into consideration when researching automation tools:

  • Is this tool recommended for the programming language used for your product?
  • Initial cost per user of the tool – Is it a “per seat” cost or is there a “site” cost available?
  • What are the maintenance costs of the tool?
  • What are the configuration costs to interact with defect and manual test case tools?
  • How many systems the tool can be utilized on?
  • Are there any training costs?
  • Is customer support provided by the tool vendor?
  • What is the expandability for the future for platforms and environments?
  • What expectations should the tool fulfill for test coverage?

We have helped a number of clients with their tool analysis and have seen firsthand how there is no single solution available for everyone. In some cases clients have wanted to use tools they already had purchased corporate licenses for, and we suggested a different tool because of application compatibility or the amount of time that would be involved to create workarounds to best fit the tool for their situation. Some clients look for “free” open source tools thinking their return on investment will be greater, yet they neglect to account for configuration costs and the costs of training involved in getting the resources up to speed. Moreover, there is the need to provide back to the open source community any changes made with the code that might help others; again a time-consuming effort to comply with while still getting the product tested.

To ensure that your team selects the right tool, make sure they are asking the questions that are most relevant and essential to your requirements. This will advance the effort forward without losing non-essential time exploring too many options. I’d recommend that a BRD (business requirements document) for the tool evaluation effort be created up front. This doesn’t necessarily need to be overkill, but collectively focusing stakeholders on requirements is worth the effort in order to keep the business and technical team in sync with expectations. Having a clear understanding of your automation project needs defined and understood is always a best practice. I also recommend that the selection process include obtaining evaluation copies of the potential tools and give your team time to evaluate them. Some tools might be eliminated from consideration quickly while others may necessarily require more time to evaluate.

In my opinion, one of the best tool evaluation methods is to take one of the most complex tests expected for the automation project and try to create those automated scripts with the evaluation packages. Make sure your project team keeps the primary automation project goals in focus; if data creation is the goal of the automation project, an automation tool that doesn’t work with a specific GUI screen or control may not be out of the running. If user interaction is the primary concern, a tool that works great with the GUI but not so great with your database structure may still be a viable candidate. It is important to analyze the strengths and weaknesses of the tools against your project needs and pick the one that will be the most efficient for your situation. Your automation project requirements may get adjusted along with the tool evaluation process as your team evaluates both together.

Test Automation is essentially a strategy that provides acceleration to market with confidence, if well executed. Taking the time to plan well and select the right tool or tools is critical for that confidence. Remember, once you take steps toward test automation, you should consider this effort as part of your ongoing quality assurance ecosystem. You will want to ensure you keep your automation scripts up to date as your product changes over time.


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!