When I was a teenager, I wanted to learn how to play guitar. It was something that really appealed to me, and was influenced by my love of a variety of bands and guitar players, most notably Ace Frehley of KISS and, later, Eddie Van Halen of, well, Van Halen. Truth be told, while I learned a bit of guitar, I discovered it required a dedication and a commitment to playing that meant, every day, I’d be practicing, and I’d have to put in a lot of time to get genuinely good. The heart was willing, but the teenage mind can be a very fickle thing. Needless to say, my dream of becoming a virtuoso guitarist was not met, then nor now.
What I did manage to do, though, was develop a little repertoire of cool licks and some exercises that were fun to do. I mastered a few dozen chords and the framework in which to play them. Part of that framework was a little exercise I’d do every time I picked up a guitar to allow me to get back into the groove of playing again, even after a long layoff. It consisted of a series of minor chord arpeggios that I moved up and down the neck, with a quick turnaround at the end. Truthfully, this wasn’t all that difficult to do, but it sounded pretty cool; like a cross between Spanish classical and Flamenco. To uninitiated ears, it made them think I was much better than I really was. Later on, when it came time for me to audition for bands (this time as a singer), I found that I was taken more seriously by some groups because I had some sense of how to play the guitar. I would meet up with them, we’d chat, I’d sit down with the guitar casually, noodle through a few chords, and I would definitely whip out my “Spanish solo”. Almost always, it would get some nods of appreciation, and I’d win a bit of respect with that particular band. Was I an expert? Not at all, nor was I even specifically aiming to be a guitar player in these bands. Having some experience, though, helped me communicate musically in ways that were more productive than if I didn’t have that common ground.
Today, I work in software testing, and I enjoy being a part of it. Some years ago, I made a commitment to learn about how to do test automation. It seemed like an interesting field, and a skill that would be helpful. There were a number of competing ideologies on this front at the time, and since the company I was working with then was using Tcl/Tk, I figured it wouldn’t hurt to get to know some of it. A few months of poking around, copying a few projects here and there, making some modifications to fit my particular environment, and I had enough of a collection of scripts that I could do some real work. Ultimately, as with guitar, the heart was willing, but the brain had other things to deal with. Thus, I was content to use the handful of tricks I’d figured out and put them to use where I could. Most of the time, they were plenty.
What do these two anecdotes have in common? We learn enough to feel knowledgeable, to feel proficient, when in truth we have barely scratched the surface of what is possible. Often, it’s easy to “fake it”, especially if we know just enough to seem like more than a novice. Merlin Mann (of 43 Folders fame) has referred to this phenomenon as being an “Advanced Beginner”. As an Advanced Beginner, we’ve done a lot of copy/paste. We’ve worked through some examples in a few books and collected some simple techniques. Perhaps it’s building a website on Rails, or learning enough PHP so that we can hook up a form and get the data from it. Maybe it’s grabbing a Cucumber testing environment, wired up with enough Selenium and Capybara step definitions, that we can effectively cobble together some meaningful acceptance tests… not like I would know anything about that last example!
Being an Advanced Beginner is that place where we know enough to sound smart and accomplished, but where we can also fool ourselves into thinking we know more than we really do. Much of the time, that’s not a big deal, because there’s a lot of work that can be done from the vantage point of an Advanced Beginner, and no one would be the wiser. Nevertheless, we don’t want to be “Advanced Beginners” forever, do we? We want to break through and get genuinely good at what we do. I certainly would like to become a master at my craft. How do we do that?
1. Declare a “Not Faking It” Policy
Folks, it’s time to come clean. If you’ve been doing just a handful of “licks” (to borrow musicians parlance) or you have a handful of tricks that you use for your testing (you’ve copied over someone else’s Cucumber environment, and it works, but for the life of you, you can’t really explain why), make a list of exactly what these areas are. When you have a successful test, how do you know it is successful? Do you know because you have an assertion that passes, or have you actually constructed a test that uses a good oracle to inform you of the passing or failing state? Does the word Oracle make sense to you (outside of being a large company that makes an enterprise level database, which is not the type I’m referring to here)?
Many testers do very good work, but are totally in the dark as to what they are doing or what it’s called; they just do it. Much like guitar players, there are a lot of self taught testers out there. Many self taught guitar players spend their entire careers never learning how to read music. Many software testers spend their entire careers never learning how to read or understand code. If you want to get beyond being an Advanced Beginner, draw a line in the sand, and say “I know this much for sure”. Make a list of what you genuinely know and can articulate. See where you have trouble making that articulation. Write down as best as you can what it is you think you know. Do you understand the difference between stress, load and performance testing? Can you articulate the context in which you work, and what areas are actually important to your stakeholders? Then write it out. If you find you can’t, or struggle to do so, don’t despair, that’s why we are doing this! You have decided that you are not faking it any longer. You are putting your knowledge to an objective test, and you are both declaring your competence, and you are also declaring your ignorance.
2. Start Looking For Ways to Remove That Ignorance
Ignorance is such a loaded word. It has such a stigma, and frankly, it shouldn’t. We are all ignorant on a great many things. In fact, the things that we are ignorant about will probably outweigh the things that we have competency in by about 50 to 1, and that’s being kind. Questions about particle physics, biomedical engineering and the finer points of financial markets? I am perfectly willing to state that I am deeply ignorant on these subjects. There are also several dozen programming languages out there that I honestly have never seen a line of code from. This is not such a big deal… until the day comes that I need to do testing in those spheres. At that point, I will very much need to start filling in those gaps of knowledge (Ignorance) and become as effective as I possibly can be.
Let’s think about that guitar. It’s a good chance that you (the guitar player) may know the five primary open chords (C, A, G, E, and D). Were you aware of the fact that these chords, in all cases, ran up the neck of the guitar? With practice, you can play any chord in any position of the neck. With a little modification, you can also play all of the minor chords, as well as a number of others. What’s more, you can build solo patterns around where these chords reside on the neck much more easily.
As a tester, what if you were to sit down with The Cucumber Book or The RSpec Book, and build from scratch an automation framework? Yes, it’s tempting to go and grab all of the examples from other projects (we already know they work), but just like the guitar player who makes that “a-ha” moment when they discover how “CAGED” can open up the fretboard, think of that “a-ha” moment for you when you decide that, through stepping through and building an environment from scratch, you really understand what goes into the statements, and the process of Behavior Driven Development the way programmers actually work with it. Programming not your thing? How about opening up the Cem Kaner, James Bach and Bret Pettichord book “Lessons Learned in Software Testing”? Think of any number of aspects of testing you might want to learn about, such as context, oracles, domain testing, scenario testing, or any other aspect of testing that you may have trouble putting words to. This book is especially helpful, since it’s presented in small lessons format. Open the book to any page. It’s a good bet you can learn something you didn’t know before, no matter how many years you’ve been a software tester.
3. Find People to “Jam” With
During my musical career, I didn’t need to rely on my guitar skills to land a gig with a band; I could do that based on just my voice. What guitar skills I did have, I was able to use to communicate to others the feelings, the chords and the ideas that made the melodies that interested me. I could also help them understand what I was looking for as we shaped songs. The positive side, I was able to communicate a lot of good ideas that made their way into our songs. The down side? I wasn’t able to write very many songs all by myself. Sometimes, that was OK, but often, especially when I was between bands, it was a struggle to put more songs together and make them coherent because I didn’t have “those extra musicians” I could jam with.
How about in our testing spaces? What are we doing today to foster “jam sessions” with other testers? How do we know what we know if we don’t challenge what we actually do know, and how well we know them based on our peers, and what they do? Frequently, musicians will get together and jam just because it’s fun, and because they can learn something new from each other, no matter the skill level. Testers can do the same thing. One of the formal ways we can do it is through Weekend Testing (http://weekendtesting.com). I will admit, I’m a little biased and self serving here, because I actually facilitate Weekend Testing sessions here in the Americas. It’s a great way to spend two hours, tackle an interesting testing challenge, pair with other testers, and perhaps learn something new. Even if you don’t want to commit to a formal gathering, head to a local pub or gathering place and have a get together to play games like SET and talk about how those skills apply to testing. There’s a lot of room for learning, growth and getting to know your fellow testers better. If you can do it in your own organization, that’s great. If you need to reach outside because there aren’t very many testers in your organization (or you may be the only one), then do that.
4. Do Not Be Afraid to Ask “Stupid Questions” I get it, really. Many people would rather crawl under a rock and hide than admit, publicly, they do not know something. We’ve been trained since we were young to believe that, if we didn’t do well on the exam, that we were stupid, and if we asked “Foolish questions” we’d be branded as idiots. Thus, we stayed quiet, rarely sticking our neck out and asking those dumb, wonderful questions that can actually help people know where we really stand. So you understand a bit of Ruby, Cucumber statements are an easy thing to grasp, but some of the language used with Capybara just escapes you. What’s the relationship necessary to read in a table’s worth of data? Is it possible to put variables into assertion tables in our Scenario Examples? We can’t fix our ignorance unless we openly admit that we don’t know something. Stop being afraid that people will think that you are dumb. If they do, so what? If you can learn how to get over that particular hurdle, then awesome, you aren’t “dumb” on that point any longer. To be more accurate, you have cleared up some “ignorance”, and frankly, that’s a great thing! It means that the next area you deal with will be more challenging, more advanced. Pretty soon, you’ll start asking questions that, possibly, no one else has thought to ask before. Quite possibly, you might be asking questions the programmers on your team might not even know the answers to. Look out for these moments, because it’s here that real organizational learning can take place. We just have to stop being scared of looking foolish. Maybe we will. Of course, the only real way to look foolish is to not ask until a crisis occurs, and then we have to admit that we are where we are because we didn’t have the courage to ask a “stupid question”. Now that’s foolish!
Get out there, make connections, make some time to jam, make some time to learn some new “licks”, but most important of all, stop faking it! Own up to what you do know (which may surprise you), and what you don’t know (which may likewise feel overwhelming), but commit to it. Own what you know, learn what you don’t, and make it a daily practice, both on your own and with others. Will you ultimately become the Eddie Van Halen of testing? That I can’t promise, but one thing is for sure; the more you put in to building your craft, the more seasoned and polished a pro you will become, an then you won’t have to fake it ever again… until the next gig, of course :).