My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #13: Understand the business model and business challenges/context before determining the testing challenges. Its not all clicks and buttons. - Mohan Panguluri
Over the years, I have worked for a variety of companies and with a variety of organizations. Each has had different goals and needs, and have been part of different spaces and industries. During my software testing career, I have worked for a very large networking company (and during my tenure watched it go from a relatively small networking company to one of the world's biggest), a company that made virtualization software, a company that specialized in touch devices and peripherals, a video game publisher, an immigration law software application developer, a television aggregator, and a maker of social collaboration tools.
Were I to have approached my testing in each of those places in a "cookie cutter" way, there is no way I would have been successful across the board (it's likely I might not have been successful at all). Each company made decisions that were unique to its environment, and each worked to woo new customers, as well as work to keep current customers happy. Taking the time to get to know those customers and what they want is always a good investment. It also helps guide you on what areas are really critical.
Workshop #13: Take a "Gemba Walk" with Someone in Sales and Support
For those not familiar with the term, Gemba is a Japanese word and it means "the real place". It is used in connotation of "the scene of the crime" or "live from this spot" or "the place of interest", but they all annotate the same thing; here's where the action is. If you really want to understand the business model and what's important, you need to go where the action is. In most companies, the "action" is in Sales and Support. They deal with both sides of the business. First, the sales people are the ones selling. They have the ear of both the current and potential customers, and they know very well what is bringing people to part with their money, as well as what is needed to keep them happy and active customers. Second, the customer support people know intimately well what is causing customers discomfort. They also know which issues are tolerable, and which ones are deal breakers.
Taking a "Gemba Walk" means to go and explore what's going on in these critical areas. See if you can spend part of a day with the people in sales (preferably multiple people, if possible). Be there to observe, listen in on calls, take notes, and see where your learning takes you. Don't go in with set expectations or an idea of what you want to discover. Additionally, spend some time as well with the support team (multiple people, if possible). Sit in on calls if you can. Take notes of what you experience. Like with Sales, do not go in with predetermined questions or expectations. Be open to what you learn,
After taking these walks go back and read what your documentation, marketing literature and company website have to say. If the materials you have support what you have seen on your Gemba walk, that's a good place to be. If you're marketing and website materials are not reflected in the Gemba walk, I recommend you give priority to what you see and hear on the Gemba walk. The marketing and website literature may be idealized. The Gemba Walk will reflect reality.
With the insights these sessions give you, take a look at your overall testing strategy. Do your testing efforts align with the reality of your business model, the *REAL* business model? Do you understand what the real goals and the real risks of your organization are? Based on what you have learned from Sales and Support, what would you want to change and do differently with regard to your testing?
Companies tend to put their best foot forward when marketing themselves. They also tend to cherry pick the feedback they get from their customers and share with the public. They may share a bit more with the development team and with the testing team, but we should not be surprised when they don't go out of their way to share more than the peaks of the highs and lows. Many important and under served areas often go unrecognized because they are in that indeterminable "middle" area. Those issues in isolation may not rise up to be seen as threats. When taken together, and examined with a different perspective, patterns may emerge that can highlight risks that we don't consider. Just because they don't rise to the level of "urgent", doesn't mean they aren't important.
Sales and Support have vital information, but they may not be sharing it because no one has really expressed interest in understanding it in a way beyond quarterly targets and trouble ticket resolutions. These are both areas where a keen tester could learn a lot, and possibly cause them to dramatically change where to focus time and attention.