
Ask HN: Test Engineer Interview - merbot
Hi,
I am currently going for an interview for position as test engineer at software company. What should I prepare for the interview? since I am new to this position actually. Also, are there any resources to learn about test engineer?
======
InternetOfStuff
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
Is there a standard in systematically walking problem space? or should doing
it in my way?

~~~
InternetOfStuff
> 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.

------
ahoka
You can prepare using ISQTB materials:
[https://www.istqb.org/downloads/syllabi/foundation-level-
syl...](https://www.istqb.org/downloads/syllabi/foundation-level-
syllabus.html)

I have never worked as a test engineer but as far as I know most large
companies use the ISTQB certification, and it covers most of the basic test
know-how.

~~~
merbot
thank you, starting reading this materials

------
ankitsoni
Test Engineer is a broad term. I would look at the job description and prepare
accordingly. Here are some things you should look into: \- Types of testing:
white/black box, functional vs non-functional, API testing, browser-based
testing \- If you are asked to write test points for a function/form etc. make
sure you cover positive, negative, edge cases, upper/lower limit etc.

Good luck!

~~~
merbot
I understand about white/black box testing, functional vs non functional. But
I am confused on covering positive, negative, egde cases part, could you
please explain this.

------
gwbas1c
Test engineer: Basically, you're interviewing to perform QA. On the job, you
may "engineer" a lot of automated tests.

(Sometimes this isn't clear, because at the beginning of our careers a lot of
us want to be developers.)

~~~
ilikehurdles
Maybe there are still companies out there that do the defunct record-actions-
and-replay approach to automation, but luckily my experience was just as heavy
on the engineering side as any of the software engineering work I've done
since I "switched". You just don't get as much respect from the software
engineer crowd because building CRUD APIs using web frameworks is considered
engineering and building an automation framework from scratch is considered
QA.

Sorry if I came off on the offensive, just didn't like seeing "engineer" in
quotes.

~~~
polotics
Word! The level of respect that a developer shows towards test and reliability
engineering is also a great way to identify skill and experience.

