Skip to content

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.

Testers who have so far been doing only manual testing are more or less forced to understand and learn coding and adapt to Test Automation and Agile Practices like TDD (Test-Driven Development). As more and more companies move from the traditional waterfall development process to Agile, testing is done more through a combination of manual and automation technologies, and programming skill plays a major role.

So do all testers have programming knowledge? No. But once a tester decides that he is going to transition from manual to automated testing, he should be prepared to acquire programming skills too. Software test automation can be a complex task, and this transition may be difficult at first, but with proper guidance, attitude and willingness to learn, it should become easier over time. It just depends on how well each person is utilizing the opportunity given to him.

Whether testers seek automation training of their own accord, or because their companies require them to, they should keep in mind that it can help their careers immensely. They should also understand that advancing their testing skills – for either manual or automated testing, or both – can help them and their companies build a much higher quality software product.

Happy Learning and Testing.

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 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.

But unit testing is not enough. Just because you tested individual pieces of an application doesn’t mean it will all work together as expected. In 1999 NASA lost its Mars Climate Orbiter ( because two software components that were thoroughly tested in separate environments did not work together once combined. Total cost of the project: $328 million. Oops.

So, as we ask developers to shoulder more of the burden of testing, what are the top 3 ways QA professionals are bringing value to agile teams? I’m glad you asked…

  1. Have Team Members Dedicated to Quality. Agile practices make quality a team responsibility, but don’t interpret that to mean ‘we don’t need any testers.’ Creating things and breaking things are different skill sets, and developers are focused on building things. Having team members with core strength in testing is crucial to ensure quality is not forgotten in the excitement to build the “Next Big Thing,” or rush something out the door to make a demo or ship date. Your QA team should be flexible enough to take on other team tasks besides testing within your agile team, but they can never lose sight of the fact that they are the last line of defense against bugs impacting customers. Your QA team should be involved from the beginning of your project working hand-in-hand with development to ensure automated unit testing is built into the core of your application. This should be supplemented by a solid quality plan, automated functional testing and, where necessary, manual testing. The QA team should also be the final judge of whether or not your product meets the quality standards set by your organization.
  2. Maximize Your Skill Sets and Productivity (and minimize your resource costs). The development team should work with the QA team to build test infrastructure into the application. Your development team should then use that infrastructure to test for the obvious (to them) test cases. The QA team can then flesh out those tests more extensively to improve test coverage and find all those edge cases that developers tend not to address and ensure your application meets your organization’s quality standards. It’s the 80/20 rule where 20 percent of the work will take 80 percent of the time. And the more cost-efficient QA resources should be working on that 80 percent, not the more expensive development team.
  3. Don’t Forget System and Integration Testing. Once you have many components or systems built, you must test that they all work together smoothly. A separate, dedicated QA team is well utilized doing integration testing of multiple components and systems, or you may need to bring in some additional testing resources for a few sprints to ensure this testing is done right to avoid Mars-Climate-Orbiter-like disasters.

Despite trends towards developers doing more testing, the role of the QA professional isn’t going away any time soon. Instead, the way QA teams are working is evolving rapidly to ensure applications are delivered more quickly, more efficiently, and with the right level of quality. It should be very interesting to see how the profession progresses over the next 5-10 years.

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 (, 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.

A typical unit testing approach involves using a testing framework that allows us to state assertions that our function, ‘sqrt()’, should satisfy for specific inputs and outputs. Our assertions might be in the form of ‘sqrt(16) == 4’, and ‘sqrt(36) == 6’. Our test framework will automatically run all of our assertions, and give us some amount of confidence that our function is implemented correctly.

The downside of this approach is that we must manually specify our assertions, which takes time and mental energy to think of so-called “boundary” or “corner” cases that our function might have trouble handling. We may also have a tendency to focus on getting our finite set of tests to pass without thinking of the broader requirements that our function should hold. Another limitation of this unit testing approach is that we don’t gain any advantage by running our test cases multiple times, as it will always return the same results given our specific inputs.

When we incorporate property-based testing into our development process, we greatly increase the range of inputs that our software is tested against. Instead of specifying a set of inputs and outputs for testing our function, we would use a property-based testing library to specify a set of properties that the inputs and outputs must hold. The library will then generate a much greater number of test cases than we are able to specify in our unit testing framework. These test cases will also be randomly generated, so running our test multiple times will increase the variation of the inputs tested. I will use the ‘sqrt’ function to demonstrate how this works.

A typical property-based testing library should include functionality that generates random positive integers. Using the library we can specify a property that for every generated integer, we can multiply it by itself to generate the square, and then pass the squared value to the ‘sqrt’ function. The code for specifying this property may look like ‘i == sqrt(i * i)’ for every positive integer ‘i’ generated. Once we have defined our property, we can run the test specifying the number of random inputs to generate. The testing library will then handle the work of generating the inputs and verifying that the property holds for each input. Since the inputs are randomly generated, running the test multiple times increases the chances that we will find a value that causes the property to fail.

Most property-based testing implementations also have a feature that will attempt to ‘shrink’ a failing test case to a minimal example. This is a useful feature when debugging that allows us to isolate problematic inputs.

Property-based testing is useful when we can easily define the properties that our software should hold. It requires some additional effort over traditional unit testing, but the increased testing variation should uncover more bugs than unit testing alone.

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.

The customer knows their business, the market segment they want to penetrate, and the unique value proposition of their product when compared to the competition. When it comes to an internal application that is going to be launched or an enhancement to an existing application, the release is intended to bridge a process gap or resolve an existing frustration affecting the company’s existing operations which directly or indirectly impact their business.

Knowing the end goals of a customer will enable the QA to determine the right areas of focus during test execution and expose risks with enough information for the business to make informed decisions. Of particular importance, such information can help a company to identify the right areas of investment, make changes to release schedules, allocate resources and, in many cases, prepare them to address customer enquires after the product or the application has launched.

For QA engineers, these are our opportunities to show how much we care about our customers, their business, and our desire to make them successful.

Ultimately, the success our company receives depends on the success of our customers.

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.”

Continued Education: Whose Responsibility Is it – Employer or Employee?

by Phil Smith, Vice President Client Services

PhilThere is a large volume of material circulating on the Internet, providing philosophical approaches to lifelong learning for individuals. The concept of “continuous learning”, as it applies to the workplace, tends to revolve around these two generally accepted definitions:

  1. “Ongoing learning process that seeks to incorporate the lessons learnt (from the results of already implemented changes) into a continuous improvement program” (, and…
  2. “Total quality philosophy in which every process and system in a firm is subject to constant scrutiny to (1) eliminate waste, (2) reduce response time, and (3) simplify process or product design” (

These links will take you back to the core concept that organizations must base their manufacturing and/or services on processes, and that once established, processes must always be under formal measurement, scrutiny, and improvement. If you are in a knowledge-based industry, such as software engineering and quality, then you have to extend the concept into your training program. Training must be viewed as a process and must always be improving. This applies to your own skill set as well—it’s not just about process capability, but also about people capability.

There is some overlap with workplace continuous learning (employer sponsored improvement) and self-improvement (individual sponsored improvement) in a few articles that I recently stumbled onto where the authors were clearly unhappy with current or past employers’ training programs. I’m not providing links because in many cases it was obvious which employer had caused enough emotion to ignite a blog. However, these articles do raise interesting points, specifically, who is responsible for an employee remaining current with their technical skills:  the employee, or the employer?

I’m referring to widely accepted workplace concepts related to improvement; not just improvement of the product or service, but also improvement of the human capital used to deliver. I’ll state my opinion clearly right here: the employer is responsible. Organizations that rely on people’s knowledge, skills, and efficiencies have a significant responsibility and market incentive to keep their workforce as far ahead of the competition’s workforce as possible.  These organizations have a social and economic responsibility to provide formal plans for training and they need to execute those plans with relevant material. The results and methods the training uses must be measured and improved over time.

I use the term “economic responsibility” because training is actually a pursuit of efficiency and improvement. Without these investments, companies lose ground to competition and ownership value erodes. Additionally, leaving training solely in the hands of employees will result in poor alignment with company objectives and unpredictable results.

I use the term “social responsibility” because the software industry typically keeps people so busy working billable hours that we don’t make time for training programs. We create them; we just don’t execute them. Cost pressure from offshore providers has left US-based resources in a predicament, because training costs are no longer easily hidden inside billing rates. Therefore training programs get sorted to the bottom of the priority list and do not receive attention. In some cases, recent graduates end up more qualified in relevant technologies than long-term industry experts. Technologists who do not take it upon themselves to learn relevant technologies may end up on the wrong side of the cost benefit curve, which certainly feels unfair to the many who work long billable hours to make their company successful.

Other industries such as health and legal, which are knowledge based, require that people be licensed, and that licenses be maintained over time on the basis of formal, ongoing education. We’ve missed this concept in the software industry, which has been convenient in that it allows us to be informal with our staffing decisions and enables us to exchange hours that should be dedicated to training and certification for more billable hours.

On the flip side, you can’t argue with free market economics. Graduating students will always have some advantages that may or may not outweigh their lack of experience, and offshore resources will always have some cost advantage that may or may not outweigh distance and other factors. Employers will always have challenges with cost and commitments, resulting in pressure for more billable hours. In the end, the only person that can be held responsible for a person’s career plan, training, and marketability is the person. Life just works that way.  Making sure you are marketable is basically the same as being a gazelle out on the plains. Fast and capable is essential. With that in mind, if I could personally meet the people whose blogs read like, “it’s not my fault,” I think I’d have difficulty finding sympathy.

So, is the employer responsible for training, or is it the employee? Yes.

Growing Pains — How to Grow From Small to Big

by Brenda Hall, CEO

Brenda_Hall_100_x_120I’ve often been asked, “How hard was it to start your company?” My answer continues to be, “It’s not hard to start a company; it’s hard to grow it!” Simply said, anyone can start a company as long as they desire to. It takes someone willing to take risk, believes they have something someone else is willing to buy, and believes passionately enough in their idea to push other, more ‘stable’ options aside such as working for someone else for a paycheck. Getting started isn’t difficult. There are endless examples of people baking their products at home and selling them through local outlets. Or, perhaps you know someone who has exceptional knowledge in a specific area (think software development) who is keen to develop that perfect app for our phones. A short cruise across the internet can provide the applications to fill out for the Secretary of State for your local state, open a business account at your bank, and without much more ado…you’re in business.

Growth, however, requires tenacity, dedication, gathering smart people around you and hard work day-in and day-out. There will be times when mistakes are made, and standing up to them to preserve your reputation while ensuring your clients don’t pay for them is paramount. You will never grow if you don’t have delighted clients. Here are a few, key lessons I’ve learned that will help any entrepreneur get off on the right foot.

  1. Make sure your company values are visible to all of your employees. Even more, try to hire employees who SHARE your values. Values are important because people need to work with other like-minded people. For example, you want people who not only respect your leadership and believe in the mission of your company, but also people who ACT on those same values especially when challenges enter the picture. Not every effort or client engagement will go smoothly or perfectly. You need to have people who will quickly work to fix errors and repair relationships. You need people you can count on to Do The Right Thing.
  2. Speaking of employees, I’ve learned it’s critical to hire well. Take your time to find the right person. It’s not always about whether you like someone, or assume someone is a good fit because they worked at a major company before landing in a chair in front of you for a job. WAIT…do your due diligence. Make sure you investigate their background thoroughly. Talk to people they worked with. Check them out on LinkedIn. Check them out on Facebook. I learned from a dear man who utilized LinkedIn to garner as much ‘intelligence’ about a potential employee he was planning to hire. Then, he went to Facebook to find out what kind of person he was planning to hire. Good advice.
  3. Surround yourself with people smarter than you. This is extremely important, and there is no room for ego to get in the way. Networking is essential in order to meet the kinds of people you would hire if you could…but necessarily can’t. For example, I’ve met several, extraordinary people through the years who have become trusted friends and mentors. They’ve guided me through tricky decisions, helped me sort through the noise and chatter to achieve specific goals, and continue to support my company’s growth in a way that brings efficiency as well as success.
  4. Listen, listen, listen to your clients. For me, the sales process is very personal. I’ve no professional sales experience, but I learned a long time ago that sales is truly about listening and keeping the lines of communication open and active. Once you make a ‘sale’…don’t forget that sale involved someone trusting you to deliver the goods. Make sure you deliver them. Make sure you follow through with your client to see if they have any questions. The world is ripe with people who feel let down after a sale was made. Don’t let that happen. If you want your company to grow, you’ll need strong referrals, testimonials and REPEAT business because you did well the first time around. You LISTENED to your client, you did what you said you were going to do for them, and you made sure they were delighted throughout the experience. This is a formula that should NEVER change.
  5. Enjoy the journey. This isn’t about how big, how much, how well known your company becomes. This is about making sure you recognize the achievements of your people, the successes they’ve brought with each client effort, and how well they’ve made your life — and kept the breath of life in your company. I don’t believe anyone gets very far on only the leadership of a few people at the top; it takes a team. I once went to the top of the mountain to visit Neuschwanstein Castle in Bavaria, Germany. The road is very steep and the wagons we rode were pulled by a team of strong (and beautiful) draft horses. I thoroughly enjoyed the journey, but I’ll also never forget the hard work those horses had to give to provide me that enjoyment. Enjoy the journey, but don’t forget your team that brings you success.

There is so much more to share, but I believe if you adhere to these 5 guidelines, you’re well on the way to building the solid foundation that gives your company all the growth potential you will need through the years.

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!


Get every new post delivered to your Inbox.