In my last post, The A**hats of Testing, I went on a rant about archetypes of people in testing that get on my nerves. I had mixed feelings about putting that post out there. I was nervous as it was a rant. It didn’t bring much to the table except a list of frustrations.

I’ve been working on a follow up for a while now, and it took a bit for me to decide on the approach. But before I get to content to match the title of this post, I want to reflect on the A**hats.

About the A**hats

First off, if you look carefully at the list, it isn’t about Context Driven Testing. Yes, there a rather prominent member of that community who fits one or more of the archetypes, but I don’t see too many CDT folks fitting the Luddite archetype, as I defined it. Additionally, I don’t think we can point to one group and say, “that’s what’s wrong with testing.”

Second, I’ve been somewhat embarrassed by the post. Being such a rant and so accusing of others, I felt a lot of pressure to be conciliatory. So I started on this post from that perspective. . But I’ve reread the original a couple of times, and I stand by it, for the most part. It’s a little rough in places, but I really have worked with or encountered people who fit those archetypes. Probably most people reading the post will dwell on the Righteous Guru or The Sheep, but I’ve been pretty frustrated at times with The Luddite and the Coder-Snob.

Finally, there is a lot of public debate about CDT and the leaders in the CDT community. There are people out there who I believe are rightfully upset about the way they have been treated. I know individuals who have “left” testing to do development or other jobs because it wasn’t fun any more (I have no intention of debating if work should be fun). That sucks. No other way to put it. I also have seen people in posts and on twitter who identify as CDT, and don’t feel it is fair to cast all of CDT in the image of a few people who are the most visible.

So I will say it here: considering yourself a Context Driven Tester does not make you an A**hat. Your actions as a member of the testing community, not your beliefs, should determine what people think of you.

So Enough With the A**hats, and About Those Quality People…

For all the complaining in my previous post, and the recriminations on twitter and the aforementioned blog posts, there are good people out there in testing. And not just a few. Some have been around for a while now. Others are more recent additions. And some have “left” us (though I don’t accept their resignation, they can be programmers now, they are still testers to me).

So Jim Holmes (@aJimHolmes) sort of beat me to this when he posted this:

All the kerfuffle over the last few weeks made me think how I want to be viewed as a tester. Ergo my own credo. http://twitter.com/aJimHolmes/status/755142010714091521/photo/1

I’ve been working on this for a bit. And similar to what Jim posted about himself, rather than archetypes, here is a list of traits of Quality People in testing:

• Reasonable: Testers are a tricky bunch. We spend our days holding products, and people to exacting standards. It’s what we’re paid to do. But I think we’re at our best when we listen to and respect each other.
• Passionate: The best testers care. They demonstrate that caring by being passionate about the product they work on. the team they work with, and the customer who will use the product. And they are passionate about testing.
• Clever: Testers are a smart bunch. It takes a clever person to figure their way around the products we test. It takes a clever person to come up with new approaches to the process of testing; approaches that change the way people work.
• Bridge Builders: Some of the best out there are looking at how to help testers work with others; whether that is in Agile, DevOps, or some other process. Bridge builders help others remember the value that can come from people who are good at finding problems.
• Teachers: There are so many great teachers among testers. They might offer it in videos, classroom settings, podcasts, mentoring session, or just their blog. They take ideas and help others understand.
• Open minded: They recognize that the world of software development is too big to know everything. So they want to learn from others to see what can be done, and what can be done better. And while they may be skeptical, they don’t start from an attack.
• Sharing: It might sound a lot like being a teacher, but not everyone is comfortable stepping out in that role. Sometimes it is good enough to share experiences be it on twitter, or at a conference, local meetup, or at the water cooler. Sharing what you know, even in little ways, can help others grow as testers.
• Independent Testers need to think for themselves. They certainly can and should be open minded and learn from others, but they also need to question what they are learning. Not everything applies everywhere. And while someone you respect may have some ideas that sound good, those ideas should be evaluated against your own experiences and beliefs before you act on or profess to them.

Wrapping Up

Notice, I’m still not naming names. I thought about it. It’s a lot easier to name people when you are highlighting positive things. But there are too many people who fit these various categories to name them. Additionally, after the last post, it felt a little bit like sucking up.

I’m not sure how well I stack up to my own list, or the list that Jim posted. At times I think I am not as open minded, or as skeptical as I should be. And sometimes I can be a bit of a sheep myself. So I have my own work to do.

The crazy part of my previous post is how I generally don’t rant like that in public. I generally don’t post flamebait or get into online arguments, as I’m not very good at it.

Yeah, I guess I’m gonna go there.

I sincerely doubt that I’m alone when I write this. I’m guessing there are others out there who are equally tired of the crap we testers put up with, and I don’t mean developers, project managers or other typical targets. I’m tired of the A**hats that are part of our own tribe.

Here’s my list of A**hats that I’m tired of, in no particular order:

The Righteous Guru

The Righteous Guru looks out upon the world of testing with absolute belief that they know the path that the world should be on. They argue their philosophy with great intensity to the point where their opponent has submitted. They lambaste people over differing opinions, letting the adrenaline propel them forward over friend and foe alike. Ultimately, they are blind to the wounded and stranded on the path behind them, or just off the road.

The Gatekeeper

Oh, I know what your thinking, but the Gatekeeper isn’t the one who says if software can ship. The Gatekeeper wants to tell you you can or can’t test, you can or can’t get a job because you didn’t earn/buy one of their keys. They want to lock up testing in a shiny tower where things work the right way, and follow their guidelines.

The Chicken Little

The Chicken Little keeps telling us that the end of testing is coming. That Agile, Certification, Offshore, or some other bogeyman is going to cause the jobs for testers to dry up. They don’t provide any helpful guidance, nor do they take the time to figure out what they can do that the bogeyman can’t.

The Luddite

The Luddite has stopped growing. They don’t want to know more about testing or how to test better. They won’t or claim they can’t learn how to use various tools to make themselves more effective. And sometimes, they will fight tooth and nail to keep things the way they are, so that they don’t have to change.

The Sheep

The Sheep just follow along. Whether that is just doing what their manager says or following whatever guru/expert they have chosen, Righteous or otherwise. They produce outrageous plans or they scream at the words “best practices”. They don’t ask questions. Whatever their A**hat tells them they should do, they insist on it.

The Coder-Snob

The Coder-Snob insists that only by being ultra-technical and writing automation can testers be useful. They will insist that everyone has to be as awesome with scripting/coding/querying as they are. If you can’t cut it with them technically, you don’t belong.

The Framework Fanatic

The Framework Fanatic is a developer, user or advocate of tool XYZ and cannot understand why anyone would use anything else. They see the strengths of their tool and are blind to the weaknesses. They will insert themselves in discussions to the defense of their tool and hijack the conversation. They forget that every tool works fantastically given the right target.

The People Who Write Posts Like This

I’m an A**hat too. People who write posts like this just want attention. They aren’t experts or gurus. They don’t have stuff to say that reinvents the industry. They just are fed up with the way all these other A**hats are mucking things up. And a little bit of ranting makes them feel better.

Where does that leave things?

Don’t be an A**hat.

• Stop bullying people who don’t agree with you or have a hard time understanding you.
• Stop being so proscriptive. Testing an be a big tent.
• Stop running around saying the sky is falling and do something that makes you indispensable.
• Stop resisting and try something new; maybe even something hard.
• Stop following blindly and challenge something you are told.
• Stop thinking that code and technology is the only way to make the software better and to find problems.
• Stop pushing your tool and start understanding there are reasons your tool might not be a good fit for a given user.
• Stop writing posts like this. ;-)

Bug Magnet

Bug Magnet¹ is one of Gojko Adzic’s numerous contributions to software development and testing. It’s an exploratory testing aid and extension for Chrome and Firefox. It keeps on hand a number of useful strings that you can enter into your web application as you perform exploratory testing. There is no script for what to use, just a handy collection of inputs to expose certain common errors.

I like Bug Magnet. It’s good to have little tools like this to extend our resources and maybe trim a little time off. Some of the entries are obvious, and one can argue that you could just remember them. Others are impossible to just type in by hand. I have it installed in Chrome, and I’ve used it often. But I also like to use Safari in my testing, and there isn’t a version for that.

I could have taken the time to find a way to port Bug Magnet to Safari. Totally was an option. Right now, I just don’t have the time, nor the desire to figure that out. Instead, I went and created a collection of Macros in Keyboard Maestro.

This installment of using Keyboard Maestro as a test tool is actually only a slight deviation from the previous two: Throw Away Emails² and Browser Agnostic Form Filling³. Again, the macros are using a lot of pasting or typing into fields.

Palettes

What is different here is the addition of palettes to the workflow In Keyboard Maestro, palettes are like a pop-up menu that is summoned on screen. You can then choose the action you want to take from the palette. If multiple pallets are sharing a hot key, they you can choose which one you want to use. Keyboard Maestro could also be configured to expand all of these macros by some sort of typed keyword (which is how I trigger the throw away emails ¹), but that’s a lot to remember. Bug Magnet’s great virtue is that you can pick from a list of things to decide what makes sense in a given field. Being presented with the choices is part of the value. So palettes match the original functionality well.

One last thing, to trigger this, I’m using my Caps Lock key as a hyperkey, as explained by Brett Terpstra⁴. Each of my macro groups is bound to ^⌥⇧⌘Delete, which I can hit very easily using Caps Lock + Delete. All of them get rolled up into a higher level palette that you can pick from with the mouse or keyboard, as you can see in the animated gif above.

You can download my macros as a library here: KM Bug Magnet

As testers, we all find ourselves having to do a lot of repetitive work. That’s just the nature of the job. To test something to the level we think necessary, we might have to do the same steps dozens, or even hundreds of times.

Recently I had a case of excessive form-filling-itus. I was testing a feature that required me to fill out the same form over and over again, just to get data into the state I needed it in. It was necessary, but it didn’t matter too much what was in the form.

So, there are a few ways I could have addressed this. For example, I could have used, Selenium to automate it. I already have scripts and page objects to do that. I could have also used Selenium IDE to record the steps and then play them back. I also could have used a browser extension to do it. None of those solutions seemed like the most flexible way to go.

Instead I called upon Keyboard Maestro again and utilize it’s ability to send keystrokes and run JavaScript functions. Here’s a section of the macro:

My previous example¹ was pretty much straight forward; set a variable, type in one thing and copy that variable to the clipboard. There were a couple of things that I needed to do that were different this time. This involves multiple fields and and dealing with dropdowns. And when filling out these forms, it was OK if some of the data was the same, but having a different first name, last name and actual street address would be enough. To do this, I put to use the ability of Keyboard Maestro to run JavaScript in an action. So I built macros that selected a first name and last name randomly from a list of each, and another macro that picked a random number, street name and designator (St., Dr., Ave., etc.). Each of these saved the values in a Keyboard Maestro variable. Then it was just a matter of using “insert by typing” and “Type the zzz Keystroke” actions to fill in the forms and navigate between fields (sending tab keys as needed).

Here is an the action that produces the random street name. It’s not fancy, but it works:

And since I created that as a separate macro, I now have it as a reusable action that I can integrate into future scripts. Right now I have three of them, Get Random Make First Name, Get Random Last Name, and Get Random Street Address.

I chose JavaScript as the language for these macros, mostly because I was just generating data. Since this all on on a Mac, a macro can also call shell scripts or AppleScript. And those scripts can interact with the operating system, not just generate strings (technically JavaScript can be used for that too in the two most recent versions of OS X).

There are plenty of tools and options for automation on the Mac, and I use several of them. Each of them has their strengths and weaknesses. Keyboard Maestro is one of the strongest for this sort of interaction. The ability to build reusable blocks and send keystrokes made it a good fit. I have a few more examples of how I use Keyboard Maestro coming. So far they don’t drift too far from a certain them, but maybe they will inspire someone.

Introduction

I’m rather fond of finding new tools and leveraging them for a variety of tasks. Often it is just a way to make some repetitive task a little easier, even if that task isn’t directly testing related.

For my day-to-day automation, I use Selenium to do automated test/checks of the system. Generally I use Se to do automation that doesn’t have a human factor to it. I certainly could use it to automate other interactions with the web, but it’s sometimes more work than I want to do for a given task.

A tool I’ve used for a while now for a handful of tasks is Keyboard Maestro,¹ an OS X application for a wide range of automation of common tasks. What makes it interesting is the extensive set of tools it has available. It can utilize a range of ways to automate things on your Mac.

It can:

• Send keystrokes to applications
• Use AppleScript/JavaScript to interact with applications
• Run shell scripts
• Track and interact with the clipboard
• Directly interact with Safari and Chrome
• Manipulate windows
• Manipulate files
• Take and manipulate screen shots

Keyboard Maestro uses a graphical programming style that adds actions to a macro as modular blocks. Each of those blocks can be configured to control how each block works. It also supports using variables and logic constructs to make your scripts more functional.

Throw Away Emails

Every so often I have to test something that needs a unique email, but it doesn’t have to be an email at a real domain. I don’t know about you, but I can’t create unique things on the fly. Not with just my head and my fingers. So this is where I’ve applied some Keyboard Maestro Magic.

The macro I below is just a couple steps.

1. Build an email address using some fixed strings (my initials and the domain) with a time-stamp of when the email was generated. The time-stamp was a suggestion of a co-worker as a way to help identify the data by when you were working.
2. It copies that email address to the clipboard, so if I need it again soon, it will be in my clipboard manager.
3. It types the email address into the active field.

I use a typing trigger to launch the macro. Currently, I use ;;temp. And trust me, there is a bunch of muscle memory tied to that trigger.

Wrapping Up

This is just a first example of how I use Keyboard Maestro to help me to my testing. Sure, it’s not hard to come up with an email. But this way, I can create an email I can identify as mine, self identifies with when I was doing the work, and gets saved to my clipboard manager (just in case I need to enter it again).

I’ll be sharing some more examples of how I use Keyboard Maestro to make me more efficient with a variety of tasks. Keep an eye open for more.