Question the Way You Work Everyday: 99 Ways Workshop #6

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 #6: Question the Way You Work Everyday - Kinofrost

Sometimes, it's easy for us to think that things are set in stone, that we cannot really change things We don't have a voice or the authority to change up what we do. Generally speaking, unless you are an inmate in a penitentiary, that is not true. You can do things to change the way that you work and the way that you are perceived in your workspace. What is usually the case is that you (and me), like many others, are waiting to be given permission to make a change. Stop it! You don't have to ask permission. Asking permission is anathema to being a tester ;).

Workshop #6: Add Some Disorder To Your Day

Pick a project you are working on. Consider its protocols, its "essential elements", its mandated deliverables, whatever process exists to do what you need to do to complete the job as it's defined. Got that? Cool. Now, for one day, look at every single protocol and rule, and try to subvert it. I don't mean break the law, I mean try to see if you can either change up the way you do things, or, if you believe you can be effective in chucking something entirely, do so… but make notes of what you do in their stead.

For many years, I had a spreadsheet, and that spreadsheet was an ironclad "do this, do this, observe this, mark yes or no". It was a totally by the numbers thing. I had to turn this sheet in every day, and it was reviewed and commented on by the lead tester. It was efficient. It was accurate. It was also soulless and joyless. One day, I decided to simply call a personal mutiny. I decided to drop the spreadsheet for a day and see if, by ranging into different places and ignoring the set script, I could discover something interesting. Often, I did, and often, the things I discovered actually were game changers. I would then go through and look at the "canned script" and see what areas I covered and give the yes or no, and sure enough, what I found was often not part of the specified test cases, and would not have been found by the set test cases. 

Occasionally, I'd be told "that's out of scope, do it by the book", but over time, as I found other interesting oddities, and continued to do so, I was able to demonstrate that some "exploration" was more valuable than following the mandatory checks (note: at this point in my career, I don't think that the term "exploratory testing" was known by many, but that's definitely what I was doing).  

Think about the way that you write bug reports. If you walked in blind, would you be able to tell what's happening? Could you recreate the issue described? If not, how could you change what you write to be more effective?

Have you ever thought to yourself "This would be a cool tool to use to (fill in the blank), but our infrastructure is so different, I don't see a good way to integrate that into our environment"?

Interestingly, the last one was something I was discussing with our development team today. I was telling them that I was exploring some open source tools for doing security testing and load/performance testing. The problem was that the tools used different languages than we were using. I was afraid that any tests I created would exist on their own little islands, so maybe they weren't worth the time to dig deeper. I just figured that that was the case, so it didn't make much sense for me to talk about it further. I did bring it up with my Director, though, and mentioned that I thought they might be novel things to look at. 

During our group meeting, said Director brought up the tools I was talking about, and my perceived "shortcomings" as far as them working in our environment. One of our developers said "Hmmm… that might not be so hard to implement after all. Since we use Jenkins to do a lot of our CI and functional tests, Jenkins can scaffold just about anything. Let's take a lot later and see if we could work those tools in". After I showed him what I was considering, he said "Oh yeah, that's no so out there. We could definitely explore this!"

Bottom Line:

As testers, we are trained to ask tough questions of the products we interact with, and the methods and tools we use. We should be just as willing to ask the tough questions when we "test" our own organizations. If something seems odd, out of place, wasteful, or less than helpful, we should be willing to experiment and see if we can do better with something else. Perhaps it really is the best way, but I'm willing to bet, a lot of the time, thinking differently and approaching situations with a different point of view will prove to be very enlightening, both to you and the organization. There is, of course  a danger if there is politics or status associated with some decisions and policies (and a sense of losing face for an individual if your changes are implemented), but even then, it's possible to start changing hearts and minds a little at a time. Be willing to "think different", but be prepared to show how your different thinking is better than what's already in place. It's possible you won't be able to… then again, maybe you will ;).