Open System Thinking and Software Testing (5)

This is a continuation of the posting in the category: Open System Thinking and Software Testing. For the previous post you might check out: Open System Thinking and Software Testing (4)

For defining the items and investigation of the relations of those items to each other I'm still working on Micro Level: Test Project. (See Open System Thinking and Software Testing (1) )

If items and relationships are defined the next step would be defining how those items have impact on the test project. And see if they empowering or weakening other items. In the figure below I took some items to work with as an example.

1. Using jargon supports usage of formal test method by communicating in a same language
2. Lesser experienced testers weaken usage of formal test method as communication might contain noise when using test related terms. Also performing tasks as intended in method might be done differently.
3. Due to PM is located on other location; it is harder for them to monitor the process if everything is done as intended.

Here you see that 2 and 3 have a relationship. Due to lesser knowledge is should be important for PM to monitor the handling of test related tasks. If it is not done, the implementation of a formal test method might be weakened. In a test plan this can be mentioned as a risk.

As item 1 supports the usage of the test method. This might help to control the impact of item 2 and 3. In this case it can be translated to train the less experienced users in front in the fundamentals of testing. This can be called boundary condition within the test plan.

As dependency the location of the PM can be mentioned. They have to be made responsible for communication and monitoring of usage of the test method.

Normally I saw in projects that risks, boundary conditions and dependencies are defined based on common sense. This approach might help to visualize the process of this common sense.

I can imagine that in some test processes the test manager or test coordinator performing an exercise like this. Perhaps in a SCRUM this exercise can be done by the Scrum Master. He can use this and call it his Risk-Dependency-Backlog.

The next article related to this post can be found on: Open System Thinking and Software Testing (6)