Skip to main content

The Macro Expansion Heuristic – A Real World Example

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 correctly say what was meant or did not mean what was said.

We talked it through and mapped it out in our mind map, but were still unable to agree that the statement was correct, but by now I believe that my colleague was also unsure as to whether or not he had said what he meant or meant what he said. It then occurred to me that I had seen a similar problem before, and that problem had been presented along with a heuristic that we could apply to solve the problem – the concept of a macro expansion, which I had first seen applied to communication by Michael Bolton in his blog post “What Do You Mean By ‘Arguing Over Semantics’?”

When we generalize on the concept of a macro expansion we can utilize it to take a single word and expand it into a series of words that more accurately express what we mean. I asked my colleague if we could do a small exercise on the white board to sort this out, and he agreed. Taking one of the markers present I wrote on the board:

“We’re modeling the requirement.”

As I was writing I told my colleague that if we were to expand that statement, we would get something that better said what was meant. So, under that I wrote:

“We’re modeling that the requirement was correctly implemented.”

After further discussion we agreed this could be shortened without a loss of clarity, so I wrote:

“We’re modeling correct implementation.”

We were both comfortable with that statement, and felt that it truly expressed what we were attempting to say. 

 Having the feeling that we were on to something, we took this one step further. If we’re modeling correct implementation then any discrepancy between the actual implementation and what we have modeled means that there is a problem. That means that the models we are creating are mechanisms by which we recognize a problem. That sounds rather familiar....


Labels:

Comments

Post a Comment

Popular posts from this blog

Takeaways from the Continuous Automated Testing Tutorial at CAST2014

I had the opportunity to attend Noah Sussman's tutorial on Continuous Automated Testing last week as part of CAST2014. It was a great tutorial, with most of the morning spent on the theory and concepts behind continuous automated testing, and the afternoon spent with some hands-on exercises. I think that Noah really understands the problems associated with test automation in an agile environment, and the solutions that he presented in his tutorial show the true depth of his understanding of, and insight into, those problems. Here are some of the main highlights and takeaways that I got from his tutorial at CAST2014. Key Concepts Design Tools – QA and testing are design tools, and the purpose of software testing is to design systems that are deterministic Efficiency-to-Thoroughness-Trade-Offs – (ETTO) We do not always pick the best option, we pick the one that best meets the immediate needs Ironies of automation – Automation makes things more complex and, while tools can make...
11 comments
Read more

Let’s Continue to Drive Software Testing Education Forward

It’s Time to Embrace the Student Who Learns Differently Last in a series. In my last two posts I’ve written about enhancing the student and instructor experience in the AST’s BBST courses by focusing on updating the Fieldstones and making BBST courses more accessible by identifying some of the more common obstacles to BBST participation, and then working collectively to find ways to lower or remove those obstacles. In this post, I want to discuss the third and final area I would like to concentrate on if elected to the Board of Directors: researching and establishing alternate approaches to teaching that better suit different learning styles. As members of the AST, we have access to some of the best information and training available in the field of software testing. The AST hosts the Conference of the Association for Software Testing (CAST) each year, providing full-day tutorials, keynotes, and track sessions. They also offer four separate BBST courses:  Foundations, ...
11 comments
Read more

CloudFormation Templates: Using Ref to Access Run Time Information

When working with AWS CloudFormation, many of the resource properties we reference in our stack template will not be available until the stack is built and creation of that particular resource has been initiated. For example, suppose we're declaring an ECS service called MigrateDatabaseService to run and maintain a task based on the MigrateTask task definition. One of the required properties of the AWS::ECS::Service resource is a string containing the Amazon Resource Name (ARN) of the task definition (including the revision number) that we want to run on the cluster. The problem is that the task definition is declared in the same template, but the ARN will not be available until run time. So, how do we specify a run time value at design time? CloudFormation provides eleven built-in, or intrinsic, functions that we can use to assign values to properties that are not available until run time. The intrinsic function we need to use to populate the TaskDefinition propert...
Post a Comment
Read more