The daughter called on Sunday to wish me "Happy Father's Day." I was engaged in putting in a cobble-stone walkway in the back yard. We got to talking and she made a comment that reminded me of conversations I've had with folks. Some recently, some in the last few years. These particular conversations were with Project Manager folks.
So, the dear daughter made a joke about fitting stones into place (she has seen some of the other "little" stone projects I've done.) What she said was "Well, brute force can work. Unless it doesn't."
Brute Force
Yeah. It CAN work placing stones and getting things to get where they belong just so. Get stuff generally set, get out the rubber mallet and beat the stone into submission. Sometimes this works really well. Being the size of fellow I am, I kinda fall back on this a bit more often than I should.
Unfortunately, things don't quite work the way you expect. There's a wee bit of resistance you don't expect. Maybe you don't hit the stone quite where you should, or at least intend to. Sometimes you do smack it just where you expect to... unfortunately.
You see, stones are all different. Shape, color, size, weight, density. They are not bricks. Bricks are pretty predictable. Stones, particularly those that come out of the back garden (where ours do) Not so much.
Laissez-Faire
Then there is the "simple way" - the hands-off, let it be way. A little paver base. A little sand. Put the stones down (more or less), sprinkle some redi-mix over it and then sprinkle water. Done.
The question is, will it be "done" enough? Well. Maybe. If you intend to walk on it, it probably will work reasonably well. If you intend to put chairs or tables on it, well... it might be an "issue." WELL, what if you intend to put your ginormous charcoal grill on it - or roll it on and off it? You could have another type of issue.
What you want to do kind of makes a difference in which approach works.
In Between
Then there is the "lay out the stones, remember the spots, pull them up, pour cement, replace the stones and hammer them into place in the wet cement." Sounds simple - unless you have done it. No, really. My muscles ache at the memory.
This gives you a really solid spot to walk, stand, or roll a ginormous grill. The problem is that getting the stones level before the cement sets is a challenge. A big challenge. Having tried this method, suffice to say that small sections are easier than everything at once. Then, when that section is level, do it again on the next.
Stones
Each of these techniques can work well for some projects and work poorly on others. Each of them has good points and bad points - easy and hard to work with. Each takes a different approach to planning and execution. Each has its own pace.
The thing is, you can rush these projects and something will give away that it was rushed. Something, possibly a loose stone here or there, will show that the same level of attention was not paid to the entire project. Sometimes, the loose stone knocks others out of place and you have a chain reaction.
Stuff needs to be fixed. That can involve pulling up a whole bunch of stones and "starting over" for that section. It can mean reconsidering how you approach the project.
I'm glad I'm writing about cobble stones and not software projects.
Software
Software projects NEVER have stuff go wrong as the result of using inappropriate approaches or techniques. Software projects NEVER have mistakes from trying to rush to catch-up or make up time.
After all, we have a wealth of practices and experiences to draw on. I'm glad that we always know what to do with every situation we face when it comes to software. We have years and years of people telling us what we should do in every situation. If We just do THIS - then everything will be perfect. Right?
Right?
Thursday, June 20, 2013
Saturday, June 15, 2013
On Testing Purpose and Documented Requirements
It has been a really crazy busy four weeks at the day job. Somehow, I ended up with several "challenged" projects in my lap. Yesterday was rather strange, in fact. I got in at my new "normal" time of 7:45 and realized that there was no reason for me to be there that early. All the troubled projects were sorted out, there were no emergencies or top-priority bugs waiting further investigation. There were no outstanding tasks to do before getting my first coffee of the morning. Everything was kind of... dull.
The cool thing was a comment that a Project Manager said to me. She looked at me and said "On Project K and Project M (two of the troubled projects) you came in and looked at the tests and skimmed the requirements then talked with the business process experts. Why did you do that? The test lead who started on the project did not do that."
This got me thinking on past projects and companies and clients and places where things did not work well. Each time someone mentioned something like that above statement, part of me controlled myself. Another part smiled to myself thinking "And that explains the state of testing for those projects."
What I actually said was "It is good to know what the documented requirements are. It is also good to know what existing tests have been set up or run already. It is essential to know what problem the project is intended to address. It is crucial to know what people are doing now and what they need the software to do for them."
When you sit down and actually speak with people in a conversation, not an inquisition, not in a meeting with loads of people who don't really care about their work, you can learn things that may not otherwise be learned. When your energy is one of "please help me to understand so I can help you better" - as a servant, not a superior, walls come tumbling down and this weird thing happens: People tend to share information freely.
Too often, IT folks come in as the experts who know how to fix problems that these lesser being have. I find that offensive. My handful of accounting and finance courses lo those many years ago do not qualify me to know more than the CFO, nor even any of the folks working for him.
So, rather than go on a 10 minute rant, I kept it simple. (Yes, I sometimes can control myself.)
"But isn't that what the BA is supposed to do?"
Oh, excellent question.
Certainly a good BA can gain that information and pass it on to the team. However, with each layer or remove introduced in the information flow, something changes. Information may be lost. Other things may be added. The "clarification" may critically change part of the message. If I can get as close to the people doing the work as I can, I often learn stuff that is important to me as a tester that other people shrug off as unimportant.
If I can understand their needs better, I can exercise the software more efficiently. If the tests I write and run do not explicitly exercise "the requirements" are they really required? Are they interpretations of something?
Sure, there may be some things that are important, like "don't corrupt the database" or "this needs to be reflected in the ziggidy-splat system" or "this value should match what is on this other screen." Do these things make the user's list of expectations? Do they make the documented list of "requirements"?
In having these conversations, I find out what the answer is.
If you only test the "documented requirements" how do you know that you are providing information the clients/customers/people using the software will be interested in? If the things they are interested in are not in the "documented requirements" what is the value in the documented requirements?
If you can, exercise both. If you can't exercise the stories. Then have folks from outside of IT sit down with you and go through it as well.
The cool thing was a comment that a Project Manager said to me. She looked at me and said "On Project K and Project M (two of the troubled projects) you came in and looked at the tests and skimmed the requirements then talked with the business process experts. Why did you do that? The test lead who started on the project did not do that."
This got me thinking on past projects and companies and clients and places where things did not work well. Each time someone mentioned something like that above statement, part of me controlled myself. Another part smiled to myself thinking "And that explains the state of testing for those projects."
What I actually said was "It is good to know what the documented requirements are. It is also good to know what existing tests have been set up or run already. It is essential to know what problem the project is intended to address. It is crucial to know what people are doing now and what they need the software to do for them."
When you sit down and actually speak with people in a conversation, not an inquisition, not in a meeting with loads of people who don't really care about their work, you can learn things that may not otherwise be learned. When your energy is one of "please help me to understand so I can help you better" - as a servant, not a superior, walls come tumbling down and this weird thing happens: People tend to share information freely.
Too often, IT folks come in as the experts who know how to fix problems that these lesser being have. I find that offensive. My handful of accounting and finance courses lo those many years ago do not qualify me to know more than the CFO, nor even any of the folks working for him.
So, rather than go on a 10 minute rant, I kept it simple. (Yes, I sometimes can control myself.)
"But isn't that what the BA is supposed to do?"
Oh, excellent question.
Certainly a good BA can gain that information and pass it on to the team. However, with each layer or remove introduced in the information flow, something changes. Information may be lost. Other things may be added. The "clarification" may critically change part of the message. If I can get as close to the people doing the work as I can, I often learn stuff that is important to me as a tester that other people shrug off as unimportant.
If I can understand their needs better, I can exercise the software more efficiently. If the tests I write and run do not explicitly exercise "the requirements" are they really required? Are they interpretations of something?
Sure, there may be some things that are important, like "don't corrupt the database" or "this needs to be reflected in the ziggidy-splat system" or "this value should match what is on this other screen." Do these things make the user's list of expectations? Do they make the documented list of "requirements"?
In having these conversations, I find out what the answer is.
If you only test the "documented requirements" how do you know that you are providing information the clients/customers/people using the software will be interested in? If the things they are interested in are not in the "documented requirements" what is the value in the documented requirements?
If you can, exercise both. If you can't exercise the stories. Then have folks from outside of IT sit down with you and go through it as well.
Tuesday, June 4, 2013
On Panic Buttons
Sometimes things happen. Murphy raises his head and gets Mrs O'Leary's cow to kick over the lantern and start a fire. The minor detail that Mrs O'Leary's cow did not actually start the Great Chicago Fire completely not withstanding, it is an image that is firmly fixed in pop-history. There are a lot of things like that.
Sometimes stuff happens.
Sometimes projects fall to pieces for any number of reasons. Even when the software is "in production" the wheels fall off. This can happen when we do no planning or when we have planned greatly. This can happen when we have considered every possible contingency and none at all.
The "Black Swan" lands in the middle of our existence and we find ourselves in a situation we are for which we are absolutely unprepared.How we deal with it is the great question.
Do we rise to the occasion and direct actions and activities effectively? Do we handle crisis with calm determination to overcome adversity? Do we roll with problems or do we bully our way through things?
Here are some things I learned that are probably good ideas to keep in mind when the wheels are falling off:
1. Keep Calm. No, really. This is kind of a big deal. Someone needs to keep their head so why not you?
2. Understand the Situation. Yeah, this one can be hard. Particularly when things make no sense. Still, if you can achieve #1, this becomes a tad more likely.
3. Communicate Clearly. Tell people what you know when you know it. Don't mince words. Don't couch your message in "nice" words. Say it like it is.
4. Think. Some of us remember when folks at IBM had that on their desk. It is still good advice.
5. Trust Others. They can have good ideas, too.
6. Make Decisions. That sounds simple, right? What about when you are not sure what the right decision is? Still Simple?
7. Be ready to Change Your Decision. If you act, and act wrongly, act again to correct it.
8. Be Honest. That one is kind of challenging for some people. And that is a sad thing.
Will doing those things prevent disaster? Will they keep everything from crumbling around them? I don't really know.
What I can tell you is this: Not doing them increases the probability of collapse, if not disaster.
Do not allow yourself to be drawn into emotional responses and reactions. Do not, under any circumstances, hit this button:
Sometimes stuff happens.
Sometimes projects fall to pieces for any number of reasons. Even when the software is "in production" the wheels fall off. This can happen when we do no planning or when we have planned greatly. This can happen when we have considered every possible contingency and none at all.
The "Black Swan" lands in the middle of our existence and we find ourselves in a situation we are for which we are absolutely unprepared.How we deal with it is the great question.
Do we rise to the occasion and direct actions and activities effectively? Do we handle crisis with calm determination to overcome adversity? Do we roll with problems or do we bully our way through things?
Here are some things I learned that are probably good ideas to keep in mind when the wheels are falling off:
1. Keep Calm. No, really. This is kind of a big deal. Someone needs to keep their head so why not you?
2. Understand the Situation. Yeah, this one can be hard. Particularly when things make no sense. Still, if you can achieve #1, this becomes a tad more likely.
3. Communicate Clearly. Tell people what you know when you know it. Don't mince words. Don't couch your message in "nice" words. Say it like it is.
4. Think. Some of us remember when folks at IBM had that on their desk. It is still good advice.
5. Trust Others. They can have good ideas, too.
6. Make Decisions. That sounds simple, right? What about when you are not sure what the right decision is? Still Simple?
7. Be ready to Change Your Decision. If you act, and act wrongly, act again to correct it.
8. Be Honest. That one is kind of challenging for some people. And that is a sad thing.
Will doing those things prevent disaster? Will they keep everything from crumbling around them? I don't really know.
What I can tell you is this: Not doing them increases the probability of collapse, if not disaster.
Do not allow yourself to be drawn into emotional responses and reactions. Do not, under any circumstances, hit this button:
Subscribe to:
Posts (Atom)
