Aundria Richard Technology

I am not suggesting that these are the only questions that would be asked, but are some samples for consideration. These are questions that I have used when interviewing others:

1. How many test scripts can you write in a day?

I am looking here for the ability to estimate. Whilst in reality the question is impractical, because it depends on so many different factors, I want to see the interviewee come up with some kind of answer. When estimating, there is a need to make assumptions and having a ball park figure enables someone to provide rough estimates more quickly.

2. How many test scripts can you execute in a day?

This is a repetition of the first question. I normally ask one directly after the other. The more junior resources tend to struggle with the first question and then the second also. The better resources learn from the experience of the first question and respond in a more positive manner to the second. Now I am not only looking at the ability to estimate, but also the ability to learn and an indication of the resources chances of seniority going forward.

3. Do you see testing as a service or a discipline?

Personally I am quite passionate about this one. I very much see testing as a discipline and a part of the software life-cycle that is as important as analysis, design and development. What I am trying to understand is the background that the individual someone has come from. Consultancy can demand one or other mindset and someone coming from either background can adapt, but I would suggest it is easier to revert from discipline to service than vice versa.

4. What is the most interesting defect you have found?

This is a passion question. I am looking to see if the individual can recount a particular incident and in what degree of detail. This begins to tell me whether they are a career tester or someone who is doing a job.

5. What are the key components of a test script?

Let’s say that you have a software project that’s under severe time pressure. Let’s say that this deadline is so tight that you already know it will involve many late nights of black coffee and frenetic programming. What can you do to make this process go faster?

I honestly don’t know, since the correct answer will depend on one’s individual circumstances. However, I can tell you how many programmers do respond under such circumstances. They decide to save time by skipping over the software planning and design phase, and immediately start coding away.

To an inexperienced or otherwise undisciplined programmer, this seems to make sense. After all, the finished product is what truly matters, right? The customer doesn’t care about flowcharts, class diagrams or software architectures. All they want is something that works.

It seems to make sense, but it’s a foolhardy approach. That way lies madness. We’ve all heard that an ounce of planning is worth a pound of cure, but in the world of software development, this adage is often forgotten.

If a real estate developer needs to get a house built quickly, does he save time by skipping over the architectural design phase? Does he decide to dispense with blueprints, and just start laying down concrete? Of course not. He knows that the results would be chaotic, and that work will progress more slowly without careful forethought and a concrete plan.