Are you thinking about having manual testers writing English-like Gherkin syntax using a tool such as Cucumber or SpecFlow for UI test automation? In this article I will outline the correct way to do it as well as advantages and disadvantages of different approaches.
I’m realizing that in today’s world, simply pushing best practices on large organizations isn’t going to work. So let’s at least talk about the pros and cons of different approaches 👍 (I will refer to all Gherkin style aka BDD collaboration tools as “Cucumber” since that’s the most popular one. But the ideas here are the same across the board)
I will talk strictly about UI test automation since that is what we mostly try to do with these tools. I strongly discourage too much UI test automation, but that’s for a whole other blog post.
Process of involving manual testers in automation
You must have manual testers doing test automation because that’s what your management wants. I get it. You don’t have any option even though you know it’s not wise. Let’s talk about the optimal strategy in that case using a Gherkin style framework.
Here is what the process may look like
Let’s analyze this process.
Manual tester codes Cucumber scenarios
The standard desire is to have the manual testers writing the Cucumber scenarios if a feature file. This implies that the manual tester must have the following training:
- Light IDE training so that they know how to write the feature files, where to put them, how to name them
- Good gherkin syntax training. This is mandatory for anyone doing BDD
- How to use the framework training so that they understand how to run tests, use tags, point to different environments…
- How to use Cucumber features such as tables, Scenario context, Examples, Backgrounds and so on
For Test Automation related overhead aka training, you can have your SMEs do that. Train manual testers in appropriate topics.
For Cucumber related overhead, you probably need to hire a highly skilled consultant to come in and do training. Most organizations don’t have the skill in-house to conduct proper Cucumber training.
At this point, we have a decision to make about…
Who Will Create Step Definitions in the automation?
A. Have the SDET Create Step Definitions
If we go this route, then the SDET is reponsible for creating step definitions. This implies that the SDET will require:
- good gherkin training
- a strategy for how to manage step definitions from all of the manual testers
- training on regex patterns
B. Have Manual Tester Create Step Definitions
If we go the other route then that means that we need to start making manual testers more technical. In which case they need mandatory training in:
- How to use Page Objects or API classes to create step definitions
- How to use an IDE so that they can code
- How to use regex
Do the Page Objects already exist?
While creating the step definitions, we also need to decide whether the Page Objects are already in place for us to use (either for manual testers or the SDETs).
A. If Page Objects don’t already exist
Then the manual testers will need to work with the SDET to create the page objects.
B. If the Page Objects already exist
Then the test is ready for production. The issue that we will run into here is that we need to make sure that our SDETs can support all of the manual testers in the creation of page objects.
Can a few SDETs support several applications and create all of the page objects?
I don’t believe so. But I’m not here to discourage, but simply guide with questions and ideas.
Summary
The main question now is How do we optimize the process to decrease dependency and maintenance costs for the business?
The ideal solution is one that is the easiest to implement. But most importantly, the easiest to maintain!
What is the ideal process of having manual testers involved in test automation with Cucumber?
Hence, what is the ideal process to include manual testers in automation and decrease complexity, dependency, and training on the entire team (trying to remove the orange and green ovals in the diagram)?
Analyzing our diagram we can see that if we push all of the technical stuff onto the SDETs, then we can reduce the amount of training and required from manual testers.
What this approach provides is forcing everyone to learn Cucumber (which is mandatory regardless since we’re using the tool). It also forces the manual testers to learn a bit about using an IDE and how to use the test automation framework.
- Manual testers have less involvement in the technical aspects of automation. Removing mandatory training that will take at least several weeks. Furthermore, this will prevent maintenance nightmares that can arise due to software development inneficiency.
- More burden on the SDETs to keep up with all of the features coming in, the way it should be. Since the SDETs usually have years of development and architecture experience, they should take on the most technical roles.
- Eliminate all the extra training that was necessary for manual testers. This includes writing real code using page objects and trying to manage the code for step definitions. Writing less code for the least technical people is key in all automation endeavors. Until someone is extremely efficient at development, it’s idea to have them avoid doing too much technical work.
- Manual testers still need to learn how to write good Gherkin, mandatory training
- Manual testers still need to learn the Cucumber features to create a scenario, mandatory training
- SDETs need to do their normal job of implementing the framework and page objects and also the step definitions
What is the most optimal approach for getting manual testers involved in test automation?
If you had your choice and were not forced into any solution. What is the ideal way of resolving this problem?
1. Don’t push manual testers into test automation
If we have the option, this is the ideal scenario. The industry is changing and forcing someone into test automation without proper training is a poor business decision.
▶️▶️Test automation is software development.
Sometimes I think the amount of tools in the industry actually makes test automation even harder. If we believe this premise and we don’t push manual testers into writing unit tests for the developers then why are we pushing them into writing UI and API automation?
Use manual testers for:
- UX testing,
- Exploratory testing,
- Product Ownership,
- BAs,
- and collaborators to find edge case scenarios for automated testing.
In many multi-billion dollar organizations I work with, this is not an option because of technical and cultural constraints, so what’s the next best option?
2. Simply don’t use Cucumber
Notice what happens when we remove Cucumber from the equation and how all the green ovals are gone. This means that we just saved that much time and effort learning a new technology. Leaving only the fundamental automation training. Furthermore, every technology comes with maintenance costs. Usually, less tech is better.
Although manual testers do have to learn more coding here. Having a well defined test automation framework that protects against mistakes, with the help of the IDE, actually makes this process easier for manual testers and test automation success. The IDE can guide automation creation. And having a code review process in place can prevent many novice mistakes.
Not requiring extra training for the manual testers and the SDETs on Cucumber specific syntax makes the barrier to entry smaller. Also, this means that we don’t need to maintain extra tools, potentially face regressions, face breaking API changes, and keep up with the documentation. Furthermore, the workload is decreased for the SDET as they no longer have to maintain step definitions and manage the logic involved in keeping that efficient.
Rather, the highly trained, highly paid SDETs can focus on the automation framework and the architecture to ensure that failure is extremely hard. Enabling an easier automation process for the manual testers.
This doesn’t mean that the organization will succeed in the long term with test automation. There will be endless challenges. But if the focus is on removing training, costs, and complexities then this approach is second best.
What if you absolutely must use Cucumber?
3. Use the optimal Cucumber automation process
Use the process as defined above. Let your manual testers write the feature files in highly trained Gherkin syntax. Let your Software Development Engineers in Test do the actual development of all of the technical features. They will face a lot of challenges to keep up with the demand from the manual testers. There are drastically more manual testers producing feature files. So you will need to tackle this challenge.
If you want to read more about different automation patterns and anti-patterns then take a read here
Conclusions
I have realized that in many multi-billion dollar organizations pushing best practices is not always possible. Instead, I am trying to focus on supplying the most optimal solution within the constraints.
Please let me know your thoughts… Have you tried one of these approaches? What was the outcome and what challenges did you face?