Irish Luck

Hope the 'luck of the Irish' will rub off on me this week because so far It's been an unlucky week indeed.

I think Murphy's Law is with me currently and hope to leave it there...

Yesterday, during my two-weekly hospital drill, I hurt my big toe. At first, although it hurt a lot, I didn't think much of it, but soon it became really annoying and I called my doctor. He thought it couldn't be broken due to the cause, but since it hurt a lot, he send me to the First Aid post in the hospital to make some X-rays just to reassure me that it was fine... Well... It wasn't ...it WAS (IS) broken. So  they decided that I had to get a special sort of shoe.

And I waited and waited... And after an hour my husband went to the desk to ask how long we had to wait, since he got very hungry ... And they were surprised we were still there... They'd forgotten us and after ten minutes I got my 'shoe' and was off to home...

Today, I had to fly to Ireland for SoftTest. When I got to the check in I kept getting the message that the passenger couldn't be found. I used several ways to check in, but it didn't validate. So I checked my original ticket and got white around the nose... It was booked for the 5th of November , luckily they had booked my return flight correctly, but now I had a new problem: World Ticket Center doesn't have a desk at Schiphol and frankly: although the send me wrong ticket, I had to check it when it came in. So the money's gone alas. 

But I had to find out there wasn't a WTC desk at Schiphol because different schiphol personnel kept sending me all over the place, so I hobbled from departures 2, to 3 to 1 just to get back at KLm in 2 where I was advised to get to the servicedesk and when I finally got to the desk to hear I had to go to AerLingus desk in departures 1. I have never walked this much on schiphol when I was healthy, and I can assure you, it's no picknick with a broken toe either. 

But at AerLingus I could still buy a ticket for the flight I had planned to take and now I'm on the plane on my way to the runway. 

At least the Irish cabin crew already rubbed me a bit when I told them my story, I hope the Irish luck will have rubbed off on me a bit! 

TestNet SpringEvent 2013 - Part 1 - The Tutorial

Today is 13th of May, SpringEvent of the Dutch TestNet. I have started my journey early today to get to Nieuwegein's NBC where it's held. I'm travelling by public transport, which goes perfectly well until I get to Utrecht Central Station, where the fast-tram stop has been moved from front to back and I didn't get the signing (is there any in the stations hall?) and I end up looking for the changed location and missing the tram, resulting in delay...aargh... well I got to the venue eventually and on time, I guess that's the most important.

The day starts with the tutorials, since it's my part-time day and I won't have to visit a client in the morning this time, I'm taking the opportunity to attend one. I chose 'Automating Production Simulations for Added Value' by Scott Barber (Twitter:@sbarber). Here are some 'blogsnippets from that tutorial':
Scott is after that telling about is path which he followed to get where he's now. I'm wondering where this is going, is there a message where this is going to or just getting to know him.... it takes a while but the point is: he didn't follow any programming or testing education but he looks at things differently than 'the norm' and we're about to look at things differently during this tutorial and he shows the image about 'nothing can stop automation'.

There's loads of 'me' from Scott, but little 'what's in it for me' till now, but anticipation is building when the following is said;  when you're taking your first steps in automation he's going to 'melt the brain', I sure hope so. The audience is really tame till this moment, there's not THAT much interaction although Scott is asking questions and relates to the knowns in the audience. I guess it takes a while to pick up steam.

Next is the following comic

and the following mind-map, which we can add to (please also look at this map for tutorial content):
http://www.mindmeister.com/nl/291649893?t=WVVr4hE3PO (I also made a PDF of the 12.52 h. version which will be available on 'funtestic.nl' later on...)

What's the point : "I don't care what "framework" you use, they all miss something important!
He's now mentioning the amazing: http://en.wikipedia.org/wiki/Specialisterne 

Tester's TIP; save a webpage that has loads of validations, save it to your desktop, open it and delete (most of) the javascript (it still has to submit though!), open it in your browser, type in everything you want and submit... and you bypass all the front-end / pre-commit data validations. 

"Most test automation lack narrowly defined Oracles to detect almost anything of value!" is now shown on the sheet, there's also a discussion about all the shades of grey between YES or NO. (My thoughts on this are: shades of grey are just very small defined YES or NO's ....even if you have a deviation of minus 10% or plus 10% it is still a YES/NO question... it falls between these margins or not)

 "An automated test's value is mostly unrelated to the specific purpose for which it was written. It's the accidental things that count: the untargeted bugs that it finds" 
Don't stop just because your automated checks work. Add more value with production simulations.
Wow, nice/surprising fact: ... only 56% of traphic on websites are really humans, the rest is bots and spiders.

Seems to me that automation is all about very nifty 'if then elses' and same as very small yes-no's mentioned earlier; the smaller those get (more elaborated) the more 'sentient' a test /might/  seem... It's becoming cool when this is combined with random data input so flows are followed differently every time.

It's now 12.44, that means I only have about a quarter of an hour left of this tutorial and we're running through models (see mind map for the types!). It's time for me to round up this blogpost. The tutorial has been a bit disappointing for me in one way that the three quarters of introduction could have been used to tell more about content than intro; the tutorial was little hands-on and mostly highlevel. Feels like of the 4 hours, only 2 hours were used effectively on content, which is a pity, because the topic is interesting enough.
Well I guess my expectancy was a bit higher and although I'm a bit disappointed I guess I'm inspired enough to search for more info, which is something too! Now signing of for the closure of this tutorial and making myself ready for the second part of the SpringEvent this afternoon and evening!

Client Based Testing ['golden' oldie]

This was my first start of an article that went with an abstract (for TestNet NL)... Because I was so 'wet behind the ears' back then and a relative 'new' tester, the presentation became a fiasco (to put it mildly) with me more in tears than in a happy mood... It can happen, but I didn't give up! ~Remember that things don't always go perfect the first time around...

As I read it now, I'm still behind the matter and it's still very relevant. I think I was 'before the time'... enjoy ... I'm curious what you find of the stuff... (date of last revision: fourth of February 2008...text below is UNchanged!, presentation was held on 'Fall event of TestNet in September 2008). It wasn't completely finished either; I guess I was too 'frightened' after the presentation fiasco to push ahead...still it gives a good idea of what I had in mind back then...

~~~~

Testing has been a hot item the last couple of years. More and more businesses are starting to understand the importance of testing to mitigate their risks and establish a certain amount of quality of their product(s).

Over the years testing has evolved from ‘an activity done just before production’ to ‘a structured process of measuring characteristics of a process or system’.

This structured process is - for its part- based on Risks (Risk Based Testing) or Requirements (Requirement Based Testing). Also methods have been developed that are involving ‘the business’ or ‘the management’ more because typically one seems to think that the prioritization of risk or requirements are best set by ‘the business’ or ‘the management’.

Testers or test managers repeatedly seem to fail to involve the ‘real’ client when developing policies, strategies or plans. Not the one who pays the money but the people who are meant to work with the product and/or processes should have an important contribution in this stage. Especially in companies where requirements are poor and there is no time or money to develop these (for example Agile testing) or in companies where there are too little or too many stakeholders to determine the prioritization of risks (layering, budgets etc.)

Hence the introduction of Client Based Testing, or – in short- CBT. CBT should be approached in two ways; from the testers view and from the clients view.

Firstly the Testers view, or in particular, the test managers view. At setting up the test planning mostly risks or requirements are used for determining the activities to be performed for testing, when these cannot be produced by the organization the manager will mostly look for specifications and/or use-cases and will set up his tests on these bases. Forgetting a very important and very accurate source, namely: the end-users or production-unit of the company. Even though the British standard provides for this group of people by the means of being a test bases, most test managers ‘forget’ to involve these group of people. In practice I’ve found that this has a couple of reasons.

1. The ‘old school’ tester (now manager) gives a natural preference to non-human input or non-communicative input, having been a programmer in the past
2. The test manager (formally non-test) has a natural tendency not to involve the ‘common people’ and always communicate with people higher in the organizational hierarchy
3. People ‘on the floor’ have a tendency not to have any time available (or otherwise said: have a natural dislike to management-people and or new software being developed (and tested) which implies the possibility of rendering them unnecessary) or do everything not to help (on which the reaction of the test manager is to ignore them in the first place)

Client based testing obligates the tester to develop more communicating skills but it also requires qualities like empathy, pliability and the ability to translate jargons.

Secondly the Clients view. Some years ago I received a questionnaire called TUSK which Isabel Evans had developed, was still developing. The TUSK list is based on the SUMI list for software but in this case the questions are translated to how the client or organization experiences the tester of test team and what part of the testing activities should be improved to the clients liking.  I used this list – as a pilot to write an article on TUSK usage - in different organizations and found that not the information the answers provided helped the most in improving the test process, but the time spent with the customer and listening tot the client was the most helpful. The client really felt understood and was more willing to participate and cooperate with the test team on improving their deliverables and processes.