honey-badger

Quality Acceleration is brilliant! I love it.

>In this case, I wouldn't say you absolutely need a full quality team, but having some folks whose primary focus is testing and test automation to help skill up your dev teams sounds reasonable.

This is what we have at our current team, as I have described in a comment above, and it has worked very well for us.

A valuable perspective, and brilliantly articulated. The process of software creation and its quality assurance is so intricately intertwined due to the nature of software itself, that it is near impossible to neatly divide labour.

Great perspective. Now if you were to take the place of Management and tell this exact story, how would it sound?

Not necessarily. In all likelihood, the market punishes bad software quality, but with a longer and more complicated feedback loop.

It is easy to see the increased traction due to building new features. It is difficult to understand the slow, grinding attrition that happens due to bad quality.

Your comment is super helpful! A few months back, we went from scenario 2 to scenario 1, and I can attest to it being substantially better.

Does the QA team comprise domain experts? What is your domain?

QA Engineer here. We don't have a centralized QA department, but we do have a dedicated engineer who is responsible for QA that is integrated within the development team.

Before I joined my team, it didn't have a dedicated QA member. The quality of the software was fine, but there were other compromises. The team didn't have a good test strategy - every developer made adhoc decisions on how their code was tested. Our E2E tests ran slowly and had tonnes of duplicates, since nobody had gone through the entire list and cleaned it up. A dedicated QA member has the time and the responsibility to solve problems with quality that most devs are likely to treat as secondary to developing features. And the improvements are substantial - our E2E tests now run 18x (!) faster.

For the most part, I see my role as being an enabler - I help devs build quality into their work and hold them accountable to it. I don't see it as an adverserial division of responsibility, but more as a collaborative effort, with the dev and QA coming from a different focal point.

The problem with strict division of labour and adverserial QA is that it leads to

1) Organizational / team silos

2) Local optimization (software development and QA is intricately interwoven, so it doesn't lend itself well to this strict division)

3) Information overhead and loss

A good QA engineer, IMO, requires better coordination and communication skills than a developer because they liaise with multiple developers and inspire them to make quality a priority in their work. Further, QA is involved from the definition of a feature (in sprint refinements) right up to when code is deployed and runs well in production. Therefore, at certain points, the boundaries between QA and the Dev team or QA and the PO blur and disappear entirely.

I found this to be a great read that summarizes my thoughts on the topic: https://www.thoughtworks.com/en-de/insights/blog/qa-dead

That is interesting! It rings true, but I never looked at it that way.

Well, the truth is that developers often underestimate how hard it is for non-developers to write scripts. The reason why they don't understand why something like RPA exists is also known as 'The curse of knowledge'.

It's also a marketing problem. You need a solution that appears sexy to the worker, the boss and a champion high enough in the organization to overrule outdated IT policy.

I think RPA exists because every organization is plagued by people management problems that developers and IT often fail to acknowledge.

Precisely. In some narrowly defined scenarios where data migration is otherwise like untangling a giant ball of yarn, RPA serves an invaluable need. However, the manner in which it is marketed is out of proportion to the narrower scope in which it is valuable.

Damn! You are like the bystander who gets taken out during a gang raid in your neighbourhood.

Author here. I agree entirely with what you say here. But consider this. I once automated an RPA process to create service records for the customer service department. I did this by automating over a Java based UI app, with reliable selectors as you correctly point out.

However, that app's UI would keep changing due to updates from the IT department, over which the customer service department had no control over. This is why I call the automation 'fragile'.

But if you are automating using a bot (a software program), why does it not have access to the same pool of data as the UI application (some database somewhere)? Would that not be a more robust means to retrieve it rather than via the UI?

If you are automating a business process via the UI (other than for simulating user interactions for testing) there invariably exists a more efficient way to achieve that end without involving the UI. I have found no exception to this rule.

It's a terrible name that has unfortunately stuck. Deliberate obfuscation.

All hail Stefan! Apart from a prolific and generous developer, he's a great human being too. He has turned into a good friend.

As for low-code and no-code, I understand your aversion. Those solutions aren't for somebody like you :)

Spot-on! From the beginning, I have hated the term 'RPA'. It reeks of deliberate obfuscation, like putting a shiny package around a used sock.

PS: I checked out Axiom yesterday and am excited to see the problem you're solving. Wish you guys all the best!

What you say here is partly correct. To your list of reasons, I would add

3) The existence of business problems that are valuable in their own right, but not compelling enough for regular developers in the firm to care about

Amen! RPA is also about democritizing IT by handing (ideally) every white-collar worker the ability to write scripts that can automate pieces of their daily-work. Of course, those solutions aren't likely to be elegant and their code won't be clean, but since their scope is tiny, that isn't a problem.

All your observations are spot-on. Kudos! You have understood this space much better than most software developers ever will :)

And yes - the exhortation in my article was essentially for RPA developers to max out on the use of the text-based script editor.

That is a symptom of hype. In the long run, this will change due to commoditization, as I point out in the article.

Author here. In an ideal firm, where data is handled responsibly, you would not need RPA at all. In large organizations though, data tends to accumulate in monolithic islands that are only exposed to each other with legacy UI based applications. Moving this data tends to make up a large bulk of white-collar jobs in large organizations.

RPA replicates the work that these workers do by automating on the UI of the legacy application and replacing them. It is championed by ambitious business professionals who

1) Don't know that a more elegant solution exists in the traditional IT world

2) Don't receive enough support from the IT org to solve this business problem that is crucial to them.

Therefore, such business professionals collaborate with consultants to spear-head RPA projects in the name of digitization, ushering in AI or similarly varnished back-doors.

However, as long as important data tends to accumulate in disparate islands that IT doesn't have the time to pay heed to, RPA projects will continue to be sold at a price that is a little lower than the salaries of the employees they 'liberate'.

There is, although, another wrinkle to this. RPA is also about democritizing IT by handing (ideally) every white-collar worker the ability to write scripts that can automate pieces of their daily-work. Of course, those solutions aren't likely to be elegant, and their code won't be clean, but since their scope is tiny, that isn't a problem.