Enter Compliance Requirements
We have long fought between functional and non-functional requirements in IT systems development. A new requirement character—compliance—is entering the stage, requiring you to broaden the scope of the testing activities.
In the classic Western movie "A Fistful of Dollars," the Man with No Name (Clint Eastwood) arrives at a little Mexican border town. He is quickly introduced to the feud between two families vying to gain control of the town. [https://www.imdb.com/title/tt0058461/plotsummary/]
For years, there has been a similar feud between functional and non-functional requirements in IT systems development. One team handles the functional feature requirements, and another handles the system's operational abilities. The testing staff has long been biased in testing only functional requirements, spending all their energy on internal disputes regarding testing terminology and vocabulary. If a requirement couldn't be dynamically tested, it wouldn't be considered real testing. Non-functional testing is left to the operations teams—yet another feud to split the town.
As you probably know, the fix is systemic. Better teams use DevOps practices to tackle the "core chronic conflict of pursuing both: responding to the rapidly changing competitive landscape and providing stable, reliable and secure services" [DevOps handbook]. Unfortunately, modern ways of working are not as prevalent as you would think. Development teams are still split, and requirements are unbalanced.
A New Requirement Character Enters
One testing activity that is not recognized in the functional/non-functional split is compliance requirements. The increase in regulated requirements is a growing pain for business leaders.
Jesper Ottosen
We have previously seen this with SARBOX and EU GDPR, but new compliance requirements are coming due to the world situation. It will spread to other industries, mainly if you deliver IT to the public sector. To name a few compliance requirements:
- EU NIS2 directive on cyber security measures
- EU ESG Environmental Social and Governance compliance
- W3C Web Content Accessibility Guidelines
- US FISMA on federal agency information security
WCAG deals with website accessibility and is an excellent example of a compliance requirement: part functional (dictates functionality: alt-text, screen reading) and part non-functional (dictates contrasts and navigational aids). Many emerging governmental regulations are around broader security controls and information security.
To be compliant, your organization has to develop secure applications—the requirement is for your organization rather than the product. Your organization's "license to operate" might depend on fulfilling the regulatory requirements.
Broaden the scope of Testing Activities.
In my experience, managing testing and quality activities is becoming more about managing compliance, security, and contractual activities than worrying about feature testing and scalability. Sure, feature development and scalability need testing. We have industry practices that handle these more effectively than a team of testers and old-school tools.
What changes do you see to the scope of your testing activities? If you manage testing, especially in a business-to-business context, other areas are becoming more critical to the business: compliance, security, contracts, and operational readiness.
New Fields of Testing Activities, 2023 https://jlottosen.wordpress.com/2023/09/06/new-fields-of-testing-activities/
A last testing activity that might fall under the scope of the project test manager and is not classically functional or non-functional is gathering evidence of contractual deliverables. In the last couple of years, I have been part of projects where we had to deliver the system functionally, test it, and collect evidence of the contractual deliverables.
The outsourcing contract converted its textual requirements into a massive spreadsheet of ~1000 lines. Each line had to point to objective evidence of each contractual requirement being fulfilled. Examples:
- Backup procedures, requirements for RTO/RPO
- Production data access controls
- Network security and integration protocols
- Processes for yearly financial controls
The above activity is indeed a testing/trial activity, as we would create a plan document of the scope, List the items under test, confirm each item by finding evidence, fix bugs, and finally collect a report. These three testing activities are about the testing – not the testers. A range of different subject matter performs the actual performance of the compliance controls. If the above testing activities fail, the business is equally at risk as if a functional or non-functional requirement is failing.
