This is a quick start point guide for anyone who wants to build a simple, efficient and easy to use test automation infrastructure. If you are a QA, who has a good amount of personal automated test cases, a small company or just a department lead who is thinking to start automating testing, this is a good place to start.
What are advantages of building a simple test automation infrastructure?
First of all, it’s availability. With this small testing infrastructure, you can offer automation services for a fair amount of people. I am talking about 20+ constant users who are very active. If you dedicate a person for Jenkins support this number can be increased to 50 or even more. Secondly, as soon as you set up, it requires almost no effort to add and maintain test cases, just copy your Jenkins job, make a few changes here and there and you have a new test case in your CI. And lastly, stability and feedback. Its centralized structure allows you to see and control everything on Jenkins. You don’t need to search for result anywhere, reports, failures, screenshots are all on CI server. All in all, if you have more than 3 people working on test automation or maintenance it would be your interest to try and use something similar.
How do I start? What tools should I use?
First of all, you need to decide what tools will you use. These are the options.
- Continues integration server – Jenkins, Hudson, Bamboo
- Selenium WebDriver – Selenium
- Physical Machines or VM – You can find it on the internet. Or use one/two physical machines at the start.
- Source Code Management Repository – Depends what you use, anything is good, i.e BitBucket, Github, etc.
- Build automation and dependency management system – Maven, Ant, Gradle
- Testing Framework – TestNG, JUnit
- You never want the user to run automation process or test case on their PC. In addition, you should avoid running test cases on your own PC as well. Th process should be isolated and controlled. For that reason continues integration server, like Jenkins, should be used. By using CI you or your user will be able to trigger jobs, see the status, job list, reports and much, much more.
- In order to start the test case using Jenkins job, you’ll need to check out your code. Jenkins will need a repository to access and compile the code. This is where Git/GitHub/RTC comes in.
- As soon as the build is initiated and compiled by CI (ex. Jenkins) it will need to download all dependencies and set up a build. For that, you’ll need to use Maven & Ant or Gradle.
- As soon as you have everything set up your framework will need to start the test case. For that, you’ll need to use one of the testing frameworks like JUnit or TestNG ( if Java is being used). It will kick off your test case, collect information and build a report.
- Your test case will be using Selenium WebDriver. Selenium framework should be using PageObject and PageFactory patterns. If you want to use an external data source for your test case, you’ll have to use data provider, which is basically a 2D array.
- So your test case is ready to start. Now Jenkins should use one of the available slaves to launch the test. It depends on what are you using, VM or Physical PC.
This is basically a high-level process of your test automation infrastructure and how it is supposed to work. As soon as your test case ends, testing framework will generate an HTML report and provide an answer to the outcome to Jenkins. Jenkins will display a status of the outcome, console output and report (if you set up to get the report). Also, you might be able to access the screenshots of your test case form your slave machine through the Jenkins if you have the right set up.
Building this kind of test automation infrastructure might take days or even weeks, it’s not an overnight process. I could also write a separate blog for each step and tool since each and every one of them requires good understanding in order to configure, however, this is just a high-level model.
In the next post, I’ll dive a little deeper into the 3rd, 4th and most importantly 5th step. I’ll explain how a basic Selenium testing framework should look like.