Part 3: Tool Selection
Timothy and his team first understand the problem, their goals and what they would like to achieve. After they decide that they would like to work on end-to-end UI tests, they start thinking about what would be a right tool for them.
They start by asking many questions.
Some questions they ask:
What kind of tests do we want to automate?
- Would it be only end-to-end UI tests or some other kinds of tests too?
Are people with coding skills going to be involved?
If yes, then they could prefer a tool where they need to write code. It would give them a lot of flexibility.
If people with coding skills are not going to be involved in the project, then they could prefer a low-code tool for automation.
Are product or business folks going to be involved in this too?
If yes, then they could use plain English tests (Gherkin format) for better collaboration with everyone on the team.
If the product or business folks are not going to be involved, they do not need to worry about using plain English tests.
What platforms or browsers do we need to run the tests on?
- Would we need to run the tests only on a type of browser? Or would we need the tool that provides ability to run tests on Android, iOS apps, different browsers, etc.?
What's our budget for the tool?
- Do we have the budget to buy or subscribe to a paid tool? Or would we prefer an open-source tool?
How is the support for the tool?
If it's a paid tool, how fast would their support respond to our queries? What would the charges and SLA be?
If it's an open-source tool, how strong is the community support? Are there forums where we can find answers to issues that we may have?
What Language do we need to use?
Would we like to use the same language as our developer code base so that the team members can collaborate on tests effectively? Or do we want to use something else?
If it's a tool that needs coding, does it support the language that we would like to write the tests in?
Where do we write the test scripts?
- Do we want to use a separate repository to write the test scripts or would it need to be in the application codebase? Can that be supported?
Where are we going to run these tests and how often?
- Can we run these tests on the CI tool that we use to build the application codebase? Or would it need a very different solution?
Who checks the test reports? Who would debug the test failure? Who would be involved in maintaining the test suite?
...
These are some of the questions that Timothy and his team consider. Based on the answers to these questions, they decide that WebdriverIO is the tool that they would like to go ahead with. They would also use Cucumber to collaborate with other team members and would write the code in Typescript.
Top reasons for their selections:
Open source
Supporting tests on Android, iOS and Web apps
Code with Typescript (since all their service codebase is written in Typescript)
Cucumber (since they want to collaborate with their product teams)
Good community support