Pages

Showing posts with label bias. Show all posts
Showing posts with label bias. Show all posts

Tuesday, 23 October 2012

One down two to go!


And no, I will not link the King Diamond song here (even tho it’s cool). This blog post is about my experiences from the first (my second first day) at the Rapid Software Testing course by James Bach. I seem to be one of the lucky few who actually are able to have two goes at this amazing adventure to the deep dungeons of an exploratory testing mind.

Like I tweeted earlier, I fell into traps; the most obvious traps that can be set for a tester. I know I can do better so here’s a quick analysis on what happened and what could I have done better:

http://morningandotherstories.wordpress.com/2011/12/
Context: When I was confronted with a testing problem without a context, the first thing to do is to determine the context. Right? Here’s what I did: I thought I might sound too clever on asking and challenging, so I answered the question without determining the context. This lead into questioning my answer and making me realize that “we’re shooting live ammo here”. So I decided to sharpen up.

  • I could have done what I (try to) do every time I’m facing a problem: Understand the context, the people involved, the background, the current status, the mission, etc; communicate with the client, stakeholders, testers, etc. That could have brought the whole problem into a new light. I fell into a clever-trap


Pattern and mental models: I had the advantage/disadvantage to see the formula for a pattern beforehand. The task was to determine what the pattern was. Those that have taken the RST course will remember this, right? I remember the point of this exercise being to break the assumption and to focus and defocus. Again, my previous knowledge bias struck in: I completely ignored testing the product and did some of the procedures I had seen done in previous classes. The pattern was the same, however, so basically I didn't lose anything…

  • …EXCEPT FOR EXPERIENCE! I could have spent the time testing in ways I had not tested before. Now I had the time to do something different. Instead I tried to look good by using Excel (like James Whitaker, I think) and I made a simple script to produce test data. I didn't even bother to check the logs, as I had checked them numerous times before. Should they have changed the behavior even a bit, I wouldn't have been able to identify the pattern. I fell into a showman-trap.


http://members.multimania.co.uk/mrmal13/saints/amardas.htm
Documenting: The task was simple: Write tests and justify all of them. James specifically asked everybody whether they had made a justification for ALL the test they were going to run. An exploratory tester documenting test cases and justifying them all with specific, detailed texts? Can you picture that? I could hear myself saying within my head “Yes, James” without even questioning my so obvious bias. I tried to be a good boy and wrote them cases and then feel pride.

  • The exercise was about justifying the testing but in a different way. My doing inexpensive testing and discovering something worth discovering, one can justify a more expensive testing. Like James said: “The cheap tests pave the way for the more expensive ones. They are the scouts that look for a good spot to place the artillery.” That comment alone is worth its own blog post. But instead of being inquisitive, exploratory tester, I became a test designer that is going to get fired. I fell to the guru-awe-trap.


So my first day was a success: more learning than I hoped for. I also thought that I had some form of advantage of knowing the stuff from previous, but it seems that I had misunderstood (or belittled) some basic principles of Rapid Testing. I felt some of the stuff explained more comprehensively, with sidetracks to bulk up the areas where I thought the content was thin (namely the modeling and project elements of Rapid Testing). I do wish James would have covered the modeling heuristics with more depth, but I will leave room for other areas for the next two days.

What I’m looking forward is the process of Rapid Testing itself. I somehow missed a whole lot on that subject when Michael Bolton was teaching the course. Also to hear more about the oracles would be nice. We scratched the surface today but we’re still to cover some of the mnemonics that I frequently use, like CIDTESTD, HICCUPPS, etc., but it was nice to see an update to SFDPOT with the Interface addition. I will be using that when I reinvigorate the workshop in near future.

The importance of the context

So as I’m heading home, I will share this one particularly funny event that happened in the beginning of the class. Here’s the story without context:

James Bach spit on Aleksis Tulonen.

If you add context, here’s what really happened: Some poor fellow was getting given the “Socrates treatment” by James and he had an act prepared for the response the guy was going to give. He asked a question and set a trap onto that question. He knew the answer would be something “horrifying”. So he took a sip of water after asking the question. When the poor fellow answered James theatrically spit the water from his mouth as if being so stupefied by the answer that he just couldn't bare it. Unfortunately the aim of the jet of water was a bit off. Aleksis, who happened to sit in the front row next to me, was a victim of the poor aim. Aleksis’ phone and computer got some droplets on them as collateral victim of this splendid act. Hopefully tomorrow’s newspaper doesn't have a title “A testing consultant got spit on by a guru”.

Saturday, 19 November 2011

The first impression bias

Hi y'all!

I just started in a new job in a new city so everything is new to me. I still live in Tampere (a midland city in Finland) but I commute to Helsinki every day (about 180 km). The job I got is a Quality Engineers position at F-secure Corporation in Maintenance team with (hopefully soon) some managerial tasks regarding Customer Care and whatnot. Most of all testing, testing, testing. Enough of that! My point was that when everything is new you get to look at things fresh eyed. I didn't say biased as I'm TOTALLY biased when it comes to all these new things as I compare them to my previous jobs. I just have a different perspective onto things some people have been looking at for years. I have longed to work at F-secure since I first started to dabble with testing and now that I have the chance I embrace this opportunity with every cell of my being. (This is to make my boss happy! ;) ) But nonetheless I have be critical as I am the new guy and I may have an impact onto those settled ways of doing things and maybe even improve them. We'll see how this goes...

In the Ohjelmistotestaus.fi -blog (which is in Finnish, sorry) Antti Niittyviita wrote about first impressions. He said (free quote) "The first impression is an opportunity to get new information of the quality of the product or service. It should not let get wasted!" When I got to the company I though "Wow, this is quite rigid stuff", for the security part was mandatory and quite formal. Actually on retrospective the event was less than formal, but I think I was so nervous.

Later this week I got to get to know the products from public website so that I get a basic knowledge of what this all is about. I thought about Antti's blog post and took a critical and learning attitude towards the browsing of the products. I was amasing how much defects, issues and such I picked up from public website! The new perspective really opened my eyes.

The testing I got to do the first week got my critical thinking up and I ended up making observations that might have been insignificant to others but I reported them nonetheless. As it turned out these thing teached me quite a bit about the behaviour of the product and the platform I ran on. They were no bugs but something that were not documented in a sense that I would have been able to learn from documentation or from tutoring. So the first impression and critizism thereof teached me something important.

The first impression also has a negative side. If you get a first impression about something you rarely change the attitude if you don't have to analyze the cause of the dissatisfaction. For instance a product that is thought of as slow and reduces performance on your computer (my sister-in-law said she hates a F-secure because it slows her computer down and eats the disk space) doesn't get to change the consumers opinion if they toss the product. If the bad image has gotten through to customer, the dent in the image will be hard to repair.

--

As testers we have the job of trying to test on the best ablity possible. We all get a first impression on something and we may guide our next move by the impression we get. This applies especially in exploratory testing. We guide our next step so that we take in account what we have learned in previous steps (in steps I don't mean scripted testing but actions we take during our testing). Because it is very power tool, we should use first impression as a first guidance tool for our testing. To remain critical we NEED the first impression. What is the first thing we feel might just be right.

As the first impression might be a inference instead of observation we must be careful not anchor ourselves onto the first attribute we percieve. Here the critical thinking of a tester comes to fore. We need to be able to recognise what we observed and afterward make assumptions from those observations instead of inference. By making judgement upon inference we lead ourselves into a trap and start thinking we something that is not there and miss things that are as irrelevant.

There are some basic tools to guide ourselves away from anchoring ourselves onto a inference, but I ain't gonna go through those here. Point being that we have to remain critical even though we have indication to start thinking something about the product/service/whatever. The first impression is a good tool just as long as you remain critical and don't let yourself be anchored onto an attribute that you have infered. (Here's the difference between inference and observation)

Hopefully I remain critical in my new job and start defending the quality of those products we offer. The first week is behind now and new challenges are coming. I hope all my colleges have the nerve to cope with my bad humor and loud voice. :)