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.

Why aren’t we… why don’t we have…

Warning: A lot of mention of “innovation”, “innovate”, “innovative” in this post. Here’s a photo of my two cute dogs if you need a break from those buzzwords.

A question got raised one evening while we were in Tinola (that’s the name of the conference room, which is also the name of a local viand), and we ended up having a full-blown discussion over it complete with a mindmap on the white board.

So the question was: Why aren’t we innovating as much as they want? We decided the key points were: Time, Skills, Motivation. Experience is essential for the insights and the intuition it brings for being able to distinguish what could be of value and what would most likely be a waste of time. We had a dotted line to “Management support” as they’d be the one most qualified to allocate time and skills at least. But that didn’t make the cut on what’s at the top of our list. Looking at the image, it kind of generally addresses any other question on why we don’t have something that’s being demanded of us.

why_arent_we

I’ll try to go over each item from what I can recall.

Time – To produce something or create something generally takes time. I think that’s a physical, realistic, and basic requirement. Just sitting down on a problem can’t solve it — you have to think about it, process it, rack your brains for solutions or ideas. That by itself takes time. And implementing the solution all the more. So when folks are so busy in their projects, it’s a bit hard to expect them to focus on anything else.

But say you free up people so they can work on “innovations”, there’s this other aspect on skills.

Skills – If the expected solution is an implemented application or system, then that requires skills in software engineering — design and analysis, then there’s implementation or coding, testing, etc. These are skills you don’t just build overnight so with the learning curve, it’s going to take a lot more time to come up with a minimum viable product (i had to use that term*). Then there’s this concern on which skill do we need to build up further — shouldn’t we focus on strengthening our testing chops since we’re testers after all? Learn more about other aspects of testing that could be relevant to our craft/career? Or should we use that hypothetical free time learning to code so we can create applications?

And then again do we know how to innovate to begin with? Maybe there are some workshops to develop one’s skills in problem solving or creative thinking which could increase one’s chances in coming up with something innovative.

So say we have the time, we have the skills. It doesn’t mean we’ll already be working on innovating. We need a reason why to drive us and that’s the third point which is motivation.

Motivation – This is what would compel us to innovate. It’s so important to have a why! It’s emphasized so much even in the Jillian Michael’s workout video I’ve been regularly watching where she says “If you have a why, you can tolerate any how.”

It’s but natural for us humans to ask what’s in this for me? What would I get out of this? This could take on different forms — it could be financial rewards for some, fun for others, opportunities to learn for the rest, etc. It depends on the person’s individual priorities on what would be rewarding and in turn motivating for him.

Then there’s also the question on whether there is even a need to innovate. Of course, there are always things that could be improved, but there has to be a good problem to solve — the kind that’ll feel like you have an itch to scratch, the kind that will merit the need to spend time on it.

So that’s pretty much it for what we discussed that evening. Thanks for reading!

*Long story — maybe i can share some other time. I’ve rambled on for too long already. Thanks again for reading!

More on When in Rome

One of the things I often say is “When in Rome, do as the Romans do.” I have some team mates who admittedly know me better than most that jokingly say what I really mean is “When in Rome, invade the Romans.” While I have no plans for domination (that’s just too much trouble), a lot of jokes are half-meant.

“When in Rome, do as the Romans do” is not a call for conformity, submissiveness, or withdrawing your own beliefs to follow someone else’s. To me, it’s about flexibility and just being plainly realistic that when you’re thrust into a new environment (be it a new company, a team, or a project) you can’t expect things to go your way or the old way that you know. You need to “do as the Romans do” to survey the environment, find out how things are being done, and more importantly to find out why things are being done a certain way.

There’s a saying that goes first learn the rules then break them. “Doing as the Romans do” allows you to learn the rules. This gives you the context and is essential for finding out which rules you can break or to how much extent can you push the limits of the rules. I don’t generally condone rule-breaking (I hate jaywalkers), but sometimes there are just BS rules (Google: sacred cows) which were set in place ages ago that are no longer relevant to the current situation. To me, rules (just like tools and processes) should be there to help make things easier or move things along more easily. If it’s more of a pain in the ass, then something’s wrong.

And I guess this is where “invading Rome” comes in. Armed with what you’ve learned from “doing as the Romans”, you are in a better position to trigger change. You also pick up on how to go about it, say who you need to talk to effect change more easily. But before we all go on a changing spree, one other important thing for me is to choose your battles. Not everything is worth rallying change for. I am not religious but the serenity prayer* says it best: Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.

[* N/A when I’m driving.]

Must I take on extra work?

At work, there’s this initiative asking people to do research work on some testing tools. There was a meeting where the topics were laid out and the facilitator asked folks who’d like to own them. There were a few takers but not everyone grabbed something to own. And I guess I can’t really blame them.

This is “on top” work (or as I’d like to start saying “in my personal time”). Most folks are already full-time in their projects and could use whatever slack there is (no matter how small) to take a breather and do other stuff that they want/need to. Personally, I need slack to be able to step back and think about how things are going, whether things can be improved, what do I need to plan for, how do I actually plan to do something, etc. Of course, a really small fraction of that slack goes into looking at cute creatures on the Internet for a boost of good vibes.

On the other hand, I want to think out loud a bit on why folks would want to do this extra work. What’s in it for them if they take on this extra, unbillable research work that they’ll have do in their personal time? Thomas A. Edison said:

Opportunity is missed by most people because it is dressed in overalls and looks like work.

The thing is if you do the work well enough, it doesn’t go without merits. If you’re hungry for learning, then the reward is that you learn. If you’re hungry for distinction, then the reward is visibility to your manager or your peers (which is a tougher crowd). If you’re hungry for promotion, then the reward is you get outputs/results to help increase your chances.

So back to the question, must you take on extra work? Sorry to disappoint, but I have no definite YES or NO answer to this. I go for IT DEPENDS. Not because it’s a safe answer but that’s the reality of how it is. It depends on what your goals are or what you’re hungry for. You can’t say yes to everything that falls on your plate. Say yes to opportunities that could bring you closer to your goal or just generally make you happy.

Specialization schmation

So I was at this meeting with a team mate, and one of topics that got mentioned was specialization. So while we were on the topic, I kinda heard Roy’s voice in my head saying “Specialization is for insects!” There was also this quote I remembered:

If all you have is a hammer, everything looks like a nail.

On one hand, I reckon there’s just too much to learn in software engineering that there really is a need to focus. But on the other hand, specialization has its own traps. I read somewhere that specialist is just a fancy way of describing someone who doesn’t know a lot on other matters (crap, I can’t remember where I saw that). Using specialization as an excuse to not learn anything else is just too egotistical. And to relate to the quote I mentioned, just imagine a specialist on a particular solution who pushes that solution for every and any problem he encounters even if it doesn’t really fit.

Here’s a similar (and probably more thought of than this brain dump) take to it: Why Office Gurus are Bad (And the Buses Who Hit Them).

Semi-off topic. TIL that quote is called Maslow’s hammer or Baruch’s Observation.

Brain dump: Being a test lead

I’m grooming a team mate to become a test lead. What makes this role different from being a tester?

As a tester, your focus is on your test assignments. But as you become more senior (and not just when you become a test lead), you need to start looking at the bigger picture. Not just in terms of functions being tested e.g., you become more concerned as the system as a whole. But you also start seeing your purpose in the software engineering process i.e., you’re an integral part of it and what you want to deliver aren’t test cases or bugs but rather an application that has been fortified by your testing, an application that the target end-user will actually want to use. Software isn’t made to just make jobs for us who are in the business of delivering software. Software is for helping people do the stuff they need.

I guess I’m getting ahead of myself with that explanation and that might be too much to take in.

So a simpler answer…

  • As a test lead, you need to be able to coordinate test tasks among the test team.
  • There’s also a lot of admin work like you need to be able to note attendance or how to contact folks just in case they don’t show up.
  • You also need to watch out for risks, dependencies, assumptions, constraints (or basically anything that could go wrong), and for issues (when things went wrong), and capture lessons learned. As a tester, you already do this but it scales up when you’re the test lead.
  • You also act as a representative of the test team — if there are concerns that they hesitate to raise, you have to either encourage them to raise it or raise it yourself.
  • You need to be able to initiate creation of templates, standards, guidelines, workflows that will help the test team do their work.
  • You need to be able to review other testers’ work — be it test case drafting, test execution, bug reporting, status reporting.
  • You need to be on your toes in case something tricky or complex comes along so that you can suggest options or strategies on how to go about with it.
  • You also need to be able to take the blunt hits for your team when something doesn’t work out, because in a way you are more accountable if you’re the “lead” in general. You might think leads or project managers have it easy because most of the time it looks like they’re just doing reports or asking others to do the work. But when shit hits the fan and the team doesn’t deliver, someone’s going to look for a neck to choke and often it’s theirs.

Ok. That’s about all I can write this morning. Till my next brain dump.