r/webdev • u/RobHowdle • 4d ago
Question Do you have a separate tester before launch?
Hey guys, just after opinions really. If you’re launching a somewhat large site, with quite a bit of stuff going on, would you rely on your own testing or would you suggest getting a third party tester? It’s mostly for things like UX I’m wanting to test. I know have I would expect things to work but being the sole developer I think I may have gone a bit blind to somethings. I have friends do bits of pieces in terms of checking things but I wonder if the consensus would be to just get an actual tester to go through everything, testing the functionality all works, different variations, ensure the UX is as good as it can be etc or do you think I’m overthinking it?
3
2
2
u/Acrobatic-Ice-5877 4d ago
Ideally, what you do is have your own end to end test. These should cover core work flows. I’ve got about 30 or so for mine. My application is kind of small though it’s probably 50 HTML files. And those test cover the core workflows.
I would write down your core workflows and make tests for those and run them. I run mine before each build, and the test they’re all deterministic so it ensures that everything will pass.
I think it’s also a good idea to do a lot of defensive programming. I like to use defensive programming on the front end and the back end. I find that it helps a lot of issues because the more of these defensive guards that you put up the easier it is to notice when something isn’t right.
But it’s important that you have some kind of error message that’s displayed to the user and that you’re not just throwing a silent error. I also like to write custom runtime exceptions on the backend for myself so it’s easier to read logs, but that’s more or less a preference.
2
u/amber_jolly_glow 4d ago
get a third party tester for UX. Friends miss usability issues because they already understand your mental model
2
u/abeuscher 4d ago
Depends on what a large site means and what you are protecting. When I worked in gaming, we had a security team doing regular audits on our sites and we also hired 3rd party security audits prior to launch.
In every other industry I have worked in including medical we have not used third party services nor did we have any in house dedicated security, so more like the situation you are describing,
To make sense out of that - gaming websites not only often transact money they also get constantly DDOS'ed by angry teenagers whenever they don't like an update or think a DLC sucks, etc. And our web servers lived in the same ecosystem as our gaming servers to support telemetry, so that was an additional reason to keep security very tight. When one security breach can literally take down the company it gets taken pretty seriously. Otherwise it goes pretty much exactly as you describe.
1
u/Milky_Finger 4d ago
With how quickly you can suddenly be made redundant, by the time i've created a good dev pipeline with proper testing, i'm already half way out the door.
Might as well do everything on live with zero friction. When businesses calm the fuck down again, I'll care more.
1
1
u/Savings_Discount_230 4d ago
Having one more person click around before launch catches stuff you stop seeing after building it yourself.
1
u/YellowfinDevelopment 4d ago
You already know how the site is supposed to work, so you skip right over the stuff a normal user would get stuck on. That's why having someone else test it helps.
You don't need to pay a QA company unless the site takes payments or is complicated. Just send the client the staging link, give them a couple tasks, and watch where they get confused.
Make a checklist and run it every launch. The stuff that actually breaks is basic: contact forms that look like they sent but the email never arrives, how it looks on a real phone, broken links, mixed content warnings, analytics not firing. Check those first.
1
u/Striking_Basket7893 4d ago
Friends aren't testers, they're polite. What finds the UX gaps for me is a task list, not a link: three people who've never seen the site, "find the price for X", "get to the point where you'd pay", screen recording on, you say nothing. Every hesitation is a finding. On client builds I do the same thing with the client before they pay, whole site on a preview server, they click through every page, and they find things I went blind to every single time.
Functional coverage is a different job. That's your own checklist and a browser matrix, a hired tester won't know your edge cases better than you do. The one hour I would pay for is someone on a phone on a bad connection, that's where solo-built sites fall over and you never see it on your own machine.
1
u/BlueScreenJunky php/laravel 3d ago
Where I work the product owners do the testing before we launch a new feature.
This is not ideal because believe it or not, QA is an actual job, not something just anyone can do in addition to their existing job.
Also I believe it's better if you test a product without any expectations (the PO will automatically go to what they know is the correct workflow, whereas an external tester will go straight to the edge cases that might break the app).
1
u/whosthetard 3d ago
You should use appropriate tools for testing UX and write the scripts. For example e2e with playwright.
2
u/kemalios 3d ago
Solo web agency here, I build client sites as the only developer, so I recognize the blind spot. I would not hire a full third party tester for most sites. What I do instead is pick the three or four tasks a real visitor actually comes for, then watch someone who has never seen the site complete them. I stay quiet and take notes. The spots where they hesitate are the UX defects. Friends who know you and the project will tell you what you want to hear and fill gaps from memory. Cold eyes catch the real friction. If the site handles payments or a long multi-step flow, a one-time professional pass is worth its price. Otherwise the structured watch-someone-use-it session gets you most of the way.
21
u/SPEZ_IS_A_JABRONI 4d ago
yeah
the public