Getting Your Team Invested in Cucumber
As a general rule, test automation is limited to either test engineers or developers. Many times, there is a disconnect among teams on what is being tested. If your role on the team doesn’t involve creating or monitoring tests on a regular basis, then you may never really know what is covered in a test beyond what testers tell you. These kind of silos can be unhealthy, especially in an agile setting where collaboration is crucial. As a tester, have you ever heard someone from your project team state they didn’t know what was actually being tested for a release? Ouch.
There are steps you can take to increase transparency and Cucumber can help with that. If you don’t know what Cucumber is then check out the project’s site. There are also great resources available for learning more about Behavior Driven Development in general. But here are a few things you can do that will help get the rest of your team onboard.
Have Clear and Concise Feature/Scenario Titles
Ideally, your feature files should be written first – before the feature itself is even developed. Business requirements are defined in these files so they should be written in a way that is easy to understand. The idea is someone should be able to read the title of a feature and the titles of each scenario and know what is going on with the tests.
But teams don’t always have the luxury of writing these tests before development. A lot of times engineers play catch up and find themselves introducing Cucumber well after a good portion of the application is already developed. That shouldn’t change how tests are structured, though. It’s important that teams not let the pressure of catching up on the automation backlog decrease the desire to write good tests. In the long run, having well-defined titles will help support your effort in getting other members of your team onboard with using Cucumber. It’s such a simple thought, but having confusing titles in your features or scenarios only complicates things.
Avoid Long Scenarios
There’s quite a bit of discussion on how to approach writing Cucumber scenarios. The Cucumber team even posted a podcast episode on popular anti-patterns. Long scenarios in your features will scare away anyone outside of QA. No one wants to read through each and every step just to get an idea of what is going on. This problem is only exacerbated further if features and scenario titles are poorly written. If a scenario contains a lot of steps (click this button, fill in that field, assert this text) then it might be time to consolidate them or try a different approach.
Cucumber makes it easy to call steps from other step files and create predefined steps for quicker test creation. But this ability also makes it easier to simply write tests without considering how to structure any of them. Before you know it, you could have a long list of steps that say “click this button” and “wait for this div to display” and never really understand what is going on in the scenario. That deviates from the core purpose of Cucumber – readable, accessible tests.
Sometimes long scenarios can’t be avoided, but don’t let that be a rule of thumb for your tests. Remember that these tests should also be accessible for others.
Be Wise With Test Data and Finding Elements
Failures involving bad data and/or hidden elements are typical with any interface test. They’re frustrating and decrease the value of a testing suite. From the outside, the suite looks unreliable. It limits a team’s ability for proactive testing if they are constantly in maintenance mode.
This frustration can be alleviated by considering how a test and any of its relevant data should be created. For example, each scenario should be independent of one another. No scenario should rely on another one. Build tests that are more efficient in how they find elements and handle obsolete elements. There are better ways to manage locator errors than sticking a few extra sleeps in your step definitions. And creating new references for elements will help alleviate any stale element exceptions. Many frameworks have built-in, configurable options for handling such situations. If you use something like Watir-Webdriver or Protractor with Cucumber, take the time to learn what they have available to make tests smarter about interacting with the DOM. This will help keep your Cucumber tests passing and show that they are trustworthy.
There is nothing better than hearing a project manager say “I’m glad our tests caught that” after a critical bug was exposed by a well-written Cucumber test.
Share Reports and Improvements With the Team
Cucumber provides different reporting outputs depending on your needs. Share those with the team. The HTML report provides a simple view into what tests passed, skipped, or failed. If someone wants to see what’s going on, sharing a report is a good place to start.
Did you create a custom Cucumber formatter that provides an enhanced view of test results? Did you refactor some old features and make them more efficient? If you make any improvements to your test architecture, let your team know about it! This will keep the suite fresh in their minds and show them that these tests keep providing real value to the project.
These are just a few steps towards getting your project’s entire team onboard with using Cucumber. Clear, well-written features and scenarios and consistently passing tests show the team that the suite is trustworthy and valuable. And sharing the generated reports with the team only aids in making the whole ecosystem of Cucumber tests more familiar.
What if my team doesn’t care either way?
Well, they should. Test automation helps find critical bugs earlier which decreases overall project costs and ensures a stable product. Cucumber can make your tests more accessible and instill some confidence in test coverage.
If teams are somewhat isolated then it can be difficult getting buy-in from others. It’s a process that could take some time. But if given the chance and platform, the Cucumber framework can get your entire team collaborating on business requirements and what needs to be tested. New developers can learn about the application by running these tests alongside their own work. QA managers can show reports on test coverage and success rates. Manual testers can gain a better understanding of what should be tested.
There are certainly aspects of writing Cucumber tests that are limited to test engineers, but it’s more than “just writing tests”. It’s defining how an application should function, building living documentation, and creating training materials around that. Everyone on the project should contribute to that effort. Taking those initial steps towards making tests more accessible will help with that and that’s where Cucumber shines.
How did you get your team on board with writing Cucumber tests? Did you get any pushback? Let us know!