The title question might seem a very straightforward one. “Who performs testing?” Testers, of course! It’s in the name! That answer would be a very short blog, and also not very interesting.
In today’s post, we’ll argue that software testing is no longer the responsibility of a single person or team and that instead of leading to chaos, it can lead to innovation.
Who performs software testing? It depends on what “performs” means.
Think of manual, scripted, non-exploratory tests. Who performs those? At least one person defines the steps of the tests based on the software requirements (e.g., a QA analyst). Then, people work through the steps and execute them in order.
For this post, we’ll discuss the roles who both create and execute software tests. Under this definition, both the QA analyst and the testers perform tests. So does the developer writing unit tests or other types of coded UI tests.
With that out of the way, we’re going to cover some of the main types of software testing in use today, explaining who performs them.
Which role is responsible for unit testing?
Let’s start with the most elemental type of testing: unit testing.
Developers write unit tests.
Software developers perform unit testing. Ideally, the same developer who writes the production code will create the unit test (this includes when the test is written before the code, such as in TDD).
Some tech leaders or managers will argue you shouldn’t let someone test an app they created themselves. But unit tests are different. Developers write unit tests to validate that a small piece of code does what they think it does. It’s a confirmation that their code does what they intend it to do.
It’s also much more efficient when it comes to software testing costs to have the developers who write and understand the code create the tests that validate their function. Splitting these tasks across developers introduces switching costs that suck time away from innovation.
Unit tests help developers validate assumptions about their code.
Having a comprehensive suite of unit tests covering a considerable part of the codebase gives developers confidence. They can change the code without fear, refactoring when necessary, knowing there’s a “safety net” to catch defects if they break something.
Unit tests also benefit end-users, building quality into the code from the ground up.
Who performs user-acceptance testing?
It’s right there in the question—the user performs this kind of testing, right?
Well, yes and no. Fundamentally, acceptance testing means verifying if an application works for the user. As such, it’s one of the final types of testing performed on software before it goes live. If the program passes the test, it’s accepted.
In teams following agile methodologies, acceptance tests might occur at the end of each sprint. However, engaging end-users to do testing on every sprint is a costly proposition.
So, who performs acceptance testing? Most often, teams will have a stakeholder or some other person from the business acting as a proxy for the end-user, having the final say on whether the app (or a given feature) is ready to be released.
Who Does UI Testing?
Last but not least, we cover another critical type of testing: UI testing.
UI testing, as its name makes clear, is a form of testing executed through the application’s user interface. It’s a form of black-box testing since the test cases don’t consider the application’s internal structure. UI testing, in short, verifies whether your application correctly handles actions performed via mouse, keyboard, and other input devices. UI testing also validates the visual components of the application appear and function as expected.
Who performs UI testing? Quite a few different people and roles participate:
- Developers. Most software developers working with a GUI-based application perform some kind of UI testing, even if it’s in a very informal (exploratory) manner.
- QA Analysts. Companies who haven’t embraced test automation likely have somebody write step-by-step scripts for manual UI tests.
- Manual testers. If you have people writing test plans, you also have people executing them.
- Developers. Many organizations have shifted more of the UI testing responsibility to developers, whether through coded or codeless automated UI tests.
- Automation Engineers. They often create automated UI tests through a codeless test automation tool.
Who performs testing in 2020? Everyone.
The software industry evolves at an amazingly fast pace, and so does the software testing world. The list of types of testing seems to increase with every passing year. So does the number of automated testing tools.
What also keeps changing are the roles responsible for each task in the software development process. Software lifecycle methodologies like DevOps blur roles and responsibilities that were once very clearly defined.
Modern software development processes do best when releases are frequent and iterative. Innovation arises from fast feedback that challenges historically slow testing processes.
The software testing field needs to keep pace with these evolving and adapting development methodologies and processes. Faster test creation and reduced maintenance overhead will free up time and improve agility.
Software organizations aiming to remain competitive also need to remove friction between tools and processes—and leverage tools that empower collaboration between the multiple types of testers involved in software.
