The lack of validation — bug or feature of the program (architectural defect)?

Suppose the program was not taken into account, which requires some checking. But over time it became clear that the lack of this check leads to a program error.

Is the absence of validation bug or feature of the work programme, even leading to an error?
Are there terms FOR accounting errors the concept of "architectural flaw"?

The question is how should be classified the lack of validation in systems of accounting errors.
July 8th 19 at 11:14
3 answers
July 8th 19 at 11:16
Solution
The lack of validation is a bug, not a "defect".
If it still fails - this is a serious bug. But if it leads to program crash, violate the integrity of data or allows to bypass security - this is a critical bug.

A bug is a discrepancy between the behavior of the program requirements.

Now consider two situations:

1) Requirements did not exist.
Neither in words nor on paper. Decided to drag the code and started. In this case, the question of "How to call what we drilled into the validation" will disturb the least - you need to drag.

2) the Requirements are written (or arranged) and it clearly States that validation should not be.
In this case, in the realization there is no bug - works as per requirements.
However, the requirements contradict common sense (all incoming data should be validated), so this is an error in the requirements and fix the necessary requirements, citing what problems can cause the lack of validation.
July 8th 19 at 11:18
If control is clearly described in the requirement implementation, and this control is not implemented is a gross (intentional) violation of work (essentially sabotage). Need to punish for non-compliance with the TOR developers and the entire chain of supervising employees which passed through the failed product right up to the prom. the customer's servers with all the ensuing consequences.

If the customer thinks that the developer will think out the idea for him, and realizes the control, but in fact there is no control, it's just a bug, with all the consequences (2-4 cat AI). The developer is not obliged to do so, but wishes.

I have identified 4 categories:
1. Failure to comply with TK - a gross violation of the implementation of the functionality.
2. Critical - non-recoverable failure in SOFTWARE, Finance. loss and others.
3. Important - it is worth paying attention to.
4. Not significantly, but would allow to avoid many mistakes in the future or to strengthen existing controls.
July 8th 19 at 11:20
The program, under certain conditions fails. For a tester this is a bug.

For example we have not provided validation of TK, and requirements of the testers. We have the check is post-factum.
Nothing can be done. Might check the requirements - it would be possible at this stage to prevent some deficiencies that subsequently would lead to a crash.

We like this: if it can solve the problem yourself without violating existing requirements and communication protocols component, it just does it. If you need changes in the specification or elsewhere are written in separate statements on a fix, and attached to the original statement. All pretty standard.

Find more questions by tags Designing softwareTesting software