Open System Thinking and Software Testing (7)

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

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

As written in the first post, I think you can divide the levels in micro, meso and macro. In the postings 2 until 6 I tried to deal with the test project, micro level.

Let me now try to explain my vision how open system thinking can help with the meso level: Test Process. I will use here also several postings for.

An approach as Open System Thinking can also be used on this meso level. Here you have to pay attention at least on the following questions:
1. Are there improvements suggested by the organization related tot the test process?
2. Are there actions from the test project which results in an improvement activity?
3. Are there other processes which have impact on defining a test strategy?
4. Is there a test process improvement program started?
5. What tooling are available to start a test process improvement program ?
6. What kind of development method is used in the organization?
7. Does the test process fit the existing development program ?
8. Does the development method support the organizational procedures?
9. ...

Of course their are more question which have to be asked to fill in the quadrants of the open system model. Only this will be the start of it.

In the next topics I will perform the same steps as used in micro level to fill in the picture how Open System Thinking can be used helping gaining the overview on test process level.

Again I will perform the following steps:

1. Define the general meanings of the categories on meso level;
2. Identify the items per category: Goals, Technology, Culture and Structure;
3. Fill in the quadrants;
4. Define how the items are weakening or supporting each other;
5. Defining the sentences how this empowering/weakening is done;
6. Defining possible solutions how to monitor or to define new improvement suggestions

If you have some additional remarks or suggestions please leave a comment.

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

Mikado Management or Test Management

Ever been in a situation were you did not have much control over your test environment? Have you been in such a situation the developers deployed their solutions whenever they thought it was ready? Or have you been in a situation when you came back at work new deployments have been done?

To me it seems that those kinds of situations all previous work you have done on testing was useless when your goal is prove quality instead of finding as much issues in code as there are.

You might compare it with the game: Mikado

In this game every stick has its own color and every color has its own value. When starting you bundle the sticks and let them cautious fall. And your aim is to get the most valuable sticks without disturbing the other sticks. If you translate this to testing every functionality has its own value and you want to see how it works and how it is integrated. Does it disturb other functionality when using it?

Only what happens when new functionality or solutions are offered? All sticks are picked up again and newly setup. The whole stick-pile is transformed and you have to start again. This result into a new situation, sticks which had in earlier phase no direct interaction with other sticks might have now.

Only do you have the time to start testing all things again? Did you handle some kind of regression testing? I think if you keep continuing testing without any additional effort you performing some kind of Mikado Management. You are not aiming for gaining as much points in your time window, you aiming for getting as much sticks in you time window. Your test strategy shifted from proofing quality of main and import/risk full functionality towards finding as much issues in the top shelf of your system.

To deal with situations as this perhaps the following actions can be performed:
1. I would start making sure that you have control of you system under test, you give approval when code can shift in your environment. A disadvantage of this is that some necessary code is not there for you to test
2. Another option is Continuous Integration: it allows you all those transports and delivery time is decreased, only when in this continuous integration also automatic quality measurement is done by the development part, or better: the team, the sticks have not been picked up again, there is prove about the impact of the new code on the system.
3. Or define a set of regression test and after every delivery moment you execute those test set. You can decide based on technical impact of new functionality or solution if you run it immediately or after several deliveries. Or when deliveries are done on daily basis, you can start in the morning with executing that basic set of test cases. Keep in mind that these sets can be dynamically based on the area where solutions are provided and time is under pressure.
4. Another option could be automating your regression set. You can start the regression set when ever a deployment is done.

I think the best situation here could be having the continuous integration mind set. Where it might be an optimal situation where also the regression set of functional test is embedded in this integration and also automatically executed.

Only not every organization or project is yet mature to deal with such an approach. In such a case I suggest to prevent Mikado Management, and keep control or gain control over your test environment. If you have to decide what the quality of the system is, you should be responsible for the state of the system. Therefore you decide when deployments are done. Important in such a case is that management accepts the risk that the test process can extend due to deliver later in time.

And for those dare devils, if you can not get control over the test environment and transports are made when ever. Take the Mikado Game with you and start playing that game instead of testing. Think about what sense does it make if you keep continue testing and you don't get time of performing some regression testing? You loose the picture of quality. In that case playing Mikado you have at least some fun. Playing it with your manager might help make them understand the situation you are into.