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 #92: Hang out with developers, designers, managers – Rosie Sherry
This is a great piece of advice in general. We learn a great deal about our role as testers when we have a better understanding of what other people do in their organizations and roles. What matters to them, what pressures they face, the issues that are unique to their spheres, all of these can give us a better view and frame of mind to help us approach how we test.
Beyond that, though, is the potential for knowledge transfer and skill acquisition. Ever wonder why certain tags and attributes are used on the web site you test? You could look up those tags, or you could ask your front end developers why they choose to use what they do. Ever wonder why certain features seem to outweigh others, but you can’t understand the rhyme or reason as to why? Talk with the project and product managers and see what they are dealing with. If you are interested in learning a new programming language, you could read up online about it, or you could go attend a Meet-Up related to that language, meet some people who attend, and ask them what makes it a good choice (or not, believe me, programmers are happy to share both the good and bad about what they deal with).
Workshop #92: Make a plan to do several “gemba walks”. Each of them should be in a different place in your organization, or in a different aspect of what you want to learn more about. Attend team meetings, talk to individuals, join and attend meet-ups related to the skills and areas (UX, programming, management, lean coffee, etc.). Try to see how what you learn from these experiences can add to your ability to test more effectively.
As I mentioned in a previous entry, “gemba” is a Japanese term that means “where the action is”. therefore, the best chance for you to learn what developers, designers and managers know, need, fear, and aspire to is to go where they actually do their work. Some basic ways to do this are as follows:
Pair with a programmer regularly if the opportunity arises, or make opportunities that are beneficial to both you and the programmer. One great way to do this is to see if you can focus on a story together in the early stages of it being programmed, or to collaborate on automated tests you have decided need to be created.
If you want to see what is important to project managers, ask to get on their calendars as they are looking to scope out new features that have been requested. Offer to sit with them and brainstorm approaches and ideas, letting them lead the way while you ask them questions. As they are scoping out ideas for features, you can also make suggestions that will help with testability, or give some suggestions that will help broaden (or narrow) the focus of a feature so that it can be more easily implemented, described, and yes, tested :).
Find out who the managers are in various capacities in your organization, and make the point that you would like to learn more from them as to what is important for organizational success. This doesn’t have to be a formal meeting, it could be a lunch break, or a visit to a local pub after work, or in some other capacity. The point is, get to know what these managers are doing, and why they need what they do to be successful. Be open and honest about your intentions. Also, be persistent, and be the one to make the invitation, and do it regularly. You may notice at first that “oh thanks, but I’m too busy” is often the first response. That’s OK, but follow up and ask again, and again. Usually, the response will be “Oh, OK, you’re serious about this. Um, sure, how about Friday for lunch?”
Barring any of these (it’s possible that you work remotely or in a way that you can’t directly access the people you’d like to talk to), go the Meet-Up route. I am blessed to live in an area that has an embarrassment of riches when it comes to structured meet-ups of every imaginable type. Sure, getting together with my team of developers is effective, but if none of them are working with the language I’m interested in learning more about, then going external is necessary. Same goes if I want to learn more about Lean Startups, mobile applications, User Experience, or software management. Another benefit to the Meet-Up approach is that you can see what other people value in their organizations, and see how other people tackle problems that may inform the ones that you have.
We can learn a lot by reading, experimenting, and trying things out on our own, but ultimately, our success depends on the organization as a whole being successful. The better we understand the unique challenges other groups face, the better equipped we will be to target our testing to the areas that have the greatest risk (i.e. those ares that each groups feels are the greatest risks to them). By getting a feel for and an understanding of what each group does, actively tries to accomplish, and yes, even secretly or not so secretly fears, it is possible to focus our attention and energies on the areas that really matter to a broad and diverse set of stakeholders.