Open System Thinking and Software Testing (6)

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 (5)

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) )

I ended the previous post with a possible task for the test manager or test coordinator or perhaps the SCRUM-master to perform this exercise. Re-reading that posting I can imagine that you start with the exercise and then stop doing it. I think this should be an ongoing process. It should be a new task for them to monitor on daily basis what is happening in the project related to testing.

To start a process like this we need besides a model also some tools and a phase description. This should be embedded in the test process.

Assuming that a test process knows the following phases (borrowed from TMap®):

1. Plan & Control phase
2. Setting up and maintaining infrastructure phase
3. Preparation phase
4. Specification phase
5. Execution phase
6. Completion phase

Assume this method knows the following steps:

1. Identify per category the values related to test project
2. Fill in matrix
3. Define per value the relations to other values
4. Define the impact of those relations to each other
5. Define the possible risk or dependency

I think you have the following tools:

You start with a quick scan during Plan & control phase. The focus lies mainly on the categories: Input, Output, Environment and behavior and processes. When the quick scan is performed you perform an assessment to fill in the remaining categories: Goals, Technology, Culture and Structure. The results are embedded in the test plan as risk, boundary conditions and assumptions. Also start creating the early mentioned Risk-Dependency-Backlog.

Keep in mind that it should relate to the test project it selves. For the process (meso-level) and quality control (macro-level) a similar process has to be defined. I think it is wise not to combine these levels as overview will hard to be gained and managed.

When starting the next phases in the test process on daily basis a similar exercise should be performed. Here you can use team meetings, walk around and standup meetings. The results of these should be translated in the backlog performing the steps 2 until 5. If there are changes identified you have to share it with your team, this can be done using the standup meeting, daily/weekly progress reports or email.

It is important that you approach the project as an open system, were all kind of things are happening and you are able to identify those things and judge their impact on the process. And most important, share it with your team. It can help you to make them understand why you made certain decisions.

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