If you’re a developer, you may not think that software testing has much to do with you, or that you have much to do with software testing.
But thinking this way is selling yourself short. It’s true that traditionally, software testing has been the focus of QA engineers who are dedicated to the role of ensuring that software behaves and performs as required to meet user expectations. As more and more organizations make the shift toward automated testing, however, the skill sets of test engineers are increasingly overlapping with those of developers.
Why? Because in order to take advantage of automated testing, you have to write automated test code. QA engineers don’t typically specialize in coding, but developers do. So, if you’re a developer, it’s likely that you have much to offer to colleagues who are writing automated tests. It’s even possible that you’ll be asked to play a role in writing automated tests. Both types of work offer an opportunity to make yourself more valuable to your organization, especially in the present DevOps-centric age, where collaboration and teamwork are key to delivering software effectively.
All of the above means that if you’re a developer, now is a good time to educate yourself about the basics of software testing (if you have not already), so that you can be most helpful in writing the tests that your organization needs to assure software quality. Toward that end, this article provides a primer on software testing from a developer’s point of view.
To start with the most basic (and obvious), here’s a definition of software testing: Software testing is the process that assures that an application meets user expectations.
That’s a simple way to put it. There is more that could be said about what user expectations mean, and how you measure them. But rather than focusing on that issue, the most important thing to keep in mind is that the end-goal of software testing should be to delight users. If you’re focused on your users, success in other areas will follow.
Software tests fall into many different categories. The most basic is unit testing, with which you’re probably already familiar as a developer, because it’s something that typically happens shortly after code is written.
Other forms of testing, like performance testing, usually occur later in the development cycle, and you may not have much to do with them as a developer. But if it’s your goal to assist in software testing, you should familiarize yourself with them.
Automated testing is a hot topic in the world of software testing and QA today. By allowing organizations to write programs that perform various tests on a software application automatically, rather than requiring human engineers to perform and monitor tests manually, automated testing enables much faster and more scalable tests. (It also tends to save your organization a lot of money.)
Given the priority placed by many DevOps teams today on being able to deliver software continuously, as well as achieving scalability, automated testing has become the goal that many organizations strive for.
This does not mean that every single software test is automated—that’s rarely the case at most companies. Certain tests, such as usability tests involving real, live users, are best performed manually. Overall, however, test automation delivers the best, fastest results in most situations.
To write automated tests, you need two basic things.
The first is an automated testing framework that supports the type of application you want to test. Selenium is a popular general-purpose choice for web applications. If you’re testing for mobile, you’ll be better served by a platform like Appium (which is based on Selenium but designed for mobile testing).
The second thing you need is automated test code. The language in which you write your code will depend on which automated testing framework you use. The major frameworks support most popular languages. Selenium, for example, works with C#, Java, Perl, PHP, and Python.
If you’re a programmer, writing test code itself is relatively simple. It’s basically just scripting, and even the longest automated testing scripts tend to consist of only a few hundred lines of code.
Of course, if you’re a QA engineer with little or no coding experience, writing these kinds of tests could be intimidating. That is why, as a developer, you can offer a great deal of value by assisting with automated test development.
If you’re a developer, you may not have much visibility into how software tests are actually run. After all, your main focus is on writing code, not testing it.
But as most QA engineers can tell you, test execution usually happens on infrastructure that is set up specifically for testing. Servers are provisioned using emulators or simulators that create environments that mimic those in which an application will run in production, and the application is tested inside those environments.
In order to speed up testing, it’s common to use what’s called a test grid, which is essentially a cluster of machines that host tests. Using a test grid, you can run multiple tests at once — or, in other words, run tests in parallel — in order to get results faster.
You can set up test infrastructure on your own on-premises hardware, but when it comes to software testing (like so much else), it’s common these days to take advantage of the cloud. When you use cloud-based test infrastructure, you don’t have to worry about setting up and managing your own servers to support your tests. Plus, cloud-based testing can be handy in situations where you want to run tests on a specific type of physical hardware device (such as a particular mobile phone) but don’t own that device yourself.
Your main job as a developer may be to write code. But because writing code is now an important part of software testing, it’s hard for developers to ignore the work that QA engineers do to test software. By teaching yourself about how software testing works and how you can help your organization make the leap to test automation, you can earn props for yourself, while also making the overall software delivery pipeline flow more smoothly.
Chris Riley (@HoardingInfo) is a technologist who has spent 15 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being an industry analyst, he is a regular author, speaker, and evangelist in the areas of DevOps, BigData, and IT. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.