Over at the Google Testing Blog, Miško Hevery has a short post on what constitutes small, medium and large testing. To summarize his post:
Throughout my career, I’ve been struck by how tight companies can be with expenditures but how freely they waste money via time. Of course, this is because labor is already budgeted and paid regardless of how efficiently it’s spent, and, I suppose, because it’s difficult to quantify time wasting.
In particular, if I get into a pointless meeting, I start to think about the money being spent. If only someone said, ‘You know, we’ve just spent $X on this meeting” it might cause people to spend their time more carefully.
Well, someone finally acted on this thought. I present to you The Meeting Cost Ticker. Enter the number of participants and the rate per hour per person, and it shows the cost of the meeting as it progresses.
(Thankfully, with agile, I get caught in far fewer pointless meetings than in non-agile environments)
(Via Boing Boing)
Early this year, the Home Depot near our home installed a self-service propane bottle exchange system. I tried it out, it failed, and I documented my experience on this blog.
A representative of Amerigas found my blog post, and contacted me about my experience in order to troubleshoot the source of the problem. I thought that was kind of cool.
Well, since several months had passed, I decided to try the self-service propane exchange again. I figured enough time had passed that the kinks had been worked out. To my surprise, I had almost the exact same experience again. I took my empty bottle but failed to open a door to a cage containing a full bottle. The only difference this time is that it apparently didn’t charge me. The receipt had ‘void’ on it.
So, I walked into the store and got in line at the service desk. While waiting for something for the person currently being helped, the service desk employee looks over, sees me holding a small scrap of paper and asks if I had trouble with the propane. He re-runs the purchase and then sends another employee out to the propane system to help me get my full bottle. With that employee’s help, I got my full* bottle of propane from the ‘self-service’ system.
I can’t believe that they’re still having such problems with the self-service propane bottle replacement system.
* ‘Full’ is a relative term. You used to get 20 lbs of propane in a full bottle, then it went down to 17.5. The bottle that I got only contained 15 lbs of propane.
NOTE: If I were WebRaiser, the company that apparently created this self-service system for Amerigas, I might want to take down my case study of the propane bottle exchange system. I’m sure the employees of my local Home Depot would disagree with this statement from the case study:
The “Big Box†home improvement stores will generate a quick financial payback. Although the specific ROI data is confidential, the labor cost savings are compelling. By capturing all transactions, the inventory shrinkage problem is virtually eliminated. The Dekko-matic also reduces restocking and logistical costs through its automated inventory control and re-ordering capabilities. (emphasis added)
I’m a member of several QA-related groups on LinkedIn, and I receive periodic update emails listing the discussions in the respective group. Often times, there is one or more posting in the group along the lines of, “If you want to expand your network then please invite me to [email address]. II will accept your Linked In invitation.”
In some cases, these posters are recruiters, and I can understand their business reason for having a large network of people who they don’t really know. In other cases, though, the poster seems to be some QA-related professional. I don’t understand how these individuals think they can benefit from having a large network of strangers.
Any ideas?
One related observation: most of the these posters seem to be in India.
Grig Gheorghiu has compiled a list of all agile testing-related links that he has put into his agile testing blog. Lots of good stuff there.
Over at his I. M. Testy blog, BJ Rollison offers succinct definitions of five approaches to automated testing: record and playback automation, keyword or action-word driven automation, scripted automation, procedural automation, and model based automation. It’s a good quick reference.
I haven’t posted much lately because I’ve been in transition between jobs. I’m in my first week in my new job as QA Lead at Hyperformix. The product dev teams at Hyperformix have just embraced agile in earnest and are about to wrap up their second sprints. Hyperformix’s new dev director, Matt Roberts, has some good agile experience under his belt, and I was hired, in part, due to my experience with agile at Borland.
As I was going over the current sprint’s team board with Matt this morning, it occurred to me that this was the first time I’ve gone into a new environment that’s using scrum. Previously, when I started a new job, discussions about how the new company does things were completely one-sided. The person I was talking to would describe the process.
In this case, however, it was much more of a dialog since Matt and I share a common standard process and vocabulary. Matt would describe how they do something, and then I would ask, “But the book says to do it this other way.” And Matt would respond by describing in more detail how they’ve implemented the scrum process in question or how they’ve chosen to deviate from the standard process and why. It was a very pleasant experience!
Over at Borland’s Agile Transformation group blog (which I contribute to), my colleague Jeff Brantley compares agile to group therapy. I think it’s an apt analogy, and it is definitely in line with my thoughts regarding agile and AA.
Over at his Collaborative Software Testing blog, Jonathan Kohl has an interesting post about Descriptive and Prescriptive Testing which he defines as follows:
A prescriptive style is a preference towards direction (“do this, do that”) while a descriptive style is more reflective (“this is what we did”). Both involve desired outcomes or goals, but one attempts to plan the path to the outcome in more detail in advance, and the other relies on trying to reach the goals with the tools you have at hand, reflecting on what you did and identifying gaps, improving as you go, and moving towards that end goal.
Jonathan also explores the personality types that are drawn to each type of testing, and he relates how he recently incorporated descriptive testing into a prescriptive environment:
For example, I helped a friend out with a testing project a few weeks ago. They directed me to a test plan and classic scripted test cases. . . Within an hour or two of following test cases, I got worried about my mental state and energy levels. I stopped thinking and engaging actively with the application and I felt bored. I just wanted to hurry up and get through the scripted tests I’d signed on to execute and move on. I wanted to use the scripted test cases as lightweight guidance or test ideas to explore the application in far greater detail than what was described in the test cases. I got impatient and I had to work hard to keep my concentration levels up to do adequate testing. I finally wrapped up later that day, found a couple of problems, and emailed my friend my report.
And then he explains how he developed some descriptive testing:
The next day, mission fulfilled, I changed gears and used an exploratory testing approach. I created a coverage outline and used the test cases as a source of information to refer to if I got stuck. I also asked for the user manual and release notes. I did a small risk assessment and planned out different testing techniques that might be useful. I grabbed my favorite automated web testing tool and created some test fixtures with it so I could run through hundreds of tests using random data very quickly. That afternoon, I used my lightweight coverage to help guide my testing and found and recorded much more rich information, more bugs, and I had a lot of questions about vague requirements and inconsistencies in the application.
Like Jonathan, I definitely lean towards the descriptive testing approach. In fact, you might say that the experience that I recently described in my post Just enough process: the checklist was an attempt to balance out prescriptive and descriptive testing.
Over at the Agile Software Development blog, Janusz Gorycki reminds us that scrum activities–daily stand-up, planning, retrospectives–play an important role beyond the purported goal of each activity:
The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management (“Good To Great†by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That’s not their purpose to be efficient.
I love it that he calls these scrum activities “liturgies.” As a church-goer, I think it’s an apt analogy. I recognize that there is indeed a certain value in just coming together with my fellow parishoners each week and at the very least, going through the motions together. Though with church, as with work, you need to try to keep the point of the ritual in mind.
