Watch this video.
Why have a biometric mechanism for preventing access, and then provide a regular lock and key in case the mechanism does not work?
If the biometric device is prone to malfunction (hence the need for a mechanical lock) why incorporate it at all? Why not spend on a better mechanical lock?
Lesson for testing: A system under test should be tested not only for what it is supposed to do (opens and with its key), but also that it does not do what it is not supposed to do (opens by any other means). To write tests for the latter is difficult. It needs knowledge of the implementation. It needs white box tests. It needs reviewers of code - and locks - to check for vulnerablity.
Reminds me of a true story. We had, in one our compilers, an implementation of some tricky optimization. Unfortunately it tripped up more often than it worked. The code had to be disabled. One of the developers was so attached to this clever piece of optimizing that he just could not bring himself to disable it. I suppose some people were attached to the biometric device.
1 comment:
Totally agree with that. Developers do get attached to code and argue to have it in the final build, even if it makes the application break in some odd situations :-)
I remember my first application (the DTS system), which I had got attached to that I had started ignoring issues which were irritants to other users ... :-)
Post a Comment