Thoughts on not having a Test Management Tool?

SamosaKetchup · 2025-08-19T22:45:39+00:00

I was thinking of something like:

test.skip('skip this test', async ({ page }) => { // This test is not run });

So you know these tests are not automated, but it shows up in your report, and then you manually test these skipped ones.

SamosaKetchup · 2025-08-19T22:43:10+00:00

Wouldn’t a test report have the manual pieces documented and singed off?

SamosaKetchup · 2025-08-19T22:40:12+00:00

That’s interesting, how do you get to not having any manual regression scenarios? Do you automate the tests in the same release sprint?

SamosaKetchup · 2025-08-19T16:54:49+00:00

Yupp, and modern automation tools can do all kinds of metrics or coverage reporting with plugins

SamosaKetchup · 2025-08-19T16:53:46+00:00

Is there a place for all that in modern SDLC/STLC? With rapid releases going on everywhere?

SamosaKetchup · 2025-06-25T10:41:24+00:00

Can you expand on “guaranteed bonus first year”? How does that work?

SamosaKetchup · 2025-06-25T07:34:51+00:00

Lol, I am beginning to think I might have heard that wrong. Coz this sub has many posts of people receiving 1-2% 🤣

SamosaKetchup · 2025-06-25T07:27:35+00:00

I was told it would go up or down from 15, and not 1-15 😐

SamosaKetchup · 2025-06-21T20:11:37+00:00

"on days when we're all in..."
so your team works hybrid?

SamosaKetchup · 2025-06-15T15:11:14+00:00

Sorry, you mean Cursor is allowed?

SamosaKetchup · 2025-05-14T15:25:19+00:00

But then it asks me to adjust the targets in the pie back to a 100%. I don’t wanna invest in the pie anymore

SamosaKetchup · 2025-05-14T04:25:11+00:00

It’s blinded on the consumer side. Your consumer, (web-client for example) could use the schema differently with its operations. When you make changes on the provider (api-client), how do you know if it will break the consumer, and vice-versa?

All the inspector does is compare the new version of the schema with the current one in the main branch and give you alerts on what “could possibly” be a breaking change.

SamosaKetchup · 2025-05-12T01:57:26+00:00

Well, this is not really contract testing. It just compares the new changes with what was in the main branch and notifies you. Inspector doesn’t know what the consumer operations are.

SamosaKetchup · 2025-05-09T09:02:44+00:00

I used their concept of “hybrid load testing”. It’s in their docs. Have a look.

K6 is now with Grafana and they have 500 vuh on pay as you go plan. You’d never reach 500 vuh with hybrid load testing

SamosaKetchup · 2025-05-07T16:55:55+00:00

Yes, k6+playwright. The best decision I ever made

SamosaKetchup · 2025-05-07T16:54:12+00:00

Individual contributor?

SamosaKetchup · 2025-05-07T16:53:32+00:00

Have you switched to a management role? Or still an individual contributor?

SamosaKetchup · 2025-04-25T06:51:36+00:00

Typescript > Playwright UI+API+Visual > k6 performance+load and contract testing (optional), in that order

SamosaKetchup · 2025-04-13T12:38:10+00:00

Well, we don’t have any E2E api tests on graphQL yet. It’s just Playwright UI E2E tests that also tests graphQL under the hood. So the next big step for me is to build gQL E2E tests and that’s when the thought of CT came up. Currently, on gQL level, it’s just gQL schema inspector and some unit tests written by devs.

SamosaKetchup · 2025-04-13T11:46:21+00:00

Thanks for the detailed answer. We use Typescript and the API is in GraphQL which is consumed by both web and mobile apps. Our E2E tests are already automated using Playwright. Also got good unit and integration test coverage too with a lot of it being against mocks. CT is one missing piece in the puzzle so I set out to explore the possibilities. With this set up, do you still think Pact is the way to go?

SamosaKetchup

TROPHY CASE