Hi folks, As a backend team working with microservices, our team has decided to take an E2E automation approach for the project which we are working currently. Previously we had semi-automated test suites which deals with test scripts that requires human intervention to execute them. With the current project I’m thinking to propose my team to use BDD framework with Cucumber for our automated test suites. This is a first of a kind for the team (including me) to have this approach in place. Is there an effective way as how I can demo/explain this to my team to persuade them? What strategy I need to make use of? Looking to hear your thoughts on it!
You are kind of there. By identifying the problem “tests require user intervention” So show how the new tooling and approach will solve that problem. There is a lot of missing detail though. Is there already a plan underway to rewrite all of the existing tests? Does switching to this tool and method require all the tests to be rewritten? are you planning to retain the current tests and continue new tests using this new tool and technique?
At any rate, the most effective way that I have found is to Show and not to Tell. So you might consider taking one of the tests that gets called out as a problem and refactoring it in this new method. When people complain about test automation, they always have a specific example. “This test takes over an hour and fails 40% of the time for no reason!” create that test in your framework using your method. illustrate how much effort is involved and the resulting comparison that addresses these concerns. Why is it faster? Why is it easier? Why is it more effective?
Its an effective means of introduction and especially so if you can get the development engineers excited about it. They will lend a strong voice of confidence in convincing others.
I am curious how well you are familiar with what BDD is, which are its benefits and downsides. It should be clearer in proposing something you trust would be useful, and worth the extra resources spent.
Check it’s founder’s thoughts when introducing it:
I’ve worked in several places, and teams and I’ve never seen BDD used or proposed by software developers or architects. It’s a thing that some GUI automation engineers like to enforce to facilitate some things for them - reports, reuse, or forcing Business Analysts to write use cases in Gherkin that trigger code scripts mapped to those phrases.
I understand this as a need to:
reduce dependency on the executors’ platform/device/pc/tools; make it scalable and installable anywhere;
configure command line execution and adapt the code with several configurations, fixtures, environment variables, etc…
integrate in an app that does the orchestration of pipelines(git, bamboo, aws, azure, etc)
Thanks @msh for your response. I get your tone here. We are pretty much starting from scratch on the automation front and as a team we have planned to implement E2E tests meaning all the test cases will be fresh start and new ofcourse. I second your thoughts around to Show and not to Tell which I think would be a good start to kick-off the discussion with.
Thanks for your response @ipstefan. I agree your view on the BDD approach, its quite useful if its being used in front-end applications. But to begin with a backend system its bit challenging to think of an approach that automates end-to-end. Let’s see what questions I’m left with to take it from there on, after having this discussed with the team.
You’ve already gotten lots of great advice. Influencing your team as an individual is a big challenge. In your situation, I would look for someone else on the team who also thinks that BDD would be a good approach for the team. Also, if your team does retrospectives, identify the biggest pain points for the team - are they things BDD will help with?
Then propose to the team that the two of you do some research into BDD and you can then show the team what benefits you think it will provide, what problems it will solve, and good practices to get started. There’s a lot of information out there. Take time to learn, maybe even get some training, so your team can do it effectively.
I HIGHLY recommend the Discovery and Formulation books from Gaspar Nagy and Seb Rose. They are tool-agnostic, they’re quick reads, and they give a great path to get into BDD.
So, in summary, do you want to persuade your team to use something that you have no clue would be suitable for the project and you have no idea what advantages it gives, what are the downsides and what would be the cost of implementing it?
BDD is not objectively “good” everywhere. You shouldn’t just start from the assumption that it will work and it won’t waste your team’s time.
I’ve audited projects where BDD was just a waste of resources. In others, the cost of implementation and maintenance was visibly higher than profits for the team.
So my answer to your question would be: don’t do it.
First, you should educate yourself on the subject and prepare a thesis, PoC and a presentation about your findings. Then, you can present it to your team, and you’ll make an educated decision.
I’m going to second @pwicherski advice which i think is 100% on the money.
BDD has existed in nearly every company I’ve worked for. However it wasnt necisarilly used in every teams auto tests.
Also I generally find it either gets suggested by contracters who say it will solve the worlds problems and then leave a half baked mess that never gets maintained by the team OR its suggested by non tech team members like PO’s, BA’s, Scrum masters etc because they read a blog post about how it will solve all the teams problems.
I personally think it can be super useful IN CERTAIN USECASES. I actively chose to implement it at my last workplace when designing the autotest framework. But its not a magic rock that you can rub on anything and it makes everything better. More often not between the team members/project/systems etc it tends to be more of an cost than a benefit.
For example the team I most recently joined had already implemented (at the suggestion of some contractors). However the steps were just like…
WHEN I can scroll “pixels” pixels “direction” on “name” by “elementMatcher”
AND I can tap “name” by “elementMatcher” with options “checkVisibility”
AND I type “text” into “elementId” with options “clearText,tapReturn”
AND I can scroll to dropdown “name” by “elementMatcher” and select “value”
THEN I can see element “name” by “elementMatcher”
And I can see element “name” by “elementMatcher”
AND I cannot see element “name” by “elementMatcher”
etc etc etc …
This meant 1x Scenario would ended up being like 20x lines long.
They had lots of issues with getting the tests to run successfully because you might have 10x scenarios all testing the same user flow just selecting different values and because of the way they were set up you had to tweak the values/testIDs in every scenarios steps individually. Which obviously went wrong for a number of reasons.
My first comment to them was: Why are you using BDD in this project specifically? What problem was it intending to solve?
Because the way it had been implemented they were not gaining any benefits from it and if anything it was making it harder than if they had just done E2E tests without BDD as an additional layer of complexity.
Thier answer was shrug the contractors recommended it and they set up the test framework, so it’s what we have
