I couldn't leave that last blog out there, so negative, without the happy side.

I'm a strange tester because I don't like working alone. Collaborative testing is one area that I'm always researching, experimenting with, and trying new things with. One of my dreams is to some day make a valued contribution to this type of testing. I keep trying my ideas, and some of them fail, and some of them are works in progress, but one made it out into actual practice.

One of the days that I remember the most was the day my manager agreed to let me try out a crazy testing idea with other participants! I really want to go into detail about this idea in my blog, but I haven't been cleared yet to talk about it.

What I learned from sharing my idea and involving other people was that not all people who test imagine things visually inside of their head. Many testers understand what they are testing only in words, and pictures confuse them. Some people will look at an idea I've drawn or represented visually and say, "Oh! Now I understand", and the person next to them is staring at me like I'm some sort of fraud who came up with an idea that will never work. If I take the same information and write it out in a list with levels, the second person says, "Why did you overcomplicate this idea? Now it makes sense and I'd be willing to try it." This was earth shattering news to me. Some people are terrified of a big picture and resent those who try to present it. Not because they disagree with your view of it, or question it, but because they feel overwhelmed by it and don't feel that they should need to see it to get the job done. I was hoping that those giving me feedback were just going to argue about how I hadn't been complete in my representation, or that they disagreed with the content. I was shocked to find that seeing everything at once was a barrier to understanding for many people.

I've done some reading on learning styles, personality types, leadership, change, change resistance, introducing ideas, and different ways to visually represent data since that day. I now realize how easily a great idea can be killed by the wrong reprensentation, and by assuming that other people think like you do. Luckily, this idea wasn't killed. It was seriously reformed and more chances were allowed. It still lives in a small and very altered form.

The second "best testing day ever" was really a 2 day period of time. I kept corrupting documents while testing, but was unable to get a fix because once the corruption existed, the data was unrecoverable, and no log data was helpful enough to debug the issue and create a fix. I believed that I could find a way without an 87 step bug report to recreate the issue. I worked until 2am and the closest I got was providing a document and two further steps to corrupt it. I was very proud because I felt that it was a great bug, and it was the most difficult test of my bug isolation skills to that date. The reason why this bug was the best bug ever for me was that the developer who fixed it explained to me exactly why it happened and showed me the problem in the code. My bug isolation has never been the same since that day. I think back to that day I remember, I don't know where all of the boundaries are even if everyone involved thinks they have been clearly communicated. Random bugs most often never are really random. If the bug is really important, I have an obligation to find that boundary and continue improving my isolation skills. One dev taking 10 minutes made me a better tester. I am very lucky to work with people who are willing to invest in my learning. I hope to be such a person for other people.