Testing

There are four ways that an interview might phrase an interview question about testing: 1) test a real-world object, 2) test a piece of software, 3) write unit tests for a function 4) troubleshoot an existing issue.

Test a real-world object

Step 1: Requirements analysis (who will use it and why)

Suppose we were to test a pen.  We could say that a student is using it to write notes in class.

Step 2: Use Case analysis (describe how the object is used)

The pen writes on the page when the student attempts to copy notes from the teacher

Step 3: What are the limits of the object (what values are ranges are permitted)

The pen is only designed for paper and is not required to write well on the desk or other surfaces.

Step 4:  Failure conditions (when is it appropriate that the object fail and how can it fail in a safe manner)

It is appropriate that the pen stops working after copying 100 pages and running out of ink.  The proper way for this to happen is for the notes to stop being as dark.

Step 5: How to perform the testing (some automated testing might be needed)

Test the pen does write on paper.  Run a machine to test that it writes correctly for 100 pages and record what page the pen starts to run out of ink.

Test a piece of software

Very similar to testing a real-world object.  The key difference is the greater emphasis placed on how you test it.

Step 1: Requirements analysis (who will use it and why)

Suppose we want to test a simple text editor like notepad.  Users would include a person using it to write text such as small programs written in javascript.

Step 2: Use Case analysis (describe how the object is used in detail)

User selects “open file” and the program loads the previously saved file, User selects “saves  file” and the program prompts for a filename and then saves a copy of the text to disk under said file name, User types in text and then the text box records said text for later viewing or editing, …ect

Step 3: What are the limits of the object (what values are ranges are permitted)

What sort of text is recorded in the text box (maybe not the arrow keys), how large of a file can the program save…ect

Step 4:  Failure conditions (when is it appropriate that the object fail and how can it fail in a safe manner)

When a file is too large to fit on disk through an error stating that there is not enough disk space to save file.

Step 5: How to perform the testing (when you do this list, list things in an organized, structured manner so your list will be more comprehensive)

Settings: font: when a user changes font change only the highlighted text

Settings: word-wrap: when a selects make the words wrap around instead of scroll

Text Box: typing an accepted character results in corresponding text appearing in text box…ect

Test a function

Somewhat simpler to reason about.  This exercise requires less initial requirement analysis as the problem is more laid out for you.

Step 1: Define the test cases (normal case, nulls & illegal input, extreme cases)

Step 2: Define the expected result (check that expected value returned, but also make sure no side effects occur)

Step 3: Write the test cases (simple setups and checking values, typically fairly straightforward)
Below is a video helping you get started with writing test cases in JavaScript

Troubleshooting

Sometimes interviews ask questions about solving bugs.  Here is a way to break down bug related problems:

Step 1:  Understand what is happening (how long this has been an issue, what version or OS, does it happen consistently, what does the error say)

Step 2: Break down the issue (write the series of steps that a user would take to recreate the issue)

Step 3: Write Specific Instructions (write out the full testing procedure that should be done to test that this is fixed)

Practice

Try writing Unit Tests for your backend code for one of your projects.  This should test your API to ensure that the right data is returned in various scenarios.  Be sure to include what happens when bad input is supplied or in edge cases where there is no data in the database…ect