I was asked a question by a tester in the office the other day that got me thinking on this topic. Her question was "Will we need to do any integration or system integration testing?" Mind you, with some products, that is a perfectly reasonable request. In this shop, given what we do, we're pretty much doing some aspects of that any time we're running a test. Many times, we're testing within the boundary of our charter and exercising only so far. To continue to the next step requires live connections with external companies. We have connections to emulators, but I don't consider that to be a "real" situation - simply checking for handshakes and responses.
So, I thought a bit about the possibility that I have a different understanding of "System Integration Testing." That led me to that all-knowing repository of knowledge, Wikipedia, and found this:
System Integration Testing (SIT) is a testing process that exercises a software system's coexistence with others. System integration testing takes multiple integrated systems that have passed system testing as input and tests their required interactions. Following this process, the deliverable systems are passed on to acceptance testing.
Hmmmm. Well, I don't know if I'd buy that in total for our situation, or for most situations where I've worked.
So, I said, HEY! She has Foundation Level Certification from ISTQB.
ISTQB Glossary says:
System Integration Testing: Testing the integration of systems and packages; testing interfaces to external organizations.
Striking me a bit as "A painter is one who paints" I went looking at the individual terms. So:
Test: A set of one or more test cases. (taken from IEEE 829)
Testing: The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.
Integration Testing: Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
System: A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]
System Testing: The process of testing an integrated system to verify that it meets specified requirements. [from W. Hetzel (1988), The complete guide to software testing – 2nd edition, QED Information Sciences, ISBN 0-89435-242-3.]
This made me think of the very first time I encountered "integration testing" when I was testing something I had not programmed.
Some folks remember the days when programmers talked to business users/clients and met with them to discuss what they needed, then worked on the design for the solution, then talked with the client again about the design and checked with the client and verified what we had worked on with them. We worked up sample reports and screen shots and went over them again. Talk about time-consuming, no?
So here I was a reasonably senior programmer being pulled into a project that was over a year late and had to be delivered - postively had to be delivered - in 2 months. The first task I was given was to "simply validate" a series of batch jobs (remember JCL on IBM mainframes?) and confirm that all the components together worked correctly and finished within the required timeframe, nightly.
No problem, I thought. Gathered what I needed to learn the systems it touched, met with the more senior programmers who wrote the programs and the JCL and what not, made sure I knew the exact sequences and limitations that they knew of. I set up a test run on a weekend. The idea was to take over the entire test system - a clone of the production system - fire the process up, monitor the logs while it ran then check the summary reports. If they all looked correct, run some SQL scripts to validate the DB was correct.
Only problem was, after 18 hours running, draining the system of all available resources, the first step had not completed. That, constitutes a problem in any book.
I worked all the next day on identifying the cause, literally. When the team walked into the main conference room Monday morning, I had the entire data flow for the system the wall - all the way around the room. Bottlenecks were circled in red, pages from DB schemas were taped to the wall, and a first draft of a solution was scribbled on data flow diagrams were on the table at my "usual" seat.
That version, after rebuilding the various PROCs that were needed (ummm, execution sequence for those who don't remember when green-bar ruled the computer world) the second version was tested the next weekend. This one took only 4 hours to run to completion. Better, but well outside the target window of 2 to 3 hours.
Next idea? Pull in a couple of other mainframe jockeys for ideas, grab a senior DBA and say "I need a process that will run in a variable number of initiators, up to at least 5 and ideally up to 7." They said, "Can we do that? Not sure, but it might be fun to try." And we did. It worked. It ran in 45 minutes.
What I learned then was that nothing "worked" until you had proven that all the parts worked in concert with all the other parts or components or systems it needed to work with, in the timeframe it needed to work.
I also learned something else that day. Testing rocks. From that point, I studied all I could, even though I was a "programmer." After changing jobs, I found myslef in a position to branch out beyond what was then my "career" and learn various flavours of Unix, languages that did not exist when I went to college. Then, there was a reorganization at the company I worked for.
Part of it was rolling out a previously non-existant group. From scratch. I took the chance and have not looked back. Without running those integration tests, I am not sure I would have chosen this path.
Sunday, August 8, 2010
CAST Curtain Call (Well, Review) - Part 1
I'm in the process (still) of recovering from an incredible experience at CAST 2010. As good fortune would have it, this year CAST was held 15 minutes from my house and about 50 minutes from my office.
CAST - the Conference for the Association of Software Testing - is an incredible experience. I had been told flat out by several people that I needed to go. As luck, and project status and work schedule and finances, would have it, at the last minute, I could.
It was very strange. I got an email from friend/colleague/fellow-tester Matt Heusser asking if I was available to help out. Now, I had previously told him that I may be able to help with some of the running around stuff, but probably would not be able to attend because of the state of the project. Matt sounded like a bit of help was needed. I checked with the project team on the state of things, checked with the boss, and determined that since it was so close, I could "work from conference" (as opposed to work from home) thus learning as much as possible, keeping the project rolling and helping folks with their conference as much as possible.
Long story even longer, I'm in as a volunteer, helping to lug stuff and helping to make and post signs at appropriate times and generally lending a hand at the registration table and being cheerful.
Sunday, before the conference officially began and while the AST Board was meeting, I went to the conference center (Prince Conference Center at Calvin College - lovely facilities) to pick up some boxes of books that were delivered Friday.
While there, I met Dorothy Graham, a fellow native of Grand Rapids, who was looking for someone who promised to meet her there. We introduced ourselves and I made my first uncontrolled reaction of the week "Oh yes! I have your book!" She laughed graciously. (If you have not read her book, I suggest you do so.
I then ran into Fiona Charles, who introduced me to Giffin Jones and a legion of other folks whose writings I had read for some time, but I had never met in person, including Cem Kaner.
Fiona, Griffin and I went to dinner, with my lady-wife joining us. We talked about anything and everything. A couple of bottles of a very drinkable red wine, plates mounded with pasta and a lovely terraza made for an evening that was the perfect introduction to the week.
Monday I was at the office most of the day, but swung by the conference in time to catch up with some people and meet Scott Barber and another flock of people leaving me in awe to be walking among the mighty of our craft.
Tuesday morning, I was there bright and early, laptop, headphones and powercord in hand. Jumped in with posting sign updates and then helping out with participants arriving, meeting people and sipping coffee. About the time the keynote speaker (Tim Lister) began, I was at the table dealing with work emails and helping the odd person coming in late.
Note - if you ever find yourself in a position to help at a conference, DO IT. You get to meet an amazing number of people and usually it gets you in the conference at no (financial) charge.
One poor lady came in just at lunch time - her flight from India had been delayed, getting her in Tuesday morning instead of Monday evening. She registered with the conference, checked in for her room at the registration desk and came back to ask if the conference required formal attire. I assued her it did not, and made the observation that the fellow who came in a few minutes after her was dressed very casually and he (Michael Bolton) was speaking. She was relieved went to her room, then came down to get lunch as I went to a conference call for work.
I was able to attend a couple of sessions Tuesday. One - Nancy Kelln's presentation on "Cutting the Mustard - Lessons Learned in Striving to be a Superstar Tester" was extremely good. Nancy is a bright, articulate, up-and-comer who stands out among a flock of other bright, articulate, up-and-comers. Solid questions were raised and addressed both by Nancy and by other participants.
If you have not been to CAST, that last bit "by other participants," is one of the things that sets CAST apart from other conferences. In a 60 minute time slot, 20 minutes are reserved for what others would call "Questions" but at CAST is "Open Season." There are colour coded cards distributed to each participant - Green is a "new thread" on the presentation, Yellow or light green is a comment on the current thread or previous comments - there are others, but those two are the most commonly used. A facilitator keeps the sessions in order and calls people in turn to speak. It truely is "open season" and anyone, not just the speaker, who has something to say had better be able to defend what they say.
Both of the presentations I was able to attend on Wednesday were extremely good. Karen Johnson gave a brilliant presentation (Reporting Skills and Software Testing) on approaching testing, and meeting with business experts, the same way a "newspaper reporter" might. This went beyond the fairly obvious "communication models" one might expect. She touched on several ideas that I know I, at least, had not considered.
Karen hit one idea around fact and opinion that struck me as a brilliant observation. "When do you cross the line between fact and opinion? Emotion." That is probably worth a blog entry in itself. As it is, suffice to say that when one is attempting to sift through what is "fact" and what is "believed to be fact" you can do a reality check with yourself, or with the person you are working with by checking the level of emotion. "I found something that did not match what I expected to see, is this right?" "Of COURSE it is! I checked it myself - its RIGHT!" Ones facts may be challenged, but expect a strong response if ones emotions or beliefs are challenged. Most importantly, when there is a strong response, recognize it as a reaction to the opinion being challenged and don't take it personally.
Finally, I rounded out my day with a presentation by Lynn McKee. Lynn, another bright, up-and-comer, gave a solid presentation on assessing your value as a tester. That she sparked a lively debate during open season is, in my mind, an indicator that she touched on something that many testers are looking for - how does one define value when value itself is subjective?
CAST - the Conference for the Association of Software Testing - is an incredible experience. I had been told flat out by several people that I needed to go. As luck, and project status and work schedule and finances, would have it, at the last minute, I could.
It was very strange. I got an email from friend/colleague/fellow-tester Matt Heusser asking if I was available to help out. Now, I had previously told him that I may be able to help with some of the running around stuff, but probably would not be able to attend because of the state of the project. Matt sounded like a bit of help was needed. I checked with the project team on the state of things, checked with the boss, and determined that since it was so close, I could "work from conference" (as opposed to work from home) thus learning as much as possible, keeping the project rolling and helping folks with their conference as much as possible.
Long story even longer, I'm in as a volunteer, helping to lug stuff and helping to make and post signs at appropriate times and generally lending a hand at the registration table and being cheerful.
Sunday, before the conference officially began and while the AST Board was meeting, I went to the conference center (Prince Conference Center at Calvin College - lovely facilities) to pick up some boxes of books that were delivered Friday.
While there, I met Dorothy Graham, a fellow native of Grand Rapids, who was looking for someone who promised to meet her there. We introduced ourselves and I made my first uncontrolled reaction of the week "Oh yes! I have your book!" She laughed graciously. (If you have not read her book, I suggest you do so.
I then ran into Fiona Charles, who introduced me to Giffin Jones and a legion of other folks whose writings I had read for some time, but I had never met in person, including Cem Kaner.
Fiona, Griffin and I went to dinner, with my lady-wife joining us. We talked about anything and everything. A couple of bottles of a very drinkable red wine, plates mounded with pasta and a lovely terraza made for an evening that was the perfect introduction to the week.
Monday I was at the office most of the day, but swung by the conference in time to catch up with some people and meet Scott Barber and another flock of people leaving me in awe to be walking among the mighty of our craft.
Tuesday morning, I was there bright and early, laptop, headphones and powercord in hand. Jumped in with posting sign updates and then helping out with participants arriving, meeting people and sipping coffee. About the time the keynote speaker (Tim Lister) began, I was at the table dealing with work emails and helping the odd person coming in late.
Note - if you ever find yourself in a position to help at a conference, DO IT. You get to meet an amazing number of people and usually it gets you in the conference at no (financial) charge.
One poor lady came in just at lunch time - her flight from India had been delayed, getting her in Tuesday morning instead of Monday evening. She registered with the conference, checked in for her room at the registration desk and came back to ask if the conference required formal attire. I assued her it did not, and made the observation that the fellow who came in a few minutes after her was dressed very casually and he (Michael Bolton) was speaking. She was relieved went to her room, then came down to get lunch as I went to a conference call for work.
I was able to attend a couple of sessions Tuesday. One - Nancy Kelln's presentation on "Cutting the Mustard - Lessons Learned in Striving to be a Superstar Tester" was extremely good. Nancy is a bright, articulate, up-and-comer who stands out among a flock of other bright, articulate, up-and-comers. Solid questions were raised and addressed both by Nancy and by other participants.
If you have not been to CAST, that last bit "by other participants," is one of the things that sets CAST apart from other conferences. In a 60 minute time slot, 20 minutes are reserved for what others would call "Questions" but at CAST is "Open Season." There are colour coded cards distributed to each participant - Green is a "new thread" on the presentation, Yellow or light green is a comment on the current thread or previous comments - there are others, but those two are the most commonly used. A facilitator keeps the sessions in order and calls people in turn to speak. It truely is "open season" and anyone, not just the speaker, who has something to say had better be able to defend what they say.
Both of the presentations I was able to attend on Wednesday were extremely good. Karen Johnson gave a brilliant presentation (Reporting Skills and Software Testing) on approaching testing, and meeting with business experts, the same way a "newspaper reporter" might. This went beyond the fairly obvious "communication models" one might expect. She touched on several ideas that I know I, at least, had not considered.
Karen hit one idea around fact and opinion that struck me as a brilliant observation. "When do you cross the line between fact and opinion? Emotion." That is probably worth a blog entry in itself. As it is, suffice to say that when one is attempting to sift through what is "fact" and what is "believed to be fact" you can do a reality check with yourself, or with the person you are working with by checking the level of emotion. "I found something that did not match what I expected to see, is this right?" "Of COURSE it is! I checked it myself - its RIGHT!" Ones facts may be challenged, but expect a strong response if ones emotions or beliefs are challenged. Most importantly, when there is a strong response, recognize it as a reaction to the opinion being challenged and don't take it personally.
Finally, I rounded out my day with a presentation by Lynn McKee. Lynn, another bright, up-and-comer, gave a solid presentation on assessing your value as a tester. That she sparked a lively debate during open season is, in my mind, an indicator that she touched on something that many testers are looking for - how does one define value when value itself is subjective?
Tuesday, July 6, 2010
Defining and Redefining Requirements
Its been crazy-busy at work. In addition, its summer which means lots of stuff to do in the garden and around the house. Time for other activities has been pretty rare. Sometimes, "other things" kick in.
Last Friday I mentioned I was a bit "under the weather." The worst part was the enforced physical idleness - not "not doing anything" idle, but not able to do the things I otherwise would do or needed to do. So, I've been catching up on my reading.
One book I've been reading is by Rebecca Staton-Reinstein called Conventional Wisdom How Today's Leaders Plan, Perform, and Progress Like the Founding Fathers. Its been an interesting read.
Vignettes from the (United States) Constitutional Convention give a framework for the lessons provided in contemporary case studies. The book is laid out by "Articles" - mimicking the US Constitution. That got me thinking about previous teams I've been a part of, and how un-like the Framers some of them functioned.
My blog post from Friday contained, well, remembrances from a past position. One thing from that was the Forced Best Practices environment. There were a fair number of people who wanted to do good work. There were others who tried to "follow the process" come-what-may. This created a potential for people to derail projects they wanted to fail, or, to assert their authority and dominate the process, inspite of what those tasked with running the project wished to do. In short, the project leaders/managers for a fair number of the most productive projects found a way by-pass the "official" process and focus on what needed to be done.
One of the tactics among those intending to derail the process was to bemoan "thrash" or "continually revisiting things we already decided."
On the surface, this makes a great deal of sense. After all...
Time is money and once a decision is made we must move forward because otherwise we're never going to make any progress. Once we have a direction we most move immediately. We must act. If we find weve acted wrongly, act again to correct it. They may well cite Ulysses S. Grant (who is eminantly quotable, by the way) on always moving towards objectives and "retreating forward."
The problem is, as the framers of the Constitution knew, one decision informs another. The deliberations around one topic may shed light on other topics. If the deliberations shed light on a topic that was "settled," the framers considered it entirely reasonable to reconsider that topic and any other previously settled decision that may be impacted.
What an amazingly time consuming process. Is it reasonable in today's software development process to see this as a reasonable approach? Can we really consider, or reconsider requirements that were "defined" two hours ago? What about two weeks? Is two months out of the question?
When a software project runs into an "issue" with requirements - why is that? Did the scope change? Did the requirements change? Did the "users" change what they wanted? Or did the understanding of the requirements change?
Are there presumptions in place that "everyone" knew, but did not communicate? Was the understanding match among all participants?
I'm not a world famous testing guru. I'm not a sought after speaker for software conferences and conventions. I'm not a famous historian or student of history. I do software testing for a living. I've seen some really good projects and some that were absolute trainwrecks. Some of those can be categorized as U. S. Grant did that "errors were of judgement, not intent." Where do we lowly software testers fall?
My assertion is, requirements will almost always be revisted. Sometimes it will be in the "requirements discovery process" other times it will be while the design is being worked in. Other times, while program code is being written, mis-matches or conflicts may be found. Occasionally, software testing will find inconsistencies in requirements when they "put all the pieces together."
Each of these instances is a far more expensive exercise than taking the time to revisit requirements and discuss them fully. What precisely does a phrase mean? What is the intent of this? Most importantly: Do the requirements work as a whole? Do they define a complete entity?
Do they summarize what the project team is to address? Do they describe the business needs to be fulfilled? Does everyone share the vision that is needed to fill those needs?
Defining your requirements does not mean that you need to know how the team will meet them. That is what the design process is for. If you can define the needs - you can define the way to fill those needs.
Last Friday I mentioned I was a bit "under the weather." The worst part was the enforced physical idleness - not "not doing anything" idle, but not able to do the things I otherwise would do or needed to do. So, I've been catching up on my reading.
One book I've been reading is by Rebecca Staton-Reinstein called Conventional Wisdom How Today's Leaders Plan, Perform, and Progress Like the Founding Fathers. Its been an interesting read.
Vignettes from the (United States) Constitutional Convention give a framework for the lessons provided in contemporary case studies. The book is laid out by "Articles" - mimicking the US Constitution. That got me thinking about previous teams I've been a part of, and how un-like the Framers some of them functioned.
My blog post from Friday contained, well, remembrances from a past position. One thing from that was the Forced Best Practices environment. There were a fair number of people who wanted to do good work. There were others who tried to "follow the process" come-what-may. This created a potential for people to derail projects they wanted to fail, or, to assert their authority and dominate the process, inspite of what those tasked with running the project wished to do. In short, the project leaders/managers for a fair number of the most productive projects found a way by-pass the "official" process and focus on what needed to be done.
One of the tactics among those intending to derail the process was to bemoan "thrash" or "continually revisiting things we already decided."
On the surface, this makes a great deal of sense. After all...
Time is money and once a decision is made we must move forward because otherwise we're never going to make any progress. Once we have a direction we most move immediately. We must act. If we find weve acted wrongly, act again to correct it. They may well cite Ulysses S. Grant (who is eminantly quotable, by the way) on always moving towards objectives and "retreating forward."
The problem is, as the framers of the Constitution knew, one decision informs another. The deliberations around one topic may shed light on other topics. If the deliberations shed light on a topic that was "settled," the framers considered it entirely reasonable to reconsider that topic and any other previously settled decision that may be impacted.
What an amazingly time consuming process. Is it reasonable in today's software development process to see this as a reasonable approach? Can we really consider, or reconsider requirements that were "defined" two hours ago? What about two weeks? Is two months out of the question?
When a software project runs into an "issue" with requirements - why is that? Did the scope change? Did the requirements change? Did the "users" change what they wanted? Or did the understanding of the requirements change?
Are there presumptions in place that "everyone" knew, but did not communicate? Was the understanding match among all participants?
I'm not a world famous testing guru. I'm not a sought after speaker for software conferences and conventions. I'm not a famous historian or student of history. I do software testing for a living. I've seen some really good projects and some that were absolute trainwrecks. Some of those can be categorized as U. S. Grant did that "errors were of judgement, not intent." Where do we lowly software testers fall?
My assertion is, requirements will almost always be revisted. Sometimes it will be in the "requirements discovery process" other times it will be while the design is being worked in. Other times, while program code is being written, mis-matches or conflicts may be found. Occasionally, software testing will find inconsistencies in requirements when they "put all the pieces together."
Each of these instances is a far more expensive exercise than taking the time to revisit requirements and discuss them fully. What precisely does a phrase mean? What is the intent of this? Most importantly: Do the requirements work as a whole? Do they define a complete entity?
Do they summarize what the project team is to address? Do they describe the business needs to be fulfilled? Does everyone share the vision that is needed to fill those needs?
Defining your requirements does not mean that you need to know how the team will meet them. That is what the design process is for. If you can define the needs - you can define the way to fill those needs.
Friday, July 2, 2010
Rhythm and Reality
I was a bit "under the weather" recently. I was thinking about a lot of things. One of them was rhythm.
I teach drumming, private lessons, group lessons and workshops. Rhythm is a big deal for drummers. Its kind of what we do. So, I went looking for how rhythm is defined by "non-drummers." So I went to the web.
I went to freedictionary.com and found this:
You get the idea, no?
Repeated patterns. Repeated actions. Repeated behaviors.
Have you noticed a repetition in projects or test efforts? Things keep coming back - almost like deja vu?
If things are working and "the process" is cracking-on, there are no problems. Right? No worries - you've got it down.
If things are, not-so-good - then what? Are your projects sounding a bit repetitious? Are they following the same model or are there slight variations in them? Is the "this could have been better" project from a year ago a role model of current projects or a warning for how future projects may go? Are things muddling along or are they getting worse?
If they are getting worse, why? Did the "lessons learned" sessions from the previous projects get acted on? Have your "process changes" been carried through and embraced by all particpants or by only some? If you're like me, you've worked in shops where that pretty well sums up the situation.
I remember one shop where I worked some time ago. They had beautiful documentation. Lots and lots of process. This happens - then this happens - then this happens. The Certified Project Managers pushed the Best Practices and Industry Standards to a fare-thee-well. They kept tight control over their progress meetings ("This is an update meeting, not a working meeting. If you need to discuss it, do so in a meeting other than this one.")
Projects were regularly train-wrecks.
All the participants made a great show of "following the process." Except they only went through the motions. It was an elaborate charade - they dutifully attended every meeting and carefully reported what was done and what needed to be done.
When the whole team really does what they were say they do, magical things can happen. One cynical... not nice person... can completely derail the project.
What I learned there, was to ignore the rules. When we projects focused on what needed to be done, and forced the "process" to that end, amazing things could occur. When the "process" drove the steps needed, the project failed.
There was rhythm in both cases. Its just one looked good on paper, the other looked messy - but it had a good beat and you could dance to it.
I teach drumming, private lessons, group lessons and workshops. Rhythm is a big deal for drummers. Its kind of what we do. So, I went looking for how rhythm is defined by "non-drummers." So I went to the web.
I went to freedictionary.com and found this:
1. Movement or variation characterized by the regular recurrence or alternation of different quantities or conditions.
2. The patterned, recurring alternations of contrasting elements of sound or speech.
3. Music
a. The pattern of musical movement through time.
b. A specific kind of such a pattern, formed by a series of notes differing in duration and stress: a waltz rhythm.
c. A group of instruments supplying the rhythm in a band.
4.
a. The pattern or flow of sound created by the arrangement of stressed and unstressed syllables in accentual verse or of long and short syllables in quantitative verse.
b. The similar but less formal sequence of sounds in prose.
c. A specific kind of metrical pattern or flow.
You get the idea, no?
Repeated patterns. Repeated actions. Repeated behaviors.
Have you noticed a repetition in projects or test efforts? Things keep coming back - almost like deja vu?
If things are working and "the process" is cracking-on, there are no problems. Right? No worries - you've got it down.
If things are, not-so-good - then what? Are your projects sounding a bit repetitious? Are they following the same model or are there slight variations in them? Is the "this could have been better" project from a year ago a role model of current projects or a warning for how future projects may go? Are things muddling along or are they getting worse?
If they are getting worse, why? Did the "lessons learned" sessions from the previous projects get acted on? Have your "process changes" been carried through and embraced by all particpants or by only some? If you're like me, you've worked in shops where that pretty well sums up the situation.
I remember one shop where I worked some time ago. They had beautiful documentation. Lots and lots of process. This happens - then this happens - then this happens. The Certified Project Managers pushed the Best Practices and Industry Standards to a fare-thee-well. They kept tight control over their progress meetings ("This is an update meeting, not a working meeting. If you need to discuss it, do so in a meeting other than this one.")
Projects were regularly train-wrecks.
All the participants made a great show of "following the process." Except they only went through the motions. It was an elaborate charade - they dutifully attended every meeting and carefully reported what was done and what needed to be done.
When the whole team really does what they were say they do, magical things can happen. One cynical... not nice person... can completely derail the project.
What I learned there, was to ignore the rules. When we projects focused on what needed to be done, and forced the "process" to that end, amazing things could occur. When the "process" drove the steps needed, the project failed.
There was rhythm in both cases. Its just one looked good on paper, the other looked messy - but it had a good beat and you could dance to it.
Sunday, June 13, 2010
Requirements and Presumptions
A common theme at conferences and workshops is "tell a story" - so here we go.
Once upon a time, there was a software project. This project had a variety of components, some were better understood than others. As sometimes happens, information was presented decisions were made in discussions where not all the interested parties are present. In this case, the testers were wrapping up another project and others involved in this one made the decision that testers weren't really "needed" yet.
So, life went on. The testers finished their project. They were given copies of the documents that had been prepared on this project. So they read the documents and worked on their own documents, like test plans and test cases. More meetings happened and conversations happened and emails were sent and read and replied to (well, were certainly replied to, maybe they were read by everyone.) Some of these had everyone present or copied or included, and some did not.
When the intrepid testing folks compared notes on an item described in the requirements documentation, they realized their understanding on did not match. No problem! They asked the tech lead to clarify what the correct interpretation should be. The answer? Neither was correct. And he explained why.
He then decided to verify what he had reported and brought the question to the business experts. Their answer consisted of "Well, everyone knows what that means..." and then they realized they each "business expert" had a different understanding of this very, basic element of their requirements.
No one had thought to define the terms. Then, to make it worse, no one had asked what the terms meant. It is possible that each participant believed they shared a common understanding. However, no one made sure that was the case.
I was not part of this project. It strikes me that most people fall into this trap at least once. Sometimes, twice.
Always question your unquestionable facts. They may not be as factual as you presume.
Once upon a time, there was a software project. This project had a variety of components, some were better understood than others. As sometimes happens, information was presented decisions were made in discussions where not all the interested parties are present. In this case, the testers were wrapping up another project and others involved in this one made the decision that testers weren't really "needed" yet.
So, life went on. The testers finished their project. They were given copies of the documents that had been prepared on this project. So they read the documents and worked on their own documents, like test plans and test cases. More meetings happened and conversations happened and emails were sent and read and replied to (well, were certainly replied to, maybe they were read by everyone.) Some of these had everyone present or copied or included, and some did not.
When the intrepid testing folks compared notes on an item described in the requirements documentation, they realized their understanding on did not match. No problem! They asked the tech lead to clarify what the correct interpretation should be. The answer? Neither was correct. And he explained why.
He then decided to verify what he had reported and brought the question to the business experts. Their answer consisted of "Well, everyone knows what that means..." and then they realized they each "business expert" had a different understanding of this very, basic element of their requirements.
No one had thought to define the terms. Then, to make it worse, no one had asked what the terms meant. It is possible that each participant believed they shared a common understanding. However, no one made sure that was the case.
I was not part of this project. It strikes me that most people fall into this trap at least once. Sometimes, twice.
Always question your unquestionable facts. They may not be as factual as you presume.
Monday, June 7, 2010
Stawberry Testing Fields
Yesterday I wrote about the garden. We really have a nice one. I learn a lot working in it.
There is a rhythm in gardening that simply can't be ignored. Brute force and frantic bursts of energy don't get you much. Patience is good, and persistence.
Strawberries are coming in right now. We picked the first two this past Thursday. More were ripe on Friday. Saturday there were more. Last night I picked a couple of pints of berries. We have enough on the vine to have a fair crop of berries this year.
This is great, because we put in a new strawberry patch last year, replacing the old one. Its not huge, around 6 feet long, semi-circular, around 3 or 4 feet wide at its widest point. The old one was huge for a city lot. Almost 20'x20'. Unfortunately, when the new driveway was put in, the berry patch had to go. We did move the topsoil to a great location. This had been worked and improved for many, many years and was fantastic for growing things.
Last year, we planted tomatoes in that soil, as we had the year before. Oops. No tomatoes there this year thanks to the blight.
BUT - the new strawberry patch is doing extremely well.
As I was picking berries last night, my dear lady-wife made the observation that sometimes beautiful ripe berries will "hide" under the leaves or tucked out of the way. So, as I was carefully going through picking what I could find, it dawned on me that shifting leaves and plants may help, or may not.
Something struck me though. As I was working in one area, I looked over toward where I had just been working, I saw three lovely ripe berries - right where I had decided I had found everything that was ripe and moved on.
In shifting my view, my perspective, I found three berries where a moment before I absolutely "knew" there were none ripe.
It dawned on me then and there, that the challenge in finding bugs is overcoming our own solid "knowing" that we have finished. If you change your perspective, and look again, are you still finished?
Does this shift in perspective reveal you things you did not know? Are there items you may not have considered? In shifting your view do you find bugs you would have missed?
There is a rhythm in gardening that simply can't be ignored. Brute force and frantic bursts of energy don't get you much. Patience is good, and persistence.
Strawberries are coming in right now. We picked the first two this past Thursday. More were ripe on Friday. Saturday there were more. Last night I picked a couple of pints of berries. We have enough on the vine to have a fair crop of berries this year.
This is great, because we put in a new strawberry patch last year, replacing the old one. Its not huge, around 6 feet long, semi-circular, around 3 or 4 feet wide at its widest point. The old one was huge for a city lot. Almost 20'x20'. Unfortunately, when the new driveway was put in, the berry patch had to go. We did move the topsoil to a great location. This had been worked and improved for many, many years and was fantastic for growing things.
Last year, we planted tomatoes in that soil, as we had the year before. Oops. No tomatoes there this year thanks to the blight.
BUT - the new strawberry patch is doing extremely well.
As I was picking berries last night, my dear lady-wife made the observation that sometimes beautiful ripe berries will "hide" under the leaves or tucked out of the way. So, as I was carefully going through picking what I could find, it dawned on me that shifting leaves and plants may help, or may not.
Something struck me though. As I was working in one area, I looked over toward where I had just been working, I saw three lovely ripe berries - right where I had decided I had found everything that was ripe and moved on.
In shifting my view, my perspective, I found three berries where a moment before I absolutely "knew" there were none ripe.
It dawned on me then and there, that the challenge in finding bugs is overcoming our own solid "knowing" that we have finished. If you change your perspective, and look again, are you still finished?
Does this shift in perspective reveal you things you did not know? Are there items you may not have considered? In shifting your view do you find bugs you would have missed?
Gardening
We have a fairly large garden. Actually, my lady-wife has a large garden and I'm the helper. This works out pretty well for both of us. She gets more work done than she could do herself, and I get something interesting that can sometimes be missing when working in some software shops: a specific, tangible result from your efforts.
In some places I've worked, projects are never really "done." You finish one project and the next is, well, more modifications to the same application. The result is, you are never really "done."
Gardening isn't like that. You work for four or five, or more, hours in a day and you can see what you have accomplished. You can see clearly defined areas without weeds, flowers, maybe vegetables, but always something you can look at and say "I did that today."
This weekend was a great example. Saturday morning there were some big, ugly nasty weeds growing along the fenceline, near where the vegetable garden goes. We got well over half of the weeds dug or pulled. By the time we had made it that far, the sun was pretty hot, so work shifted to a shady area in another part of the year. While we did not finish that portion on Saturday, the work that remains can be finished in another good day's work. The list is fairly simple: finish pulling the weeds; till the garden; hoe it back into rows. Then we can plant again.
Last year's rows are still visible. This is part of the garden's version of a "legacy" system. The footprint of last year is there. The problem is, sometimes that can make more work.
Where we are, and a fair portion of the state and region, tomatoes had a blight last year. This was a fungal infection, related to the same blight that caused the potato famine in Ireland in the 1840's. The relationship is the spores from the fungus. Because the spores are found where the plants were last year, there is a problem with the "legacy system" - we can't put the tomatoes where we have in the past. We also need to get them as far away from where they had been as we can get them.
The solution was pretty simple. Spores are contained in the ground. To keep the tomatoes from getting blight keep them from coming in contact with the spores. So, as with most of the really good ideas in the garden - well, all of them, my lady-wife came up with a solution. Pots. Lots of pots. Large pots. Lots of very large pots. In a sunny spot with no contact with the soil that may have blight spores. The top of the driveway, of course. Hot and sunny, good for tomatoes. Near the rain barrels so easy watering. Tomatoes like a lot of water, so this is good for both them and us.
Moral of the story? Just because you've "always done things this way," does not mean that another is available - particularly if the solution presents itself.
Have you ever noticed that the solution "presenting itself" usually happens when you need to completely change the rules? How often can we make the rules change in what we do with software? Beets me. Lettuce try.
In some places I've worked, projects are never really "done." You finish one project and the next is, well, more modifications to the same application. The result is, you are never really "done."
Gardening isn't like that. You work for four or five, or more, hours in a day and you can see what you have accomplished. You can see clearly defined areas without weeds, flowers, maybe vegetables, but always something you can look at and say "I did that today."
This weekend was a great example. Saturday morning there were some big, ugly nasty weeds growing along the fenceline, near where the vegetable garden goes. We got well over half of the weeds dug or pulled. By the time we had made it that far, the sun was pretty hot, so work shifted to a shady area in another part of the year. While we did not finish that portion on Saturday, the work that remains can be finished in another good day's work. The list is fairly simple: finish pulling the weeds; till the garden; hoe it back into rows. Then we can plant again.
Last year's rows are still visible. This is part of the garden's version of a "legacy" system. The footprint of last year is there. The problem is, sometimes that can make more work.
Where we are, and a fair portion of the state and region, tomatoes had a blight last year. This was a fungal infection, related to the same blight that caused the potato famine in Ireland in the 1840's. The relationship is the spores from the fungus. Because the spores are found where the plants were last year, there is a problem with the "legacy system" - we can't put the tomatoes where we have in the past. We also need to get them as far away from where they had been as we can get them.
The solution was pretty simple. Spores are contained in the ground. To keep the tomatoes from getting blight keep them from coming in contact with the spores. So, as with most of the really good ideas in the garden - well, all of them, my lady-wife came up with a solution. Pots. Lots of pots. Large pots. Lots of very large pots. In a sunny spot with no contact with the soil that may have blight spores. The top of the driveway, of course. Hot and sunny, good for tomatoes. Near the rain barrels so easy watering. Tomatoes like a lot of water, so this is good for both them and us.
Moral of the story? Just because you've "always done things this way," does not mean that another is available - particularly if the solution presents itself.
Have you ever noticed that the solution "presenting itself" usually happens when you need to completely change the rules? How often can we make the rules change in what we do with software? Beets me. Lettuce try.
Subscribe to:
Posts (Atom)
