When strictly following process, creating pages of documentation, or trying to stop a release without understanding the business, testers do not provide a service. They instead become an expensive part of a company that returns little value.

These testers are surprised when management reduces the cost of testing by limiting staff, physical resources, and available time.

A test group adds the most value and gains the most respect when they are focused on the business and its users. The return on investment of a testing service is higher when the cost of tester salaries, time, and virtual and physical resources is considerably less than the value of the information returned by the service. The value is determined by the amount of money it saves, or gains, a company, such as:

  • Revenue gained due to bugs not released to customers
  • Reduced expenses due to fewer customer service representatives needed to support customers
  • Software development savings due to bugs found early in the project, or
  • Smarter testing due to fewer testers and/or time needed to find problems (in requirements, design, code, packaged software, etc.)

Increasing and improving the effectiveness of communication, collaboration, and comprehension leads to reduced costs within a test group and across an organization. This means a test group is providing more value with less cost incurred.

Documentation Overkill

Whether Waterfall or Agile, or somewhere in between, many test groups are documentation heavy. Test strategies are created early in projects and become small books when printed. Days or weeks are invested to prepare test strategies that are lightly reviewed by stakeholders before they are put into use on a project. This also happens as testers create hundreds, or thousands, of test cases. As a product is tested, additions, deductions, and modifications are needed for test strategies and test cases because the requirements and software have changed.

I’ve been that tester.

On one project I spent weeks preparing a 52 page test strategy document that was mandated by my organization and getting it approved, only to have half of it negated by changing requirements. I tried to keep the document upto- date weekly because I was told to. These activities did not add significant value. Nearly 60% of the document was repeated in every test strategy we created. For every hour I spent on it, we lost an hour I could have spent testing or coaching another tester to be better at their job. When I wasn’t focused on finding bugs, I was not adding value to the project. The ROI was dismal.

Meeting Overkill

In some companies the status of an employee is tied to how many hours they spend in meetings each week. The harder it is to schedule someone, the more important they were perceived to be. When someone spends hours in meetings each week, the company loses hours towards their primary responsibility. If a tester isn’t testing (against requirements, design, code, problems, software, etc.), are they providing the expected value? When a tester spends two days a week in meetings, is it really a wonder why the test group costs so much when compared to the value they provide?

I’ve been that tester too.

I worked on a project where I had to block off afternoons to get any project work done. Team members, stakeholders, and process-initiative leaders constantly wanted me in different meetings. While some meetings were valuable for communicating important information, most could have been handled through a conversation or brief phone call. Some meetings were not wellfocused on a particular outline or objective. Others were for processinitiatives with valuable objectives but made slow progress because participants were split between too many things. When I was in most of those meetings, I was doing very little to help my project. The company was paying me to perform a service that I wasn’t performing, so the ROI was dismal (meaning high cost to little value).

Focus Overkill

There is a pronounced rhythm in some organizations. Testers run tests and report pass and fail rates as fast as they can. They do this repeatedly for hours on end, working hours of overtime every week. Requests for training, conferences, or to spend time learning new things are turned down because fewer tests will be run, or it costs too much. Some testers are so run-down they don’t consider asking for these things. Unfortunately, it is these very things that enable testers to improve their work quality and the value of the test group, and in turn, reduce costs.

I once worked in a company where the value of a tester was determined by the number of hours they worked every week. I embraced that belief for a couple of years, regularly working 60 hour weeks. It wasn’t until I felt run-down that I recognized there was a problem. There is a difference between loving your job and working yourself to the point that the company would get more value from you if you only worked a couple hours a day. I was in a slump, having brought few new ideas or approaches in several months. I could not perform at my best until I slowed down, gathered new ideas, and allowed myself to engage in new ways of thinking.

Be Smart – Increase Value, Reduce Costs

Testers have a choice, dare I say a duty, to do their job as testers, which means to test ideas, desires, designs and software. Consider: n Why do testers spend so much time putting test strategies, test plans, and test cases into lengthy, misunderstood and incorrect documents? What if these are instead captured as mind-maps, flowcharts, video-screen captures, or test session notes? These methods increase collaboration, save time, and reduce costs.

n Why do testers spend hours in meetings every week? What if they have critical and creative thought discussions with the people that matter at the time that it’s important? Why aren’t testers avoiding the overhead meetings that take them away from their primary responsibility – testing ideas and products? These allow testers to collaborate with stakeholders in the moment, increase understanding of the product, customer, and business, and reduce costs.

n Why do testers agree to run the hamster-wheel of executing test cases? Why do testers accept not learning new things, generate new ideas, and trying something new? What if testers slowed down to look around, think critically and creatively, and learn new things? This allows testers to be better at testing throughout projects. These all provide the opportunity for an increase in collaboration, understanding and quality, as well as reduce bugs and costs.

It took time for me to recognize these areas as issues and learn to speak up. Saying ‘no’ to a manager and defined procedures and processes requires a lot of courage.

Consider this: Regardless of what a process says to do, if you are not doing an activity that returns high value in your testing service, how can you do it better and prove that it does to those you need to convince? When you use your time towards testing instead of documentation or meetings, you will provide more value to your company.

When you use your time to think, learn, and try new things, you will increase the quality of your testing. Focus on these and you will increase the ROI of your testing service and help reduce the cost of testing.

About the Author

Selena Delesie I am a consulting software tester and agile coach, and run my own company, Delesie Solutions. I have more than 10 years of experience testing, managing, and coaching in software, testing, and agile practices for leading-edge technologies. I facilitate the evolution of good teams and organizations into great ones using individualized and team-based coaching and interactive training experiences. I am also an active speaker, participant, and leader in numerous industry-related conferences and associations. View my blog at www.SelenaDelesie.com, and my business-facing website at www.DelesieSolutions.com.