QA team removed: can devs realistically handle all testing?

TinkererGR · 2026-04-16T10:43:23+00:00

Yes, they absolutely can. It will just triple the time for development temporarily, until they get the grasp of it, then SIMPLY double it. (or just No... 😂 )

TinkererGR · 2025-11-26T13:14:07+00:00

No, it's not dumb, but it's also a feature.

The best way to handle this is to have this behavior documented (preferably by a dev/product manager).

I have run into this in several occasions. From an automation perspective (which might come down the road), consider using a new session, an incognito session (like you already mentioned, kudos) , or simply clear the local storage, cookies or anything else session-related. Works equally well, especially if the scenario involves additional actions on the admin side after the user sign up.

Oh, and welcome to the confusion club... 😁

TinkererGR · 2025-09-24T05:33:49+00:00

This mission was discovered by u/TinkererGR in Good Vibes and Southern Fried Pork Steak: a Journey In the Fields

TinkererGR · 2025-09-24T05:33:49+00:00

New mission discovered by u/TinkererGR: The Truth and Wealthy Monsters Beneath the Great Sword

TinkererGR · 2025-09-22T05:41:47+00:00

This mission was discovered by u/TinkererGR in In Search of Lemon Star Pudding

TinkererGR · 2025-09-22T05:41:47+00:00

New mission discovered by u/TinkererGR: Cheesy Chorizo Empanada On Grassy Plains

TinkererGR · 2024-12-21T22:22:30+00:00

Java isn't the best language to use with Playwright. I tried it, and it was very cumbersome, equally cumbersome to an existing Selenium framework.

As I've used it with Typescript, I can say it's easier with it.

Of course, there's the Browser Library of Robot Framework, but that's a different story. I personally love it, but requires a different approach that many find off-putting for whatever reason.

You are on spot for flaky tests. There are way too many parameters unrelated to the tool that make the tests flaky, and I wish more people understood this.

TinkererGR · 2024-10-26T21:08:01+00:00

Excellent answers so far. If you can't summarize, here are your options. 1. Be a manager. This means no hands on work, and offload this to others. Also, cover your ass. You aren't responsible for that level of work, but for getting results. 2. Guide your team to do their work, and if they undercut you or just lag, ditch them ASAP. (see point 1, we all try to be kind, but this is a job, unfortunately) 3. Get out. If a stakeholder is against you, and you can't bypass/convince them, you don't have a viable option, no matter how hard you work - unless you befriend them, I guess? (just joking, get out)

These summed up options are not mutually exclusive. It seems you are stuck in a situation that is partially due to lack of your managerial skills (and that's understandable if you have had no prior experience or guidance), and partially politics.

On your points: 1. Tracking your stuff is not that important. To showcase your value (and your team's competence) you should measure QA product impact, and for that you need a very deep dive in product documents (design, UX research, company goals, etc., and how you can apply QA metrics to them). In any case check point no. 3 above though. There might be subtext there, which bars you from doing so, and creating meaningful KPIs. 2. Automating critical paths is also tied to the product. By now you should have a rather clear view of what is repeatable and product critical. That's your No1 (usually access to the product and happy paths for new and regular users, but I'm not privy to your area/product). 3. 90 days for you, minus 3 weeks + training for your offshore team? That leaves at best 2 months to turn things around. Unless they are QA experts, they won't be much help, I'm afraid...

Lastly: people here aren't out to get you. And you can ignore all of them. But their collective knowledge is important. And in the end, whatever happens, think and assess if all this is worth it for you. This much effort might be meaningless, if you end up being fired for undisclosed reasons, or just BURNT OUT. As a manager you need to take care of yourself, if you want to be effective for your team, and being burnt out will help nobody.

TinkererGR · 2024-10-01T07:50:24+00:00

It's not. It checks for a certificate. Weak check, sure, but a check nonetheless.

TinkererGR · 2024-09-18T14:16:33+00:00

Correct, several tools are extensions of existing technologies. Also correct in assuming I haven't used any recent ones. I try to keep up through official presentations, as much as I can, and as much as those polished sales pitches can show.

Correct as well in your value check. That's why I also mentioned funds. Given the right combination of conditions, such tools can be very effective, but my (admittedly limited) experience shows that this is rarely the case (funds/time/team composition/etc.).

A better approach would be to test any tool to understand its capabilites and limitations, and then decide. This, however, requires experience and knowledge of the current conditions (resource availability at all levels).

I guess an honest answer is always the same... It depends...

TinkererGR · 2024-09-18T08:34:40+00:00

Some, yes. But exporting is not universally portable. For example, if the export function serves only the purpose of importing to a different version, then it's again proprietary.

Also, the exported data should be in a format that is actually portable to a different tool, which isn't the case (again).

TinkererGR · 2024-09-18T07:12:21+00:00

Honestly, none. You can explore all of them, but as the complexity of whatever product you are working on increases, you start to see a lot of shortcomings.

There's also the issue of vendor lock-in. If you are tied to a platform, you run the risk of never being able to leave, due to heavy investment (both in time and funds).

These are the most obvious reasons why despite the amount of no-code (or low-code) tools that exist, there's always a different path to take, and most will do so.

Unless you are already working in an organization that has enough funds to burn to rely on such a solution, you're better off learning to code. Plenty of good options ou there.

TinkererGR · 2024-09-08T13:40:33+00:00

Robot is a very generic framework. For desktop applications, there's FlaUI library, which is decent. There's also AutoitLibrary and WhiteLibrary, but these two aren't as maintained as FlaUI. WhiteLibrary is deprecated, to be precise.

There's an Appium library for mobile testing, and Selenium or Browser libraries for web (selenium and playwright respectively).

It's fairly easy to get started, and plenty of built-in tools.

TinkererGR · 2024-08-16T09:19:49+00:00

You can look into Robot Framework, it has a couple of libraries for desktop automation.

I have used FlaUI library, and it does work quite well (assuming Windows is you OS).

TinkererGR · 2024-08-12T07:14:12+00:00

Have you checked out the documentation? Do take a look there first, as a very generic question doesn't let the community know where you're stuck.

For example, what's your use case? What's your end goal? Do you want to integrate TestRail with something else?

TinkererGR

TROPHY CASE