Friday, November 17, 2017

Live from Potsdam, Day 4 - Agile Testing Days 2017

Friday, 17 November came and I realized I had a full night's sleep!

With every intention of attending the "late keynote" and "women & Allies in Agile" sessions last night, I sat down for quiet time - and woke up at 9:30 PM, and I decided that it meant it was time to go to bed - so I did - and overslept. Missed lean coffee but had a wonderful breakfast chat with David Evans and  Marianne Djuist

Huib & Stuart are announcing the auction of the each sheet of sketchnotes for day's keynotes. Proceeds will go toward the fund me for Linnea Nordström, the 6 year old daughter of Kristoffer Nordström (a fantastic tester and many time speaker here at ATD) -  who is suffering from brain cancer who is going through an experimental cancer treatment that is not covered by insurance.

Roya Mahoob is presenting "Computer Technology as Agent of Change for Women in Developing Countries." Wait, what?  In 2013 she was named as one of the 100 most influential women in the world. I should mention that Roya is involved in leading the Afghan Girls Robotics Team.
Photo by Sabina Simons, used with permission

In 2010 she formed Afghan Citadel Software - yeah, a female computer entrepreneur -  from Afghanistan. In 2013 she moved to New York because of threats. I should mention that Roya is involved in leading the Afghan Girls Robotics Team.

"Through technology, we are reshaping how entire communities view women."

When she was young, there was an open field across the stret from her house. After the Taliban took over the country, the Taliban gather all the books from the town she lived in that were not Islamic or "approved" in that field and burned them. In her words, her view of the outside world went to ash.

The image of the fire stayed with her and instead of destruction, "The Taliban loved the darkness. Ideas that were not theirs were forbidden." The fire that remained with her though, was the fire of her imagination.

When the first internet cafe opened, her brothers were allowed to go in, girls were not. "I was told that the cafe had this box-machine that connected you to the world."

One day, she made a point of going in very early and was amazed. She saw the computers and saw the world could be opened to her through technology and the internet. 

Becoming the first female tech CEO in Afghanistan was nothing but challenges. Corruption, interference by religious conservatives, interference by social conservatives, all were obstacles to any form of success (ahem - Important lesson here for the world!)

"I believe deep inside all of us is a desire to change the world."

She was asked to arrange/sponsor a Afghan robotics team made up of students to compete at an international robotics competition in Washington DC. There were many applicants for the team, but only 6 who had family permission to travel to the US and had any idea what robotics involved. After being rejected for Visas twice (TWICE!) by the US, until Congressional and White House pressure pushed them through the Visa process - they came and won a silver medal.

They demonstrated that with support and education, even from countries considered non-technology centers, girls have as much potential as any boys.

Girls everywhere deserve the rights to select their own future and deserve their own voice - as well as access to the same education and technology many in the world believe should be  reserved

Jose is giving tokens to each of the girls.

Dear Lord - one of them has the guts to address the conference. My heart is breaking at the story. Notes on this later. (Nope - not posting the notes. sorry. )Not just the suffering inflicted in their own country, but their treatment by certain governments (ahem) because of where they were from and their religion.

"My parents support me and because they support me I can be here."

Her father was killed by Daesh for supporting her education and trip to the USA.

And a standing ovation.

OK - I left out that they are building a tech school. I'll post a link to more info when I find it.

I'm a little overwhelmed by this and taking the time to assemble thoughts and clean up blog posts. Sorry, Matt, we'll talk later.


In George Dinwiddie's talk on improving gherkin.
Major point, in BDD & TDD, "I don't write automation to detect bugs, I write them to prevent them." This is a sense that some people expect things from software development to be simple. Yet the point of the 3 Amigos is to help determine not just what was needed, but hwat really was possible.

The point of BDD is to do 3 things - Elicit/discover requirements is part of it the rest? well...

If you are writing tests the same way you are doing it manually, consider you are doing it wrong.

If you start out with THIS -
Why not do THIS instead?
Cut it into pieces - and get the result Liz pointed out (ahem)

Instead of detailed... stuff - distill to the essence of what you are trying to get to. Because - keep it simple. Don't worry about the UI - Worry that the message is the same - for example - Does the kitchen timer indicate when the time is up?

"Every word in a test should be directly relevant to its purpose" - Marick
"Tests should contain every detail that matters, and no detail that doesn't matter." - Emery

"I blame the British (for US companies tendency to not reimburse for alcohol at meals). Australia got the criminals, we got the Puritans. Someone else having fun should not be allowed."

Focus on the rules - focus on the intent - Look at the interesting cases that MIGHT have something of value FOR them. REALLY!

Very good lunch! Conference attendees are dwindling - fewer & fewer.

Jose is giving some announcements - he seems really tired - I think we ALL are!
And they are auctioning the sketch art murals of the keynotes - 1st one - started at 100 euros and ... sold at 225. They just passed 200 Euro for the 2nd... and that ended at 250.

The third is at 175 and going... up...

And NOW -
2nd keynote of the day...

Maaret Pyhajarvi is giving us Leaning with Osmosis.

Maaret won the MIATPP award last year.  She is presenting on some ideas that seem inline with much of this conference. She has been constantly growing and changing herself and how she presents informatioon. She describes herself as a polyglot feedback fairy and a polyglot programmer.

Osmosis is movement through semi-permeable membrane without recognizeable amounts of energy being spent.

While in school, she worked very hard to be prepared for class. She was regularly called on in her Sweedish class to translate passes from Sweedish. While her classmates were amazed that she could translate it, they did not know that she spend a great deal og time preparing to be able to translate the passages.

For a long time, she was the only tester by profession - and the only woman on the team. She was the only one to get excited about bugs. She was also the only one who was not really excited that the developers were able to do... something... with only, say, 3 classes.

And then there was this comment -

"Women only write comments in code."

ummm - right, Testing is generally a good environment, given the gender balance among the testing community.

Still, things changed...

Her daughter came to school age. And Mareetp bought her class a book on programming. And - SOMEhow, her friends all liked doing programming - so she tried it to. And she LIKES it. THEN - they tried pair programming - partly because they were doing it naturally.

Then she met Woody Zuill and the idea of mob programming - where 1 person is typing and loads of smart people are working with them. At first, she rather rejected it - because - well - the team did not collaborate. very well. The team rejected the idea - "it's just silly." and other responses.

But trying it at meetups and with random people helped.

Finally, she asked a co-worker to try it with her, so she could learn. THey went from typing letter by letter to moving forward fairly freely - she had seen the developers doing things and had a strong sense of what was happening and what developers did on a regular basis, given the situation...

Soon, she found that she could try things and it would be OK. THEN! There was less of yours and mine attitude, and it became an "OURS" attitude.

Then  - the began finding something interesting - Correcting things on the spot, by the mob finding things - removes ego from the environmant. It also helped learn what was relevant. While she slowed them down by inexperience, the slower pace allowed for more thoughtful thinking.AND she was able to do some exploration during these sessions

Programming is like writing - Getting started is easy and it takes a lifetime to get good at.

The point of mob programming is that you can get the best out of your team - and learn from each other all at the same time - and everyone takes on ownership

(and a breakdown of mob programing roles - driver, navigator, etc.,)
HUGE POINT - Best ideas win over credit!


Learning in a mob is a way of moving toward learning things you did not expect ot learn.
Mob techniques can work in testing - ET, Automation, Unit, Perf & Security - which makes perfect send (to me) Mareet explains how she learned about programming from mobbing with her team, and they learned about testing by mobbing with her.

Very, very good.

Discomfort can make you learn - the idea that doing something that made you uncomfortable might mean that you can learn something new - or  relearn...

OK, a word of apology. My battery was completely flatlined after that last sentence. Shutdown Now. I need to go back and check photos, etc., I missed getting the last of Mareetp's talk - I have some photos and tweet's I'll try and get in place to rebuild it, but...

The batter was SO drained, I could not get Janet Gregory's closing talk either. GOOD THING THE PHONE HAD POWER! Someone tweet-stormed her talk! I'll be incorporating that in here later.

In the mean time, you might get a sense of it here:


In the meantime. I had a number of conversations that last day and evening.Dinner with friends, return to the Dorint to pack up and return to the pub for the farewell drink - the parting glass as it were.

I'm sitting in the airport in Dublin at the moment finishing a bottle of porter going over pictures, notes and smiling at the memories. Pulling things together for a recap later in a new blog post.

Thursday, November 16, 2017

Live from Potsdam, Day 3 - Agile Testing Days 2017

Morning came at the usual time in Potsdam on November 16, however many of the conference attendees missed its arrival as they had been having much fun following the Agile Games and ATD Cabaret. Much singing and music and jokes and fun was had, and SOME (ahem) were feeling the effects a bit more than others....

Still, that is one of the aspects of this conference, and many conferences. People getting to know each other, swapping stories, asking questions, sharing ideas and sometimes sharing advice.

One aspect of this, beyond the evening events and other random conversations that grow organically at events like this, is Lean Coffee (introduced at ATD by Lisa Crispin & Janet Gregory). I mentioned this in the Day 1 blog and today, after inhaling a quick breakfast (someone was up later than intended... ahem) I wandered in to see how Lean Coffee was going, and was pulled into moderating a table. OK! Dive in head first!

What is Lean Coffee? It is a time blocked method of discussing ideas, problems or exploring questions where people bring topics, vote on them, then discuss them until a resolution is reached OR the energy for the topic has been expended. The idea is to share ideas, investigate things the original person had not considered and come to a take away.


I've moved into the main hall for the morning events. Jose is going over "lost & found" items (including someone's tablet - THAT will be missed!) Ash Coleman is talking briefly about the events later today around inclusion and diversity. AND we're getting ready for this morning's keynote, The Pothole of Automating Too Much with Paul Holland.

Paul is kicking off his message that (for the opening aspects at least) is challenging the conventional wisdom held b y many: Automated tests are not likely going to give you all the benefits that many people believe it will.

Automated scripts will only look for the things it is programmed to look for. It takes a vigilant human to find other things. He uses a metaphor around the roads of the United States for software.There are so many raods (paths) we can't really "test everything.


Problems - 
There are more kinds of problems that an automation can be programmed to recognize...
  -  Vigilant testers can observe and evaluate a very large variety of outputs and also vary the inputs let us find more problems than we can predict.

There are more checks to automate than can possibly be written;

Some things are too difficult to automate effectively;
  -  Complex pass/fail algorithms;
  - perhaps it can be dome more quickly by a human;

Investigating reported failures takes a long time;

Automation is expensive to build and maintain;
  - High cost to value ratio;
  - Sunk cost problem (so much spent so far, abandoning it is hard)

What about -
A strategic mixed approach:
  - Automate critical paths;
  - Automate paths with the highest use;
  - Do NOT write automation for all failures found in the field;
  - Consider the cost of automation vs benefit -
     Difficulty to create;
     Difficulty to maintain (frequency of changes)
     Difficulty to analyze failures;
  - Augment automation by performing human testing
  - Automation is excellent at showing that the code CAN work;


Grabbed some lozenges, and a coffee and headed into Toyer Mamoojee's session on "Coexistence of Legacy and Cutting Edge Technology Systems". AND - the conference staff bring in a birthday cake for him! Yeah. these folks are awesome.

I met Toyer Monday evening, after having been told I needed to find him and have a chat - and we did! Bright tester from Cape Town, South Africa. I am really looking forward to this.

Here we go -

For this discussion Toyer is defining legacy systems as:
Business Critical;

Lack of support;
Skills shortage;

... and a couple others I was too slow to type...

so why keep them?
Customized over time to the Org;
Change could negatively impact business

Their environment looks a bit like this:

Oh yeah...

Deployments are manual (very manual);
Achitecture - Too much logic build into legacy systems to easily update/decouple;
Processes - Slow running processes, including tewsts;
Delivery Process - Some teams less Agile than others...
Skills - Different systems required different skills.

Solutions -

Their approach (over time and not this neatly - Pete comment - they never are...)

Deployments - Automate, automate & Automate;
Achitecturally - Built APIs, Micro-services, Rewrite complex batch processes;
Processes - Faster Running processes, quicker test execution;
Delivery Process - Functionality, Freeze, E2E meetings, SOS (Scrum Of Scrums)

Skills - Internal vs External recruitment (right skills for the right system)

Testing -

Automated Testing -
  Automate what you can with commercial tools for legacy;
  Open Source for Cutting Edge/newer tech
  Push to get CI/CD;
  Automate at different levels!

E2E Cross System -
  Centralized E2E testing tool;
  Daily SOS meeting
  E2E Meeting before stories get developed (measure the impact on teams)

So, what was the result?
Originally, they had Excel for test case tracking  & QTP.
and now...

And the result?
Cross skilled workforce;
Everyone engaged, relevant & up-to-date;
Get the right people on the right system;
Maintain/expand buisness competitive edge with less risk;
Faster delivery time - monthly releases instead of quarterly


Some good chats, dealt with some minot work items AND slide into "An Alien Visiting MY Office" with Viktorija Manevska. (a little late... sorry)

Starts a new job - AWESOME! And she hears they are going to do Scum - AWESOME! And she learns how they are doing it - AWESo... uhm

So, she went and took on the task of reading and learning about Scrum. She found the typica; "THIS WILL SAVE THE WORLD" articles and then some that were less than enthiusiastic.
So, she looks at what is around there. And how people look at things -
So, since she knew that things weren't quite right - so she decided to get a certification (cultural thing - certifications lend greater authority - your mileage may vary).
Except, things still weren't quite right. Stuff wasn't happening the way it seemed like they were supposed to be.

Except - Scrum is not a problem fixing framework, It is a problem FINDING framework.

Key question...
Is the value of the product developed by Scrum?  -  Hmmmmmmm

Except Scrum is a bit like the blind men and the elephant...You see scrum based on how it is exposed to you. Hmmmmm.

So, if we know what the customer wants and we have some ideas on how to make this happen, does the development method/model really matter?

So, if we focus on the end result, what can happen? Working together, not worrying about the ritual forms, what if we share ideas and collaborate and not worry about what to call it? Instead of doing a daily stand-up, particularly when people are all working in the same room, what happens if we just do stuff?

THEN she lands a new position (same company) and finds out that.... not so happy. The rainboes & unicorn thing was more a tangled mess. She began looking at items, making mind maps and researching the intent of the such things and.... "that is not your job - you are a tester."

Quotes Paul Feyerabend - "The only principle that does not inhibit progress is: Anything goes."

So, she let them go and do their thing... Allowing people to fail, then supporting them when the problems arise can help them begin to change their minds from fixed positions to a more flexible one. By working with them to find shared spaces - they began coming to her to find potential problems before deployment, then pairing then... everywhere.

By looking at things from an external viewpoint, like an alien, she was able to see problems, then share the means to help people see things the same way.



Slight change in plans. After an amazing chat with Cassandra Leung over lunch, have I mentioned how remarkably bright she is? Right - I must rest a bit... and deal with stuff from work - yeah, day-job stuff. I hope to spend some time in the open space shortly.

See you all in a bit!

And Congratulations to Jose Diaz - the master behind the conference - for officially becoming a German Citizen today!

Sometimes taking a nap is an excellent thing. Other times, having a nice relaxing cuppa (or 3 or 4) and conversation with interesting people Can be just as good, if not better. Thanks to Rob Lambert, Alex Schladebeck and Chris George for giving me much to think about.

Open Space is an excellent way to explore ideas and have a chat with people about items you may not have considered.
Sliding into the LAST track talk of the day (refreshed and ready to go!)
Our Journey to Reduce Manual Regression Tests - presented by Thomas Fend and Trinidad Schmidle.

They work at Bachmann Electronics, a company with a broad product portfolio, long lived products, a development team of around 40 developers and 12 testers. The majority of their software products are released at the same time, typically once a year.

There is a fixed issue verification system that tends to go straight to the tester. The were massive numbers of bugs being reported, however, when the development team reported a as "fixed" it went straight to the test team, not to the person who reported or raised the bug.

By changing that loopm so the person who raised the bug had first crack at the fix, or at the lease, had the change explained to them, they were able to streamline the process and reduce the amount of rework. THIS lead to more time to work on more new features.

Now, with a common acceptance criteria definition, the team & product manager are in agreement as to what needs to be done.

Then there was the "feature veto" issue - Features are completed very lat with little time for thorough testing. When everything else seems to be better, the tester might raise bugs, get very unpopular and get told to leave them alone.

By getting testers involved early in the process, this has been reduced.

Then there was automation. Yeah. Some tests are executed each sprint. The BIG ones are run after feature freeze - once a year. Not all the tests are fully automated - there would be manual configuration before starting some tests. Because, well.... yeah.

Each sprint, testers present test results in the test department. As an incentive, the number of tests being run each product cycle, through automation.  Result was increasing to around 65% of the tests.

This helped improve stability, helped find bugs when there was time to fix them, and help find and fix "blocker" bugs.

There was limited time to make regression test really happen. So, they pulled in developers to help. This was PL, but...

By working together, working on some basic action - the time to regression test dropped dramatically. They also reduced distractions during "test weeks:, no meetings, etc.,

By introducing a mix of static and dynamic code analysis to check out the changes that have been made, they were able to restrict the interruptions, limiting meetings, encouraging test pairing, etc., They were able to reduce the amount of effort to do regression tests and do them far more efficiently.

Conclusion - Through communication, teamwork, detailed planning and focusing on things needed RIGHT NOW, they were able to make this improvement where they can run the full suite in under 2 weeks!


And NOW the lights come on in the room. It is REALLY hard to see to type with no lights (ahem)...

Right - something else is coming up, - AH yes - the closing keynote of the day with Liz Keogh.

Jose is back up with a few announcements and introducing Liz...

Liz Keogh will be speaking on "How to Tell People The Failed and Make Them Feel Great."

And asserts that Failure is Essential. Whilst on a project, a couple of developers had tried to install a tool to help do testing. It took a couple of days and they gave up. And got yelled at. And new rule was implemented that NO one did anything without getting permission from the BAs. Except - they made that rule for EVERYTHING.  All creativity ceased. And it became a far less fun place to work.

Enter Cynefin - (the new version)

Obvious Domain - sense-categorise-respond ; Best Practice(s) -
Complicated Domain - sense-analyse-respond ; Good Practices ;
Chaos (Chaotic) Domain - act-sense-respond ; No effective constraint ; Novel Practices
Complex Domain -probe-sense-respond ; Enabling constraints ; Emergent Practices ;

Dan North - deliberate discoveries
Unknown unknowns - 2nd order unknowns

You failed - but we expected to because... and that's OK...

We want to help people improve. Before we go nuts with this, consider what do you like about the person - how about respect them? What is it that anchors the relationship? What is it that  you value them for.

There's the sandwich thing - where you put "the problem" between 2 good things. That's ok - sometimes...

But why - if they screwed up, they probably know it. Let them know that you know, and that they have succeeded in the past and will be awesome again;.

Radical Candor/Care - come out and tell people something is wrong, but come from a place of care. Let them know the person is valuable and valued, and they can make some small corrective action and be awesome. Because SOMETIMES not doing that will lead to much bigger failures.

Failure only "hurts" because of the impact. Safety lines can help - and can help people explore safely. Always work toward buying time - making time - by avoiding the trap of "running out of time" - allow yourself options, just in case.

Remember that "root cause" is misleading. There are usually (often) multiple contributing issues. Sometimes they may not be obvious. What can these things be?

Try scattering around ideas. They MIGHT just land and be able to be acted on immediately. OR, they may lay dormant for a long time, until the context changes. THEN it can take root and grow.

Etsy - home of the blameless review. This is an interesting idea - let's see - often times this gets translated as "the testers screwed up." One thing in the "blameless reviews" - or "learning" reviews - instead of  "who did what..." try "what happened" and "when were decisions made."

Take the blame out and look at the steps and decisions made. That might show opportunities to isolate the issue and act as a fail-safe. You will always miss SOMETHING - so mitigate the risk.

Most organizations struggle with Agile stuff, because stuff is hard. Changing directions can be a challenge. Supporting the ability to change direction is a challenge.

-- The best way to tell someone they failed is to not even mention the failure.
Come from a place of care. Anchor what is valuable. Show what is possible - the bright future ahead. Work on building safety nets.

All of this is part of solid, positive growth... unless England is playing in the football match


There are a couple of other items coming up this evening, but first, supper!


Wednesday, November 15, 2017

Live from Potsdam, Day 2 - Agile Testing Days 2017

Wednesday, November 15 dawned... well, not really. It was pretty foggy when the sun rose, so I'm not sure there actually WAS a dawn. However, it did get lighter. Conference attendees and participants made their way to the morning activities of Lean Coffee, a morning run and yoga (yeah, I know I did not mention the run OR the yoga in yesterday's post - mostly because I do not do either.)

There is a full slate of activities for today - keynotes, track talks, workshops - AND! Games! TESTING GAMES! Great fun.

Jose is finishing morning announcements and the keynote from Claudio Perrone is about to start - Popcorn Flow.

Interesting title slide - with "Change is hard, make it continuous!"

Here we go!

Operational excellence is not enough, Most ideas for software ideas (and others) are really... crap. Too many times we end up with crap ideas getting delivered really, really fast - because we get told that faster is better. Innovation is key - so you get crap delivered by jet engines or crap on a stick (with spikes)

So - we want to improve, Except Improvement, real improvement, takes change. and CHANGE is a bit like Godzilla. So, don't worry about Godzilla - he's pretty big. Look at single cell organisms, they are changing ALL THE TIME.

Popcorn Flow is an anti-fragile philosophy -

Popcorn Flow Principle 1 - If change is hard, make it continuous;
Popcorn Flow Principle 2 -Everyone is entitled to their own opinion, but a shared opinion is a fact;
Popcorn Flow Principle 3 -

OK - it is too dark in here to really type... so changed seats and now I have a bit more light - maybe I can keep up

Problems & Observations - What is getting in the way of innovation (or anything else)?
To beat inertia, everyone will see problems - when multiple people share the view that something IS a problem, it goes from an opinion to being a FACT. There is a shared view of an issue that is supporting inertia and getting in the way of not delivering crap.

You can form shared observations to create and elicit options (get a bunch of people, like 3 together and explore the ideas around. Experiment - like - "We might try BDD or Code Reviews or Paired worked to maybe make things better..."
    - pull quote! If there is salt in the cake, it is already too late! We can't fix it!

We can talk and agree on experiments, look at their expectation then TRY them! What is the result?

Set an expectation - then see what happens . Not meeting the expectation is not a failure - it is a correction of the anticipation.Be prepared for that form of failure - but - learn from each one.

Fail fast is not the point - LEARN fast is the goal!

The thing about "being agile" vs "doing agile" is not something to worry about -

(I perhaps celebrated a bit too much with my friend Huib... sheesh)

If there is a continuous flow of experiments (the core of agile) then what limitations are there? Some may work really well - KEEP DOING THEM - some may not work - STOP those, try something else.

Try "Here's a problem as I see it and some ideas that might help..." with the manager - then experiment with the experiment model.

DING! Quality is something we worry about - what about the value we get from something? Like, a conference talk? Does a "high quality" talk deliver value to EVERYONE? Or is value to the customer without regard of the "quality" of the presentation - or software (ahem).

Set yourself up for learning - Do something - oberve what the results are (for you and your customers) Is there a correlation between the 2? There may be, but not always - so look for the gaps.

And he slides into an example - His (then) 5 year old son had an idea - he could sell snails!

First few experiments failed - welp - give up? What about trying something else?.So, instead of giving up after the 1st 2 tries - he launched a 3rd idea - a comic book about... snails. Launched - landing page - AND... collected 1 Euro per donation, and send updates with pdfs in the future.

First night - 24 Euro. and it just kept going up - 1 in 6 conversion ratio (that is pretty astounding)

 Don't be afraid to think big - really - like - end world poverty...

Keep thinking - keep innovating.

RIGHT - sat down and helped a speaker prepare for her session (SOME one changed all her slides.... last night) I know, I still have not loaded the images from the keynote - I'll get to them a bit later - I promise.

And HERE we go!

Wearing Hermione's Hat: Narratology for Testers - with Marianne Duijst.

Narratology is the study of stories - the narrative and other aspects of any story. (warning academic theory stuff coming)

The Fabula is the series of related events - logically or chronologically - the "plot". There there is the Story - the presentation - ANY presentation, the manifestation and colouring of the fabula - the plot.
The TEXT is the medium these are presented to the oberserver or reader -

Building blocks to consider -
The AUTHOR (the one who write the narrative) who is likely NOT the narrator - they are not the same person (usually).

So - J K Rowling presents the story, but the Narrator herself is unnamed.
We experience the actions thru the experience of the characters (Ron, Hermione and Harry) - THEY will experience things based on the different perspectives.

For example - 1st quidditch match - Harry nearly falls off his broom, etc., and we see the story thru Harry's perspectives - however Hermione sees something else.- the change in perspective.

Hermione's Role is to understand and figuring out the fabula / plot /events of the story...
HOW? She gathers and interprets information from MULTIPLE sources - multiple stories. She stores this information and retains it for use.

This is usually not obvious to people who read the story once - usually people read the story once and leave it. Multiple readings will shed more light and reveal more information as we can get past the mechanics.

This works for software as well! Code? how often do we look at code? Maybe once? What are we missing? (We never presume we miss anything - just as we don't believe we miss anything when reading a story - once.

The question is - can we work around this?

Who do we trust?
Rita Skeeter does this weird thing of talking with people - and twisting anything she gets into something else. Hermione, by observation, realizes how Rita works - and finds a way to present an alternate story to the same facts - the same detail.

She - Hermione - listens to all sources - including those that appear to be minor r insignificant - like, House Elves. She realzies that elves such as Doby and Creature have extremely powerful magic - magic stronger than hers. She also is able to retain and present this to others because she gained the understanding needed.

This can set up shifts in understanding from the various perspectives - we change the realities - based on this shifting perspectives. The change in paradigm follows this all - for example - Snape kills Dumbledore in book 6 - and is slagged as irredeemably evil - until we see the reading of Snape's memory.

We are actively NOT looking for all the pieces of the information that can be used - because they do not meet OUR narrative - what things do we hold that we are not considering deeply. Our closely held beliefs/stories /understanding can we wrong. We don't like that. It is uncomfortable.

Context drives everything - Time is part of the context - as is place - The Time Turner allows for shifts in time to allow us to see the actions Place is another context. We know what we know because of where we are.

The challenge to Harry - which Hermione takes on - is to enable others - where Hermione teaches Harry about the information needed - aqnd shows Harry, Ron and others on how they can do the same thing.

The problem is, Hermione does not always have all the information needed to make the best decisions. She builds a model based on incomplete, if not faulty, information. Just as we do with software.

For software people, we need to find ways to think differently - what happens if we do this - what can we infer from THIS. What happens if we change...


Lunch and many excellent conversations. More on those later -

Now it time for the 2nd keynote of the day - A Practical Guide to Testing in DevOps, being pesented by Katrina Clokie - the AWESOME Katrina Clokie.

When she was young, she had a teacher named Miss Perfect (really, that was her name) who taught the kids in the class about Atoms - and how they are everywhere and make up everything - including how they could move atoms around by moving their hands in the air - which is made up of... Atoms...

So, when DevOps began to be a thing, many testers looked at that and said "Oh, that is for Devs and Ops folks, we're not in there..." Except... well, Atoms

In Agile, we have everyone helping with testing and helping with quality.  And then we have others added in the mix of Agile to come back as .... Dev Ops - so Infrastructure, Support, Analytics - everything, no?

Citing the equally awesome Dan Ashby. his model - where testing is involved everywhere...


Once upon a time.... Katrina's org was having a lot of issues. Specifically big red lights going off when builds were made - and things went wrong regularly.  Machines dying and stuff happening and conflicts and - ick.

By splitting the Selenium Grid from the Jenkins Slave, ...
Things got better - - a LOT better.

Now, while this was not a typical "DevOps item, the fact was, that Testers led the drive to make things better. Awesome!

They also test in production. Ummm - yeah - Did I mention they are a bank. Testing in production? Really? Dangerous. Not really.

Monitoring. watching - looking for behaviors that might inform us on what is actually happening.

Because - in a mature DevOps environment, the testing is all around - at every level. Because testing is not looking for bugs - it is looking to see how the organization can be informewd about the bahvior of the software - before and after it goes to production. Really.
And a post to the LeanPub site! YEAH!


Sliding over to Getting Ready for the Cloud with Sabina Simons. Sabina is a very bright, intelligent young woman from the Kitchner-Waterloo area of Ontario - practically a neighbor of mine! Only around 4 hour drive and an international border crossing away.

And we're underway - OH YEAH!

She is a Development Manager at D2L Corporation. She was given an option of 3 choices for next position in the company - 2 of which she had already done, and the third (the one this story is about "scared the crap" out of her...

What does "the cloud" mean? Welp - their background was to move to an AWS single tenant instance - fine - why?
They wanted to be able to move faster and serve customer needs more quickly and focus on getting product out to people and not the logistics of how to do that. Their customers are educational institutions at all levels, from pre-school to universities.

Can they get this to work? Locally? Globally? How does this actually WORK? What in the world does this look like?>

Change infrastructure - except they have a heap of a mess of legacy... stuff.many, many, many levels of ickiness (my word - family friendly blog)

Some 20 streams of work present, their code base was comparable to... a park with trash everywhere. No test instances, not test cases, not automation of any sort. With a mindset of getting it sorted - their goal was stated as "leaving it a little cleaner" each time they did something. Addressing immediate legacy needs by making incremental improvements.

Experiments! Canary Testing - small actionable instances, small changes to track what is being done. Leave benchmarks and small unit tests documented in the process - and set changes up and run things in the perf lab... things are awesome! Except the code path they were interested was not executed.

Complex scenarios sometimes take unusual solutions - like, how to set things up and how the conditions exist in production. Really.

Benchmarks are fine, making them drive forward. The set the throttle and exercise it.
Things worked great! Except - when they opened it up - stuff hit the fan.

So, now they have a significant problem. Loads of people pointing fingers and loads of "YOU SCREWED UP!" So, deal with the situation as it is - look at what process flow can be tweaked to improve the situation and open conversation. Stepping away from the blame game and being open in communication can actually help calm everyone down and make things better.

Home grown automation tools - (looks like some instrumental graphs she is displaying - and yeah, they were were instrumental stuff - which is awesome - I get to ask a question!)

Tracking behavior through various models - good solid reliable information. Watch what is happening and look for leaks - Really look in the corners, the places that appear to be OK - particularly when things are ... a little odd.

Use the code analyzer to track what is being used - presumptions & beliefs are grreat - BUT - go prove it.

Failure mode testing -

Always sounds great until people realize what that may mean. In short - How do you figure out how the system will behave in different "suboptimal" ways - usually catastrophic!

These start with What If? stuff - and working through it. Sabina's team worked through the issues as a team - (YEAH!) the question is always figuring out the stuff that is likely to happen.

Enter the Master of Disaster - writing alerts to handle with some level of grace things that are likely to go wrong.

Takeaways -
Lead by example. Move boldly and show actual results;
Experiment - What Happens if I Do BLAH!;
No Excuses (really) - everyone has stuff that needs to get done, make things happen;
Share your story - internally, externally - make the world a better place....


Right - I snuck off to a corner for a few minutes quite time, then sat with some new speakers and had a lovely chat with them on talking in public and working up the guts to stand up and bare their souls in a way that many people don't realize novice speakers do.

I then did some preparation for the Agile Games night, where I was running a table of mixed small games confusing people and offering puzzles that required them to set aside their preconceptions and immediate beliefs and look at the "call of the question" and the words actually said and written.

Great fun for everyone. I gave away many stickers for prizes and people had fun. There is some socializing going on right now that I intend to return to - with a "tester cabaret" which seems to be great fun. IN the meantime, I've had excellent conversations today and tonight which have given me much food for thought. More on that later.

Monday, November 13, 2017

Live from Potsdam, Day 1 - Agile Testing Days 2017

Tuesday, November 14. A nice day dawned in Potsdam. Just a bit of fog (which strikes me as fairly normal this time of year, from what I recall.)  I had a nice lie in followed by a good breakfast (the Dorint Sansucci does a lovely breakfast, really), a nice coffee followed by getting ready for the day.

I did manage to snag a bag from the conference volunteers, with a t-shirt, conference goodies and the various sundries one might expect (although a postcard from Agile Testing Days is a fun idea!)

Lean Coffee is going on right now and if I scurry, I might just make it!

HAH! Full house! I have NEVER seen a Lean Coffee THIS WELL ATTENDED on the first day of Agile Testing Days. I am astounded - and very pleased for Janet Gregory & Lisa Crispin, who pioneered the idea here several years ago, and it has simply grown since.

What is on after Lean Coffee? The opening keynote to the conference followed by my talk in the  same room!

Jose Diaz is presenting announcements and introducing people who are working very hard. The committee and volunteers are still in the lobby working to get everyone in the conference - IT PAYS TO COME EARLY! Your volunteers would appreciate it! You would too. (I've been on both sides of the table - it is easier if everyone helps out.

The Afghan Girls Robotics team are here. There is a drive to raise funds for medical help for Linnea Nordström the daughter of Kristoffer Nordström, a frequent speaker and friend of ATD. (

OK - WOW - Next year is the 10th edition of this conference AND Jose just announced there is a special discount available - 30% off the registration fee for Agile TD 2018 - if you register by 31 December!

Now - the Keynote!

Jez Humble (@jezhumble) is talking on how people make excuses (and call them reasons) why continuous delivery wont "work" for them in "Continuous Delivery Sounds Great But It Won't Work Here."

Jez "wrote the book" on Continuous Delivery in 2010 and was told the idea was crazy. SOmehow, many (not all) companies have begun doing just that. The goal is to make releases boring (his words) so they can be pushed out any time, and not stuck working  over the weekend (ahem).

The goal is to push to production in a simple manner, simply! with no interruption of service and even be able to upgrade hardware infrastructure - remotely. - If it is not possible for you - it is not a problem with CD or Continuous Integration - it is a problem with your infrastructure - or worse, your configuration.

"We all know the 'works on my machine certification' is useless."

He's walking thru the basics of how most shops do development, check in, integration, etc., The KEY is knowing if there is an issue. If you can't fix what you just merged in - revert. If need be, blow it away, stop what you are doing, rest and do it again. Really.

Citing Brian Marick & testing matrix.

Automated testing - using a machine to help you do what you need to do and don't want to waste a human being's intelligence.

The point of CD is NOT to replace testing or testers. It IS about using people wisely - using their talents to advance what the work is supposed to be! THIS IS REALLY, REALLY IMPORTANT.

The case he is making is that you should be able to reproduce you production environment configuration(s) FROM VERSION CONTROL. Data is different, yes - but the configuration should be able to be pulled. Need a test environment? Pull it, run an instuall, run a simple check to verigy the build was good - and BOOM - Bob's your uncle.

"Reasons" why people don't adopt CD -

1. We're heavily regulated.
Hogwash (not his word, this is a family-friendly blog)Amazon is a fine example (look for a nice photo when I geta chance) Amazon is HEAVILY regulated (although most people don't realize or think about it - and they are releasing every 11 minutes...

He's moved on to his experience with GSA (in the US) setting up to assist US government organizations to release software FASTER. How? 269 of 325 mandated security checks are done through Make them common and stuff simply will WORK.

WHY? The US Federal Government is the most heavily regulated environments there is - and until January, they had successfully deployed tools to speed secured delivery on a regular basis.

Most change management is about covering your ass in case things go wrong. For MOST organizations, Change Management is nothing more than CM Theater - it looks good but is worthless.

2. We're not building websites.
Ummm, you know that that is hogwash too, right?

Most of the time, people have a problem - not what they think it is, but they are spending more time doing things related fixing problems than to catch them before they get deployed and end up spending a fraction of the time on new features. For example - HP Laserjet products @ 2008.

Ummm - firmware.

The issue was - simply - "we don't have time to get this automation stuff written, we need to make new features so people want our stuff."  Sound familiar? Except the features were simply dependent on too much stuff.

Their solution (not recommended for most orgs) was to scrap everything and start over.

OK - He is going really fricking fast. REALLY Fast - the pictures that are getting loaded later.

The issue - ISSUE - is HP - ended in 2011 with 23% of their "dev" budget being dedicated to automated test development. It was astounding - (there is a slide going in here shortly)

Architecture is key to making continuous delivery work - no matter the structure or environment (runs a short video of a mainframe-based - green screen system using automated tests against it - AND CD concepts.

(he skipped reason 3)

4. Our people are too stupid.
"Where do you get your really brilliant people who do this work?"
"I get them from you."

Teams create outcomes - Bad systems & processes will overwhelm good people and good teams. The POINT is to get people to a point where people can excel.

Make the environment one where people feel free to excel and discover innovation. When you give people the opportunity to do great thing, they will.

"When you say "our people are too stupid" you are absolutely right. Except, the stupid people are not the ones you mean..."

And he is plugging "This American Life" - - awesome radio show on NPR and a fantastic podcast. - The John Shook episode in particular. It is a great episode (I listened to it when it went out originally.)

Make things better - ALL THE TIME. Management needs to focus on helping people MAKE things better. This is the crux of the issue. Really!

Wrap up -

Agree & communicate on MEASUREABLE business goals (not handwavy rubbish)
Give teams support and resources needed to experiment;
Talk to other teams (particularly the one that piss you off - go buy them lunch and LISTEN);
and quote Grace Hopper -
"If it is a good idea, go ahead and do it. It is much easier to apologize than to get permission."

and into questions...

{I'm a little disappointed that Susan Bligh is delivering her talk AT THE SAME TIME as I am giving mine. She is talking on QA/Testers and their relationship with BAs. Sounds really good to me. I hope to catch up with her and chat on this.}

Bailing for now - I am about to present. Be back later!


RIGHT - talk went - we'll see how the feed back comes, it seemed really short and really fast (I might critique myself later)

Grabbed a quick drink, chatted with some people and slid (late) into another track talk.


Sitting in Elisabeth Hocke's session on "I am Groot."

Came in late so I missed the introduction. Talking about fear of failure and concerns around that. Slit into finding inspiration - boss gave her a copy of "Agile Testing" but Janet & Lisa - then the company began getting into social media, including Twitter - so she joined Twitter and found .... Lisa and Janet - which set up conversations there and her learning grew. (she is giving ideas around key ideas - I'll be listing them briefly as she goes)

She has now slid into Job Titles and how ephemeral they are. In short, don't let the words define who or what you are. Be what you are and find the right words to describe it.

Behavior drives change. You can change your behavior, You cannot change OTHER people's behavior BUT you can begin the process with yourself, and see what the influence is.

Mix up your learning - look to other tools around how people learn and how you learn. Drive yourself to force understanding. Don't get comfortable (ahem) with what you are and do - keep forcing change on yourself.

Constantly reinvent yourself. Really. Change things that you do - find things that are new to you - blog posts, interesting ideas in twitter streams or other social media - look for things that look interesting but you know only a little (or nothing) about. Reach out around that and try it.

Share responsibility. Work with your team/co-workers on what testing is and learn from each other. The "whole team" thing does not mean not being a tester anymore - it is instead a way of continuous learning.

GAH - had to bail on Lisi's talk (sorry! We'll catch up!)


Couple of maintenance things then back with Cassandra  on test automation.

Her topic is "5 ways test automation is like sex..."

Right - THAT might get people's attention.   The real question is, do I have a future in software testing if I don't do/know automation...

 This grew out of a question in Ministry of Testing discussion forum... and here we go!

1. All the cool kids are doing it.
Well, yeah, this ties in with an assertion she made on twitter, that test automation is a bit like high school kids - they talk a lot more about it than they are actually doing it. Most job adverts in the UK (where she works generally) focus on automation testing experience. So, she went looking - 1st 5 posts she found, 4 mentioned automation straight up, the 5th, down in the sub context, was "we don't have automation in place, but we have a need. If you want to do this with us, come apply and help us.

2. There's pressure to "do it."
General press shows that "automation" or "robots" are replacing people - except they aren't really doing it. Things like "AU could threaten up to 47 percent of jobs in two decades - reports."

Yeah, cuz adding the word "report" to the end of a headline makes it real, right?

There is "fake news" and "fake information" and "alternative facts" - and always has been since the beginning of time, including the fake "studies"  Assertions need to be followed up.

The thing about test automation, are precisely the same as was said about self-checkout in grocery stores/shops.  Right.

3. There's a lot of MISinformation.
Loads of myths and urban legends but real, measurable information is harder to come by. People may cite other people - those considered "reliable" and still, somehow, they have not checked sources either.

References Alan Page - references Richard Bradshaw. Should testers write automation or should "tool smiths" write test automation? Page & Bradshaw think the later. (I'll find the references in twitter - I remember the conversations from a few months ago...)

4. Good people are wanted with or without automation.
The "community" may be the bubble - and may be an echo chamber.
Yet, the community of testers give a solid presentation

5. It (automation) is not the enemy (or is bad)
We need to find ways to contribute to it and find ways to make use of it to make better products. Tinkering with tools and dealing with people are flip sides of the same coin.

Lessons from Cassandra -
Don't believe the hype (it's mostly rubbish anyway);
Understand you reasons for wanting to "do it" - or not;
Benefit from and contribute to it;
Don't let it be your excuse;
Understand your value and have confidence.

** Be a successful testing with or without automation. **

RIGHT. I completely missed the 2nd keynote of the day because I was talking with the very intelligent and engaging Susan Bligh.

I am now sitting in the video replay of There and Back Again: A Hobbits/Developers/Testers Journey.

In the beginning - the start of the Hobbit clarifies what a hole is, by challenging the assumption that a hole is something known by rejecting that "known".

This sets up the core message - People know what they know, but it is fallible.

Testers tend to become quite comfortable. Many like being in that nice safe spot. Testers tend to react to the class bias instituting their OWN bias.

OK - I'll fill in the rest later...

Had some good questions/discussion and headed out of the room for a longer discussion. That took a while! THEN I got pulled into several enjoyable conversations with people who were asking questions around what my presentation had to say.

Short interview and sneak into Ray Arell talking about Safe-to-Fail.... Failure. Yeah. awesome!

He's asking questions around "Who in the end is afraid to fail? What does failure look like? Wgeb bugs (failues) are found in production, who is it they managed to get there? Persistence? For example - let's talk about Fail Safe (speaking of oxymorons)

What if the failure was something... odd. But the issue was not us, what if our experiments were flawed. What if we create a naive experiment? What if we have an issue with people being afraid to fail publicly? What if the concerns of the people is not physical but emotional safety? What if they are both?

High degrees of uncertainty - do we have an issue with the core way we do things?

We are defined by how we find value - by helping other people over come challenges and fix problems and drive conversation, which drives ideas....


Getting a bit tired. Sat for a moment & chatted with Mike Sutton. He's been having a busy time of it at the Open Session/chat area. Frankly,

GAH Battery is going!
OK - temporary replacement - Let's GO!


Closing keynote of the day - Poornima Vijayashanker is presenting on ... ick

How to Onboard and Train New Hires into Happy and Productive Employees.

OK, starting with the story of how she started - the new grad, lands the first job and finds herself in... not the world's best gig. The CHALLENGE for new employees is often the company, not the employee. Most organizations are pretty top down (that is why there are vbosses, right?

THe problem is, when the immediate boss is absent (physically or emotionally) or a bit of an expert in everything. The one who is telling people his or her version of how awesome they are.

So, what does this mean? Well, consider this, most people want to be good employees and contribute, etc.,

Consider this - What does the 1st day/week/month look like?
How soon does the new person feel they are contributing?
Watching cat videos does not count. Really.

Consider, how long does it take to get the new person to meet their new team - not the department, just the folks they are going to be working directly with.
Also, how long will it take, how much work will they have to get their machine and environment setup and WORKable - if you make it a screening process, you (the boss) screwed up.

Don't be that boss - help coach people, get them in contact with people to guide them. Really.

Get them involved - and WARN them if there are ... issues ... that might trip them up. Biff works well with most folks, but clashes with Dorf. Also, consider inter-departmental challenges - these guys like showing THOSE guys how in-control they are. Sometimes a word of warning can help people not walk into a minefield early on in their gig.

By getting people involved, they can make things work FOR THE COMPANY.

Given a new hire will feel connected early on, ask them what they think of the org, Ask them what problems they see - maybe at 60 or 90 days from start Maybe 100.

Ask them what they would suggest about direct problems they see. Why? It gets them involved and INVESTED.


Right. Tonight is the MIATPP awards and banquet. With a theme of "Super heroes" - yeah, people are encouraged to come dressed as a super hero.

This should be ...


Loads of Cat Woman costumes, wonder woman costumes, super man, super girl, captain america and some costumes I have no idea what they are.

Big news is, my friend Huib Schoots was named as the Most Influential Agile Testing Professional Person (MIATPP) for this year. I am very happy for him. He's a good man.