Anyway, here is my problem…every 3-5 days, performance on my machines gets really sluggish.  A quick check shows that about 90% of my 4 Gigs…yeah, FOUR GIGS…of memory are actively in use.  I then proceed to shut down every application running.  Nothing gets better.  Most times, by the time I notice the degraded performance, I cannot even get all the apps to shut down, and am forced to reboot…Hard.

Now I have researched this, and I understand the official position that Win7 actively seeks to not waste memory…if any memory is free, it will use it for cache or some such, always seeking to improve your performance.  Free memory is wasted memory.  And in theory, I agree with that…but when my computer consistently slows to a crawl every 3-5 days, then the theory and the reality are in conflict.

So it happened to me again today.  I did manage to get all the apps closed down this time, and got the resource manager open.  This is how things looked.

My Resource Manager with NO apps running

By the way, I shut down all the apps and then left the machine alone for over three hours to let it try and fix itself.  I find it really difficult to believe that with no apps running (and I know there are things running, but no ‘User Interface” apps, ok?) that Win7 needs an entire 3.5 gigs of memory to do something, anything, in the background.  And right after I saved this screenshot, everything locked up, and I had to reboot again.  When I tried to do a soft reboot, Windows refused…it said a background program would not shutdown.  The offending background program?  Program Manager.

Also, I have checked the top nine memory consumers in the above list…Notice, no matter how I sort them, Committed, Private, Working Set, or Shareable, the order may shift around, but these are always the top 9.  What do we have there?  5 SvcHost.exe, which translates into an application or group of applications that is explicitly running in such a way as to avoid being identified…a haven for a litany of crap windows keeps dumping on us as well as viruses, but because the mechanism is valid, it is nearly impossible for Joe Average to figure out and deal with what highly obfuscated stuff may be encapsulated therein.  Ekrn is my virus scanner, something I simply won’t be turning off, largely in part to the previous comment.  DWM, that part of windows that is responsible for all the visual magic such as Aero, task bar preview, and the Roll-O-Dex app switcher;  sadly, turning all that crap off will do next to nothing to decrease the actuall resources consumed by DWM.  SearchIndexer, which as much as I may not like it being there, and taking lots of resources, is the only practical solution I currently know to 1/2 TerraByte hard drives.  And finally PerfMon, which I had to run to get to Resource Manager to get this screenshot…Windows telling me how bad it is at telling me how bad it is.

So to summarize, that is Windows, Windows, Windows, Windows, My Virus Scanner, Windows, Windows, Windows and Windows.  Hmmm…

Okay, enough of that.  I don’t wanna complain…I wanna solution.  So, if you have any supporting stories that may shed light on my problem…if you have fixed such a problem on your own…or if you just wanna tell me I am full of crap…let me know what you think.  Thanx.

David

Now I have been tasked with creating the test plan…THE Test Plan…(Trumpets sound, the clouds part, a golden chalice descends from heaven containing a scroll upon which is written The Test Plan…you get the picture)… for a new upcoming project. And, since it is a large organization with lots of projects going on, and they like for their official documentation to have a consistent look and feel, there is a template for the test plan. Okay, no problem with that. So I go open the template to start crafting the test plan. The template…the empty structure, devoid of any meaningful input at all…is already 28 pages long. My response to this was not positive.

And to make matters worse, I really do not have much good information to put into the test plan, because, primarily, communication and collaboration among the teams is not strong right now. So I am frustrated that creating a test plan is deemed the highest priority at this point.

It is these kinds of situations that caused me, some time back, to come up with the theorem of the well formed test plan.

The amount of formatting and verbosity applied to a test plan is inversely proportional to the amount of actual good testing represented by such plan.

David

Last night, the Rebel Alliance gathered at StarEast. The original plan was to gather at Cafe TuTu Tango, a local watering hole that would have done the canteena scene from StarWars proud. But then, as happens in these epic stories, a stroke of unbelievable luck crossed paths with a stroke of genius. In a deus ex machina that even Shakespeare would be jealous of, one of the alliance members got comped into a massive suite; really, the official max occupancy for this room was 78. Why did this happen? I am not really sure…the story I heard was something along the lines of “The hotel just wanted to give him the room” But our plans instantly shifted, and we gathered in his suite, stocked the kitchen with beer and soda and snacks, and ordered Thai food for dinner.

After some general socializing, the lightning talks began. I must say, lightning talks are a marvelous icebreaker. The AA version of getting to know each other — “Hi, my name is David, and I am a software tester” — is feeble. But spend a couple hours listening to fast paced 5 minute talks about something someone is interested in, and then participate in the Q&A afterward, and in a couple hours, you really start to get to know people. I especially liked Lanette Creamer’s presentation, “Herding Cats”, where she used her experiences getting her collection of cats to live happily together as a metaphor for her professional passion, which is collaborative testing and development. Since my own home is somewhat like Noah’s ark, the metaphor resonated strongly with me, and I immediately felt like she and I could find so many things to talk about, rather than just how to write good tests.

She later proved she could not only talk the talk, but also walk the walk, as she paired up with Shmuel Gershon to work through The Dice Game, being proctored by Michael Bolton. Their ability to work very well together was noted as being exemplary of how such things should really be done.
Shmuel continued to work with Michael throughout the evening, sharpening his skills as Michael continued to challenge him more and more. His enthusiasm for learning, and meeting new people, and sucking every bit of goodness out of the evening that he could, was infectious. Kudos to Intel in Israel for believing in him, that he could come all the way from there to here, and actually find and bring back something of value, not only for himself personally, but for them as well. Trust me, he was successful…and he has also distinguished himself as a young tester of note.

It was these kinds of experiences that made the evening special. The room was just the right size, as was the crowd, thanx to Matt for being wise enough to cap attendance. Through the evening, people gathered in corners and at coffee tables, in small groups of a few to a dozen; they would talk for half an hour or so, then get a drink or snack, and find a new group. Through the evening, I was a part of probably a dozen or so different conversations. There was no pressure to watch the hall for someone else you might feel compelled to schmooze with, no other schedule to be mindful of, no other distraction; but there was plenty to keep your interest — no one was looking at the clock and wondering when it was okay to leave. It was a marvelous evening.
And lest you believe that I am just pimping my own opinionated view, I can tell you that based on the collective experiences, conversations, blogs, tweets and emails of the last 48 hours, as I write this I know of at least two other large national conventions which are suddenly putting together events modeled directly on what happened last night. I hope to be, and present, at one if not both of them. And if I am fortunate enough to make that, I truly look forward to gathering with another Rebel Alliance group.

If you are headed for a conference soon, jump on this bandwagon. Get in touch with someone from the original Alliance, and if the conference you are going to is not doing something like this, do your own…that is the Rebel part. Even if they are, still consider doing your own…again, be a Rebel. It will make a difference, trust me, I know. I Love conferences. I go to them as often as I can…but this…this was special.

Long live the Rebellion.

David (Ben Kenobi) Gilbert
Charter member, Master Brewer, Rebel Alliance

Ultimately, I have to justify the expenditure for going to a conference with some practical business benefit. And in this business climate, networking is always one possible benefit. But large conferences can be a double edged sword in this regard. While there are tons of folks there to meet, it can be difficult to meet them. And, there are tons of other folks there meeting them, so a week later, will they even remember you?
And if you have a network of colleagues you reconnect with at conferences, how do you manage to make new contacts as well?

Matt Heusser has come up with a wonderful idea to help resolve this…something he has referred to as a conference within a conference. You can listen to a podcast about it here. He has issued invitations to a collection of folks he knows, and they know, to create a quick sub group, which he has dubbed The Rebel Alliance. The whole point of this is that when the conference is over, in the evenings, for one or two evenings, we are going to get together and have a casual mini-conference, with our own lightning talks and possible presentations. We are all going to blog about it and tweet about it.
Participation is being purposefully limited, so that it does not just become another huge gathering (such as the conference sponsored socials), but rather, everyone will actually get to know each other, and learn a bit about each other, so that when we leave, we will have a collection of a dozen or so business cards that is unique from the 200 or so that we grabbed with a quick “Hi, do you have a card?” For that dozen or so, we will have dinner, lightning talks, conversation afterward, some are heading to Disney after the conference, all of us are already communicating online, and that hopefully will continue. Everyone knows someone in the group who knows someone…no one in the group will be a complete unknown, so introductions will flow naturally.

This is a first, and I am not sure how it will evolve moving forward; but I would imagine that in future conferences, the Rebel Alliance formal attendees will be different, since the point is to create new business relations, not simply create a new clique. So if you are looking to a conference in the future, keep your ears and eyes open for Rebels, and join up at the conference you attend; make some real new connections, and have some fun at the same time. Eschew the ice breakers and conference sponsored fun night out, and embrace something that can really provide some return on your investment. Be a Rebel!

David

When I first started in software QA, I was one of the “We are the gatekeepers of quality!” kinds of people, considering myself the last vanguard before unleashing unclean software upon an unwitting world.  I eventually gave up that belief, and came to a place where I viewed testing as an information service, providing timely and accurate information to management concerning the quality of a piece of software.  Whether or not that software got released was a business decision, and the current state of quality was only one of many considerations that went into that decision.  Then I became a member of the Context Driven school of testing.  And then I came to work here.

Now, in the time that I have worked here, I have seen a lot of good work done.  I have done a lot of good exploratory testing, I have even gotten to do exploratory load testing, and I have stopped a lot of bad software from landing in users hands, which ultimately is job satisfaction of a kind for us testers.  But I have also seen at least three different projects go incredibly bad, and when a government project of the size and scope we work on here goes bad, it goes really BAD.  Estimates of the cost in dollars are millions…not quite a bank bailout, but still pretty serious coin.

As I have looked around and tried to understand what causes these collossal failures, I have come to the conclusion that it is not just bad testing.  It is not just bad development.  It is not just bad program management.  I think it is a series of events that is almost a natural outcome of organizations that become this large.  Projects become interdependant;  communication through the cloud of beauracracy is unclear;  people come and go;  with almost inexhuastable resources, and very lax accountability, mediocrity sets in;  and one day, you wake up with two projects that seem to work fine independantly, but won’t talk to each other, yet are interdependant in the real world.  Welcome to the brave new frontier of Systems instead of Applications.  Soon after, the finger pointing begins, everyone circles the wagons, and both projects proceed to fall out of the sky and become grey smoking holes in the ground.  The casualty count is high.

So given that, how do I try to make things better?  This question has led me to a new field of study, and a new era in my continued professional development;  I, and my company, are now beginning to get involved in Scope Management.  Scope managers are not common, per se, in American organizations, although they have been gaining prominance for the last decade in other places such as Finland, The Netherlands, and Australia.  A scope manager is essentially a mediator between the various consumers and producers of IT products in an organization.  The skills involved come from diverse set of more commonly understood professions;  Development, Project Management, Business Analyst, Customer Advocate, and Quality Assurance Engineer.  Strong analytical skills as well as strong communication skills are essential.  If you have been an independent consultant for any amount of time and with some measure of success, you likely have all of these skills.

So why do I think a scope manager can make a difference, when a tester cannot?  Two reasons;  First, they answer a different set of questions, e.g. “How do we all, all stakeholders, define this project”  and “How do we monitor the evolution of this project and keep our discreet definitions in synch?”  Second, they function at a much higher level, where the input carries more weight, and is less likely to get lost in the local politics.  A scope manager never blames anyone for anything…he simply states truth and reality, and presents options;  management then makes choices.

Now, some will say, this is a very document heavy, process heavy thing; you have sold your soul and are no longer context driven;  to them I would say, you are partially right.  This can be, and likely will be, relatively process and document heavy.  But these last four years have taught me that that is simply the reality of the world, in some contexts…see, still context driven.  Context driven does not say document heavy and process heavy are always bad…it says there are no best practices, nor are there any worst practices…just practices that work better in some instances than others.  Think of it this way;  if you are out on the lake on your personal boat on bright summer day, and the boat starts leaking, process and documentation may not be important;  you have a few choices, including simply jumping over and swimming the 50 yards to shore.  But if you are on an oceanliner in the middle of winter miles from anything but more water and that ship starts leaking, wouldn’t you prefer that there was some documentation and process to keep you safe?  Size seems to shift the context that way…so I would not think a startup dot com would see value in scope management.  But huge organizations, like my current client, will.

Also, I am getting in on the ground floor more or less, and talking with some of the influential folks in the industry, and we have already begun to discuss how we may try to adjust the basic process into a variant designed with more agile organizations in mind.  And so I am excited about the opportunities ahead, and the chance to try and continue to make a positive difference.

If you are interested in Scope Management, and the training and services we will be providing, please visit our website for more information, and feel free to leave comments here about what you think of this new emerging concept.

David

I am writing this blog, because I have the time to do it.

I have the time to do it, because my test environment is down.

My test environment is down because someone is installing and configuring and troubleshooting a new testing tool.  They have been since around the middle of the day yesterday, and an email just came out reiterating how important it is that everyone stay the hell out of the system until further notice.

We love tools here.  We have gobs of them.  We have even documented, at least to the acceptable level of most of the testers, that we have so many tools they actually affect the accuracy of our test results at times.  The managers don’t necessarily agree with that.  But I think about the last thing we need is another tool.  And I say that as a tool maker and seller.  Yes, another tool is not always the right answer.

I know it is just my opinion (Okay, thanx to James and his introducing me to the concept of Epistemology, at this point I think everything I think I know is just my opinion…ouch, my head is gonna explode) but…

When you spend more time installing, configuring, and troubleshooting your tool than using your tool to learn about your application, you’re not testing anymore.

When the value of the 10% of information a given tool will give you is more important than the other 90% of the information you can get without it, I am not sure you’re testing anymore.

When being able to say “On line 10 of method Foo in class Bar you have a memory leak” is more important than being able to say “6 out of the 10 primary business processes I have tested failed to meet my expectations, with me being a reasonable proxy for an average user”, I am not sure you’re testing anymore.

To me, these activities smell a lot like analysis and development.  And more and more, I am beginning to believe that tool blindness is both a symptom and a cause of this kind of behavior. I love tools.  I make them, I sell them, and I use them.  But I am always cautious to keep in mind that the tool is only that, and that the key to testing is the active involvement of people with brains, and skill.  And when the behavior of myself or anyone else on my team begins to look like tool usage for the sake of tool usage, so that statements can be made such as “We are doing good testing because we are using Super Snooper” or “If we don’t use Super Snooper, then we can’t be doing good testing”, I think tool blindness is setting in.

Begin with the end – and I don’t think any management team every created a test team with the express purpose of having them tool up.  When you are holding up testing on a semi-permanent basis to play with your tool, I think you have lost sight of the end.

Play with that tool too much, and you may just go blind.

I have always been a fan of CAST. It is a great conference, with a unique format that fits my personality very well. But this year, the list of speakers and presenters is absolutely next to none.

To start with, the Keynote speakers are all legends in their own rights, including Brian Fisher, Robert Sabourin, and Cem Kaner. But for me, the opening keynote speaker is the real draw…Jerry Weinberg. Jerry is a legend, a consultant’s consultant, a prolific author, and mentor to many of us consultant type software testers. For me, the mentoring has all been through reading his books and hearing the stories and legends from my colleagues who have had the pleasure of meeting him. And that is why I am so excited that he will be there…I will finally get to meet the legend.

In addition to Jerry, the other keynote speakers are also legends, and while I have had the pleasure of meeting them previously, I always enjoy hearing them speak, and never fail to learn something new and broaden my thinking when I get the chance to spend time with with.

But wait!!! There’s more!!!

In addition to outstanding keynote speakers, the tutorials and track sessions also read like a who’s who of the current testing profession, including Scott Barber, Julian Harty, Hung Nguyen, Michael Bolton, Jonathan Kohl, Adam White, Doug Hoffman, Adam Goucher, and more. While not all of these folks are legends yet, most of them are well on their way. These are the brightest, sharpest, deepest and most creative minds in software testing today.

If you’re looking for a conference that has substance, where the name of the game is NOT filling up your plastic bag with free give aways and getting your bingo card punched, then you could find no better conference than CAST.

So while I doubt there will be a red carpet, limo’s or paparazzi, I assure you this will be the most star studded CAST you’ve ever seen. We hope to see you there!

David

Now, I am a caffeine addict, so I was very happy with this surprise and knew I would make good use of it over the next few days at the conference.  However, I am not part of the coffee generation.  Hot tea is my fix of choice.  So, next morning at breakfast, I dropped two tea bags into my new bright shiny cup, filled it up with almost boiling water, and walked over to my table.  As I sat down, I put the cup on the table next to my plate, and as my hand left the cup…it moved!!  It wobbled away from my hand, and the previously calm surface began to ripple in that telltale fashion that immediately precedes a cups imminent disastrous toppling.

With my brain feverishly trying to calculate the odds of an entire cup of boiling hot water spilling onto what passes for a bistro table in hotel breakfast bar and somehow miraculously not ending up mostly in my lap, I quickly and desperately reached out and grabbed the cup again.  With the disaster averted, I caught my breath, relaxed, and let go of the cup again, careful not to hit it with my hand or anything like that this time around.

It wobbled again.

And so the tester in me took over, and I began to investigate this behavior.  I soon discovered that the bottom of the cup was slightly convex, not so much that it was actually likely to fall over, but enough to make it wobble somewhat.  Enough to be disconcerting.

This made me wonder, Why had I never seen this before?  Why had I never even thought of it?  So I began looking at other cups.  Turns out, there is a fairly standard method of preventing this.  Most cups have a lip on the bottom, a raised edge around the perimeter of the cup that is ground, or shaved, or planed, or in some way mechanically adjusted to make the cup sit flat, in spite of the fact that the cups actual bottom, due to the nature of materials cups are made of (glass, ceramic, wood, plastic) is not flat at all.  But MY cup, apparently, chose to not employ such a design philosophy, instead apparently relying on its ability to actually BE flat on the bottom.

Bad Choice.

So this made me wonder, whose fault is this?  I am fairly certain that the folks at SQE did not say “Oh, yeah, and make sure it wobbles.”  On the other hand, I’ll also bet they did not say “Oh, yeah, and make sure it sits flat.”  They would have had no more reason to say this than they would have had to say “Oh, yeah, and make sure it can actually hold some liquid.”  These things are known, understood, taken for granted…and that is fine.  They should be.

As software testers, we need to understand that that same reality applies in our world as well.  Some things are just understood.  Within any given context there are a collection of well defined implied requirements for an application.  There is no reason to state those requirements explicitly.  To do so only adds clutter.  This is important for testers to understand.  It is this very fact that makes the following statement patently absurd:

“I can’t test your application;  you have not given me all of the requirements.”

Of course they haven’t, and they shouldn’t, and it isn’t likely that they ever will.  And for any tester to make that statement is simply insulting to the rest of us.  There is tons of testing that can be done in the absence of ANY explicitly stated requirements, and certainly in the abscense of the complete set of all explicitly stated requirements.  A requirement only needs stating for testing if it in some way violates an existing implied requirement.

Here is an example:  In any Windows application, there is a button in the upper right hand corner with an “X” on it.  Clicking this button closes the application.  However, in recent years, there is a growing trend to attaching a different behavior to this button, specifically to close the GUI, but leave the application running, and place an icon in the SysTray for user access.  Now, if I am given an application to test, and I find no documentation on what that button should do, am I powerless to test that button?  Of course not…I simply presume it will follow the implied requirement of actually closing the application.  If I test it and it does that, all is well.  If it minimizes the application to the SysTray, then I would ask the developers to state the requirement so that the ambiguity could be resolved.  If it did anything other than those two behaviors, I would call it a defect and move on with my testing.

So as I sit here drinking my morning tea….umm, my FIRST cup of morning tea…out of my new, bright, shiny wobble cup, I am constantly reminded of this fact.  It is somehow comforting.

Hey, you don’t suppose the folks at SQE planned it that way all along, do ya?

And as is common, the catalyst for my newfound energy and enthusiasm is a conference — StarEast, to be specific.

I have taken a year out of being visible to try and repair some things in house.  Version 5 of TestExplorer is in Beta, and will hopefully be released by the end of June.  It will be Vista compatible…no, it will be a Vista compliant and friendly application…as well as having many new features.  We are standing up a new website, www.testexplorer.com, to seperate the marketing efforts for the product side our business from the consultancy side.  There will be a few new products coming soon also.  All very exciting.  All very timestaking.  So I have been silent.

But now it is time to refind my voice…to get back in touch with the real world out there…to interact with people who share the same daily frustrations and victories that I do.

When I walked into the Rosen last week, it was with much trepidation…I had been largely silent and inactive for almost a year.  How quickly do you get forgotten in this industry?  How much forgiveness is there for getting swept up in your own thing, and not contributing to the community?  Questions that were quickly answered…within 15 minutes of walking in the door, half a dozen different folks had waved me over to say hello, have a drink, sit and talk and catch up.  Within two hours, I stopped talking and just looked around for a moment to soak it in…I was sitting around with Jon Bach, Michael Bolton, Rob Sabourin, Antony Marcano, Ben Simo, Elisabeth Hendrickson, Richard Bender … we were all sitting and talking and joking and having a great time.  It was exactly what I needed.

I did not have a booth in the expo, nor did I present this year…first time in 4 years for both…but I simply needed to soak up the karma, and settle down, before this last big push to release.  And it was great.  I made some new friends, caught up with old ones, and have a wealth of new ideas.  Here are some things you will see me blog about in the near future..

• Cups should sit flat
• The strength of community
• The growth of community
• Quality is a relationship
• A witch is not a duck
• Why do we call Testing QA?
• What do you take away from a conference?
• Have Fun!!
• Recording and Reporting in storytelling
• Side Door Testing

And finally, something for this blog;  the importance of teamwork.  While we often discuss and debate the pros and cons of pair testing and pair development, anyone who was with us Thursday night in the bar got to see Rob Sabourin and Antony Marcano put on a tutorial in teamwork that was just astounding.  In minutes, the two of them, working together, accomplished a feat that most of us individually would have dismissed as unattainable — and not only that, but they had great fun with it, and entertained everyone else who was watching.  Bravo, gentlemen!!  A great example of testing at it’s best, truly.

It is good to be back.  And as part of our ongoing evolution, you will now notice the built in ability to share our blog posts in many ways.  I encourage you to do just that, if you enjoy what you find here.  I also encourage you to join and contribute, and help me build a community of like minded testers.  All feedback is good feedback…but what else would a sirius tester say?

David

As weeks go, this has been a good one.

I have, for quite some time now, been involved with a very large client who is creating a massive SOA system.  Concurrently, the organization is moving from being very decentralized, to being much more centralized.  The two are not unrelated – this kind of project requires massive amounts of coordination that the organization previously did not support.  Growing pains abound.

In an odd quirk of luck, I am on the performance test team here, although it is safe to say I do a LOT of cross functional work, especially in the area of automation.  For months now, the test team has labored to test a particular application in this system.  While in some circumstances, this application may perform well, in the broader context of the entire SOA system it really has to work in, it is a hurtin puppy.  In almost 10 years of consulting, testing, and automating, this is the most challenging, frustrating, irritating circumstance I have ever found myself in.  At conferences, over dinner, on phone calls, and via Skype, I have spoken at length with colleagues about the problems, challenges, personal issues, and frustrations.  My thanx to all of them for helping me keep my head screwed on straight, and especially to Michael Bolton, who literally spent over 12 hours on Skype with me on one of my absolute worst days, convincing me not to throw in the towel and walk away.  Were it not for them, I may not be writing this…

Three days ago was a watershed day.  After weeks of chasing down a particular defect that the performance automation team considered a showstopper for further automation, repeating results, gathering data, refining our understanding, analyzing myriad charts and graphs to help the dev team understand root cause, the dev team finally pronounced that their app was fine, and our scripts were breaking it.  (Much of this blog will read like a classic tale of every testing parable we all know…except this really just happened to me)  So, stepping up to that challenge, three days ago we turned off all of our automation tools, took the entire test team for one day (all 10 of us) and began manually pushing the application into a corner.  With 10 people in a couple of hours, we logged hundreds of errors…not hundreds of defects, mind you, many of the errors were the same defect over and over, but that was exactly our point as performance testers…it keeps breaking the same way over and over under incredibly light load.  Complete vindication.  Absolutely every single bad behavior we had documented in our automated tests came to the fore under this manual assault.  And with that, we were suddenly on the map.  Now not only did our bosses boss know what we were finding, but his bosses bosses boss did as well.  We were suddenly center stage in the spotlight…in a metal chair…at a barren table…in a room with no windows…you get the picture.

The dev team, not to be taken that easily, immediately proclaimed it was our test environment that was to blame.  (Never mind that we had spent millions building a test environment that much more closely matched the target real world deployment than what they were developing in).  So two days ago, we switched off of the performance test environment onto the functional test environment, and did the same thing all over.  Same results.

The dev teams next response was that our testing methodology was flawed, and we were purposely setting the application up for failure.  They informed us that they were going to do their own version of our manual assault, in their environment, using their test methodology, to prove that we were purposely breaking their baby to make them look bad.  This announcement was immediately followed by a request from our bosses bosses bosses boss, politely asking if we would be so kind as to monitor the developers testing process.  Ouch.  So yesterday the dev team spent several hours proving that in any environment, no matter how delicately you touch it, it simply falls over and cries.

By now, you have probably inferred (correctly) that the relationship between dev and test is strained.  That is a whole different article, but yes, it is.  But even given that, this is a MASSIVE success for the testing team.  I am a firm believer that the role of the test team is to provide valuable information to management to allow them to make informed decisions about releasing software.  Until three days ago, I felt like this train was running to the station, no matter what we said.  Now, we have incredible visibility, management is listening, and I am fairly certain that this application will undergo extensive adjusting before it sees the light of day.  It is a brave new world.  Next week, the offsite contract developers have been invited in to help us “understand” this behavior that now cannot be ignored any longer.  It is not an invitation they can decline.  This test team has turned a juggernaut running at full throttle 90 degrees off course…an absolute miracle in my experience…and ultimately, a very satisfying experience.  This application ultimately will have a very direct impact on the quality of life of a large group of people, people I actually care about personally.  It really needs to be good.  And I finally feel like I may have made a difference.

In our industry, on the blogs, in the newsgroups, at the conferences, in conversations, we constantly decry how bad things are, how much we are ignored, how futile our efforts often seem.  I am very happy to present what I believe, at least for now, is a true success story.  I would like to see more of these.  I think it would help raise the spirits of some of us, and under the heading of “You catch more flies with honey” may actually help improve our professional lot in life.  So if you have your own success story, I invite you to post it here as a comment to this blog.  Large or small, anything that says “Hey, testing made a positive difference here”, bring it on.

And now, I am going to go bask in the newfound glory of my fame…because I know by Monday it will all be gone again.
Happy testing.