BDD Living Documentation using Yard-Cucumber

BDD Framework like Cucumber aims to bridge gap between business and technology. In BDD we describe behavior of software as plain text in .feature file. Cucumber helps us wrap business language around test code so that there is better visibility and tests are not lost in code. Sharing documentation within and across teams is an important aspect and there are currently different solutions available to host and share .feature files. I have used Relish in the past for hosting feature files online. also looks promising for collaboration. I came across a post from Shashikant here about living documentation using Yard-Cucumber and wanted explore more.  Yard-Cucumber is  a free tool which can be used to generate documentation interface to view features, tags etc. It generates HTML files and is a nice interface to search/view features and tags. In his blog post Shashikant shows how to use Yard-Cucumber for a ruby cucumber project. I attempted to use Yard-Cucumber for a cucumber-jvm project and share my experience in this blog post. Here are the steps,

Make sure you have ruby 2.0.0 installed

Go to your project and install bundle if its not installed already.

gem install bundle
bundle init

This will create a Gemfile in your project. Add gems below,
gem "yard-cucumber"
gem "redcarpet"
gem "rake"

Then execute,
bundle install

Now lets create Rakefile and add contents below,

require 'yard' do |t|
t.files = ['src/test/resources/features/**/*.feature', 'src/test/java/**/*.java']

Now Yard-Cucumber is configured successfully and now you should be able to run the tool to generate reports,
bundle exec rake yard

Now you should see doc folder under your project. index.html should be the launching pad. My sample project is hosted on github here and you can take a look at my docs over here (give it a few seconds to load).

Some images from my project are like,



Cultural shift in Software Development for good

I have been working in agile teams for sometime now as a Test engineer. I have been pondering a lot recently about roles of development and test engineers in the context of delivering business value at a nimble speed in a given sprint.

Although I am a test engineer in my team, I consider myself as a development engineer with test focus. When I have free cycles, I develop features, help fix bugs, write unit tests to improve code coverage, review code (pull requests in github). I took conscious efforts to get to that level and gained respect of my fellow developers. I believe in modern software development, to be a good tester, you need to be a decent developer and vice versa. So while I showed interest in contributing development activities, similarly I wanted developers to show interest in testing activities too. I convinced my fellow developers that they should not only write unit tests but should also contribute to functional tests to a certain extent. They cannot depend on one person for writing, maintaining all functional tests. Quality is shared responsibility and everyone should contribute. We are still in the early transformation of this cultural shift of engineers performing hybrid roles, however the more I think about it the more it makes sense.

Think of this scenario, let’s say a developer has some of free cycles in a sprint; can he/she help with current burning issues like,

  • Increase functional test coverage
  • Fix a failing functional test
  • Review build report, make sure test failures are not caused due to code issues
  • Or something else?

Similarly think of this scenario, let’s say a tester has free cycles in a sprint, can he/she help with current burning issues like,

  • Increase code coverage by writing unit tests
  • Fix bugs
  • Or something else?

If other engineers can perform hybrid roles, then current burning tasks no longer need to wait for the special engineer’s attention.  Lets say we have a database developer in a scrum team and he is the only person who knows about database development, issues etc. If the person leaves the company or goes on vacation, then it’s naturally going to slow down team’s progress. This analogy applies to a tester, developer too. The moment we draw stronger lines and define rigid roles, we add dependencies, which eventually thwart faster development.

Thankfully my team is naturally going in the direction where engineers are able to perform each others roles. Communication between quality and development engineer is much better than before. Although as a team we are still working on many areas, this approach has been working really well for us and as result of it we are able to deliver business value at a better speed. I strongly feel that in agile world the line between a quality engineer and a development engineer is getting blur. This notion is not new. Modern companies like Facebook; Google etc. have successfully implemented this approach and are able to release software at a greater speed.  Sure, test engineers are hired to test and development engineers are hired to develop, however they should be able to perform each other’s tasks when its required in order to release faster.  What are your thoughts? What is working for you in your company?