Showing posts with label Testing Schools. Show all posts
Showing posts with label Testing Schools. Show all posts

Friday, May 7, 2010

What you can learn from your kids and yourself?

It is so obvious, I knew it and although I search for someone to blame, it is my mistake.
Sure, how easy it is to accuse my little daughter who sat behind my PC playing some games on it. How adorable she was when she laughed and called me for help. How priceless her smile was when she was proud to be allowed playing on my PC.

It doesn't mind at all. It is broke and I didn't do it. So I am not to blame or am I?

Here is the situation:
I have a external disk drive and I used that one as back up facility. So far so good, why not use an additional drive for backup instead those disks. (I have still some 3,5 inch disks with stuff on it and those cannot be used for backup anymore) It seemed reasonable to use an external HD for backup facility.

That hard drive was standing on my tower, and as it is a tiny one it felt down already quite a few times and afterwards it worked every time. Amazing how solid that Freecom HD was. Until last weekend. It felt, and no one told me. And today after some times I needed that nice solid backup facility. Unfortunately, it was not approachable anymore.

An unapproachable device is nothing new. Sometime USB -ports are just mixed up or deactivated due to some stupid installation etc. As I needed the HD I did some checks.
The initial check was turning on the power. He, that is strange, the power was already on, normally the HD would be recognized. Hmmm. I turned the device on and off. no result

I checked the USB cable, I tried another port. I restarted the PC. Checked the USB settings. Shouted a bit loud just to express some kind of frustration. I checked again the HD if the blue lights was glowing. I listened if the HD was running while I restarted it (turn of and turn on)
I actually checked if it was recognized in the "remove safely-dialog". I kept refreshing my explored window. Did this using THE F5 button, The combination with the SHIFT+F5 button. I used the refresh-option in the explorer menu. I even tried the F9 button as in MS Excel this refresh also sometimes the results.

I stood up and connected that external HD to the PC of my daughter. Tried all USB ports on that PC as well. I actually carried the HD to the PC of my son. All with same results.

While I was walking downstairs my daughter asked me about the status of her new PC. And there something happened, I found another victim. I reminded about the situation finding it strange that the HD was lying on the ground. Only didn't suspect anything at that moment.

While I was walking downstairs my daughter asked me about the status of her new PC. And there something happened, I found another victim. I reminded about the situation finding it strange that the HD was laying on the ground. Only didn't suspect anything at that moment.

I asked her if she remembered if the HD felt down from my PC. She looked with glazy eyes wondering what I meant. I asked her again if that grey little box felt on the ground, and she remembered that. Somehow I felt even more frustrated, it came actually in my mind that to tell her I would work on her PC until cure was found. Only, which person can be angry on her little princess. not me, I went downstairs, informed my wife about the situations, made some strange sound to express my frustration and went upstairs back to the PC.

That gray little box, when I shake it I hear some noise. It sounds like something very tiny was broken. As a skilled engineer I tried a way to open the box. OK, I admit, I'm not skilled in those grey little boxes. Somehow I believe I can become skilled opening the item when it is broken. Also when it is not broken I hope I learn.

Looking back at that gray box no screws visible. I questioned myself if it was worth the effort to open the box using brute force? This time I decided not to open the box. Instead I calculated and argument the damage.
I look at the damages in terms of:
- what is lost?
- is losing a lost?
- time taken to collect,
- times of usage,
- emotional value,
- options to recover (from other) resources,
- time it would take to recover,
- time when information was needed,
- what have I done to prevent loss
- what were my intentions to prevent loss
- what did I not do

Evaluating the process
Looking back and thinking what I have learned or could have learned I come up with this blog and the following identifications in the process
- I found an defect
- I made sure it was broken
- I investigated it in several ways
a. Functional
i. What was behaviour
ii. What should behaviour be
iii. Was the drive approachable
b. Technical
i. Was it turned on
ii. Was there power available
iii. Was the power-cable plugged in
iv. Was the power source connected?
c. Hardware
i. Cables working
ii. Light working
iii. Does it make sound
iv. Can it be opened
v. What effort must be used to open it
d. Connections
i. Was there hardware recognition
ii. Did behaviour occur on all other USB-ports
e. Reproducible
i. Own system
ii. Other systems
f. Information
i. What was on it
ii. What is gone
iii. Were are some pieces stored
iv. How old was data
v. What was the value
g. History
i. What did I remember
ii. What did I do with data
- I checked if others were to blame
- I noticed some strange behaviour as result of my fury/frustration
- I found someone only didn’t want to blame
- I noticed that blaming is not solving the problem
- I searched for arguments not start blaming
- I try to evaluate the loss
- I evaluate and wanted to learn from it

Lessons Learned
When looking back at this situation you might noticed that there are some similarities between this situation and testing.
How often did you:
- face issues and became frustrated about it?
- looked at a system in different ways?
- spend time to find the one to blame?
- did you try to look at behaviour of others and yourself?
- did you learn from that situation?
- did you aimed for value instead of spending time for too detailed proof?

When I look back at that situation I see I didn't stick to problem pointing, even problem solving was not the issue. I valued the situation and took actions. This time it was apologizing to my daughter, removing the external HD from my PC to avoid other damage and check some old other storages and made sure that they are approachable. Finally I scheduled some time to check for other hardware and decided it could wait for a month.

I still have the image of her face sitting proudly behind my PC smiling at me. That is priceless. In other terms also valuable. I would say, that is even valuable then the damage/loss.

A valuable lesson I want to give to the reader: Don't take things for granted, if something happened; look what you learn from it and how you can learn from it.

Friday, April 9, 2010

Value of certificate or understanding

Today there was a great happening at our family. After weeks of training, my son and daughter were invited to take their exam for karate.
Almost more then half year ago they started to attend this course on weekly basis. Now and then they are showing the moves they learned in the lessons. They not only paying attention to the moves, also to the words, terms and how they should be used.

They are aware that they are preparing for the next grade. Last time it was the white turtle, this time it was the white cranes. Somehow I believe that they understand exactly the meaning of these grades. They know exactly in which order the grades can be obtained. They also are aware of the skills they need to know and able to show.

They took the test and they succeeded. I am proud on my kids as they persisted, listened and behaved in the dojo. They had respect for the teachers and other participants. At the end every one got a badge, a certificate, a sign on their karate passport and an invitation to attend a meeting with a great master. They also got respect from the teacher and the judges.

It seems so obvious that all those items were important like certificate, badge etc. Perhaps it is. Somehow the certificate of my son got lost. It made me proud to see that he did not complain, or else. He felt a bit sorry and still went back to his place. He accepted it as the value of respect was more worth then the certificate, knowing that the teacher told him being a white crane was more valuable. The certificate was just a paper.

This made me think, he might be right. I’m sure he is right. A certificate is just a paper; the respect he earned made him proud and made him to continue. The respect of the teacher made him know that he is allowed to show more skills to others which he was not yet allowed doing.

To me a great lesson I see here is that we are tending to look at our old heroes what they achieved and accept their sounds that we needs certificates. Perhaps we also have to watch out for our young, new heroes and bring everything back in perspective.

After al, a good day that as I learned from my children.

Saturday, October 31, 2009

Growing bananas

This week I attended a presentation Exploratory Test Automation:Investment Modeling as an Example given by Cem Kaner in the Netherlands as part of the Cem Kaner week

One of the statements he made is avoid commodity. This triggered me to reflect on how I see software testing.

To my opinion Cem Kaner tried to explain to use why commodity is good for those who feel happy to be a tester who have and can use standardized skills and knowledge. Who accepting to be replaced easily and who’s expertise can be cheaply outsourced. Those testers are as valuable for the client as all other testers. The other side is that there are testers who are willing to become better; they want to become valuable for the client. The client experiences the value. I think for this you have to express yourselves, keep learning, and adapting to the environment and work hard for it.

What does this have to do with growing bananas?
As C. Kaner mentioned about commodities:
There are green bananas
and ripe bananas
and rotten bananas
and big bananas
and little bananas.
But by and large,
a banana is a banana.


If you look at the phrase above and replace "bananas" with "testers" then testers are in general commodity testers. Unless they choose not to be a commodity tester. If the choice is made then you have to become aware of yourselves, what do you value?

As with a banana, the shell can be used, only the inside is eaten. Based on that taste the banana is valued.

This made me think a bit further. In general if people are thinking about bananas they visualize the banana including the shell and sometimes with a small piece of the inner stuff visible. People are visualizing a banana eatable when the shell is removed. There is more to imagine. the structure of the inside of the banana is also a result of the outside structure, how it is grown, how fast, with which means and under which conditions.

The same can be the situation for testers, they might be thought under certain conditions. This might not definitely lead to wrong results. They remain testers. I can imagine that for certain test certification might be useful to gain some basic fundamentals about testing. It might be right, it might be wrong. At least a direction can be defined. It is up to the tester if he/she becomes a commodity tester or able to add other specific value to the client. There are more roads which leads to Rome.

If testers are tending to become commodity testers and they might be identified as bananas. As said, bananas shouldn't be judged and testers also not; just because their believe in methods and approaches is different. I think it counts more what a tester is doing to become of more specific value.

Sunday, February 22, 2009

Understanding the problem: the skilled helper

How often are we offering solutions to help people based on our experience? Somehow we are trained to identify possible problems and judging them against our best-practices. Because we are always in some kind of time pressure we tending to help claiming our approach is proven and has some successes.

For example: we are asked to structure the test process and our best practice is the TMap approach. Instead of identifying the actual problems we are defining the test process based on their phases and to see what context we have to work in we perform a so called Product Risk Analysis (PRA).

For some time I'm trying to understand the Context-Driven-Testing (CDT) approach. I think the main idea here is to understand the context first before you come with solutions.

To understand the context you first have to listen. This reminded me about a book I read some years ago: The Skilled Helper: A Systematic Approach to Effective Helping by G. Egan.

I think this approach fits well in our profession also. Aren't we also "helpers"?

Egan's approach consists of three stages which might prevent us jumping into conclusions/solutions. Every stage consists of three steps with continuous evaluation (E).

Stage 1 - The present scenario: Help clients identify, explore, and clarify their problem situations and unused opportunities.




Stage 2 - The Preferred Scenario: Help clients develop goals, objectives or agendas based on an action oriented understanding of the problem situation



Stage 3 - Formulating Strategies and Plans: Help clients develop action strategies for accomplishing goals, that is, for getting from the current to the preferred scenario


I think these stages and steps can be combined with Heuristic Test Strategy Model can help define the correct context and choosing the best strategies and plans for that certain context.

For more information about Context Driven Testing see:
The Seven Basic Principles of the Context-Driven School
Weblogs:
James Bach
Michael Bolton
Cem Kaner

For more information about Egan's approach you also might check: Introduction to ‘The Skilled Helper’ A Systematic Approach to Helping

Monday, November 10, 2008

"Schools of testing" are evolving

The first time I read about "schools of testing" I posted already an comment about it
Wednesday, February 20th 2008: Schools of testing, can you decide?
Sunday, February 24th 2008: Testing Schools and Organizational Schools

To understand this topic you might view the presentation of Bret Pettichord: Schools of Software Testing

Currently the discussion is still going on about this topic on several weblogs:
Cem Kaner:
Friday, December 22nd, 2006: Schools of software testing

Paul Gerrard:
Thursday, February 21st 2008: School's Out!
Monday, February 25th 2008: Clients, Contexts and Schools
Tuesday, November 4th 2008, Schools of Testing - Go Away
Thursday November 6th 2008: Labels, Stereotypes and Schools
Friday, November 7 th2008: I'm Not Ready for School... Yet

James Bach:
Wednesday, February 20th 2008: The Gerrard School of Testing
Wednesday, November 5th 2008 : Schools of Testing… Here to Stay.

Michael Bolton:
Thursday, November 06th, 2008: Schools can go away... when we all think alike
Monday, November 10th 2008

In very general terms these articles are about the need for schools for testing. Do they exist? Do we need them? Or can we solve it using the correct heuristics and axioms?

In my posting related to organizational schools I already mentioned a history about these schools. These schools also evolved over time. We kept learning and adapting the current situation and found new approaches. This didn't meant that the other approach was wrong or useless. I think there was another situation which needed another solution.

In history we see more of these examples. You can take examples from psychology (History of psychology), sociology (History of sociology) and also political List: forms of governments.

So my thought is that we cannot avoid "schools of testing". It is in human nature to create groups.
From Wikipedia:
Group:
In sociology, a group can be defined as two or more humans that interact with one another, accept expectations and obligations as members of the group, and share a common identity

The main reason of creation of groups is the need for interaction and share a common identity.
I think we as testers didn't do anything else over the last decades. We also want to interact with other people. Not only people part from our own group. Also communicate with people from other groups like developers, managers, users etc.

As those other groups have also their own behavior; testers adapted their approach towards those groups based on their needs.

In some organizations an Quality approach is more appropriate then an Agile approach.
To support these approaches we have methods to support them like: TMap, TestFrame, ISTQB and SCRUM.

This raises the following question to me: Are we capable to support an organization properly when we are experts in one of these methods and the need is for another "school approach"?

This made me think about were to position the Context Driven approach. As far as I understand they look at the context which is best suitable for the customer within defined boundaries.

As it might be impossible to be an expert in all methods; thinking within the good context might be an answer. The organization might have chosen for a method. Because this method is carried by several people, read group, they all want to make it a success. Using this as context you would be able to be successful although you are not an expert in Agile or TMap or that method. You are able to adapt yourselves to the need of the organization. Perhaps I'm wrong here.

To get this picture more clear for me I hope I will meet next Wednesday on EuroStar Michael Bolton who might explain it to me.

Saturday, March 1, 2008

Does the testing school fits the organization?

Can Approaches support organizations?
Here is another posting related to testing schools. In my previous posts I started to explore my thoughts if I belong to a school. Schools of testing, can you decide?

And continued to think if there is some dependency related to organizations: Testing Schools and Organizational Schools

As Paul Gerrard there is a lively discussion going on towards this topic Clients, Contexts and Schools

Today, on this rainy and windy day, I continued thinking about it. Though, I still have the feeling that the quest for answers is not over yet. (Probably there are no good answers, instead solutions that might work.)

Over the years I saw different people using methods/approach what they knew the best and sometimes forcing organizations to adapt their processes so their method might work. I also saw people adapting their method/approach towards the processes of the organization.

Both approaches might lead to the solution the organization was waiting for. And both approaches create new risks for the organizations. Some people say that risks can be accepted based on the change of failure in relations with the cost of that failure. Less people are asking why to accept those risks. To give an answer to that question I think it is important why organizations initial choose for a certain approach.

I could try to search for answers why to choose for a certain school. And try to start discussions about it. Instead, I try to think out side the box and find out how both ways can be good, how schools can help, how solutions can be provided to organizations.

How would my "box" look like?
To create a picture of the "box" you might ask the following questions:

  1. Does the organization have other goals to improve the testing process and increase quality of the software?
  2. Does the organization have the means to get to those sources which support these goals?
  3. What is the life cycle of these goals?
  4. Can the tester based on his/her skills and experience commit to these goals?
  5. Is the tester able to adapt their approach/method to these goals on continues basis?
  6. Are tester and organization able to communicate on equal basis?
  7. What is the life cycle of the tester in the project?

Imagine how that box would look like if the answers were like:
Example:

  1. The organization is not able to change other processes like development on short time. They also using a test method and there entry criteria to dictate that process.
  2. The organization has the means like time, money, though the market is not providing the right people within time.
  3. Improving test process is long term goal, extend the project life cycle. Improving development process for documentation is short term goal, only should extend over other projects. Deliverance of high quality software is explicitly needed for this project.
  4. The tester they found is able to meet these goals under restriction. This means that the tester doesn't have experience with defining strategies based on the several schools. Though he/she is well skilled using on test method like TMap.
  5. The tester is not able to change his approach as he is well trained on one method.
  6. Based on organizational hierarchy tester didn't get full commitment.
  7. As the market for experience testers is small the tester will attend the project till the end.

Now, close your eyes and investigate the feeling these answers are giving you. Now open your eyes and try to answer the same questions no under best circumstances. Close your eyes again and you might notice a different feeling.


Creating borders
Feelings can lead you into a good direction. Though, it is hard to translate them into risks. To identify risks you need borders. I always try to find the borders of a method. This helps me when a method can be used successfully or when a potential risk might rise. Therefore it is good to have those testing schools be defined. This help to define the borders of your picture. And give you information when you are crossing that border. If you cross the border then this is a sign that a school related approach doesn't fit the organization. And reaching the goals might come into danger.

As organizations are dynamic, testers also should be. I think there is an organization for every school. Only a school might not fit the organization. I don't think that it makes you a less good tester if you belong to one school or a better tester if you know about all the schools. It might help to give the organization an usable solution they need if you have knowledge about them.

Conclusion
A tester should be aware of their skills, be honest towards the organization about their skills. It is not wrong to belong to one school. It might help to know about the "Schools of Testing" and their approach and vision. Be aware that good testing is not a purpose, a good solution should be. And you should help the organization to decide that it is and was a good solution.

Sunday, February 24, 2008

Testing Schools and Organizational Schools

In the last few days an interesting story was started by Paul Gerrard and James Bach as I mentioned in my previous post: Schools of testing, can you decide? The key in their story is the term Axioms. Can Axioms be defined, used and maintained to help us testers? Do we need Axioms? Can we live without Axioms? Or as Paul Gerrard mentioned in one of the comments: Is Axiom the right word?

Paul Gerrard's replied on both postings with a next posting: Schools Out!

With those articles in mind and their comments on user input I thought about it for this weekend. Somehow, I couldn't get it out of my mind. As was I thinking I'm tending to the Context-Driven school as explained in my previous post. Somehow Paul Gerrard's post makes a lot of sense. It makes sense to let us think about. Or even better, force us to think about.

To understand it all better I tried to paint a picture about it. To understand the object to paint I did a quick search on the internet and found these besides other information these sources about the Schools of testing.

Presentation of Bret Pettichord: Schools of Software Testing these schools are mentioned:

  • Analytic School: sees testing as rigorous and technical with many proponents in academia;
  • Standard School: sees testing as a way to measure progress with emphasis on cost and repeatable standards;
  • Quality School: emphasizes process, policing developers and acting as the gatekeeper;
  • Context-Driven School: emphasizes people, seeking bugs that stakeholders care about;
  • Agile School: uses testing to prove that development is complete; emphasizes automated testing;

On the Blog of Cem Kaner: Schools of software testing these schools are mentioned:

  • Factory school: emphasis on reduction of testing tasks to routines that can be automated or delegated to cheap labor;
  • Control school: emphasis on standards and processes that enforce or rely heavily on standards;
  • Test-driven school: emphasis on code-focused testing by programmers;
  • Analytical school: emphasis on analytical methods for assessing the quality of the software, including improvement of testability by improved precision of specifications and many types of modeling;
  • Context-drive school: emphasis on adapting to the circumstances under which the product is developed and used;

They already presented the differences between the schools. Therefore I shall not continue in my own view of schools. What could be interesting is the similarity of these schools. They reflect some timeframe of human thinking and approaching the world.


Something similar also occurred in organizational thinking. In Organization theory, a strategic approach, chapter 2 by Narayanan & Nath they mentioning 3 types of schools:

  1. Classical theorists
  2. Human relations school
  3. Early modernists

Short description of the 3 classical theorist schools: Short description of the 2 Human relations schools:
Short description of the 3 Early modernists schools:

To me it seems that history is repeating in small and much quicker in the Information Technology industry. These schools were defined over the last century while our schools evolve in the last few decades. The challenge might be now how to make our schools fit in the Organizational schools. Here I make the assumption that Organization still tending to one of these schools.

To make testing fit and also work in those difference organizations depends strongly on the skills and experience of the tester. As Testing is getting Global and our occupation has new testers and experience testers it would help that we speak about the same thing. And also be able to explain it to the organization we work for.


In this I see at least 2 levels of communication. One is based how we communicate within our community. This can be done by explaining the principles of our schools. And try to work according to it.


Another level of communicating is making the organization understand what we are doing. This should be translated to the "Organizational School" the organization is based on. To translate we have to explain how testing is helping the organization and what we meant with it. If we are able to this we might be able to get the best out of our schools. I think using Axioms can help to explain the organization what we are doing for them and what we mean with them. Picking the Axiom can be depending on the school we tending to.


Perhaps there is some relation to Law's, we have different kind of laws, they all are captured in the book of laws. Only they apply only to a certain area. Those laws are made to communicate to each other and to make sure we are talking about the same.


To write the book of law's related to software testing would be wrong to do. At least now as we are working in a dynamic environment this needs some kind of flexibility. Though, a book or list of Axioms might help to explain to others what we mean with certain terms and how they can help the organization.


Coming back to my initial questions:

Can Axioms be defined, used and maintained to help us testers? We can define them and use them. Only maintenance would be hard. As who should maintain them.

Do we need Axioms? I think it depends on the skill and experience level of the testers and the understanding of the organization of our occupation.

Can we live without Axioms? I don't think so as there are still projects failing based on commitment of organizations towards obtaining their goal of quality understanding and related to that their undrstanding of the need for us tester's.

Is Axiom the right word? I think it is a better word then Law.

Wednesday, February 20, 2008

Schools of testing, can you decide?

Today I noticed a posting of James Bach on his blog called The Gerrard School of Testing

In that article he discusses the axioms Paul Gerrard posted on The 12 Axioms of Testing.
James also mentioning the context-driven school and her The Seven Basic Principles of the Context-Driven School

As Dutch is my native language I first had to find out what axiom means. According to Wikipedia, Axiom it means the following: "In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be self-evident. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths."

And this made me think about what school I think I belong to. When starting in the software testing business I learned about one test method. And what that method is saying I took for granted. I assumed it as the initial truth. During practicing I noticed that a method on its own cannot take for granted as it depends on the situation. And sometimes situations seem to look-a-like. Practices from previous projects turned out not completely covering the situation I needed them. They could be best practices, though they need to be altered into new practices.

In all cases the Human Factor was playing a huge role in success of implementing those practices. And beside this Human Factor, also the choice of the organization for development method made a difference. As this lead to the way they intended to communicate in the project as by iterations, increments, documents, delivery moments etc. And what was important to be delivered. In some cases deliverance of a product was a goal in it selves. As some functionality was removed and the initial problem which lead to this development was just partially solved.

This made me think that deliverance of a solution for the problem should be the goal and not deliverance of the product it selves. Though this depends on the situation I was into.

Writing this all down here, I tending to think I could belong to the Context-Driven school, as the principles I believe in fit more in the 7 principles of them. This doesn't make the axioms of Paul Gerrard obsolete. Only would it be short minded to say that those axioms are more the beginning of a vocabulary where instead of explaining the meaning of them the way to get there is explained? That those axioms are communication rules where, what we are talking about?

In the last case for some organizations it would help to talk this language. Though, I'm more tending to say that it depends of the context. Perhaps there are situations where other axioms also work within that organization or project.

Though I'm tending to Context-Driven, as it also supports my thoughts about other articles related to Open System Thinking on my blog, I need to learn more to say that those Axioms are not useful for me.

Cem Kaner made a presentation available related to Context-Driven School which also might worth to take a look at.

[Jeroen: Added on 2-23-2008] Paul Gerrard made another posting Schools Out!. This is worth looking at. It might help us understand how to look at Axioms in respect to Context-Driven School.