Software Testing Interviews in India - Importance of definitions for a Tester!

Last Sunday I was having a conversation with Ajit, a tester friend who works for a reputed Software MNC. He has been in testing field for more than 4 years now with experience in some cool domains. He is in his current organization since 2 years and now, much to his discomfort his company has started sacking employees citing the goddamn recession as an excuse. So obviously Ajit feels a sense of job insecurity despite his good performance in the organization all these years. People with such experience will tell you, it is never easy to concentrate on your job when you are insecure about it and always in fear of a pink slip landing on your desk bringing the news of misfortune. And it would not be long before you would find yourself searching for a new job (even though that would not mean any better sense of job security). May be, it is human nature to change nest when they feel a storm might be on it’s way. Obviously, it is no secret that Ajit has also started job hunting and has started appearing job interviews. If you have started to wonder if this post is going to talk about the current recession and it’s impact on people in IT industry, then I am sorry for disappointing you. I am no economics expert, and hence I don’t think I can take a look into the global slow down and suggest any solution.

The idea of this post came from a question that Ajit raised during our conversation. He has been attending some interviews recently and has spotted an interesting tendency among the interviewers, i.e. “they tend to ask lot of can-you-define-xyz-testing kind of questions”! Ajit was curious why they are so much interested in the definition of some testing buzzword, whereas they should be more interested in judging the level of competence of the tester being interviewed, by asking her some practical questions.

I can understand how stupid it can be to ask such “define this testing terminology” kind of questions. The stupidity would be more obvious if we take a look at the following reasons:

1. No testing terminology can be defined in a single unanimous way. Any particular term may mean differently to 2 different testers, testing organizations, schools of testing, testing gurus depending upon their own understanding of that particular testing terminology. Then how can the interviewer ask the candidate to define something and expects that their definitions match?

2. A single underlying testing principle might be called differently (different testing terminologies) by a different group of testers depending on their organizational practice, education, school of thought etc. Then how can the interviewer ask the candidate to define something and expects that their definitions match?

3. Lets say, I have memorized the definition of a testing buzzword and I am lucky! My definition (luckily/coincidentally/by chance) matches with the definition that my interviewer had memorized from his testing institute days. So suddenly, I look more competent as compared to other candidates whose definitions had not (due to bad luck) matched with the interviewer. But what does this prove? Does this prove that I have applied this understanding in practice? Does this prove that I can apply my understanding of that buzzword in real life testing? Does this prove that I am a better software tester than the earlier candidates who could not define it in a way that maps to the understanding of the interviewer? If not, then I wonder what makes the interviewer think that asking such definitions is a good way to judge how skilled the candidate being interviewed is!

I am not saying that knowing the basic fundamentals (read as theoretical testing) is a waste of time. I agree, learning the fundaments of testing is equally important to start a career in testing. But wait, doesn’t that hold good for any other professions too? Isn’t having theoretical knowledge necessary for any other profession? Then why is the fuss? The problem seems to arise when people on the interviewer's chair start imagining that whatever they know is the ultimate truth about testing and all the rest (read as candidates) must also know it. This problem becomes even worse when the interviewers start to think that testing is just all about textbook definitions and fundamentals (types of testing, levels of testing, testing life cycle, verification vs. validation, smoke vs. sanity testing, test automation, testing certifications, and so on).

Stories like Ajit’s often make me wonder if software-testing definitions are so important for becoming a skilled tester that they must be asked in interviews! Is it an absolute necessity to know how something is called (definition) to be able to actually do it? I think the answer lies with the Mother Nature. An average human child starts to smile, cry, sleep, play, crawl, stand and even walk much before it actually learns to SPEAK (define?)! If a child can do so many things even before knowing how they are called and described (defined), then why should it be so mandatory for a tester to define something in order to apply it in practical testing? I have come across many exceptionally good testers who are great at testing even though they often don’t realize that there must be a term to describe what/how they perform testing. At the same time I have come across many testers who are like the bookworms of a testing bible (they know every nook and corner of the textbooks and know each and every word in it), but when it comes to apply that knowledge into testing, they often fail miserably.

Then why do we give so much importance to testing definitions in interviews? Is it wise to ask these questions just because we were asked the same in our interviews? Is it a good way to judge whether a candidate for testing is skillful by asking some testing definitions [as if there is no better way to judge a tester’s competency]! Let me hear what you think.

Happy Testing…

How to test on a tight testing schedule?

If you have spent some time in the field of testing, then you must have faced situations where you were asked by your test manager to test the application on the fly and deliver your report in XYZ days [replace XYZ with as few days as you can]! In case, you have not faced such a situation yet, then either you are unbelievably lucky or with all due respect, you have not worked on sufficient projects. But either way, it won’t be long before you encounter such a situation in your career as a software test engineer.

Contrary to popular belief/myth, proper skilled testing requires lot of planning, effort and work, and hence a substantial amount of time. But unfortunately, when projects get delayed, the time planned for testing invariably gets the hit while squeezing the schedule. What? The development team is running 2 months behind the schedule? No problem. Time for the magic trick! Squeeze the testing schedule by 2 months and presto! Congratulations, we have got ourselves back on the project schedule. Cool, isn't it? Well, probably not!

If you have started to presume that this post is going to criticize how project management stinks, then thankfully, you are mistaken. Because, as a tester I believe that a part of my job is to act like a “problem solver”. So instead of whining about how the rescheduled testing time frame keeps killing the poor tester, I would rather concentrate on finding a way to deal with such a situation. When you are hit by such a squeezed testing schedule, first thing that you could do to help yourself deal with it, is to “accept it”. This kind of things keep happening to everybody who works on a software project. Once we accept it as a part and parcel of our profession, dealing with it would suddenly start looking easier.

When facing a short time frame available for testing, you have to make the best use of the time and resources available. Starting testing with an assumption that “we can’t test everything, no matter what”, can really help. Even from an economic stand point it does not make any sense to spend lot of time and energy testing areas of the application where the chances of having bugs are low [this we can fairly tell based on our previous testing experience]. Also identifying areas where the impact would be negligible [based on expected user behavior] even if bugs were found is a good strategy while starting testing. As a rule of thumb determining what to test first and in which sequence, so that you spend the limited time testing areas that really matter, is an important decision that requires certain amount of analysis, intuition, and experience. Start doing a risk analysis to identify functions with the highest risk [thus most important and need highest attention] and functions that would be used most by the end user. Having a checklist to remind you of key areas that you would not want to miss certainly helps. Here is a checklist that I often use when I have much less time than I would have wanted to bargain for testing an application:

» Functionalities that are often used by the users. Start by asking yourself, “Which functionality is most visible to the user”.
» Functionalities those are most important to the project’s intended purpose.
» The most risky areas of the application with the largest safety impact. Areas, which if broken can bring down the entire application to it’s knees. [Talking to the developers for suggestions on the same is probably a good idea here].
» The areas of the application with the largest financial impact on the users (and hence on the project stakeholders).
» Newly added functionalities. Often they are the least tested ones and hence the dirtiest.
» Complex functionalities those are easy to be misunderstood (and hence misinterpreted). Look for parts of the code that are most complex, and thus most prone to errors.
» Functionalities that are based on parts of the requirements and design that are unclear or poorly thought out.
» Functionalities that are developed using challenging new technology, tools, architecture.
» Functionalities that are developed in rush or panic mode.
» Functionalities that demand a consistent level of performance.
» Functionalities that reflect complex business logic.
» Functionalities that require interfacing with external systems (e.g. third party shrinkwrapped software). These are often classic areas to look for integration bugs.
» Functionalities developed under extreme time pressure.
» Functionalities that had recent updates or bug fixes.
» Functionalities developed by many programmers at the same time.
» Functionalities those are most important to the project stakeholders.
» Identify related functionalities of similar/related previous projects that caused problems (in terms of user reported bugs). Correlate them to the current application and try to use it to your advantage.
» Identify related functionalities of similar/related previous projects that had large maintenance expenses. Correlate them to the current application and try to use it to your advantage.
» Identify functionalities, which if gone wrong could result in bad publicity.
» Identify functionalities, which could cause most customer support complaints.
» Devise tests that could cover multiple functionalities/features at the same time.
» Devise tests that could cover high-risk-coverage at the minimum time.

This is clearly not the exclusive list of guidelines/checklist to test under a tight testing schedule. But still, it covers quite a lot of important areas that usually needs attention. Being a context driven tester, I am well aware of the fact that using this checklist may or may not help a tester who is trying to test an application on a jam-packed schedule. However, it has served me quite well whenever I was in need of it.

What do you do when faced with such a situation of a tight testing schedule? How do you react when you suddenly find yourself being stripped off with some valuable testing time at the very last minute of a project deadline? How do you readjust your testing strategy to cope with it? Do you have any such checklist that you follow? I would be delighted to hear your ideas.

Happy Testing…