It’s great that you are trying to find better ways to do testing. Those are very good questions. Don’t be afraid to ask them even if someone else has already asked them before. Technology changes overtime, and you will get different answers each time, as some solutions go out of date, or better solutions emerge.
Let me answer your questions individually.
1. How can automation make you more efficient and cover more areas?
When it comes to functional testing, you can only be testing two things:
Existing stable features (Regression testing), or
New unstable features (Exploratory testing).
In regression testing, you want to find out - is the feature working correctly?
In exploratory testing, you want to find out - what do I need to test, and add to the test plan?
To cover more ground, you should automate regression testing, and spend more time yourself doing exploratory testing.
But if you are doing manual testing, you likely are spending up to 80% of your time testing existing features - running through the same user flows, the same actions, the same button clicks - again and again. These tests should be automated to save you time, so that you can do more exploratory testing, and cover more ground.
With good tools and good tools (and good governance - a separate topic altogether), you can make automated testing work for you, which I will get to next.
2. What tools can you use?
So there are a few kinds of tools, for different needs and different levels of expertise, and it is good that you have already explored a few commonly used ones, like Selenium IDE.
There are two types of test scripting tools:
Macro-recording tools, e.g. Selenium IDE, Ghost Inspector
Test scripting tools, e.g.: Selenium WebDriver, webdriver.io, CodeceptJS, UI-licious (https://uilicious.com) (Disclaimer: I’m the creator of this),
There are many more tools available, but I’ll just name the popular and - IMHO - the good ones.
Macro-recording tools are a good place to start, because it doesn’t require you to code, anyone can use it.
Simply hit the record button, perform some actions, and hit stop when you are done, and a test script will be generated for you.
But as you have noticed, there aren’t the most reliable tools because they tend to pick up the wrong identifiers for the elements on the webpage you are trying to test. Moreover, since the test script is wired to the UI code, if the UI changes - because of business decisions, or if your programmer decides to do some spring cleaning and change the identifiers - your tests breaks. This makes it pointless to automate tests for evolving products or in new teams with slacker engineering-testing governance.
Ghost Inspector is a popular paid tool because it has friendly user interface, and offers to run your tests on a cloud at a massive parallel scale (it means you can run a ton of tests at the same time, and you will start to need this when you have 200-300 automated tests).
Test scripting tools:
Test scripting tools offer you a few great benefits over macro-recording tools:
Precision: They are a lot more precise. Rather than worry about a macro-recoding tool picking up the wrong identifiers for the element you are trying to test, you are set the identifiers yourself.
Flexibility: Sometimes you just really need a bit of coding to get certain things done. For example, setting the check-in date you enter in a hotel reservation form to be always 3 days from the current date.
To have a lean and productive (=happy) engineering team, test automation is the way to go, as it is far more powerful and efficient.
The good news is, you already know HTML and CSS!
Now, more about the test scripting tools themselves!
- Selenium WebDriver is the mother of all test scripting tools - but it’s in Java, and has a high learning curve. It offers a lot of functionality, and it’s useful if you need custom scripts for fine-grained control over the testing.
If you are just starting out, I’d highly recommend CodeceptJS, and then graduated to WebDriver.io when you need to implement custom commands.
Now, CodeceptJS is great, but I ran into some limitations using it for in my previous work. It requires you to have a very experienced and disciplined front-end engineer to write your UI code in a certain way for CodeceptJS to work its magic. For example, for I.fillField(“Username”, “James”) to work, the label must be associated with the text input field using the “for” attribute to match the “id” attribute of the input field. If you use placeholders instead of labels for your input fields, you would need to use IDs, CSS class selectors, or XPATHs to identify the field to test instead. This means that your tests are dependent on your UI code, making it difficult to keep these tests up to date when you have an evolving product with rapidly changing UI. (Another problem is that it’s not very smart at handling UI rendered progressively on the client-side, using new front-end frameworks like Angular, React, VueJs, but I won’t go into detail as this is a fairly technical topic.)
Hence, I’ve created my own testing tool UI-licious for the busy front-end programmers who don’t have the luxury to keep their UI code and test scripts sane and in-sync.
Disclaimer again, I’m the creator of UI-licious, and I’m working full-time with a team of dedicated engineers on this, which is why it is a paid product.
Writing a login test in UI-licious looks like this:
I won’t go into detail into how it works under the hood (it’s not some secret sauce, it’s just really long and technical). But one great thing about UI-licious is that this test doesn’t require you to have a UI written with the perfect code, it just need to have a UI that renders good enough for a human user (or tester) to use.
There’s more great things about UI-licious, and there’s a 30-day trial if you are interested to try.
So I hope this helps you, James. All the best!
And if you want to have a further discussion on web testing, I’d be happy to help you at firstname.lastname@example.org.
CEO & Co-founder, UI-licious
Follow me on twitter at @taishiling