Monday, March 10, 2014

Testing Timeline: What is your %

Do you test software? Do you test every day? Do you get paid for it?
If you answered yes to any of the two questions, I have one more question for you :)
What percentage of office time do you actually test (interact with the software)?
The answer to 'Testing includes...' might differ from one person to another. I don't want to get into that discussion right now. I am more concerned when people spend very little time interacting with the product and complain of bugs being found by the customer. Consider the following three scenarios:

Scenario 1:
A feature has been revamped and will be released to market soon. A tester who has never worked on the feature is called to test the revamp. The tester could:
  • Understand the existing feature
  • Understand the revamp
  • Analyze the XYZ specification
  • Write test cases
  • Test the feature and file bugs
  • Test the system
Scenario 2:
Your team reaches office at 9am and is available till 6pm.
The total time spent testing the product on an average is 3 hrs. Rest of the time is spent on the following:
  • Attending meetings
  • Updating KnowledgeBase pages
  • Plan for next release
  • Taking interviews
  • Document the learning
Scenario 3:
Here is a tester who refuses to follow the rules. She never attends any meeting unless her inputs are a must-have. If she wants to learn anything, she knows the right person who can help her. She is very good at networking and has lots of friends in the whole company. She has one bad habit though, as her colleagues mention. No - not the one about rules, when she is given a feature to test, she spends most of the time interacting with the feature. Her activities can be summed up as follows: 
  • Understand the mission quickly
  • Highlight the traps and risks
  • Test the feature, system
  • Use information from different sources as a heuristic
  • Get help from those who can help her
What is your take on 'How much should you INTERACT with the feature/product/system?'
If you are smart enough, I would expect your answer to start with
.
.
.
.
.
.
.
.
.
'It Depends...' and continue the discussion. At the same time, I am open for new answers.

8 comments:

Rob DeRosia said...

The answer to your question really depends on what your role is.

If you are strictly a manual, scripted tester, then I would expect you to spend a lot of your time testing the software.

However, most people are not manual, scripted testers. If you have interest in growing your career as a software quality professional, you probably do much more than test the software. For instance, documenting test cases, creating and tracking defects, managing test environments, conducting root-cause analysis, etc. are all things I expect a quality professional to do.

Also, I would argue that the more time we spend up front understanding the software, the less time we might waste later on testing things that are lower priority.

To answer your original question, I would say I spend roughly 25% of my time interacting with the software.

Atul Chauhan said...

Hi Ajay,I think i should consider myself in scenario 2.mostly in office,team spend time in lots of meeting & understanding of Application.I think maybe due to transitioning phase of project .Generally i saw my most of friends are in scenario 2.
Hey thanks for writing those books that's really helpful...

Rajesh R said...

It depends on the risk of the product and process of the company,if we have only less time,we cant able to have lot of meeting and other discussion,

Rajesh R said...

It depends on the Risk of the project / Product & process of the company, if we have only less time and resource, then there will be only less no. of meetings and other discussions

Wasiqul Huq said...

Hi Ajay, it is a nice post, you highlighted out a significant point.

bharani. r said...

It's a really good blog us to interact with the software more intimately. Revamp tester quite difficult for Interacting and Analysing with the feature I think so because new environment, new ideas to implement. I hope this blog gives the ideas with scenarios. Mainly, the Heuristics to follow up, http://www.qualityperspectives.ca/resources_mnemonics.html Thanks Ajay, I got initiative to know about the technical word Revamp “A tester who never worked on the feature”&I came to know about the different heuristics, mnemonics. I am quite worthwhile to follow the Mnemonic to jump-start testing SFDPO Heuristic for exploratory. Happy Testing!

Anonymous said...

It's a really good blog us to interact with the software more intimately. Revamp tester quite difficult for Interacting and Analysing with the feature I think so because new environment, new ideas to implement. I hope this blog gives the ideas with scenarios. Mainly, the Heuristics to follow up, http://www.qualityperspectives.ca/resources_mnemonics.html Thanks Ajay, I got initiative to know about the technical word Revamp “A tester who never worked on the feature”&I came to know about the different heuristics, mnemonics. I am quite worthwhile to follow the Mnemonic to jump-start testing SFDPO Heuristic for exploratory. Happy Testing!

Anonymous said...

Too much of Processes & meetings also killing most of our time. I agree that Processes & documenting things are important but it should not affect our interaction time with our AUT.