Often application functionality is tested by executing business workflow sequences. These workflow sequences can be broken down into logical business transactions. Each of these business transactions can be developed independently and maintained as separate manual tests. These manual tests can be used to implement multiple workflows.
To get maximum value from this concept, you should implement each of these manual tests as a separate test case with a corresponding manual test. The manual test starts from a known application state, executes the business transaction, and verifies its results in the application.
Use Test Suites for Business Workflows
For the business workflow testing, you design a test suite
that is basically a sequence of these business transactions represented by a
number of test cases (and their corresponding manual tests). By implementing workflows in this way, if new
workflows introduce an enhanced capability with a small addition to the
application, the testing of this workflow can be put together very
quickly. Most of the workflow will
consist of existing business transactions with either a few being modified to
take into account the new functionality or by the addition of a new business
transaction if it is a completely new step in the workflow.
As an example, in web testing where each screen tends to contain data fields to be filled in and potentially an enforced sequence of steps, this may map to a single manual test. Let’s begin with the assumption that screen to screen navigation is not linear but rather a network of possible workflows. By implementing each screen or set of screens that have a definite sequence as an independent test case (and manual test), you can build a catalog of test cases from which you can construct business workflows through your application.
Impact of Blocking Defects
When a test case is blocked then none of the test suites (workflows) containing that test case are also blocked. This highlights the importance of fixing blocking defects towards the completion of the testing effort. As you report on your testing status, you can want to highlight how many of the test cases can not be executed due to blocking product defects. Currently the only way to do that is to attempt each of the test suites containing the test case which is blocked. This permits the execution of all the preceding test cases up to the blocking test case but doesn’t permit any of the subsequent test cases to be executed. By looking at the overall test cases planned, you can see that there are many test cases not run and maybe a few that are blocked. The status is a little misleading if there are a few blocking defects that are present in a large number of the test suites.
View Requirements Impact
By viewing the test suite results, you can see if there have been a large percentage of test suites attempted and ended up blocked. By running the “Plan Requirements Defect Impact” report in RQM, you can see what requirements are impacted by defects and then trace those “blocked” requirements over to the test cases and test suites related to those blocked requirements. This is one way to assess the impact of the current blocking defects. In the case of an integrated tool solution, this report must be run against the combined data warehouse either through the Insight product or in the new CLM 3.0 product set.