Do you want your manual testers to transition into full-fledge Gherkin syntax writing testers? This article will teach you all about the cons and benefits of different approaches for testing.
Today’s world requires much more than just the best practices incorporated in the world. Therefore, you need to learn about the advantages and disadvantages of multiple different approaches. (Just a disclaimer: I will be referring to the Gherkin style BDD collaborations as “Cucumber”, as it is one of the most popular ones).
Also, this article only discusses the UI testing as that is our main goal. But I do condemn the usage of too much automation in UI testing, however, that is not the topic today.
Process of incorporating manual testing in automation
All the manual testers might be doing the automation in your firm, because that is what the management wants. We get where you are coming from, even if it isn’t the best to do. Therefore, we shall talk about how you make the best out of the situation.
Manual tester codes Cucumber scenarios
The standard procedure is to use the manual testers to write some Cucumber scenarios in a feature file. This means that the manual tester must be familiar with the following concepts:
- Light IDE Training, this will ensure that you have the skills to write a feature file, and you know how to name them and the general navigation.
- Gherkin Syntax Training, this is a pre-requisite for anyone interested in BDD.
- Framework training, to learn about the general know-how of the framework, such as running tests, tags, identifying different environment, and much more.
- General Cucumber Training to learn about the basic features such as tables, scenario context, background testing, and others.
For, Test Automation overhead (orange ovals), have the SMEs do that.
A few things to note here are, that for the cucumber testing, you need to hire highly skilled consultants to help train your staff. As an example, our team of 7 automation engineers with over 75+ years of automation experience have seen one successful Cucumber implementation.
Who is responsible for defining Step Definitions in the automation process?
A. Have the SDET Create Step Definitions
If you opt for this approach, then SDET will be the one in-charge of curating step definitions. This means that the SDET will need:
- Excellent Gherkin Training.
- A solid strategy for the management of step definition for the manual testers.
- Familiarity with regex patterns.
B. Have Manual Tester Create Step Definitions
This is the second option, however, it requires much more effort from the manual tester’s side. For this step, the manual testers should be a little more technical. That implies that they must know:
- The concept of Page Objects and API classes to curate step definitions.
- IDE navigation.
- Regex concepts.
Do the Page Objects already exist?
While making the step definitions, we need to choose if the Page Objects are already for us to use (for both the manual testers and the SDETs).
A. If Page Objects don’t already exist
Here, both the manual testers and the SDET will need to work together to make the page objects.
B. If the Page Objects already exist
If this is the case then the test is in motion for production. However, the small challenge that we might face here is that we need to ensure that the SDETs are compatible with the manual testers for the production of Page Objects.
Can a few SDETs be compatible with more than one application and make all of the page objects?
Unfortunately, that isn’t the case. But you can always try your luck. I am here to encourage you and help you out with any questions that you might have.
Summary
The most important question here is about the optimization of the process to minimize both the dependency and the maintenance costs of the business.
The most ideal solution will be the easiest to both implement and maintain.
What is the ideal process of having manual testers involved in test automation with Cucumber?
So what exactly is the most optimal process to convert manual testers to automation testing, and minimize complexity and dependency at the same time?
By analyzing the diagram, we can conclude that pushing the technical aspects on the SDETs can decrease the training required and will also put off some weight form the manual testers.
This approach offers the entire staff to learn about Cucumber, which is mandatory as we are working with it. But it also gives the manual testers to study about an IDE and how it works, in the process they will also learn about the automation framework.
- Manual Testers are generally not that much involved in the technical part of automation. Eliminating the core training might take a long time. Moreover, this will save everyone from the maintenance challenges, which can arise because of inefficient software development.
- It put more burden on the SDET spectrum, so that it gets balanced properly. As SDET has a vast experience inboth software architecture and development experience, they should fulfill all the technical roles.
- Remove the need for excessive training, which is mandatory for manual testers. This includes; coding, utilizing the page objects, managing step definition code. Writing as little as possible code for non-technical people is the key for automation projects. Unless and until a team member is a highly skilled developer, it is best to avoid technical work.
- Manual tester will still have to take Gherkin training to code in proper syntax.
- They still need to study about the Cucumber and its features to curate a scenario.
- SDETs still need to perform their actual job, which is to implement frameworks, page objects, and step definitions.
Btw, if you want to see these tips in code, as well as dozens of others, check out the Complete Selenium WebDriver with Java Bootcamp.
What is the most optimal approach for getting manual testers involved in test automation?
If you were given a choice and you were not pushed into the solution. What would be the most ideal way to resolve this issue?
1. Don’t push manual testers into test automation
If you have a choice, then this is the most optimal scenario. The industry is always evolving and to force someone against their will and relevant training is a bad business decision.
At times, it feels as if the abundance of tools in the market makes automation testing even harder. If we do not force a manual tester into writing unit tests for the developers, then why do you force them to write UI and API automation codes?
Manual Testers are for:
- UX testing,
- Exploratory testing,
- Product Ownership,
- BAs,
- And are for collaborations to find mind-blowing testing scenarios.
The big names that I work for do not provide this option. What should be my next best solution?
2. Simply don’t use Cucumber
Have you ever wondered what might happen if we eliminate Cucumber from the equation? This means we are saving up on massive effort and time that was needed to learn the new technology. That means we just require the core automation training. Moreover, nothing comes without maintenance costs, especially in tech. Therefore, the fewer new technologies, the better.
Even though, in this approach, the manual testers will have to study about coding in a little depth. Having a well-understood automation framework will secure the procedure against risks. This also makes the process easier for testers with IDE. The IDE can guide the automation creation and having a code review policy set can help eliminate the notion of risks.
No extra training for the manual testers and SDETs with a specific Cucumber syntax makes the entry point much narrower than before. This also implies that the organization will not require more tools, or face regression, or have to make many API changes, and update the documentation.
Moreover, even the SDETs will feel relief here as they no longer have to worry about step definitions and manage logics.
Instead, they can hire highly qualified and trained SDETs to work on the automation framework and ensure that the architecture is fail-prove. This enables a much friendly automation process for manual testers.
This does not imply that the firm will be able to survive with test automation in the long term. There will be countless challenges but as long as the focus is on eliminating training and minimizing the costs and complexities, then it is the second-best bet.
What if using Cucumber is essential?
3. Use the optimal Cucumber automation process
Use the process part two that we discussed. Encourage the manual testers to write a feature file in Gherkin Syntax. And then enable your Software engineers in test to develop the technical features. This will have several issues with the manual testers, but as they are the ones making more feature files you have to comply with them.
Conclusion
I have seen that going for the best practices in a multi-billion-dollar industry is not possible every time. That is why I am trying to show the most optimal solution, which can be implemented with such constraints.