I’ve gotten quite a few calls today from recruiter telemarketing call centers in India. One was for a local company that handles most of the contracts at a very large local software company (which also sells keyboards and mice.)
Anyway, I’m a little more desperate for work now, so I thought I’d humor this one and fill out their forms. I started off okay, but got a little tongue in cheek towards the end for a position I’d probably consider “beneath me”, which I’m probably not qualified for, at a company I’d prefer not to work. Of course, if they like my answers, I think I’d change my mind about wanting to work there.
Here are my answers:
1. What is ad hoc testing?
Ad hoc means that it does not follow a detailed plan. It can either be done through normal usage or exploratory testing. It is a good idea to plan for some amount of “ad hoc” testing, as it may reveal unanticipated defects, or help identify areas that could be targeted for future, more methodical testing.
2. What goes into the body of a good bug report?
First of all, a bug report summary should be contain a concise description of the problem that makes it easier to search for, and identify the problem specifically. The body of the report should contain a more detailed description, as well as steps to reproduce the problem, expected results (as well as the actual, unexpected result), and any necessary setup or data needed. Attachments with further information might include an excerpt of the log file or screenshot identifying the problem.
3. What is the difference between priority and severity?
The severity of an issue reflects how great of a problem it is believed to be. Indications of severity might include the number of users or amount of the system affected by the issue. Priority, on the other hand, represents a decision as to how important it is that the issue be fixed. Priority is, by definition, a relative measurement, while severity is qualitative. Two issues may be identical in severity, but have different priorities. While severity and priority are often correlated (a high severity issue is likely to be high priority), it is not necessarily so.
4. What is regression testing?
Regression testing is done to ensure that the quality of code does not “regress” or decrease. Regression is also sometimes used to mean the “recurrence of defects”, though that usage is not as intuitive. The purpose of regression testing is to verify that the system continues to perform as expected after changes have been made. The practical method of ensuring this is to re-execute tests that have been known to pass previously. A major challenge with regression testing is that as the system grows over many iterations, the amount of regression testing increases to the point where it is not practical to execute all tests. Automation of regression tests helps, but is not a complete solution for this problem. It can thus become necessary to target a subset of all tests for regression.
5. What are the different test categories that test cases are commonly grouped by?
There are several categories of tests. Common usage includes:
- unit tests – designed to test individual code components in isolation
- integration tests – designed to test several units of code working together
- functional tests – designed to test the features or requirements according to the design. These are sometimes also called “acceptance tests”, though “user acceptance tests” are also sometimes considered a separate category, since they are performed by, or in behalf of the end user.
- system tests – designed to test the system as a whole. “System integration tests” tests multiple systems interacting the way lower level “integration tests” test individual components interacting.
Other types of testing include performance testing, load testing, penetration testing, security testing, usability testing, etc.
6. How would you test a light bulb?
If it was in the socket, I’d turn on the switch and see if it lights up. If not, I’d shake it and listen for a rattle that would indicate that the filament is broken. Seriously, I know this isn’t what you’re looking for, but I thought I’d take the opportunity to make a point about requirements rather than play the interview question game anymore.
7. When is a product ready to ship?
It’s always ready to ship. Don’t you practice Agile, use continuous integration, and shoot other silver bullets? Truth is, that’s a management decision, not a measurable quantity of quality.