|
When we test an applicaton, there could be a case where developers have claimed our application has some 'wrong behavīor', and they are not going to change it.
In this case, we still need to verify this 'wrong behavīor', i.e, to verify if our application does behave wrongly exactly the same as developers described, sounds 'ridiculous', en? :)
The logic behind this is to verify the consistancy between what developers have
claimed/documented and our applciation's real behavīor. If no verification has been
implemented, in new release, developers may have the assumption that our previous
version app has the same 'wrong behavīor' as documented/claimed by them before, and
new fix/enhancement (or even new app design) based on this assumption will face high
risk of failure.
Of course, there's precondition as long as the claim is clear & simple enougth to test
, we should test it, otherwise, if the descrīption is so vague (e.g, 'our app does not support ...'), we need not implement the test on this, but we need to highlight issue. |
|