Tuesday, August 30, 2005

Gaither Reshuffle: Random is the New Order

There is reshuffle at the Gaither Road facilities of our CNSI office. We expanded our office space by acquiring our next door neighbor’s space. We all assumed it is going to be as convenient and as manageable as $ 99 Apple shuffle. But alas I woke from my day dream. The office planners had planned this for months, but then they re-planed with few weeks left ( they did not order the carpet ahead of time), and then they went into a crisis planning mode( they bought down a wall which now needs to be build up again) too. Alas they finally stopped planning when the work got underway. Anyway, all the planning for the future growth did not last very long since by the completion of this reshuffle project we run out of space (anticipated) Ironical! Well you decide that!
However, to the credit of the office planners, the project appears to be getting over on time unlike some of our IT projects which every time we look into it, we figure out that we have 6 more months to finish. Am I looking North East? Arghh! Back to the shuffle, oops, I mean the reshuffle.
Space is premium ladies and gentleman and individual offices are what people would fight for as if there was no tomorrow. Cubes are considered a step down. Sending emails, escalating to everyone (can you escalate to everyone, I need to figure that one out yet), making presentations to justify the need for the office are the flavor of the week. Hey come on we have to work in the environment for long extended periods, weekends too. (This project was an exception. No work was done during the weekends even though it meant outages in the regular work days.) So Brethern, all I can say is that the fight is justified! Damn! I have an office too and gosh it feels on top of the world. Close the doors and you are at home. The office planners worked to satisfy all kinds of forces for the office space, brainstormed ideas ( as if there were many) , discussed for long hours in meetings ( actually same thing repeated n times ). But time was spend like crazy ( for there was no other work to be done) and out came the guiding principles. Can those be shared? No, because for they are guiding principles, we are not supposed to follow them, just guide along them to walk into the exception world. Further they are baked fresh every day.

Finally the D day came and phase I of the project got completed on time! Infact ahead of time. Pandemonium!! We were supposed to move on Friday. OK! No! Wait we are supposed to move on Wednesday, since we cut down the networks, telephones from the old to the new already. Yikes!
Anwway, we all welcomed the randomeness since 'In Chaos lies Creativity", and we all eagerly wait for the next phase with great anticipation. So till next time welcome the random order and enjoy the reshuffle across the border !!!

Tuesday, August 02, 2005

Purpose of Testing

The purpose of testing can be to show that the software works or it can be to show that the software does not work or there can be another level where the purpose is not to prove anything but to produce higher quality software. When we say quality, a lot more gets added to the whole process. The testing simply does not become a procedure to find bugs but something where one set of tests try to fail it and another set tries to improve it( increase in usability/"easy to use" is one such improvement).
Black box testing, white box testing, bottom up approach, top down approach etc. has always been there. To my understanding the goal is still the same , making sure (1) what we built is what was expected by the user and (2)Another level, where the software exceeded user's expectations and software is really solving his problem and not creating a new problems of its own kind.
Today morning while driving I heard this analysis on radio about automakers. Their big challenge is that they design their cars based on user requirements or who would be driving the car etc. But the issue is , as they were saying, most of the time a user doesn’t know what he/she wants till they actually see it. This is what happens to us also when our system goes to production. We can always argue use agile/RUP/CMM etc. to avoid this but still we always find this issue.
There is another issue and that is our test cases. Most of the test cases are written either to satisfy the requirement or to satisfy the design. This is not a bad thing (although I have read some articles which say the word “requirement” is bad. Another topic of discussion!).

I would divide testing in to two levels (1) Business Process Testing. (2) Code level testing.

Arvider has already posted his views on "Business Process Testing". But there is another level " Code level testing" where you go down to the code level, making sure you test each method in the code(Method coverage), Making sure each statement gets executed at least once (statement coverage), Branch coverage etc…. This is where GACC, RACC comes in to picture.
Now you can always say that , that would be a lot. Well you do not need to achieve 100% of Test Coverage and also in order to do this you do not need to change what ever you are doing but you need to look at your Test Cases and produce smart test cases. How you produce smart Test Cases? I will try to write something about it soon.