Hello Everyone, 

It is good to make your product better at any moment. At Bitbar we usually have a quality season which exactly means the whole development team is busy. Neither sunbathing, nor partying, but enhancing Automation and development process from the inside. I’m Jakub Koziol, QA Lead of Bitbar Testing and I want to share briefly our experiences with BDD.

As we’re all involved in test automation we all know that it’s not a piece of cake. Sometimes just simple innovation can make the whole testing world better. Not every change will be a milestone, but from time to time even the most stiff-necked tester has a feeling that there is a need for revision.

When Bitbar Testing UI 2.0 was held up we stood over to build, possibly the best functional test automation. We’ve chosen, of course, Selenium WebDriver in Python which starts automatically from Jenkins CI. It was a great opportunity to question ourselves what kind of software development process fits us literally enough to make it an everyday reality.

After several discussions, our R&D team decided to go with Behavior-Driven Development (BDD). This technique is not only good for focusing on user behavior but also requires everyone’s commitment to creating .feature files. From words to deeds we had to follow Cucumber and implement Gherkin language to our automation – a common language that will be essentially easy to express user behavior for non-technical company branches. From the very beginning we felt that this is it – finally, we’ve found a complete solution – living documentation of application. At that moment there were no BDD minors.

Unfortunately the more we got into it, the more complicated it became. The idea to move smoothly from step definition to code was great, but that’s just about it. The main problem we had to confront is that our IDE doesn’t support mapping steps to definitions. Also it turned out quickly that our test code became complicated as our application is, which seriously means that some places in the testing project started to be a mess. There’s no denying that BDD gives the advantage of proper vision for handling test cases connected with a real user. After all, our testing team had the belief that it’s the best way to cover more advanced scenarios. Nowadays there’s no unnecessary extra baggage in our automation. But there is still a place for step definitions in language understandable to everyone. With the help of BE team, we have refactored all existing automated tests to a unit test pattern. So now writing new suites is much easier and quicker than ever before.

In our team we’re strongly focused on going forward. Our wish is to be agile with no quality losses anyway. That’s why in every summer we spend most of our time on details that are not always visible at the first sight but the majority is to have fully comprehensive solutions. And this summer we’re going to leave virtualisation for dockerisation. It’ll give us a chance to start running the applications in a dedicated container with no need of hardware emulation. With Docker we can build environments without virtualisation. We’re sure that Docker will be a great support in raising the efficiency of hardware and above all – human resources. We’re still in the middle of work, so please keep fingers crossed 😉

Regarding the next release v2.43, it’s been planned to be delivered in the middle of August. We can’t wait to show you new features of Bitbar Testing, but for now let’s chillax for a moment and enjoy summer weather!

See you soon!