The rate of change
The rate of change has increased than ever.
My great grandparents used to live in a village and they lived there for centuries. But since 1920s, my family has moved to three different cities in three different generations.
Technology has played a role in the recent increase. Consider this: The idea of PC is ~40 years old, the idea of internet is ~20 years old and the idea of a smart phone is ~10 years old. Which one has caught fire earlier than others? Obviously the hand held devices.
One way is to whine for things that have changed and pray that they go away. Other is to do some effort to cope for this change. Luckily the Agile methodologies are based on the concept of ‘change is permanent, so let’s incorporate it’ and thus Agile Manifesto says:
“Responding to change over following a plan”.
On the other hand, humans are not designed for accepting change and there is always resistance as quoted in ‘Making Change Possible’ chapter in the Peopleware book:
“People hate change…
And that’s because people hate change…
I want to be sure that you get my point.
People really hate change.
They really, really do”
(Steve McMenamin, The Atlantic Systems Guild, London (1996)
And if one breed of software engineers are more against changing world; those are software testers. It can be challenging to coach testers to incorporate change in their testing strategies but here a few ideas that I would pass on the testers working in this changing world
Ask the testers to keep an eye on what has changed so that testing effort is focused around the change. It can be as manual as a Freeze Memo email from the project manager or as automated as a build diff log produced by your source control system. In one of the teams I have worked with, we used a way that whenever a change is committed to the code base, an email has to be sent to the entire team. There are also tools available that help you figure out which of your deployed file has a newer content and you should worry about them only.
Then you can suggest a build schedule which can be anything from daily to once a week. By grouping changes in one bundle, the disruption for the testing team is very less. If you don’t have a build schedule, it is like waiting for a bus when you don’t know when the next one arrives.
Try to gain more understanding of what’s inside the system and if your view is not of a white box, it should be of a grey box. Having more in depth knowledge of what causes what will help you figure out which test plans you should pick on next scheduled build if you know the changes before hand.
In a changing world, any time spent on non-production activities sucks. That is why, you need to consider how you manage your test cases and test plans. If you can switch to less documentation and look for ‘lean’ test case management systems, you’ll hand over more time for the tester to actually test the system rather than testing. There are even such things as a 10 minute test plan to save you time and thus money. In terms of what details you might trim down from your test documentation, consider the story of ‘Fresh fish sold here today’, though I won’t suggest removing the whole banner but at least some words can be.
It is also important to nurture a dedicated automation team and have it work closely with your manual testing team. The focus of manual testers should be on Exploratory testing and any significant test cases found by these testers should go to the automation team to get automated before your next build. Well, I’m too optimistic here but some of this can actually work.
So embrace the change and who knows it becomes your friend?