Validate and Verify

I have been thinking for a long time to write something on interviews. I usually take an interview every week, if not more and most of the times the candidate loses out. More so because the interview process in my company is really comprehensive, 5+ interviews, and being a small company, in terms of number of employees, we really have to ensure that we are not making a bad call. But this is not my motivation behind this post. My real motivation is something else. There are more then few times, when I personally think that the candidate is losing out because he is not really aware on whats expected out of him. He either goes too deep and hence makes more mistakes, or remain too shallow making the interviewer feel that he doesn’t know the subject. This invariably happens because the candidate doesn’t know on what to focus upon. My goal is to give you a clue on where to focus.

My first source of these ten questions are the hundreds of interviews which I have taken over last many years. This source only constitutes a minor portion, the majority of this list has been drawn from the un-ending conversations we had after we interviewed a candidate. As I mentioned above that we usually have 5+ rounds of interviews and after this all the interviewers get together in a room and discuss. During this discussion everyone shares on what he asked and what did he feel about the response. These discussions have been a great ground of learning for me as you hear from at last 5-6 people on their experience with the candidate. So without any further ado, here my top ten questions for a software testing interview.

Q1 - What is ‘Software Testing’. What do you mean by ‘Validation’ and ‘Verification’.
Q2 - Write a program in ‘C’ to reverse a array of characters without using another array as a temporary variable.
Q3 - Write a ‘Test Plan’ for testing ‘Find’ Box of MS-Word.
Q4 - Test an object, say a bottle opener.
Q5 - Write a program to find a ‘Prime Number’.
Q6 - Design a traffic control system for a junction of four roads.
Q7 - What would be the factors which you will consider to decide whether you should fix a bug or defer the bug, late in the product release cycle.
Q8 - You sent a word document to your friend.MS Word crashes when he tries to open it on his machine. Isolate the bug.
Q9 - Explain a defect/bug lifecycle and write a bug report.
Q10 - Why you think, you can be a good tester.

Read More

Large software organizations have the luxury to invest in labs, or test labs to help their test engineer better test a software. These labs could range from a setup having racks and racks of machines of various configs or could be just a big room with 10-20 machines. Having worked in a company (Legato Systems, now EMC) which creates Enterprise Backup Solutions (Legato Networker) I have been fortunate to see a lab which really had these large cupboard sized machines, fiber-optic powered SAN (Storage Area Network), really cool racks which support multiple machines with same keyboard, a display which would slide out and then go vertical. Probably it was done since it was needed. At the same time, out here at Adobe, we usually have a set up where a bunch of standard desktop machines are present running all kinds of operating systems, various locales and so on. Probably the reason we do not have racks is that our users do not have racks. Though I am sure that having racks might be more space efficient but thats for another day.

Some of these labs are powered by Image servers, the ones which can spit a OS image and do a raw-copy on local disk by booting the machine through network, while others may rely on OS installation through shiny disks. At some places, you have a check-in/check-out register for each of the machine, so as you get in you can work on a machine which is available and then as you go, you let go of the machine. I am sure that during your work experience you might have seen a different kind of lab as well. Also, some of you must have spent long nights in one of these labs trying to isolate a bug or just getting done with your part of test coverage. Sometimes these are also fertile grounds of new associations, more so since these are not too crowded, fall in a neutral zone (its neither harry’s office nor sally’s cubicle) and there are always many reasons to ask for help, there would always be something which is not working. Before your mind takes off and before you get nostalgic , let me come back to my intention of writing this post.

My intention here is to try to capture some of the best practices, best methods and general good housekeeping tips to harness most from a test lab. A happy test lab is key to success of test-case-execution and here are some things which you can employ to make your lab happy. These are not in any order but feel free to ask back incase it appears fragmented.

Five Things towards a Happy Test Lab

Read More

As software testers, we have to find faults in our own creations. Even though its lot of fun and a lot more sadistic pleasure to send a RED report every week to management on how buggy our own software is,  we can’t be holding on to  it till eternity. This is more of a problem for software managers like me then what I was few years back, a Test engineer. Somehow it never occurred to me as a Test Engineer that all my RED reports are actually not a good news to my manager and nor to company in general.

So as we like it or not, there is a time when there are very few bugs which deem a fix and we have to ship the product. Once a version is shipped, the whole game reverses. The same shortcomings which looked so much on the face are now ‘Known Issues’ or ‘Cosmetic’ and suddenly the average test engineer Mr. Joe starts to take full ownership, the same feature which he scoffed at since it was sort of developed by someone else is now something which he blessed. Any fault which gets reported later is looked at with suspicion and an explanation is tried then gladly logging them in the ‘Bug Reporting System’. Over time, the whole problem of maths-n-science and of finding logical bugs becomes a OB (Organizational Behavior) and psychology thing. What is now happening is that a tester has started to love his product too much and not able to see faults.

Read More

Even though this industry is looked at by other folks as being infested by geeks and people who prefer to keep long hairs and not worry about being too tidy, who only drink black coffee, are at odds on social gathering and speak in C or Java rather then roman or french, the truth is that this industry indeed has lots of noble men.This is what you would be thinking, if you are a developer.

“………………..Wow. thats like real ego massage. A software tester claiming, or is proclaiming a better word, to be noble. What else could a man do ?. Especially when he is not writing code, or a better way to say would be ‘when he has not written a piece of code ever’………………..”

Read More

Software testing is gradually coming off age and with every new day everyone is starting to realize the importance of having a dedicated testing effort for any software project. In a company like Adobe where I manage small to medium sized test teams, there is now a much greater focus towards testing. Most of the times we have a 1:1 ratio between developer and testers which is very good but still as the project starts to wind and testing team has to test almost all the s/w every day, it starts to get tight and amid this one big question which every tester keeps asking is that

“why the hell developers can’t write a new piece of code without bugs”

which in itself is a very un-reasonable query but a more reasonable one is

“when a developer fixes a bug, why can’t he ensure that there is no side effect.”

Why ? why and more whys ??

Read More

Some days back I went to watch Die Hard 4.0, please notice that its 4.0 and not 4. The movie is about our old cop Bruce and the bad boys who want to destroy the world, in this case they were more interested to demo or show a POC (Proof Of Concept) that given the right funding they can save the world from destruction. They actually did some destruction to drive home the point that destruction is possible.

The movie moves very smoothly with few people getting killed every now and then. Special effects are awesome and good wins over bad, albeit the good (in this case our very own Bruce) also wins over a F16 bomber, in-numerable bullets, n kill attempts, speeding oncoming cars and what not. Read More

I like to travel (Read my travel blogs at www.ghumakkar.com) and mostly I am not alone, infact never. I travel to near-by places which means driving and a little far-away places as well which makes me to buy tickets and to encounter air-ticket reservation systems.

Last week, I got bitten very badly by a bug which was sitting in Air Deccan’s Ticket Reservation System. Before I start the story and give you details (including the PNR nos) I would like to first thank Captain for making air travel possible for common man. Frankly, all my leisure trips have been on budget airlines whether its Air Deccan or Spicejet or someone else. Had Captain not started it, we would still be travelling by train or not travelling at all. Read More

Am I old enough to leave active testing ?
After spending last 10 odd years, testing software for a living, I asked this question to myself:
“Am I old enough to leave active testing ? ” and after a brief moment of indecisive Mr. schizophrenic thought, I told myself that the answer is an emphatic No.

Top 5 reasons to not leave testing
No 1. Testing is still an exciting work more so when you have to go for the details. The much needed involvement is killing and monotonous and gets frustratingly slow and sorts of puts you to the end of your life, only to you a real high in the end, abrubt at time so as to have a grand finale. In this world, one thing you better need all the time is the feeling of being existent. Once you come out from the deep search say isolating a defect, you sort of come out as a victor. The achievement is simply too high to propell you to more such journeys.

( I also write on travel at http://www.ghumakkar.com/) Read More