Wednesday, January 14, 2009

When Contexts Collide...

I got a first-hand reminder recently of the value of the idea of Automation Contexts. A conflict that I was having a lot of trouble framing productively suddenly came into focus for me when I looked at it through the lens of contexts.

Recently a couple of testers in our functional test team rewrote on of the modules of our test automation system and started using their changes on their own test harnesses. The changes that they made enabled them to add some additional gear to the test rig and do some testing that wasn't previously possible.

Everybody was really excited about this--it's always good to have the capabilities of the system expand, and this showed that the capability of the functional test team was also expanding. A year ago there was no one working on the functional team who had the knowledge of the automation system and the technical skills required to do something like this.

We decided that we wanted to take their code and integrate it into the ITE (our automation system). Then the fun started.

There was a chain of emails that, when you boil it down and strip away the polite phrasing, went something like this:
Automation person: "This code is really good, but it isn't done yet, there are several other things that need to written before we can use this:

Functional test person: "This code is really useful. We're already using it."

Automation person: "Yes, like I said, this is good code, but it doesn't solve the whole problem."

Functional test person: "This is really useful code. Look at this list of bugs that we've found using it."

Automation person: "We often find a lot of bugs while we are developing a new piece of automation functionality. But there is still work that needs to be done before we can use this code."

Functional test person: "Why do you keep saying it isn't done yet?"
This all went back and forth over a couple of days when I was out of the office. The next day, when I was back in the office my manager came and asked me what I thought was happening, and how I wanted to handle it. I thought about it for a little while, and noted that the people involved seemed to be talking past each other.

I went and talked to my principal engineer for a while. As we were talking, it dawned on me that this was an example of Project Context needs being different from Product-Line Context needs. The functional testers had written something that addressed their needs for their project.

Because it addressed their needs for their project, the functional test manager was happy and didn't immediately see why the automation team thought additional work was needed. Looking at it from the Project Context, it really was done, and there was no need to do additional work.

But when my team looked at it from the Product-Line Context, as is our habit, there was more work to do. The changes required some manual configuration, which would be a problem in the lab. The changes added additional hardware to the harness that the system health check didn't monitor, which would also be a problem in the lab. Until that work was done, we couldn't run set up and run the tests in "hands-off" mode in the lab.

I summarized all this in an email, and set up a meeting to discuss it. The meeting, which I will describe in a future post, helped me figure out ways to balance the organizational need of the business for both Project Context and Product-Line Context automation.

No comments:

 
Creative Commons License
Context Driven Automation is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.