HomeAboutContactWinging ItHere's what I got...Thursday, December 15, 2011Cucumber Is Not A Qa ToolCucumber Is Not a QA ToolIn my recent travels, and they have been plenty, I have come across some interestingviews about Cucumber.In one conversation someone was looking for "QA people with Cucumber experience." Ithought that was pretty cool, they want some testing folks familiar with a ratherpopular test framework. Then came the second sentence, "I really don't know whatcucumber does, but I know that QA people need to do it." (Yes, this person was arecruiter, if you couldn't tell by now.)Contrast that with conversations with management and leadership types who don'tknow what cucumber is, but as you explain it you can see the words scrolling acrosstheir foreheads, "If we use this, I can lay off half my QA people! Cost savings!!"Now, I can not totally discount both points, there is a little merit of truth in each oneof them. In the first case, a QA group that knows and understands Cucumber can be agreat asset to your product team and the long term quality of your product. Additionally, once Cucumber is in place it will free up some QA departments from doing repetitive manual tests and allow them to focus on more exploratory testing.However, if you consider Cucumber to be only a QA tool, you are missing a good portionof what this and other Acceptance Test Driven Development (ATDD) or Behavior DrivenDevelopment (BDD) frameworks can provide.Note: From this point forward I will use BDD in the discussion. BDD and ATDD are veryclosely related, almost indistinguishable in practice. I learned the phrase BDD first,so I tend to stick with that. And for writing purposes, it is one character shorter,thus promoting my natural laziness.CollaborationThe biggest benefit to employing Cucumber, or any BDD framework, is that it tears down alot of the communication walls to which we have become accustomed. Specifically theGherkin syntax of Given/When/Then helps bring down those walls by writing acceptancecriteria in a plain text format that everybody can agree on.From the business's standpoint, finally being able to communicate to the development andQA teams in a clear manner has to be beyond welcome. Being able to work with multipleteam members and arrive at something for the delivery team that says:Given the customer has an item in their shopping cartWhen the click the checkout buttonThen I will have more money in my bank accountNo more reams of documentation around a simple feature with wire frames, UML diagrams,feature documents, and other items buried in a wiki somewhere that gets ignored. Plaintext is easy, and in my experience the easier something is to use, the better chanceyou have of it getting used.Now from the QA person's standpoint, we have actual acceptance criteria that let us knowif a feature is complete or not. No more vague language that allows room forinterpretation where I can inadvertently add more functionality to a feature becauseit is what I think