I learned to build a UI automation suite through a lot of trial and error. This article would be the guide of how to teach yourself to design a suite from the ground up: resources for learning specific skills, reasons for selecting languages (Python or Ruby are lightweight choices and easier to learn, for example), reasons for selecting frameworks (you might not want a BDD framework for certain situations, while for others it’s good), and what skills to learn first.
How Most Testers Learn to Build Test Automation
Like most testers I speak with, I learned to build my first test automation suite through trial and error. My choices for language and tooling were directly related to the strengths of the development team, as I was learning programming and test automation skills simultaneously.
Experimentation was really critical as I worked my way through books and hundreds of stackoverflow posts, learning the nuances of test automation development. Over my time of developing automation frameworks on my own for three different companies, as well as performing maintenance and writing tests for my current company, there are some key pillars that I have leaned on each time I do this work from the beginning.
How did I approach building test automation frameworks from the ground up with no experience and no training? I will share with you the strategies that have worked successfully every time I have built a framework. They are the strategies that I rely on today, and they have been proven by other professionals in the test automation space as well. I will give an overview of necessary considerations for testers who are choosing a language for their test automation, and elaborate on what frameworks deliver based on the kinds of testing that needs to be completed. Finally, I will breakdown the skills that testers need to learn in the order that they should be learned, so testers who are being asked to learn automation can learn it successfully.
for QA and Development Teams
Choosing a Programming Language
There are many different programming languages used to build software, and every language has its own strengths and weaknesses. If you’ve programmed before, you likely have a sense about your preferred language and what it can do. If you are new to programming, you may feel very when looking at all of the potential offerings for test automation.
The first thing that I consider when choosing a programming language to build an automated test suite is the expertise of the developers on my team. For instance, when I was at my first full-automation job, the developers all worked in Python. Because I had started to learn Python online and I was in a Python shop, I selected a Python tool to do browser UI tests. Choosing a language that the development team was familiar with gave me 15 instant tutors who could help me work through some advanced issues in my programs. Choose a language for your test framework that matches the languages that are used for your company product. While you might not personally be as comfortable, you will be able to get programming knowledge and expertise from your colleagues.
Also, when choosing a programming language, consider the jobs that you need the test suite to do, and the documentation and support that are available. Popular browser-testing languages include Ruby, Python, Java, and Javascript, all most typically used with the Selenium-Webdriver API. Each language has at least one (and generally more) domain specific language (DSL) for BDD-style development as well. (The DSL is what makes three ‘given, when, then’ test syntax readable by the computer.) Popular programming languages for penetration/security, load, and other testing depend on the jobs that one needs to accomplish. While some tools have a GUI interface, many can be extended or customized by learning the programming language in which they are written.
Choosing a Framework
Choosing a framework depends entirely on what you are trying to automate. Initially, I learned Ruby/Cucumber/rspec because I was learning how to build Selenium tests in my first job. When I moved to my first job as lone QA/SDET, I chose a python framework because I worked in a 100% Python shop. I used Behave, a Python BDD framework, because it was well maintained at the time, and product and UX teams were helping to write acceptance criteria for user stories.
The main considerations for selecting a framework include the complexity of the job I need to do, the needs of the business, and the maturity level of the tool. Here are some basic questions I ask about potential test tools:
- Is the tool easy to use/easy to learn?
- If commercial, is there is a trial period?
- What kind of customer support/training is provided?
- If open-source, what is the frequency of releases?
- Is the documentation up-to-date and of high quality?
Getting answers to these questions about each tool helps you make an informed choice for your company and team, and can also help with cost/benefit analysis, especially as you look at a multitude of products with different features.
Skills You Need
Once I understood enough about programming languages to start to learn one, and enough about different tools to pick a tool that fit my needs, I began to build my test suite. These are a few things I wish I had known about test suites before I had to build one.
Developer Tools
I learned to program out of necessity, using a wide range of resources. However, there are technical skills that are not programming that are nevertheless necessary when developing and using code:
- What is a good integrated development environment (IDE) to use?
- What versioning system do you use (svn or git)?
- When does your company want to use the tests you build (locally or Part of a CI/CD system)?
Structure and Scalability
Structure the test suite with scalability in mind! In the first two companies where I created test suites, I was learning to program simultaneously. Things like page objects, regular expressions, and DRY (Don’t Repeat Yourself) code practices were new knowledge to me. However, they are really helpful to know, particularly when developing an automated test suite.
Page Object Pattern
Software developers use the page object pattern to keep code clean. The page object pattern is so well applied to UI testing that there is even a Page Object Gem (Ruby library) that has been developed specifically for this purpose. While other languages don’t have their own library, the page object pattern is essential to know in order to build a scalable test suite. It is also easy to learn.
Regular Expressions
Regular expressions are a beast, but a necessary tool for building extensible, flexible, and DRY code. By using regular expressions, you can build code that is less repetitive, because you can use regular expressions to match the parts that you might like to repeat. Regular expressions are not a skill for beginners, but they are a great conversation starter with developers or anyone who has written automated test suites.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
If You Want to Build A Test Suite
If you want to learn the skills to build an automated test suite before you are required to do it, don’t wait! Follow up your reading and learning from this article. Choose a small project, such as automating a google search, to start. Learn the basics of the programming language of your choice by using an online tutorial. When you are comfortable, learn more about the page-object design pattern, and see if you can do some smaller automation projects to build your skills. Finally, commit all of your work to github so you can show prospective employers your new skills.
Resources
- Ruby BDD: https://cucumber.io/
- Python BDD: http://robotframework.org/
- Java BDD: http://jbehave.org/
- Interactive Code Tutorials: https://www.codecademy.com/
This is a guest posting by Jess Ingrassellino. Jess is a software engineer in New York. She has perused interests in music, writing, teaching, technology, art and philosophy. She is the founder of TeachCode.org
Cross-Technology | Cross-Device | Cross-Platform
