If you can not beat the paradox then join them

I recently read an article written by Zeger Van Hese, Jun 9, 2007 called: Software Testing: A Profession of Paradoxes? This paper won the Eurostar award for best paper 2007 Although I don't know about the competetitors, I can imagine why he won it. The article explains in easy and general terms about the paradoxes we testers have to deal with.

Some paradoxes are supported with good examples giving me the feeling: "I have been there, I have done that?" I think if you also come in the position to explain to your manager, project leader or wife/husband why you have such an exiting job, you just hand them this paper.

I hoped there was more information available on the Net which teach me how to deal with paradoxes. Or even better: How to beat them.
Though I didn't find my answer, during this search I found this other article The Paradoxes of Change

Some of the expressions mentioned here are worth to think about:

• "Stick to your knitting"
• "If it turns out I really have to change, I'll change."
• "You find your craft by doing the things that are the most difficult."
• "We must live in the paradox"

Perhaps:

1. Stick to your knitting can be translated in testing terms like: Let me just do my work, you give the code and I'll test. Or, let me just use these techniques as I know these very well.
2. I'll change might be translated to terms like: Give me my marching order and I will march, any direction you like. If you telling me that we tested enough, finally I will agree.
3. Doing the most difficult things perhaps represents the idea of helping the organization by honor as there is currently none available and the job has to be done. I will inform you about the risks
4. We must live is perhaps supporting the idea that we as team might find out difficulties and we as team will challenge them.

What have I learned after reading those articles and writing this post? At least that writing something to combine things explaining those paradoxes without repeating them is hard to do. And also some believe that we testers have to be aware of the existence of those paradoxes. Understand them and most of all, recognize them. And decide for our selves if we keep knitting or join that live with paradoxes.

Let the bug rule?

Just sat down behind the PC reading an article about bugs and testing. This made me think about bugs in general. Normally we see bugs as annoying creatures or behavior in the system. Aren't we looking to it in a small framework? Some say that bugs are a part essential of the food chain. So do other creatures need bugs to exist? And so do testers.

I think systems do also need bugs. Let me explain. Almost every year there are fire seasons. Huge areas are burned down and start growing again. And occasionally flowers are growing on that place that has not been seen there over the years. Something beautifull got some space to grow again.

Getting back to the system. If there are no bugs in a system we might get to a point of no return, were we become afraid to touch the system and think about newer features.

I saw in some projects that because of bugs found during test phases some elegant solutions were build. This also could happen while the system is in production. Bugs might force people to think what they really need and while they are thinking they will also come up with newer things.

This made me wonder if we should try to find all the bugs we need? Perhaps we should focus only on those bugs who prevent for some uncontrolled disasters. Calculate the risk and deliberately don't test certain areas. Just to force Mother Nature to do her work.

Are you overruled and the I told-you-so moment

Now and then I visit Dilbert
When I read the strip by Scott Adams Dilbert 24/01/2008 I got a flash back. In a previous project I gave advice not to go into production. They accepted my advice and still went to production. In that particular situation the acted on the risks I mentioned and sent a service engineer together with the software.

This strip made me think about the boundaries of our responsibilities:


Is it fair for us to go into the I-told-you-so-mode when the risk becomes effective when a system is in production? Should we be more persuasive when it comes to effectuating identified risks?

It is easy to say: "The project ended, therefore I'm no longer on the project and therefore I cannot held responsible anymore as the owner accepted the product."
Or can we say: "If you disregard the advice about the system, I want to define a new project monitoring the chance of occurence with the goal to improve the test process to avoid those issues earlier?"

How can we be more persuasive and what are the boundaries?

Play the tune you know best!

James Bach made a posting on his blog Why Labels For Test Techniques? This triggered me thinking about communication of testers, between testers and testers communicating with systems. When I read that post for the first time I had some flashbacks about some situations I was into over the last years. In some projects there were testers who had experience in testing and understand the "test-language" I spoke. On other projects there were dedicated testers from the business having the assignment to test, understanding the business processes very well only had no education in the "test-language". This did not make them better or worse testers.

In my opinion we use labels, for example test techniques, to communicate with other testers. To make sure we understand each other about those things. And the rules to apply those techniques are the grammar rules of our language.

If this is indeed our grammar, we might have a risk if we don't know our grammar well we get some noise in our communication which might result in not testing the things we intend to do. The combination of noise in communication reminded me of a model I once learned: The Shannon-Weaver-Model from that site looks like:

In combination with that model I learned about terms like verbal and non-verbal communication. Where some researcher claiming that >90% of our communication is non-verbal. Though I don't have the exact books which confirms this statement, here an article who is mentioning and explaining it Non Verbal Communication

Think about when 10% of our communication is verbal, test techniques are used to present that communication, and then there should be more resources for us testers to measure our test process or quality of the system.

What has the grammar, the Shannon-Weaver-Model and the differentiation between verbal and non-verbal to do with testing? And what might be the relations between these objects?

Imagine what happens if we don't know our grammar well, or don't even speak the same language assuming that only 10% of our communication is done using the products of this grammar to speak to each other or to speak to the system we want to test. The chance we have noise in our communication will increase and by this the chance we don't test the system we ought to do. If we don't the test the system we ought to do we might give wrong conclusions.

I can imagine that applying the model towards Human-Human communication might be clear and the question rose how this can be translates to Human-System communication. In this I made the assumption that we communicate with for example test scripts to a system under test. Here I see the requirements as source, the encoder is the tester, the channel is the PC, the decoder and receiver is the system under test and the behavior of the system is the feedback we receive. This is the verbal part of the communication of the Human-System. The non-verbal part could be the attitude the tester has. For example if he looks happy, then the scripts might be executable and the system response as expected in the scripts. If the tester groans, there might be something wrong with the system, environmont or even with the test scripts.

How can we improve our communication?
Perhaps these steps might help:

1. Identify the skill level of the testers;
2. Determine the labels and grammar in combination of skill-level;
3. Agree on labels and grammar how we communicate;
4. Review the products as result of applying the communication labels;
5. Apply the products in communication with each other and towards the system (verbal);
6. Define measurement moments based on Shannon-Weaver-model when to check the non-verbal communication;
7. Clarify or adjust grammar rules or change communication language

To identify the skill level of the testers you can check on several items like: understanding the # of test methods, understanding the number of test techniques, ability of using those techniques. Assume we take the number of techniques as criteria then you might use these classifications:

1. Those who know no techniques;
2. Those who know about 3 techniques;
3. Those who know >3 techniques.

Of course there are more classifications to think about still 3 is a nice number. Here also starts the non-verbal communication part. You should not only act on the answers they give about knowing those numbers. You also should pay attention towards their attitude when you are asking them explicitly using test techniques. Hesitation might be a sign of not knowing those techniques or perhaps lack of trust in on selves about those techniques.

As said in a project I worked with testers without no knowledge about testing techniques. This made them not less valuable and able to test. Instead of using those test technique names like boundary, equivalence, interval testing I used other labels they understand.

This brings me to step 2: Determine the language and grammar. In that situation I used the following labels:

1. Basic functionality
2. Business Rules
3. Screen/ Layout/ Forms/ Reports
4. Exceptional/ Combinations / Negative

To get an agreement you have to ask them personally. When sending out an email or a document you will miss the non-verbal communication. A stand-up meeting might be a good tool to check if they fully understand and agree. When we agreed about the definition and meaning of these labels they continue thinking about test cases based on their experience with the system and processes. And they classified their test cases as such.

Using these labels helped me to check the purpose of their test cases and translate it for me to those techniques I know about and see whether we could extend their test cases. In this case the step 4 is executed by me using my test knowledge.

Now the real testing begins. (step 5) The testers can execute their test scripts. They communicate verbally (instead of spoken words, written words) with the system. They also communicate non-verbally. If for example they hit the machine or looking depressed there might be signs of something not wrong. This might be worth to check upon. Here the monitor process starts. If this behavior results in raised issues, they translate the response of the system on verbal level. If it doesn't result in a raised issue, then we have a chance of missing defects in the system. Or perhaps a flaw in the test script or test process. Perhaps you know more items we can check upon?

Only keep in mind that continues monitoring of testers might have an contrarily result. The tester might feel uncomfortable and signs of communication might become false signs. To avoid this we have also to agree on the moments we monitor. We sort of open the communication.

If communication is important in testing. And usage of grammar is a tool. We might consider the project goals and the personal goals in perspective. In short I mean with this that if there is lack of time and quality should be granted on a certain level there might be lesser time to teach the testers on their skills with newer techniques. In this case using those techniques they know might be a choice. I think it is better to apply those techniques you know instead of intending to use those you know for half as the result might be interpreted wrong. This is similar to "Play the tune you know best!" learning tunes while playing might result in bad tunes. And some people might become unhappy hearing those.

It is better to use 1 techniques you know best instead of using all for just a part and claiming you used them. As a claim might result in expectations.

Did we test enough?

Often you will say to your self or asked by your project manager: "Did we test enough?"
Sorry for this, I won't give you the answer on this question. As there are much better articles and books explaining when to stop. Instead I will give you a similar question(s). Hoping to trigger you to find the answer for your self.

Imagine that testing can be seen as reading books. And you have books on several topics and genres. You have also multiple writers on the same topic. When will you stop reading? When do you have enough knowledge for the next step?

When you reader start learning to read you picket those magic books with colored pictures. After a while you learned how to recognize some words. Here your journey of reading started. During your travel you learned more words and you might become interested in reading. After a while you figured out that reading more made you learn more, on college, university or your own free time.

You build your own reference of books and on certain genres you professionalized on an acceptable level. Did this stop you reading books on that genre? If you are interested then you keep on reading. If not, you stop reading that book, perhaps after reading just a view pages. Or you continue with another genre.

Perhaps the similarity with testing is asking your self: "Am I still interested to continue reading?"
In testing you also start with those funny screens. After a while you recognize certain defects in a system. You discovered that there is a certain grammar in testing to help you testing much better. You start using techniques. After discovering the process of testing in a certain way. you will notice that there are also other ways. Other genres for example Agile testing.

Related to the initial question: "Did we test enough?" Are you able to say you "read" enough?

For me testing is the same. I love reading and after a certain period I discover new writers and new genres. And both I hope to do for a much longer period.

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)

My Son the tester

This morning I came down and my son sat on the couch investigating his arm. Not taking care of his action I start making my bread. Suddenly I heard:
"Daddy, Daddy, I found it!" He was much exited.
"What did you find?" I asked.
"The bug bite!" he replied.
I asked him now he found it what he intends to do.
"Scratching of course."
"Will that help?"
"No but it itch."
I asked him to stop scratching as what he did.
Now he took a better look at the arm and noticed that it wasn't a bug bite at all. In the environment of the red dot he found some other red dots.
Curious as I was I asked him why he starts searching initially on his arm.
He just simply replied: "I had such a feeling"
Fortunately it was nothing this time.

On the road to work I thought about it. And somehow he made me proud. As he starts testing while he is just 6 yrs old (almost 7)

In my opinion this is similar to Exploratory testing. You have some feeling that there might be something wrong. He was thrilled when he found something. Though he tended to cure the symptoms he continued investigating in the surrounding part of the red dot to check if there were other symptoms. He found others and asked the developer (me) if it are bug(s)(bites). After rechecking we noticed that it wasn't a bug(bite) and also nothing serious. Still it was a temporarily behavior of his system.

I'm curious what he will become when he is 7 :)

Opmerkingen mbt TMap next (DUTCH)

Jeroen: 4/21/2008: Changed this posting as it was mainly in Dutch and Im not sure it will help someone. If you still interested in my remarks you can always contact me.

Normally I'm trying to write this blog in English. Only this would exception on the rule and sometimes rules can be broken. :)
The list mentioned below I based what I found while reading TMap Next. There is no warranty if this list is correct. It is based on the ideas I had while reading the book. I created it while reading and at that time it was Dutch. I also don't know if it represents the same pages in English. this is the main reason why not starting to translate the whole list. Perhaps it helps some one in the nearby future.

Though the list is quite long, I DO like this book. It can give good help on test projects. In other words, if I didn't like the book I didn't spend time keeping a list for myself.

Here the list in Dutch: (here the list was in Dutch)

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)

Management by Bleep

There are some ways of managing projects. A way of classifying them is:

• Management by Objectives: employers get there goals to reach and the manager has a facilitating role;


• Management by Directive: manager tells the employer what to do;


• Management by Walking around: manager checks on the floor on frequently basis if every thing is done the right way;


• Management by Exception: only when things are getting out side the defined borders management gets involved

I will not say one approach is good or one is bad. I think it depends on the situation. In testing it can be the same and during the project situations can change.

Sometimes when a project starts you develop a master test plan and detailed test plans. In these test plans you also mention what the entry criteria how the communication will be with other members of the teams like developers and more. You start with a bright vision and a clear view.

During the project some decisions are made. Those decisions have impact on your test process and the style of management. What will you do when:

• Requirements and functional design are frozen while they are not SMART yet;
• The test environment is no longer of your control, development can deploy when ever they want;
• The system is not stable, as older issues are returning again;
• The test scenarios and test cases are only focusing on code which would be probably delivered the next time and not covering all functionality;
• Due to unclear FO's newer requirements are showing up, issues are rejected as it was not specified;
• And a few more

A possible strategy would identify the risks and tells it to project management. Seems that the management style turned into Management by Exception. Only what management style is involved when all risks are accepted? To me it seems you are no longer in control of the test process as you intended in your test plan/strategy.

What I see and hear in some projects is that the manager goes with the flow and acts on bleeps. If the system makes a bleep or a tester bleeps out loud then the manager interferes. The manager keeps managing what is still manageable for him and if one of the mentioned risks becomes real he acts. This action is triggered by the bleep. A kind of Management on Bleep.

Now I'm wondering if it can be done using multiple management styles by one person. Or is this still Management By Exception?

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)

Do you, user, dare?

Sometimes I'm asked if we tested enough. As tester I'm tending to say "You can always test more". What is enough? There are dozens of answers when to stop testing. It mostly depends how many time, budget, risk etc there is.

Recently I was asked by a key user who was responsible for testing his part of the application. The key user had to give advice to his manager.

I could reply his question with testing terms like coverage, open issues, risk there is and what more. Only I knew that the answer would be: "I'm not sure, I think so."

I used this example:
Imagine you have to buy clothes for your self. You walk into a store and pick a trouser, underwear, T-Shirt. You like the color of the clothing only the T-shirt could be without that funny picture. Do you, user, dare to go out on the street with those clothes? Do you, user, dare to do it know based on the winter season and no coat? Do you, user, dare to approach your manager in those cloths as you know your manager likes formally dressed employers?

Do you have the same feeling about the application and do you dare to give advice? Can you answer me the question did you test enough?

Product User Life Cycle (PULC)

Over the last years I noticed that there are many ways to describe a Product Life Cycle (PLC). All cycles are explaining how the product grows during a project(s). The product can grow into a good direction; still the user feeling might tend to go the other way. There seems to be some other cycle next to the PLC. Parallel to this cycle there is something I will call the Product User Life Cycle (PULC).

The existence can be shown in short words using the phases in combination with user feelings:
1. Requirement phase: the user is exited since after long time he is asked to think what the user really needs
2. Building phase: the first negative sounds are getting there as the user is confronted that some functionality might not be there on go live
3. Test phase: There are still some requests for changes, seems the user knows how to act in a project and knows much better how to ask for functionality
4. User Acceptance test (UAT) phase: The negative sounds from build and test phase are acknowledged, not all functionality will be there, even some main functionality
5. Production phase: there is on certain areas no direct match with functionality and wish which results in dislike of the system.

Though the user is involved on early basis still there is a negative grow of user feeling. (Off course not on your projects) In development methods the call for early user involvement was growing. And sometimes continues User involvement. Still did it control the feeling? What I noticed that on a certain time in a project the user was heard, a RFC was created and it was scheduled for the next phase of the product. Or user involvement was only granted in the UAT as the code was not mature and the fear for negative sounds would be bigger.


Isn’t it better to manage those sounds on early basis then at the End? I think so. I like the idea of showing the user parts of the application while building and testing and give him the notice that it is not as it should be and intended to give them the opportunity to confirm if it is as expected or if some changes has to be made. Isn’t it better to have those RFC's now instead of the UAT?

On a previous project I got in touch with Conference Room Pilots. This is a term which is used in Oracle's development method called AIM. For more information about it see the article:

Managing Successful Conference Room Pilots by Ed Estaugh & Craig Scollick


Quoted from that article:
"CRPs naturally lend themselves to progressively increasing the functionality demonstrated to the users. The figure below highlights three blocks of CRP sessions within the Build Phase to scale the functionality demonstrated from transactional activities (CRP1) through to end to end business scenarios (CRP3)."

Though there are some challenges using this approach as managing the perception of the user and learning the user how to participate. (And off course more.)

A great benefit was that the user became familiar with the project, product and the team. In the first CRP it learned how the system would look like without seeing the "end" system. Based on that pilot it was easier to define the needed functionality. In the next CRP it prepared the user how the system would act on their own environment with their own data. No customizations were there. In the last CRP also a climps of the customizations were given.

This early user involvement can also be accomplished in normal trajects too. Let key users test during Functional Acceptance Testing (FAT) the critical functionality with a user point of view and not only looking towards written (requirements) functionality. Those users will learn from the product and will be better prepared for the UAT. They even understand certain decisions and can explain it towards other users. The acceptance grade might become larger and the chance of RFC's lesser.

This might help to manage the "feeling" of step 4 and step 5 of the PULC. Negative sounds are confirmed, though they understand the decisions as they had the opportunity to give feedback. And they know that in some cases the wish changed. Only it changed after they agreed to it.

I am aware that this post doesn't cover my whole idea as it would be too large for posting. Still the essential meaning is expressed:

• There is another cycle next to the PLC
• Involve users also during FAT is not a shame
• Managing feelings during the project is better and perhaps cheaper then when the product went live.

Combinations of all values in 3 columns

Here a macro which combines all values from 3 columns and makes unique combinations of it. I created this macro a while ago for someone on Experts-Exchange.com

Sub CombinedValues3Column4()
'Author: J. Rosink
'Date: 11-10-2007 'http://www.experts-exchange.com/Software/Office_Productivity/Office_Suites/MS_Office/Excel/Q_22949908.html
Dim i, j, k, l, RowsA, RowsB, RowsC, Rw As Long
Dim MyCol1, MyCol2, MyCol3 As Collection
Dim strtime, endtime As Long

Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual
RowsA = Cells(Rows.Count, 1).End(xlUp).Row
RowsB = Cells(Rows.Count, 2).End(xlUp).Row
RowsC = Cells(Rows.Count, 3).End(xlUp).Row

Set MyCol1 = New Collection
Set MyCol2 = New Collection
Set MyCol3 = New Collection

For i = 1 To RowsA
MyCol1.Add Cells(i, 1)

Next For i = 1 To RowsB
MyCol2.Add Cells(i, 2)
Next

For i = 1 To RowsC
MyCol3.Add Cells(i, 3)
Next
Rw = 1
col = 4
With ActiveSheet

For Each j In MyCol1
For Each k In MyCol2
For Each l In MyCol3

If Rw = 65536 And col < 257 Then
Rw = 1
col = col + 1
If col = 257 Then
Exit Sub
Else
'Exit Sub
End If
.Cells(Rw, col) = j & k & l
Rw = Rw + 1

Next l
Next k
Next j
End With

Set MyCol1 = Nothing
Set MyCol2 = Nothing
Set MyCol3 = Nothing

Application.ScreenUpdating = True
Application.Calculation = xlCalculationAutomatic
End Sub

To use this code:
1. Open Excel
2. Open VBA editor (ALT+F11)
3. Insert new module
4. Paste code.
5. Run Macro

Calculate speed of web site connection

This macro is a small example how to measure the time a webpage is loaded:

Sub CalculateSpeed()
Dim sch As Object
Dim xmlUrl As String
Dim fName As String
Dim ws1 As Worksheet
Dim counter As Long, k As Long
Set ws1 = ActiveSheet ' Result sheet ("sheet1")
counter = InputBox("How many times loading?")
k = 2
fName = "http://www.YOURWEBSITE.com" ' internet adres
Cells.ClearContents
ws1.[A1:C1] = Array("StartTime", "EndTime", "TotalTime")
ws1.[A1:C1].Font.Bold = True 'Exit Sub
For i = 1 To counter
Set sch = CreateObject("InternetExplorer.Application")
sch.Navigate fName

'Optional to make visible explorer
sch.Visible = True
strtime = Now()

'Wait until page is loaded
Do While sch.Busy
DoEvents
Loop
endTime = Now()
totTim = Left(Right(endTime, 5), 2) - Left(Right(strtime, 5), 2)
ws1.Cells(k, 1) = Format(strtime, "hh:mm.ss")
ws1.Cells(k, 2) = Format(endTime, "hh:mm.ss")
ws1.Cells(k, 3) = totTim
k = k + 1
sch.Quit
Next i
Set sch = Nothing
End Sub

To use this code:
1. Open Excel
2. Open VBA editor (ALT+F11)
3. Insert new module
4. Paste code.
5. Run Macro

nr of Test cases for a certain test depth level

Here a function in MS Excel. Though it is for no use at all, at least you don't need to pick up the book TMap and go to the page where a table is shown.

=IF(B1=0,0,IF(B2<=B1,2^B2,IF(B1=1,2^B1,CHOOSE(B1-1,2^B1+SIGN(B1-1.5)*(B2-3+B1)-2,(B1-1)*B2,(COMBIN(B2-1,B1-2))+(B1-2)*(B2),((COMBIN(B2-1,B1-2)+COMBIN(B2-1,(B1-1)-2)))+(B1-(B1-2))*(B2),((COMBIN(B2-1,5-2)+COMBIN(B2-1,(5-1)-2)))+(5-(5-2))*(B2)+COMBIN(B2-1,B1-2),((COMBIN(B2-1,5-2)+COMBIN(B2-1,(5-1)-2)))+(5-(5-2))*(B2)+COMBIN(B2-1,6-2)+COMBIN(B2-1,B1-2),((COMBIN(B2-1,5-2)+COMBIN(B2-1,(5-1)-2)))+(5-(5-2))*(B2)+COMBIN(B2-1,6-2)+COMBIN(B2-1,7-2)+COMBIN(B2-1,B1-2),2^B1))))

To use this function: Enter:
1. Enter in B1 the number of deteminants (conditions)
2. Enter in B2 the test depth level
3. the formula in cell B3

Why re-test

Here another question I was asked recently.

Why do we have to re-test some test cases as they worked in the previous cycle?

Imagine you are buying a car. On Top-Gear you heard some very good critics about the car. And you go to the garage. Still you are not that foolish and ask for a test drive. During the ride you step on the accelerator, turn on the radio, open the window to hear the sound of the engine and you are almost convinced.

The sales manager is a very skilled person and tells you that there are more extra's you can choose of. And of course he fooled you and you also want the engine get tuned, a shining outflow and a DVD/navigation system.

After a month you are called that the care is ready and you can pick it up. Don't you use a new test drive to see that the tuning didn't disturb anything else, that everything you liked about the car is still the same?
I would. I would spare me some extra time for the test drive.

In short, you make a test drive when modifications are made to your car, why not perform a regression test on your system to see that everything you liked (no defects) is still working.

Why not start immediately with testing

A while ago I was asked why they couldn't start immediately with testing and have to think about conditions what to test.

I tried to explain it with finding a tree in the wood.

Imagine you are asked to find a tree with 20 branches of which one is 1.2 cm long. If you don't think how you are going to approach the trees you can walk towards the wood and from a distance of 100 meters you stand still. You investigate the trees based on the size of the branches. Soon you noticed certain logic in the growth of the trees. On the right front small trees are growing, at the back left large trees are growing. The number and size of branches are also separated on a similar basis. You don't walk into the wood as you will get lost, from closer distances all trees look like the same based on current conditions.

As you don't have the time or need to investigate further you answer the question positively and point that the tree should stand in the middle of all trees. Though you don't express you are not certain about this.

Isn’t this also what is asked when you have to test something, be positive sure if it works or not?

If you take the time to investigate further and take some other conditions like: kind of earth, season, kind of tree. You are able to search more directly. You are able to define the area you have to walk in the wood. As on yellow ground the trees are not growing that hard, due to the winter season the trees don't have leaves and since as you noticed that oaks had more trees around there it is more easier to decide and define you plan. You are now able to walk in a specific area and count the branches.

The chance that the deviation of your expectation is different from the result will be much smaller. You are able on a higher level of certainty that the tree is there or not.

So it could also bee with testing. If you start think about what conditions there are and might influence your expected result, take some time to think about this. You will be much certain on your advice then without doing this.

Perhaps this metaphor can help someone else also, as it helped explaining why to spend first more time on thinking and not actual testing.

A new year for projects, a new feeling for testing

When a new year is about to start all kind of new promises are made. When the year is actually started some of them are already broken. Still, the New Year gives the feeling everything will be done better for now on, or at least we will try to. It gives you the feeling you have the opportunity of a fresh start. And you have a whole year to manage this feeling.

This sounds very similar to some projects I did. Instead of a new year a new iteration was started. Promises, read action points, are made and followed up. Only somehow, the feeling of a fresh start is not there. Most of the time we keep looking backwards, remembering especially what others did otherwise making it impossible to fulfill our promises. This behavior made it harder to continue with a fresh sense.

While you are reading this you might think what does this have to do with testing. While I'm writing this I have the same thought. Still there is some feeling there is a relation. Writing this article might be the same as a project/iteration. It has a goal, it is already started, there is some feeling, and the structure is not clear yet as I don't know yet what to write exactly, and perhaps most of all: I'm not re-writing this post to make it a better post.

Every year we start at the end to think about what went good and what went wrong and what could be done better. You made decisions, accept the effects, take the risks and continue. That is also why I'm not re-writing this article, I accept the risk that no-one would read this or understand this. And I continue. Isn’t this also similar to the decisions which are taken during testing: you know that sometimes test cases are not good, you did not execute some test cases or you missed some functionality and raised an issue for this? You acknowledge the risk and continue. Continue with a new iteration.

As on the first day the structure becomes a bit clearer as you already know the risk you accepted, you defined some counter actions and you start embedding you promises. As you have to. You need to accomplish your goal.

My goal here is to make a posting as my initial goal was starting a blog. To maintain a blog I new to post on regular basis. And to post a article it has to make sense to the topic of this blog: Software Testing.

The structure here is getting much clearer. It started with a new year, new iteration. It tells about promises/action points, not looking backwards and continues to fulfill the goal. And the project is already running so no time for re-writing and accepting the risks. to me this sounds very similar to projects. The thing I missing here is the "feeling" thing.

A new year starts with the feeling of a fresh start. In projects we don't work with feelings. It should all be measurable so we can verify and validate. Expression of feelings can disturb the clear view of the goal, wrong decision could be made. Is it wrong to express you feelings? Sometimes it is. But who am I to decide. For this article I'm responsible for feelings, only this is my own feeling and as said, I accepted the risk. Is it wrong to express your intuition in a project? Depends on the role you have. The project manager or test manager should decide what to do with it.

Only you are responsible when and how you express your feelings. This becomes a part of the communication skills and moments. So if you have a feeling that can help to achieve the fulfillment of your action points then express them on a correct moment in time. As in the New Year it is just before the year starts. Similar to review moments of projects. And also during the project for example during team meetings, stand up meetings or on initial basis with your project manager. While expressing this also try to explain what you can do to help making this feeling measurable and listen to the manager, as if he makes a decision not to continue with it. Just let it go and keep on focusing on the project. Keep you mind fresh as this is necessary for a fresh start.

Seems that I almost finished this article as I explained my goal, made a small translation towards testing have the feeling that I said most of the things I wanted to explain for now and have a feeling that this will the beginning of a fresh start for this year maintaining my goal: publishing on regular basis in my blog expressing a feeling on this moment.

Towards testing this could be translated in: Don't always look back, communicate also your feelings and try to help to emphasize that a new iteration can be a fresh start as a new year does for you.