Bloggo back to the blog
‘One eye on Path, One eye on Goal’ by Ajay Balamurugadas-->
We always seem to have at least one teacher who inspired you when you were young. Even after many years have passed by, we would definitely remember the lesson.
For me, one such lesson is – ‘When you have one eye on the goal, you only have one eye on the path.’
So, if you are wondering why am I highlighting this lesson, there is a reason.
Let me tell you a short story:
A team of three testers are testing a product to be released in seven weeks from today for a special customer. There is a QA team lead and a QA Manager who are also quite interested in the project.
Week 1 & 2: Know your Role
The team spends the entire week in product discussions, presentations, Q & A sessions, email exchanges and feels confident with the test data and the test environment. The team is getting used to the different features. Lots of questions are answered and many more questions pop up.
Week 3: Bugs, Builds and Fixes
The team starts logging bugs. The number of open bugs(yet to be fixed) is increasing day by day. The test team is busy testing, uninstalling the old build, installing the intermediate builds to verify the fixes. The frequency of builds has increased and the test team is spending less time testing a particular build.
Week 4: Prioritize, Setup and Adapt
The test team is busy attending meetings to prioritize the bugs logged. The project manager sitting miles away from the test team wants the testers to test on one additional operating system and browser combination. The testers are busy setting up the test environment. Did I mention that they had to attend the 1 day training session on ‘Effective Time Management for IT Professionals‘
Week 5: Meetings, Compromises and Safe Testing
With one day spent on reinstalling a build due to incorrect setup, there was only three days in the week for testing. The fifth day was a holiday due to a national festival :) The 1-1 meeting with the QA Team Lead and the project review meeting with the QA Manager did not help the test team either. The test team were running tests which would always pass ;)
Week 6 & 7: Less Open Bugs, More Fixed Bugs
The test team was so busy verifying the fixed bugs that they have very few time left to test their new ideas. Less tests meant less bugs. The illusion of ‘Everything Seems OK‘ forced everyone to release the product at the end of the 7th week.
Now, try relating each week with the line: ‘When you have one eye on the goal, you only have one eye on the path.’
Week 3: Intermediate builds slow testing.
Week 4: New requirement, 1 day training
Week 5: Meetings
Week 6 & 7: Ratio of Fixed bugs to Open Bugs
How many times have we faced similar situations?
Matt Heusser in his interview with uTest highlights how increasing the actual testing even by a small percentage helps add value to the overall project.
Similarly, if one eye is focussed on releasing the product on DD-MM-YYYY, we are left with just one eye on the testing activity. Add to it the various administrivia, setup, meetings and you are the best judge of how much time was actually spent on *testing*.
How much time is spent on activities that do not add value to the overall goal?
How effective the test team would be if they just tested without worrying about any other activities?
When will we have the courage to say NO to non-testing activity and spend most of the time testing?
I have learnt the lesson:
Two eyes on the current activity helps me achieve my goal than one eye on goal and one on path.
What about you?