Software is designed for humans: it should be tested by humans
In this two part series, we explore the two sides of testing: automated and manual. In this article, we examine why manual testing should be done. To read the other side of the argument, go here.
In the sprint to keep a competitive edge during digital transformation, organizations are optimizing and updating how they build and deploy software, trying to create a seamless continuous integration/continuous delivery (CI/CD) structure. Leveraging tech like AI, machine learning and automation is certainly helping to make this process as efficient as possible. But optimizing speed must be carefully balanced with maintaining — and improving — quality.
Where and how does testing fit into accelerating software development pipelines?
Shift-left testing has gone from new concept, to recognized buzzword, to reality for many digitally evolving organizations. Instead of running QA after code is developed, this testing is now taking place earlier and earlier in the software development life cycle (SDLC). This is done in part with the help of the developers who are actually responsible for building the code.
Testing earlier in the SDLC has the potential to slow down development, which runs against the priority of developers building and shipping code as quickly as they can. But this slowdown has been worth it for many brands, leading to a reduced number of bugs released to end users and cost savings involved for fixing bugs later in development or once deployed. Essentially, many organizations are on board with compromising a bit of speed for an overall better user experience.
But should they have to?
Collaboration and real-time reviews
At the core of shift-left testing is the notion that every member of a team is working together in the name of improved quality, but that shouldn’t mean that release velocity is sacrificed to a great degree in the process.
Pair programming — where two developers work together to create code— is a great example of how important collaboration and real-time reviews can be used to improve code quality at the outset. With pair programming, one developer writes the code and one reviews it in real time so as to make the process as efficient and the code as clean as possible early on.
This real-time review process goes against the grain of traditional automation, but is nonetheless an important tool in shifting testing and quality processes left. Real-time review and insprint testing methods like pair programming are useful steps to take while test automation matures.
They also offer benefits that test automation cannot because only human testers can provide the dynamic and unbiased validation and verification of software that machines are simply not yet capable of providing. Automation can tell you if the intended result was achieved, for example, but cannot tell you if the experience was intuitive, easy to use or inclusive of all potential end users.
The human element
Automated software testing does all it needs to do to tell developers and QA teams if software is working or not working. But in the wild, where that software is used and sees its value recognized, it isn’t so simple.
When software is only tested in a lab environment, it doesn’t encounter all these other variables. Automated testing simply does not cover the diversity involved in real user experience by the billions of humans accessing applications every day, around the world.
For this reason, organizations committed to providing the highest quality of user experience and accessibility for their users and customers will keep humans involved in software testing.
Offsetting with automated testing
Developers are an invaluable resource to organizations. IT leaders naturally want the majority of developer time to be spent focused on developing applications. Yes, at some organizations with less mature QA setups they do need to spend some time on quality and testing, but ideally, as little time as possible should be spent away from their main priority of developing exceptional software.
Shifting testing left has pulled developers further into the mix of testing responsibility, however. This can reduce developer productivity, and as we know, reduce release cycle speed. But automated testing capabilities can actively offset these areas of compromise.
All in the name of user experience
The benefits of automated testing practices can’t be understated. Automated tools pick up on issues that humans sometimes miss, and they do it in a way that is agile and efficient. But as long as the end product is being used by people, it is people who also need to be involved in some aspect of the testing.
Adding this human element into the mix alongside the efficiency of automated testing is the best way to make sure an application is ready and accessible for any prospective user.
The post Software is designed for humans: it should be tested by humans appeared first on SD Times.
Tech Developers
No comments