Tuesday, March 16, 2010

Testing's "Lone Gunfighters"

Throughout my career, I have had the opportunity to work with various test teams, both as an individual contributor and as a team lead and test manager. During that time, and currently, I’ve also worked where I was the ONLY member of a test team. This can be both liberating and frightening. Liberating in the sense that you can do what you feel is appropriate, but frightening in the sense that there is no cover if things go wrong; if you mess up, it’s ALL YOU!!!

There are different levels of being what I refer to as a “Lone Gunfighter”. Sometimes you are the lone tester for a project, but you still have the resources of a test team to turn to. Sometime you’re the lone tester for a division in a given area, but you still have people you can communicate with in the testing department for your company. Sometimes, however, especially in smaller companies, you can be the “Lone Gunfighter” for the entire company. If you find yourself in this position, then this entry is especially for you.

When the situation of the “Lone Gunfighter” happens, testing takes on an interesting hue. Now, it’s all on you, and when you are the last line of defense, you really are all there is between the product getting out into the wild and bad things potentially happening. Sobering is a good word for this situation.

So what does an everyday software tester do when they are the Lone Gunfighter in their organization? From my years of being in this situation, here are my suggestions:

1.       Consider yourself a consultant for hire: This is a mindset that I feel is very helpful to the lone guns out there. Many times, we can feel like we have no direction, or that we are being barked at to get this or that accomplished, with little to no support from others. By putting yourself into the mode of consultant, you change the relationship. Now you are providing a service to a customer, and in this case, the development team and the ones purchasing or using the product are your customers. When the development team becomes a customer and your goal is to provide top notch service to that costumer, your entire mindset and focus changes.

2.       Get buy-in from your development team as to their expectations: In smaller companies, the development team may be only slightly larger than the test team, and therefore may be just as harried and under intense pressure to meet deadlines as you are. Make sure that you define your role as clearly as possible, and what you feel the expectations for your contribution should be, and let them say what they feel it should be as well. This agreement may be formal and in writing, or it may be something discussed in meetings or between team mates. Either way, get it out there so everyone knows the expectation and can work to meet or exceed it.

3.       Get over the us vs. them mentality: If you have no idea what this means, congratulations, you work at a company that “gets it”. If you are all too familiar with this mentality, make the first steps to change that dynamic. Testing and development are allies, they both have the same goal, to ship a product that has high quality and that will meet the needs of its customers. No other attitude is going to help that other than development and testing working together to help solve problems. That means any adversarial attitudes should be stopped, and often the adversarial issues come from testing, whether we intend them to or not. Look at the way you write issue reports, or the way you speak in meetings. If you find that you are pointing fingers at developers or if you reread bugs written and you see attitude and innuendo in the writing, vow to change that.

4.       Realize that Test Tool decisions may mostly be yours: most Lone Gunfighters are in this position because the approach to quality or testing is relatively new in the life of the product or the company (not always, but that tends to be the case). As such, it’s very unlikely that a structured mechanism for testing or using test tools is in place. This provides both challenges and a great deal of freedom at the same time. Challenges in that a small organization is not likely to spend a lot of money on a proprietary test tool (though some might, if you are exceptional in using it and can make a strong business case as to why that tools might be the way to go). They might, however, be very open to using open-source tools. More often than not, though, there may be no tools at all in place, and this may be a great opportunity to explore and implement tools you already know or, barring that, have a hand in recommending what the group will use going forward.

5.       Accept that you will not be an expert in everything: You will have knowledge gaps, and at times those gaps will be huge, but you have to make a clear assessment of your strengths and weaknesses and put them out there. Yes, make them known, the strengths and the weaknesses. Also, make a game plan to overcome those weaknesses where possible and telegraph the fact that you are working to close those gaps.

6.       You won’t have time to do everything: This is just a fact when you are alone in your efforts. Testing of multiple products, setting up multiple priorities, writing multiple test plans, working on automation, creating new test environments and keeping them up to date, all of this has to be juggled and maintained. It’s not possible to do it all, or more accurately, it's not possible to give all the same priority at the same time, but it is possible to have your stakeholders know what you can do and when. My simple and old school method of this is a white board on my wall that faces out to everyone in the hall, along with what have become known as my “Morning Declaration” and my “Evening Update”. The “Morning Declaration” is where I let my stakeholders know what I have planned for that day, and what spheres those plans occupy (testing, documentation, bug database maintenance, environment setup, automation, etc.).  I believe in “thrashing early”; get my plans out to everyone as to what I am doing and give them a chance to have their say. Once that’s done, barring a major catastrophe, I stick to the plan.

7.       Find an outside mentor: When you are Lone Gunfighter, you may be able to find someone who can help you in the development group, but often they may have limitations as well (especially around testing questions and issues). Reach out to other testers you have worked with and ask questions (within reason, these people have jobs, too J ). I still have mentoring relationships with friends who were instrumental in my development over the past 20 years, and I also occasionally get asked questions as to something I have experience in. I believe it’s important to have a mentor and to be a mentor, so look for opportunities where this can be utilized. Fortunately, in this day and age, sites like LinkedIn, uTest and others have communities where testers can reach out to other testers and get some advice on a topic or area where they are not necessarily an expert (and when you are a Lone Gunfighter, that situation happens a LOT of the time). What’s very cool about our community is that we tend to help one another; it’s rare that you will get snubbed for asking a question (it helps of course to do your own homework first, and narrow down to specific questions where possible, but if you’ve done your part up front, most testers are more than willing to help a fellow tester out).

To my fellow “Lone Gunfighters”, I feel for you, and I understand the occasional loneliness of your role. Nevertheless, realize that you are a critical element in the success or your endeavor, and in many ways, you have the potential to become “the indispensible one” where you work, as well as the one that the team ultimately grows around when the situation and growth of the company calls for it (and if you actually want to go that route; some Lone Gunfighters deliberately make careers out of being exactly that). For those who are Lone Gunfighters, what have you found to be your biggest challenges, and what have been your best ways to deal with them?

No comments: