Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users

Dashboard
Notifications
Mark all as read
Q&A

What user-facing things aren't covered well by automated tests (and should be tested manually)? Question

+1
−0

We have automated tests (good). Automated tests usually don't cover everything, so when there's a new version we want to test (say, on the dev server), I'd like to be able to prioritize things that wouldn't be uncovered through our automated tests.

Maintaining a full catalog of test cases as seen through the user-function lens is impractical, but can we have a "punch list" of user-visible areas or actions -- things that we know are not covered, or not covered well, that human testers should be sure to poke at?

If I'm kicking the tires of something on the dev server to try to answer the question "is this ready to go?", what should I focus on?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comments

1 answer

+2
−0

The really core features (posting, voting, commenting, editing) are pretty thoroughly tested; we only really need to test those exhaustively by hand if we're making significant changes to them - otherwise it's a reasonable assumption that if the tests passed then they're working.

It's as we get outside of core features that testing starts falling off. We have especially limited testing in moderator and admin tooling, because that's not something that most users will ever see.

We have no tests for the UI. Our existing tests essentially simulate a request and assert various conditions on the response, but there's no real way to test that the UI we've created actually submits an identical request. I always test any new UI I create before pushing it, but especially for major changes this should be a focus.


Writing tests is probably one of the easiest parts of the application to pick up, so if folks have ideas for test cases, it may well be quicker to write the test yourself and submit a PR. I'll write up a separate post on how to create a test case.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

Sign up to answer this question »

This community is part of the Codidact network. We have other communities too — take a look!

You can also join us in chat!

Want to advertise this community? Use our templates!