Thoughts from Agile Austin QA SIG Meeting on August 17

I am taking a slight detour from catching up with my spring STP Conference experience.  Once a month a group of testers meet as part of Agile Austin.  The topic was TDD and BDD.  Jill Ott was the presenter and she did a good job introducing the topic.  For some reason I walked out of that meeting completely unsatisfied.

This is my attempt at a personal retrospective.

One comment was made saying that testers really do not get involved in TDD.  I consider myself a tester and when collaborating on building an open-source testing framework, I found TDD necessary,  TDD is an excellent practice to prove that your ruby methods work.  One person did comment saying that testers could certainly add value by reviewing the tests created through TDD.  I agree with that statement.  The conversation did not advance beyond a couple of comments.  I guess I was not satisfied because I wanted more detail on how developers leveraging TDD create better code and increase tester confidence.  After recently learning TDD, I found it extremely valuable as a tester.  I guess I had expected more testers in the room to be developing automation code and that they would have an opinion on whether TDD was easy to do with automation code.

The conversation on BDD seemed to bounce around two themes: requirements and brittleness of automation.  One person gave a couple of great working examples of BDD.  One example where it appeared to work extremely well and a counter example where things did not go well.  I did have to admit that the reason I considered BDD is because to many legacy requirements were in peoples heads.

I guess I was not satisfied because I wanted to talk details with respect to cucumber implementations and the processes surrounding the implementation.  We never got into that level of detail that I desired.

• When in the process do Cucumbers get written?
• Who is responsible for writing them?
• Who is responsible for building the step definitions?
• How well do teams get reuse out of their step definitions?
• How do you avoid cucumbers being scripts and focus on specification?

There were also threads within the conversation about the cost of automation.  Yes automation can be expensive, but I am of the opinion that automation is extremely necessary.  I tend not to pull cost into the game, but rather focus on the value that automation can deliver.  I concede that I probably should factor in cost a bit more, but I do not permit cost to be a deterrent.

So My conclusion as to why I walked away dissatisfied is because  I did not get the value I had hoped out of this meeting.

I am now pondering what could I have done differently to get more value out of this meeting.  There were 20 persons in the room and I knew 3 or 4.  I think if I attend this meeting again, that I should arrive early and meet more of the attendees.

I think I may have to either speak out more or get my questions on the table early.  I was a bit hesitant to chime in, which is unusual for me.  Approximately 4 -5 of the 20 people tended to dominate the conversation.  I ponder how can we facilitate more participation.  I am wondering if I should have submitted in advance of the meetings the questions I was hoping to address.

Perhaps I should follow up with the user group with the questions posed above.

I think I will do that!