Tag Archives: functional

How Would You Test a Toaster?

Posted on by
Reply

This is another example of a testing in the wild interview question, and it’s your role again to 1) show what you know about software testing in general; and 2) show how you can apply your general knowledge to a specific problem.

First off, you should talk about the requirements for a toaster. A toaster toasts bread. It doesn’t burn bread. It doesn’t set on fire. It does allow for several pieces of toast to be toasted one after the other.

Then, talk about general kinds of testing, and how they can be applied in this case. Some possible things to mention might be black box testing, white box testing, load testing, and usability testing.

At this point, you’ve shown you know the basics of what software testing is about. Now move on to applying that to the toaster.

First off, how would we test a toaster using black box testing? We simply give it an input (a piece of bread), look at the output (the toasted bread), and check that the required functionality is satisfied (bread is toasted, not burnt).

Secondly, wow would we test a toaster using white box testing? This would require knowing how the toaster does its magic, and checking that this actually happens. I’m not sure how toasters work, but I imagine it’s electricity passing through a coil and heating it up. Assuming that this is the internals of the toaster, our white box test would be to somehow take a look inside the internals of the toaster once we put the bread in, and to verify that electricity is indeed passing through the coils and heating them up.

What about load testing? Toasters generally handle at most a few pieces of toast, so we can’t toast dozens of pieces of bread concurrently. However, we should be able to toast 10 pieces of toast one after the other, and the toaster should toast all the bread well.

Finally, we might want to test the usability of the toaster. What is the user experience with the toaster? Is it easy and intuitive (put the bread in, push down a button)? Or, is it complicated and confusing (put the bread on a tray, enter a temperature range by pressing a small button on the side repeatedly, then hold down the button to activate the toaster)?

Altogether, this would be a good answer to the toaster software testing question, but if you want, you could also apply additional software testing types to the toaster problem.

Types of Software Testing

Posted on by
1

Types of Software TestingWhat are the different types of software testing?

If you’re asked this software testing question during an interview, first list some of the different categories headlined below. Be prepared to explain a little bit about each of the different types of software testing to show the interviewer you have a broad knowledge of software testing.

White Box vs. Black Box Testing

These are probably the two most famous types of software testing.

The difference between them is the level of insight that a tester has into the program under test.

White box tests mean that the tester has some insight into the inner workings of the program. In general, this means access to the code, but it could just be access to API’s or a description of system internals.

Black box testing is testing without this kind of access. In general, this means you know what the program is supposed to do, and you have to check that the program actually does what it should by feeding in input and looking at the output.

Unit vs. Integration vs. System Testing

The difference among the three categories is the level at which the tests are performed.

Unit testing is done at a very low level: typically individual methods or functions.

Integration testing is done at an intermediate level. Imagine that a part of your program has to read in and process an Excel file to represent it in some internal format. A second part of your program takes the internal representation of the Excel file, and does some computation based on it. Both of these parts can be internally complex (for example, consisting of multiple classes), but they are not the whole of your program. Testing that both of these pieces work together as expected would be an example of an integration test.

System testing is done at the system level: making sure that the system as a whole actually does what it should.

Regression vs. Acceptance Testing

The distinction is the objective of the tests (though also when the tests are performed).

Regression testing checks whether a new change broke something that used to work (so the program regresses to an earlier state with worse functionality). In order to test for regressions, you need to have a body of tests that are run regularly (let’s say, daily, or after every code change), and to compare the outputs.

Acceptance testing is performed to check whether the completed program satisfies the specifications as given by the customer. Preliminary acceptance testing is first performed internally by the developers or by a testing team. A second (and hopefully final) step is user acceptance testing, in which the user or customer goes through the program and validates that the program meets the requirements.

Functional vs. Non-Functional

The distinction is whether you are testing what the program does (functional) or how it does it (non-functional).

Functional testing means testing program correctness: the program should do the right thing (and not crash, or give a wrong result).

What other things might you care about besides correctness? Some answers are resource usage, security, and usability. These are all examples of non-functional testing.

Stress vs. Load vs. Performance Testing

Not much distinction here. Generally all three refer to working the system to check how it behaves and whether it might crash, become unusably slow, or eat up crazy amounts of resources.