I swear preparing an app update that's going to be deployed to 500+ people stresses me tf out.

I hope I'm not the only one who feels this way.

No you are not. I always triple check everything before release(8k+ users) and still have that feeling that I may have forgotten something

I'm updating an app for 30-40 people and still am stressed, so I can totally feel you

Dude... Its so stressful.

And no matter what you do, something will go wrong. Nature of the beast.

Thankfully there's plenty of bullshit reasons things go wrong that works great on end users. Employ them when needed.

You don't wanna know how fucking stressful I was when I deployed an application for about 1k people few weeks ago.

Step 1: automate the build, from start to finish. The only thing you should have to do manually is change the version number

Step 2: get someone to do a manual test plan, and execute it before release

Step 3: ???

Step 4: enjoy releasing on a Friday evening.

@Fradow Step 2: get someone to do a manual test plan, and execute it before release

Why not just have an automated test suite that you can run any time you want? Manual test plans are expensive, inefficient, and flakey. Deploy to a pre-prod environment, run the automated suite, if everything passes, deploy to production with confidence. Repeat as often as you want without having to worry about paying extra people to run all the manual scenarios and possibly make mistakes.

@CrashOverride if you can get a good coverage, sure go with automated test suite only.

There are several advantages to have a manual test plan in addition to automated test suite:

1) ass-covering: if a bug slip through, the test plan is incomplete, as opposed to "OMG devs sucks there are bugs"

2) you get more guarantees that the core of the app works great from a regular user standpoint. Your test suite is not a regular user, and might missed obvious things, because you didn't even think about it. For example, your test suite might happily succeed while there are missing/broken images because someone fcked up a server somewhere.

3) if your testers are halfway decent, they will spot some very difficult to reproduce bugs

Obviously, your manual test plan shouldn't cover 100% of your app. The goal is to guarantee the core of the app is not broken.

My company recently implemented manual test plans, and it's a relief to know a real human had a go at the app before release.

@Fradow I 100% agree that you should still have human testers. I just feel that the core functionality should be very thoroughly covered with Unit/Integration/System/End-to-End tests so that you can know at the click of a button that you haven't broken something fundamental to your application. Yes absolutely humans are great and trying weird scenarios and finding edge cases where stuff doesn't quite look right. And that's what your testers would be doing essentially. But to get full-blown continuous delivery and continuous deployment, the whole thing needs to be automated, from merging to trunk, to deploying to production. You merge one change, it goes through a series of environments, each more closely resembling production than the last, each running a more rigorous set of tests than the last, until eventually you get to the end and have no doubt that everything works the way it should. A very very idealistic scenario, I know, but it is achievable.

@CrashOverride I agree with this idealistic scenario, but testing UI is a notorious pain in the ass, especially when you have a few more things in the way (cross-platform, use a game engine, framework has no testing lib etc...).

In the end, depending on your use case, it can be more cost-effective to just throw humans at the problem. It certainly is for my case.

Adding a test case is way faster using a human than coding it too: just describe it in plain english, human will figure it out. Human is also able to write test case on his own. Stakeholders too.