preload

Shadow Work In Testing

Posted by Albert Gareev on Nov 04, 2015 | Categories: NotesStories

This writing is a cross-reference to the post  with regards to the concept of Shadow Work.

A quick reminder.

In economics, shadow work refers to unpaid labor in the form of self service. Shadow work has one or few of the following attributes.

  • Transferring part of the service from company to customer
  • Takes away personal time
  • Because of automation, people actually work more, not less

Let me match some of these points with a story.

Once upon a time there was a company which had an IT department. IT wasn’t the core business of the company but they run own data centre and used in-house software for data processing.
When the tough times came in the company had to be efficient and revisit its staffing to meet the business objectives. So were the people told.
An outsourcing was brought in as a way for the staff to achieve the “work-life balance” and for the departments to “accomplish more”. Based on some analysis, new development plans were made, and the existing ones were revisited to account for the offshore services.
After all, efficient and cheaper means higher quality and faster, right?

So were the IT folks thinking.

Of course, programmers had to stay at work longer to explain coding tasks to the people in the offshore unit. Or come two hours earlier. Of course, testers had to do the same, explaining testing objectives and giving walkthroughs.

Everyone needs to catch up in the beginning, right?
Yet somehow it felt as a disappointment.

Although the promised progress has been made, and the management felt succeeding. They didn’t see IT staff disappointed.

As it went further in the project, testers started noticing an unusually high amount of defects, ranging from cosmetic to “ship stoppers”. Their fellow programmers who worked on the in-house code modules were called in to resolve those numerous issues. The programmers didn’t feel happy to leave their current tasks on hold, but the feeling didn’t compare to the shock they experienced after inspecting the “offshore code”. It just didn’t go along with the coding quality standard they’ve established! They felt an urge to re-do and clean up. Of course, that would mean doing extra job in their personal time, because the management didn’t recognize the problem.
That was really frustrating.

So it was for testers.
After they discovered that the offshore service has happy passing reports not really backed up with test results they felt an urge to re-test the delegated areas. At least, sample them. And yes, the results were frustrating.
But they couldn’t get an understanding from the management, because those parts were already reported as developed and tested. The job has been done. The time and money were spent.

 

I don’t have much happy words to say of the outcomes. People learned to distrust such a service. They were unhappy verifying and cleaning after some others’ work. Administrative measures didn’t help the situation. Many didn’t want to stay in misery and left the company.
Deteriorating quality of the software impacted the quality of the business services.

Now, that was an example made from the real stories of many developers and testers, as well as my own observations and experiences.
Things don’t necessarily go so bad with offshoring, and outsourcing is the strategy that proved itself working. Moreover, I can instantly name a few offshore companies doing insanely awesome testing services that really make their customers happy, while their testers are highly recognized in the professional community.
But let’s focus on the Shadow Work aspects that played the negative roles.

  • It begins as a service offering. However, beneath the business level, the important parts of the service are transferred back to the technical staff.
  • It goes unnoticed – by management – and surely was not accounted for.
  • Dealing with it takes away personal time.
  • People have to work more but are recognized for less.

—-

I have another story to tell, this time about the automation aspect. But let me do a recap first.

Disclaimer: those below are observed patterns. Wise management surely drives the situation differently and the shadow work might be not causing so much grief. Otherwise it becomes a major demotivating factor.

Management

  • Don’t see it (or perceive it as a “norm”)
  • Don’t know about it (not aware anyway)
  • Don’t understand (because it’s technical aspect lying beneath)
  • Don’t account for it in planning and estimation
  • Don’t give recognition

Top negative attributes

  • Unexpected
  • Unscheduled
  • Unsupported
  • Unrecognized

Main emotions

  • Disappointment
  • Frustration
  • Distrust

Can you share examples of the shadow work you’re doing or had to do?

 

 


Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.