Embracing change can be difficult, whether you are a tester or not. After all, why should you change how you have tested?
We have always tested using waterfall and the project was delivered.
We have always written detailed scripts on Excel and we.
We have always tested web pages using IE on a Windows PC.
We have always tested this way, why should we change?
You may have heard these or similar statements from your fellow testers, or even said them yourself. You may have fought against change, believing it will only make things worse. If something has been tried and tested over and over again, why would you change?
I’m hoping I can convert you to embrace change, and help others who are resistant to it.
If there was no change, we would not have a job to do. If code was created once and no more was ever made, no alterations, no new features, what would we be testing? Change drives our very profession. We are agents of change!
Picture change as a flowing river.
You can resist change, building a dam against it so that you stop it completely. But the river will dry up, and you will have nothing left to work from.
You may let a trickle through, a small amount to keep you going. But will that be enough for everyone? What would have previously need a team of 5, 10, 20 people may only need 1 or 2.
But what if you didn’t build a dam. Instead you built a water wheel for you to work from, and let it empower you to do even more? Or you built a boat, to carry you off into somewhere new, seeing things you have never seen before?
Each day, more companies and there testers change how they work, moving from waterfall to agile using sprints or kanban boards, or to continuous integration where instead of big bang releases they are using lot of small releases so it is easier to see what is wrong whilst fixes problems faster. When you go to a developer or business analyst with a question, you are more likely to ask them about something they may have only looked at days if not hours ago, instead of weeks or even months ago and can’t even remember.
Instead of using highly detailed scripts, you may explore what you are testing and create a charter, with an outline of what you are intending to discover. It may seem like you are going in blind, but your charter will allow you to show others. Imagine you were dropped off in a random city and told you have a day to see what you can find. You may see some tourist attractions, places to eat, shops, etc. But there is plenty you would have missed. Now imagine you were told to only look for places to eat. Or find as much as you can on a main road. You haven’t been told to walk 20 towards shop A, walk inside, do a lap of the shop and walk out, continuing to the next shop, only to find out the shop next door is closed for lunch and unable to progress.
We cannot test without learning, whether it be a new piece of functionality, a new way to write a SQL query, a new way to capture a screenshot on Word. By embracing the changes that are flowing down the river, it allows you to learn more new things.
If you are still resistant to change, ask yourself why? If you try something new and get it wrong, call it a test and try again. If everything worked perfectly and as intended every time, we wouldn’t have a job.
I’m not suggesting change is easy, but we don’t need to make it any harder than it already is.