The 4-Note Bass Line…
I’m pretty much a head-banging metal fan, but I’ve always hated Metallica. Seems almost sacrilegious, doesn’t it?
Well, I was a music major in college; had three scholarships in performance (that’s the only way I could have paid for college), and I was cursed with close to perfect pitch. Those of you similarly affected know what I mean. Music or people that are out-of-tune make me cry.
It also means that I can usually pick out any given melodic line, as long as the timbre is somewhat different.
Thus the Metallica bass line. It’s like, 4 notes, repeated over and over and over and over and over and over and over and over and over and over.
By the end of a Metallica song, I’m a headbanger, all right. Banging my head against a wall until my brains leak out my ears, screaming. I hate anything excessively repetitive. That means I’ve never been fond of instrumental jazz. One instruments flogs the crap out of a theme, then another instrument picks it up and does the same thing. While I appreciate the skill of the musicians, the music itself gives me a headache.
This means that to some deep thinkers, I pretty much have the attention span of a chicken. It’s not in my nature to ponder the same thoughts over and over. I dislike “standing meetings” that are at the same time, same place, every week. I have to force myself to go and will eventually find reasons to skip some. I don’t even go to work or go home the same way every day. I’m easily bored. It’s so bad that if I’m stuck in some kind of repetitive rut, I actually begin to suffer both physically and mentally – becoming exhausted, listless, and lethargic.
So as riveting as this glimpse into the depths of my persona might be, where, one might ask, is all this leading?
To my last pitch and set of comments, ever again in this lifetime, regarding schools. Yes, that pitched battle is still raging.
I can only assume November and December have been slow months.
Primary proponents of the idea continue to be members of the Context-Driven Test community.
I understand, and I even agree with some of what has been said about what the positive aspects of schools COULD BE if only things were different. I also understand what those proponents of the idea WISH IT WAS.
But that is not what it IS RIGHT NOW and it is not WHAT IT HAS BECOME.
CDT members, no one wants to play with you. That means the only acknowledged school you’ve got is your own. You’ve got some of the best minds in the field. My suggestion is that you use them to look at what went wrong and what you would need to do in order to save the original concept. Telling me, or others “this is what schools mean”; hearkening back to the original concept, with no acknowledgement of how that concept has really been used or how it has mutated in the intervening 5 years or so, is ignoring reality. And I have no patience with people who can’t recognize reality.
It’s much easier to point at others and say they don’t understand than to acknowledge that maybe some of you have made some pretty major gaffes, isn’t it? I understand that. You’re a very prolific group, are you not? Where are all of your posts accepting a large chunk of the responsibility for the failure to have the concept widely accepted? An exploration of where you went wrong? Suggestions as to how to make the concept workable?
Regardless, at the moment, you’re a 4-note bass line. I’ve heard all this before. Give me something new; something better; something that has included the thoughts of people outside your group; something useful; something workable. Show me something that DOES WHAT YOU CLAIM IT DOES, dammit, and don’t waste my time pontificating about what it COULD do, if only virtually everything was different than it actually is.
I could pull a dozen comments made by acknowledged leaders of Context-Driven Testing right now that use the terminology and/or concepts associated with different “schools” in derogatory and belittling ways. This has been going on for a long time – I don’t really understand what appears to surprise at the resulting lack of enthusiasm for embracing the concept.
I don’t know if anyone else out there has had to have diversity training, but one of the first things you learn is that you are responsible for your own actions and the results of those actions, and that if other people give you the courtesy of telling you what is wrong and why, you should listen, and make every attempt to see that point of view and respond appropriately. It seems to me that many people brought up the problems they have with the concept of “schools” and the response has been either “No, no, no.”, or “You’re wrong.”, followed by yet another description of what schools SHOULD be. But they aren’t. And a lot of that is your own fault, CDT. No one treated with contemptuous disrespect for years is going to raise their hand and ask for more. “Oh yes, sir”, “I do, in fact, poop out detailed test scripts on command and am, in fact, proud to be a member of the School of Steaming Piles of Tests (SPOT)”. It just ain’t gonna happen.
I’m starting to get that head-banging urge, so I’m going to stop now (sighs of relief); I can’t believe I posted multiple times on a single topic. I feel dirty…
Friday, December 12, 2008
Tuesday, December 9, 2008
STOPLIGHT REPORTS
A Picture is Worth a Thousand Words…
On occasion, I read an article or blog that really hits home or addresses a problem we have and I get excited about it. I’d like to bring your attention to an article called “Simple Strategies to Keep Quality Visible" by Jeff Patton on StickyMinds.com on their Process Improvement tab. I apologize for not having the link available, but inserting simple links in this format continues to be a challenge.
Now what Jeff’s team was addressing and what we need to address have similarities and dissimilarities, but what I particularly like about this concept is the idea of “quality at a glance” provided in a visual format that can be easily absorbed and understood not by the project team, as in Jeff’s example, but by executive management.
Executive management is not involved in the day-to-day activity of the team, and yet when schedules get crunched and production dates are looming, they need to get up to speed quickly and absorb issues ASAP in order to make some tough decisions or take action.
In my company, questions asked are as follows:
1. How far along is the testing effort? Note that unlike Jeff’s example, executive management
does not especially care about “depth”; they assume that number is rolled into the overall
“how far along” number. But the underlying question we’re really being asked is “What
kind of shape are we in right now?”. We express that verbally in meetings. Some sort of
visual “Quality Meter” that has mutually acceptable “this is how we determine where we
are” logic behind it is an interesting idea that might work for us. Executive managers find
information such as “we’re half-way done, and what we’ve seen thus far is pretty buggy”
tells them what they need to know if there are only 3 days left in the test cycle and the
testing effort was scheduled for 20.
2. Based on what we’ve seen thus far, how many errors are likely to occur? (This number is
used to determine roughly how much more development work is going to be required, and
when/how many additional patches are going to be required. Nobody expects it to be
hewn in stone, but if the error rate for new stuff has been running at 40% throughout the
project, assuming it will continue to average 40% is at least somewhat better than pulling a
number out of your…ear).
3. What are the urgent defects and do they block any testing? If they block testing, how
much testing is blocked and is it user-critical functionality?
4. What defects must, from the business/user perspective, be fixed prior to production?
5. Considering 1-4, how long will it take to complete the testing effort? Note that this really
means “When will a) testing of all currently untested stuff be done b)fixes to errors found in
(a) made and turned over c)retests performed and d) everything be ready for
production?”. Executive management realizes that if we are testing ten minutes before
production, we can (and have) located more defects.
We produce a Stoplight report right now, which lists errors and highlights them in green, yellow, and red according to urgency. This does allow both the team and executive management to immediately focus on “red” items, but it never really answers the questions “where are we, overall, right now” and “what needs to happen to get where we need to be (what’s left to do and how long will it take)”. The Stoplight report is also an excel spreadsheet, attached to the normal status report, which means half the recipients don’t even open it up. For those more “old school”, it doesn’t print nicely – the colors don’t show, and it’s 37 pages long. As usual with highly detailed individuals, it’s also become mutated so that there are multiple shades of yellow and green. This means the colors have to be explained.
So what does this mean and why am I blogging about it? Because I think this is a common problem and because I feel inspired to tackle it by something I’ve read; I thought some of you might feel the same way. We’re going to take these ideas, our status report, and our stoplight report, armed with what we know we get asked for every migration, and brainstorm those ideas into one simple, easy-to-read non-excel format . It should be interesting, since the questions that get asked involve what has happened, what is happening, and what is likely to happen. Predictive numbers tend to make my staff break out in hives, so some bravery and a bottle of Calamine Lotion will be required. But what the heck – you have to be unspeakably brave to work in the testing field anyway….
When we’ve developed something we think is going to work for us, I’ll share it and let you know if it addressed any of our issues. If it doesn’t, I’ll tell you about that too….
In the meantime, if any of you have come up with something unspeakably clever that works for your shop, I hope you’ll share it as well. If nothing else, this blog will probably illustrate how we glom onto an idea, play around with it, and make it into something that works for our particular environment. I wouldn’t call my normal business environment agile and I wouldn’t call it structured either. It’s a combination that is primarily iterative and that works for this specific business. One of the things I like best about this company is that they could care less about the technique du jour. They never waste time or money jumping onto some bandwagon just because someone else said the shiny red one is the best. They’re willing to try anything, modify (whatever) and use pieces and parts of any idea, as long as it results in either time/cost savings, or makes something (quality, the user experience, etc.) better. It makes working here worth the effort.
Now this idea is just a small thing – a bagatelle – but it addresses an annoying issue that comes up for us on a regular basis, the solution is simple (Simplicity is the Ultimate Sophistication), and it gives us something new to play around with to make things just a touch better for our next go-round. We have a tendency (go figure) to be too detail-oriented and somewhat anal; I think it will be good for us to pull back and look at how to simplify what we’re communicating.
Kudos to Mr. Patton.
On occasion, I read an article or blog that really hits home or addresses a problem we have and I get excited about it. I’d like to bring your attention to an article called “Simple Strategies to Keep Quality Visible" by Jeff Patton on StickyMinds.com on their Process Improvement tab. I apologize for not having the link available, but inserting simple links in this format continues to be a challenge.
Now what Jeff’s team was addressing and what we need to address have similarities and dissimilarities, but what I particularly like about this concept is the idea of “quality at a glance” provided in a visual format that can be easily absorbed and understood not by the project team, as in Jeff’s example, but by executive management.
Executive management is not involved in the day-to-day activity of the team, and yet when schedules get crunched and production dates are looming, they need to get up to speed quickly and absorb issues ASAP in order to make some tough decisions or take action.
In my company, questions asked are as follows:
1. How far along is the testing effort? Note that unlike Jeff’s example, executive management
does not especially care about “depth”; they assume that number is rolled into the overall
“how far along” number. But the underlying question we’re really being asked is “What
kind of shape are we in right now?”. We express that verbally in meetings. Some sort of
visual “Quality Meter” that has mutually acceptable “this is how we determine where we
are” logic behind it is an interesting idea that might work for us. Executive managers find
information such as “we’re half-way done, and what we’ve seen thus far is pretty buggy”
tells them what they need to know if there are only 3 days left in the test cycle and the
testing effort was scheduled for 20.
2. Based on what we’ve seen thus far, how many errors are likely to occur? (This number is
used to determine roughly how much more development work is going to be required, and
when/how many additional patches are going to be required. Nobody expects it to be
hewn in stone, but if the error rate for new stuff has been running at 40% throughout the
project, assuming it will continue to average 40% is at least somewhat better than pulling a
number out of your…ear).
3. What are the urgent defects and do they block any testing? If they block testing, how
much testing is blocked and is it user-critical functionality?
4. What defects must, from the business/user perspective, be fixed prior to production?
5. Considering 1-4, how long will it take to complete the testing effort? Note that this really
means “When will a) testing of all currently untested stuff be done b)fixes to errors found in
(a) made and turned over c)retests performed and d) everything be ready for
production?”. Executive management realizes that if we are testing ten minutes before
production, we can (and have) located more defects.
We produce a Stoplight report right now, which lists errors and highlights them in green, yellow, and red according to urgency. This does allow both the team and executive management to immediately focus on “red” items, but it never really answers the questions “where are we, overall, right now” and “what needs to happen to get where we need to be (what’s left to do and how long will it take)”. The Stoplight report is also an excel spreadsheet, attached to the normal status report, which means half the recipients don’t even open it up. For those more “old school”, it doesn’t print nicely – the colors don’t show, and it’s 37 pages long. As usual with highly detailed individuals, it’s also become mutated so that there are multiple shades of yellow and green. This means the colors have to be explained.
So what does this mean and why am I blogging about it? Because I think this is a common problem and because I feel inspired to tackle it by something I’ve read; I thought some of you might feel the same way. We’re going to take these ideas, our status report, and our stoplight report, armed with what we know we get asked for every migration, and brainstorm those ideas into one simple, easy-to-read non-excel format . It should be interesting, since the questions that get asked involve what has happened, what is happening, and what is likely to happen. Predictive numbers tend to make my staff break out in hives, so some bravery and a bottle of Calamine Lotion will be required. But what the heck – you have to be unspeakably brave to work in the testing field anyway….
When we’ve developed something we think is going to work for us, I’ll share it and let you know if it addressed any of our issues. If it doesn’t, I’ll tell you about that too….
In the meantime, if any of you have come up with something unspeakably clever that works for your shop, I hope you’ll share it as well. If nothing else, this blog will probably illustrate how we glom onto an idea, play around with it, and make it into something that works for our particular environment. I wouldn’t call my normal business environment agile and I wouldn’t call it structured either. It’s a combination that is primarily iterative and that works for this specific business. One of the things I like best about this company is that they could care less about the technique du jour. They never waste time or money jumping onto some bandwagon just because someone else said the shiny red one is the best. They’re willing to try anything, modify (whatever) and use pieces and parts of any idea, as long as it results in either time/cost savings, or makes something (quality, the user experience, etc.) better. It makes working here worth the effort.
Now this idea is just a small thing – a bagatelle – but it addresses an annoying issue that comes up for us on a regular basis, the solution is simple (Simplicity is the Ultimate Sophistication), and it gives us something new to play around with to make things just a touch better for our next go-round. We have a tendency (go figure) to be too detail-oriented and somewhat anal; I think it will be good for us to pull back and look at how to simplify what we’re communicating.
Kudos to Mr. Patton.
Subscribe to:
Posts (Atom)
Posts
