TrainingConferencesAbout UsContact UsAdvertiseSQE.com

StickyMinds.com: brain food for building better software

Join

Join

Clarify Your Search Criteria
Tips on Using Our Search Feature(s)
StickyMinds.com Home
ResourcesEventsTopicsPowerPassJobs
Software Testing & QA Online Community  >  Detail: The Tyranny of the "To Do" List


Viewing Item 1 of 680


A StickyMinds.com Original
Article Picture
The Tyranny of the "To Do" List

By Elisabeth Hendrickson

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: We create lists to help us prioritize tasks and stay on schedule. Sometimes those lists help us accomplish those tasks faster. Sometimes those lists simply chain us to an archaic way of doing things. Having a “To Do” list is a good thing if you don’t let it prevent you from thinking outside the box. In this week’s column, Elisabeth explains why the agenda items that don’t make the list can often be some of the most important.


ASTQB
I have a "To Do" list. Actually, I have several. I have Web site update "To Do" lists and "Client To Do" lists and "Writing To Do" lists. But I digress. 
 
Every time I make a commitment, I try to remember to put an item onto the appropriate "To Do" list. My usual habit is to remove items from the list only once they are complete. And that means that my "To Do" list can get very backed up. I often struggle with the feeling that I must complete everything on my "To Do" list, an impossible task. Worse, I sometimes feel required to finish certain onerous "To Do" list items before I move on to the more interesting tasks on my plate. Some of the onerous tasks may be less strategically important than the fun ones, but they’re on my "To Do" list, so I feel they must be done. The end result in some cases is that neither the onerous nor the fun tasks get done. I’m stuck.  
 
In the worst cases, I've had to throw out that "To Do" list and start over. This is not ideal—I'm throwing out the good with the bad. But sometimes it's the only way to get myself unstuck. A better approach is to comb through the "To Do" list, plucking out those items that truly still need to be done and then tossing the rest. But by the time I get stuck, I’m incapable of doing even this kind of weeding. The whole list has to go.  
 
When I let myself get stuck on a handful of "To Do" list items, I am suffering from the tyranny of the "To Do" list. I am allowing my life to be run by line items stored in my planner. That just doesn't work. I can't allow my "To Do" list to run the show. Yet I see the same kind of "To Do" list tyranny happen in some test departments. "We have the test in our suite, we have to run it," they say. "No, we can't add more tests. No, we can't improvise. This test is here; it must be run. It leaves no time for any other testing." What a sad situation.  
 
There are an infinite number of tests we can run. Of those, some are more likely to yield interesting information than others. In testing, we're after the interesting information. Unfortunately, some test suites seem specifically designed to not find out anything interesting. The documented tests might have been interesting two years ago, but they yield no new information now. Wouldn't it be a shame to miss a serious bug because we’re too busy running the planned tests?  
 
Think it can't happen? I've seen it. For that matter, I've done it. I've seen entire departments slog through the tests cases in their documented test suites because they were "supposed to," all the while bemoaning the fact that they didn't have time to do the interesting testing. In one such organization, one tester argued with her manager for the freedom to run some unplanned tests. "No," said her manager. "If you think it's important enough to run, it's important enough to document. Put it in the test case database, and then you can run it." Mindful of the time these updates were taking, the tester only added those tests she thought were most critical.  
 
As a result she nearly missed a showstopping bug. Fortunately for her project, she found it just in time—because she deviated from her test suite while testing a bug fix. Her manager finally relented. He gave her a little time to do exploratory testing. He wondered if she could she put an item in the test case database called "Exploratory Testing," though. This is the problem with following "To Do" lists.  
 
"To Do" lists are a guide. When used well they help prioritize tasks. When they're allowed to take over, they become a trap, forcing list followers to do things that are no longer important. Test suites are also a guide. They point us to areas that we must test. Our test suites remind us of all the ways in which we agreed to exercise the software before shipping. We need to pay attention to those tests suites without allowing them to overcome our good judgment.  
 
Just as I'm learning to treat my "To Do" list as a guide rather than a rule, let me suggest that you let go of the documented tests long enough to figure out if they really are the most important. Try unexplored scenarios. Look at the software from a new perspective. Do crazy things you think no sane user would ever try.  
 
Your team could be suffering from the Tyranny of the Test Suite if you’re ignoring certain testing tasks in favor of running predefined tests. Veer away from the established path for a time so you can come back and look at your test suite with fresh eyes. Does it truly contain the best and most important tests? Or has it become a petty tyrant forcing you to waste time on unimportant activities?


About the Author
Elisabeth Hendrickson (esh@qualitytree.com) is an independent consultant specializing in software quality assurance and management, with fifteen years of experience working with leading software companies. You can read more about her ideas on quality and testing at www.qualitytree.com.

Back to Top
 

StickyMinds.com Weekly Column From 9/8/03 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Danny Faught 9/9/2003

Elisabeth, I know just what you're talking about! I had a personal to-do list that grew to several pages long, and the only way out was to trash it and start over. Then my wife got me a small whiteboard that we put on the refrigerator. My to-do list goes there now. If it's full, I have to erase something that's a lower priority to make room for it. If something I erase is important enough, it'll come up again sooner or later. Or maybe not. I'm now doing the same thing in my office. To-do lists should not be allowed to grow indefinitely. The same logic should apply to test suites.

Author's Response:
9/11/2003    
Hi Danny, I like your whiteboard trick. (My problem is that I'd start writing smaller and smaller. Do they make ballpoint dry erase markers?) I think your point about not allowing test suites to grow indefinitely is a good one. I'm a firm believer in retirement plans for old, weak tests.

 
 
Comment:    
by Andrew Raybould 9/9/2003

Elisabeth, The first response to the examples you give is that more automated testing is called for, but you also make it clear that management probably wouldn’t see how to use it to make testing smarter. The bigger issue is that of how testing is perceived.

What you describe is one symptom of the stultifying bureaucracy that passes for software engineering in too many organizations, and which has its roots in that common mistake of taking a good idea too far. In this case, the good idea is that well-defined procedures are important; this becomes an assumption that the process is the only thing that matters, that following the process...Read On

Author's Response:
9/11/2003    
Hi Andrew, "stultifying bureaucracy" is such a beautiful phrase! Thank you very much for your comments!

 
 
Comment:    
by Keith Collyer 9/9/2003

Two topics. First on ToDo lists. I have been a bit of a Time Management junkie, reading just about everything available and trying out all sorts of systems. The only one I have found really works for me is Getting Things Done from David Allen (www.davidco.com). Onto testing. It is important that you carry out the tests in the test suite, so long as these are relevant. For acceptance tests, are they derived from the USER (business, stakeholder, etc.) requirements. For system tests, are they derived from the SYSTEM (functional, etc.) requirements, and so forth. But, of course, there is still a need for a certain degree of creativity. The...Read On

Author's Response:
9/11/2003    
Hi Keith, thanks for the pointer! Like you, I've seen test suites that only look at the happy path in the software, ignoring the things that might go wrong. I've also seen test suites that are essentially a direct copy of the requirements with the words "Verify that" thrown in front of each item. Neither tend to be terribly effective. I agree that software (never, ever people, just software) needs to be mistreated to find out what it's really capable of! :-)

 
 
Comment:    
by Gerold Keefer 9/8/2003

elisabeth, yes and no. full agreement that sticking to the plan/list/test suite is a rule that comes with exceptions. it is good common sense to deviate from the plan sometimes. however, if "deviating" becomes the norm, chances are high the initial planning is avoided as well - welcome to CMM level 1 ...

Author's Response:
9/11/2003    
Hi Gerold, thanks for your comments! I think that if deviating becomes the norm, there may be many explanations. Poor planning is one. Emerging requirements or an overwhelming quantity of possible tests due to a high degree of complexity are two more. In any case, if the organization intended to do good up front test design and discovers that deviating from the plan tends to yield more interesting results, I agree that it's worth examining the planning process to find out why that might be so.

 
Back to Top



 
Ads By Google
What's This?
 
 



About Us   |   Contact Us   |   Terms & Conditions   |   Privacy Policy   |   RSS Feed



© 2013 StickyMinds.com. All rights reserved.
ASTQB

Tricentis



Agile Development Conference & Better Software Conference West