2

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?

Improve this question
3
  • 1
    Automated testing. It won't ensure there's hidden pieces of functionality sneaking into your code, but you'll ensure at that what's currently working isn't broken.
    – Tiago Cardoso ♦
    Jun 15, 2016 at 23:36
  • 10
    I smell an XY problem. You have problem X and think that Y will solve it, but you're not quite sure about how to do Y. So you ask us about Y, but your real problem is X. What is your X? What is the real problem that you're trying to solve?
    – RubberDuck
    Jun 17, 2016 at 0:50
  • Is this about gold plating?
    – Sahan De Silva
    Aug 19, 2016 at 3:06

5 Answers 5

Reset to default
7

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.

Improve this answer
6

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.

Improve this answer
3

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.

Improve this answer
0

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.

Improve this answer
0

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

  1. 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

  2. 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.

  3. 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

Best,

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.