A passionate tester
I’m not a scientist, I’m not a historian, I’m not religious follower and I’m not a native English speaker (bare with me and educate me if I’m wrong). What I am? I am a passionate tester and see in other disciplines lessons we can learn for testing.
So I come this posting. Yesterday I watched a documentary about the beginning of life. This documentary made me think about the discussion which is recently going on in my world of software testing.
Some references contributing the discussion:
Stuart Reid: Keynote 3: When Passion Obscures The Facts: The Case for Evidence-Based Testing
Cem Kaner: A new brand of snake oil for software testing
James Bach: Stuart Reid’s Bizarre Plea
Jon Bach: The Truth about Testing?
Nathalie Roosenboom de Vries- van Delft A lot on my mind…
The documentary
While watching the documentary on discovery channel I was captured by the example how John Needham (10 September 1713 – 30 December 1781 was an English biologist and Roman Catholic priest) performed an experiment to "proof" that live can be created in an "closed" environment. Based on his experiment he believed that a concept of "Vital Atoms" exists. This concept deals about the escape of atoms into the soil and are again taken up by plants. You might see this experiment of adding water in a sealed bottle and after a while life was growing in the bottle. As there was nothing and it was sealed, there must be something which is smaller and is created by parts of atoms.
If I'm correct he had quite some followers and the concept of "Vital Atoms" became a hype. People seemed to believe what he told based on his proof.
Fortunately Louis Pasteur (December 27, 1822 – September 28, 1895) was a French chemist and microbiologist born in Dole.) proofed with his experiment that a mistake was made. The obvious sealed bottle was not sealing the bottle completely from the outer world. Bacteria were able to enter the "isolated room".
The debate about the origin of life occurred later on triggered by Charles Darwin (12 February 1809 – 19 April 1882 was an English naturalist) who wrote the On the Origin of Species. With this document a new era is started. He didn't write about how life began. He brought biology and chemistry together in explaining how life evolves.
The debate started between a god who created life and life which evolved.
Between the followers that life evolves several experiments, hypothesis and theories were developed to proof that under various circumstances life can evolve and created. For example the combination of oxygen, carbon and other materials combined with some source of energy can result in "life-forms". The Oparin-Haldane Hypothesis by Aleksandr Oparin (in 1924), and John Haldane (in 1929, before Oparin's first book was translated into English), defined such a process. In short I would refer to this process in terms of chemical components which were individual present in the sea and transformed by ultraviolet or lightning into organic components.
Haldane even called it the 'prebiotic soup'.
Stanley Miller came with an experiment called Miller–Urey experiment (conducted in 1952, published in 1953) (re-concucted in 1982) to proof that in an isolated world life can be created. This experiment together with the outcome resulted in "the standard". They believed that it would be so easy to create life.
This concept also supported that life could be created else were but on earth, also called Panspermia. If I remembered well from last night watching the documentary, there is space in found pieces of meteors which are older then the earth resembles the structure of "simple" cells. Combine this with the theory that in isolated spaces also organic components can be created, the change is available to raise life from outer space.
Jeffrey Bada also executed the Miller-Urey experiments (see: Primordial Soup's On: Scientists Repeat Evolution's Most Famous Experiment by Douglas Fox) and continued on it. With the difference looking to the environment of the earth containing amounts of iron and carbonate minerals. He added them to the experiment and came to different outcome.
Other scientist followed their road bringing up hypothesis and research to see about the options creating life under extreme conditions, like near volcanoes, in caves, under water without light etc.
In the documentary I watched more exampled were provided which in my opinion also can be translated to testing.
What to do with testing?
Perhaps you wonder what this has to do with testing. Perhaps you made your own conclusion or picture. What I see is a process where evolution is involved. Not only evolution of the human species. You can see also an evolution of human thinking. Based on the known context John Needham came to his approach and method. He was able to sell it to the crowd and gained followers. Almost hundred years later a new person, Louis Pasteur, came with his conclusion to proof otherwise. I proofed that although the conclusion seems to be valid, the environment was not as what was expected. Based on the knowledge of John, he was right, only due to technique and new understanding; human kind was able to bring up other methods.
In testing I see also people evolve and continue to challenge "experiments" and "methods" and also people who accept certain outcome and become a follower.
Louis Pasteur did not proof how life was created, he just showed what went wrong in that experiment. In the same era Charles Darwin published his view about evolution. This triggered other scientist with other disciplines to continue the search how components evolve.
This evolution triggered me to think how just "zeros and ones" translate in bugs.
I would say that those zeros and ones alone won't do anything. It is the context how the will become visible into functionality and the environment how they can evolve. Even in new functionality or in flaws of evolution.
As testers we have to be open for other disciplines and understanding from those disciplines to continue. We can learn from it and should spend time for investigating those disciplines instead of spending time our approach is the only truth. For learning an open debate and does necessary based on mutual understanding and not solely on the perception own the single truth.
Like Stanley Miller re-conducted his experiment after years we have to be alert and keep learning and questioning our approach. It is mandatory to keep an open mindset. Like Jeffrey Bada did, also perform our own experiments. They might support or adapt visions of others, or even your own vision.
Testers should be able to discuss the possibility of own failure and learn from others if they perform similar experiments. In approaches like the Schools of software testing there must be space to discuss, challenge, disagree and agree with each other to make evolution in software testing possible.
Do you believe?
What I learned from the documentary is that people are followed by others who claim to have found the evidence for their hypothesis and that others are false. To me, it turns out that in history certain failures are often made. In the example above, initially they seemed to be right although time proofed the opposite.
I don't think it should matter who is wrong or who is right, you have to be able to define you own mind and not following people because they claim to have the proof. You might use their thoughts because it helps you. it helps you in your work. It helps you in your own process of learning.
When accepting this, you have to be aware that what you believe in now might be wrong or different later on.
Was John Needham wrong with his assumption? I think not, based on his knowledge and the lack of knowledge of others who lived in his era, he seems to assumable right. Others learned from it. It would be wrong if he deliberately misused situations/ did not present facts or ignore other(s) visions to obtain his proof.
If we follow some school and deliberately ignore others how would this support the evolution of our profession? How different are we then Pope Damasus I who assembled the first books of the bible at the Council of Rome in AD 382? Imagine how different the world would look like when the bible contained other chapters?
I think we should mutual accept each other thoughts and learn from it and adapt. The key word is here mutual. Are you making the step with an open mind and support mutual learning or are you leaving behind?
Additionally to read:
While searching for some background information I stumbled on this book. I believe it is worth reading
Thinking about Life: The History and Philosophy of Biology and Other Sciences By Paul S. Agutter, Denys N. Wheatley preview this book
Thursday, May 20, 2010
Thinking about testing and learning
Posted by
Jeroen Rosink
at
11:27 AM
1 comments
Labels: Ideas, Open System Thinking and Testing, Testing in General
Saturday, November 29, 2008
Open System Thinking and Software Testing (8)
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 (7)
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 mentioned in the previous posting the same steps can be followed.
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
To define the focus of general meanings of categories you have to consider the basis of an organization: Vision, Mission, Strategy and Objectives.
Based on a vision of one or more persons a mission is defined. That mission is the goal of an organization. To comply to this mission a strategy is developed. To meet that strategy objectives are defined. If one of these objectives are not yet met often they are mentioned in business cases which will be the basis of a project.
I think we need to make a decision. To use this model you can use two approaches.
1. Define the basic context (general meanings) and after performing the defined steps you create heuristics which you want to act on
2. Start defining heuristics and use them as basis to perform the steps.
For more information related to heuristics I want to refer to documentation and weblogs from James Bach, Michael Bolton, Cem Kaner and Brett Pettichord
Documentation:
Brett Pettichord: Schools of Software Testing
The Seven Basic Principles of the Context-Driven School
James Bach, Rapid Software Testing
James Bach, Rapid Software Testing Appendices
Posted by
Jeroen Rosink
at
10:08 AM
0
comments
Labels: Ideas, Open System Thinking and Testing
Sunday, May 25, 2008
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:
- Define the general meanings of the categories on meso level;
- Identify the items per category: Goals, Technology, Culture and Structure;
- Fill in the quadrants;
- Define how the items are weakening or supporting each other;
- Defining the sentences how this empowering/weakening is done;
- Defining possible solutions how to monitor or to define new improvement suggestions
The next article related to this post can be found on: Open System Thinking and Software Testing (8)
Posted by
Jeroen Rosink
at
10:47 AM
0
comments
Labels: Ideas, Open System Thinking and Testing
Sunday, March 23, 2008
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®):
- Plan & Control phase
- Setting up and maintaining infrastructure phase
- Preparation phase
- Specification phase
- Execution phase
- Completion phase
- Identify per category the values related to test project
- Fill in matrix
- Define per value the relations to other values
- Define the impact of those relations to each other
- Define the possible risk or dependency
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)
Posted by
Jeroen Rosink
at
8:11 AM
0
comments
Labels: Ideas, Open System Thinking and Testing
Sunday, March 2, 2008
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.
- Using jargon supports usage of formal test method by communicating in a same language
- 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.
- 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)
Posted by
Jeroen Rosink
at
11:36 AM
0
comments
Labels: Ideas, Open System Thinking and Testing
Sunday, February 3, 2008
Open System Thinking and Software Testing (4)
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 (3)
In the previous post I defined some items to the categories. The next step I want to do is identifying what items form the categories: Goals, Culture, Structure and Technology are supporting or weaken each other.
In the picture below I classified those items.In the figure below an example is given how to visualize supporting/weakening items.

A table like this gives some lead on those actions were to focus on. A next step could be identifying certain problems which might rise or what positive effect could optimized. For example: Internal testers don't have much experience in testing. This might result in less optimal implementation of a test method. As counter measurement an experienced test coordinator might be assigned to those testers to monitor their work.
Another example would be that not issues are logged as testers are talking to the developers to get some issues solved. Allowing this might result in a less clear overview of the quality as you loose information about issues.
I think a certain result of this excercise not only give information and control over the process. It also gives information about dependancies, boundary conditions and risks which could be used in test plans.
I leave this post as is and will continue with the next post in this category with more examples and perhaps how to continue with it. The postings in this category is a result of a living mind.
The next article related to this post can be found on: Open System Thinking and Software Testing (5)
Posted by
Jeroen Rosink
at
10:13 AM
1 comments
Labels: Ideas, Open System Thinking and Testing
Sunday, January 20, 2008
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)
Posted by
Jeroen Rosink
at
9:33 AM
0
comments
Labels: Ideas, Open System Thinking and Testing
Friday, January 11, 2008
Open System Thinking and Software Testing (2)
As mentioned earlier I will try to continue with the Congruence model.
In the previous blog I Open System Thinking and Software Testing (1) stated the following:
- Task & Formal Organizational Arrangements (Which might support creating Order)
- Informal Organization & Individual (Which might lead to Chaos)
In test projects you also see a similar behavior. I will try to give an example how there is a relation.
There is a tendency to gain control over the situation by assigning testers to the project performing tasks out of their expertise (testing) on a defined way like a test method, Formal Organizational Arrangement.
The chaos is created because people have as individual their own agenda to act in the project. Also there is interaction with others which is not written down, still that information might be valuable for the project. An other example is that due to immaturity not all things are captured in procedures and work instructions.
Is order good? Or is Chaos bad? I don't think so. Organizations are sometimes called as living organism. Why not a test project? Sometimes some items which lead to chaos can intensify the means which leads to better control.
For example: In the coffee corner there is a conversation between testers from 2 different projects. This is done on informal manners. During that conversation the tester is explaining he struggles with a way to structure the test. The other tester explains that she has a good simple template for it. This template can be used in the other test project as well.
In this situation an informal conversation can support a formal organizational arrangement, using a test method and support this method with means.
Michael I. Harrison presented in his book: Diagnosing Organizations - Methods, Models and Processes 1987, the following model
In my opinion these are just other words for: Task, Individual, Informal Organization, Formal Organizational Arrangements.
In the next blogs I will use the elements from M.I. Harrison. The reason to do this is because it might be easier to classify. As there might be conflicting goals and supporting goals. Also technology is much easier for us testers to understand :)
The next step would be identifying the items which can be placed under the categories:
- Goals
- Technology
- Culture
- Structure
This should be related to the test project. As you might already noticed that I started to identify on Micro level. Feel free to post your suggestions.
The next article related to this post can be found on: Open System Thinking and Software Testing (3)
Posted by
Jeroen Rosink
at
9:15 PM
0
comments
Labels: Ideas, Open System Thinking and Testing
Sunday, January 6, 2008
Open System Thinking and Software Testing (1)
A former teacher of mine introduced me the Open System Theory (OST). Some part of those lessons kept me thinking as it was about finding the balance between Order and Chaos in organizations and identify their influence on some basic components of an organizations.
Thinking about this I noticed over the years that in test processes we also know some moments of creating order and still manage chaos. Mostly this is done using some formal test methods.
Perhaps there are some lessons we can learn about the way of Open System Thinking.
The Open System Theory was partly explained in the book: Organization Theory by V.K. Narayan and Raghu Nath. Though I didn't had the book anymore it triggered me on a quest on the internet.
What I found on the internet related to Open System Thinking are these figures (knowing not to be complete):
- 1951: Kurt Lewin came with Force Field Analysis in Field Theory in Social Science
- 1965: H.J. Leavitt based his Leavitt's model onto that in Applied organizational change in Industry
- 1978: D. Katz & R.L. Kahn defined the model Open Systems in Theory in The Social psychology of organizations
- 1980: D.A. Nadler & M.L. Tushman defined the model: Congruence Model in A model for diagnosis organizational hebahiour
- 1992: W.W. Burke & G.H. Litwin defined the Burke-Litwin Casual Model in A casual model of Organizational performance and change
Some models are shown below to give an idea which direction I'm tending to follow.
A model introduced in 1978 by Katz & Kahn
Nadler & Tushman defined a model called Congruence Model (1980)
Burke-Litwin Casual Model:
In my opinion basically Open System Thinking is focusing on getting grip on organizational changes making not a direct link to different levels. In lessons related to Economics I was though about terms like Macro, Meso and Micro.
I will try to link these terms to Open System Thinking and Software Testing, it could be something like:
- Micro level: Test Project
- Meso level: Test Process
- Macro level: Quality Assurance as part of an organization
Another idea is investigating looking to the Congruence model: Task & Formal Organizational Arrangements (Which might support creating Order) and Informal Organization & Individual (Which might lead to Chaos) how this can be translated in those levels.
Of course there are more roads which leads to Rome, an expectation I have on this quest is getting more information/ insight how testing can be separated from development methods and still fits in organizations.
The next article related to this post can be found on:
Open System Thinking and Software Testing (2)
Posted by
Jeroen Rosink
at
2:03 PM
0
comments
Labels: Ideas, Open System Thinking and Testing

