Changing roads to follow: start exploring

A new day started for me like almost every day starts at this time of the year. The sun is rising
while I drove in my car with music on the radio. I turned on the navigation system and selected a destination from my Favourites called “Work”. You might wonder why is work my favourite, well, at work, I’m involved with software testing and that is one of my favourite things to do.

Every day I follow the same route, actually I don’t need to use my navigation tool as I know where I’m going and which other options there are. Somehow I got used to it getting information which is sometimes valuable for me under certain conditions: the expected time of arrival. That information is also just valuable for a short period. On arrival only the arrival time remains and sometimes arguments for delay.

While driving along the route peeking at the navigation tool what the ETA could be. Also at my
dashboard of the car which is telling me that I’m not driving the maximum allowed speed. Triggered by this information I look with different eyes to the traffic in front of me. Although, different? The only observation I made at that moment was the same as I do in previous days following the same route. I confirmed what I already now: at this time the chance becoming part of traffic jams is obvious. So why bother, just enter the queue and lower your speed and accept
the conditions. Why bother for other information.

This day could be same as any other day. Following the route you already known, look at predefined” behaviour and at the end of the trip: report for duty. Only, this day was not the same as others. I observed that the traffic jam started earlier on the route then occasionally. At that moment I consulted my mobile app and got information about the length of the traffic jam, which was exceptional. I could accept the expected delay and use my navigation tool to monitor the ETA. The chance it would change beyond the boundary of 9 o’clock which would force me to escalate.

I could do what I supposed to do; follow a predefined path and collect information I already
could know. No new information collecting besides there was some disturbance which could cause delay. Making the comparison with scripted testing. Only collecting information about a certain path in the system (landscape) neglecting there are other ways to fulfil my trip. The obvious checks can be made:
- traffic jam = check
- delay within boundaries = Issue (assumption: queue is to long compared to speed and distance)
- option to enter the queue = check
- predefined route accessible = check
- predicted delay = actual delay = Issue (probably)
- accept delay = check
- predefined route followed = check

Again: following this route will provide me information about the accessibility of the route and the time it cost. It doesn’t provide me more information about possible routes which can be followed.

This day was different; I decided to take another route. I already had some information about one route which threatened the ETA: The Traffic Jam on the High Way. I changed my route. At first my navigation system told be to turn around and follow the initial route and based on this info calculating a new ETA. It took some denial of turn-message to get a new route to follow. Fortunately I new a bit of the area.

It seems like ignoring the original route. I see it more as finding a new way to reach my goal.
Immediately I noticed my new ETA was not increasing. It stayed as predicted. This can be translated that the new way to follow was not used at that point by others creating delay.
I cheered too early. Just after a while I noticed another traffic jam. This meant that other drivers
had made a similar observation. Based on my early experience I valued that this route would not bring me the expected result, being early, on time. Instead of adding the queue here I challenged myself by choosing other paths. This time I new just a bibt about the environment. I accepted that decisions I would made now need more information then just experience. It need focussed observations.

I still used my navigator in combination with the environment and my experience. As my
navigator tried to push me back on the high way I tried to ignore it and follow the road signs. A new information source was added to my journey. Just after a few minutes I relied on that new source of information, road signs in combination with small knowledge of the environment I followed and made a short stop. I did not feel good to go this direction.

My feeling and understanding about North, South, West and East I was travelling the correct
way, though I was forced to got directed to the road with the initial traffic jam. I made a bold step, ignore tools, ignore road signs with directions, I used my understanding of the position I needed to go to and the position I was at. At this moment I gathered new information: following this route could bring me back using another path.

I think it was this moment I got aware what I was doing. I was touring around, gathering all kinds
of information which normally would neglected. This seems to me the strength of exploratory testing, reject predefined paths, following your own, while doing reflecting the information you can collect.

I accepted that I can make decisions how to follow my way to destination point. I collected some
interesting information continuing.

- I came again on a road I know. It was also crowded by slow speed queued cars. The chance was that this queue caused the 2nd traffic jam I avoided. My mobile app told me that this queue was also huge.
- based on this information I choose another road combined with the position of the sun. The
ETA was still beyond borders. I saw a detour information board. I neglected it as it seems there might be other ways too. I interpreted it as a detour for other routes.
- A few kilometres ahead I saw traffic signs with places on it, this helped me define another road
which seemed to be more valuable while the navigator was telling me different. Somehow I could not rely on that tool as it wanted to direct me in opposite direction I was heading to.
- While driving I noticed I made some wrong decisions, followed the turn about by 180 degrees.
- I passed another detour which can cause delay
- I noticed it seemed I was lost in space and focussed on different ways, no longer the primary goal to get to the destination point, instead getting back on track again.
- trusting the road signs no longer heading for one known place I drove to a direction where any
place in the direction of my goal. I ignored feeling of being lost. I accepted there are multiple ways to get to destination as I was still in the right area.
- I came closer and got stopped by traffic lights. A new source of information normally neglected
by certain context. I placed it in future context. New knowledge was gained for future tours in this direction. I learned something new about areas.
- Finally I entered the town from a different view and could follow the last kilometres of the original tour. I did arrived within allowed time and learn more then I expected when I started

Lessons learned:
- Following pre-defined routes can make you blind for other information
- Starting to explore you need some bravery and embrace uncertainty
- Coping with uncertainty you need moments to defocus and to focus
- It can help if you don’t value information immediately, try to find the context and
challenge that context against another
- Exploration can bring you different information on different levels; perhaps it is not bad
and not good, if might even not useful after all
- Context can change; be aware and take time to allow it or not
- There is no wrong path, all paths provide new insight, it depends how to value it and
use it. Perhaps not immediately valuable, it might be in the future
- The meaning of situations causing delay change over time
- When exploring you can use more skills in different areas. Trust on yourselves and continue.
- Continuing parts of the original route is not falling back to it; it is addition of your
exploration.
- Even in daily live there are examples which can help you to understand exploring.

This day started good, normally I would complain about the traffic jams, now I got excited by the
lessons learned. I did something which was valuable for me. I was in control and learned. I made the decisions instead the predefined path in some kind of scripted route.

No space for innovation?

This time a smaller note then usual. It came to my mind that in times of trouble we stick to what
we know. In history there were other cases when the world was in trouble leaders gave trust to those who got ideas which might fail or might succeed. For instance the war machine during the WWII provided in a very short time different innovations. (Technology during World WarII)

Perhaps the reason lies with the lack of procedures, methods and controlling processes.
After the war improvements were made which seemed to be successful for that time. People still using those methods and methodologies like PRINCE2, ITIL, BISL, TMAP, Six Sigma, etc. It helped managers to give them a feeling being in control.

Sometimes they still work for them. I’m wondering if there is still room for other approaches then people are looking for certainty and good practices are not yet given it to them. Is there still space in projects to approach uncertainty with Agile approaches? Can we SCRUM and accept the skills of dealing with that uncertainty and adapt earlier to get better results? Is a context driven approach in software testing explainable when managers are focussing on methods which are
know to them, instead of learning and adapting to the actual need?

I might be wrong, implementing methods can be useful, mostly I saw implementations of it where it became an objective on its own and no longer for adding value to business. Somehow I have the feeling that in times of trouble like we are now as in the economic crisis people tending to get proof that the method is working for them and make decisions to reveal that is not delivering the value by blaming it after all on the economic situation.

Is there space to use approaches like Agile approaches or Rapid Software Testing? Are there managers who dare to face uncertainty and learn from it, become stronger and more skilled? Search innovation in the way of thinking and working?

I hope so, as technology is still changing which mean that the way we have to face our new world might be different as we know. Although I’m uncertain about that too. :-) To maintain innovative we have to provide space for those new ideas also. Let us give and get some space for new ideas and try-outs

It is released! Book: How to reduce cost of software testing

This week this great book is released. (sept 15th 2011)

How to Reduce the Cost of Software Testing [Hardcover]

Not just another book
For me it is not just another book related to software testing. The editors Matthew Heusser and Govind Kulkarni gave me the opportunity to cooperate in their journey.

I think it is about a year ago an interesting thread started on Linkedin about cost of testing. This already made me more aware about this topic. There passed not much time Matt Heusser also contacted me as student of the “Miagi-Do School of Software Testing” and wrote me about Govind’s and his idea. He asked if I have some valuable contributions to make.

After explaining shortly to both that I was in the middle of some interesting exercise. Based on that exercise I might have some valuable contribution.

My short exercise
At that Time where I helped gaining information how we could help the business site of the organization by delivering software on defined dates while accepting in some cases functionality was not yet mature.
I observed that there was another need of information. I also noticed that which decision management made, it has impact on the test process.

When impact is involved, there are risks involved and to get more information about that risk you need to perform some activities. You can also introduce a risk yourselves: perhaps by not performing certain activities.

My idea is mainly based on controlling the test process on cost level by collecting information about the risks, the business need and how it work through the testing process. If risks are known you can start defining a strategy about how to continue: are you remain testing in the current phase and the costs are on that project? Or is there an option to shuffle the cost to another moment in time? Does it result in extra testing resources and cost or can you actually benefit from the accepted risks by management.

A year passed by
I never had experience writing a book or make a contribution to one. I had the dream of doing so. And more then a year ago I had the opportunity to participate. Amazing how such a process is evolving. I had great support from other co-authors and reviewers. They made me help to shape my story I believe is valuable. As I saw my story grow, I also had the opportunity to read the other chapters in the book. This strengthens me to believe we were working on something big. A book with combined knowledge and diversity in visions.

And now it is there! A book with great stories, sharing visions written and shared by testers I respect. If you want to know more about my contribution you might buy the book. If you have questions or need more information or share your experience you can contact me by mail.

A day at Test Automation Day 2011

On June 23rd 2011 I was in the position to attend the Test Automation Day 2011 as an advantage since Squerist, the company I work for, was the founding partner of this event. In my profession I started with automated testing although I like to think more how test processes can contribute value to an organization I still have a weak spot for automated testing. This made me curious about what to expect.

I attended in the afternoon due to other obligations. This leaves me to the experiences of other people. I entered the exhibition area just before lunch and noticed the crowd entering the room. Normally I recognize some people from past conferences, now I saw new faces with one thing similar: passion for their profession.
I talked with a few of them and they heard new interesting stuff how certain tools might fit into their business. They got already some value back for attending. Others heard more or less the same story. Isn't it always this way.

I attended 3 keynotes: From Martin Gijssen (De kracht van open source testtools), to Mark Fewster (Experience Driven Test Automation) and Scott Barber
(Automating Performance Tests: Tips to Maximize Value and Minimize Effort)

Somehow I missed another presentation in the middle. instead I had a great talk with others.

What I remembered about the presentation was that Martin was able to speak about open source tools without making a judgment what we should do. In generally it depends, sometimes open source tools are good to use, sometimes not. Personally I expected more information how, when and the pitfalls instead focusing on a framework. Though some introduction was needed and if time is valuable you cannot tell the whole story. What left was the importance of a framework, a test architecture and key-word driven testing is still kept alive.

About Mark Fewster: I like this guy, If you sit far behind in the room and you don't have the full picture he has some similarity with David Letterman only in his best days. (hope he is not offended by this. I enjoyed listening and watching to him) With passion and wit he stood there convincing about the experiences he collected about test automation. Based on this he shared us his future. One of the things in his future was the maturity of tools supporting test techniques. I think he might be right, there will be coming more tools than ever.
I think another road in the future is the need for focus of tools on the human aspects.

So I think we have here 2 paths: 1 path of tools which will support more techniques and move towards the developer to build the scripts for testing and other tools which will support the "keyusers" to tell in what they want to do or did with testing.
What the future will bring, we will never know. At least he triggered me to look forward to his book in which he collected the experiences of others.

The last keynote was provided by Scott Barber, I never saw him before. Wow, he is an artist, how he sells his story. He got me all the way. Although it was mainly focused on performance testing, he sold me the idea that it is quite different then functional testing. More complex. And perhaps equally fun :-)
During the time he gave us 10 tips for free to focus on while setting up your performance test. I think they also are generally usable for all the test we perform

Top 10 performance test tips by Scott Barber on Twitter
10 data design
9 variance
8 object orientation
7 Iteration/agile
6 Error detection
5 Human validation
4 Model production
3 Reverse validation
2 Tool driven design
1 value first

For details about his tips, just contact him. I'm still looking forward for his presentation as the information was to much to write down. And he has some story to tell. (Afterwards I spoke with him and he is willing to tell you about his experiences)

Some of the eye-openers/lessons I remembered:
1. Performance testing is for developers, let them help you,
2. provide information about performance on continue basis, not only as a big bang
3. Think about the release management, test management and infrastructure before you start measuring performance
4. Also in performance testing, numbers doesn't say much. Perhaps start presenting you measurements with the happy faces and sad faces.
5. Although I was not directly involved with performance testing, in the past indirectly I learned some items and were involved with some performance issues too.


I think this conference was a good one, for a first time I think they can be proud of it. A lot of information was shared, good presentations (and some less) were given. They missed the short break after the 2 keynotes and between the "business cases". Now there was less room to share experiences of the presentations. As all conferences, you hear some old wine in new bags or what is it called. I strongly believe in the skill to learn from the information you get and read between the lines.
I had some good fun that day and was surprised. It triggered my thoughts and extended some perceptions/views and ideas.

Reflection of a day at DEWT

DEWT peer conference: A fact
On June 11th 2011 the first #DEWT peer conference was held. For passionate testers attended by passionate tester and challenged by the same testers. The intention of this day was to share information about topics we have chosen in a previous DEWT meeting with the understanding it interest us and might help us understanding better and become better testers.
Next to sharing information it was also an opportunity to practise some skills like presentation and teaching. Or what about sharing ideas to work on them.

The evening before
Actually, it started already the evening before. In an informal setting, more informal then on the 11th we sat down at the bar and immediately the spirit was already there. The spirit of supporting and challenging each other, tell about their experiences and how we might continue.

This was just at the beginning of the evening, there was much fun from sharing experience stories, judging the music, talking about artists and how lucky we are the have open minds able to learn what is testing all about.

The day it happened
At 9 o'clock sharp we started.....with waiting when the last persons would show up. And after 10 minutes the great happening was opened by Ruud Cox, appointed chairmen for the first part of the day. On a previous meeting of DEWT we decided to support this day with 2 chairmen (Also Jeanne Hofmans) to restrict our ideas and thoughts. Based on the same session we came up with the following program (except the lightning talks, those were defined during this day)

On todays program where the following topics:
§ Opening presentation on Artful Testing by Zeger van Hese
§ Transpection by Michael Bolton
§ Lightning talks by:
Jeroen Rosink: Testing Pyramid
Huib Schoots: The power of knowing nothing
Zeger van Hesse: Bader Meinhoff-phenomenon:
§ RST and SBTM in The Netherlands by Ray Oei
§ Credibility (the quality of being trusted and believed) introduction by Ruud Cox

Each performance had its own perspective and story, you had to be there if you had the chance.
I shall not recapitulate everything instead let me tell you some of the lessons I learned

Some Lessons Learned
When Zeger told about art and artist he made the relationship with testing. What I liked is that he sees testing as and art though we are not the artist. Testers can be seen more in the role of an art critic. And an art critic should know about all the variants of art.
Should he?
This triggered me thinking about the tester, should he also be aware about all the variants of testing? Perhaps at a certain moment. At least what he knows about testing must be told with confidence en compared to the truth.

I think if you keep shouting something is bad, that noise will no longer leave your room. If you tell the story and you are capable to make that story accepted then you gained reliability. This means you have to be able to explain in certain details what your test was all about....You have to be able to tell and explain the art of the software.

Another challenging topic was supported by Michael Bolton and was about transpection.

What I remember about the definition was Transpection: "An idea in head to explore which gives the person the opportunity to probe/play with the idea without influenced too much"

Valuable information about this topic can be found on:
Transpective Dialogs for Learning
by James Bach
Blog: Transpection and the Three Elements of Checking by Michel Bolton
Blog: Transpection and the Three Elements of Checking by Michael Bolton

He challenged us to use transpection to investigate the meaning of it. it made us think. Some investigated the internet to find more information, or examples. Together with Jean-Paul we did our own mind exploring to see how we would see the boundaries of transpection.

What I learned about transpection it is already done by persons like Plato...it is a good way to gain information or guide persons to learn/gain insights. Not everything is a transpection, pub talk can be rather not. It has a beginning and an ending although you never know which direction it goes. Though it starts with a main subject.

I think transpections can change over the time. With this I mean:
- you are the person who held the transpection and challenge the other
- you are the person who is challenged
- During the initial transpection, in which you are challenging your idea, you leave space for the other for a moment of transpection. perhaps you get it back later on?

Some questions I still have:
What is the option to step out of a transpection?
How can you step out without minimizing the result for the other?( Rude behaviour might distract and loose focus on the results)
Can the main subject be changed? How is this done/monitored?
When do you have a transpection and when did you loose the transpection?

These are some questions I have to look further and learn about myself.

The Lightning talks
The first talk was provided by Huib Schoots. He explained the idea of the power of knowing nothing. I think he is onto something. Though I know a bit about this :-)
It reminded me about the concept by general Rumsfeld: about known-knowns onto the unknown-unkowns.
If there is some power behind the information we don't know I think it can be worth to investigate what we don't know and always be aware of it.

I was also chalenged to held a talk. This gave me the opportunity to challenge an idea. While expressing the concept I was triggered to continue thinking about it. What was my idea? The main concept is that testers start as junior and grow up as senior. Only there is not much space for seniors so if you want to survive, you ahve to be good at what you are. This reminded my about a story by Adam Coucher: The most important stakeholder are you!

Or what Cem Kaner ask us: do we want to be commodity (a banana)Exploratory Test Automation: Investment Modeling as an Example by Cem kaner or do we challenge ourselves and learn?

In my opionion if you want to stay in business you have to create to ability to learn and not only to remember. You have to be aware that you can't rely on what you have done in the past or which certificates you collected. You have to be aware and think what you want to be.

During the lightning talk MB chalenged me: about the "You" and the "Why" he was right. Who am I to tell you what to do!!!

Zeger spoke about the Bader-meinhof-phenomenon. If I'm correct it is about the situation, when you noticed something strongly you suddently see it all around you. Imagine you have a new car, before you never noticed those beautifull cars, and now it is all around you. Imagine what this can do with bugs. You never were aware of this type of bugs and now: HELP!!!!

The thing I don't like is the title of this phenomenon, it has some negative feeling. Im certain there are other sources from psychology which explains more in detail from another perspective about it. I know that something similar is also explained by Oliver Sacks in The Man Who Mistook His Wife for a Hat
In one of the chapters he explains about a situation where after learning about it he saw similar symtoms all over the city by people.

Somehow we made it to lunch and deserved also a great walk through the woods next to the hotel.

RST in The Netherlands

After getting back some final tutorials were given by Ray Oei who explained about the lessons he learned implementing RST at 3 companies. It was sometimes hard as we still live in "TMap-country" There was some sound who explained that if TMap is asked we might call it TMap.

This idea I reject. Why call it something which doesn't work in the essence because when we ask testers about it they too often exlpain that it is not done as written therefore intended. They made there own twist..When asking them about it it is far from TMap. They use some templates, they use some techniques, they use some something and at least: it is al planned and those planned are nto telling what you actually did.

What I believe is: if you found you own way to make testing happen, don't lean on a name to sell it. By selling it under a name like TMap or ISTQB you support the believe it actually works. So it is sold more often. Perhaps it works for you, what I believe in is in honesty. Borrowing good things or bad things from a concept which leads to your succes doesn't make the concept be a succes.

Ray remined me why I suport RST because it chalenge you to think out of the box, it helps you to guide your thoughts, it leaves space to make it work for you!

Are you credible?

After the RST the final presentation was provided by Ruud about credibility of a tester. he is onto something, we testers should be aware about our credibility more often. When it is gone it is hard to gain back. Perhaps we should copy his action and create our own card or "buy" it from Ruud

copyright about the photo: at Zeger van Hesse/ copyright of the actual object (style-card): at Ruud Cox

STYLE


• Safety language


• Two ears one mouth


• Yes but


• Lighten up a little


• Empathy

With this final tutorial we closed the day in STYLE and went out for a dinner and reflect on the day and share some mysteries and parrots ;-)

Afteral it was a great day.

See also
DEWT
Zeger van Hesse
Jean-Paul Varwijk

How can I work when you build a fence around it?

Protection of your work
Last week while I was busy with one of my hobbies "geocaching" I found beside the treasure another particular thing. As on the photo below you see a mailbox only how can the postman deliver his work?

You might pass by this situation and laugh about it and continue what you are doing. The same you can do with this posting. You also might think what can be learned from this? is this a bug? Can it bugging me? Or bugging someone else? In certain situations I try to reflect on these situations towards testing. I believe that in every thing/situation there is something to learn from and which can help you define your mind set about testing.

A mailbox as trigger for questioning
So what did this picture triggered me: translate mailbox as you test object...it is a box that you want to see what you can do with it, what value it can give you, what you can tell about it, perhaps you want to take a look inside.

Currently there is a fence between you and the mailbox. How would you translate the fence. In my opinion anything which stands behind you and what you want to do. This can be procedures, a process, no resources just use your imagination.

The situation here reveals more information. Only you have to make assumptions, and some people claim making assumptions is a bad thing for testers. I like to play with assumptions to see if there is valuable information behind those assumptions. For this situation I raise the assumption that this mailbox was of use for someone at some time for some period. I'm onlyy a person who found about this situation when there was a fence. Perhaps this was not always the case. This is an assumption. In my opinion the value of the object changed over time. Only it is the value I can give based on my current observations and knowledge. I might tell this mailbox cannot be used anymore, big deal, the postman should take postcards back to the station.

Change of process
For the postmen it might disturb the process as he was ask to deliver, by taking back it is not taking back his postcards; it are the receivers postcards, and now there is no line of communication with the receiver. The package cannot be delivered and there is no solid way to communicate about the changed situation. The owner was not available. The fence is stopping him to do his job.

Another assumption here is that someone else placed the fence for some reasons we don't understand, yet? That other person used his process to place the fence without bothering other process which affects his action. In organizations there are also those people/roles. Therefore this can also be translated testing.

Other processes affects testing

How often are we testers bothered with other processes which stopped us doing our job? Our job is testing, asking questions to the software and more. How often are we busy to find information why processes/procedures which are defined to help us obviously to test better? Making the quality of the process visible instead of making the quality visible of the product. We use our energy on other "important" things than using it for testing. I learned that often we are busy with "valuable" metrics to control processes instead of collecting information to tell the story about the product. Value time is lost.

Help us with testing

Instead of focus only on processes try to focus on testing. Sure there is always other processes which affects our work. Let those processes help us. Only make sure you don't build your fence around our job!

Testframing: a bit of my perspective

Last week I attended a tutorial on testnet spring event 2011 given by Michael Bolton on Testframing. I already read something about (see: http://www.developsense.com/blog/2010/09/test-framing/ )and now had the chance to see it work. it was a great day as it made me think more about this concept. To preserve my thoughts and ideas I wrote this article. Perhaps you can learn also a bit from it.

Initially I thought it would be an approach were you frame all the tests in constructive sentences, and write them down. So initially it seems to be the same as I was told to do in the past: write test cases and then execute them.

I was wrong then: Why would you write down or use valuable time to write down test cases till the lowest detail when your mind is able to work with the speed of thinking. So there must be more to understand.

During the tutorial I noticed that one of the strength is the way you use a mission to guide the story you want to tell and the observations and actions you do how the story can be told. While explaining there was interaction between the listeners, when something was not clear you change the vocabulary of the proposition or perhaps the vocabulary itself. You even extend the frame using formal or informal connectives

I think that the difference between writing test cases and test framing it takes you much further, it combines the strength of a test strategy with thinking about the justification of testing together with(when necessary real time) adaptation of the path in the system you tending to follow ending up with the explanation of the results you found combined with the justification why you did it. This can be done very fast.

In other approaches like TMap we tend to call it in the Netherlands, there are all kind of delays involved, first the plan, then the written cases, then the execution and after a while a verdict about quality which was stated in the plan.
In some way it is a structured way of working, is it testing? This is another discussion I will not start here. There are other sources about this topic.

In short I learned more about test framing that it is a way of telling a story why and how you tested something combined with the results you found and what you think it tells about the system.
Testframing to me can be done by writing it down, in some cases this makes sense perhaps because of some complexity is involved or some kind of uncertainty about the system you have and you use it to validate your story.
Sometimes you actions are less important and easy to explain afterwards, then you use it without writing it down, just explain it.

Somehow I see a lot of potential in this way of testing. one of the reasons is that it keeps me thinking if I'm doing the right things.

On the same day Michael Bolton also had a keynote were he explained about the dark and the bright future. This was a great view. In the birghter view he explained about first order measurements (some more information can be read at stickyminds.com:
Three Kinds of Measurement and Two Ways to Use Them By Michael Bolton

While explaining first-order-measurement he used a connective "or" this triggered me to think that this is one of the strengths of testframing. You are able to adapt you story based on the first-order-measurements. My first reaction was: This is great!

If I'm able to tell a story about why I'm doing something with what mission (direction) then I'm able to tell the stakeholder/person who cares why Im worth paying for and spending time and resources.
If I'm able to make visible that I'm able to react on circumstances, the information from first-order-measurements, which are happening now instead which happens in the past (the delay when test scripts are written down and the explanation is proved later on) then I provide my self a tool to see if Im on the right way of acting and providing information which are accurate and supports transparency.

Looking back to testframing, I see some different ways to use it with respect to logging the actions:
- use it by thinking in testframing: nothing to write down or explained.
- use it only using your mind, thinking about it and explaining what you have done/doing
- use it in front and write down some notes how you think you want to approach the system
- write down while testing how you framed the mission
- pair testframing: you tell and share your thoughts/mind and another person make notes without interrupting you thinking process (this is another role than the person who challenge you while testing)

Another dimension here is the measurement-order. I think first-order-measurement is an valuable addition to be aware of while framing. Here you can do also some logging as the measurements changed or confirmed the path you were following in your mind.
- before testing and framing first: you might consider which propositions might provide valuable information
- during framing and not logging the testframe itself: log the moment of measurement and result, here you might wonder if you also write down the impact on your story.
- during testframing and also explaining the result: tell the story not only what you have found and why you did it, also explain what impact the measurement had on your frame and ask if you valued your measurements properly. If not there might be some valuable information left behind the framed story.

Somehow I believe testframing is a great way to test a system fast with the right transparency and justification. it is not just a trick you can learn, you have to practice to be able to do it and learn to become better at it. It is a way of thinking and communicating with others which is not only challenge the system as you do it, it also challenge you by explaining how you do it. Perhaps it also tells the story about the tester.

I hope this article challenge you to think a bit on Testframing, for me this is just the beginning in learning about testframing looking for opportunities and time to start with it and learning about it.

Issue solving in the cloud

This time not a story which I did a bit of research. This time not a long story, at least the intention is not to write one. This time about a thought I want to share with you.

The trigger for this thought was the failure of internet. As often I didn’t had the phone number available to call some service desk. Therefore I used my mobile and twitter account to express some #fail moment using a #service from some #provider

Within 10 minutes I got response from a service desk who noticed my call and asked for more info over twitter. Wow, I was taken serious, even more serious then providers took me before. They came to me to help me instead I asked them to help.

I provided some info with the idea: “We will see, perhaps it might work for me.”
Approximate 15 minutes later they came with the information that there was some kind of capacity shortage and they are working on it and asked me to have some patient.

Wow, not only they contacted me, they also shared information with me. How powerful twitter can be.
I shouted in the cloud and got help from some kind of desk. This made me think about the concept: “Issue solving in the cloud.”

Imagine that all apps, information, data etc are in the cloud. As user the chance of identification the service who can help me might even more challenging then solving the problem. Nowadays if we have an issue, we make a ticket or call someone to make a ticket and we have to wait and see. If I don’t know who to contact, why not make the provider responsible to monitor. We just need some rules, or perhaps even not. Who will tell.

Assume the following
- I want help
- I don’t know exactly who should help me
- apps are every where and nowhere, at least I don’t know were
- I have a tool which I can use to communicate

If there are a huge number of applications, you can do several things, use several issue tracking systems, (how can I monitor all?) Buy some service who does this for you (why do I need to pay more for something I don’t control?) or just communicate about it and use only those apps of organizations who also care.

Perhaps this can twitter also be for us. In this example I know what was not working for me I used the identifier #fail and a #provider name. Surprisingly, someone cared and responded; and informed me.

Perhaps this is the new way of issue solving, not writing huge reports what went wrong (only 140 characters) get help by interaction (question within time) taken seriously as a customer (provide service). No issue tracking list about metrics, no waste of time by spending more attention how to get the numbers right for management instead use that same time to investigate, learn, question and adapt.

I know this might be far away from the future how to deal with issues and provide service in the cloud. In my opinion if cloud is a new way of serving then also problem solving must be adapted to the this new way of working. Let change the roles. As we placed the apps in the cloud, the data in the cloud and the people in the cloud. The not store the issues on the ground and use the processes for solving as we do know. It might not fit. So let look fore other solutions out side the box into the cloud.

Just a few thoughts about issue solving in the cloud to share with you.

Seminar: Are you innovating

Although this is not a correct translation it might make things more clear then call it "Innoveer jij mee!"

Today I attended a free seminar sponsored by Ordina with to great speakers: Gojko Adzic @gojkoadzic en Anko Tijman @Agiletesternl

The evening started with a long row to obtain "bad" coffee. With this start everything can only improve. And it did. Sure, there are always some things which are worse or could be better. Let me start with some small notes about the impression I gained. It is not the full story, just some snap shots and ideas.

Gojko's "Sleeping with the enemy".
As the chairmen mentioned, "Oh, no, not that again" It was not about testers and developers. Us and them. Hearing Gojko mentioned these words I immediately thought about the song from Pink Floyd Us and Them

Looking to the lyrics it can be so true. It also start with:
"Us and Them
And after all we're only ordinary men"

Gojko did not emphasize the idea of Us and Them. What I remembered was that he want to skip the functions. In teams we don't need functions, we perhaps need roles. We should get rid of our who's to blame culture.

He started with a great statement "Why are we[programmers] going to stop telling testers how to do their job? They know testing much better than we do!"
There is still some discussion possible if developers should test or testers should test. I think we should do both. I will come back to this later on.

In my opinion he used a very strong example. (Keep in mind that these are some pieces I remember from this evening. Therefore these are my interpretation and words).
A driving instructor is not telling you: you hit that car, and that car and that pedestrian. A driving instructor is teaching you how to drive.

A similar thing we testers should also do. Teach the developers how to test, participate. If they are able to do the testing for you. You gained time to do more important things.

Meanwhile @michelkraaij tweeted a statement @gojkoadzic, you keep making the distinction between developers and testers. Testers ARE developers!

We discussed this in the short break and Gojko marked that within a role there is also persons are involved. I translated that into a thought that personality is also important how a person can interact within his role.

So I polluted the twitter sphere with this idea as response:
ppl matters,personal value creates personality help define skills 2 form attitude able to act in a role

My idea with this statement is that it is easy to think that every one should be able to test or develop or do the same. Skills should be equal. Who does is doesn't matter. If people are involved we should respect them and human beings with a certain value. People differ and therefore have different personalities. I think the personality able a person to use their values under certain circumstances which will express their skills under those conditions. When it is noticed, people will respond on it and this will influence their attitude. And now based on the attitude, the presentation of the role which is needed will be express also. (don't shoot me for these thought, it are just ideas which seems reasonable to me, I did not read a book to support these ideas)

As promised, based on this concept it should not either be developers or testers who do the testing. Testing should be done by those who care about testing. If a developer cares about testing then let him test.

This was in other words also Gojko thought; he explained that when testers were involved quality reduced as they rely on the tester and no longer on their own skills/value (testing).

After all Gojko held a great presentation with hand drawn slides :) With perhaps a credo: "let developers help us to test so the testers can do other important things."

I think this can also be expressed by the words from Pink Floyd from the song mentioned earlier "And who'll deny that's what the fightings all about
Get out of the way, it's a busy day"

Agility in the waterfall?

After dinner Anko started the presentation he also held at Eurostar 2011 called "Building a Quality Driven Team". After some introduction he came up with some slides I initially thought he wants to bring us back into the waterfall. I can come up with argument I reject his story. I think he showed me some other ideas concepts. He made me think. Although his slides seemed to look like waterfall explanations. If I turn that concept around: He made me able to bring put arguments to the traditional project manager who relies on requirement, design build etc till it is good and supported by waterfalls ect.

The model Anko made for me was a model I could use to explain how certain phases of Agile testing fits in a V-model approach. If a PM fancies a V-model, why not use it to explain your thought. It can help to express that your ideas about Agile attitude and quality firs in his project also, only there are some other conditions. You might be able to build a bridge between different thoughts and gain some understanding. This might be a solid base for obtaining commitment.

Anko posed another statement about the emotional acceptance factor. I would translate that into an example I learned a few years ago.

I was on a project with the ideas of Agile and with a lot of commitment from business, team and project management. We tested together and did a great job. As well as developers and testers were able to tell on daily basis what they did and how the project was evolving and value was introduced. We were almost finished and one of the stakeholders complimented us with the result and made one final addition. I see you did a great job, I see that the quality is somehow made visible. The only thing I would ask you to do: Coach and support one of my key-users, make him test in his uncoventional way. if you are able to help him gain trust it would help me to sell it to the business.

This was not about not trusting our results. This was about some feeling based on emotions. This was emotional acceptance.

Hearing those words, I start remembering more of those examples. It is not explicitly written in books. It is there. And we should care.

There are more things I have remembered and should remember. After all, it was a valuable spend evening. Of such value I want to share it with you.

At the end I had some great conversations with other people and thanked Anko and Gojko.

While driving home I forgot to ask him if he had a copy of his book available and ready to sign, perhaps another time (@gojkoadzic you have my card :-) )

Navigation by blindness

Let me start again with a phrase: a few weeks ago.... some how I got triggered by the navigation system I own. I drove back from work towards the place I call home. I push automatically the “home” button and the navigation system calculated the optimal trip home without asking me for any questions if I prefer another way to follow.

Normally I would consider this normal behaviour and follow the advice route or ignore it. This time I got aware of “it”. “It” gained is this situation a new context. “It” turned from an accepted situation of which the rules did not matter into a situation with several conditions. “It” turned into a predefined path into an path which could be overruled with made decisions which I controlled.

You might think, this is nothing strange, you always follow the route which is calculated, or you also overrule the calculated route.
If so, are you able to make the connection with software testing? Do you even wonder if there are connections?

At that moment driving back at home there were several things I thought of:
- Why do I ask for a defined route calculation although I know were I am, were to go and how to drive?
- Why did I still continue to add the destination?
- Why was I curious about the ETA, I had a watch and I know how long it would take approximately and somehow it was not higher maths?
- Why did this remind me of some moments in regression testing? Performing the same actions although you know the outcome?
- Why did it give me a bad feeling that using a tool did not provide me any additional value?
- Why did it feel as false trust to rely on a tool although I could use my own knowledge, skills and senses?
- Why did it look like I was in control and in testing using standard regressions test or standard automated tests provide same feeling of control?

So why do I bother at all to write about such a simple action. That is “Why”.

While driving I deliberately ignore the advice as I know another route, not faster, not slower, a route which worked for me. I ignore the tool, the navigator, and followed my route. I used a who-cares-factor.
So who cares?
I cared because:
- I got aware that I was able to overrule the system
- I got triggered to ask me the question why to ignore the system
- I added new value to the meaning of the route, as I was curious about some parts of the area
- It made me also challenge the tool I was asking for information. I compared the initial prediction of ETA combined with KM’s to drive with the newly forecasted information
- It made me able to listen to my car under other conditions, instead of driving 80 km/h driving the care with 120 km/h. somehow certain speed at certain moments gave some other thrills.
- I got aware of a situation were things seems so obvious you have to change focus to learn new things and redefine old behaviour.

That evening I learned more about not following blind advises provided by people or systems. I learned to play with the context, instead of accepting the situation I got new insights about the way I behave, think and act. I learned that I and perhaps others using tools out of familiarity instead of certain purpose which value has changed.
I learned that if you don’t change the situation or circumstances then the value will be minimized. This remembered me of a lessons I read somewhere sometime that if you don’t change your regression tests then they are worthless, they don’t add anything. So why do it, spend time, and valuable skills if you skilled testers?

I think we should avoid navigate with certain blindness by relying on tools and defined routes. Instead we should change our test cases and not rely on our “old” regressions tests or other tests we scripted in the past.