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.

Innovation schmation

I was asked to write an article on innovation sometime ago to be included in our team’s newsletter. It’s finally out so I can finally post it here. I guess my basic thinking about the whole innovation thing is to get over the hurdle that it’s this major monster of a buzzword that only special geniuses can overcome. As Seneca puts it, “It is not because things are difficult that we do not dare, it is because we do not dare that they are difficult.” So really, just try and start doing.


Have you ever had a pretzel from Auntie Anne’s? I’d typically have a Cinnamon & Sugar pretzel, request for that to be cut into pieces, and order their cream cheese dip. Then one day, I was about to order my usual when I noticed something posted on the side. “Cinnamon Stix,” it read. The pretzel dough was shaped into short sticks coated with the Cinnamon & Sugar flavor, and each stick had a cream cheese filling. That “new” item was pretty much my usual order — rolled into a different package. “Ooh, innovation!”, I thought as I took my first bite.

It’s probably not what folks would even consider as an innovation. “Innovation” is such a buzzword nowadays. When you say “innovation”, people think of something mind-blowingly drastic with tremendously huge impact. The type that if you give a keynote speech about it you’ll get at least 5 minutes of standing ovation.

One other common notion is that you have to automate in order to innovate. Or that you need to produce a new tool that will save a measurable number of hours.

Or that you produce an even newer (hopefully, better) tool than the one just recently deployed. That happens. There was one time I attended a tools demo, and there were several tools that were shared but they were pretty much just different implementations of the same thing.

Discard those notions. Putting those limits in your head counters the chances of you coming up with one. So for starters, open up your mind to the possibility that you can come up with something that will make things easier for yourself and others. Take a look at how things are currently being done, and question whether they can be done better. It can be something as simple as introducing a minor change in one step of the process, or finding a useful shortcut key combination.

Your innovation doesn’t have to be big. You can start with the little things and it could be just as valuable because little things can add up to something bigger.

It doesn’t have to make a universal impact. Start with something that helps yourself, and then maybe work your way to helping a bigger audience.

You don’t need to automate. Automation is a tool that can be used to innovate; it is not innovation itself. If coding is not your thing, you can do research. For all you know there could be an existing solution to what you’re trying to address that is already out there.

It doesn’t have to be something totally new altogether. Just take my cinnamon stix example. Also, you don’t need to come up with a new tool every time. Sometimes it could just be a matter of tapping some unused feature of the existing tool, or looking into the current process rather than the tool.

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.

Sprint retro: Testing worked!

So my friend is in this other agile project doing 1 week sprints implementing a web-based system. Until last week, their team didn’t have a tester. Of course, they probably dev-tested their own work and they did have sprint reviews with their product owner. But, as they’ve also brought up in their retro, and what’s also great about their team is that they recognize the need or value of testing (I quote: “need proper testing”).

A couple of weeks ago, my friend asked me to take a look at their site, give it a quick run through, and give feedback. So I sat down on it for an hour or so, and did some exploratory testing on a few available features. After that session, I had spewed out as many comments (bugs) as I could and consolidated them along with screenshots. For the sprint they were doing a retro on, they fixed some of the items I raised and finally got a tester in their team. It felt great to see this dev team post under “what worked”:

  • Tester
  • Bugs are raised
  • Some bugs are fixed / completed
  • KC (that’s me!)

Yay for testing!

Reads: The Myth of Epiphany

The myth of epiphany is that great ideas dawn upon you in an a-ha moment. Take for example the popular story of an apple falling on Newton’s head when he discovered gravity or Archimedes’ eureka moment in the bathtub. But what those stories seem to miss out is the significant amount of work that they’ve poured into solving related problems, and that it’s only when they took a break and let their minds wander that the answer came to them. We mustn’t overlook that there is work that leads up to those a-ha moments. There is a period of incubation where we try to digest the information that we’ve observed as we work on things, and our brains are catching up with all that’s been observed. Then if we’re lucky, the answer or the great idea comes to us at an instance that seems so out of the blue that it makes for a good story.

One quote from Ted Hoff (inventor of the first microprocessor, Intel’s 4004) said it best:

“… If you’re always waiting for that wonderful breakthrough, it’s probably never going to happen. Instead, what you have to do is keep working on things. If you find something that looks good, follow through with it.”


The Myth of Epiphany is from a chapter in Scott Berkun’s book, The Myths of Innovation.

Active testers should be the norm

So yesterday we had a sprint review wherein the testers conducted the demo to our product owner. I reckon it went rather smoothly. I am pleased with how my tester team mates did their presentations. The delivery team overall got good feedback from our PO (yay!), and we testers got some kudos from our PM (yay, again!).

Later in the day, our team had our sprint retrospective. Under the header of what worked well, one of our team mates wrote “DEV-TEST” (which someone corrected to DEV♥TEST) referring to how well the devs and testers were working together. It was actually one of the most upvoted items. And from the retro deck I quote: “Strong and instantaneous link-up between developers and testers. Notification and resolution of defects are faster due to great work relationships between the team”.

Under the header of what to do differently of our sprint retro, not wanting to make scrummerfall a norm in our coming sprints, I suggested to plan sprints such that there are testable features earlier in the sprint (and definitely not 3 days before the end of the sprint as what we’ve encountered for Sprints 0 and 1). This concern didn’t go unheard and the team actually brought up a couple of action items which addresses this.

Earlier today, we got word from our PO on the priorities for this sprint. The devs had to prioritize several bug fixes and that left one of the high-priority items on data encoding to us testers. It’s not exactly testing work, and it’s not exactly dev work either. But it needs to be done this week, so we went ahead and owned it. We actually completed the task in half the time we estimated. Yay for efficiency (or overestimation, but I’d say the former).

So where exactly am I going with this post. I guess I’m just glad that the testers are having such an active role in this project. We’re being heard and (I’d like to think) appreciated. And I guess this shouldn’t be an expectation only in Agile projects. This should go for any project.

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.

Hello again, world

I haven’t been in this space for some time. Lately, I’ve been instagramming about my lovely dogs and tumblring my attempts of doing art. I am still in software testing. I still feel that the work we testers do highly contributes to making software better (or at least less sucky).

I’m around month and a week into my 2nd mobile testing engagement. We’re at the 2nd week of our 2nd Sprint. There are a lot of things that are new in this project so it’s a really great learning opportunity for myself and more so for my younger tester team mates. For one, we’re adopting an Agile Scrum methodology, and it’s probably the closest we’ve gotten to an actual agile project (we have some scrumbuts). This project is also an implementation project, so this provides them with the opportunity to see something get built from scratch. I think testers who haven’t tried working in an implementation project are missing out. This is where the fun is, and where testing can make the most impact. Plus, this one’s building a mobile app so it has a really modern feel to it.

So tomorrow’s a holiday and we still haven’t received a build for half of the user stories in scope of this sprint or for the fixes of the bugs that were already reported, and Friday is the last day of the sprint. Ah, scrummerfall! It’s a word I picked up yesterday. One of the questions in a webinar I attended touched on the topic of agilefall or scrummerfall. It happens in Agile projects wherein the testing work starts at around the 8th day and the testers are scrambling to test the features and doing overtime work to catch up, and the developers are already moving on to other things. If you’re experiencing scrummerfall, sorry but you planned it that way. The good thing is you can choose to not plan it that way (or so the speaker says). Someone needs to raise their hand and point it out so that the team is planning for a sprint that has something testable as early as day 2 or 3.

Something to raise for our retro. :p

TED Talk: Why work doesn’t happen at work

Excerpts:

That’s what happens at the office.You don’t have a workday anymore. You have work moments.It’s like the front door of the office is like a Cuisinart, and you walk in and your day is shredded to bits, because you have 15 minutes here and 30 minutes there, and then something else happens and you’re pulled off your work,and you’ve got to do something else, then you have 20 minutes, then it’s lunch. Then you have something else to do. Then you’ve got 15 minutes, and someone pulls you aside and asks you this question,and before you know it, it’s 5 p.m., and you look back on the day, and you realize that you didn’t get anything done.I mean, we’ve all been through this. We probably went through it yesterday, or the day before, or the day before that. You look back on your day, and you’re like, I got nothing done today. I was at work. I sat at my desk. I used my expensive computer. I used the software they told me to use. I went to these meetings I was asked to go to. I did these conference calls. I did all this stuff. But I didn’t actually do anything. I just did tasks. I didn’t actually get meaningful work done.

And what you find is that, especially with creative people –designers, programmers,writers, engineers,thinkers –that people really need long stretches of uninterrupted time to get something done. You cannot ask somebody to be creative in 15 minutes and really think about a problem. You might have a quick idea, but to be in deep thought about a problem and really consider a problem carefully, you need long stretches of uninterrupted time. And even though the workday is typically eight hours, how many people here have ever had eight hours to themselves at the office? How about seven hours? Six? Five? Four? When’s the last time you had three hours to yourself at the office? Two hours? One, maybe? Very, very few people actually have long stretches of uninterrupted time at an office. And this is why people choose to do work at home, or they might go to the office, but they might go to the office really early in the day, or late at night when no one’s around, or they stick around after everyone’s left, or they go in on the weekends, or they get work done on the plane, or they get work done in the car or in the train because there are no distractions.

… Just silence, that’s it. And what you’ll find is that a tremendous amount of work actually gets done when no one talks to each other. This is when people actually get stuff done, is when no one’s bothering them, when no one’s interrupting them. And you can give someone — giving someone four hours of uninterrupted time is the best gift you can give anybody at work. It’s better than a computer. It’s better than a new monitor. It’s better than new software,or whatever people typically use. Giving them four hours of quiet time at the office is going to be incredibly valuable.

Reads: How to destroy programmer productivity

Not a programmer, but a lot of what he said somewhat applies.
Excerpts:
Whatever I can control, I should control. That means:
  • Turning off notifications on my iPhone (this has the added benefit of  increased battery life)
  • Giving myself a reward for 3 hours of continuous coding [or testing, in my case] (usually in the form  of “internet time” like checking Hacker News or twitter)
  • Working from home when I really, really, need to get something done
  • Scheduling ‘no meeting’ times on my calendar. These are times shown as busy  to everyone else. It’s my work time.
  • Not getting into programmer arguments around the office; people have strong  opinions, and the programmers who have arguments love to argue. If  there’s an actual business problem that needs to be solved, let’s grab a  conference room and come up with the advantages and disadvantages of each  approach. Let’s get some data. Let’s not just argue.
  • Position my desk in such a way that passersby aren’t distracting. [Well, i slouch so that i can’t see passersby. That’s not so healthy but that’s another topic.]
  • Taking a first pass at the problem, and *then* asking another developer to  walk me through the problem so that I can get a better understanding of what to  do. This accomplishes two things: First, it allows me to get the ‘lay of the  land’ so that I’ll at least have a basic understanding of the forces at work.  Second, it allows me to ask more intelligent questions when I ask for  help