Sunday, February 20, 2011

On being the only tester in TW teams

Well, I've been working as the only tester in the team for last 3 projects, almost 3 years.

Some learning / observation:

Initial impression of 'oh my goodness, there is so much to do!' is actually true. I had to get involved in quite a many things. And all those tasks are important in their own way. It is definitely not easy.

Key takeaway is reducing re-work and increasing efficiency.

Ask for help ! [increases efficiency]

Asking for help from other team members really helped. Be it automation of tests, bug triage, setting up environments or clearing of backlogs. Just had to make sure I don't delegate a task completely with out getting involved, in that case I'll be more of a pain than productive.

Be assertive: [increases efficiency]

Shout out when dev practices get sloppier or if there is constant increase in number of bugs. Helping the team figure out the root cause will make the next iteration much better.

Spend more time in developer box testing [reduces re-work]

This one practice can reduce so much of re-work ! Testing is nothing but giving feedback. Faster, the better. If possible, make 'Dev box testing' part of the story life-cycle. Thus, it will become a routine and leads to less re-work.

Get involved in analysis. [reduces re-work]

Again, helps in reducing re-work. Story kick-off are good too. More questions I asked at this stage, more easy it became while testing.

Less documentation: [increases efficiency]

There is a difference between less documentation and no documentation. Does this bug need to go to Mingle ? Does it make sense to list all the test cases for this log-in story ? What if I win a lottery and decide to leave? If I go on leave for another 2 months can some one else pick up from where I left and so on and so forth. It helps to ask the team (includes clients as well ) about what they expect /need from testing documentation POV.

Think beyond just story testing: [increases efficiency]

There are other areas of testing that I had to worry about: Performance, security, analysis, client interaction, environments … the list goes on. Interestingly this didn't become a pain. But it definitely is more time consuming and exhausting if I don't plan little ahead or ask for help.

Managing time: [increases efficiency]

This is tricky. Its easy to get overwhelmed by the pressure and just give up. There are few tasks which need much longer span of attention than others. Example: Test automation. I would declare "I am in 'Automation' mode" in stand up , and let every one know that I may not be able to help with other tasks. I usually keep these single task mode stretch for one or two days in an iteration.

Another way to manage time is to combine few tasks together. A rough example is : I'll keep my sql profiler running while I test a story for it's functionality. A quick scan through the DB logs helps to identify any quirky behavior. Like wise, I'll let perfmon run while I run my routine automated tests. The performance graph would later help to identify any leaks and such.


Finally, communicate. As often as possible. My habit is literally shouting at the table about the new info or an interesting bug. Identify risks / bad trends early and communicate. Easier said than done though.

Also a couple of hours of 'Do Not Disturb Me' mode of working helps, a lot. Communicate that too :-)