Testing Mindset

At work, I’m helping a colleague in developing a material on ‘testing mindset’ which is to be shared to our fellow testers. Initially, we have this list of one-liners — catchphrases that we hope would stick like: Always ask the question why, Assume the product is broken, Trust but verify, etc.

I tried going over them one evening. And while they do emphasize some qualities that are important for testers — like being persistent, curious, attentive to detail, critical-minded — I felt that it was still lacking. Some qualities that I deem important were missing — like having good communication skills, being a team player, being technically skilled, striving for self-improvement, having pride and ownership of your work/craft. I came up with an 8-point bullet list describing qualities that I would like in my test team, until I cut myself short since I was working time-bound. And as I’ve taken a step back from the one-liners to come up with this incomplete list of desired qualities, I took another step back from these qualities and thought of what is the driving force behind the need for these qualities.

Why must testers have those qualities I’ve been enumerating?  Why must they keep those catchphrases in mind?

In pausing and taking a step back, I realize it’s all for making things better. I guess that’s my personal testing mindset: I try to make things better.

When I started testing, I thought it was my nitpicking skills and slight OC-ness that made me such a good fit for the job. I just loved finding bugs (and still do)! Over time and over many projects, I found that my purpose in the team isn’t just to find bugs. Essentially, it’s to try to make things better. By “things”, I don’t only mean the products under test. But also my working relationship with my team mates, work loads, schedules, processes, the team itself, and even myself.

  • Say, I try to expose the bugs and report them, so that they’d get fix. Product gets better.
  • I try to provide suggestions for improvement like a comment on usability. Product gets better. If fixed, that suggestion could cut short the work that the end-user has to do.
  • I try to report bugs clearly and concisely. Dev’s life and mine are better than it would have been if i had given a vague report. Dev will hopefully be able to replicate the bug so he won’t have to nag me for details.
  • I try to find shortcuts and tools, and share them with the team. Tester’s lives are better. Even just the little things that could help minimize the tedium of some of the tasks we do is something I appreciate.
  • I try to read up, and try to continue learning and improving myself. I (hopefully) get better. (Well, i try.)
  • I try to encourage knowledge sharing among team members. The team (hopefully) gets better.
  • Etc.

Yoda might disapprove, because after all he said “there is no try.” But still, we must persist. The things we do, the qualities we instill in ourselves, our values — these must all drive towards the betterment of our team, our product, and ourselves.

Looking into improvement opportunities… Laziness FTW

20120524-095504.jpg I found this bit (screenshot at the left) a couple of days ago as I was going through a Business Analyst reference. It lists some common examples of improvement opportunities that a BA is likely to identify. But I think it extends to any role, after all, continuous improvement can and should be everyone’s business. Sometimes when I’ve got time to kill at the office, instead of visiting Facebook, 9gag or other time sinks, I make it a point to think about my work and my team’s work to reflect on what can still be improved. I try to leverage on “laziness” to look for ways to do things faster or make things simpler. 😉 Looking into the common examples given in the list can be a good starting point.

Automate or simplify the work people perform.
For instance, in a previous project, there were SQL queries or Unix commands that I had to run frequently. What I did was to tie them all together into scripts so I just need to run the script and then review the results afterwards. Another example is the sharing of shortcuts or other quick workarounds to the team during our test team meetings. If there are tedious tasks – especially those that have to be performed repeatedly – these could be something worth reviewing or automating. If you come across a tool that could help you do your work faster, share it.

Improve access to information.
Consolidating references into a repository that is accessible to those who need them is an example. Another example is generating reports from our defect management tool which captured information that we had to focus on (e.g., number of days the bugs remained open). In both cases, you make the relevant information easily available to those who need them. If there are things that are hard to find or hard to retrieve, yet should be available to the team, then this could be an area for improvement.

Reduce complexity of interfaces.
For most of the tools deployed to a previous team, I prepared a README reference to hopefully make it easier for them to use the tool. Another example is creating a view for our defect management tool which displayed only the fields that were relevant. The default view displayed all fields which could look a bit daunting as there were so many columns. If there’s something that looks far more complicated than it should be, then this could be something that needs to be worked on.

Increase consistency of behavior.
In my old team, there was a tendency for meetings to start late – so folks who actually come in on time end up penalized since it’s their time that gets wasted the most. This wasn’t the consistency I wanted though. What I did was I took ownership of the test team meetings and made it a point to start on time and with a prepared agenda. Another example is preparing a set of standard test cases for checks that are needed across certain applications. Without this in place, the tendency is tester X tends to miss out on some stuff, while tester Y covers them but misses out on other stuff. If there’s something that has to be done consistently, support it by reinforcing the behavior behind it or by providing some structure to reinforce it.

Eliminate redundancy.
In one project, a colleague and I did a review on test cases and we managed to eliminate some overlaps. There was tester X who worked on A, B, C; and tester Y who worked on C, D, E. They might not have been aware that they were working on C had it not been for the more holistic review. Another example is we had a couple of scripts that functioned quite similarly. One summed up a couple of fields from a text file, while another did the same thing but with the ability to do groupings. I asked a volunteer to merge them so that there’ll be only one script to use and maintain. If two folks are working on the same thing, then that might be a waste of effort; their energies could be diverted into something more useful or worthwhile. If you have more than one working solution, it could be worth examining whether the cost of maintaining them all outweighs the benefit.

Help yourself

It’s a bit ironic that I’ve become friends with a fellow tester only when she was about to leave the company. We still get to have dinner occasionally and I get to find out about the training and learning activities her new company offers. For instance, she’s got some training lined up on Perl. They also have book reviews with the costs for the books and for reading them shouldered by their company. I think the last book they’ve read was on scrum which I find interesting since I would like to have some experience with Agile methodologies. Their upcoming book for review is on Agile testing, which made me blurt out, “by Lisa Crispin?” and just left me with my mouth agape. Lucky lucky lucky!

As for where I work, well, the last official training I received was way back in 2007. It wasn’t even testing-related. It was an upgrade training on CMMI version 1.2. Some books on software development and testing were purchased last year (or was it the year before). We don’t have time allowances for reading them though. You can, but it would just have to be on your own time. That’s fine, but only if the workload and schedules given to you afford for you to have your own time.

Anyway, the lack of training offered isn’t — and shouldn’t be — an excuse for turning stale. It sucks if you aren’t provided training to keep you up-to-date. But it will still be your fault if you let that stop you from picking up new things altogether. With social media on the rise, one can turn to blogs and testing networks for materials. Web sites covering Agile methodologies, offering programming lessons, giving testing tips also abound. Online shopping has also made it possible to buy books from overseas, but it’s just too heavy on the wallet.

Unavoidably, there are things that impede or limit us — financial constraints, lack of time, no internet at work, lack of available training (although this one’s expected to change soon), etc. But what is important is that we don’t limit ourselves. We can learn if we want to. We can train ourselves. We can seek mentorship outside the confines of our workplace. The potential to grow is there.

Quite aptly, I received a text message from my friend: Obstacles don’t have to stop you. If you run into a wall, don’t turn around and give up. Figure out how to climb it, go through it, or work around it.

Text: 10 differences between a winner and a loser

Here’s another thing I stumbled upon, and as the title suggests it’s on the differences between a winner and a loser. But of course, context matters so we can’t immediately brand someone a winner or a loser upon matching at least one or two of the descriptions below.  Anyway, the text gives us an image of a winner as someone who is responsible, humble and mature; and hopefully, that’s an image we should all want to emulate.

On the other hand, if we recognize ourselves in the items tagged as being loserish, then perhaps we may need to put in some time for introspection. This introspection thing is not to make excuses and it’s not to identify who else can be blamed. The focus should be on how to improve so that the next time we’re in a similar situation, we’ll hopefully come out as winners.

Read on…

Continue reading