Jiro dreams of sushi

When I first read Daniel Pink's blog post: The best 82-minute movie on mastery I’ve ever seen I knew I had to see the documentary Jiro dreams of sushi and that I would love it. Now I've finally done that and, despite having sky high expectations, it blew me away!

What is it about?
It's 82 minutes of watching the 85 year-old restaurant owner and sushi master Jiro, and his crew, express their passion for sushi. That's it! How can that blow my mind you might ask and if you know me really well you could add: You don't even like sushi!

What is it really about?
Let's zoom out. This is a documentary about passion, the actual craft is pretty much irrelevant apart from how the people in the documentary treat it (if you love sushi you would probably get another dimension that I don't really get though). Jiro and his crew shows this by just expressing their genuine passion and devotion. They talk about how they reason and what they prioritize, about harmony and challenges, about their inner drives and journeys. That's what it's really about.

Why should you watch it
What made this documentary amazing was how well it transferred the core feelings of passion on to me as a viewer. I love the feeling of having something just turn on an emotional switch inside of me and that's exactly what Jiro and his crew did. When I came back to work the day after seeing the documentary I felt even more engaged when i usually do, it was like the inner spark was just ever so slightly stronger that day (which made me slightly overexcited at times .) I'm definitely planning to see it a second time soon just to see if I can get the same feeling again... and again... and again (hmm, is it just me or am I starting to sound like a drug addict?).

This wasn't really... useful
Well apart from a film tips this wasn't really useful. However, a blog post about finding passion, based on this documentary, is on it's way. A link to it will be placed here when I'm done.

RST: Was it worth it?

First of all, this is my opinion about what I experienced, about the instructor, the content and the events. Feel free to comment but bear that in mind.

I took the Rapid Software Testing course so...
Was it worth it?

What did I get?

Content
Most of the teaching material (excluding mainly/only exercises) is available for free but it turned out the actual written information was just a small part of every slide's value. During class I got to hear the idea behind each slide, engage in arguments about its content, I got a chance to ask questions in the middle of other's arguments, I got to hear how other people interpret the information and I was sometimes challenged to react to the slides when I accepted things that were not clear. All this combined added a lot of content value, value not available to download.

In case you know very little about the course's contents let's just say it covers most aspects of testing to some extent, especially those that are rarely covered elsewhere like quick tests, time pressure and how to actually figure out what to test. I have no idea how we managed to cover all the ground we did in just three days, that's a mystery.

Teacher
There are only three people allowed to teach the RST course, all three are highly respected tester within the Context Driven Testing community. In this case the teacher was James Bach, the same person who once inspired me to start my quest of becoming a great software tester (read more in About me). James is inspiration with two legs and a beard! During class people spoke up who (I suspect) normally don't, people volunteered to "fail" in public who (I very much suspect) normally don't and people seemed eager to test who (I unfortunately suspect) normally don't. Inspiration was everywhere and he manage to make it that way!

Using the Socratic method, he made me think for myself and the different ideas that emerged doing that generated interesting discussions where I had to argue and explain why I came to certain conclusions. This was an amazing way of practicing critical thinking and forming valid arguments, it also made information "stick" a lot better. Kinda like being guided to answers rather than put there and the journey in itself was a big part of the learning experience.

Finally James raised my general confidence as a tester. Sure any new knowledge makes you slightly more confident doing related stuff but that's far from all in this case.
To begin with, after the course I not only know new stuff to try, I understand why and when to try them. I can argue for strengths and weaknesses and, using the same principles, I feel more confident bringing up and arguing for my own ideas.
Second, there is no perfect answer to any exercise and therefore you will partly "fail" every time. But James was really good at helping me observe that everyone failed/succeeded to some degree and that it's important to learn from the result no matter the outcome. He also, in a very clear way, explained both what I did really well and how I could improve. All and all, when I ended up in a pressured situation at work last week I could act a lot more calm and systematical when I usually do, that was a huge confidence boost for me and I trace that back to the class!

Meeting great testers
I got to meet some really inspiring people with tons of wisdom to share. Some did arguing really well, others questions, some had completely amazing ideas and some just acted in ways I would never had done myself. Just being put together with all these, generally highly motivated testers and great thinkers, was inspiration and learning on its own. At the end of the course many of us shared contact information and the facilitator offered to spread this (Layer10, the facilitator, did a great job in general I should add). I'm looking forward to hear more from many of them.

Challenging yourself
RST made me challenge myself. Like I said before, there was a certain atmosphere in the class. That atmosphere and the many challenges put out by James sped up my learning a lot. The extreme example for me was testing the Mysterious Sphere (which by the way was my highlight during the course) where I was in the spot light for quite some time under somewhat high pressure doing something I had never done before. That was an amazing opportunity which I'm very grateful for. The experience, apart from raising my confidence in pressured situations, taught me tons of things about myself like how I act under pressure (military service did I quite fine job as well but reminders are great), what I could improve in my approach to similar problems and strengths I have.

Exercises
I did expect to learn a lot from the exercises in class but I didn't expect the usefulness of them after class. I've tried a couple on my closest colleague and many of the ones I did in class still makes me think and realize things. One example would be the IP address problem I described in my SWET 4 lightning talk. That still keeps me thinking (and I'm sure it would have even without the added ideas from James) and ideas pops up that I might present here at some other time. Also, when I try out some of the exercises on others I learn things I didn't realize when doing them myself, for instance how much of a difference the choice of words can play when explaining something. Finally the exercises have acted as helpful reminders of things I learned in class. For example the, by now well mentioned, IP address exercise reminds me of visualizing problems and that humans aren't good at randomizing so I probably need help when randomization is desired.

Epiphanies
I have tons of small notes ending with several exclamation marks. Each of these notes represent some kind of  great reminder or epiphany. Just the written words on their own probably won't communicate much but here is a short list of samples just to give you a picture of what I mean:

• Fear prevents intelligens!
• Just because you say the same thing you don't necessarily mean the same thing
• You don't always need the information not available, use your brain! (assembler example)
• Doing tons of work you shouldn't do is the opposite of being responsible (assember example)
• The trick is often to see what's not there (flower exercise)
• Figure out what a product doesn't do, otherwise you never know when you're done
• Bugs are not in the spec!

Oh, by the way, that list only covered about two thirds of the reminders/epiphanies written on the first 2 pages... out of 21.

Opening doors
I want to work using my skills, creativity and passion. The only "branch" in testing where I feel this is true is in Context Driven Testing. RST is the "de facto" course for context driven testers and my impression is it's a great way to open the doors I'm interested in (just like certificates are the way to open many of the doors I try to avoid). At the moment I'm in contact with two companies who have adopted many of these values and even though their interest in me is not only due to RST I imagine it strengthens my position.

By the way, just to be clear, Ericsson, where I work now, is not a bad company for a tester (see for instance Guided by fun) but I'm looking for a new challenge and it's nice to have the merits required to choose a bit.

Any special benefits of paying it yourself?
I didn't get any "special treatment" during class because I did what I did but I think it helped proving to James that I was ready to be put on the spot. For example, even when I had a bit of a slow start I still got the chance to do one of the tougher exercises (which I am, once again, forever grateful for).

I also got invited to SWET 4. I've no idea about the exact reasons for that but I think my action at least helped convince the organizers that I was suited for such a challenge/experience.

Finally, and this, despite the things already mentioned, is the most important thing to me: It proved to myself that I was ready to make a sacrifice to reach my goal and thus it proved to myself that I care a lot about my goal of becoming an outstanding software tester.

Verdict
So, was it worth it?

I don't expect this course to ever "pay itself" through salary raise that can be traced back to me attending. Also, the time spent was time I would otherwise had spent with my family, something very important to me.

So, it was not worth it?

Not so fast! This course improved me as a tester in ways I didn't think possible. Sure it was time away from my family but it was weeks and months of learning, packaged in a three day course. Learning I would otherwise had to do in my spare time anyway.

RST has taught me valuable skills (apart from looking good in my resume) useful when I apply for jobs I want, jobs where parts of what I do in my spare time can be part of my job (like RST, SWET 4 and GUI testing). Also, no matter the circumstances, I'm now more comfortable and skilled in changing my current work to become more like the job I dream of. For instance I know how to argue for and against ways to test, plan test and report test.

Finally, I want be so good at what I do that it turns into an art. I think that's exactly what James and other great testers have done and I want to do it to. This course really propelled me in that direction.

So was it worth it?

Yes, Yes and Yes! This was an amazing experience and if someone offered to pay this for me I would say: "Save your money till Michael or Paul gets here".

If you get this course offered by your job, answer yes.
If you hear it's available in you region, read this and act accordingly.
If your company won't sponsor you, read my first RST post and decide if that's how you feel as well. If you ever want help motivating this for your boss, feel free to contact me (Twitter: @brickuz).

Lightning talk - SWET4

Intro
Last week included both RST and SWET 4. I have so much I want to share about these amazing experiences, not to mention all the inspiration, ideas and epiphanies related to the events. However, to start off I would like to just share a written, more complete, version of my lightning talk (SWET 4). After presenting it, people feedbacked I left out important information (extra credit to Henrik Emilsson for pointing this out in a great way). Hopefully this version solves any confusion.

The talk
During RST with James Bach I was staring at a long list of IP addresses. All of them shared some kind of pattern making a validation check fail but I just couldn't figure out what the pattern was. Here you can see a 3 row example of how the list was constructed (imagine dots between the numbers and you see IP addresses). Notice that the numbers in the example has nothing to do with the actual exercise, I just made them up right now:

203	176	15	117
74	101	255	103
65	18	247	0

At some point I started thinking about visualization and since I didn't have any better idea I just went crazy with the graphs in Excel. Most of these didn't provide any valuable information but two stood out:

With respect for the class I won't go into details but both the "boxes" in the first one and the "zig zag" in the second reveal useful clues to the mystery.

When looking at the graphs generated by Excel I also had an idea about a graph I didn't know how to plot. The idea was a box there each side represented one of the four numbers making up an IP address (0-255). By drawing a line from side to side a geometric four sided shape would appear in the box representing an unique IP address:

Example: The blue line would represent
an IP address similar to 40.180.110.80
starting at the top and ending to the left

Since this was during RST I asked James if he knew how to plot this. He said he probably could but we didn't speak more about it.

Some days later I met James again when attending SWET 4. He immediately showed me an exciting idea. The box apparently didn't reveal any useful information as a graph. However, if you instead drew your own shapes and used the IP addresses these shapes represented (same basic principle), it became an interesting way to generate test data and visualize data coverage at the same time. Brilliant idea!

There is a lot of things you can learn from this, the power of visualization being one. But I want to highlight three underlaying decisions I find crucial:

1. When stuck, just do something
   Even if the graphs would have provided nothing, so would more staring. Just doing something can sometimes kick your brain into gear and give you new ideas (like the box graph for instance) so even when the initial act is fruitless it might get you forward.
2. Don't overthink cheap tests
   I could have analyzed what kind of graphs to plot but plotting one cost just 2 clicks so why care? If it's really cheap, just do it!
3. Share your ideas
   If I had decided not to ask James, the great idea with using the box as a test data generator would never had occurred. When something seems useful but you can't figure out when or how to do it, share it, cause others might!

Credit

In addition to James Bach, who played a key role in this, and already mentioned Henrik Emilsson, I would like to thank all the other SWET 4 participants for inspiration:

Torbjörn Ryber, Rikard Edgren, Martin Jansson, Sigurdur Birgisson, Sandra Camilovic, Anna Elmsjö, Johan Jonasson, Maria Kedemo, Oscar Cosmo, Saam Koroorian, Simon Morley and Joakim Thorsten. I had a blast!

Practice: Note taking

Yesterday I decided I wanted to improve my note taking skills (my finance stopped trusting my memory a long time ago and it's time I do the same). I also decided books, blogs and similar was forbidden ground cause I constantly find myself reading instead of practicing when I try to learn something, which I don't think is a good thing. So I picked a presentation, in this case Elisabeth Hendrickson's keynote from Cast 2012 (The Thinking Tester, Evolved), and forced myself to take enough notes to be able to retell her key points a week later. At the bottom of this post I've added my actual notes as pictures, not very easy to read but hopefully good enough (with my handwriting when writing fast, I don't think any picture quality would make a difference though)

First a few general realizations:

• It was fun!
• It was easier than I thought! I don't know if this was because it was fun, due to the specific topic or some other reason but I guess time will tell.
• It felt efficient! I have a hard time imagining it would be possible for me to learn as much in the same amount of time by reading (for this topic I should add).
• Just like reading makes you practice other skills, like focus, this was an efficient way to practice several other useful skills for instance:
• Observation
  Both during and after I observed everything I did in a conscious way.
• Reflection
  From the observations I draw conclusions and tried to figure out what I could learn from these conclusions.
• Focus/Discipline
  This was, for me, a much more powerful way of practicing focus than reading.
• Listening
  In this particular practice I soon noticed my way of listening to what Elisabeth actually said got better and better leading me to believe this could be a powerful way of practicing listening as well.
• I feel motivated to do it again!

So what did I learn about my way of taking notes (the quick version):

• I'm not bad at taking notes when I really try, my problem is rather that I don't try
• I tend to structurally close sections (for instance adding borders) before they are really finished adding some interruption in flow when I have to fix this.
• I change style when I mentally change section. That's actually quite useful since it makes different parts easier to distinguish. Compared to my borders above it's much easier to come back to sections when style, rather than boxes, differentiate them.
• I like to headline my sections, sometimes that becomes counterproductive, for example I sometimes make up headlines before I really understand what a section is about making my final result confusing.
• In the beginning I wrote down stuff as I heard them, the more into the note taking I got the more I listened to a whole section before adding notes, this made the notes more relevant but sometimes I missed out on details. In most cases I would prioritize relevance, but I have to be aware it's not always the best choice.
• I organize my notes on paper as I organize the information in my head. I have a hard time writing down my notes in a more "reading structured way". This could sometimes be useful (I believe) so trying a similar practice with a more "live blogging" approach would be very interesting. Also, this could be an area where reading would be really helpful. I've not read so much of Markus Gärtner's work yet but I've understood from comments he's the king of live blogging so that could be one place to start...
• I believe some parts could have been better represented with visualizations. This is definitely an area to improve, maybe by doing a similar practice with just different constraints.

I'm pretty sure more lessons will be learned tonight when I sit down and look at my notes again (only did that briefly yesterday) but no matter the outcome tonight, this feels like a success! Hope it can help someone else as well.




... and by the way, right now retelling key points next week seems really within reach...

The context driven ad

Would you rather have...

... your doctor say:
Nothing is broken, just rest
-or-
Surgical suture, a cast and amputation, you can never be too sure

... your soccer coach say:
Due to their strong central defense...
-or-
4-4-2 like always!

... your kid say:
Will you teach me that?
-or-
Fuck you, school 's over!

... your mechanic say:
Of course I'm responsibility for my work
-or-
Broken? Sorry but according to...

... your scout leader say:
Let's put out the camp fire
-or-
Step 1, look for trapped survivors...

Would you rather have a:
Context driven tester
-or-
Not

(if anyone reads my posts, feel free to comment with your own favorites)

Test certification thoughts

Expiring date
Skill diminishes over time if not properly maintained, or at least I strongly believe that. Since a certificate says nothing about how the receiver develops afterwards it's usefulness as proof of anything diminishes over time. What would you today score on tests you passed in school? What's the value of a several years old certificate?

Memorizing information
The standard examination format is about memorizing all the, to the questionnaire, correct answers. That is not a proof of any skill but the skill of memorization.  Hopefully you've picked up stuff along the way but still, from a test skill perspective, nothing is proven.

What's the educator's target
An educational dilemma is schools being compared based on the average grades they issue. For the pupils, higher grades mean more options for higher education and jobs which is often higher valued than actual good education. I imagine the dilemma exists for certifiers as well. The certificate is what is used when applying for jobs so getting the certificate could easily become more important than actually learning anything. So would you as a certifier focus on teaching how to pass the exam or how to become a great tester?

Memorization vs Understanding
First, read the amazing post About learning by Janet Gregory.

I'm very interested in kids' learning. One thing I strongly believe in is, if you want to build understanding, helping kids finding their own solution rather than providing a solution is key. I also believe the same goes for educating testers. Providing answers is not very educating, coaching testers to think and question believes is. Certificate training is unfortunately the former, it's all about reading and accepting other peoples strategies in testing. Don't get me wrong, I still think there's a value in knowing what highly valued people think but only as guidance to your own solutions which are based on practice, critical thinking and experience.

Paying for what is free
Why pay for something that is free? What, apart from a silly paper, do you get by taking the exam? The information is free. You can even find tons of questions available online for free. In reality it means paying for nothing that helps you improve as tester. Might be reasonable for someone searching for a job (since it works) but companies? Send out a link to the syllabus and invest your money in a proven test coach/teacher instead of paying for something that is only valuable when looking for a new job. By the way, donations are a great way of funding great work so I'm not against the paying in itself just what you actually pay for.

What to look for as a recruiter
Certificates are probably nice, if nothing else it shows the person wants to work with software testing. However, a blog, twitter, recommendations, publications, experience, enthusiasm etc. are all way more valuable in my point of view.

ISTQB and certified testers
I do not agree with the ideas presented by ISTQB but that doesn't mean they are wrong or not valuable (or at least I can't tell). I'm also not saying testers with a certificate is worse testers than those without. The only thing I'm questioning is the value of a certificate. What does it really say about a tester's skill? My opinion: virtually nothing.

Why I've signed up for RST instead of buying a kick ass sofa and new computer

I tried to get this course paid by my employer but due to budget cuts and the fact another testing course was ordered to the company it was rejected. Instead I paid for it myself. So what drives me to this:

Most expensive things bought so far

1. My current apartment
2. My current car
3. Previous car
4. Previous car
5. RST
6. Stroller/baby buggy
7. TV
8. Sofa
9. My fiancee's computer
10. Bed

So why RST?

• Because the testers I admire and know in real life praise it
• Because the testers I admire and study recommend it
• Because James Bach has been the single most important person in my transformation from "well it's a job" to "I love this, give me more"
• Because it's the most respected course in the branch of testing I believe in
• Because I don't get a chance to be challenged very often at work and that's a fundamental part in how James teach
• Because I've studied the work of both James Bach, Michael Bolton and Cem Kaner with great interest
• Because I long term believe this will help me form a career I will really enjoy
• Because I'm in the middle of making my current work fun (not only for me) and I believe this course can teach me valuable tools for that
• Because I've never found a negative review
• Because I believe in skill and experience rather than assumptions
• Because it's a chance to meet other highly motivated testers
• Because I believe this will make me a more professional tester
• ... but most of all...

I've always been fascinated by people who turn what they do into an art, like a waiter who makes you wanna come back even if the food is crappy or the girl who cleans our stairwell who cares more about the building than all of us living here combined. The passion these people radiate and the level of satisfaction they seem to enjoy has always inspired me. That's what I'm aiming for, I don't intend to become better than everybody else, I just want to become the best I can be and inspire others to do the same... and that's something I believe RST can help me with.

... 25 days left.

Guided by Fun

This is actually a rewrite of my old blog post: Using Fun as your guideline. Reason being that I think the idea is good but it was poorly presented and too connected to our unique context in the old version.

Background
Documentation is generally not fun, so focusing on fun would leave us with chaos
// colleague

This summer we ran an unintended experiment in my team where almost all our time was spent testing and documentation only existed as casual notes not really stored anywhere.

What happened was we couldn't explain to stakeholders what we had done, why and what our current status was. However, we did get a lot of testing done so we pretty much failed to support stakeholders but did support programmers.

Was it fun? No! Why? It was frustrating and we felt unprofessional.

So we added some very basic documentation. When we encountered questions we couldn't answer, we first asked ourselves: Is this question really something we should be able to answer. If yes we looked at what we had to improve to be able to provide that answer, if no we politely explained this (I will touch the "it's not a choice" response in further down).

Guideline
At some point we realized that generally the better we worked the more fun we had. Turing it around would be: The more fun we had the better we seemed to work. Fun was a lot easier to relate to than "better" or "more efficient" so we stated what we felt was fun, asked ourselves if it seemed like a good way to work and, if so, tried to reinforce it. Here are our results:

• More time for testing = fun
• Understanding what we do (continuous learning) = fun
• Being able to explain our testing = required to have fun
• Knowing what is done and what is left = required to have fun

In practice we try to fulfill the bottom two requirements, in an as lightweight but sufficient way as possible so we can put as much time as possible into testing and learning (association to exploratory testing anyone?).

It's not a choice

When you don't really see a point in answering a certain question the response might be:

It's not a choice

Without going into reasons for that, both valid and invalid, let's talk about how to approach it. First, never (if possible) ask for what information someone wants, ask what questions you should be able to answer. This not only helps you find alternative information that might be sufficient but it's also something not too often asked so the stakeholder can't just go back and use the default answer.

If this isn't enough try to understand what the information/answer is used for (by asking questions, not by making assumptions). This may:

• Make it less frustrating to provide (since you understand its value)
• Help you find a better alternative
• Make the stakeholder more aware of gain compared to cost

Summary

Always trying to enforce things that make testing more fun is not a solution to every problem, it's a heuristic, it can be very useful in many situations but not all. Please also notice the opposite of fun is boring, not serious or professional. Instead I claim doing something in a boring way when there exists an equally good, or better, fun alternative, that is truly unprofessional.

An interesting set of skills

Look at the following set of skill:

• Ability to see unplanned ways of using a function
• Ability to see beyond obvious functions and attack "passive parts" as if they were functions
• Curious
• Continuing even though something is "generally considered finished", to see what happens
• Attacks any problem with an open mind
• Doesn't assume a common function necessarily works as it's commonly expected
• Won't give up just because something seems complicated or someone says it's impossible
• Finds great pleasure in finding new unexpected behavior i products
• Always have an idea about what to test next
• Deliberately and constantly practicing presenting any achieved result and how it was achieved
• Love to present ideas without demanding others to use them
• Always willing to help
• Creative
• Systematically covering function after function and when "done" unfocusing, looking for any abstract/general functions that might have been overlooked when looking at the details.

Sounds like the description of a great tester doesn't it?

So who is it?

A random one year old kid I observed while waiting at the hospital of course.

Think we have stuff to learn from her?

I do!

Think we're born with a huge amount of testing skill?

I do!

So where did it all go wrong...?

...

Using Fun as your guideline

This post is rewritten, please read the new guided by fun post first.

Very interesting statement from colleague after my presentation on Exploratory Testing long ago:
Documentation is generally not fun, so focusing on fun would leave us with chaos

Last spring I started on a new team as part of an organizational change. The goal was to create something less cumbersome and depressing than our current waterfall implementation. In our old way of working tester's have had time to prepare detailed test cases with instructions and god knows what information.

Things just went bad. We were standing in a situation where a poorly written strategy was all we had while code was handed to us: "Please test so we don't have to wait for months before faults are discovered and we have to dig into code we already dislike" (like we did before) plead the programmers.

So we did the only reasonable thing: We tested, we tested and we tested. Life was great! No public documentation! Success!

Time went by and the first hand over was made between me and the other tester in the team due to vacations. Chaos! I knew to some extent what was tested but I couldn't really say if anything was "done". Soon after he handed the work back to me as he went on vacation. Chaos once again. The team even started to ask us for test cases just to get some kind of idea of what was tested.

Was it fun spending all our time testing? No! Why? Because it lead to tons of frustration and a feeling (a well motivated one) of not being professional as we couldn't answer fundamental questions about our work.

Fun as guideline
Today we use fun as our main guideline in our internal test process.

These are our criterias for fun:

• More time for testing = more fun 
• Understanding what we test = more fun 
• Knowing what's been done = basic requirement for fun 
• Knowing where we're heading = basic requirement for fun 
• Being able to answer questions about our work = basic requirement for fun 

To summarize: On top of actual testing (incl. learning anything we need to learn), we put a layer of administration, as small as possible, to reach the basic requirements for fun.

In practice

• More time for testing
  Exploratory testing, removing anything that does not provide value to us, asking stakeholders what questions why want us to answer rather than what documents they want.
• Understanding what we test
  Experience database, ask questions, ask for presentations, involve programmers in testing discussions, read, discuss, pair testing 
• Knowing what's been done
  Test matrix (I'll explain that in a later blog post), SBTM inspired team internal test management (still have a lot to learn about SBTM though) and (at least) weekly test discussions
• Knowing what's next to test
  Compact test strategy, test matrix  and (at least) weekly test discussions
• Being able to answer questions about our testing
  Test matrix, bug tracker, backlog, test strategy

Things we fell we've achieved

• We are more motivated than before 
• We are a lot more efficient than before 
• We know what we're doing to a much higher degree (surprising result!) 
• We constantly learn things about testing and our product (= more fun) 
• Less frustration 
• We understand the code better and can write our own corrections / add testability ourselves more often (in our case this is a bit special since our product supports injecting assember instructions in runtime). 
• The test matrix creates more interesting questions than the test case progress reports ever did (once again: I'll write a post on our Test Matrix later) 
• Minimal waste upon changes. This makes it far easier to work in an iterative way 
• More lightweight administration makes test more available to programmers 
• Quicker feedback to programmers 
• So far we think we've found more important bugs this way, especially important bugs that are indirectly a consequence of what we've implemented (impacts we could not had anticipated) 
• We take responsibility for our testing to a much higher degree ("we probably triggered that case" is not enough anymore, instead we learn how to do it, implement the necessary testability or admit it's not tested and explains why). 
• We've stopped considering issues as something we need to "revert from"/work around and rather consider them as a chance to learn and improve. We've also learned that we can't really know for sure what we actually need before we've lost it a valueable lesson.