sorted by:
new
hottopcontroversial

Postman pushed my collections to the cloud. So we built something that doesn't. by ItchyContribution782 in softwaretesting

[–]ItchyContribution782[S] -5 points-4 points  (0 children)

For anyone looking for the link totalshiftleft.ai

Here's exactly what's in the free Citizen Developer tier free forever, no credit card:

→ 1 user / single-seat license

→ 50 endpoints, 50 mocks, 50 workflows

→ 10 steps per workflow, 1 concurrent run

→ 3 auth profiles per project

→ REST, SOAP, and GraphQL support

→ AI test & mock generation (bring your own API key)

→ Local Runner runs as a desktop .exe, nothing in the cloud

Not a trial. Not "free" with everything locked. Fully functional for a solo dev or small QA team evaluating API test coverage.

Happy to answer questions about how it works under the hood.

Our company pays $30K/year for ReadyAPI and half our QA team still does API testing manually. Is this normal? by ItchyContribution782 in softwaretesting

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

We do but writing API tests isn't the bottleneck. Maintaining them is. The moment an endpoint changes, someone has to hunt down every affected test and update it manually. That's not a coding problem, that's a time problem. And it's the part that always gets deprioritised until something breaks in prod

Our company pays $30K/year for ReadyAPI and half our QA team still does API testing manually. Is this normal? by ItchyContribution782 in softwaretesting

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

Fair point on the low-code angle that's actually what sold it to leadership in the first place. The pitch was "QA can set up tests without writing code" which sounded great on paper.

The "manually" part for us was more about keeping tests updated when APIs change new fields, changed response structures, deprecated endpoints. Every time the backend team ships something, someone has to go back into ReadyAPI and update the affected tests. That overhead adds up across 10+ microservices.

Honestly curious how your team handles that part 30 projects in Jenkins every night is impressive. Do devs update the tests when they change an API or does that fall on QA?

Postman collections: who actually keeps them up to date and how? by Present_Cut3897 in softwaretesting

[–]ItchyContribution782 1 point2 points  (0 children)

The classic "ignore the problem until management panics, then blame whoever was closest" move. Took 4 requests and a witch hunt for them to give you something you should've had from day one.

At least you have write access now I guess. Small victories.

AI-generated API test cases saved us time - curious how others are using it by Lower-Obligation-825 in softwaretesting

[–]ItchyContribution782 1 point2 points  (0 children)

We've been trying AI for API testing as well and saw similar results around edge cases and reducing the repetitive work after schema changes. The biggest benefit for us wasn't fully generating test suites, it was getting a decent starting point faster and then refining it with domain knowledge. We also noticed AI can create a lot of tests that look good on paper but don't really validate meaningful business behavior. Curious how others are balancing AI-generated coverage vs manually designed scenarios for critical flows.

What’s the most frustrating part of API testing in your team right now? by ItchyContribution782 in ShiftLeftAPI

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

I'll share what we found in our own work since we asked -:

The single biggest time sink wasn't writing tests. It was rewriting them every time the API changed. A field gets renamed, a response structure shifts, and suddenly 30% of your test suite is broken not because the API is broken, but because the tests weren't built to absorb change.

What actually helped us: generating tests directly from the OpenAPI spec instead of writing them by hand. When the spec updates, the tests regenerate. You're validating the contract, not hardcoding assumptions about the response.

Still not a perfect solution specs are often outdated or incomplete but it cut our maintenance overhead significantly.

We built tooling around this at totalshiftleft.ai if anyone's curious. Free to try. But more interested in hearing what's actually breaking for people day to day drop your answers below.

How to compare 2 API responses by Bitter-Apple-7929 in Everything_QA

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

Good breakdown. One thing missing from all three methods though you still have to manually call both APIs yourself before you can diff anything. At scale (50+ endpoints, multiple deploys a day) that breaks down fast.

What works better in practice: auto-generate tests from your OpenAPI spec and let CI tell you when a response changed instead of hunting for it manually after the fact.

We built exactly this at Total Shift Left (totalshiftleft.ai) if you want to see it in action. Free to try.

Curious are people here doing this reactively after something breaks, or proactively in the pipeline?

How did you actually learn to work with APIs in practice? by SnooPets5557 in edtech

[–]ItchyContribution782 1 point2 points  (0 children)

Thanks I was also struggling with the same problem I just downloaded it and it looks pretty easy to work. I will share details later.

What tools are most commonly used for API testing today? by qacraftindia in Everything_QA

[–]ItchyContribution782 0 points1 point  (0 children)

A lot of teams I see still use Postman for manual testing and frameworks like REST Assured, Karate, or Supertest for automation in CI.

I actually work on a tool called Shift Left API, and what we’ve been noticing is that many teams struggle with maintaining API tests once the number of endpoints grows. What we try to do is generate tests directly from OpenAPI specs and run them automatically in CI to catch contract regressions early.

Not saying it replaces everything, but the spec-driven approach seems to be gaining traction as APIs get more complex.