4 ms·
While I'm sceptical of the ISTQB certification as such (I'm certified, nobody ever cared), I agree with ahoka that the syllabus offers you a very useful guideli
by InternetOfStuff 8y ago
While I'm sceptical of the ISTQB certification as such (I'm certified, nobody ever cared), I agree with ahoka that the syllabus offers you a very useful guideline to understand the field of testing, especially the nuances and tradeoffs involved.
Go through it, and think about things like the seven testing principles.
If I were to interview you, I'd also throw a whiteboard-ish test at you: I'd pose a problem to you (say, I'd explain a function) and ask you to find test cases.
It's been my observation that this kind of exercise is pretty good at separating the wheat from the chaff: I could see who dares to ask questions, I could see who systematically walks the problem space, I could see who even thinks of testing not just the functional requirements, but also the non-functional ones.
Most importantly, I could use this as a way into a discussion, and see how people carry themselves in such a (vaguely work-like) situation.
I suspect the interviews I conducted were on the more rigorous side, so you might be spared whiteboard tests, but in any case it can't hurt to to try and exercise actually creating and reasoning about test cases.
Also, it can't hurt to find out about the testing tools they use. Either you can find them outright, or you can at least make educated guesses about what they use based on the technologies they build their product on. Actually trying them out would be asking too much, but at least get a feel for what their purposes and limitations are.
- merbot 8y agoIs there a standard in systematically walking problem space? or should doing it in my way?
- InternetOfStuff 8y ago> 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.