How a testing tool becomes a job description
This is a guest post for the Computer Weekly Developer Network written by Scott Sherwood in his capacity as founder of software testing tool company TestLodge.
Sherwood explains that he created TestLodge after working for years as a developer and found that many of the tools he used were cluttered and clunky.
He bemoans the fact that these ‘other’ tools were filled with unnecessary features that made it harder for him to do his job.
Confident of his own product’s worth, Sherwood makes the somewhat unusual suggestion that a testing tool can become a job description — but just exactly what is he talking about? Sherwood writes from this point onwards…
A big developer market
According to market researchers Evans Data Corporation, there were 23 million active software developers across the world in 2018. With this expected to rise to 28 million by 2028, it’s safe to say that there will be no lack of new software in need of testing in the coming years.
As automation and the growing reliance on IoT devices continues to integrate and conglomerate software, it’s more important than ever to make sure that, well, it works!
Developers need to ensure all systems stay green across the board… and it’s why the rise in testing tools has been so prolific in recent times. So what position should you consider testing tools to take in your own skillset?
Historically almost every job has come with the standard ‘must have experience with Microsoft Office’ tagline. Today the knowledge of tech in job descriptions is a little wider and platforms such as Facebook and Twitter are appearing more and more.
But something we have noticed is that testing tools (I’d like to suggest own product, but I do acknowledge the existence of others in the market) might be regularly being cited as ‘essential experience’ for job requirements.
Naturally, it’s very specific to roles such as Quality Assurance (QA) engineers where they also mention programming languages such as Python, Ruby and Java, but it’s a new job requirement label that I’d like to suggest some people may not have anticipated.
From tool… to description
So how does a testing tool become a job description?
Whether I’m talking about our product or our competitors’ offerings… the number one action is probably the most obvious – listen to your users!
We always made a point of charging for our software from day one, even if it was only a few dollars. This wasn’t necessarily about the money, but more that we knew the feedback from customers who are willing to pay for our service was likely to be the most valuable.
As a second point, I want to advise you not to outsource customer support early on.
Feedback is your most important asset and should shape how you build the tool. This will also help you keep from overdeveloping. Users don’t want bloated platforms that try to do a million things poorly. They want to you use your SaaS to solve a problem, quickly and easily.
As a developer, if you keep these points in mind you will grow a user base that will be happy to recommend you to their colleagues… and that’s how you become the preferred bit of kit for a team, department and company.