Testers don’t just test software. They perform many other activities aside from testing that, while equally important, tend to be forgotten about by managers and leaders. So, let’s break it down. When testers aren’t testing, what are they doing, and why is it so expensive? How can we reduce some of this expense?
One aspect of testing is reviewing specifications, wireframes, user stories, and acceptance criteria. These documents aid the tester in developing test cases for both manual testing and automated tests scripts. Testers can even begin working on test cases and automated scripts before the feature is complete. For example, once a tester has met with the project manager, designers, and the product manager, they can develop acceptance criteria for that feature. It is easy to imagine the happy path, as well as positive and negative cases that will need to be checked during regression. Certainly, testers will not capture every aspect of the product that will need testing, but when they approach the first iteration of the product, they will already have helpful information to inform their explorations and hasten the development of automation.
Get TestRail FREE for 30 days!
In addition to gathering information, testers often need to create or learn tools to aid their investigations. The testing tool set is broad and varied, including common tools like Selenium regression suites, through to specialized tools for security. All of these tools take time to learn and master, and this is another reason testing seems expensive.
Let’s take automated regression scripts as an example. Many technical leads outside of the test group see automated UI regression as an answer to slow regression turnaround and frequently updated code, especially if they want to work in a CI/CD environment. Yet, the very things that make automated UI regression useful are the things that make it expensive. Frequent changes to production code mean that automated testers need to spend as much, or more time, maintaining tests as they do developing tests. While many leaders believe that automated UI scripts will make testing faster, the truth is that these scripts increase some costs; maintenance, collaboration and architecture for example — while alleviating others, like the amount of time taken to regression test and the overall amount of time taken to get a production release.
Testing also involves writing and maintaining documentation. Some of the necessary documentation in test is included in test automation efforts, especially if a BDD tool is used with a “Gherkin” syntax. Test charters are another means of planning, recording, and communicating exploratory testing efforts. Test case documentation and reporting may need to be very specific, particularly for testers working in regulated industries like medicine or finance.
Documentation seems costly to produce, and does indeed take time; however, in the form of automated feature files, charters, or checklists, documents generated during testing can help other stakeholders understand what testing activities were performed, and provide a platform for shared discussion about testing decisions. For example, new testers can read feature files and regression test cases to learn about the product quickly. These documents can serve to help rookie testers do their own explorations of the product, and find new issues. Thus, while expensive at the outset, documentation saves money by saving time during the onboarding process.
As with any other profession, testers need to invest in continuous learning to perform effectively. Technology changes rapidly, and the testers that can keep up with new technologies will be able to test those technologies more effectively. Further, there are many kinds of testing that require specialized knowledge, such as security or performance testing. While much learning can be obtained for free via the internet, there are higher-cost opportunities like classes, webinars, or conferences, where testers are presented with a high-volume of material in a short amount of time, often with an associated cost.
Some companies are reluctant to provide support for testers to learn. However, the cost to the organization of poorly-educated testers is likely far greater than the cost of helping testers to learn. For example, testers who lack knowledge in technologies, tools, or methodologies, are less likely to find bugs before they make it to production. These same testers may not be able communicate with developers or project managers about project needs, because they are uninformed about the multiple approaches they could take to solve problems. So, while there is an initial expense in supporting enthusiastic testers who seek education, the higher expense will come if weaker, less motivated testers make expensive mistakes that find their way into production releases.
Counting the Cost
Part of managing the expense of testing is hiring testers who are good researchers with proven skills in tooling, keeping documentation, and self-education. While this extends the hiring period quite a bit longer than might be considered normal, it also can help to cut the expense of teaching testers good questioning skills, or pulling teeth to get them to learn tooling that they are not comfortable with. The self-educating tester will spend their time learning and improving their craft on their own, and will likely seek a variety of opportunities to help them do so.
This is a guest posting by Jess Ingrassellino. Jess is a software engineer in New York. She has perused interests in music, writing, teaching, technology, art and philosophy. She is the founder of TeachCode.org
- Announcing TestRail 5.5 Release with Ranorex Integration, GDPR, Admin, UI and Performance Enhancements