## India Gate

India Gate is a war memorial situated at New Delhi, India. Since India’s independence, India Gate has become the site of the Indian Army’s Tomb of the Immortal Soldier, known as the Amar Jawan Jyoti. Want to share some of my photos of the memorial below.

 India Gate - going for a shower India Gate - traffic zooming by India Gate - up close

Unlike the rest of this blog, these images are copyright and all rights reserved for now. In future, they may be released under the same license as the rest of the blog.

## Making scores comparable

How to compare scores rated under different tests, or by different people? Find out, and use the ready spreadsheet to crunch your own numbers.

Assume that we have feedback on team members from two different project managers.

 People-> U V W X Y Z Managers | A 70 63 82 91 56 77 B 68 60 80 80 55 60

Can we say that W performs better in team A compared to team B? It looks like yes, he works better but analyse the scores a bit deeper. Project manager B has rated all team members lower than manager A. It may be that he is using tighter scoring.

In a different situation, it may be that two teams (of different people) have gone through two different tests, and we want to compare the people against others. Or, a university might want to compare people passed out in 2001 with those passed out in 2009.

The question is, how do we compare people when the scores that we have do not use the same basis.

The answer is: normalization. We fix the mean score, and the degree of deviation that we would like to see. For a 100 marks test, we may want 50 as the score and a 20% deviation. Now, we will compare this with the actual mean and the deviation of each of the sets, and modify the scores as needed. Please refer to the attached spreadsheet which helps you do this.

In the given example, A has a mean of 73, and a deviation of 13. B has a mean of 67 and a deviation of 11. Let us bring both to a mean of 70 and a deviation of 15.

 People-> U V W X Y Z Managers | A 66.3 58.1 80.4 91 49.9 74.5 B 71.2 60 87.9 87.9 53.1 60

So we note that A is indeed better in project A, but only slightly. Also from the initial figures we might have concluded that U is better in Project A, but actually the reverse is true.

Mathematically this process is called Normalization and is useful in fitting scores to a bell curve. Read more about it here if you are interested. However the spreadsheet attached is sufficient to get you started.

## The world of computers: vision 2020

What would the shape of computing be 12-15 years from now? Here is where I think we will be:

My wrist watch will have my computer. When I reach office, I will place myself in front of a ‘dumb’ terminal – a monitor, a keyboard and a mouse. Embedded into the keyboard will be a smart card which will talk to my wrist watch (without cables). I will use a remote log-on software to connect to the computer inside the wrist watch – all applications will already be installed on the wrist watch and I will use them. It will also be possible to use the wrist watch as a pen drive of today. So all the data on the hard disk of this computer will be available in two ways: the remote log-on (which will also enable the use of installed applications), and USB (that is, minus the capability to use apps).

At home (and everywhere else), I will have a similar dumb terminal.

Microsoft will be dead – opensource (and portable) software like OpenOffice, and AbiWord will have caught up in terms of functionality. For profit firms of 2020 will provide support (and contribute to the enhancement to) GPL software.

Google will be going, but its offering of (office and other) applications as an online subscription (which will have become paid by then) will not be doing very well. People want to collaborate, but not at the expense of being tied down.

Electronics commerce will still have identity fraud ðŸ™‚ Sorry guys. However, the total volume digitally traded will be rising steadily.

Digital signatures would be much more easier to use, and transparent to the unitiated user. However, it will not be free from its own share of frauds.

Operating systems will be very different from today: there will be no device drivers. Every device will be plug & play, and will use universal drivers. Linux will be the defacto standard.

You have some more ideas? Please feel free to share.

Blogged with the Flock Browser

## Top 10 considerations when preparing a software test plan

Click on images to enlarge

-> Test the parts of the application that have changed since the last cycle / go live

This part of the test plan is very obvious: test the changes to the application. Each change needs to be tested individually if possible, or as groups if the number of changes is large, and is known by the name regression testing.

For example, if you added a new field called ‘maximum pay by date’ to the voucher batch interface, then you could test the interface for this – having both data with this date entered, and with this date set to blank.

There is nothing more to this one – its normally the facet of testing that does receive the due focus during testing.

-> Test sampled parts of the application that have NOT changed

Now we come to something that does NOT receive the due focus. The parts of the application that remained unchanged. No, you do not have to test ALL if it. If you can test all of the application (especially with automated tools, as discussed below) – nothing like it. However, at least test 10-15% of functionality that has not changed.

For example – as discussed above – if you changed the voucher batch interface, then you can test the online voucher entry. Under the online voucher entry, test at least one scenario that has not changed.

The rule of the thumb is that if in a module having 100 test cases, 40 have changed – then test those 40 that have changed, and test 6-10 of those 60 that have not changed.

-> Look at it from the end users perspective: do one full cycle end to end

Next to include in the plan is something you can call integration testing: if your application is about users entering vouchers and getting paid – perform this cycle as a user would do. Many times we IT folks test only our application – the one we are developing and forget the rest of the glue technology. It falls into the category where we want to do it, yet are lazy at – so we find some short-cuts.

Once I was asked to carry out testing for a reconciliation report that had already been tested by the developers. I uploaded the same input twice, which ended up showing double on the final report. It turned out that the developer had missed this because he tested only on the basis of data that already existed in the system, and did not upload any new vouchers.

-> Stress testing

Stress testing should again be a very critical part of your test plan. How many users are expected to use the application? during normal hours? during peak hours? Plan for all such scenarios. Design the business process that would take place if the application does fail – the idea should be that the user’s work doesn’t get halted.

There are stress testing tools available both free and commercial that you can use to simulate users.

In one of my projects, a web application that was created for 800 users, failed under a load of 35. Increasing the number of processors, or the number of server boxes is not a guaranteed way of handling load on the application: the application has to be designed to support the load from the ground up, and tested suitably.

-> Performance testing

How long does a file take to get processed? How long does the user expect it to take? How long it takes for the screen to open/save?

The user expectation part is sometimes ignored. Please go ask the users of your application now what their expectation is – or it might already be too late in terms of coding.

The developers might think if a process runs for one hour its good enough. However, the users might be needing to run it six times a day during the closing period. Hence one hour might not be fast enough. In such a scenario we had to run four parallel instances of a process to achieve the user specified timing.

-> Concurrency testing

Can two different instances of the new process run together? The panel you just created: can it be used by two persons at the same time? Does it cause deadlocks at the database level if 100 instances of the process are run together?

Can two different versions of the application exist on the same machine?

These are the kind of questions that you ask yourself while working on the ‘concurrency’ aspect of test plan/execution.

A team of developers once needed to clone a process, and create slightly different functionality. However, it turned out that when both the processes were run together, 1 times in 10, one of the processes would fail. This was noted after go live ðŸ™‚ Turned out the cause was incorrect use of the shared temporary tables by one of the processes.

-> Unit test before Integration testing

Our laziness at work again: we ‘trust’ our work and want to move directly to integration testing. Partially, the waterfall model of software development is also to blame here.

99% of the times, after the developer moves directly to integration testing – the very first test case for the application fails, and the developer comes back to the unit testing phase. ðŸ™‚

Unit testing is a very critical part of your test plan – if you do it right, you will find hundreds of issues that will otherwise never get detected. Even not during integration testing.

Build ‘driver modules’ to iterate through all the ‘ifs and whiles’ that have been coded. Try out all avenues control can flow through.

-> Create test history

Creation of a test history is as important as doing the testing. Being able to, at a later date, answer such questions as: ‘what are cases we tested?’, ‘what are the problems we found?‘ etc is very helpful. Showing a clean slate (a ‘pass’ on all test cases) at the end of all our test iterations is not so helpful. In short, record the problems found, even though they may get corrected later on.

-> Automated testing

Automated testing solutions can be a big help. It does not mean that all testing be delegated to the automated testing mechanism: but it can definitely be an add-on to your manual testing.
In changing the order entry functionality, use it to enter 1000 different orders. There are several solutions available (use google) that will record the user actions, and will repeat those actions later with different data.
At a very simple level, AutoIt is a great tool for automated data entry, and is free (GPL). Its very flexible and has a great library of functions built into its scripting language. I use it all the time, and not just for testing!

-> Code review

While we focus on all these great ways of testing let us not forget our tried and tested workhorse: code review. Being humans, we are tempted to feel that by doing better testing (being easier to do) we can offset the need for a good code review, but there are hundreds of reasons to do code review.
There may be some program flows designed for rare situations which may never get tested. Code review in such a case will contribute ideas for such test cases. Documentation may not be in sync with the code, with the potential to make future changes difficult. There may be code improvements possible: for example, replacing an ‘if condition’ with a more specific check.

There are other things, depending on your scope you may also want to include them:

-> Knowledge transfer/competence testing

-> Backup & recovery testing

## Summer in Delhi

The summer season in Delhi is one of scorching heat with temperature running into forties (degree centigrade), and of hot air blowing (called loo). Its difficult to venture out into the sun even for five minutes. Plants, especially outdoor ones, need a lot of water and care.

However even in this weather there are some beautiful flowers that do not dry up – its amazing how Mother Nature is able to create such a treat. Seasons change, but flowers are simply replaced by other flowers.

 Flowering in Summer Zoomed Yellow Yellow dirty fellow ðŸ™‚

## Jogging

Am trying to motivate myself these days to initiate some physical fitness activity, hence writing about jogging. You know its time to resume running when you try to do a few push ups and discover that certain body parts refuse to leave the floor. Michael Johnson, the Olympic gold medal runner went to a club with friends. The bouncer stopped him and said “Sorry mate, no denim“. Michael retorted “Do you know who I am?“. “Then it won’t take long for you to run home and change, will it?” replied the bouncer.

Pheidippides is said to have run 149 miles to carry the news of the Persian landing at Marathon to Sparta in order to enlist help for the battle. It may be that the story of Pheidippides is a myth (if the Athenians wanted to send an urgent message to Athens, there was no reason why they could not have sent a messenger on horseback), yet the myth had legs and was the genesis of the modern marathon.

Jogging is a high impact exercise that puts strain on the body’s joints. I find real running much more rewarding than treadmill. Its a good cardiovascular exercise, and elevates mood levels when sustained over time.

Regards, etc.