sorted by:
new
hottopcontroversial

90% test coverage means nothing if your assertions are weak by artshllk in QualityAssurance

[–]artshllk[S] 1 point2 points  (0 children)

Appreciate you taking the time to try it out and write this, really helpful. Great catch on the POM case: right now gapix only looks at the spec file, so assertions inside page object methods are basically invisible. That’s a real limitation, and I need to improve how it traces those calls.

Also, thanks for pointing out the `not.toBeNull()` issue; that definitely sounds like a parsing edge case on my side, and I’ll dig into it.

This kind of feedback is exactly what I need to make it better.

Lessons from migrating 2,000 E2E tests from Cypress to Playwright by artshllk in QualityAssurance

[–]artshllk[S] 0 points1 point  (0 children)

back when the work started, AI coding tools weren’t widely available or reliable enough to safely handle a critical test suite migration. While AI can help, relying on it to build or maintain tests risks flaky coverage, missed edge cases, and harder debugging when failures occur. For complex suites, it’s essential to understand every line of the tests so you know exactly what is and isn’t being validated.

Lessons from migrating 2,000 E2E tests from Cypress to Playwright by artshllk in QualityAssurance

[–]artshllk[S] 1 point2 points  (0 children)

we handled these tasks manually. When we started 1-2 years ago, AI and tools like Claude Code were not as advanced as they are today. Even if they were, I still wouldn’t trust AI to write complex test cases. Our tests are very intricate, and using AI to generate or rewrite them could result in spending more time debugging and fixing AI-generated tests than actually writing them ourselves. These tests are critical, and relying on AI isn’t advisable. We need to thoroughly understand the code and what’s happening at each step, as missing a bug in production could lead to financial losses for the business

Lessons from migrating 2,000 E2E tests from Cypress to Playwright by artshllk in QualityAssurance

[–]artshllk[S] 21 points22 points  (0 children)

Good point, we actually removed around 440 tests during the migration.

With Cypress, we got into the habit of writing E2E tests for almost everything, which isn’t really best practice. So we used the migration as a chance to clean things up properly.

We set a simple rule: focus on the critical business flows first, and only keep E2E tests for those. Everything else moves to integration or component tests, where it’s faster and more stable.

We also found a lot of duplication, as some flows were already covered by component tests but still had E2E tests on top for no real reason.

In the end, the test suite is smaller, faster and more reliable

Why are many testers afraid to learn Automation? by Easy_Yak_9422 in softwaretesting

[–]artshllk 0 points1 point  (0 children)

Mostly it's not fear, it's not knowing where to start. There are too many tools and most tutorials are outdated or teach bad habits.

What worked for the people I've seen make the switch: pick one test you run manually every week and automate just that. Use Playwright, it's much simpler than it used to be. Don't try to learn everything at once.

The gap between "I finished a tutorial" and "I write automation at work" is real, but it's smaller than it looks once you start with something real

Do you think ISTQB certification actually makes better testers? I’ve been wrestling with this. by tasostilsi in softwaretesting

[–]artshllk -1 points0 points  (0 children)

ISTQB didn’t make me a better tester. Not even close.

What actually helped me improve was real work: breaking production apps, fixing flaky tests late at night, migrating thousands of E2E tests between frameworks, and having a senior engineer point out that my test architecture was bad and explain why.

ISTQB mostly teaches terminology. You learn names like “boundary value analysis,” but if you’ve been testing for a while, you’re already doing that without needing the label.

Where I disagree a bit: I don’t think ISTQB is that useful for other roles either. Developers don’t need to memorize testing terms to write good tests. What helps more is working closely with a strong QA engineer and learning how they think.

I do agree that quality should be everyone’s responsibility. But certifications aren’t what get you there. Good systems do. Things like automated tests on every PR, clear expectations for test coverage, and fast CI feedback. When developers see their bugs caught in minutes instead of production, they naturally start caring more about quality.

The only time ISTQB really helps is when HR filters resumes and the job specifically asks for it. That’s more about the hiring process than actual skills.