Lecture 3 - Test Cases and Test Suites -> Quick Intro -> Test Case Structure -> Results Of The Test Case Execution -> Useful Attributes Of The Test CaseThe test case execution is finished once we have compared the actual and expected results. This comparison can give us one of two results:
1. PASS-i.e., AR equals ER
2. FAIL-i.e., AR does not equal ER (bug? – see below)
Brain positioning
If test case execution result is FAIL it doesn’t necessarily mean that we found a bug.
Here is typical start-up situation: product manager communicated certain change with programmer, but none of them communicated that change with test engineer.
So, code is going to be legitimately changed, but test engineer will not be aware of it and test case execution will end up with FAIL. Thus the FAIL would be caused not by bug, but by the fact that expected result known to tester is wrong.
Sometimes we have a situation where the test case execution is blocked, so we cannot get to the actual result. For example, in Test Case with Credit Card, we can be stuck at Step 23 if the Make Payment button doesn’t exist on the Web page. In that case, we would file a bug about the absence of the Make Payment button, and we would delay the execution of this test case until that bug is fixed. Next ->
Lecture 3 - Test Cases and Test Suites -> Quick Intro -> Test Case Structure -> Results Of The Test Case Execution -> Useful Attributes Of The Test Case
