Writing Tests for an object/scenario/application in a testing interview:

Sometimes interviewers give an object or a scenario and wants interviewees to write tests for them. The intent behind these questions is to identify if the interviewee could understand the situation and think of various ways to tests the system. It would also give an idea about the interviewee’s lateral thinking. The wider you can think, the more is the coverage. In situations like these try to come up with as many tests as you can but always start with the most important usecases. There is no correct way to write the test but if you keep the following in mind you would be able to cover much ground:

1: Think of all the use cases first (as many as you can). These would be mostly priority 4 functional tests. Eg, If you were to test a Bangle (metallic ring), you could write the following usecases:

a: Bangle could be worn.

b: could be used to draw circle.

c: could be used to hit somebody.

d: could be used to open beer bottles.

e: could be melt to extract metal which in turn could be used for various purposes

so on and so forth

2: Think of all the atomic parts the object is made up of and write tests on them. For the whole system to function properly, each of its components should be functioning properly. Eg, suppose the interviewer asks you to test a PEN. Pen could be further broken into a refill, a cap, a grip, a case, a nib etc. Write tests for each of them (The interviewer could argue that these are unit tests to be performed by developer)

3: Apart from functional tests a quality product/feature should be evaluated on non functional aspects as well. You could consider writing tests for the following non functional test types:

• Performance
• UI
• Usability
• Security
• Localization and Globalization testing
• Recovery testing
• Negative testing
• Compatibility
• Workflow etc.

 4: Tests to be written keeping in view the datapoints into application. Application should be tested using valid and invalid data. Popular techniques like boundary value analysis and equivalence partition could be used here.

1: Valid inputs and different type of valid inputs.

2: Invalid inputs and different types of invalid inputs.

3: Special inputs (like zero null, blank values)

5: Sometimes the application given by the interviewer is too complicated to understand in the first go. The intention of giving a complex system to test is to test how you grasp things, how you make assumptions, what do you do for things are not clear. In such situations ask questions (VALID questions), as many as you can. The more questions asked the more understanding you’ll develop and easier it would be to write tests

Also think of the components working behind the scenes. The interviewer might not explicitly tell you to tests them but you should be able to write test for them as well. A classic example would be to test a chat messenger or a login page. Nobody would ever tell you that there is a database working at the backend but it would be important to test the databases functions properly.

6: Think of the environment surrounding the application. The interviewer would talk about one of the supported environments. DO NOT make assumptions. Ask questions to yourself like what would happen if you change the environment itself. Eg, you could say that a pen is working in India. But could you say that the same pen works in Antarctica or a place with zero gravity. These would also be important tests. Another Eg, suppose interviewer wants you to test a login page. The login page could be viewed on various OS platforms, various devices and on a variety of browsers.