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:SomewherelahMyFile) in the script window - then, when this line is executed the file will be copied to the C:SomewherelahMyFile. Remember no spaces around the comma or after or before the brackets.

QAuto will automatically make a backup of existing file C:SomewherelahMyFile 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:SomewherelahMyFile) 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:SomewherelahMyFile) - 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:SomewherelahMyFile) - 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.