Brain dump: How I’d like my Agile testers to be

So I was just thinking about how I need the testers to work in our project (and maybe in any other project). This started as a brain dump and then the next thing I know I’ve got this outline already. So anyways, If I were to outline what I’d look for in testers, I’d look into the following areas:

  • Attitude towards testing
  • Technical competence
  • Being a team player

Attitude towards testing

Working on an Agile, greenfield project really needs to have testers who are quick studies, self-sufficient and proactive. Most of the time we are given just the user story and some mock-ups, so I need the testers who can model the user story in their heads or in their notes, ask the right questions about it, and do it on their own (i.e., not wait to be served the information they need on a silver platter).

I think testing is like problem solving. It’s like: Hey, you’re given this user story. How do you test it to make sure it’ll pass the PO’s review? What exactly do you need to test? What do you need to know to test it? It has a save functionality– what does it save, where does it save it, who’s allowed to save, are there stuff that needs to be derived or transformed, etc. It has a read functionality–read from where, how do I know I’m pulling the right data into the fields I’m checking, how do you get data entered to be read in the first place, do we format certain items differently, etc. Hey, look at this screen, what can I do with the controls in the screen, what can I do that I’m not supposed to, etc. Hey, I found a bug–can I consistently replicate it, can I narrow down the cases when this bug would appear, is this just a symptom of an underlying bug, is this even a valid bug, etc. There’s a fix I need to retest–what could possibly be affected, do I need to retest everything, etc. There’s a lot of figuring out and critical thinking involved.

What I don’t like is to reduce testing to an activity where we just write test cases and execute the test steps without thinking about how our work can provide value to the team, to the product, to the client, and to people who’d end up using our product. I really want the testers go into the project with the desire to make their being in the project really matter.

Technical competence

You can’t just WANT to be a solid contributor to the project, you have to BE one. You can be the most idealistic person but that won’t get you to where you want or need to be, you need to be able to execute.

For testing, I don’t necessarily equate technical competence to being able to automate. Being able to automate tests doesn’t mean so much if your tests can’t find the issues that needs fixing. We have to keep in mind that the product is the actual product — not the test automation scripts.

As I mentioned earlier, testing is like problem solving. Part of this includes modeling the application or feature you need to test — figuring out where there’d be if clauses or doing some decision tables, figuring out the data flows, state transitions, figuring out combination of valid/invalid input, etc. Figuring out what you actually need to test given that the lines defining the scope could sometimes get blurry. Then there’s instances where you have to work with the database, parse some flat files, or with some API. There are also instances when you need to simulate a certain scenario — and you have to figure how to do this right otherwise you might just bring up an invalid test case or bug. There are also instances when looking under the hood allows for more efficient testing; for instance I’ve reviewed database scripts and that reduced the effort as opposed to executing the test cases in fully black box mode.

You’ll also need to collaborate with developers and you need to be able to keep up with the discussions. You can’t rely on the layer of having the test lead interpret stuff for you. And it just saves people time from having to explain things if you can keep up with the technical discussions. When you report bugs, it is also very helpful if you’ve done your own investigation to narrow down the possible causes. When it comes to bug reporting, I always say “A problem well stated is a problem half solved.”

There’s a lot of collaboration within the Agile project. Roles of people you’ll engage with include fellow testers, devs, UX designer, BA, PO, and possibly support. You’ll need to share status updates, raise impediments, raise bugs, raise potential enhancements, raise a lot of clarifications, and possibly conduct demos of the user story. There’s going to be a lot of communication going on so you really need to know what you’re talking about, and you have to know how to talk about it.

Being a good team player

This is good to have in any project or in any team. You want to work with people who are responsible, reliable and who keeps each other informed as needed. You want people to pull their own weight in the project, and to help each other out esp when the load gets heavier for some. And it’s all the more appreciated when people help without having to be asked to help.

Meeting the Sprint goals is the primary focus, and so when needed, the lines defining the roles are blurred and folks try to contribute whenever and wherever they can. For instance, I’ve taken on the BA role while another tester has taken on the PM/scrum master role. We have front end devs who also work on back end tasks. When we needed load testing to be done and we couldn’t get another tester to work on it, one of our devs took on the task. When there were some data update needed, the team split the task among those who can help so as to get the job done faster.

Summing it up

It’s hard to come up with a checklist of traits for what I’d like in the testers in my team. Essentially, I want testers who sincerely want to contribute to the project. I want testers who can actually test, who respect testing per se, and who can build their credibility within the team. And of course, I want team players to help make the not so easy task of building software hopefully less hard. People won’t always fit the bill off the bat, but what’s important is to advance towards improving.

Ensuring quality

“A tester ensures the quality of the product.” — Probably just as much as my donations to wwf are helping me to “save endangered species.”

The other day I listened to a podcast by the Bach brothers. One of the things they pointed out as needing improvement is the accuracy of testers’ statements. As an example, they cite — and question — the familiar statement “a tester ensures the quality of the product” which many of us use to describe what we do. But then I guess it can’t be helped. Someone I follow on twitter shared that a book on software development described the tester’s task is to verify that software is correct.

Is that really what I’m supposed to do? Ensure quality? Well, it does make my work sound more powerful. It sure makes for better marketing than “find bugs”. And probably for more attractive hiring. But there’s a shred — ok, a tiny sliver — of truth to it albeit so indirectly (just as i am saving endangered species… somehow).

In the podcast, Jon Bach suggested the term “assistance.” Between “ensuring quality” and “helping” to do so, what we do comes closer to the latter. We help our SAs by spotting design holes. We help our devs by spotting errors and misses in their code. We help them when we give clear and concise bug reports — all the more when we do bug isolation and provide accurate reports. We help our team leads by providing information on the product under test. Et cetera, et cetera. Sometimes it may not be quite obvious but we, testers, are a very helpful bunch!

We do our bit, we play our part. But no matter how well we play it, by ourselves, we (testers) cannot ensure quality. I reckon it’s a team thing. What we do as members of the project team (be it testers, devs, SAs, etc), how badly or how well we do it, can either make or break our software product.

Ultimate team player

This evening, I received an exclusive pre-release article from [the] new Marcum and Smith book, “Momentum”.  They’re the same guys who wrote Egonomics.  Anyway, part of the article is on the ultimate team player — which I’m sharing here.

According to our work and research, the ultimate team player has certain characteristics that set them apart and make it easy (at least easier) to know who they are when you see them. Here are some key questions that distinguish a great team player:

  1. Do they make the people around them better?
  2. Do others offer better ideas because of their questions?
  3. Do others work more passionately because they’re around that person?
  4. Do others pay attention more when they’re in the room?
  5. Are others more engaged because they’re on a project with that person?

Here are 12 characteristics of a great team player that feed into the five questions above:

  1. We, then me mindset; works with a team first approach without losing sight of his individual talent, confidence and contribution.
  2. Devoted to progress; committed to a cause or purpose beyond himself.
  3. Speaks her mind boldly and diplomatically.
  4. Listens to feedback carefully and anxiously, especially when it’s difficult to hear.
  5. Constructively discontent; not pessimistic, but not relaxed about status-quo.
  6. Inclusive; loves diversity and talent, especially those with talents and history different than theirs.
  7. Insists on debate, and debates ideas effectively; doesn’t care who has the best idea, as long as the best idea wins; doesn’t take things personally.
  8. Open minded; not change or new idea resistant.
  9. Doesn’t allow the early warning signs of poor communication and teamwork (defensiveness, showcasing, excessive competition, seeking acceptance) undermine team dynamics and individual talent.
  10. Sees people as equals, not as superiors and subordinates. Only in accountability and performance are those hierarchical relationships visible.
  11. People trust your intentions; people know where you’re coming from when you challenge ideas, share new ideas, etc.
  12. Desire to make a difference, not just “do your job.” There is a clear performance difference between “job-holders” and difference-makers.