How many times have you cringed on being asked this question? Kunal Guha explains the logic behind it
If a poll was conducted on ‘worst interview questions’, this one would probably top the list. And as pointless as it may seem, recruiters don’t seem to tire of asking the question-‘where do you see yourself five years from now?’ Let’s find out why your answer to the above is so important.
TESTING SINCERITY
Contrary to technical questions that could be answered with mechanical ease, this one requires one to think, unless you’ve subscribed to ‘Accepted Interview Answers Digest’. Recruiters, however, can easily see through rehearsed answers and pick out the genuine ones. “A lot of interview questions are based on the person’s accomplishments and choices. Answers to these questions demonstrate a pattern, on the basis of which one can evaluate the applicant’s future aspirations. The trick is to observe how well the applicant’s responses tie in with what one has done, and how well one is able to logically break down one’s career steps. I have seen candidates who broke down their long-term goals into small logical steps,” explains Manoj Varghese, HR Head, Google India.
Recruiters also pay a lot of attention to a candidate’s career record. “Responses backed by a documented track record are valued most. The response may be rehearsed, but the same can be easily validated against the candidate’s track record. Also, an employer’s own experience helps assess whether the candidate’s aspirations are realistic,” explains M V Subramanian, Director-Staffing, HP India. Satish Venkatachaliah, HR Head, SAP Labs, seconds the thought, “We believe that past behaviour is the most reasonable predictor of future behaviour. In case of freshers, we try and look back at the nature of the candidates’ college behaviour - whether he/she was interactive and enterprising, has participated in extra-curricular activities and worked in teams for campus projects.”
JUDGING CHARACTER
Since where you see yourself in the future is based on your imagination, your answer could divulge vital learnings about your thinking pattern and how you would respond to any given situation. These factors could be crucial in evaluating a candidates’ potential. “In our case, if we ask this question, the reason would be to understand the individual’s thinking and quality of reasoning, self-awareness, etc. For example, the person may not know the mechanism of the organisation. Therefore, if he/ she responds to the question in the context of the organisation without asking exploratory questions regarding career growth in that organisation, then the person is obviously shooting from the hip. On the other hand, if the person responds generically, then it is important to understand why the person considers that path and not other alternatives. This will give an idea of the person’s self-evaluation,” explains Pankaj Bhargava-HR Head Marico Limited.
MATCHING EXPECTATIONS
It is crucial to understand how realistic a candidate’s expectations are and whether there is a match between the candidate’s goals and the organisations’. “Investigating a prospective candidate’s future aspirations tells us in advance about the candidates personal goals. This helps us match the candidates’ personal goals with those that we have set out for the role and the organisation. If we find a strong dissonance with the two, it would definitely affect the selection process,” explains Mona Cheriyan, General Manager, Employee Engagement & Europe Liaison, i-flex solutions limited.
Subramanian elaborates, “This question, though perhaps not the most significant, actually attempts to co-relate the candidate’s aspirational level with that of his/her potential. The belief here is that an employee is motivated when he/she sees the role in question as a path toward a larger career goal.”
PRESENTING ASPIRATIONS
You may say that you see yourself as a delivery head or a project director in 3 years, but unless you are able to logically break down your aspirations, it will be a lost cause. So, where you see yourself in the future must have a strong link with the current capacity being offered to you. “Aspirations should be always linked with the role and what the applicant would like to do within a period of time. I have seen candidates create a very good impression with the interviewers by spending time in understanding what their current role is going to be and thinking about ways to add value to that. Such candidates plan their long-term aspirations around mastering their current role, contributing in that role and then checking about the next level of contributions. Even titles can be misleading from organisation to organisation; hence an applicant expressing a desire to be a senior manager in five years may sometimes not make sense in the context of the organisation one is interviewing with,” elucidates Varghese.
It is certain that there is no right or wrong answer, when asked how you envision yourself in the future. But answers could be weak or strong and if your answers are backed by stong conviction, a weak response could be transformed into a strong one.So, now the next time you appear for an interview, make sure you’re honest, reasonably ambitious but not overtly aggressive and it should work out just fine!
Software Test Automation - Myths and Facts continued...
Observations
I have met a number of QA managers who are frustrated with their automation. According to them the tool is not doing what it is supposed to do. Here is a true story, the client (I had the opportunity to work with them for some time) found out that the tool they have just bought does not support the application they are testing (I am not making it up). How can this happen! – It does happen more often than one would think. I will get back on this when I discuss possible solutions. A manager of one of the major telecom companies that I had a recent interview with told me that after three years and more than a million dollar he is still struggling with automation. This is pretty sad and I get the feeling that he is not alone.
Solutions/Suggestions
Let’s discuss some of the reasons for this frustration and some of the solutions to this problem.
- Unrealistic expectations: Most managers have their first encounter with any automation tool when they look at the demo and everything looks nice and simple. But everything is not so nice and simple when you try to use the tool with your application. The vendors will only tell you the things you want to hear (how easy to use, how simple to set up, how it will save time and money, how it will help you find more bugs etc.). This builds a false set of hopes and expectations.
- Lack of planning: A great deal of planning is required from selection to implementation of the tool. “Evaluating Tools” by Elisabeth Hendrickson is a very good article on step by step process of selecting a tool. She talks about “Tool Audience” as one of the steps. This would be an ideal way to select a tool. It may not happen in every place because of the everyday workload of the people involved. But the participation of the users in the process is very important, because they are the ones who will use the tool day in and day out. I am almost certain that what happened to one of my clients (the tool they have bought did not support the application they were testing) would not have happened if the users were involved in the selection process.
- Lack of a process: Lack of a process may also contribute to failure of automation. Most places do have some kind of process in place. In most cases (although it differs from place to place) developers write code against a set of requirements. If the requirement does not call for a change in GUI then, there should not be any change in GUI. But if the GUI keep changing constantly from one release to another without any requirement for that change then, there is a problem in the process. You may have the best tool and the best (for your environment) architecture is in place and you will still have problems with your automation because of a faulty process.
Software Test Automation - Myths and Facts
Introduction
Today software test automation is becoming more and more popular in both C/S and web environment. As the requirements keep changing (mostly new requirements are getting introduced on daily basis) constantly and the testing window is getting smaller and smaller everyday, the managers are realizing a greater need for test automation. This is good news for us (people who do test automation). But, I am afraid this is the only good news.
Myths & Facts
A number of articles and books are written on different aspects of Software Test Automation. “Test Automation Snake Oil” by, James Bach is an excellent article on some of the myths of automation. I like to discuss some of these myths and will try to point out the facts about these myths. I also like to discuss some of my observations and hopefully point out possible solutions. These are based on my experience with a number of automation projects I was involved with.
Myth 1: Find more bugs
Fact: Some QA managers think that by doing automation they should be able to find more bugs. It’s a myth. Let’s think about it for a minute. The process of automation involves a set of written test cases. In most places the test cases are written by test engineers who are familiar with the application they are testing. The test cases are then given to the automation engineers. In most cases the automation engineers are not very familiar with the test cases they are automating. From test cases to test scripts, automation does not add anything in the process to find more bugs. The test scripts will work only as good as the test cases when comes to finding bugs. So, it’s the test cases that find bugs (or don’t find bugs), not the test scripts.
Myth 2: Eliminate or reduce manual testers
Fact: In order to justify automation, some point out that they should be able to eliminate or reduce the number of manual testers in the long run and thus save money in the process. Absolutely not true. Elimination or reduction of manual testers is not any of the objectives of test automation. Here is why – as I have pointed out earlier that the test scripts are only as good as the test cases and the test cases are written primarily by manual testers. They are the ones who know the application inside out. If the word gets out (it usually does) that the number of manual testers will be reduced by introducing automation then, most if not all manual testers will walk out the door and quality will go with them as well.
Some Classic Testing Mistakes
The role of testing
- Thinking the testing team is responsible for assuring quality.
- Thinking that the purpose of testing is to find bugs.
- Not finding the important bugs.
- Not reporting usability problems.
- No focus on an estimate of quality (and on the quality of that estimate).
- Reporting bug data without putting it into context.
- Starting testing too late (bug detection, not bug reduction)
Planning the complete testing effort
- A testing effort biased toward functional testing.
- Underemphasizing configuration testing.
- Putting stress and load testing off to the last minute.
- Not testing the documentation
- Not testing installation procedures.
- An overreliance on beta testing.
- Finishing one testing task before moving on to the next.
- Failing to correctly identify risky areas.
- Sticking stubbornly to the test plan.
Personnel issues
- Using testing as a transitional job for new programmers.
- Recruiting testers from the ranks of failed programmers.
- Testers are not domain experts.
- Not seeking candidates from the customer service staff or technical writing staff.
- Insisting that testers be able to program.
- A testing team that lacks diversity.
- A physical separation between developers and testers.
- Believing that programmers can’t test their own code.
- Programmers are neither trained nor motivated to test.
The tester at work
- Paying more attention to running tests than to designing them.
- Unreviewed test designs.
- Being too specific about test inputs and procedures.
- Not noticing and exploring “irrelevant” oddities.
- Checking that the product does what it’s supposed to do, but not that it doesn’t do what it isn’t supposed to do.
- Test suites that are understandable only by their owners.
- Testing only through the user-visible interface.
- Poor bug reporting.
- Adding only regression tests when bugs are found.
- Failing to take notes for the next testing effort.
- Attempting to automate all tests.
- Expecting to rerun manual tests.
- Using GUI capture/replay tools to reduce test creation cost.
- Expecting regression tests to find a high proportion of new bugs.
- Embracing code coverage with the devotion that only simple numbers can inspire.
- Removing tests from a regression test suite just because they don’t add coverage.
- Using coverage as a performance goal for testers.
- Abandoning coverage entirely.
Testing Mistakes continued...
From the “find important bugs” standpoint, the first testing effort was superior. It found 100 bugs before release, whereas the second found only 74. But I think you can make a strong case that the second effort is more useful in practical terms. Let me restate the twosituations in terms of what a test manager might say before release:
1. “We have tested subsystem 1 very thoroughly, and we believe we’ve found almost allof the priority 1 bugs. Unfortunately, we don’t know anything about the bugginess ofthe remaining five subsystems.”
2. “We’ve tested all subsystems moderately thoroughly. Subsystem 1 is still very buggy.The other subsystems are about 1/10th as buggy, though we’re sure bugs remain.
”This is, admittedly, an extreme example, but it demonstrates an important point. Theproject manager has a tough decision: would it be better to hold on to the product formore work, or should it be shipped now? Many factors - all rough estimates of possiblefutures - have to be weighed: Will a competitor beat us to release and tie up the market? Will dropping an unfinished feature to make it into a particular magazine’s special “JavaDevelopment Environments” issue cause us to suffer in the review? Will critical customerX be more annoyed by a schedule slip or by a shaky product? Will the product be buggyenough that profits will be eaten up by support costs or, worse, a recall?
The testing team will serve the project manager better if it concentrates first on providingestimates of product bugginess (reducing uncertainty), then on finding more of the bugsthat are estimated to be there. That affects test planning, the topic of the next theme.
It also affects status reporting. Test managers often err by reporting bug data without putting it into context. Without context, project management tends to focus on one graph:
The flattening in the curve of bugs found will be interpreted in the most optimistic possible
way unless you as test manager explain the limitations of the data:
· “Only half the planned testing tasks have been finished, so little is known about half
the areas in the project. There could soon be a big spike in the number of bugs
found.”
· “That’s especially likely because the last two weekly builds have been lightly tested.
“Furthermore, based on previous projects with similar amounts and kinds of testing effort, it’s reasonable to expect at least 45 priority-1 bugs remain undiscovered. Historically, that’s pretty high for a successful product.”
1. “We have tested subsystem 1 very thoroughly, and we believe we’ve found almost allof the priority 1 bugs. Unfortunately, we don’t know anything about the bugginess ofthe remaining five subsystems.”
2. “We’ve tested all subsystems moderately thoroughly. Subsystem 1 is still very buggy.The other subsystems are about 1/10th as buggy, though we’re sure bugs remain.
”This is, admittedly, an extreme example, but it demonstrates an important point. Theproject manager has a tough decision: would it be better to hold on to the product formore work, or should it be shipped now? Many factors - all rough estimates of possiblefutures - have to be weighed: Will a competitor beat us to release and tie up the market? Will dropping an unfinished feature to make it into a particular magazine’s special “JavaDevelopment Environments” issue cause us to suffer in the review? Will critical customerX be more annoyed by a schedule slip or by a shaky product? Will the product be buggyenough that profits will be eaten up by support costs or, worse, a recall?
The testing team will serve the project manager better if it concentrates first on providingestimates of product bugginess (reducing uncertainty), then on finding more of the bugsthat are estimated to be there. That affects test planning, the topic of the next theme.
It also affects status reporting. Test managers often err by reporting bug data without putting it into context. Without context, project management tends to focus on one graph:
The flattening in the curve of bugs found will be interpreted in the most optimistic possible
way unless you as test manager explain the limitations of the data:
· “Only half the planned testing tasks have been finished, so little is known about half
the areas in the project. There could soon be a big spike in the number of bugs
found.”
· “That’s especially likely because the last two weekly builds have been lightly tested.
“Furthermore, based on previous projects with similar amounts and kinds of testing effort, it’s reasonable to expect at least 45 priority-1 bugs remain undiscovered. Historically, that’s pretty high for a successful product.”
Subscribe to:
Posts (Atom)