Using Exploratory Testing Skills to Learn Programming

As an exploratory tester, I specialize in learning with an application. I sit in front of a computer, read a bit if that feels the the right fit and very quickly I move from the theory of what documentation says into hands on, using whatever I’m working with right now.

Since I test, the thing I’m learning is often an application. It may come with documentation, “stories” and “specifications”, but all of that is promiseware. The reality of what is there is to be found through use of the application. And it’s not just the application, but the application in the environment of use, user included. With whatever unique characteristics I choose to intentionally or serendipitously include in.

I’ve been testing applications a while, and decided that as I know embark on a journey to deepen my understanding on many fronts, so blogging seems like a match. I’m learning leadership and managing teams of developers&testers, more techniques to exploratory testing, and programming.

As someone who values learning through exploration, I find myself taking that very same approach to learning new tricks around programming. I read a little, try out a lot more, track what I know and don’t know and move forward on paths I did not foresee as I was starting but that emerged. I know what I’m trying to learn to be able to do, I have a sense of purpose with first getting something to work, then cleaning it up with others, and ensuring that the future me can also work with what the me of today was creating.

As learning programming is doing programming, and learning by doing is exactly what I’ve been doing as exploratory tester, I stop to think about what is the difference in exploratory testing and other exploratory activities. With any activities, learning is at the core. With testing, learning about information to share with others is at the core.

Programming can include testing as long as the bar is where the exploratory tester in me sets it. The programmer in me often sets the bar where things appear to work. The tester in me drives the programmer in me to not stay with the first solution, but bring in perspectives of what may or may not be sufficient.