Testing interview

The following content is taken from Cracking the Coding Interview.

Testing problems usually fall under one of four categories

1. Test a real world object(like a pen)
2. Test a piece of software
3. write test code for a function
4. troubleshoot an existing issue

Remember that all four types require you to not make an assumption that the input or the user will play nice. Expect abuse and plan for it

1. Testing a Real World Object

example Question : How would you test a paperclip?

step1. Who will use it? And Why?
The answer could be "by teacher, to hold papers together", or it could be "by artists, to bend into the shape of animal". The answer to this question will shape how you handle the remaining questions.

step2. What are the use cases?
It will be useful for you to make a list of the use cases. In this case, the use case might be simple fastening paper together in a non-damaging(to the paper) way.

step3. What are the bounds of use?
The bounds of use might mean holding up to thirty sheets of paper in a single usage without permanent damage(e.g, banding), and thirty to fifty sheets with minimal permanent bending. The bounds also extend to environmental factors as well

step4. What are the stress/failure conditions?
No product is fail-proof, so analyzing failure conditions needs to be part of your testing. A good discussion to have with your interviewer is about when it's acceptable(or even necessary) for the product to fail, and what failure should mean.

step5. How would you perform the testing?
For example, if you need to make sure a chair can withstand normal usage for five years, you probably can't actually place it in a home and wait five years.

2. Testing a piece of Software

it is actually very similar to testing a real world object. The major difference is that software testing generally places a greater emphasis on the details of performing testing.

two core aspect to it

• Manual vs Automated testing : In an ideal world, we might love to automate everything, but that's rarely feasible. Some things are simply much better with manual testing because some features are too qualitative for a computer to effectively examine. Additionally, whereas a computer can generally recognize only issues that it's been told to look for, human observation may reveal new issues that haven't been specifically examined. Both humans and computers form an essential part of the testing process.
• Black Box vs White Box Testing : This distinction refers to the degree of access we have into the software. In black box testing, we're just given the software as-is and need to test it. With white box testing, we have additional programmatic access to test individual functions. We can also automate some black box testing, although it's certainly much harder.

step1. Are we doing Black Box Testing or White Box Testing?
Though this question can often be delayed to a later step, I like to get it out of the way early on. Check with your interviewer as to whether you're doing black box testing or white box testing- or both.

step2. Who will use it? And why?
Software typically has one or more target users, and the features are designed with this in mind.

step3. What are the use cases?
In the software blocking scenario, the use cases of the parents include installing the software, updating controls, removing controls and of course their own personal internet usage. For the children, the use cases including accessing legal content as well as "illegal" content.

step4. What are the bounds of use?
Now that we have the vague use cases defined, we need to figure out what exactly this means. What does it mean for a website to be blocked? Should just the "illegal" page be blocked, or the entire website?

step5. What are the stress conditions / failure conditions?
When the software fails - which it inevitable will - what should the failure look like? Clearly, the software failure shouldn't crash the computer. Instead, it's likely that the software should just permit a blocked site, or ban an allowable site.

step6. What are the test cases? How would you perform the testing?
Here is where the distinctions between manual and automated testing and between black box and white box testing, really come into play.
Step 3 and 4 should have roughly defined the use cases. In step 6, we further define them and discuss how to perform the testing.

3. Testing a Function

In many ways, testing a function is the easiest type of testing. Suppose you were asked to write code to test 'sort(int[] array)' which sorts an array of integers. You might proceed as follows.
step1. Define the test cases

• The normal case: Does it generate the correct output for typical input? Remember to think about potential issues here.
• The extremes: What happens when you pass in an empty Array? Or a very small(one element) array? What if you pass in a very large one?
• Nulls and "illegal" input: It is worthwhile to think about how the code should behave when given illegal input.
• Strange input : A fourth kind of input sometimes comes up: strange input. What happens when you pass in an already sorted array? Or an array that's sorted in reverse order? Generating these tests does require knowledge of the function you are writing. If you are unclear as to the constraints, you will need to ask your interviewer about this first.

step2. Define the expected result
Often, the expected result is obvious: the right output. However, in some cases, you might want to validate additional aspects. For instance, if the sort method returns a new sorted copy of the array, you should probably validate that the original array has not been touched.

step3 Write test code
Once you have the test cases and results defined, writing the code to implement the test cases should be fairly straightforward.

4. Troubleshooting Questions

A final type of question is explaining how you would debug or troubleshoot an existing issue. many candidates balk at a question like this, giving unrealistic answers like "reinstall the software". You can approach these questions in a structured manner, like anything else. Reinstalling the browser might solve this user's problem, but it wouldn't help the other users who might be experiencing the same issue. your goal is to understand what's really happening, so that the developers can fix it.

step1. Understand the Scenario
The first thing you should do is ask questions to understand as much about the situation as possible.

step2. Break Down the Problem
Now that you understand the details of the scenario, you want to break down the problem into testable units. A strong tester would iterate through the elements of this scenario to diagnose the problem

step3. Create Specific, Manageable Tests
Each of the above components should have realistic instructions - things that you can ask the user to do, or things that you can do yourself(such as replicating steps on your own machine). In the real world, you will be dealing with customers, and you can't give them instructions that they can't or won't do.