What has modern application development evolved into, and how has this impacted software testing? The software development world has embraced new technologies including cloud, AI, mobile, etc. that continue to emerge and expand; new methodologies have evolved focused on speed and teamwork for DevOps and CI/CD, and new ways to include the user (user experience, social network orientation, crowd input), as we move further away from monolithic legacy software. Let’s look deeper at these progressive changes that have helped the programmer and see what they mean for the tester.
New technology promises new benefits for the user, who may only need to see it as a magic box whose innards can remain a mystery. For the developers and testers, they now need to become experts, not only understanding the basics of the new capabilities, but also the intricacies of the hidden wonkiness within. Software architecture will evolve and adapt, and all devices (even ones not yet invented) will need to be supported. Suppose you were testing mobile and had no familiarity with it. Would you realize that device fragmentation is a major concern, with OS and screen sizes variables? Would you know to test screen rotation adjustment? Would you know that a tablet, unlike a phone, lacks voice input and may therefore need to disable on-screen Skype or phone links? These are all things that both the developers and testers need to be aware of, to ensure they are handled correctly. In the case of A.I., the testing mindset needs reorientation, as scenario responses are more probability-based than true or false based.
Conclusion: Testers, like developers, need to increase their knowledge and how they do their job, as the scope of their work increases. While most of this education (such as industry experience and regulation) will take place prior to static (pre-coding) testing, some (such as the specs for a new module) occur simultaneously with static testing. Dynamic (code V&V) testing should be largely unaffected.
New methodologies like the DevOps and Continuous Everything have come from a shift-left push that’s been a blessing for SQA – increased automation means less time performing tests, and more time analyzing results or dreaming up new tests. With closer connections to Dev and Ops, QA also gets more opportunities for recognition and respect given their visible output. More scripting is really only a threat to manual testers who never made the jump to automation. Newer methodologies also tend to provide QA with an earlier presence in the production cycle to discover and express any concerns.
Conclusion: Testers, like developers, need to increase their knowledge and how they do their job, as their work becomes entangled with the work of other departments, as the scope of their work increases. Learning the new methodologies takes place prior to static (pre-coding) testing, although some team building may occur during static testing. Dynamic (code V&V) testing usually improves due to the heavy amount of automation utilization.
While DevOps combines the coders, the testers and the business, one role is still missing – the end user. User experience was not a concern in the past, WYSIWYG applying not just to how the GUI displays. Modern application development has a few ideas on how to be inclusive of this valuable input. User input in the design phase may educate developers and testers alike into what user experience requires. In the test phase, user (possibly a managed crowd) input can help spread test coverage across a wider range (like device fragmentation), supplementing a test team’s scope. As user feedback is scraped for common insights, it has the potential to uncover edge cases or flaws that were outside the test build’s ability to encounter; this item gets added to the tester’s list of “things to look for in future builds or projects”, possibly a reserved string or character that a parser cannot handle that wasn’t caught during alpha testing. Or imagine a search engine or personal assistant that is particularly tone-deaf in response that is only detectable when asking the right question.
Conclusion: Testers supplement their testing by including the work of others. This is just a new tool in the testers’ work belt, or a new information stream, serving to increase testing coverage. However, it also provides valuable input that helps better prepare the testers for future edge cases to include.
As computer languages advance, complex libraries and frameworks of open source code become more commonplace. On the downside, these may run the risk of security vulnerabilities (“Does it write a temp file that may not always get deleted?” and “How public is its output?” and “How do I customize to include the user’s logged-in permission role when they try to issue the command?”). Popular components that already exist (dropdown, date picker, etc.) are likely to NOT be built from scratch, API’s are often NOT built inhouse, and the developer team often has a designated expert on specific public API’s (Windows comes to mind). The in-house expert extends their knowledge through online communities and that are often more thorough or responsive than the codes proper owner/originator. Awareness of the risks associated with these components and how they fit in therefore becomes important to the tester.
Conclusion: Testers, like developers, need to increase their knowledge and how they do their job, as the scope of their work increases. This adds to the list of edge cases that both developers and testers need to be concerned about; static testing may become slightly longer as a result.
Much legacy software was highly monolithic, wholly dependent on the originating company (or sometimes the salesperson) for advice when problems arose. Once you get beyond these dinosaurs, integration testing becomes a much bigger concern. Seamless integration of multiple system is crucial, including many microservice intercommunication commands that serve as connective tissue between the various applications. In the legacy days, storage was at a premium, severely limiting database size (good luck with CRM solutions!) and scalability – not so today.
Conclusion: Testers, like developers, need to increase their knowledge and how they do their job, as the scope of their work increases. Once your system has more components, more things need unit testing, and integration testing becomes necessary. There are also more variables regarding interaction, as there are more moving components that can be in a variety of different states, and different combinations of communications or miscommunications. Debugging a choir is more complex than debugging a soloist.
Whether you’re a tester, developer or software user, you now have an idea and appreciation of how changes in the development world affect the testing world and will continue to do so.
