Testing Blog

The 7 Plagues of Software Testing

Monday, June 22, 2009
Share on Twitter Share on Facebook
Google
Labels: GTAC , James Whittaker

23 comments :

  1. UnknownJune 22, 2009 at 1:50:00 PM PDT

    Very true.

    As a tester, while testing we need to pause and ponder over the direction, capture and go on building the knowledge, which helps the process (apart from the individuals)...not just for the team, or organisation but for the testing community from where we have learned many many things.

    Writing about it is much easier than done. However being aware is like half battle won.

    Knowledge building will be a continuous process. Sometimes, for its applicability, we need to remove specificness w.r.t. bug, project, domain, etc. and make the content more generic to begin with. That's how other disciplines of engineering have been able to come this far.

    ReplyDelete
    Replies
      Reply
  2. UnknownJune 22, 2009 at 4:27:00 PM PDT

    You suggest grabbing a 'testing spell book', but from a 'Grand Wizard' like you, what spell books should we pick up?

    ReplyDelete
    Replies
      Reply
  3. UnknownJune 22, 2009 at 9:46:00 PM PDT

    An excellent post, I'm sharing this with my colleagues as we speak. Some good "a-ha" moments in here when I realize that I sometimes "just do it".

    ReplyDelete
    Replies
      Reply
  4. Preston RedlonJune 22, 2009 at 10:17:00 PM PDT

    So very very true. I wish I had that 'lore' during my early days. I struggled and am struggling still. I have tried to pass on my knowledge/collections at Software Testing Fundamentals Blog. I feel we, Software Testers, need to open up more and feel dignified.

    ReplyDelete
    Replies
      Reply
  5. JoeJune 23, 2009 at 4:31:00 AM PDT

    "Be their wizard. Build a testing spell book and share it with others on your team. Over time you’ll banish the plague of aimlessness."

    No thanks!

    Perhaps for you, testing is sorcery. Perhaps incantations are what you teach. Perhaps spells and numerology should be future subjects for your writings.

    But for me (and I suspect most of us), testing is all about our business.

    Instead of incantations, I want people to think.

    Instead of spells, I'd suggest knowledge and practice.

    Instead of praying to the mystical, invisible "crowd", I'd suggest hiring professionals.

    Testing isn't magic. It's hard work, knowledge and skill. Magical thinking cannot help move testing forward as a profession.

    I feel sorry if your testing is aimless. Mine isn't. My team's testing is far from aimless. And that of most testers I know isn't aimless.

    -joe

    ReplyDelete
    Replies
      Reply
  6. Brent PaineJune 23, 2009 at 6:49:00 AM PDT

    I have to disagree. I think there is plenty of lore. In my case, using this "lore" is extremely important.

    I manage a very small group of testers. Half of my group is made up of interns who, most of the time, have absolutely no experience in testing at all. Many times I can persuade them to come back for another term, but how can I teach you how to test in a matter of a month or less? So you can be effective for me?

    Well, aside from mentoring (Wizard and Apprentice), my team sits down for a half hour or 45 minutes every day for a "brag session". To put it in terms of your lore, think of it as a group of warriors sitting down at a wodden bar table and telling their tales of battle over a dirty mug of grog.

    We don't have a lack of lore in testing, we just don't spread the information as well as some. Soem people I talk to claim they don't have a half hour a day to spend in a brag session with their team, but, from my experience, I can't afford NOT to have a half an hour a day with my team.

    ReplyDelete
    Replies
      Reply
  7. UnknownJune 23, 2009 at 7:01:00 AM PDT

    I have to jump on the disagreement bandwagon, I've not resorted to lore since I started in the mid-90's. Since then I have pursued a body of knowledge that helps me find the business and customer, needs of the product I am testing. To me its all been about the communication, we have plenty of voices speaking out there about testing, and how to test, but its a cacophony, Maybe if people get off their own bandwagons, and dogma, and speak to each other instead of over each other we'll get that body of knowledge.

    There are points you bring up that everyone who works in this industry should be aware of.

    "We test because we must or our manager tells us to do so."
    Well it is what we are hired to do, but the reason we were hired is because we have the aptitude to look for issues and think outside of the code. My manager may tell me to do the work, but its work I want to do, and am excited to do it.

    "We automate because we can or because we know how to, not because it is part of some specific and proven strategy and certainly not because our lore dictates it."
    I think this is the problem with most automation, it is not planned and haphazard, unless you treat it like a software project its going to fail. There is plenty out there about this already.

    "When a hunter makes a kill, they remember the terrain and circumstances."
    When I test a product I should have known what my prey and terrain are through careful planning, the Test Plan, and as I have learned from my hunt, my updates to the plan, it should be able to help me next time. This is what I think of when it comes to test experience.

    ReplyDelete
    Replies
      Reply
  8. James WhittakerJune 23, 2009 at 8:53:00 AM PDT

    Sorcery isn't as easy as you make it out to be. Wizards spend their lives studying and practicing their discipline. It only seems like magic because you haven't seen all the practice that goes into it. Magic is the art of making knowledge and skill look easy. If your processes are more mature in this manner then call it magic/lore/knowledge/discipline but share it with the rest of the world please. I like the idea of a 'brag session' as a concept but I don't like the name.

    ReplyDelete
    Replies
      Reply
  9. JoeJune 23, 2009 at 9:57:00 AM PDT

    Those who think most testing is aimless, or that sorcery, illusion, spells, incantations, folklore, magic, hocus-pocus, or wizardry are needed for teaching testers should get their hands on:
    "Lessons Learned in Software Testing", "How We Test Softare at Microsoft", or "Effective Software Testing: 50 Specific Ways to Improve Your Testing"

    No magic there, just real-world, practical advice.

    ReplyDelete
    Replies
      Reply
  10. UnknownJune 23, 2009 at 2:36:00 PM PDT

    A lot of this talk of magic makes me think of the line "any sufficiently advanced technology is indistinguishable from magic".

    Actually one of the first things I do when I join a company, as the first tester, or as part of a group is find the wiki - local document repository. Everything I do, or can do, is documented in some form for others to use, after I left one company I heard from a Developer months later who thanked me for that as he needed to do something I rarely did and no one remembered how to do; yet my document gave step by step instructions. I've done monthly QA talks as a way to share with others, even getting others on the team to sign up and share.

    I guess I wouldn't so much say that its all Lore, but rather isn't it better not to hoard the information? I like the Agile concept of Information Radiators, and try to implement them in any fashion possible whenever I can.

    ReplyDelete
    Replies
      Reply
  11. Preston RedlonJune 24, 2009 at 1:40:00 AM PDT

    Well, what the gist of what James says and the 'disagreement bandwagon' say is the same, I think: We need to communicate, we need to share our knowledge.

    How we choose to do that might differ but a Tome and an Information Radiator are the same in essence.

    ReplyDelete
    Replies
      Reply
  12. JulianHartyJune 24, 2009 at 5:57:00 AM PDT

    Books such as "Lessons Learned in Software Testing" codify some of the lore learnt by software testing professionals.

    I'd like to encourage more of the blog readers to share experiences of their testing techniques and practices.

    ReplyDelete
    Replies
      Reply
  13. Brent PaineJune 24, 2009 at 7:39:00 AM PDT

    Hey James!

    Thanks for the comment. Yeah, the "brag session" thing has actually worked well for our team. I haven't tested it in a larger environment, where I think it may be less feasible to do in a half hour.

    In the case of a smaller team, maybe a "brag box" could be another idea. So you can still gather the team for a half hour a day. However, throughout the day, if someone finds something and it makes them laugh or they think they did something extraordinary in order to find the issue, have a "brag box" accompanied with some 4x6 cardstock cards that they can write it down on and drop it in the box. Then the Manager should decide what is appropriate for that day, or ever for that matter, and they can organize the submissions into something more fluid, so there are no 10 minute ventures off into the woods by any one person.

    I agree, "brag" is a little sucky. I just haven't come up with a better name for it as of yet.

    As for your comment on sorcery, I found it pretty interesting. I mean I've always just found these scrolls and tomes lying around or in treasure chests and stuff like that. Then I read them and BAM! I know something new. However, you need to actually look above your head really quick so you know what you learned because the text will disappear after 3 or 4 seconds. I mean there would be nothing more embarassing than thinking you don't know magic missle and immitating some other wizard in the bar and you're like, "muahahahaha, I cast MAGIC MISSLE!" and they you send a magic missle right through the side of the wall or something, or worse kill someone.

    You know, because if you kill someone who's good, then you're automatically relegated to black magic and they have this WHOLE set of other complex rules, like you must know Curse Level 2 and you need to wear the skull of some dead animal around your neck, or you need to be open to the idea of summoning the evil lord. Being good is just so much easier.

    ReplyDelete
    Replies
      Reply
  14. Kumar McMillanJune 24, 2009 at 11:01:00 AM PDT

    This is a great post. Recently some members on my team were fighting the fact that we had all these stub controllers for testing the user interface. The controllers did nothing and created unnecessary maintenance, they said. Soon I realized that I had not explained well enough how the stub controllers were there in order isolate the user interface from the rest of the system so we could pinpoint failures easier. Aha, they said.

    ReplyDelete
    Replies
      Reply
  15. UnknownJune 25, 2009 at 5:52:00 AM PDT

    Spellbook = WIKI

    ReplyDelete
    Replies
      Reply
  16. AnonymousJune 25, 2009 at 7:52:00 AM PDT

    The testing slogan should be "Just do it yourself (with a little help from your friends!)".

    I see the point on sorcery, magic, and lore. I have rarely worked with selfish individuals so I have had great experiences working to obtain knowledge from others.

    However, it gets to the point where you need to learn on your own. Isn't that what we're all supposed to do?

    I like the book recommendation. Lessons Learned is a good book but doesn't provide anything close to all the answers. To be a great tester you must be a great software engineer. Too often we focus on just testing or its techniques and lose sight of the greater goal: The Software System .

    Sharing is great and you should always allow time to provide guidance when needed. I currently assist several junior testers and some not so with information they need to do their job correctly. Do I have the time to do so? Not really. However, it's magical to be able to assist others.

    The best learning is obtained while teaching.

    ReplyDelete
    Replies
      Reply
  17. Alec MunroJune 30, 2009 at 8:03:00 AM PDT

    This feeds into a topic that I've been pondering for while.

    Test automation, by and large, ends up being a very domain-specific exercise. This is because software developed to solve a problem becomes a domain of it's own, and then we create another layer of software (automated tests) to solve the problems of that domain.

    So most test automation "lore" ends up being very domain specific. For example, we often have to scrape screenshots for text or bitmap fragments, and there are dozens of things that can cause this to fail. Almost all of them are specific to the software being tested. So if we adapt our tests to compensate for these, they become more and more specific to the problem domain.

    As this progresses, our "lore" becomes inherently more arcane, and seemingly less useful, which means it is less likely to be recorded properly.

    Now, much of this occurs because automated testing software is not treated as software itself, but rather as a side-effect. So maintainability and extensibility tend to be second class citizens when it comes to development.

    The net effect of this, in large organizations, is that there is very little re-use across automated testing projects, and they tend to get scrapped once the problem domain they are solving becomes less important, or is rewritten.

    We are currently working on a project to establish a common platform for automated testing, and I may attempt to give a GTAC presentation about it. Anyone interested?

    ReplyDelete
    Replies
      Reply
  18. MauraJune 30, 2009 at 6:33:00 PM PDT

    This is actually quite interesting to me as my first book on software testing was actually written as a sort of spellbook on testing security.

    The reasoning behind what was being tested, then case studies, then suggestions of testing techniques and resources.

    I would put forth, however, that as long as testing is regarded as something anyone can do if they can write code (as it is by some companies), the less the need for this passing of knowledge is acknowledged.

    ReplyDelete
    Replies
      Reply
  19. Eccentric AbhilashJune 30, 2009 at 8:56:00 PM PDT

    Very true. Very true. Well said and you took the guts to say just that. There are many masters out there who reinvented the wheel themselves but have shied away from sharing with others the intricacies of testing. Software development basically being a team effort, we should see to it that like minded people could come together and share their experiences (both good and bad) among the testing fraternity.

    Kudos to you for this post. For all those testers out there, you could refer to my post for any basics of testing you may need.

    Go to Software testing Basics

    ReplyDelete
    Replies
      Reply
  20. AnonymousJuly 1, 2009 at 7:06:00 AM PDT

    Any analogy fails if you push it too far, but the best analogies give real insight; perhaps even unexpected insight.

    If we look away from the pages of the Dungeon Master's Guide for knowledge on how sorcery was actually used we will see a history of ever more bizarre failure. Most of the time, magic does not work, some of the time it at least appears to and so the practitioners try to determine what was important, what contributed to the success, what could make it better. Testing is too much like that. There is a body of lore, but little empirical evidence. Just look at Software Inspections, running full inspections is as difficult as high magic and just as expensive and yet how much real evidence is there to support all of these arcane practises?

    As with hitorical magical schools, the would-be testing adept will happily jump on whatever new craze comes along, desperate for effect. Has anybody tried Test Point Analysis? Smoke and mirrors comes to mind. What about Exploratory Testing? Obviously I can't see the benefits because I'm not a good enough tester, insufficiently refined.

    How much test effort is wasted effort? How much time do we spend on validation/positive testing when we should be looking for problems? How much effort do we put into automation? What returns have we seen? Why do we not know? Why don't we collect real, useful data?

    As surely as alchemy became chemistry software testing must improve, I just hope we don't have to sacrifice all the unicorns before we get there.

    ReplyDelete
    Replies
      Reply
  21. TroyJuly 2, 2009 at 1:00:00 PM PDT

    I am on the disagree bandwagon myself. Testing may be "magic" in some organizations but not mine. Every test we write and run has a well defined purpose. Every day we learn new things that we share in our daily meetings and every project produces lessons learned that feed our knowledgebase and are used to refine and improve our internal best practices.

    ReplyDelete
    Replies
      Reply
  22. Regi JohnJuly 5, 2009 at 4:25:00 PM PDT

    My read of James' testing sorcery analogy is that we need to continue to move from the days of the Alchemy of Testing, to the Chemistry of Testing.

    The testing community has clearly come a long way since Glenford Myer's "The Art of Software Testing".

    That said, there will always, IMO, be a certain level of magic involved in testing. That thing that cannot be defined. Call it inspiration. Call it creativity. Call it sorcery. There is always that something special that separates a master practitioner, from a mere dilettante.

    ReplyDelete
    Replies
      Reply
  23. ReinderJuly 14, 2009 at 1:36:00 AM PDT

    completely do not agree as a software tester myself. When I test, I do it with a purpose and with the knowledge of the people who went before me as every professional should (be it testing, development or design). Maybe this is the way that Google likes to test (we need to test; oe, lets program something to test it with, not caring what the coverage or thought behind it is).

    Don't get me wrong; I like google, but not their view of testing (what do you mean testing engeneer? That's just ike a developer who does testing....). They should take a look at what the profession of software testing really means and that is to test if the requirements of the client are being met; Will he get the program he asked for with the quality required...nothing more, nothing less....

    There are some lores around the world as far as I know (Take TMap for example), but as it is with any profession, there is always someone who does not agree with this and goes his own way....

    ReplyDelete
    Replies
      Reply
Add comment
Load more...

The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.

  

Labels


  • TotT 104
  • GTAC 61
  • James Whittaker 42
  • Misko Hevery 32
  • Code Health 31
  • Anthony Vallone 27
  • Patrick Copeland 23
  • Jobs 18
  • Andrew Trenk 13
  • C++ 11
  • Patrik Höglund 8
  • JavaScript 7
  • Allen Hutchison 6
  • George Pirocanac 6
  • Zhanyong Wan 6
  • Harry Robinson 5
  • Java 5
  • Julian Harty 5
  • Adam Bender 4
  • Alberto Savoia 4
  • Ben Yu 4
  • Erik Kuefler 4
  • Philip Zembrod 4
  • Shyam Seshadri 4
  • Chrome 3
  • Dillon Bly 3
  • John Thomas 3
  • Lesley Katzen 3
  • Marc Kaplan 3
  • Markus Clermont 3
  • Max Kanat-Alexander 3
  • Sonal Shah 3
  • APIs 2
  • Abhishek Arya 2
  • Alan Myrvold 2
  • Alek Icev 2
  • Android 2
  • April Fools 2
  • Chaitali Narla 2
  • Chris Lewis 2
  • Chrome OS 2
  • Diego Salas 2
  • Dori Reuveni 2
  • Jason Arbon 2
  • Jochen Wuttke 2
  • Kostya Serebryany 2
  • Marc Eaddy 2
  • Marko Ivanković 2
  • Mobile 2
  • Oliver Chang 2
  • Simon Stewart 2
  • Stefan Kennedy 2
  • Test Flakiness 2
  • Titus Winters 2
  • Tony Voellm 2
  • WebRTC 2
  • Yiming Sun 2
  • Yvette Nameth 2
  • Zuri Kemp 2
  • Aaron Jacobs 1
  • Adam Porter 1
  • Adam Raider 1
  • Adel Saoud 1
  • Alan Faulkner 1
  • Alex Eagle 1
  • Amy Fu 1
  • Anantha Keesara 1
  • Antoine Picard 1
  • App Engine 1
  • Ari Shamash 1
  • Arif Sukoco 1
  • Benjamin Pick 1
  • Bob Nystrom 1
  • Bruce Leban 1
  • Carlos Arguelles 1
  • Carlos Israel Ortiz García 1
  • Cathal Weakliam 1
  • Christopher Semturs 1
  • Clay Murphy 1
  • Dagang Wei 1
  • Dan Maksimovich 1
  • Dan Shi 1
  • Dan Willemsen 1
  • Dave Chen 1
  • Dave Gladfelter 1
  • David Bendory 1
  • David Mandelberg 1
  • Derek Snyder 1
  • Diego Cavalcanti 1
  • Dmitry Vyukov 1
  • Eduardo Bravo Ortiz 1
  • Ekaterina Kamenskaya 1
  • Elliott Karpilovsky 1
  • Elliotte Rusty Harold 1
  • Espresso 1
  • Felipe Sodré 1
  • Francois Aube 1
  • Gene Volovich 1
  • Google+ 1
  • Goran Petrovic 1
  • Goranka Bjedov 1
  • Hank Duan 1
  • Havard Rast Blok 1
  • Hongfei Ding 1
  • Jason Elbaum 1
  • Jason Huggins 1
  • Jay Han 1
  • Jeff Hoy 1
  • Jeff Listfield 1
  • Jessica Tomechak 1
  • Jim Reardon 1
  • Joe Allan Muharsky 1
  • Joel Hynoski 1
  • John Micco 1
  • John Penix 1
  • Jonathan Rockway 1
  • Jonathan Velasquez 1
  • Josh Armour 1
  • Julie Ralph 1
  • Kai Kent 1
  • Kanu Tewary 1
  • Karin Lundberg 1
  • Kaue Silveira 1
  • Kevin Bourrillion 1
  • Kevin Graney 1
  • Kirkland 1
  • Kurt Alfred Kluever 1
  • Manjusha Parvathaneni 1
  • Marek Kiszkis 1
  • Marius Latinis 1
  • Mark Ivey 1
  • Mark Manley 1
  • Mark Striebeck 1
  • Matt Lowrie 1
  • Meredith Whittaker 1
  • Michael Bachman 1
  • Michael Klepikov 1
  • Mike Aizatsky 1
  • Mike Wacker 1
  • Mona El Mahdy 1
  • Noel Yap 1
  • Palak Bansal 1
  • Patricia Legaspi 1
  • Per Jacobsson 1
  • Peter Arrenbrecht 1
  • Peter Spragins 1
  • Phil Norman 1
  • Phil Rollet 1
  • Pooja Gupta 1
  • Project Showcase 1
  • Radoslav Vasilev 1
  • Rajat Dewan 1
  • Rajat Jain 1
  • Rich Martin 1
  • Richard Bustamante 1
  • Roshan Sembacuttiaratchy 1
  • Ruslan Khamitov 1
  • Sam Lee 1
  • Sean Jordan 1
  • Sebastian Dörner 1
  • Sharon Zhou 1
  • Shiva Garg 1
  • Siddartha Janga 1
  • Simran Basi 1
  • Stan Chan 1
  • Stephen Ng 1
  • Tejas Shah 1
  • Test Analytics 1
  • Test Engineer 1
  • Tim Lyakhovetskiy 1
  • Tom O'Neill 1
  • Vojta Jína 1
  • automation 1
  • dead code 1
  • iOS 1
  • mutation testing 1


Archive


  • ►  2025 (1)
    • ►  Jan (1)
  • ►  2024 (13)
    • ►  Dec (1)
    • ►  Oct (1)
    • ►  Sep (1)
    • ►  Aug (1)
    • ►  Jul (1)
    • ►  May (3)
    • ►  Apr (3)
    • ►  Mar (1)
    • ►  Feb (1)
  • ►  2023 (14)
    • ►  Dec (2)
    • ►  Nov (2)
    • ►  Oct (5)
    • ►  Sep (3)
    • ►  Aug (1)
    • ►  Apr (1)
  • ►  2022 (2)
    • ►  Feb (2)
  • ►  2021 (3)
    • ►  Jun (1)
    • ►  Apr (1)
    • ►  Mar (1)
  • ►  2020 (8)
    • ►  Dec (2)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Aug (2)
    • ►  Jul (1)
    • ►  May (1)
  • ►  2019 (4)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Jul (1)
    • ►  Jan (1)
  • ►  2018 (7)
    • ►  Nov (1)
    • ►  Sep (1)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (1)
    • ►  Feb (1)
  • ►  2017 (17)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Sep (1)
    • ►  Aug (1)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2016 (15)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (1)
    • ►  Sep (2)
    • ►  Aug (1)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (1)
    • ►  Mar (1)
    • ►  Feb (1)
  • ►  2015 (14)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Aug (1)
    • ►  Jun (1)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (1)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2014 (24)
    • ►  Dec (2)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Sep (2)
    • ►  Aug (2)
    • ►  Jul (3)
    • ►  Jun (3)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2013 (16)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Aug (2)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (2)
    • ►  Jan (2)
  • ►  2012 (11)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (1)
    • ►  Aug (4)
  • ►  2011 (39)
    • ►  Nov (2)
    • ►  Oct (5)
    • ►  Sep (2)
    • ►  Aug (4)
    • ►  Jul (2)
    • ►  Jun (5)
    • ►  May (4)
    • ►  Apr (3)
    • ►  Mar (4)
    • ►  Feb (5)
    • ►  Jan (3)
  • ►  2010 (37)
    • ►  Dec (3)
    • ►  Nov (3)
    • ►  Oct (4)
    • ►  Sep (8)
    • ►  Aug (3)
    • ►  Jul (3)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (3)
    • ►  Mar (3)
    • ►  Feb (2)
    • ►  Jan (1)
  • ▼  2009 (54)
    • ►  Dec (3)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (5)
    • ►  Aug (4)
    • ►  Jul (15)
    • ▼  Jun (8)
      • The plague of repetitiveness
      • The 7 Plagues of Software Testing
      • GTAC: Call for Proposals
      • Google Test Automation Conference 2009 - Zurich, S...
      • Burning Test Questions at Google
      • I'm a Googler now
      • James Whittaker joins Google
      • My Selenium Tests Aren't Stable!
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (5)
    • ►  Jan (4)
  • ►  2008 (75)
    • ►  Dec (6)
    • ►  Nov (8)
    • ►  Oct (9)
    • ►  Sep (8)
    • ►  Aug (9)
    • ►  Jul (9)
    • ►  Jun (6)
    • ►  May (6)
    • ►  Apr (4)
    • ►  Mar (4)
    • ►  Feb (4)
    • ►  Jan (2)
  • ►  2007 (41)
    • ►  Oct (6)
    • ►  Sep (5)
    • ►  Aug (3)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (7)
    • ►  Mar (5)
    • ►  Feb (5)
    • ►  Jan (4)

Feed

  • Google
  • Privacy
  • Terms