Tag Archives: reactive work

What Is It For?

You, as a Scrum Master, tells everyone on the team that it’s time for the daily stand up. What is it for?

You created a wiki of the team’s activities and you told the group about it’s existence. What is it for?

You are putting some time writing automated checks. What are those for?

You’re adamant that there should be regular team progress reports. What’s that for?

You’re crunching numbered story/task estimates and drawing a burn-down chart. What is it for?

You learned how to hack networks of computers. For what reason would you use that knowledge for?

You built a testing document filled with test cases that pass or fail. What’s that for?

You’re keeping tabs of the history of released changes to production. What is it for?

You are giving up some personal time for teaching colleagues skills that you know which they don’t. What is it for?

Sometimes what we do are rituals that are based on existing processes, handed over because the people who have used them before think they work, and so we don’t think otherwise. It often requires more effort to think deeply about why we keep doing certain things, but, in the long run, it certainly is worth double-checking that what we decide to do align well to the goals that we’re trying to achieve.

Easy and Challenging

Easy:

  • give programmers something to do and monitor their tasks
  • add new features
  • file a bug report
  • work on the clock
  • say we are good to go on that production release
  • perform daily stand ups
  • complain about company training opportunities
  • write a test scenario
  • find time for the things we want to do
  • teach someone how to test

Challenging:

  • empathize with what programmers do
  • solve a customer’s problem
  • understand why a bug exists in the first place and prevent it from happening again
  • make sure that work never ceases to have deep personal meaning
  • build the confidence and systems necessary for being able to say we are good to go
  • collaborate and communicate with teammates well
  • stop waiting for permission to build or learn something
  • understand why a test scenario is valuable or not
  • have the discipline to actually do the things we really want to pursue
  • teach someone how to test effectively

A Matter Of Prioritization

After taking on testing lead responsibilities, I find out that it’s difficult to strike a balance between time for personal creative work and time for support work. By creative work I mean research and study of processes, testing activities, and tools. It is work that I prefer to do most of the time because it is where I often learn something new. It provides insight about stuff that can lead to interesting changes and tools that might help us perform better and become more remarkable. Support work, on the other hand, is all about rushed, reactive but also important, short-term goals –  helping a teammate solve a problem at hand, teaching others how our apps work, providing necessary information to people who need them, or taking on requests.

Often I lean towards filling my day with creative work because it is where I have fun the most but there’s never a day without someone asking me for help. Software testers and product owners go to me for help investigating issues and testing scenarios, and programmers look for me if they need business rules clarifications. Some days there’s just too many requests than I’d like to handle. Other times I get obsessed about a new tool or skill that I forget for a while to check the more pressing things at hand.

In the end everything becomes a matter of prioritization. I go right away if someones asks for my help. And if I have time to work a little on my projects, I do that.

Tomorrow Is Another Day

For the software tester, some days are long and hard.

Popup messages appear one after another from people asking for assistance and requests. Mails pour in for the same reason. There are ongoing bug fixes she knows she needs to focus on with her programmers but she can’t, not with all these incoming distractions. Her boss calls for a meeting and it takes an ample amount of time that she could have used to follow up more important things, especially now with deadlines looming. Several application updates are in line for testing and she’s sorry she’s unable to provide test reports yet. She’s also required to double-check software requirements with the product owners on upcoming projects. With the little free time she has, she tries to create automated tests on the side because she knows this will help her in future regression work. Some testing documents are outdated and needs reviewing too, she remembers.

When all these things happening in rapid succession on any given day, it’s easy to fail. With these many things to attend to and keep track of, it’s difficult to concentrate and making mistakes is almost inevitable.

But that’s alright. Even on unsuccessful days, the remarkable software tester does her utmost best. She takes the hit, she takes responsibility for the mistakes and she extracts whatever she can learn from them. She knows that tomorrow is another day. Eventually, she gets better and grows.

When Things Go Out Of (Our) Control

We’re irritated when a fellow software tester doesn’t come in at work without prior notice because, suddenly, our work for the day becomes much heavier. We’re annoyed when a programmer makes a mistake in a code commit that pushes back the testing schedule. We’re infuriated with product owners when the changes in business rules happen too often. We’re piqued with people who do not appreciate the importance of our work.

If we give it some thought, we’ll realize that many of the things that enrage us are often rooted to situations that are out of our control. We can’t control when a fellow software tester will not go to work. We can’t control when a programmer makes a mistake. We can’t control when business rules change because they will always continue to do so. We can’t help it if other people do not appreciate the work that we do: their priorities and preferences are just different from ours. Our feelings of anger get the best of us sometimes, triggered immediately when, with bad timing, surprising problems arise.

It’s only natural to be surprised, to feel stressed and stretched when things do not go the way we expect them to go. But, please, do not let things worsen with pointless bickering and finger pointing. How we respond to the things that surprise us should be within our control. We can do better: let out a cry, accept what happened, investigate, create a solution.

During Downtime

Most software testers are quick on their toes when critical issues arise. When a major bug gets reported on the Live version of the app, she immediately goes to the available programmer to sort it out as soon as possible. When the boss commands what feature needs to be released ASAP (so they say), she automatically gathers her team to tell them they need to work double, no, triple-time starting now. When a client is starting to get angry with a feature that was previously working perfectly, she instantly thinks of any possible workaround and promises a fix in a flash. A serious bug appears after a release and she gets around to fixing it quickly before anyone is able to notice. Almost all testers are actually good in such situations, when everyone is tensed, when there are pressing matters that needs resolution, when there is a need to react pronto.

The same software testers however are often not as good during downtime. When there’s no email to reply to promptly, when a feature is currently in its planning stages, when there’s time to sort out the test scripts, when regression testing is still ongoing, there is a tendency to let small issues slide by. When there’s no adrenaline to push them into action, they stay idle. When there’s nothing to react to, they forget to let their creativity run free.

It is not obvious but what software testers do during their free time seems to be a more telling tale of their abilities than what they show during times of crisis.

Think About Where You Work

What we’re able to churn out every working day is determined by three things: what we decide to finish, how much energy we have, and the work environment. The first two are pretty manageable because we can plan our to do‘s the night before and we can rest enough to be able to perform. All it takes is self-discipline, something we control. Work environment, however, is an external stimulus.

I go to work in an office and I like to do all my testing work in the mornings as much as possible when there aren’t so many people coming in yet. That’s because I can’t concentrate anymore when people talk to me. Sometimes they ask for clarifications on the requirements, other times they just want to chat. Either way my focus will continue to shift from listening and replying to testing work then back to listening then back to testing work, which affects my output. After changing my schedule several times, I found it better to set aside time in the afternoon to help or lead my team and then just do the bulk of testing early in the morning. This works for me. If I didn’t do the work early, if I slack off in the morning, often I find myself feeling unproductive at the end of the day. I might have been able to help co-workers, answering their important questions or guiding them, but because I didn’t finish what I set out to complete I would feel like I did not do anything.

The stage where we do our work affects us in so many ways, most of which we do not often consider. So think about where you work, the place, the time, the culture of the people you meet and converse with, and use what you learn to help you accomplish things better.

Do Creative Work

Software testers are often swamped doing reactive type of work. Day-to-day tasks are filled with checking and responding to emails, creating bug reports, testing bug fixes, or providing important testing information to people who are asking. Their work schedule can be easily overwhelmed with following up on updates from programmers or confirmation from product managers, especially while there still a backlog of testing to do for demanding clients, and (most of the time) there isn’t much room for doing anything else. This poses an interesting problem: a software tester that is too busy responding to issues day-in day-out will soon find herself stuck in the flow without changes in processes, always just reacting to whatever new concern is the most priority, just a cog in a machine.

Better for her to challenge oneself to move outside the loop, to find time bit by bit, to find ways to experiment and improve her skill set, to make herself more valuable in software testing work, to balance reactive work with creative work without waiting for instructions from the boss.