A TESTHEAD ST&QA Double Play :)

     In the October 2011 (Vol. 8 No. 5) version of ST&QA Magazine, I get to have a double play :).

     First, this issue is dedicated to the release of our book "How to Reduce The Cost of Software Testing" (available from both the Publisher, Taylor & Francis and from Amazon) and there are a number of stories that are focused on the topic. Many of them are all new material that was written after the book had wrapped. The cover story, coolly enough, is an excerpt of my chapter (Trading Money for Time: When Saving Money Doesn't (and When It Does).


Second, and really humbling is a piece called "What is the Cost of Testing?" in which Rich Hand interviews, well... me! We had a great conversation a while  back, and only about 50% of it appears in the article. Rather than structuring it like an interview, it's a narrative with many of my thoughts interjected. Maybe this is a better approach; Rich was able to edit out areas where I probably rambled a bit (LOL!). Still, I think it's an accurate and representative piece, and I'm happy to have had a chance to be a part of it.

So for those interested in getting a copy ST&QA, go to the SoftwareTestPro.com site and download it, or you can read both the Cover Story or my Interview right there on the site. If you do, please leave a comment or two, I'd love to know what you think :).

Exercise 3: Numbers And Math: Learn Ruby The Hard Way: Practicum

Performing calculations is an important part of any programming language, and Ruby is no exception. Many people have been led to believe that to be a computer expert you have to be a mathematics expert (and Computer Science and Engineering requirements certainly don't dispel that rumor; it's a lot of the reason why I have an I.S. degree rather than a C.S. or E.E. degree ;) ). Still in many instances, the math that is performed is actually pretty straightforward. Most of the math symbols will be perfectly familiar to anyone who has done any kind of programming in the past or even worked with Excel.

For the first exercise, Zed has us saying out loud what everything is. It helps to know what these things are so when you mention a "modulus" character to another programmer, or them to you, you know what it is :).

And here we go...

+ plus [performs addition]
- minus [performs subtraction]
/ slash [performs division]
* asterisk [performs multiplication]
% percent  [provides the remainder of a division, i.e. the modulus]
< less-than [what's on the left is less than what's on the right]
> greater-than [what's on the left is greater that than what's on the right]
<= less-than-equal [what's on the left is less than or equal to what's on the right]
>= greater-than-equal [what's on the left is greater than or equal to what's on the right]

The first thing to do was to tell what the operations were, fairly straightforward [see above]

Next, let's get gedit and ruby in to the game:


 1 puts "I will now count my chickens:"
 2
 3 puts "Hens", 25 + 30 / 6
 4 puts "Roosters", 100 - 25 * 3 % 4
 5
 6 puts "Now I will count the eggs:"
 7
 8 puts 3 + 2 + 1 - 5 + 4 % 2 - 1 / 4 + 6
 9
10 puts "Is it true that 3 + 2 < 5 - 7?"
11
12 puts 3 + 2 < 5 - 7
13
14 puts "What is 3 + 2?", 3 + 2
15 puts "What is 5 - 7?", 5 - 7
16
17 puts "Oh, that's why it's false."
18
19 puts "How about some more."
20
21 puts "Is it greater?", 5 > -2
22 puts "Is it greater or equal?", 5 >= -2
23 puts "Is it less or equal?", 5 <= -2

[see below]

What You Should See

$ ruby ex3.rb
I will now count my chickens:
Hens
30
Roosters
97
Now I will count the eggs:
7
Is it true that 3 + 2 < 5 - 7?
false
What is 3 + 2?
5
What is 5 - 7?
-2
Oh, that's why it's false.
How about some more.
Is it greater?
true
Is it greater or equal?
true
Is it less or equal?
false
$

[yep, that is indeed what I am seeing]

Extra Credit

Above each line, use the # to write a comment to yourself explaining what the line does.
[see below]

Remember in Exercise 0 when you started IRB? Start IRB this way again and using the above characters and what you know, use Ruby as a calculator.

[see below]

Find something you need to calculate and write a new .rb file that does it.
[see below]

Notice the math seems "wrong"? There are no fractions, only whole numbers. Find out why by researching what a "floating point" number is.
Rewrite ex3.rb to use floating point numbers so it's more accurate (hint: 20.0 is floating point).

[see below]

TESTHEAD's TAKEAWAYS

It can be tricky to know what gets worked on first with a string of characters and no designation. For me personally, I like to use parentheses even if the system is smart enough to figure them out (the system might be, but I want to know it's doing what I want it to, so I use the parentheses to keep it straight). Even if we don't use parentheses, the system will use mathematical order of operations to evaluate values, so make sure you are writing them out the way that you intend to... or again, use parentheses if you want to make sure you are calculating the values you think you should be calculating.

Exercise 2: Comments And Pound Characters: Learn Ruby The Hard Way

So the last exercise had us typing in characters to help us understand what lines would be printed to the screen and which ones wouldn't. The character used is the 'octothorpe', aka 'pound', 'hash', 'number key', hey, whatever works for you. The important thing is that wherever it appears, any character that follows on after it doesn't get run in the program. It's used for commenting your code and for disabling lines in your code.


So here's the exeercises as dispayed in the book and what I see when I run them.



1 # A comment, this is so you can read your program later.
2 # Anything after the # is ignored by Ruby.
3
4 puts "I could have code like this." # and the comment after is ignored
5
6 # You can also use a comment to "disable" or comment out a piece of code:
7 # print "This won't run."
8
9 puts "This will run."

[And here it is]



What You Should See



$ ruby ex2.rb

I could have code like this.

This will run.

$

[so far so good]



Extra Credit



- Find out if you were right about what the # character does and make sure you know what it's called (octothorpe or pound character).



[Well, yeah, the pound character, when it is by itself and with a space next to it, acts as a "comment" character. Here's the thing, it doesn't always do that. there are examples where when combined with other characters it means something else, but that's jumping ahead in the exercises]



- Take your ex2.rb file and review each line going backwards. Start at the last line, and check each word in reverse against what you should have typed.



[done, looks clean under the circumstances]



- Did you find more mistakes? Fix them.



[this time, no, I think we are clean]



- Read what you typed above out loud, including saying each character by its name. Did you find more mistakes? Fix them.



[I had some spacing issues and cleaned them up, but otherwise, looks clean from what I can see]



TESTHEAD's TAKEAWAYS



OK, seriously, did Zed really make me just do that? Does he think I'm really that stupid? Well, no... and yes. You see, in reality, we are that stupid, if we are inexperienced or we are not really good typists. We think we have typed our information well. We think we have done everything right, until we actually run the program and it gives us output that we don't expect, or we get an error. By reading the code backwards, we can see if, indeed, we did write what we believe we wrote. Remember, the human brain can make sense out of a lot of static, and it's very helpful when it comes to filling in the blanks and letting us see what we think we mean.


I see this all the time with my own blog posts. I proofread them, sometimes two or three times, only to have another reader spot a glaringly obvious error that I overlooked. Why? Because my brain knows what I mean, and it is more than happy to fill in the blanks. Computers can't do that; they have to be told explicitly what to do, and even elegant layers of abstraction, of which Ruby is, cannot overcome that. If you tell the computer to do something, it will do it, whether you meant to tell it that or not. It doesn't understand intent. So yeah, Zed wants you to proofread even these simple starter programs. You may be surprised how many flaky things you do and do not realize at all that you are doing them.

The Tyranny of Unintended Conformity?

I just finished the Instructor's Course for AST (in an unusual twist of fate, I can now say that I have completed the last step I should have done to let me actually be a Lead Instructor, even though I've already been one for quite some time... hey, things happen ;) ).


Nevertheless, I found it to be a very worthwhile experience, because I had a chance along with several other Instructor candidates (including quite a few I've taught over the past year plus) to reconsider how I "teach" what I know. Many of the things that I do and recommend, I've discovered, have unintended consequences, and I had a chance to see one of them first hand.


Here's an interesting thought. When does a "good suggestion" become a call to conformance? When you repeat it enough. I hadn't realized that something I did as a suggestion to students could actually be used as a blunt instrument and help enforce laziness. What could this be you might ask? My suggestion that people use the question in their answers. How? By structuring their answer around the question. The benefit? In my opinion, it make it easier to see if the question is actually being answered. It also saves me having to jump to another screen to review the question. It's just something that I figured would save people time and effort.


How can this go wrong? When people start using an "unintended metric" to penalize people who don't do it. Nope, that was not my intention at all, but I was shown, convincingly, that it does happen. When people look for a lazy out, this is a great way to do it. When they cannot effectively answer or offer feedback for the merits of an answer, they will instead hack points away because the answer "didn't match the requirement of including the question in the answer"... a "requirement" that never existed in the first place!


Do we find ourselves at times making up requirements that don't exist, merely because we think they would be good? I'll reiterate, I think the idea I suggested is a good one, it can be genuinely helpful to developing an answer and getting the thoughts down in a format that is direct, answers the call of the question, and stays on target and topic. That would be my preference, but I have to draw the line at requiring people to do it the way I would prefer when their way is every bit as good (or maybe even better).


Having a guideline to help with structure and ideas, I think, is a good thing. Having rigid formalism just for the sake of formalism is not my intent, but I can see how asking for something too often will instill the idea that there is a requirement, and then everyone clings to it as though it were gospel. I'm going to look to doing better on that front going forward.


How about you? Do you find things that you think are potentially good ideas becoming rigid rules you never intended?

Exercise 1: A Good First Program: Learn Ruby The Hard Way: Practicum

The whole point of the first exercise (Exercise 0, as befits a computer-centric topic; all arrays start at 0 :) ), was to install the gedit text editor, figure out how to work with it,  run some sample commands in irb, and navigate around the file system and directories. Again, for those of us who were using systems back in the early 80's or earlier, this interaction was the only way to deal with a computer (graphical interfaces would come later). It's good for people to get familiar with these tools because the book is focused on using these tools specifically, and not relying on anything that gives additional help or adds any wrappers.

The first real coding exercise is a simple one, and it deals with one object and the parameters for that object. This program has the user enter a number of "puts" statements. They may all look the same, but some are just a little bit different. Let's take a closer look at the exercise "by the book" (note, all pictures will enlarge if you click on them).

- Type the following into a single file named ex1.rb. This is important as Ruby works best with files ending in .rb.

- Then in Terminal run the file by typing:

ruby ex1.rb

What You Should See

$ ruby ex1.rb
Hello World!
Hello Again
I like typing this.
This is fun.
Yay! Printing.
I'd much rather you 'not'.
I "said" do not touch this.
$
[yep, I have a match :)]

If you have an error it will look like this:

 ruby ex1.rb
ex1.rb:4: syntax error, unexpected tCONSTANT, expecting $end
puts "This is fun."
          ^
[no error this time around]

Extra Credit

The exercises have "extra credit" scenarios, and yes, as I am trying to do these by the book, I will print my extra credit ideas (and yes, you can snicker at them all you want to, or write back to me how lame my approaches are, it's totally cool :) ).

- Make your script print another line.

- Make your script print only one of the lines.

- Put a '#' (octothorpe) character at the beginning of a line. What did it do? Try to find out what this character does.

[See the next to last image and I've added a bunch of octothorpe characters explaining what they do and when they were put in and why. Long story short, they prevent a line from being interpreted by the ruby interpreter. They are good for entering in comments or stopping certain lines from being run.]

So yeah, pretty master of the obvious kind of stuff, huh? The funny thing is, most people do really well this early in the game because, well, it's basic and it's easy and they get bored really quickly. The early going is very simple. Misleadingly so. It's kind of like skiing. Learning how to snowplow is quick and basic and you can learn how to do it in a few minutes and ski the bunny hill with no problems. All feels perfectly normal, until you get on the intermediate slope and realize "oh wow, this suddenly got a lot tougher!" Coding is the same. Don't get complacent in the very early stages, it's deceptively easy, but many important fundamental practices take root here. Pay attention to them and the jump to later programming is not so painful or so abrupt. Work through the simple examples and pay closer attention to why you are being asked to look at these super simple examples.

Exercise 0: The Setup: Learn Ruby the Hard Way: Practicum

So I have two systems that I can play with on this, Mac and PC. Since the Mac version has some limitations that I can't really get around (I have to keep certain versions of the app at the versions installed since I'm runnning an active testing environment in Ruby 1.8), for this challenge I'll be using Windows and using the Ruby Version Manager to install the app.

The first step is to go and get the "gedit" text editor. Why gedit? Because it has little in the way of extra help beyond spelling and language support.

There are some basic tweaks we can make to gedit once we have downloaded the editor, such as setting the tab to 2 spaces, inserting spaces instead of tabs when hitting the tab key, and making it so that the line number is visible. Other than that, there is little in the way of the cool tools that many of the IDE applications have. To tell the truth, I really am starting to like some of the features in RubyMine that I've played with. For these practicum posts, we shall be doing this with the preferred editor (all things being equal).

Here's the steps straight from the Learn Ruby the Hard Way site:

- In your Terminal program, run irb (Interactive Ruby). You run things in Terminal by just typing their name and hitting RETURN.

- Hit CTRL-Z (Z), Enter and get out of irb (actually, it doesn't work this way on my command prompt. typing "exit" or "quit" does exit irb).

- Learn how to make a directory in the Terminal. Search online for help (mkdir LRtHW)

- Learn how to change into a directory in the Terminal. Again search online (cd LRtHW).

- Use your editor to create a file in this directory. Make the file, "Save" or "Save As...", and pick this directory (heh, I edited this blog post in the editor, see below :) ).

- Go back to Terminal using just the keyboard to switch windows. Look it up if you can't figure it out (alt-tab and the arrow keys :) ).

- Back in Terminal, see if you can list the directory to see your newly created file. Search online for how to list a directory. (dir, and there it is :) ).

Warning: Windows is a big problem for Ruby. Sometimes you install Ruby and one computer will have no problems, and another computer will be missing important features. If you have problems, please visit: http://rubyinstaller.org/ (So far so good!)

Ta-daa!!!

OK, admittedly, that was not a big deal, but for many just getting the stuff installed can be a big deal and a challenge if they are not used to packages and gems and running the Ruby Installer, but once it's downloaded, then you have a lot of flexibility in how you can use the tools. As stated, though, I'm going to be as literal as I can be, and you will see the literal details as I see them and as I work with them. If I get stumped, I'll say so. If something doesn't work the same way, I'll say so. Tomorrow, some very rudimentary code, done in the spirit and in the system Zed recommends. My pledge is to do this by the book, and therefore, that's what I'm going to do :).

A New Chapter and a New Challenge

Well, now that it's been announced to the students in the current AST Instructor's Course, I guess their's no reason to not mention it here. While I was in Madison a couple of weeks ago for the AST Board Meeting, one of the orders of business was the need for someone to take over as the Chair of the Education Special Interest Group  (EdSIG) within AST. I'd heard of this need for quite some time, but I kept my mouth shut, because, really, what do I now about Education? I'm not a teacher (well, not really), I certainly don't have any academic credentials, or any fancy title to go with my name. I certainly don't have much in the way of academiese in my vocabulary; I'm much more comfortable speaking "dude".

Yes as I kept think about the situation and the needs, I realized that I may actually have more of an understanding of these things than I gave my credit for. I finished my Bachelors degree, my last two years, entirely online via distance learning courses. I went through 22 online courses of varying quality levels and went through a total immersion process to get the most out of them. Were they exactly like university classes held on campus? Nope, but they had their own interesting challenges, and I'll dare say I learned quite a bit from all of them. I realized that this experience dovetailed well into the way that AST delivers the BBST Classes through online facilitation.

What's more, I was one of the few people who has taught Foundations and Bug Advocacy, and was participating in the pilot program of the Test Design class (which starts next week, btw, and yes, I'm excited to be participating in it :) ), plus I'm scheduled to help teach the March session of the Test Design class. Who else could say they've been teaching all three of the classes (well, OK there's a couple others, but I was one of them)?

As I mulled these over in my head, I decided to do something brave or crazy... time will tell on that one :). By the time we reached the end of the discussion, I decided that there needed to be a Chair for the EdSIG... and if no one was going to step up to the plate, well why shouldn't I throw my hat in the ring? So that's exactly what I did, an for better or worse, the board accepted my offer :).

So over the next few months, I will be learning the ropes of what the EdSIG entails, but most specifically how to administer and run the BBST course series for AST's members and participants. That's a big chunk of where my involvement will be, and due to that, it means my direct involvement as a regular instructor will likely diminish (though I'll still be involved with all of the classes). What this does mean is that there will be a need for more instructors to help teach. We have a fresh cadre of newly minted Certified Instructors for courses, and it's my hope that they will step into the role of helping teach the upcoming classes in 2012. It's also my hope that many of you out there will consider taking the classes if you haven't already, and help me to deliver the best software testing training to be found anywhere on the planet (that's a bold boast, I know, but I happen to believe it :) ).

Why the Hard Way is Easier: Learning Ruby the Hard Way: Practicum

Why the Hard Way is Easier

Zed starts out by explaining that this was the way all programming was done before the copy-paste from electronic sources became so common. People took a book, put it next to their keyboard, and physically typed out the examples. To make this successful, you have to type it exactly and get it to run. No shortcuts, not philosophizing, no copy-paste. Zed also makes very clear that this is a foundational book and approach. Will you learn all of the ins and outs of programming by doing this? No, but you will develop some solid Foundational chops to build on going forward, and that's really the goal. LRtHW aims to teach three things, and from an Adult Learner's perspective, these are not emphasize enough (I'm sorry, I can't use words like "Androgogy" in a sentence and keep a straight face. Maybe that's my failing). Those three things are:

- Reading and Writing
- Attention to Detail
- Spotting Differences

Reading and Writing

This is the point of physically typing in the sequences of characters. Some of them are weird. Some of them are not common for people to use in their every day communication. that's why the idea of not copy-pasting is so important. You have to do it with an eye towards repeating every character so you can appreciate why those characters are being used. there is a reason. Physically typing them gives your brain that brief but ever important option to say "hey, why are we using that?"

Attention to Detail

By typing in everything exactly, we will likely not type in exactly what we think we are typing in (still with me on that?). The simple fact is, we are not as careful as we believe we are. Our brains are very helpful; it works to help us tease meanings out of things we have familiarity with, and when we make a mistake, it's very helpful in working to get around the error, so much so that w don't really notice if we make a mistake. Fortunately, run time engines and compilers are notoriously picky; they know what they can and can't interpret, and erors help us start to see what we may have missed or typed incorrectly.

Spotting Differences

IDE's have lots of tools to help a programmer spot the difference between two code examples. This book expects users to see them with their own eyes. It's a skill that's important to develop and very helpful in the long run (let's face it, sometimes the IDE isn't even an option when you are debugging a remote server that is exhibiting problems, so best to not entirely depend on them).

Do Not Copy-Paste

Again, copy-paste is tempting, but Zed solemnly warns that users will not get the benefits if they just copy-paste the code. The tedium, the time spent typing all of this out is like building muscles. There's simply no way around putting in the repetitions necessary to fatigue (and thus make stronger) the muscles, whether they be in our hands or our minds. Read, Understand, Apply Persist, Achieve. It works for the Hardgainers in Bodybuilding, it should work for the Hard-gaining Programmer's, too :).

A Note On Practice And Persistence

The first time I stepped on a snowboard, even though I'd ridden skateboards for much of my life, it was a foreign thing, an my body didn't know how to do it. For several hours, I fell repeatedly, I could barely manage to keep upright, and I was nothing like the graceful kids who were trucking past me effortlessly  But I kept at it, and then, at some point, it clicked. I found that magic place where my balance and center of gravity made sense. I was able to do rudimentary turns, and after a few days I started to get to the point where I could handle steeper terrain, some jumps and other aspects of the sport that just a few days earlier seemed impossible. You don't reach this point without putting in the time.

I've gone through several programming boks and dabbled in several languages, so why wasn't I a proficient programmer afte all these years? Because of two things. First, I used the languages to do what I needed to do an then when I had those tools in place, I just used the tools. The net result was that I had lots of projects where I figured out how to do something and then stopped. To get good at something, though, you have to keep learning about it and pursuing it. That will be the difference with me and Ruby. I'm now in a place where daily Ruby needs and efforts are becoming more and more real (and measurable) parts of my work. Therefore, I can't just build a tool and blindly and half-understandingly maintain it. I need to develop the knowledge necessary to build stuff from scratch and then be abe to maintain, grow or restart different projects. The simple hack approach won't cut it going forward, so I have to go for it and make this all work. A bit every day (and a missive writing about it) I hope will do that :).

Practicum Revisited: Learn Ruby the Hard Way

Books are great, but they tend to linger and hang around as references when you need something. Screencasts are cool, but again, you need to remember to go to them and work on them when you can. Coding is like language study (and since in a way it is linguistics, that should come as no surprise). I remember back in 2009 I went into overdrive to learn how to write in Japanese. I spent each day practicing Kana and Kanji, and while I learned a lot, I had one major drawback... I had no one to converse with on a regular enough basis to make the skills stick. Additionally, I tend to do better when I prepare things as though I'm going to teach them to someone else, or at least have a dialog about the ideas I'm looking at.


My goal is to do something similar, and to that effect, I'm going to start another extended project, and invite you all to come along for the ride. Each morning, I will be doing a write up on "Learn Ruby The Hard Way". This is not just a pseudo-journalistic lark... it's actually a hard deliverable I agreed to for my performance review :). There are several goals that I will be working on and that I want to learn and think about, and so I'm going to experiment with a "total immersion" project. Also, this is a bit of a study in "Androgogy" or to see how well and under what circumstances an adult actually learns. I'm also big on the potential of "high shame goals"... meaning if I don't follow through, I deserve to have the entire TESTHEAD readership bag on me (remember my post this morning about Motivation? This is the equivalent of a double Espresso shot of it (LOL!) ).

Also, just as with the BOOK CLUB posts, I realize that this may not excite everyone, so I will be aiming to do two posts a day, the other posts covering different topics. The games will commence tomorrow morning. For those excited, I hope you will join me for the festivities. For those not excited, well... you have been warned (LOL!).

What Motivates You?!

This morning, Episode #68 of This Week in Software Testing went online, and in many ways, this was one of my favorite episodes to produce. We still deal with the challenges of optimizing Skype for multiple conversations (it's getting better) and it was tough to decide what to keep and what to trim out, but I think the result is worth it.

This show also celebrates the first appearance of Jonathan Bach as a contributor. We've been trying to get Jon on the show for months, but various scheduling issues and other factors have prevented it from happening. We're glad he could join us for this, especially since we cover one of my favorite topics, Motivation.

It's a challenging thing to deal with what motivates people. We often get it wrong. What motivates me may or may not motivate you. Some people are motivated by money. Some are motivated by attention or fame. Some just want to see an idea of theirs take shape. Some want to grow internally and spiritually. Some just want to have fun.  Many want varying combinations of all of the the preceding.

I discovered that, in a way, my biggest motivation is this... I want to be part of a vanguard movement.

This really doesn't surprise me. It was my primary motivation as a musician, above and beyond just playing and dreaming of being a rock star. I really liked the idea of representing San Francisco and the San Francisco rock scene. More than just wanting to be a rock star, I really wanted to be a rock star "that came from San Francisco". Ultimately that dream fell short of my ultimate and intended goal, but I'll dare say I went a lot farther with it than many people I knew that had similar dreams did. To be fair, many more went much farther than I did, of course, but the motivation was still there, and that motivation defined my involvement.

In Scouting, I've held a lot of leadership positions, ranging everywhere from Tiger Cub Den Leader, Cub Scout Den Leader, Cubmaster, Scoutmaster, Venturing Crew Advisor, Explorer Post Advisor, Order of the Arrow Chapter Advisor, and Assistant District Commissioner (sort of a Board of Directors for the Scouting movement in a given area). Again, much of this came from my desire to be involved and my self identification as a Scouting leader and wanting to make a difference in the lives of families and in my community.

In an earlier post I mentioned that I became part of "the movement" that was the burgeoning snowboarding scene in Lake Tahoe during the early part of the 1990's. That was a core part of my identity for many years, and it still is in a lot of ways. While I never had any real thoughts of ever "turning pro", I did align with and aspire to associate myself with the ideals of the snowboarding movement. In fact, one of my first stabs at editorial writing came through this era. I wrote a number of feature article for an online snowboarding magazine called "Cyberboarder" (don't laugh, this was in 1995, *everything* was cyber this or cyber that... OK, go ahead and laugh, it's cool :) ). I started competing in the late 1990's (as a Masters level competitor, i.e. the over 30 division). I won a few medals, placed in a few slope-style events, and podium'd in several races, actually winning a Gold Medal in a regional event in 2004 in the Giant Slalom. I wrote about my experiences and published them in a series of articles (about 30 of them) called "The Geezer X Chronicles" (you can enjoy my early writings for "Cyberboarder" and "The Geezer X Chronicles" via "The Way Back Machine" if you so choose :) ).

What's my point with these examples? Feeling a kinship with these communities, and actively seeking that kinship, gave me identity. Identity gave me purpose and a mission. Mission gave me drive. Drive helped me produce.

For many testers, I believe that the problem is that there is not quite a sense of belonging, or that many testers are unaware of a broader community. Those who will read this are probably already aware of this broader community. The greater challenge is getting those who are not aware to become aware of it and encourage them to be a part of it.

For me, looking back, the real and true motivator in my life, and the one that has had the most sustaining power, has been kinship with a group of people. Continuous communication and involvement has helped me develop drive and passion, and with that drive and passion, opportunities appear. Other opportunities are spawned by how we respond to the initial opportunities we are offered. If you are wondering how to develop your test mojo, my answer is to find other testers who similarly want to improve. Become a community, or attach yourself to the broader testing community via Twitter, LinkedIn, Forums, Weekend Testing, Associations, whatever. The sooner you become part of a community that you care about and cares about you, the sooner you will kick your own motivation into overdrive. Or at least, that's what did it for me :).