When defining software requirements, should automated testing (unit and integration) be specified? I have not seen any guidance on this, and "testing" is not a functional requirement for the software. But, from a CI/CD perspective, it's pretty much a "must do".
Perspectives/opinions are appreciated, but direction to articles/guides would be greatly appreciated.
1 - The requirements (high level) are being written to support a bid/proposal process.
2 - There is a desire/intent to incorporate CI/CD to facilitate shorter delivery/deployment cycles.
3 - Achieving #2 is next-to-impossible without automated testing, both unit-level and integration.
4 - The intent is not to identify specific tests to be performed against specific requirements, but to establish a requirement that development of automated tests is included as part of the successful bidder's software development process.
5 - I get that this should, ideally, be in other documents/processes. But, those tend to be developed/delivered after the award; ergo, the question.
And, last but not least, simply requiring automated tests to be developed does not mean that the tests will adequately test the developed software. So, if such a requirement were imposed on the successful bidder, it would also require some objective measure of defining what constitutes an acceptable test. These exist, but this all has the potential to become a wormhole - so I'm trying to balance the pros/cons.