Testing. How do I begin?

Anita asks, "I am trying to get into software testing..but I never took a course on testing..what would u recommend for a beginner???"

I could sum this up into three parts.

1. Read it.
2. Experience it.
3. Network with it.

Unfortunately testing is not something which might be taught at most schools. I was lucky enough to work as a tester under one of my professors in his team. Even there we were handed out certain notes on day one and asked to read up. There are many good books in the market. Some of the historical sites to refer to would be

Cem Kaner: http://www.kaner.com
James Bach: http://www.satisfice.com

Reading through their articles and publishings+recommendations would introduce one to the world of testing. If you have extra cash on you, attending a seminar/training sessions might be useful (I say might be since I have no on hand experience of attending one of these). I believe what could be taught could be very well learnt by yourself. Another major source (and a free one) is that of blogs. There are many testers blogging out there. One person I religiously follow is Michael Hunter (http://blogs.msdn.com/micahel). Just reading his blog gets you hooked onto testing. So yes, you need to start reading.

But all books aint gonna get you nowhere. Unless you practice it. If your day job does not support testing, make it your night job. If you write code, test it more sincerely. One practice I used to follow was trying to break my friends code for some project while he tries to break mine. Working in pairs could help. Try getting a partner. Not only does it make your code robust during submissions, but it also gets you better grades if you are in school :-)

Look up Mozilla (www.mozilla.org). Participate in the open source community. You could download nightly builds from Mozilla and try to break them. Want to know what a test case or a bug report would look like? You'll get those on Mozilla. Did you know Visual Studio 2005 Betas are being shipped free? Get one of those and try to probe into it. The more inquisitive you are about testing, the more questions you will have. And more the questions, more you will learn. Makes sense?

Sign up as Beta tester. Microsoft has a Beta testing program. Acronys has a Beta testing program. Try to look up some test automation tools. Dig into nunit and the likes.

Lastly, network around. Participate in discussions, write articles, offer suggestions. Not everything you do might turn up being right. But if you aint getting your fingers slapped once in a while, you aint pushing the boundaries far enough. If nothing else write a blog.

Start working on a pet project, test it and upload it to one of the communities. People will download it, run it, and test it for you. Vice-versa! Everytime they report a bug, you know where your testing+coding skills need to be improvised. Pick project ideas off Codeproject, Planetsourcecode or my professors site: http://www.ecs.syr.edu/faculty/fawcett/handouts/Webpages/Projects.htm
Buddy up with someone and build it, break it. Break it to build it. Try to automate your tests. Everytime you wonder how you could get a certain aspect of it done (ex. how to provide test hooks etc.), look up Google, ask people.

And of course, if you land up with a Software Testing job, it just makes life simple.

Reading up, implementing it and asking around is what helped me. There aint a formula to getting started. Just get started with one aspect of testing, it leads to others. How wide you spread your arms depends on your interest.

Quick advice before you venture into any coding. Write a quick Spec. Getting a clear spec is the first step towards being a good tester. Not only will it help you design, it will help you catch bugs before you start coding.

You can be a hero, but do you want to?

Are you in one of those teams where testing starts late in the development cycle? Do your testers and developers work round the clock and spend late nights to finally get code to ship? Do you have those last minute moments of excitement and last minute heroisms?

A friend of mine, also a fellow tester was telling me about a project he had joint late in the development cycle which had a loose infrastructure for testing. How he and his team had to work late hours to ship the product out in time with minimum bugs. After pulling out such a feat successfully he felt like a hero, but also felt burnt out by the end of it.

This made me wonder. Do we really need heroes? Yes, we do. But its the Last-Minute heroes that we could do without.

Testing which starts late int he development cycle gives many bugs which might have been initailly small and simple to get entangled with some complicated ones and blow out of proportion. Now these bugs get difficult to fix. Now if you manage to identify them and fix them, invariably you will come out as a hero. But do you really need this kind of heroism?

Lets look at this from a different perspective. Lets talk about actual bugs. Cockroaches. Roaches to make it short. They can swarm up your place. I have seen this happen to a persons house. They were all over and finally he had to get the place bombed. But this could have been prevented. Getting a good vacuum cleaner, cleaning up the place regularly, using pest sprays when the first tiny roach made its appearance and maintaining hygenic conditions in and around his locality would never have seen them appear. This makes me draw a simple comparison between the vacuum-cleaners to people who bomb the house.

1. Vacuum cleaners are not the ideal thing to watch for entertainment. Its boring to vacuum your house everyday. Watching house-bombers in action is entertaining.
2. Vacuum cleaners come cheap. To get your house bombed would be expensive.
3. Vacuum-Cleaners are not the ultimate solution. Pests do get in even after maintaining a clean environment. But hopefully you wont need to bomb your house as often.
4. Using a vacuum cleaner requires you to do some amount of thought-processing. Where do you start? When do you start etc.
5. Estimating the preventive job vacuum cleaners do can be difficult. You cant count the number of insects killed.

Now lets talk about your software team. On your last project did your developers work in reactive mode? Did you keep sending them back at the last moment to get things up and running? Did you find bugs late in the development cycle? Did you have a loose infrastructure and finally manage to burn your team out?

But what if your team took cheap measures like the vacuum cleaners to do the work beforehand and get bugs fixed before they could get entangled into a big mass of code? Yes, you have these cheap tools at hand:

1. Automated testing tools. Yes, for the ones who are too lazy to get their own automation set up, there are cheap automation tools which would test code for glaringly suspicious constructs.
2. Spec reading. Yup, reading through your spec could help identify ambiguities or spec bugs.
3. Unit testing. Its getting famous!
4. Code reviews. Like I might have mentioned before, I might give up unit testing, but I wont give up code reviews.

All of the above, mainly the last one, look like the most boring things to do. Its definitely not on anyones list of exciting things to do. But code reviews is something all of my team goes through. The fact that it could very well find 70-80% of your bugs makes it high priority!


You see what I am getting to. Most of these techniques would help you avoid those nail biting finishes. They cost much less, are much less exciting and require lot of planning.

Who doesnt want to be a hero? We all do. But I would'nt want to be one where it could be avoided. At least not when it comes to testing software.

Passion Passion Passion!

I have spoken about passion in a few of my posts. When you hire someone, look for passion. I happened to write about passion on my personal blog and thought I might just link it here for some reading.

The link is
http://heartcurry.blogspot.com/2005/05/passion-of-apoorva.html

Come what may, passion is the key!

On The Lighter Side

Testers have a life too. Oh yeah, we pretty much do. Its usually the developer who spends sleepless nights. Dont believe me? I have someone to back me up.

I have been asked what else do I do besides testing stuff. First off, let me tell you that testing is more of a hobby right now. Its something I am passionate about but its not what I am into full-time. Where I presently work, I am not into full time testing. As a matter of fact we work on clinical trials. Work on creating programs which would generate certain statistics for a particular drug being developed. Yes, its very different from the normal software world. Why am I doing it? Just because its something new I am getting to learn. It gives me scope to draw an analogy of the pros and cons of the software/IT world compared to the pharmaceutical world. And it throws light on some different aspects of design and testing.

What else do I do normally? Well, most of the time you could find me behind my laptop. Either its some new thing I am trying out (you can spend a whole day trying to figure out inheritance even after you thought you knew it well - I'll see if I could post some examples later). Sometime I am looking up whats happening on Mozilla. Lately I am trying to look deeper into algorithms and data structures. Make my brain work that little bit more.

Then there is walking/jogging. It sort of depends on my mood. When there is a lot of thought process going on, I prefer long walks. It helps you clear out things in your head and get fresh in no time. Else I'd rather run on the treadmill. You'll probably find me at Bally's every alternate evening.

Cooking. yeah. I enjoy cooking. But I wont go more into that. But the day I open my own chain of cuisine, everyone shall be invited ;-) And then, there is music. I do play the key board but its been years since I touched one!

Why is this post a little off topic? Just to let you know its important to strike a balance. Companies love people who are dedicated and code-slaves but if you are at it for long, sooner or later, you will suffer a burn out. Too much of anything is bad. Good companies always look for well-balanced individuals. Its good to indulge in different things. You never know what links to what. Sometimes when I am walking, a solution to some problem strikes me out of the blue. At this point I do a U-turn and jog back to my laptop. But its change which brings out the solution.

Every person needs fresh air. Whatever profession you may be!

To be a tester, be a developer (just for a bit)

Sometimes to know how green the grass is on your side just walk across the fence.

Lately at work I have been taking up the role of writing code which would actually ship. In other words I am not testing anyones code (except mine). And testing your own code is waaaaay too difficult than I thought it would be. But more on that in another post, some other day.

Here is a story. I checked in the first version of my program and awaited feedback. After waiting a day or so, and checking in another version, I walked up to the tester to check what was up (read: I tested my own code and found some bugs, did you find any more?). It seems she had apparently not looked into much of it. Not a problem.

Few more days pass by and no feedback yet. By then I had started doing what I love doing. Testing my own code and checking in newer versions. The good part of all this was after a few days I had really some robust code which I felt really confident about.

Yet, nothing beats another pair or eyes looking over your work. So by now I started pestering this tester to check my work. Finally I got comments from her which did put me in a state of partial shock. "Please change the way you have spelt CLick to Click." I had serious doubts in my mind. Is this a genuine comment after doing some solid testing or is this a "lets show I am on the job and keep him quiet for a while" kinda testing. Anyways, time went by and I didnt really hear from her. I got busy with some other modules and few days before shipping my favorite tester walks into my room and says she found a problem with my code. Now she did not pin-point the flaw but the code basically built a filter and and then did some analysis on the data which passed through this filter. As per the tester, there was certain data which should pass through the filtering mechanism but it apparently did not pass through mine. I wont get into the details right now, but it was difficult if not impossible to determine what that data was. All we knew is I had say 100 entries and she felt it should have been 101. All this few days before shipping.

Now changing my filter might potentially break the code somewhere else. Complete dilemma! And few seconds of anger for catching a bug so late in the cycle. Countless hours were spent stepping through my code. But somehow I couldnt figure out where I was going wrong.

Finally I walked up to the tester and asked her how she had come up with her numbers. It seems she had built a quick app which would do something similiar to what I was trying to achieve and had cross checked the results. Brilliant! May I have a look at that piece of code please? So I sat with her for a few hours and stepped through the code line by line. Finally we caught a bug in her code. Was I pissed off? No! I was relieved that my code worked fine.

What did I realize from this experience?

• A lot of heart beats are skipped when a bug is found very late in the dev cycle.
• At this stage when the dev. says "I refuse to change my code", he is pretty much justified. Of course this depends on the impact fixing this bug might cause across the application.
• As a tester if I do a bad job, it could thow others into a lot of trouble. A false negative is worst than a positive.
• More things which I will talk about later as the bell tolls.

But yes, being a developer for a wee bit has raised my bar of respect for developers. Specially those who do a good job.

And those who are wondering if I killed that tester, no I didnt. Everyone makes mistakes. Had she applied herself right from the start I would not have been grumpy. Unfortunately I did not see her do that. Every week I have to write a project update to my director. Also, everyone sends in a powerpoint slide to him listing what work they have completed in the week which passed by. My last bulleted point read something like "Did some testing. Found a bug in the code which tests my code." My director is a clever man. He understands the rest. :-D

In the Matrix

Update (4/18): This post does not seem to render well in blogger. You could find a well formatted version here.

If you belong to a testing organization its very difficult for you to do without test matrices. As a matter of fact you would be using test matrices semi-consciously in your day to day life. Managing money, time or girlfriends. You need matrices.

But on a more serious note, test matrices can be used for a variety of things. You could record a consistent set of tests using the test matrices. It can be used as proof of coverage of a certain criteria of tests, to serve as a checklist and refine/improve area in which a defect occurred.

Lets take an example to make things clearer.

Consider some new font sizes, size 75, 80, 85 and 90 which have been included as a standard in your Word application. You need to test whether they work well with your Word application across different platforms of Windows.

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75
Font size = 80
Font size = 85
Font size = 90

Figure 1

What have we achieved here? We have set up two axis. The Y-axis contains font size and X-axis the OS. So we can put down the first step as determining the axis variables and putting them in such a form where you have minimum one test per row and one test per column. The test performed is recorded as the intersection of row and column. Once the test is performed, you could lodge the result as a pass or a fail.

You could use other notations in your test matrix too. P=Pass, or N=Note, or F=Fail etc. A test could pass but you would like to add a note to it. Very possible.

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75	PASS
Font size = 80		PASS	PASS
Font size = 85			PASS
Font size = 90		PASS

Figure 2

Some points to note from the above:

Highlighting gives us a better idea of test coverage.
Complete testing of a huge matrix is not feasible. The matrix would give us a good idea of test coverage for key areas.

You could apply your mind in different ways to eliminate or identify problems.

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75
Font size = 80	FAIL
Font size = 85		PASS	PASS
Font size = 90

Figure 3

From Figure 3, we could conclude that there might be a bug with Windows 2000, there might be a bug with font size 80, both of the previous or there could be a bug when you try font size 80 on Windows 2000.

Lets test on the same axes as the failure and we would be able to make a much better guess to the problem. We perform two more tests.

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75
Font size = 80	FAIL	PASS
Font size = 85	FAIL	PASS	PASS
Font size = 90

Figure 4

Ah! Now we know the problem is platform specific.

What if the matrix read:

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75
Font size = 80	FAIL	PASS
Font size = 85	PASS	PASS	PASS
Font size = 90

Figure 5

Figure 5 will help us conclude that the problem is specific to Windows 2000 and font size 80.

One more matrix which could come about would be:

	Windows 2000	Windows XP Pro	Windows XP SP2
Font size = 75
Font size = 80	FAIL	FAIL
Font size = 85	PASS	PASS	PASS
Font size = 90

Figure 6

Figure 6 shows a font specific bug.

So on, test matrices can be used for any pair of criteria's. Sometimes, a bug might be found which might not be listed under any criteria in the test matrix. The matrix can easily be expanded to include this criteria. Another advantage I see of test matrices might be the fact that if a defect is found after release, one can always go back to the matrix and look for areas not tested or areas which were tested and still had a bug (this could be poor testing).

U + I = UI

I recently had to change my cell phone service provider. I would never have left Verizon (still claim they are the best) but somehow their service around my home sucks! So I mentally prepared myself for a phone. No digging deep into my pockets for a device which will play mp3's, allow me to IM, serve as a camera + video camera, have some colored tooth, internet browsing, windows media player etc. which also serves as a phone. Bottomline - control the geek in me..... and of course, spend minimum.

I ended up buying the Sony Ericsson Z-500a.

Now I am sitting home looking at this phone comparing it to my LG VX6000. OK, for its price and features, the phone aint bad at all. It lacks the the classy look of the LG. But the bad part is some of its design features.

Lets take this a little further. On your cell phone, you get into "Menu" and then hit "Contacts". Mostly you will have a list which will read as - "List Contacts", "New Number", "New E-mail", etc. Gee, now you realise that this aint what you were looking for. You were looking for the camera feature of this phone.

Next logical step: Hit Clear or CLR or "C" (as seen in most of the phones).

The user model of the clear button or anything which says "C" is you either go back to the previous screen or just clear out to your main screen. Oh well, thats how it has been with my LG and the phone we have back in India.

Back to the Z-500a. Hit the key "C" and the screen just stares at you. Hit it again and still no effect. Now look closely at this picture.

The Z-500a




There are 4 round buttons. The round button the green arrow points to is "C" or clear/cancel (whatever you wanna call it). The red arrow points to a button which had a u-turn shaped arrow on it. I figure this means "Back". So here is the key. Hitting "C" will not clear the screen or rollback. There is a special key to take care of this functionality. So whats the "Clear" key for? When you type in text and if you type texy instead of text and wanna clear the "y", you use clear.

Well, as a concept, its pretty clear. But for someone used to the "Clear" key taking care of everything, its frustrating. You hit the "C" key and wait. Then you hit it again and wait. You think something is wrong with the key. Finally you realise you have been hitting the wrong key. Is the UI bad? No. Its not. So that means the LG UI was bad? No, that was not bad either.

Eh? Am I actually going to learn anything from this post then?

Lets go back to what we are good at. Computers. Operating Systems. The Mac and Windows. Imagine if in the Mac, if you have to move a window, you can grab it by any edge and move it. In Windows, you need to move it using the title bar. For a Windows user working on the Mac, a task of resizing the window will result in moving the window. Very very frustrating. And you say the Mac is known for a poor UI? Of course not. Anything which comes out of the Apple store is known for its pretty face. The world claims the Mac to be pretty and Windows to be loaded with features. But thats a story for another time. The point here is ease of use.

Hmmmm... now we are getting somewhere. I might actually learn something out fo this.

In UI design, you have to see two aspects. User model and Program Model. You have to match the user model.



If your Program Behaves the Way users thought it would, then you have a well designed UI.




The mac OS works perfectly fine.... for Mac users.

The UI design has to be made keeping U and I in mind. You, I and the others. Usually ten of us.


Oh, by the way, the Z-500a does have a camera, video recorder, IM, web browsing, speaker phone, media, etc. And only worth $50. Not bad eh? Of course, I dont know if I am going to stick to it... that "C" key is very frustrating indeed.

I help, You Help. You Help, I Help!

Till now I have been rambling about how it is important to have a good customer focus and how its really important to nail down the specs. Get something wrong and suddenly you are the target of a lot of customer ire. Ship a product with a glaring bug and find yourself losing a big chunk of your market share. But how much ever perfect one would try to be, a product will be shipped with bugs.

Today let me talk about how you, as a customer could help in making a better software.

Report bugs. Its simple.

Lets take Visual Studio as an example. A very well made software (yes, I know there are bugs, but looking at the complexity of the system - I think some bugs are expected). But here is how you can help. When you are working happily along and a terrible crash occurs, a much dreaded dialogue comes up which says something like -
“Microsoft Development Environment has encountered a problem and needs to close.”

And then a little farther down it says…

“Please tell Microsoft about this problem.

We have created an error report that you can send to help us improve Microsoft Development Environment. We will treat this report as confidential and anonymous.

To see what data this error report contains, click here.”

Then you see three buttons: Debug, Send Error Report, and Don’t Send.

Now this is where as a customer/user you could help. After all you are using the product. So why not make it better? Finally its for your benefit!

The above mentioned is known as Watson. When you hit the "Send Error Report" a minidump is sent to the server at Microsoft.

Why am I saying all this? Because I have seen people hit - "Dont Send". I know co-workers (where I work as of 20 March 2005) who spend a long chunk of their day on MS Word and have many crashes. When the Watson Dialogue pops up, they just say "Damn Word" and hit the dont send.

Unfortunately not many people know about Watson. I am sure if they knew what happens behind the scenes they would hit the "Send" button. Altho nothing can be as clear as - "Please tell Microsoft about this problem." But the user is anyways pissed off with Microsoft since what he was working on crashed (consider this user to be someone not highly adept in computers). Now when he finds another screen saying "report the problem" - irritated users says "NO". Dont ask me why - but I have seen this mentality.

Similiar with the Google pop-up blocker. Google suggests that if some pop-up manages to pass through the blocker, to report it. What page you found the pop-up on and properties. Now, how many of us would actually report that? Very few! How many would say "Damn this pop-up blocker!!!" whenever a pop-up appears? I see all hands go up.

This is a two way process. Software teams can only provide you a certain level of security. Testers try to advocate for every end user. But unfortunately thats not possible. The end user has to help the tester too. I can help you only if you can help yourself. The next time - do yourself a favor and hit that "Send Error report" button. After that you have the full right of saying - "Damn ".

The First Tiny Steps

A reader left a comment on Michael Hunters blog asking how one could develope into a SDET (Software Design Engineer/Test) when his day job does not have much scope for automation. Michael provides him a simple answer which says to make it his night job. heh!

Reading this makes me relate to a few days back when we were preparing the final validation documents for submission. Unfortunately I cant go into details till our press release but I'll talk about something very similiar.

As a new employee 2 months ago I did notice that no one is really a big fan of automation. Some places do not need automation but some places could do with automation. Unfortunately I had not been able to convince my manager to automate a few things I felt should be automated. But that didnt stop me from thinking up other ways to get his attention towards automation.

When we are making our daily runs/builds

• All programs lie in the PROGRAM folder.
• All Logs (of corresponding programs) lie in the LOG folder
• The outputs of the programs lie in the OUTPUT folder.
  
  

Fortunatly when we laid out the specs, we put forward a naming convention for the three. An example would be, for an output the corresponding programs and logs will be:
Program : ABCD 1.2.3.sas
Output : Table 1.2.3.doc
Log : ABCD 1.2.3.log

The final stages of our submissions process is something like this:
A folder is created for every set of program, output and log. This folder will be named the same as the output file, taking off the extension .doc. So our validation folder would carry another folder with the name Table 1.2.3 and this folder will contain the above three files along with other documentation.

Now the poor programmers (myself included) who wrote the programs are the ones responsible for making this folder with the above documents. So if you walk into a programmers office when he is creating this structure, this is generally what you find on his screen. Four windows of Windows Explorer open, having the program, log, output and validation folder. Then he searches through the list of programs and identifies the one he wants, copies it into the validation folder. Ditto for log and output. Then he realises he has to do that for another 80 more programs/logs/outputs... turns around, takes out his revolver and shoots you in frustration! After he is done with all the 80 folders someone comes and tells him they had got the numbering wrong and all the numbers need to be changed. He shoots himself.

So to stop myself and others from being killed, I came up with a small (but effective solution). Automate this process. Usually we work off SAS. Doing this through SAS might have taken a little more time (which no one had) but like Michael suggested, I made it my night job. A simple application in C# would not take more than a few minutes to bring about the desired automation.

The next morning I did a small demo before my manager. He was happy. 3 hours of work had come down to 3 seconds. The programmers were happy. Everyone was happy. But most important - automation had taken its first tiny step. Suddenly I had people come up to me and say - "Hey, can this be automated too?" - "If we can write a generic program for this, it can save us a lot of time" etc. I find myself much more busy, but much more satisfied! The programmers are smiling. They finally got to go home early! A very small 20 line program can change the way everyone looks at automation today.

So when your workplace does not really support automation - look around. Definitely there is something which could be automated. There always is. Even the smallest thing. Once it gets noticed, there is no looking back.

On a different note - most people in the pharmaceutical industry might not know much about C# but to my surprise not a single person at work had heard about it! My manager just walked in today and wondered about this other issue and if it could be solved better with C#. For everyone at work, C# = Magic! ;-)

The Microsoft Interview - Revolutions

Interview 4:
I called up Ian after an hour and let him know I was down in the lobby. In a couple of minutes I found myself in his office. He said he was training someone on interviewing and wondered if it was OK with me to have him watch. No problemo! So now there were 3 of us. Ian started off with, "Lets write some code." Yay!! I was asked to write a program which was similiar to a mergesort. After writing it, I was asked to test it. While testing it, I was told to correct any errors I found. Writing code on a whiteboard is a whole new experience.

Advice 13: Practice writing code on paper or a whiteboard before your interview.

After finishing off with the above, I asked Ian how he would recommend testing some code like the one I had written. This led to a very interesting conversation where Ian walked me through a step by step process on how one would ideally test code and why certain things were done in certain ways etc. After this I was asked to test a program which would check for 2 rectangles overlapping. But I had to apply everything which Ian had taught me over the last 15 mins. Had I not paid good attention to what he was saying, I would have been in a fix! :-) I felt I did really well here.

We spoke general stuff about testing etc. and then Ian briefed me on how it would be to work at MS. If I was chosen for the group I was interviewing for, what my responsibilities would be, etc. By this time I started thinking I was almost hired which brings me to:

Advice 14: Read Advice 10 of Part 2.


Ian walked me to the lobby and asked me to wait for my next interviewer - Mike.

Interview 5:
Mike also happened to be a Test Manager and my last interview of the day. By this time I was close to being called a Zombie! I could have done with an energy bar which I had not carried. We started off initailly by talking about SDLC and the role of test. Then I was given a "simpler" puzzle and then a difficult one. I got the difficult one rather easily but took time on the simpler one. Heh! At this point Mike said he liked my thought process. Yes, yes, I was on Cloud No. 9. Then he got into the team player mode.

Mike: "I am a fellow tester who hates being disturbed or working as a team. As a matter of fact, the whole team might hate me, I dont care. You need information about a certain part of the project on which I am working. You might need my opinion, you might need my code. How will you approach me?"

My first thoughts were why hire such a person...? But I let those remain as thoughts. After talking generally about team relationships, my reply was a direct approach of walking to the person with a friendly hello, letting him know about the situation I was in and saying it would really help in taking this product dev/test process ahead if he could provide me with his invaluable guidance.

Mike: "Doesnt work for me. Leave me alone, get out of my room."

I assumed it was the fellow testers response and told him about various other approaches I might try. I got the same response to all of them.

Mike made me go through several such excercises and when I look back on them, I messed up in several of those. Some of my answers were actually "pathetic".

Finally Mike picked up his laptop, and asked me to test a certain feature on it. Apparently his desk was all filled with paperwork + desktops so I decided to keep the laptop on my lap (oh, now I know why they named it that!!). But Mike pulled up 2 cardboard boxes, put one on top of the other and said I should use them to place the laptop! After a while I was paying less attention to testing the feature and more attention to balancing the laptop on those boxes!

We finally spoke about trustworthy computing and some other areas where MS plans to grow. I was finally told the positions I was interviewing for. As Mike walked me to the lobby he asked if I planned to get a PhD. He said Building 19 was just across the street and I could walk it up. As I dragged a tired me across the street on a cold January evening, I knew deep inside that I had messed up the last interview. Only if Mike considered balancing his laptop a brilliant act, I might get this job.

Advice 15: Learn to balance laptops! Just kidding! But seriously, towards the end of the day, you will feel dead tired. But these interviews are probably the most important ones (what people call - as appropriate). Just think its now or never and give yourself one last push!

If you love writing code, solving puzzles etc. you wont be mentally drained out. As a matter of fact, even after 5 interviews I felt all pumped up. But my throat was killing me with all the chit-chatting I had done!

Amanda called me on the day she promised she would. "You came very close, it was a tough decision, but the groups you interviewed with have decided not to make you an offer." Oh well, it was a good excuse to go out drinking and drown your sorrows. A week later, Amanda calls while I am in the bus. Hmmm... maybe they made a mistake, maybe I actually got the job! "You came very close, it was a tough decision, but the groups you interviewed with have decided not to make you an offer." Errr... Amanda, you told me that last week. "oh I did, so sorry, I didnt note it down that I made the call. your file is still lying on my desk." Are you sure nothings changed in that file? We both laughed! Its okay... the bus stops right in front of the liquor store!

Advice 16: Know where the liquor store is.