Katalon Testing Suite

I've always been attracted to low-code, no-code (preferably) automation test suites, probably because I never really got on with coding. Oh, I've dabbled over the years. I've written "Hello World" in quite a few languages, and actually made progress with Python -- in that I completed all the exercises in the course I was following along with. However, in the hierarchy of testing, automation trumps manual. I have known many people leave testing -- or decide against going into it -- because coding seemed the only way forward, and they weren't temperamentally suited to coding. 

There are quite a few low-code, no-code suites, on the market, and they've promised a lot of over the years without ever fully being able to deliver in a world of business bespoke software. I asked Copilot to give me a top ten list of low-code, no-code automation test suites and it returned the following: 

To be frank, I've heard of the top two on that list and Ranorex at No 6. And I was surprised that TestComplete (from SmartBear) wasn't on the list, perhaps because I've seen a lot of marketing for it. 

Anyway, to our Katalon tale. I've had a few cursory looks at Katalon over the years, and liked the fact it had a Linux client. I have to say that it now seems to have reached a surprising (to me anyway) level of maturity. As an aside, I also had an interviewee who sang its praises untroubled by the fact we weren't using it. I sincerely hope she's working in automation using Katalon and is still enthusiastically advocating for it. 

I downloaded the latest free version to follow along with Raghav Pal's Katalon masterclass, which can be found here: 

https://www.youtube.com/watch?v=lcUgrciUCPg

And very good it is, too. The suite and the masterclass. He does lots of training stuff, and if you have the time to follow along and actually do the training as opposed to just watching the video, you will learn a very great deal. And so there I was with Katalon and Raghav following along assiduously, when I hit this error (or limitation): 

I understand. I truly do. This is an application intended for use in businesses, and they don't want to give everything away for free, which is perfectly reasonable. I was just a mite miffed because I was caught up in the flow of the training and it was a bump in the road. 

I now know how to do the following in Katalon: create test cases using three different methods; create a test suite and add test cases to it; create a test collection and add test suites to it. And, of course, I cheerfully ran the tests and watched them complete. I looked at the reporting, which is impressive (businesses love reporting) and I looked at scripting which Raghav made it easy to follow along with. Despite this, I know there is much, much more to this suite than the little I've learned. All I've learned is confined to web applications, which are increasingly common these days. But Katalon also does mobile applications and, I believe, desktop applications. I used to test desktop applications exclusively, but that was before the world changed, and I have no experience testing mobile applications beyond browser simulations of various mobile phones. 

Past real-world problems

Imagine you have a piece of software in which you have to create a list of items, but the snag is that all the items have to have unique names. So you record yourself adding the first item. You go to the URL, you enter the login name and password, you take the steps to add the item, and then you close the browser and save the test. When you run the test, it will fail because the name has already been added and the name has to be unique. I know a coder using the Selenium webdriver (and coding in C#) who solves this problem by simply adding the date and time to the item, thereby making them unique. I'm sure it's not too difficult, but I don't yet know how to do this in Katalon. 

I'm going to continue learning with this suite, as far as the free version will allow, and I will post my progress here. 

Opportunities

Job roles are becoming increasingly specialist, including testing job roles. The day of the charming generalist belongs to yester-year. We used to work in IT, doing a bit of everything as our skills and inclinations took us. Installing software, fixing computers, helping someone having a problem with their hardware, creating and cloning virtual machines, a batch command here, a script there, a select statement here, a manual test there. Now all these things have their particular lanes and boxes, and the rest of it -- such as my enjoyment of Linux on the desktop -- is in the hobbyist arena. 

Employers now want and advertise for a very specific set of skills and tools. I saw one job advert that said "Knowledge of Appium essential". Essential. This was in a long list of other desired skills. Basically, though, don't bother applying if you don't know Appium. I looked it up (it's a tool for testing mobile apps on Android and IOS), but I didn't apply. 

On the plus side, mastery of a particular tool, such as Katalon, would pretty much guarantee you a decent income. And there are people who invest a lot of time trying to divine the next big thing in their arena. In testing, I've heard Playwright and Cypress mentioned. I believe Raghav has a course on both. 

Vibe Coding and the Mortified Hubris of Developers

 

Introduction

In the queasily shifting landscape of software development, a new phenomenon has emerged: Vibe coding. AI. Basically, just as you can generate images or videos from worded prompts, now you can as easily produce functioning code. You can bet developers don’t like this. They like to get together in rooms and online forums and diss the code it produces. It threatens their “creativity”, mocks their sense of exceptionalism. “No-one will ever be able to automate my job,” a developer once told me. Oh, dear. The disrupters disrupted. The march of automation. The doorbell rings, and the worm of panic wriggles in the gut of an impending identity crisis. Call your new AI friend a collaborator if it makes you feel better, but you know it’s a boss in waiting. 

The Hubris of Developers

For decades, developers were the architects of disruption. They served their corporate masters well and unquestioningly – what they were doing, they were sure, was good. They built the systems that displaced and devalued others: typists, cashiers, travel agents, and traders. They celebrated efficiency, automation, profit and progress, indifferent to the human cost. They were doing all right. And the smug assumption: technology might replace others, but never us.

This hubris rested on two mistaken beliefs:

• Coding was an irreplaceable skill: Developers saw programming as way too complex, too creative, too human, indeed, to be automated.
• Progress as virtue: They championed disruption as a moral good, equating technological advancement with societal improvement. That’s if they even thought about it at all. Self‑justification always comes with a layer of slime. 

Mortification in the Face of Automation

Now, with vibe coding, developers confront the same fate they once blithely imposed on others. The mortification lies not only in the threat of job displacement but in the realization that their craft — once revered as a pinnacle of intellectual labour — can be reduced to autocomplete.

•  Loss of exclusivity: Non-technical professionals can now build apps with no-code platforms or AI assistance, bypassing developers entirely.
• Erosion of identity: For many, coding was more than a job; it was a badge of intelligence and creativity. Vibe coding undermines that, which is why the childish attacks. The code, guys, it’s only going to get better. 
• The mirror of disruption: Developers must now reckon with the same anxieties they once dismissed in others.

The Irony of Progress

The irony is sharp: those who once wielded automation as a weapon of progress now find themselves its target. The beast of disruption, once unleashed, does not discriminate. It devours typists, cashiers, traders — and now, developers. The mortified hubris lies in realizing too late that they, too, have been cheapened and devalued, that their particular skill is easy meat for the silicon overlords. As with chess, soon it will be pointless comparing a human developer to the code engine because, as with chess, the latter will always win. 

Conclusion

Vibe coding is more than a technical trend; it is a cultural reckoning. It forces developers to confront their own vulnerability, their historical complicity, and the self‑interest they were happy to pretend was progress and good for society. It was always a Faustian pact and the devil always collects. But I get it. I do. You were just doing what you had to do in the game of getting on. I understand. It’s not easy. But, remember, the only soldiers that really matter are the ones who don’t follow the order to fire on the crowd.