Open System Thinking and Software Testing (3)

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

To place items in categories I will define the meaning of those categories in general terms:

• Output: The important products or services like test plans, test scripts, registered issues, Quality advise;
• Input: The means which are used in the process like: requirements, employment, budget;
• Environment: Relations with other processes within the project, organization like department: development;
• Goals: Official forms and standards like a test method, Key Process Indicators, mission;
• Technology: How the process is performed like kind of production, system landscape, usage of tools;
• Culture: Symbols, myths, rituals, jargon, dress code, way of working;
• Structure: identified services and units like management structure, geographic location of departments, employees and activities;
• Behavior and processes: identified processes for making decisions and communication style like conflict management.

As I intended to describe first on Micro-level (test project). I will start to define the items per category first on this level. Keep in mind that those items shall not be complete.

Output:

• Written advice about quality of system
• Identified risks for production
• re-usable test ware

Input:

• Written and approved Functional designs
• Test team of 10 persons
• Testing guidelines
• Iterative development process

Environment:

• There is a development department
• Maintenance is done by internal party
• Developers don't take testers seriously

Goals:

• Perform test project using a test method like TMap Next
• Measure quality within 3 months
• Give advise about: functionality, performance and usability
• Perform System Integration Test
• Create re-usable test ware

Technology:

• There are no official test tools for test execution
• There are some home made tools to create input files
• System under test doesn't contain all functionality
• System under test is a new build system
• There are several environments like: development, test, acceptance, production
• Testers doesn't have full rights a test environment
• Developers cannot deploy to test environment
• Templates are used for defining test cases and test scripts
• MS Project is used for defining test schedule

Culture:

• There is a mixture of internal and external (hired) testers
• Some testers are approaching developers about issues without logging them
• External testers are using test jargon to communicate to each other. Internal testers less experience. Don't know all the words
• Every morning there is a stand up meeting with the test team
• Test manager does not communicate informally with testers
• Not all testers are testing using test scripts as they don't understand them
• Some testers are only testing functionality what they think is important

Structure:

• Project management is located in another building
• There are 1 test manager (TM), 3 test coordinators (TCO), 10 testers
• The testers are located in the same room
• TM and TCO are involved in test management meeting
• TM is involved in project management meeting

This is an initial list. The next step could be identifying the relations between the items and investigating if they support each other or not. What could be the negative response of an item onto another item or what would be the synergy effect.

Currently the list of items are defined a bit general. I think in the following post they will be written in more concrete syntax.

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