Other than than code reviews by another developer and by trusting your developers won't do anything nefarious or stupid, is there any way to ensure that when you release a build to production or even QA that it doesn't include any extra code that's not part of the assigned requirement?
There is a lot you can do that ensures that the code does what it's supposed to do, but aside from trusting the people developing it (including their reviewers) there is basically no way to make sure it does not do more.
But it comes down to that trust in any other job, too. At some level, you need to trust the people. If you cannot, get others that you can trust.
Using a Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD) approach means that the code is self documenting. So introducing functionality beyond the original requirements would be obvious to anyone who paid attention to the code base.
What constitutes 'extra code' is a much more difficult question. It is quite possible that code is added:
- To indirectly support the requirements (e.g. helper classes)
- To refactor and improve the quality of the code base
- To ensure the expansability of the code
- To deal with non-functional requirements (performance, security, etc.)
Only somebody who is deeply engaged with the development team is likely to understand the significance of all the code being added.
Undesirable functionality can become a significant software security risk. The absence of architecture, design, formal requirements, specifications, test cases, and infrastructure can turn a harmless Easter egg into a massive data breach. In some organizations, this is a firing offense.
Code review is recommended but not sufficient for larger applications with limited budgets. Positive testing as practiced by most QA testers will be hard pressed to identify unwanted functionality. Such functionality is by definition absent from the software specifications or resulting test cases.
Static code analysis (SCA such as Fortify, Veracode, etc) will detect "dead code" aka code that is not executed during data flow analysis. (This goes well beyond compilation.) Then you can review the findings to determine what is happening and what to do. SCA will also find other concerns which could be equally serious.
Dynamic and integrated code analysis such as fuzzing could detect unwanted functionality in the application.
Answering this question in a product/project agnostic way, this is what the quality processes are about, specifically quality control. Product inspections before delivery to verify and validate it meets requirements and delivery criteria. It should not matter if the product is an IT solution or a remodeled bathroom or an ice cream cone. Inspect, exercise the product, use a checklist, and then sign off on it or not.
I understood that you are looking out for a Development process where in the code should not call for any additional functionalities expect the ones that are asked for.
Lemme try to pen down a simple approach here
Requirements Workshop - Once the requirements document is signed off by customer, arrange a requirements workshop meeting with Requirement provider / IT Expert (Developer) / Test Engineer - This helps to ensure that there is common understanding with three stakeholders
Work Break down structure - After Requirements workshop, set up a phase for IT Expert to provide work break down structure for the given requirement and get reviewed by reviewer - This helps IT Expert to focus on requirement and analyse dependencies.
Test Scenarios - After requirements workshop, set up a phase for Test Engineer to provide Test Scenarios and get reviewed and sign off by Requirements provider. The same test scenarios will be executed by IT expert as part of Unit Testing - This helps all teams to be on common understanding