Monday, October 16, 2006

Why is execution so important?

Almost anybody can tell you what is theoretically right. I know it, you know it and almost everyone in the world knows it. BUT, who ensures that what is theoretically right is executed right. In the professional world, every day we have lots of meetings and everyday we take lots of decisions. YES, all those are right, BUT who ensures that they are executed. Planning takes 30 minutes and its execution 30 hours :)

Below is an E-Mail which I had sent on 7th Feb, 2004 to one of my Ex-Managers. Two and a half years down the lane, we are still trying to execute it. Had I led it to a proper closure that day and at that time, the cost now would have been too low and we would already have reaped the benefits.

Hopefully I would learn something from it and be careful the next time :)

Hi

I have tried to work on a framework with the help of which the automation of the testing of wireless STAs can be done (with the help of WirelessConfigurationTool package). It will require add ons to the code we have for PrismServer and PrismProfileChanged and implementation of test cases. I am giving a brief overview of the idea I have in mind:

There will be test suites and test cases within suites. Test suites are a group of test cases for which the settings of the AP will remain the same. Each test case will have some configuration information in the form of XML going to the PrismPCtl running on the DUT (depending on the test case being executed). The Wireless STA settings will be changed accordingly and the expected result noted.

Before triggering a new test suite, the user will be prompted for permission. This is required because before executing each test suite, the settings of the AP need to be changed accordingly. The prompt would give the user time to change the settings of the AP. This also can be automated by synchronization between the changing of settings in the AP and the transmission of new profiles to the STA.

The framework I have tried to make has the concept of test suites and test cases built in. It prompts the user before starting the test cases within a test suite. The full automation (i.e. automatic setting of AP after each test suite) is not yet done, but theoretically speaking it should not be a tough task.

The ADVANTAGES of automating the test cases are:

a) I think that after a fair deal of automation, only one day should be required per DUT for testing purposes. Thus it should save *lots of time*.

b) There is no need to *repeat the monotonous activity* of running the test cases reading a test case document, after we have considerable faith in the automation of test cases and they start giving the desired results.

c) It should *save lots of firmware dependent bugs* because it is not feasible to run the whole bunch of test cases manually after each firmware / UMAC revision is released (which have been quite frequent going by past experiences).

d) It should be *quite easy to append* new test cases to the test suite as more and more features become available (WPA, WPA-PSK).

e) The test suites test the wireless features and thus they *should be independent* of the type of DUT we are working on. For ex. the same bunch of test cases should work with a USB Cohiba or a PCI device attached to the laptop.

Thanks
Vaibhav