"Some birds aren't meant to be caged, their feathers are just too bright"- Morgan Freeman, Shawshank Redemption. This blog is from one such bird who couldn't be caged by organizations who mandate scripted software testing. Pradeep Soundararajan welcomes you to this blog and wishes you a good time here and even otherwise.

Wednesday, May 28, 2008

Reduce Reuse Recycle

I toured Singapore for about 10 days this month. I don't know why my eyes kept catching signboards that suggested people to Reduce, Reuse and Recycle plastics. I think it was because I am from India.

As a part of my tour, I had been to a Zoo and there, I heard the animal show host explaining the need to reduce, reuse and recycle as it impacts the environment and animals.

I felt great about Singaporeans, for stressing the point in many places. No wonder their country ( most parts ) is so clean and tidy that I felt I am in a foreign land. I thought for a while that people in India don't talk about Reduce, Reuse and Recycle as much as Singaporeans do.

16 days after the tour ended, I realized I was wrong. People in India talk as much as Singaporeans do about reducing, reusing and recycling. Here is how they ask:

How can I reduce testing and thereby decrease the cost of the project and increase my profitability?

If testing is a job of providing quality related information to the stake holders to help them take better informed what could reducing testing mean?

I think the people who talk about reducing testing to decrease costs want to know if there is
  • a way (or more than one) to make testers more efficient, skilled and competent.
  • a way (or more than one) to get information more faster.
  • a way (or more than one) to know if they can save costs by not purchasing unnecessary tools.
  • a way (or more than one) to know if they can avoid hiring bad candidates.
  • a way (or more than one) to know if they could spend less on managing attrition.
  • a way (or more than one) to know if they are not doing things that would not add value.
  • a way (or more than one) to know if they are meeting the mission.
  • a way (or more than one) to know if they can fall into fewer traps.
  • a way (or more than one) to know if they can recover much faster from the traps.
  • a way (or more than one) to know if they can be more successful in getting more projects.
and : How can I reuse and recycle my test cases, test scripts and testers for future projects thereby reducing the cost of my future projects to increase my profitability?

I think people who talk about reusing / recycling test cases, scripts and testers for future projects want to know:
  • many ways (or at least one) to know if they can cut costs by not needing to train testers on a similar domain, technology or product.
  • many ways (or at least one) to know if they can cut costs by not having to spend time on writing test cases and test scripts for a new project by modifying existing test cases and test scripts.
  • many ways (or at least one) to know if they can cut costs by not having to write code that tests code by modifying existing code.
  • many ways (or at least one) to know if they can cut costs by not needing to spend much of a time on learning the new product and finding bugs faster.
  • many ways (or at least one) to know if by thinking of reusing and recycling, they are definitely saving costs without sacrificing the value they want to add.

Well, if all those who ask the questions knew how to ask it more elaborate or deeper questions, we'd be living in a different world. Thankfully, we still are in the same world.

How did I reuse, recycle and reduce?
  • I don't recommend writing test cases and executing tests with the help of that. Although I am not someone who'd like looking at test cases, there was a context in which I looked in to test case document that someone else had written, to gather ideas for my exploratory testing. That's how I reused a test case. It definitely reduced the cost because I took help of an already existing database of ideas. ( That doesn't mean test cases can be handy for ideas to test. A check list, cheat sheet, mnemonics, heuristics... might do it as well more cost effectively).
  • In one of the several product development organizations I worked for, I identified that a tester was not performing fair enough. I probed for his history of performance within the organization in past projects and recommended him to be fired ( of course, I had the authority to recommend ) He was being paid a lot for he had over 7 years experience. The management feared firing him could send wrong signals to other team members but I asked, "What more right a signal can people get?". On firing him we had money to afford hiring 4 junior testers for 1/5th of what he was paid and got more than what he was delivering. That's how I reduced the cost of the product.
There might be a lot of ways to solve a problem and there might be a lot more ways to not solve them. Unfortunately the ways to not solve a problem appear like the ways to solve problem. Humans are stuck!

If working on reducing, reusing and recycling test cases aren't working, you might want to reduce your intention of reducing, reusing and recycling /and/ think of reusing those ideas in a different context /or /recycle those ideas at a later date when you think the context has changed to suit it.

--
Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

6 comments:

Shrini Kulkarni said...

When you hear "Reduce" testing - I am afraid, it is none of those good things that you mentioned. From my experience in IT for so many years, it is about doing less of what you are doing under the name "Testing" (read human testing). IT world works on constant pressure of keeping the costs low. So Testing becomes the victim of this, mainly.

This would translate to reduce manual testing effort, make testing cycle shorter and then infamous advise (almost all contexts) to go for automation.

There would be risks of this "cutting" excercise ..but as James Bach mentioned - results of insufficient/bad testing can be attributed to many other resons.

thus at the end, you may not notice, why there were so many bugs slipped, why product failed in the market ...?

People will immdiately install another "stringint" process, more monitoring, more documentation, more review, more tools --- no one talks about improving tester skills.

BTW, the word "reuse" is the MOST ab-used word in testing today - especially in automation.

Recycle - you can recycle your old test ideas, I guess ...

Shrini

Pradeep Soundararajan said...

@Shrini,

When you hear "Reduce" testing - I am afraid, it is none of those good things that you mentioned.

Well,I too am aware of what you are saying. This post is to help them say the way that you think is good from what I have said.

Whether they say it after reading this?

Its not under either of our control.

BTW, the word "reuse" is the MOST ab-used word in testing today - especially in automation.

When people have taken the liberty to abuse the word "testing" why would they spare the word "reuse".

Amit Arora said...

Pradeep,

The Idea to reduce, reuse, recycle is essentially one of conservation. The problem is, it is mostly misunderstood, misinterpreted and misused.

Yes conservation does apply to project management, it applies to test project management as much. Its no mindless reduction, its conservation and utilization, best possible utilization, not even optimum, because optimum means a trade off for a constraint, which again is prone to be wrongly defined.

The example you have given, the one where in you recommended someone to be fired is a good example of the essential idea of utilizing resources better.

On second thoughts, couldn't one move this resource to a position where he could be used better than firing him?

But thats a different able no doubts.

Regards,
Amit

Pradeep Soundararajan said...

@Amit,


On second thoughts, couldn't one move this resource to a position where he could be used better than firing him?


If you have second thoughts about not firing someone despite poor performance, you aren't doing business.

You also might have read what I did after firing that person: We had money to hire 4 fresh testers ( thereby providing more job opportunities for young talent to prove ) and we did get results that suggested us our decision was right.

Amit Arora said...

Pradeep,

I did read that, and that's the reason I said that it was a good example.

I was just wondering if the highly paid resource was not performing in that position, may be he could do better in another, but you said you did check his past record, so I think that puts the concern at rest.

And yes it makes no point keep paying someone who does not perform.



Regards,
Amit

Pradeep Soundararajan said...

@Amit,

And yes it makes no point keep paying someone who does not perform.

I learned from my previous boss that if a person is not performing maybe it is because of the environment of the office. Firing is easier than changing the environment.