> Is there a standard in systematically walking problem space? or should doing it in my way?

Yes and no.

An important idea is to principally check corner cases, where potential errors lurk.

What the corner cases are depends on the system under test, of course.

There are a few rules of thumb, such as if there are limits to the input, check around the limits (e.g. if your function under test expects a month as its input, do the obvious thing of checking month 1, 12, 0, 13, Null, "foo"). Or if your function takes a list, use the (0, 1, infinity) rule: try with the empty list, a list with one entry, and a list with "infinite" (in practice: very very many) entries. Etc.

But you also should try to get an understanding for the SUT, to find corner cases that are less obvious or cookie-cutter.

And have opinions on how efficient/throrough your test suite should be: does the function under test just provide decoration, or does it make life-and-death decisions? The effort invested in testing them would certainly differ based on this assessment.

Again, the ISTQB syllabus provides helpful guidance.