Ridgeback Tested

It started as a joke. Having recently watched the Big Bang Theory episode `The Herb Garden Germination` and reviewing too many resumes listing the same buzz words over and over, I had an idea: create some term or concept, inject it into the wild with enough backing information to make it sound legitimate, and see if it ever made it back to me in a resume and, if so, how long it took to get back to me. I needed something in an area that was being used where I worked as well as in enough other environments to be feasible, yet wasn't widely popular. The perfect candidate seemed to be model-based testing. So, I came up with the concept of Cross-Matrix Defect Analysis – multiplying a state transition matrix by a matrix of known defects to get a sort of weighted state transition matrix. I worked up a few formulas, wrote them on a whiteboard in a prime location at work, and recruited colleagues to help me plant the seeds so that when someone asked, “What’s that?” they could respon

My wife and I took the Ridgeback for her first tracking class last Saturday at the Oak Ridge Kennel Club. It was basically an introduction to tracking for the handlers, with a short hands-on exercise with the dogs to wrap things up. The exercise was not to have the dogs track at this point; the instructors wanted to get the dog to realize that there is something “out there” for them to find, and when they do find it they hit the jackpot with treats galore, exuberant praise, and playtime. The idea is to get the dogs to follow a trail of food from a starting point with one article, usually a sock or a glove, to the end where a matching article is located. We laid the track by using a survey flag to mark the start of the track, and we would place the first article on the ground, step on it, and place a piece of food on top of it. We would then walk twelve to fifteen steps, place another survey flag, get the dog’s attention, wave the second article around while they were watching, the

It's time for Techtoberfest at work – a technology summit held every October that provides an opportunity for employees from all over the company to sign up and present on a technology of their choice. It’s traditionally been very developer-heavy, and submissions from my team are often rejected with a quick “we already have a presentation about testing, we don’t need any more.” But there was a changing of the guard this year, and a new group was asked to take it over and revamp it. Seeing an opportunity to beat our own drum and show off the hard work the test automation group had put into completing the model-driven automation framework, I asked the automation lead to submit a presentation. As we were brainstorming about the presentation, we came up with the idea to use the AutoTweet PowerPoint add-in to tweet the talking points as the presentation progressed. We created a Twitter account to use (@ScrippsQA), installed the add-in, and got to work on the presentation. It wasn’t

I enjoy learning new things, and I especially enjoy making connections between things I've learned or read about, and applying them to real-world situations. I had the opportunity to do that today while I was brainstorming with a colleague for a presentation on model-based testing and its application in intelligent automation. We were talking about the benefits that model-based testing provided when my colleague said something that caught my attention: we are modeling requirements. I tend to be overly careful in conversations about model-based testing because my experience comes from modeling the states of use of an application and not the approach we’re taking with model-based automation, and I don’t want to use the incorrect context. So I stopped and thought about it for a few seconds before telling my colleague that I wasn't comfortable with that statement. Something about it didn't sit right with me, and I suspected it was that the statement either did not correctl

I've noticed over the past several months that the team’s Monday morning weekly kick-off meeting was becoming more and more ineffectual. It originally began with the idea of getting team members interested and involved in the projects and tasks their team mates were working on, allowing the opportunity to meet, provide input and insight, and take a break from their own projects. What it degenerated into was a high-level review of Friday’s weekly report. It wasn't quite as bad as some of those daily stand-ups I've attended where team members point at the board and mumble “Yesterday I worked on that. Today I will work on this. No obstacles.” However, it was certainly getting close. We would occasionally find the rare nugget of information that wasn't reported on Friday, but it was certainly failing to meet its initial charter. It had been my idea, and I had the responsibility to either make it work or cancel it. I had spoken with the team a few weeks ago, asking if

I've seen some conversations and blog posts recently about whether or not we should be arguing over semantics. Some I read and follow, some I don’t, but someone recently directed the people involved in one of these threads to a blog post by Michael Bolton. The post is entitled “ What Do You Mean By “Arguing Over Semantics”? , “ and I think it provides one of the best discussions I've seen on this subject. The thing that caught my attention was when Michael finishes the post by saying: “There’s a common thread that runs through these stories: they’re about what we say, about what we mean, and about whether we say what we mean and mean what we say. That’s semantics: the relationships between words and meaning. Those relationships are central to testing work.  If you feel yourself tempted to object to something by saying “We’re arguing about semantics,” try a macro expansion: “We’re arguing about what we mean by the words we’re choosing,” which can then be shortened to “We’re

Why I blog? What’s the difference between a good tester and a great tester? I think the main thing is the ability to think for yourself and to be able to incorporate your experiences as a tester back into the context of your testing practices.  I think that if you look at the software testing community and pay attention to who has good ideas and who does not, you’ll find that the vast majority of people with good ideas emphasize their experience, what they have learned from it, and how they incorporate that back into their testing. Writing about my thoughts and experiences in software testing provides an opportunity for me to take a critical look at what I thought about a subject, assess it in the context of experience and information gained since I first came to think that way, and then update or reaffirm my thoughts on the subject. It also allows me to share my thoughts, experiences, successes and failures with others, creating an additional feedback loop. That, to me, is one