Currently, many IT organizations utilize licensed automation tools, but providing licenses to all QA and development personnel is impractical. Typically, licenses are allocated to designated automation engineers who create and run tests as needed. This creates a challenge in allowing any team member to execute tests as required. With most automation engineers located offshore, additional licenses would be needed for onshore test execution, which can be expensive.
Furthermore, ensuring high code quality, adequate coverage, absence of code smells, and thorough security scans is crucial. So how to handle automation test tool cost and security checks implementation upfront? What are your thoughts?
6 Likes
Wait, organizations buy licenses for tools at work? Where in the world is that? country, domain, company?
In the past several years most development and testing I’ve seen has been with free/open source tools.
3 Likes
there are so many paid QA tools (like TestComplete, Tosca, UFT, LambdaTest, TestSigma, Perfecto) organizations have to buy licenses as there is no code maintenance cost . Also QA team members possess varied programming language skills, making it challenging for each QA to learn multiple languages. Some projects prefer to write automation scripts in Java, while others use JavaScript and employ different JavaScript automation frameworks. This diversity in skill sets makes it difficult to have a unified QA resource pool, prompting organizations to opt for licensed no-code or low-code tools.
2 Likes
I’ve worked for lots of places in the UK and abroad that have licences for tools at work. Governance/enterprise level companies etc. Postman is one example because we had secure libraries. Web storm, Jira, Testrail, there are loads. Some companies work with vendors/offshore companies that insist of specific tools due to local/country regulations.
2 Likes
A lot of the target market tends to be enterprise level companies for the paid tools.
Sometimes this level of company struggle to evolve and adapt to change quickly so in turn they will often accept the high costs for a common tool.
The marketing of the tools will often specifically target these companies due to potentially older testing practices and a strong bias towards scripted testing and in particular regression risk as their primary perceived risk.
The high pricing model is often based on either the regression risk being a very high costly threat or its sold based on saving against having testers carry out the exact same scripted tests by hands. This often creates a fairly easy sales model.
Banking, financials, insurance enterprise level companies for example. Many still have older practices but they also have funds.
Perhaps the enterprise level companies drive the mainstream view in a lot of cases which then encourage smaller companies to emulate their practices which is where they can run into the additional problem of high costs if they try and use the same tools.
Many tool options out there for less cost particularly if you are smaller and able to change and evolve faster than some of the larger companies.
Consider if your company and practices are not actually the target market of the expensive tools, you may find something both cheaper and better matching to your own challenges as a result.
1 Like
Yes we do, a lot. We license environments and platforms quite often in order to support some of our CI/CD and to allow us to build correct customer environments with the integrations that they use. Most integrations are available on a developer tier for free use, but some, you do have to pay for.
1 Like
There’s a lot mentioned in this question and some very specific contexts. Let me see if I can answer some or part of your question:
- Do I feel the cost of testing tools is too much? No and yes. That’s part of the calculation of choosing the tool, right? If the benefits outweigh the risks, then use it. Otherwise don’t.
When I use a service like LambdaTest or SauceLabs I generally find they are good for the value. But I only use them for specific situations.
- Should we seek innovative ways to reduce costs? Yes, depending on the cost.
Tool selection is about weighing trade offs. Limited access to the tools, limited ability to code in your changes. Its frustrating when someone else chooses a tool for you, but if it stops working / stops being beneficial then stop using it.
To comment on your other points:
Having testers with skills in different programming languages is a benefit, not a negative. Having testers with experience with different tools is a benefit, not a negative. Testers with broad experience is a benefit as well. We don’t need a single unified field, variation is good.
I’ve chosen to use low / node code tools, again because the benefits outweigh the costs. Not because there is no single unified field of software testers.
1 Like
I have written an article on how we can save cost while utilizing licensed automation tools -