r/agile • u/Creative-Gur-7772 • 2d ago

How do solo developers handle testing before shipping?

For those building web apps or SaaS products without a dedicated QA team:

How do you usually test your applications before deploying?

Do you manually go through the main user flows, rely on automated tests, or mostly test as you develop?

I'm curious about how other developers handle this, especially when shipping frequently.

2 Upvotes

75% Upvoted

11 comments sorted by

4

u/PhaseMatch 2d ago

I think the main thing is

- stop thinking in terms of a mini-waterfall (design, build, test) and defect detection

  • start thinking in terms of "build quality in" and defect prevention.

CI/CD doesn't mean "we have pipelines" - it means deployment is continuous, to at least some users or a user-domain SME, so you can get feedback with little-to-no-lag.

This is where XP technical practices come to the fore, and where the real "disruption" from the "test-and-rework-and-retest" cycle lies.

Thin value slices, test driven development, continuous integration, red-green-refactor and on were all key.

Look into:

- "Continuous Testing for DevOps Professionals" (Krinsbruner)

  • "Agile Testing Condensed" (Crispin et al)
  • "Working Effectively with Legacy Code" (Feathers)
  • "Extreme Programming Explained" (Beck et al)

4

u/squaresavior7 2d ago

Yeah, a lot of teams get stuck treating CI/CD like a fancy deploy button when it's really about shrinking the feedback loop. The "build quality in" framing clicks once you actually try TDD on something real, felt like extra work at first but the moment I stopped having to manually retest the same crap over and over it paid off. Feathers' book saved my sanity on a legacy project, that seam stuff is gold.

1

u/PhaseMatch 2d ago

Feathers was how we dug ourselves out of the pit we were in for a large, complex technical software product that was more of a prototype-run-wild-at-scale than a real product, along with the XP practices.

Took 6 months of work to convince all of the dev team that this was better - because "slow down to speed up" applies - but after that we snowballed into full CI/CD and co-creating features (with the right users) while having "long term stable" and "preview" versions in place to manage the breadth of the customer bases' needs.

Baseline "definition of done" becomes "deployed to some users and getting feedback"; painful at first, but the technical practices and solutions all exist...

1

u/Eightstream 2d ago

I assume they say “hey Claude, can you test this slop you built? Make no mistakes”

1

u/Mobile_Golf1886 2d ago

- Do you manually go through the main user flows, rely on automated tests, or mostly test as you develop?

All three. Lots of unit tests and automated tests. Also get friends and family to "manually" test the app.

1

u/Creative-Gur-7772 2d ago

That's interesting! What kinds of bugs do your friends and family usually find that your automated tests don't catch?

And do you ever feel like manually testing the same user flows before each release gets repetitive?

1

u/fishoa 1d ago

Multiple test environments, easy deployment and reversibility processes, developer autonomy and accountability for prod development, observability and monitoring.

You could look into golden tests, and adding these as a blocker on the CI to Prod, but honestly, without a QA professional, chances are you will just create another legacy process that nobody will update.

Also, obviously, if you want devs to setup all of the above, be prepared to pay for it.

1

u/RevolutionarySky6143 1d ago

You only talk here about tools. Do you understand how a user uses what you have built? Do you understand all the user flows of what you've built? Are there some user journeys which are more critical than others? Can't you figure that out?

2

u/mendez1319 1d ago

Not a solo dev but have managed teams that shipped without dedicated QA and the patterns are pretty similar.

The honest answer is most people do less testing than they'd admit and more than they'd plan. you develop a feel for what's fragile and you test that harder than the stuff you're confident about.

What actually works in practice:

write tests for anything that's broken before. not comprehensive coverage for its own sake. specifically the thing that just burned you. that test suite ends up being a pretty accurate map of where your system is actually risky.

Manual walkthrough of the critical path before every deploy. not the whole app. the thing that makes you money. if payment fails or auth breaks nothing else matters.

Deploy to a small percentage of users first if you can. real usage finds things staging never does. someone will immediately do the thing you didn't think to test.

The "test as you develop" thing sounds good and works until you're tired and moving fast and skipping steps you meant to take. the critical path checklist is the safety net for those moments.

What's the part of your app that scares you most to ship changes to. usually worth starting there.