I can’t tell how many times I thought “Wish I could just run a script instead of clicking through it for the hundredth time”. Aaaaand that’s basically it. Automation of software testing allows you to mimic user’s behavior and does the boring/time-consuming stuff for you. Log in, check if the title is correct, log out, repeat it 50 times overall, twice after every single modification? No problem.
Which tools should you use?
Any tool you find suitable. It depends on which language you know and whether you’re interested in using commercial tools. Personally, I recommend using Selenium Webdriver, because:
- it’s open-source;
- it has a support of largest browser vendors and language bindings for Java, C#, Ruby, and Python;
- it;s probably the most popular software testing tool.
Additionally, there’s a bunch of frameworks for these languages, such as JUnit, TestNG, JMeter (Java), unittest, test-unit (Ruby), or NUnit (C#). As you can see, there’s plenty to choose from.
The selection of a proper tool is, of course, related to what you need to achieve - if you have to perform a stress test, then you’ll use different tools than in a case of end-to-end testing.
Stress tests and end-to-end tests
Those are two of many different types/levels of automation testing. You can actually differentiate the method, type and the level of software testing you want to perform. The method defines the approach to the project - the most popular ones are:
- white-box testing:
usually used at the low level of testing (for instance in unit testing);
you possess the knowledge of tested environment and know what you should receive as the output for given input;
you can’t check the performance of methods that are not implemented.
- black-box testing:
tests are carried out at users’ level;
You have no knowledge of the system under test;
only expected output is known, but there’s no knowledge how it’s achieved.
When it comes to levels of software testing, I’d like to mention the concept of a testing pyramid. According to this publication it’s safe to say that following the pattern 70/20/10% of unit/integration/UI (end-to-end) tests grants proper test coverage. While it’s good for Google, the values may differ when it comes to small websites/application - we’re not working on Google Search, after all. That being said, I highly recommend following this 70/20/10 pattern.
Finally, testing types. Initially, I wanted to create a list with a variety of tests you can execute at various levels of your project, but I see no point in overloading you with meaningless information. That is why I decided to mention those that matter in the development of the website:
- continuous testing (Continuous Integration)
- it’s based on regularly running tests or sets of tests in order to ensure quality of the project, (usually) after every new deployment;
- the new deployment isn’t a requirement to run tests - they can be scheduled to run every week, day, etc.
-
unit testing
- unit testing allows to check whether the method returns expected output; tests are run against the tested code;
- test coverage is a term describing a percentage of passed tests.
-
functional testing
- this one is similar to unit testing; the difference is you’re testing whether user is capable of executing a number of actions in order to achieve expected output;
- functional tests are run on a ready environment, and they’re usually executed during the integration phase (and later).
-
regression testing
- this type refers to tests that are run after a new upgrade to the used software; if there’s new Windows release, or Firefox/Chrome has an upgrade, then you should run your set of tests to check whether they pass;
- the bigger your customer’s target is, the more setups you should be covering, making your website/application bulletproof.
-
smoke testing
- runs tests against key features of website or application;
- ensures that there are no critical errors that prevent the website/application from working.
Software testing tool, types of testing… what’s next?
Well, that’s basically it. Assuming you already have a programming knowledge, you need to choose your tool for testing and make it work. Basics are quite simple, and there are tons of tutorials on the Internet and Youtube - for instance, you’ll do stuff that requires you to find the element and discover a way to use it in a desired way. Later on you’ll notice that your code has a lot of unnecessary boilerplate and you will work on refactoring it over and over, but that’s another story.
In case you read this article because you wanted to understand what automated testing refers to and you’re interested in using it later in your project, I’m already working on another article covering the topic of pros of automation. Stay tuned!