Test Jumpers: One Vision of Agile Testing

Many software companies, these days, are organized around a number of small Agile teams. These teams may be working on different projects or parts of the same project. I have often toured such companies with their large open plan offices; their big tables and whiteboards festooned with colorful Post-Its occasionally fluttering to the floor like leaves in a perpetual autumn display; their too many earbuds and not nearly enough conference rooms. Sound familiar, Spotify? Skype?

(This is a picture of a smoke jumper. I wish test jumpers looked this cool.)

I have a proposal for skilled Agile testing in such places: a role called a “test jumper.” The name comes from the elite “smoke jumper” type of firefighter. A test jumper is a trained and enthusiastic test lead (see my Responsible Tester post for a description of a test lead) who “jumps” into projects and from project to project: evaluating the testing, doing testing or organizing people in other roles to do testing. A test jumper can function as test team of one (what I call an omega tester ) or join a team of other testers.

The value of a role like this arises because in a typical dedicated Agile situation, everyone is expected to help with testing, and yet having staff dedicated solely to testing may be unwarranted. In practice, that means everyone remains chronically an amateur tester, untrained and unmotivated. The test jumper role could be a role held by one person, dedicated to the mastery of testing skills and tools, who is shared among many projects. This is a role that I feel close to, because it’s sort of what I already do. I am a consulting software tester who likes to get his hands dirty doing testing and running in-house testing events. I love short-term assignments and helping other testers come up to speed.

 

 

What Does a Test Jumper Do?

A test jumper basically asks, How are my projects handling the testing? How can I contribute to a project? How can I help someone test today?

Specifically a test jumper:

  • may spend weeks on one project, acting as an ordinary responsible tester.
  • may spend a few days on one project, organizing and leading testing events, coaching people, and helping to evaluate the results.
  • may spend as little as 90 minutes on one project, reviewing a test strategy and giving suggestions to a local tester or developer.
  • may attend a sprint planning meeting to assure that testing issues are discussed.
  • may design, write, or configure a tool to help perform a certain special kind of testing.
  • may coach another tester about how to create a test strategy, use a tool, or otherwise learn to be a better tester.
  • may make sense of test coverage.
  • may work with designers to foster better testability in the product.
  • may help improve relations between testers and developers, or if there are no other testers help the developers think productively about testing.

Test jumping is a time-critical role. You must learn to triage and split your time across many task threads. You must reassess project and product risk pretty much every day. I can see calling someone a test jumper who never “jumps” out of the project, but nevertheless embodies the skills and temperament needs to work in a very flexible, agile, self-managed fashion, on an intense project.

Addendum #1: Commenter Augusto Evangelisti suggests that I emphasize the point about coaching. It is already in my list, above, but I agree it deserves more prominence. In order to safely “jump” away from a project, the test jumper must constantly lean toward nudging, coaching, or even training local helpers (who are often the developers themselves, and who are not testing specialists, even though they are super-smart and experienced in other technical realms) and local responsible testers (if there are any on that project). The ideal goal is for each team to be reasonably self-sufficient, or at least for the periodic visits of the test jumper to be enough to keep them on a good track.

What Does a Test Jumper Need?

  • The ability and the enthusiasm for plunging in and doing testing right now when necessary.
  • The ability to pull himself out of a specific test task and see the big picture.
  • The ability to recruit helpers.
  • The ability to coach and train testers, and people who can help testing.
  • A wide knowledge of tools and ability to write tools as needed.
  • A good respectful relationship with developers.
  • The ability to speak up in sprint planning meetings about testing-related issues such as testability.
  • A keen understanding of testability.
  • The ability to lead ad hoc groups of people with challenging personalities during occasional test events.
  • An ability to speak in front of people and product useful and concise documentation as necessary.
  • The ability to manage many threads of work at once.
  • The ability to evaluate and explain testing in general, as well as with respect to particular forms of testing.

A good test jumper will listen to advice from anyone, but no one needs to tell a test jumper what to do next. Test jumpers manage their own testing missions, in consultation with such clients as arise. A test jumper must be able to discover and analyze the testing context, then adapt to it or shape it as necessary. It is a role made for the Context-Driven school of testing.

Does a Test Jumper Need to be a Programmer?

Coding skills help tremendously in this role, but being a good programmer is not absolutely required. What is required is that you learn technical things very quickly and have excellent problem-solving and social skills. Oh, and you ought to live and breathe testing, of course.

How Does a Test Jumper Come to Be?

A test jumper is mostly self-created, much as good developers are. A test jumper can start as a programmer, as I did, and then fall in love with the excitement of testing (I love the hunt for bugs). A test jumper may start as a tester, learn consulting and leadership skills, but not want to be a full-time manager. Management has its consolations and triumphs, of course, but some of us like to do technical things. Test jumping may be part of extending the career path for an experienced and valuable tester.

11 Responses to “Test Jumpers: One Vision of Agile Testing”

  1. Claire Says:

    This. I identify so strongly with this description. Thanks for putting it into words. :)

  2. Lanette Says:

    This is EXACTLY what I do in my job! Thank you for describing this. I was asked today if I was a software tester, to which I replied, “Of course! No matter what else I do, I’m a software tester first and foremost and always. Just because I plan other things, pair with developers, or coordinate other things we need to make testing happen doesn’t mean I’d ever NOT be a tester.”

    It takes devops, tools, scripts, builds, and sometimes sacrificing chickens to get testing done. Doing everything that I need so that testing can happen is part of my job. It’s all part of this odd swiss army knife that is what I’m doing on small projects in the wild. It sounds like I’m far from alone in the jungle, and I’m glad to hear the rustling of a few others doing this odd Guerilla Testing. (which no actual animals were harmed during). Just so PETA doesn’t stalk me, I’m against animal testing, except for humans who are willingly performing testing. I recently performed some animal testing and learned that my cats prefer their canned food “minced” over cubed.

  3. Augusto Evangelisti Says:

    Great piece James

    I have been a test jumper in agile teams for quite a long time and I appreciate the fact that you have formalised the concept in a blog post.

    There is one dimension though that maybe should be explored more and that I use quite heavily in my work. I do most of the things that you mention but while doing them I keep the focus on coaching the team on how to test.

    My goal as a test jumper is to reach a point where I am not necessary any longer, a time where the team have gained the ability to be self sufficient without relying on the test jumper. I know I am successful when I am not needed any longer.

    [James' Reply: Excellent point. I have added a paragraph in the middle and credited you with the assist.
    ]

  4. Jim Hazen Says:

    James,

    I can definitely identify with this description. Too many times when a tester is put onto a new project, or hired to start a new test group/function you are jumping into the middle of a wildfire. As part of that you need to quickly evaluate the situation and determine the plan of attack. Then you start building fire breaks and working towards getting things under control. You just hope you don’t get caught by a shift in the fire’s direction and end up burned.

    I don’t think any of us want to end up looking like “Fire Marshall Bill”, but sometimes it does happen. Let me tell ya somethin!

    Jim Hazen

  5. Andrew O'Gorman Says:

    Excellent post James.
    The description of the role almost exactly parallels our role of “Test Master” (a less than subtle nod to the Scrum Master position).
    Test Masters helped us ensure consistency of the agile approach as we introduced 8 new product teams (where previously there was a single team whose focus changed from release to release).
    We were dealing with both internal and external development teams, as well as Product Owners and Business Analysts who were new to Agile Development, so this role became a very useful parallel with scrum master activities.

    There’s also a similarity between the Test Jumper and the Quality Assistance activity that Michael Bolton wrote about a few years ago I think.
    Andrew.

    [James' Reply: Thanks.

    Michael and I draw a sharp line between testing and QA. When I think of what QA supposedly does that is other than testing, I find that it usually boils down to routine project management. A QA operative as usually conceived (when not conceived as a tester) is essentially a project manager's office clerk. There is another aspect of QA that I very rarely see that is neither project management nor testing, and that is product risk abatement. But I think that is better served by the developers themselves, hence a QA operative in that mode would be acting as a architect's clerk.

    A test jumper does testing, fosters testing, manages testing, and trains testers. Quality is the job of the whole team and does not sit on the tester's shoulder any more than anyone else's, and probably less. What the test jumper role shares with the most sophisticated versions of QA is that both involve leadership, rather than solely individual technical action.]

  6. Joe Strazzere Says:

    So a Test Jumper does whatever needs to be done (testing-wise). Sounds like a lot of fun!

    “In practice, that means everyone remains chronically an amateur tester, untrained and unmotivated.” I don’t yet have enough experience in Agile to see this for myself yet. If true, this is very sad and certainly seems to be a weakness with the Agile approach. I think you really need to write about this more. Please?

    [James' Reply: This has been a longstanding philosophical difference between the programmer-dominated culture of Agile and the culture of skilled testers. Attitudes vary from place to place, of course. But what I'm saying is that to do any technical activity well you must study and strive to improve. If you are focused on programming, you study that. If you are focused on testing, you study that. It is possible to study both, but programming is so interesting and all-consuming that it is VERY rare for a programmer to study testing to any great degree.

    Some of them seem to be offended when I say that. I think that's because they honestly don't realize how deep I am speaking when I speak of studying. Many of them seem to see little worth learning in the testing sphere.]

  7. Richard Bradshaw Says:

    Hello James,

    As always an excellent post. As with RST you have captured my thoughts and experiences and expressed them at a level where I go, of course! Its so clear now.

    I had this exact role recently, the role was described to me as a tester, but with my main responsibilities being the go to guy for all things testing, not an Omega Tester. It was clear that I wouldn’t be doing much testing but there to guide and orchestrate testing.

    I have a post in draft where I have been trying to write a similar post about this role, based on my experiences from those 6 months. There were no other testers at this company it was developers who were doing the testing, it was them I was coaching and training. As you can imagine there was pro’s and con’s which I intend to discuss.

    I will work on this post over the next few days and will reference this post now, because as mentioned its covered things I was trying to write about but unfortunately I don’t have the skill of extracting the details or my experiences for that matter and clearly writing/explaining them that you have, yet.

    Richard Bradshaw

    [James' Reply: If you want to chat with me about it to help you put your ideas and experiences into words, contact me on Skype. ID: satisfice.]

  8. Scott Says:

    Hi James,

    Great post, I love the description of the “Test Jumper” and the activties that he/her performs as part of that role and I can see a number of similarities that align with the way my testing career has gone over the past few years where it has expanded into more of an adhoc capacity such as combining TL, Consultant, Automater, test writer, demostrator to name a few and I believe this has similarites with what you have described and perhaps this is the way a lot of the testing roles are going particually in agile enviroments, which I tend to find is the norm in the domains that I operate.

    I’m still not convinced about the terminolgy though, as “Test Jumper” implies something that simply starts and ends (jump out of an aircraft, perform some stunts and land, rinse and repeat) and does not seem to fit with my thoughts of what that testing role like this represents, perhaps a testing evangelist might be closer to the point ?.

    [James' Reply: Evangelists promote things but don't do those things. You know, like those televangelists who talk about morality but don't do it.]

    I have not heard of a test jumper so perhaps you could shed some light on the meaning of this term.

    [James' Reply: The post you are commenting on describes the meaning of the term.

    The reason "jumper" fits is that this concept of testing, just like Agile itself, is an episodic view of work. This kind of tester DOES jump in and then away from projects and tasks. It's similar to firefighting, hence the allusion to smoke jumpers.

    I suppose another analogous term would be "test ranger."]

    Regards
    Scott

  9. Emmanuel Says:

    Hi James,

    I do not know if this is the medium to contact you. Your blog posts are very educational and interesting. I am interested in becoming a software tester but do not know where to start. I will appreciate it if you could point me to the right direction. Secondly, I would like you to be my mentor please? I look forward to hearing from you.

    Thansks

    Emmanuel

    [James' Reply: See here: http://www.satisfice.com/blog/archives/category/about-me

  10. Nilanjan Says:

    It might be good to be cautious about using the phrase ‘agile testing’. ‘agile testing’ has a specific connotation (even if it isn’t clearly spelled out). If you look at http://agiletestingalliance.org/ or http://www.agiletestingdays.com/program.php?id=248 you may see what it stands for.

    [James' Reply: I know what it means, and I think I am using it in a reasonable way. Agile testing has two common meanings that I encounter in my consulting: 1) any testing on a self-described Agile project, or 2) automated checks created in the course Agile development. Most people subscribe to the first meaning, I think. The second is not even really testing, so I don't worry about it.]

    While ‘agile testing’ is not antagonistic towards the principles of CDT, I think CDT represents much more and it is possible for someone to practice ‘agile testing’ while being quite weak in CDT techniques/principles. When you use the phrase ‘agile testing’ it *can* seem as if you endorse the approach of ‘agile testing’.

    [James' Reply: I have heard it proposed that there is an "Agile school" of testing. And that's persuasive. Although I don't belong to that school, when I speak of Agile testing, it is fair to say I wouldn't mind being heard by members of that school.]

    In your description of ‘test jumper’ I think you should emphasize that you assume that the ‘test jumper’ is first a ‘good tester’. The way you present this topic, one could exhibit all the attributes of a ‘test jumper’ and be a poor tester. It’s also possible for teams without developers to exhibit ‘jumping’ without the ‘testing’.

    [James' Reply: I am mystified that you would say that. Please read the first paragraphs of my post, where I repeatedly speak of testing skills. I don't know how I could emphasize any more the importance of possessing strong testing skills. There's no fair reading of my post that supports the idea that I think a poor tester would make a good test jumper.]

    Surprisingly, your description of the ‘omega tester’ contains many attributes of a good tester (agile or not). However, I suspect most readers will not click on that link.

    I like what you’ve said with my caveat – must be a good tester before being a jumper.

    [James' Reply: But I did say that. See paragraphs 2 and 3 and tell me what words you would have me change.]

  11. Donald Firesmith Says:

    I tend to work on large programs that when they use an agile or evolutionary (iterative, incremental, and concurrent) development cycle, they may have from 5-15 “Scrum-like” teams. In that case, a test jumper would and probably should stay on the same program (because it is critical in MHO that to be a good tester of a system, one must to a reasonable degree understand that system and the software and hardware (including things like sensors and actuators) technologies used in the system. My experience has been that the testers for the most part are not qualified to do professional programming, and programmers are not qualified to do professional testing). Also, many testers are not skilled enough in test scripting to do a lot of test automation, while programmers don’t really understand testing well enough to do test automation on their own. While I think that a test jumper is a good idea, I also think that merely mentoring developers in testing is not adequate, especially if you are not officially part of the project and here today, gone tomorrow. I much prefer programmers and testers being joined at the hip when doing Agile sprints. In fact, I think that pair-programming/testing is more important than pair programming. In other words, I think all agile teams need at least on professional tester and part of that tester’s job would be mentoring the developers in testing.

    I realize that there are many exceptions to my observations in the sense that there are numerous developers having a fair handle on testing and testers having a fair handle on development, But these exceptions are all too rare. With testing needing to be at least 30% of the effort, even on Agile programs, I don’t see how it makes sense to not have a qualified tester on each agile team.

Leave a Reply

Comments are moderated. You might want to read my commenting policy before you make a comment...