The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
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 #82: Go to non-testing technology events - Rosie Sherry
We have a thriving community, but it's a small community, all things considered. There are a handful of software testing conferences when taken as a whole. There are considerably more e could be attending if we take into account programming conferences (of a broad variety of languages), web development conferences (and those related to particular platforms) and other interesting disciplines (mobile, maker, scientific, etc.) and that's not even considering the proliferation of Meet-ups that take place around the world.
There's another aspect to this, in that many of us who are active in software testing circles look to share a message about the value of focused, controlled, sapient testing that emphasizes human judgment and smarts. When we attend our own conferences, even with the various quarreling factions in our own sphere, we are mostly "preaching to the choir". When we venture into other venues, we have a different audience who can hear our message that otherwise would not.
Workshop #82: Choose five events in the next three months (regional conference, peer conference, peer workshop, Meet-Up or hackathon). Go in to see how you can learn to enhance your testing through what you learn and how you can spread the word about better testing in these various events.
In my own back yard, so to speak, there are hundreds of meet-ups that take place. Most of these do not have a direct focus towards software testing, though there are a few that do s. peripherally. I attend several of the local Meet-Ups that have a testing element to them (San Francisco Selenium Users group, San Jose Selenium Users Group, East Bay Agile Software Group, San Francisco Web Performance Group, etc.). Just with those four mentioned groups, I could attend a different Meet-Up just about every week. I learn a great deal from these groups, but to tell the truth, I often learn more when they discuss topics outside of software testing than I do when I attend sessions that are directly focused on testing.
Some might feel that going to a coding meet-up or event will be a wast of time because, well, they are not a "programmer". This is a narrow view, and if I can make any recommendation, try this. Pick a Meet-Up or an event that's close to you, preferably one that doesn't cost anything but time or travel, and go in asking the following questions:
- Why would this particular event be interesting?
- What might I learn that could help me better my testing?
- Who might I meet at this event that might be able to help me or be a good resource in the future?
- What would happen if I actually applied this technology or approach to my efforts?
- If I were to speak to these people as a group, what would I talk about to them?
Let me give an example from my own work-a-day world. Back when I first joined a small Agile shop in 2011, I knew next to nothing about Ruby, Rails or the ecosystem that informs and powers it. I had been participating with the San Francisco Selenium Users Group in San Francisco because I was a direct user of Selenium, and figured that would be sufficient. Over time, though, I discovered that there were several groups dedicated to Ruby, Rails, learning groups dedicated to the family of utilities that make up the greater Ruby metaverse, etc. By going to each of these, I was able to learn a lot more about the underlying stack I was now testing, as well as see alternatives or ideas that I wouldn't see if I just relied on the input of my development team.
One of the things that I do when I attend these events is, if possible, I check to see if there is WiFi and access to the Internet. If there is, I make it a point to announce that I will "Live Blog" the session. This has a number of benefits. The first is the fact that I have put "my community" on notice that I am going to do something that they can follow along with in semi-real time (seriously, just about every paragraph or two I hit the Update button ;) ). This also requires me to treat the event like I'm a live correspondent, and it's a "breaking news" story. It forces me to pay close attention, and to distill the ideas as I am hearing them, and give my own impression. To this end, I deliberately avoid trying to use a "Live Blog" as a way of "taking notes". Yes, I am doing that, but more to the point, I'm trying to give my take on what I am hearing, seeing and learning. This pushes me to make a connection. It mens I have to make a point as to why this event matters to me!
One point to consider when you "Live Blog"… ask first. Sure, it's common for people to Tweet small points from events, but Live Blogging is a lot more encompassing, and in that capacity, some may feel that you are taking content that's been prepared for a privileged group and sharing it too broadly. To this end, if I have been invited to attend a workshop that people have paid to attend, I treat the primary content of that workshop as more private than I would a free event. Those who paid to attend this event have the right, in my opinion, to have the key details of that event be for them. I will certainly talk about the broader topics, and my impressions of them, but I will not go into as much details in those circumstances.
Bottom Line:
There's lot of things we can learn that can inform our testing from places we might not initially consider. Additionally, technology events need not be the only place we learn and make breakthroughs in our testing. Discussions about philosophy, psychology, education, astronomy, science in general, and many other areas can help to give insights. The important thing is to go and look for them. The phrase "when all you have is a hammer, everything looks like a nail" is good advice much of the time (i.e. broaden your toolkit), but here I am really asking you to use a hammer and take it to different places with the point of finding nails. In this case, the hammer is the question "what can I learn here that will help make me a better tester, and will help me develop better testing?" The nails… well, you'll just have to find those for yourself ;).
No comments:
Post a Comment