Saayan's Blog

Based on user feedback, 5 new commands are added to QAuto:
CopyFile(param1,param2)
BackupFile(param1)
RestoreFile(param1)
DeleteFile(param1)
Comment(whatever string)

For regression testing, you need to be stateless - that is if you add new input files, the test running for other tests may be affected.

So, these above functions will be useful.

When you record a new test (say ABCD), then a folder called _AuxFiles_ABCD is automatically created in the same level as the test ABCD (where you store the QAuto test cases).

If you put a file called MyFile in this folder (_AuxFiles_ABCD) and you manually add a line CopyFile(MyFile,C:\Somewhere\blah\MyFile) in the script window - then, when this line is executed the file will be copied to the C:\Somewhere\blah\MyFile. Remember no spaces around the comma or after or before the brackets.

QAuto will automatically make a backup of existing file C:\Somewhere\blah\MyFile before overwriting.
Also, QAuto will automatically restore this backup when the script is complete. If there was no existing file there (at the time of copy), then it will delete this file.

BackupFile(C:\Somewhere\blah\MyFile) will create a backup of this file. And when the test run is complete, it will restore automatically from this file. This helps when your test cases modify existing files and you want to restore them.

RestoreFile(C:\Somewhere\blah\MyFile) - is the explicit restore command. You can use it in conjunction with CopyFile and BackupFile - but it is not really necessary. QAuto does this automatically.

DeleteFile(C:\Somewhere\blah\MyFile) - will delete this file. It is useful if your test cases create new files and you want to restore system back to original state for the next test.

Comment(my comment blah blah) - will add this comment in the results. It is useful if you want to add own comment or say where the snapshot is stored, etc.

I am glad to announce the release of the prototype for QAuto - the Windows GUI Functional Testing Tool. This only works on Microsoft Windows.

Tested on XP. But you can try on Vista. Also, you need to have MFC dlls already installed on your machine.

It is platform / language independent. What does it mean? It means - it does not matter if you are testing desktop application or web application or Java app or .NET app; or what language was used to write the app - C++, VB, Java, C# etc.

What is its biggest drawback? It has one - it works with windows raw co-ordinates. That means, if your window has changed position - your test would fail. Language and platform independence comes at a price.

How does it work? It works with low level mouse and keyboard input recording and playback. It generates a human readable script that you can tweak around to insert Wait and Snapshot commands.

Why did I develop it? I wanted a simple and fast GUI functional testing tool to test the desktop software products that we develop for our client. There are very good tools out there - but they are expensive and what is more important is that we use custom Windows and the off-the-shelf tools do not work very well with those. To get them to work, we would need highly experienced testers who would be able to customize and write test scripts.

QAuto is very simple to use. It records and plays back keyboard and mouse events. The premise is - if it cannot play back - the test has failed. You can also take snapshots of the entire desktop to manually verify if the UI shows what you expected. At some point we can put in a pixel matching functionality - but that is for later. This is only a prototype.

A small note on how QAuto can be used for regression testing by developers. The process is simple. Developers can share a common LAN area where all test cases are stored. Developers have their own copy of QAuto. When they fix bugs or develop some functionality, they can enter (means, record) a corresponding test case in QAuto. So, the number of test cases keeps growing. The developer then executes (plays back) the n+1 test cases in QAuto with a single mouse click to do regression testing before committing code in source control. QAuto is very fast - the playback can finish in seconds whereas the recording could have taken minutes. Simple and highly effective. In the presence of a test team, the test lead can manage (add/edit/delete) the test cases.

Need to know more? Ask me.

You can download it here - but be warned, it is a prototype and there is no help file. So, please follow these basic steps:

Please Note - If you do not have MFC dlls on your machine - then you can download the full installer here.

Preliminary steps

1. Download and install it. Or, download the full installer with MFC dlls here.
2. Run it.
3. Click on ‘Options’ button and set the Test Case and the Results folders.

How to record?

1. Run QAuto.
2. Click on ‘Record’ button. Select a suitable test and description. Click OK to start recording.
3. Whatever actions (mouse and keyboard) you do now on your entire screen will be recorded.
4. Hit the Pause/Break key on your keyboard to stop recording.
5. Your test case will be stored and you can see it by expanding the test cases tree.
6. You can see the recorded script by double clicking on the test name in the test cases tree.

How to playback?

1. Run QAuto.
2. Select a test on the test cases tree on the right pane and click ‘Playback’
3. When playback is going on - do NOT touch your keyboard and mouse.
4. When the playback is over, you can see whether test passed or failed. The result will also be stored in your results folder (that you have already set using the options button).
5. Note that you can run full suite of tests by clicking on a test case node (rather than an individual test case). In that case, QAuto will run all test cases under that node and under the sub nodes. How do you get a node? You have to manually create a sub folder under your master test cases folder (that you set using the Options). Test cases can go under that folder and you can see this reflected in the tree.
When you Record a test case, you can select a sub node and that will store the test case under that sub node. You can also manually move files around in your hard disk and that will be reflected by QAuto when you click the “Refresh Test Cases” button or you restart QAuto.

Other stuff

1. Often, you need to introduce Wait manually in your recorded script. That is because QAuto plays back very fast. So fast, that the system does not get time often to bring up a window (when QAuto expects it). That causes the test to fail and that is spurious. So, you need to use the Wait command in your script.
In a line by itself type in Wait(1000) to make QAuto pause for 1 sec. The Wait command takes in a number denoting the milliseconds to wait.

2. Also, you need to take a snapshot of the screen (screen capture) at specific points of QAuto run. This is so that you can manually verify window contents so that you can tick off tests as passed. How to do that? Use the Snapshot command. Snapshot command takes a name (no extension). For example:
Snapshot(abcd) will take a screen capture (entire windows desktop) and store as abcd.png image file.
Insert Snapshot commands at the points you wish to capture screenshots.

3. How long will QAuto wait for window to appear before prompting you to abort / retry test? This is set using the Waiting Time value in the Options. You can set a value from 0 to 10. A value of 0 means that QAuto will prompt immediately if it cannot detect an expected window when playing back. However, it is prudent to set a value of 3 or more for Waiting Time.

4. This is a bit advanced. Click on Options button to bring up the Options window. You will see a Sync Fine Tune slider. When QAuto plays back mouse and keyboard events, sometimes the windows for which it is meant - does not receive it. This is because of playback speed. However, you can make the event insertions in the system slower by increasing the Sync Fine Tune value. The higher the value - more accurately the playback will happen (and correspondingly slower). This varies from system to system - so I have put it as an option.

My own top 9 list of resources on the web for C++. Why top 9 and not top 10? I am just tired of ‘top 10′ s.

In no particular order:

C++ Language Tutorial

  The basics.

C++ FAQ Lite

  Interesting FAQ. You can get answers to most of your interview questions here

Bjarne Stroustrup’s C++ Page

  The father of C++. ‘Nuf said.

Herb Sutter’s Guru of the Week

  I had to scratch my head even after reading the explanations. This GOTW is the foundation of Herb Sutter’s C++ books.

Codeguru

  Community site. Useful.

Codeproject

  Another good community site.

Bruce Eckel’s Thinking in C++ - Free Download!

  Free download! No, it is not pirated - although, plagiarism these days is the highest art form.

64 bit programming with Visual C++

  Ahem, not core C++. But then, 64 bit architecture is OS specific. This one is from Microsoft. And click here for general 64 bit Windows programming discussion from Microsoft.

Backyard Hotrodding C++

  For the truly wild. For example, how do you counterfeit the this pointer. How very wild, how very interesting.

Finally!

JobCanvas.com is here. A jobsite that is simple, fast and effective. I am glad to see it go live.

It is an exclusive portal for Kolkata jobs.

Will write on the making of JobCanvas sometime soon.

Enough of analysis. Let’s attack this task-wise. What we will finally have, is a blueprint for successful outsourcing. For the sake of clarity, I am considering a single outsourced resource working on a client’s project. This is scalable.

The Players

Players on the Client side

The Handler - who is basically a proxy for the remote developer. The Handler is also the single point of contact for the Developer.

Players on the Vendor side

The Developer - the person doing the real work.

The Project Manager - managing the outsourced project from the vendor’s side.

Vendor’s local presence at the Client location - suggested, but seldom possible.

The Opening

A game well begun is a game half won.

Who are involved in the first requirements gathering phase?

All the players - the Handler, the Project Manager, the Developer.

Who will write the requirements document?

If the Client has an existing requirements document, it serves the purpose. Else, the Project Manager plus the Developer from the Vendor’s side have to do it.

Either way, the Vendor has to produce their own interpretation of the requirements and have it signed off by the Client. This is a separate document, if the Client already had a requirements spec. If the Client has to prepare the requirements doc, this can be it.

Who will prepare the project delivery schedule?

The Project Manager on the Vendor side, in consultation with the Developer. The delivery schedule has to be signed off / approved by the Client.

The Middle Game

Consolidating on the momentum.

Who will manage the Developer?

The Developer is managed by the Vendor, as a normal employee. No attempt is made by the Client to micro manage.

Who can access the Developer?

The Handler - directly, without any level of indirection in between.

How about the accountability of the Developer?

Weekly updates from the Developer to the Handler on the client side.

Weekly updates from the Developers to the Project Manager on the Vendor side.

How to measure the progress of the project?

The Project Manager should provide interim builds. The Handler should do a sanity check on the build and keep an eye on the progress.

How to escalate issues that are not solvable by the Developer?

The Handler should escalate issues to the Project Manager.

Defense - How to protect against potential Checkmates

Ah, the joys of fending off a ruthless enemy attack.

How to handle requirements changes?

First, change the original requirements doc.

Second, if required, the Vendor prepares the Vendor’s perception document to reflect this change.

Third, get the Vendor’s perception approved by the client.

Fourth, change the project delivery time line accordingly and get it approved by the Client.

What happens if the Developer leaves the Vendor for greener pastures?

The Client fills in from the redundant developer pool. This certainly has an impact on the project schedule. Who pays for the time impact depends on the understanding / agreement between the Vendor and the Client.

What happens if the Handler leaves the Client?

Bad luck. Some one has to fill in the shoes. But this will not have as big as an impact as a Developer leaving the project.

What happens if the Project Manager leaves?

The Vendor has to put in a substitute. Again, the impact is that serious. The key is the Developer.

The End Game

The final touch.

Who will manage the final delivery?

All - the Handler, the Project Manager and the Developer.

How to do post delivery support?

Think of it as a part of the whole project. The Client should engage the Developers in the same way as a normal project. This includes post delivery bug fixes.

Who does the testing?

The Client should do the testing.

There should be a test plan. If the Client already has a test plan, it should share this information with the Vendor. If it does not, then it should either prepare one, or have the Vendor do it.

With a test plan, the Vendor can ensure that the deliverable is meeting the expectations.

Nasty Question

What to do if the Client is not happy with the work?

Such a case should not arise if there are periodic deliveries. In the worst case, the Vendor has to bite the bullet.

This concludes my rambling. Comments are welcome.

The issues with outsourcing for small companies were outlined in Part I. Now, we shall explore the tactics and strategies to solve each of these. Not all is doom and gloom.

The Issues for the Client

Let’s sort out the client’s issues:

1. Process

Process will be a derivative. More on process in Part III.

2. Structure

Bare minimum structure. There is a handler on the client’s side. One to many relationship. Means, for each outsourced developer, there has to be one handler. And one handler can handle / manage multiple outsourced developers. One developer should have one and only one handler on the client’s side - this is to avoid confusion.

The handler is responsible for the following:

(a) Checking on the progress of the developer.

(b) Taking delivery of the interim releases and the final release from the developer.

(c) Answering questions that arise from the developer side in a timely manner. No delay tactics.

(d) Fundamentally, taking ownership of the developer’s work from the client side.

3. Cost

Since maintaining redundancy is a luxury for the client, the responsibility falls on the vendor. More on this later from the vendor’s perspective.

4. Cohesion

The handler in the client’s side is responsible for maintaining cohesion in the team. The handler should make the developer transparent to the team. The handler is the proxy for the developer.

Again, the load on the handler can be significantly reduced by a local presence from the vendor’s side. More on this in the vendor section. However, in the absence of such a local presence, the handler substitutes for the developer.

5. People Management

The client should not attempt at managing the remote resource. All the client should worry about is the progress of work and the final delivery.

6. Requirements Management

Software requirements change - and they change a lot. This is the truth. Any attempt to seal requirements in a bottle has failed. So, what to do?

My suggestion:

Step 1 > The client communicates the requirements to the vendor by email or phone or both. If there is no formal specification, do not despair. In this scheme, the vendor will prepare the specs, if not there. Who sends the requirements on the client side? The handler in consultation with business analysts or architects. Who receives the information on the vendor side? The project manager. Who is the project manager? See the vendor section.

Step 2> Let the vendor come up with their interpretation. The vendor writes it in a document - does not have to be IEEE standard formal document. Only the core needs to be there.

Step 3> The client the vendor’s version - making sure they understand the basic requirements. It is impossible to understand 100% of the requirements. So, the client needs to be sure that the vendor is on the same wavelength.

Step 4> Once the client is satisfied, let the vendor start work on the project.

Step 5> The client takes interim builds and checks on the progress. The client should not wait to be surprised at the end.

Step 6> Requirements may and will change. The client should communicate the change to the vendor, and let the vendor express the change in their own language. The client should check the vendor’s interpretation and be satisfied. The client should ask for the impact on the delivery time line. Finally, the client should discuss the time line, confirm acceptance and get going with the project.

7. Out of Sight, Out of Mind

The client should have regular updates from the remote developer - get him / her to send weekly progress reports. Organize a weekly meeting, even if for a few minutes. Let the meeting be on an instant messenger or on phone - both are fine. The client should always know what the developer is doing. It is important to know where the developer is at the moment, but it is more important to know in which direction the work is moving. This weekly meetings should be organized by the handler at the client’s side. The weekly reports should also be checked by the handler.

8. Communication

The handler should communicate directly with the remote developer. No passing the parcel game. If there are issues that cannot be resolved, the handler should escalate these to the project manager on the vendor side. All direct communication with the developer should be cc to the vendor project manager. Who is the project manager on the vendor side? Please read the vendor section.

9. Post Delivery Support

Undoubtedly, the client will need post delivery support. So, instead of being coy about it, the client should put it in the equation at the very beginning and continue to maintain the outsourced resource beyond the project delivery. Until, the client makes its own official release. And may be, even after that, depending on what support is required.

10. Quality

The client should get the delivered work tested in its own testing environment. If the client has a test plan for the work that the vendor is doing, it should send the test plan to the vendor. The vendor will check their work and will significantly reduce the client’s testing load.

The client should never do adhoc testing. If the client does not have the time or the inclination to prepare a test plan, it should get the vendor to do it - but do not test without a proper test plan.

11. Dispute Resolution

This unfortunate situation should not arise if the client has taken interim builds from the vendor. No nasty surprises there. However, if the client is still unsatisfied, it should communicate the distress to the vendor. No one wants to lose a client - the vendor will try to accommodate the client.

The Issues for the Vendor

Now, let’s solve the issues for the vendor:

1. Process

The tactics we determine in this part will dictate the process in Part III.

2. Structure

The vendor should maintain its own structure. The client’s command and control is superimposed on this. But from the vendor’s view, the normal reporting and accountability is maintained. Access is granted to the client via the handler in the client’s side. Little extra work for the developer, but worth it.

The vendor should have a project manager internally. Every client project should be controlled by a project manager - one and only one project manager. The project manager is responsible for the following:

(a) Initial requirements gathering and signing off with the client.

(b) Ongoing requirements change management.

(c) Resolving client handler <-> developer issues that are escalated.

(d) Keeping an eye on the overall progress of the project.

(e) Periodic (weekly) checks with the developer regarding the project status.

(f) Any other outstanding issues related to the project.

If the vendor can afford, it should also consider maintaining a local presence at the client office. That person can solve issues on the spot. This is strongly suggested.

3. Cost

Attrition is a fact. So, redundant resources need to be maintained. But small client companies cannot maintain resources at per project basis. What to do?

My suggestion is - the client keeps redundant resources for its overall resource strength. Not, per project basis. So, if the client has a developer workforce of say 20, he can maintain 20% redundancy at all times with 4 developers on standby. The redundant resources should be very familiar with in house technologies and have workable knowledge of client projects in execution. The fill-in and ramp up can be very fast.

4. People Management

The vendor’s reporting structure remains as-it-is. Additional load for the developer is reporting periodically (preferably weekly) to the client handler. This overhead is bare minimum and a must.

In addition, the developer reports to the internal project manager (who is assigned to the project).

5. Requirements Management

Requirements and change management are controlled by the internal project manager.

6. Communication

The developer communicates directly with the handler on the client side. Any issues that are not resolved at this level are escalated to the project manager.

If the vendor has a local presence at the client office, on the spot trouble shooting can be done.

7. Post Delivery Support

Post delivery support should be considered as a part of the overall project. The question of separate billing should not arise.

However, if the client wishes to scale down the number of developers after the delivery, then a separate maintenance contract needs to be executed. The formula remains the same - one or more developers are assigned and managed in the way we have seen earlier.

8. Dispute Resolution

Interim releases, checkpoints and weekly project status meetings are the key to avoid disputes. In the unlikely event that a dispute does arise, the vendor should take steps, however unpalatable, to ensure that the client is truly satisfied.

In Part III we shall view the whole process in task form.

Much has been said for and against outsourcing software development. And yes, many models of outsourcing have been championed. In this 3 part series, I will explore my own software outsourcing model that I think works for small companies.

Assumption - the company that is outsourcing is small; the company that is being outsourced to is also small.

“Small” is a relative term. In the Indian context, small can mean a company with 50 employees. In the Australian context, “small” can mean a 5 employee or less company. It depends. By the way, I like the term “it depends” - a lovely expression to keep things open ended without committing to anything and sounding very wise at the same time. But, I digress.

In the first part of this 3 part series, I shall attempt to identify the problems faced by small companies that want to outsource. These are not only issues, but also contradictions.

The Issues for the Client

The client is the company that wishes to outsource software development. From the client’s angle, there are a few issues:

1. Process

Small companies do not have the luxury of following a sophisticated process - for example, CMM. But without some rudimentary process, this is bound to fail.

2. Structure

Not enough people and resources to establish a delivery structure. Yet, there has to a framework for delivery. And this is talking from delivery acceptance angle. Without structure, communication breaks down.

3. Cost

Not enough spare cash to throw around. If a 10 person company is outsourcing the work of 1 headcount, it is outsourcing 10% of the work. For a headcount of 2, it is 20%. Each outsourced headcount need to save cost for the company. Cannot maintain redundant resources. This causes a significant tactical issue in case the developer assigned by the vendor company decides to leave the project. More on this later.

4. Cohesion

The hallmark of a good software design is high cohesion. What is cohesion? - verbatim from webster - the act or state of sticking together tightly. Cohesion is important for projects as well. Small companies naturally have small project teams. Typical size is about 3 or 4 people per project. If you outsource 1 person’s work from a team of 3 people, you are breaking the cohesion by 33.33%. That number does not feel good.

5. People Management

Remote management of software developers is a sure recipe for disaster. But then, if a company is outsourcing 1 person’s work, how is it going to manage that 1 person? That 1 person is a part of a 3 or 4 people team. And that team’s manager need to manage this 1 person remotely. How do you do this?

6. Requirements Management

How do you specify your requirements? Do you write down every nut and bolt in a beautiful colorful document and send it across to your remote developer - and presto, he / she produces exactly what you want? Wake up - this is utopia - has never happened and will never happen.

And, how do you do change management? Your customer may feedback on a prior release saying that there should be a search box in the top-right corner. Fine, it is just a box, right? Wrong. This box is Pandora’s box. Anyway, how do you change that lovely screen-shot in your first requirement specification and let your remote developer know that he has to implement a search box (and the search functionality of course). Small monkeys indeed have quite long tails.

7. Out of Sight, Out of Mind

It means - when the remote developer is out of sight (which is the case here), then the client company is out of its mind. People get very uncomfortable by what they cannot see. Here is a small company that values every single dollar - paying a few thousand dollars a month for a person whom they cannot see. Not really a warm fuzzy feeling, is it?

8. Communication

How do you communicate to your remote developer? Directly? Or through a point of contact in the vendor company? This opens a can of worms - like how do you handle coding emergencies - like, lord in heaven forbid, the remote developer’s submitted code has broken your build? Do you call this guy 10,000 kms away or you send him an email? What do you do?

9. Post Delivery Support

Will the vendor jump ship after delivery? How to ensure post delivery support? What are the cost implications? How does the client make the vendor accountable after the delivery?

10. Quality

How to ensure quality of the delivered product? What to do if the delivered work does not meet expectations?

11. Dispute Resolution

What to do if the vendor’s work does not match requirements? How to resolve this without having a severe impact on the overall project?

The Issues for the Vendor

The vendor is the company that is providing outsourcing services. The issues from the vendor’s angle:

1. Process

Clients will typically outsource 1 or 2 people’s worth of work. Cannot afford a rigorous process on per client basis. Have to come up with a process that works across several client companies.

2. Structure

The vendor has is own project structure internally. But the client views the structure from another angle. How should the structure support these multiple views without contradictions?

3. Cost

Need to keep per-client overhead to a minimum. Cannot maintain redundant resources on per-client basis.

4. People Management

Every developer is accountable internally and externally. Internally to vendor’s own lead or project manager. Externally, to the client’s project lead or manager. This can be very confusing. How to resolve this?

5. Requirements Management

Clients, who are small companies, typically carry the specification in their head - not on paper. They do not have a spec, forget about giving the vendor a spec. So, how do you develop without spec?

Also, small companies typically do not follow formal software development process. This means, they change their requirements at the drop of the hat. How will the vendor handle change management?

6. Communication

How will the vendor manage communication with the client? Will it give direct access to the developer?Or, will it have a level of indirection - means a point of contact - through which communication will be channeled?

7. Post Delivery Support

How to do the post delivery support? Bugs in software are inevitable. Will the client be charged for the time to fix the bugs? Will bug fixing be done free of charge? If there are requirement changes after delivery, how to handle that?

8. Dispute Resolution

How to handle disputes concerning software not matching requirements? What strategy to follow to avoid this situation?

In Part II of this series we shall address these issues. The model will evolve from the solution and we shall see it in all its glory in Part III.

Children in India are quite good at math. And one of the math problems is that of a monkey climbing an oiled bamboo pole.

It goes like this - a monkey is trying to reach the top of an oiled bamboo pole. When he climbs up 3 feet, he slips down 2 ft. Climbing up 3 ft takes 3 seconds. Slipping down 2 ft takes 1 second. If the pole is 12 ft tall, how much time does the monkey need to reach the top?

I leave the solution as a trivial exercise for the little grey cells.

However, let me get to the point now. The question is - in the first place, why should a monkey climb an oiled bamboo pole? Does he not have other poles to climb that pose less challenges?

Jokes aside, we often see the need to address root cause of problems in software, before even attempting to solve them. Sometimes, the problem can be made to disappear altogether.

A real life example - in one program, I had to read a certain value from a hardware key. But, the driver dlls were taking too much time to load. So, I could not read the value directly.

The executable in question was part of a clutch of exes. And, one of the other exes already read the value, even before the target exe started up. So, a possible solution was to read the already existing value.

Fine; I started thinking of interprocess communication (IPC). My line of thinking was something like this: “I need to transfer the value without windows messaging because there is no message pump at the point we want to read the value … so a shared memory or socket based IPC approach would be nice.”. A value transfer problem morphed into an IPC problem, and all I was thinking about was how to design an elegant IPC mechanism.

Then, I realised that the target exe was a child process of the exe that already had the value - and, since child processes inherit environment variables of their parent, I could use an environment variable to pass this information. Two lines of code did the job - one line in the parent exe to set the variable; another line in the child exe to get the variable.

So much for IPC.

Sometimes we need to ask if the monkey really needs to climb the oiled bamboo pole.

The other day I was remembering (fondly) few tickles in the venerable Bengali magazine “Desh“. Well, it is really a serious mag, so serious that it is better to keep a Bengali dictionary (”Abhidhan“) nearby while reading it. But, sometimes you come across real witty ones. And by the way, we Bengalis make fun of ourselves - and we are also famous for self criticism. Anyway, enjoy:

[One]

A guy went to London. He tagged along with a friend to a house party. Other than not knowing to say “please” and “thank you” like punctuation marks, he also did not know how to ask politely the directions to the restroom.

His friend advised him - “When you want to go to the restroom, mention that you wish to wash your hands”. “Washing hands” is apparently the euphemism for attending nature’s call.

Anyway, this gentleman arrived at the party. Just before the dinner was about to be served, the lady of the house walked up to him and said, “Would you like to wash your hands please?”.

His reply? “Thank you. But, I have already washed my hands on the lamp post outside”.

[Two. I am not sure if it was my friend Mustafee who told me this.  Me old, memory rusty.]

At the time India was not independent, a Bengali school teacher was sacked (for whatever reason) by the Inspector of Schools. When he met his colleagues after the unfortunate incident, he was smiling. His friends were surprised. “Why are you smiling after getting the sack?”

He replied, “Sahib scolded me in English”. “Sahib amake Ingregite galagal diyechen”

Yeah, very unkind indeed. This one a direct swipe at the anglophile Bengalis.

[Three]

This one is a gem. Interviewees, beware.

One guy went for an interview. Later, he met his friends. “How did the interview go?” they asked.

He said, “It went fine … but …”. He was not very sure. They said, “Why the but?”

“It was all fine … but I think I made a mistake when they asked me to show my testimonials.”

I love the fish in Kolkata. Actually, I love the fish in Assam more (better flavour, freshly caught etc) - but, the Kolkata fish will do just fine. I miss it so much when I am out of eastern India. Sea fish cannot hold a candle to river fish. Just thinking of a live sleek ‘Chitol’ makes my mouth water.

I am getting nostalgic. The setting: an evening in a fish market anywhere in Kolkata. Awesome ambiance. Ferocious looking fish sellers, in peacock blue lungis and singlets making an attempt at being charming. The sweet come-hither call punctuated with batting eyelashes- ‘apnake ajke ekta bhalo Ilish khaoai?’. Something to the tune of - ‘Sir, may I treat you to a delicious Ilish?’ (you can substitute Ilish with a fish of your choice).

Man, this is almost like giving the fish away for free. Not only free, but close to the point of begging to give you a treat.