Rediscover your focus

So you’ve been working on the same project for quite awhile. Say, more than a year. Testing the same application, ‘doing yer thing’. I mean, we cannot all be flashy consultants moving from project A to project B in a matter of months. Personally, I like building up a vast amount of knowledge in one application and helping others with that knowledge.

The downside of staying at one project for a long time is also clear: boredom. Sloppiness. Testing the same thing over and over again. I know I’ve fallen for that sometimes. I didn’t sleep well and just wanted the day to be over, that kind of thing. But I always feel guilty when that happens, like I could’ve done better.

Over the course of the last few months I really found my focus again and I want to share with you how I did that:

Take a break. The biggest impact I felt on my performance was being away for awhile. I went on a hiking holiday in Scotland and boy, that paved the way for a change. With the risk of sounding a bit spiritual, I really got some soul-searching done there. I didn’t even intent to, but when you’re walking you have a lot of time to just think. I got some stuff I was struggling with sorted out and made a promise to myself to focus more at work. You could say that I prioritised what’s important for me and found new motivation to do my work at the best of my abilities. To sum the whole thought process up: I want to give work my best effort so I can enjoy my free time more.

Realise that things always change. Even in software that has been around for years, things constantly change, so you also constantly have to change the way you test. DOH, sounds like a no-brainer really. But still, when I had to do some regression testing for example, I felt so much resistance in myself. The urge to just do the same thing as always was hard to fight. I really had to force myself to spice things up. Throw the testscripts in the bin (just write the test intent as documentation if you have to), automate as much as you can (sensibly) and do your regression test in an exploratory manner. Use personas to test, think about states when you test, etc. Some of the things I mention here can be done at once, others (the automation) will take longer. But there is always room for improvement. Last week I found a couple of bugs that had stared me in the face for awhile, just because I suddenly was thinking ‘what if I put the application in this state’ and BAM. It felt really satisfying! It also gives me more motivation to continue this search for better testing.

Improve things. Improving things for testing doesn’t mean just you. Lately I have involved myself in discussions with the developers more. When a bug was fixed I also ask what had caused it. I ask if we can improve the implementation so it is more robust. Often, I don’t even have to ask, because the developer realised it himself and cleaned up the code. Also, I try to get the developers to test more. It still happens that I find a bug that really shouldn’t have been there (because a requirement was  misunderstood for example). I don’t want to be the gatekeeper of quality (that’s scary shit), so I’ll try to make the developer realise that there is room for improvement. That sounds really patronising and shit, but I feel it’s really necessary! I just want everyone to realise that they are very important in the success of the team, so it’s important that they too improve their way of working. To avoid coming across as to patronising I always try to keep it light. And in the end, I can only point out to the developers what has gone wrong, I cannot control them. But at least I know I have done my part in making the app better. Testing isn’t just waiting for the dev to finish his coding, so I actively want to involve myself in the process. As a team, we also have testing session where everybody tests. I wrote a post about that here.

Document tacit knowledge. When you’re on the same project for a long time you build up knowledge. That is cool and all, but it also comes with a trap. Before you know it people come to you with all their questions because they know that you ‘know everything’. Then you will teach them ‘learned helplessness’, meaning that they become lazy in researching how to solve a problem because you will tell them the answer anyway. Combine this with an attitude of wanting to help everyone because you want to be liked (or want to be irreplaceable?) and you are on the road to a burnout if you’re not careful. Document your tacit knowledge where possible in a wiki. It has to be living documentation so others can add to it. Ask others in your team to help with this as well and you’ll end up with knowledge that is transferable to others.

Those where my main tips, I hope they were helpful for you! If you have tips of your own, please leave them in the comments. Sharing is caring! 

Learn by doing