Live! From Agile Testing Days 2016! Day 2!

Wednesday, December 7 - cold. cold cold cold. Overcast. Did I mention cold?

Good thing we're still inside the Dorint Sansoucci in Potsdam.

Last night's award dinner and party was a tremendous success. The winners of the Software Testing World Cup were announced (see yesterday's blog post for that.) What ELSE was announced was the Most Influential Agile Testing Professional Person (MIATPP).

The winner of the 2017 MIATPP was Maaret Pyhäjärvi (@maaretp)!  Terribly pleased with this announcement. Congratulations to Maaret! Well deserved.

This morning Michael Sutton is warming people up for the first keynote of the day. This will be Diana Larsen (tweets at @dianaofportland) whose topic is Liftoff: Start and Sustain Successful Agile Teams.

(Umm, internet access is toast right now, what’s up with that?)

Diana opens with the recognition that the in open space events, the right people for the discussion are those that are in the ones that are in the room at the right time.

And we’re having a reprise of the issues I did not mention in yesterdays keynote – man – loads of challenges with sound this morning – and internet access.

When Diana got into “Agile” she hung with some of the XP guys and have been engaged ever since. Do you use some form of Retrospective in an Agile team? Yeah. She wrote the book. Literally – Agile Retrospectives.

The point of the “Liftoff” book was to help teams get to where they want/need to be – so they can achieve Successful High Value Delivery

That means:

What the customer wants and accepts;
That creates value for the business;
In a timeframe that fits the customers’ needs;
Easily maintainable and supportable;
Leaves the team members with increased capability and eager to work on the next deliverables.

Thus people can deliver useful, high quality software and where the team learns enough to employ what has been learned in the next project. Thus, we need to avoid deathmarches – because, well, at the end of a deathmarch, we’re… ummm… dead.

Are we really ready? Do we know what we need to do to drive to a scenario where those things actually happen? If so, we’re ready for a Liftoff.

Now, if you’ve launched and having problems, it might be wise to stop and relaunch. After all, many of the stories, anecdotes, etc., presented by the “experts” are actually relaunches of the original effort.

Teams a Complex Adaptive Systems (CAS)

One challenge is that teams are collections of individuals, within a large collection. Hence they are a system. Specifically a complex system (that is a very specific term, I’ll try and post a link to a definition when the dust settles).

In addition to being a Complex System, teams are ADAPTIVE – they change! They adjust and adapt. THIS IS A HUGE POINT when getting ready for liftoff.

One aspect – are the teams really cohesive? Do they work well TOGETHER?!?!

Promote Team Cohesion with Liftoff Design

Group Cohesion is a multi-faced process

Conditions for CAS?

What Containers do you want to establish?
What DIFFERENCES will show up?

Set the conditions PROPERLY for team learning – 

How? Remember these are HUMANS! (duh) Keep the team emotions ALIVE! People will learn best when their emotions are engaged! Appeal to the sense! A dill boring lecture is generally a terrible way to lean for most people.

Do it for real – learn by doing it. Keep people interested by having them do the work and learn to master the real work! Exercises are OK to start, but get to the real deal QUICKLY!

Keep stuff obvious – “Start Obvious, Stay Obvious” – make sure people can get a quick grasp of what is going on and needed.

Focus on the flow – no really. This is what will help drive learning.

When you are able to do this, THEN – Keep the setting first!

Choose Liftoff Activities (Pete comment -wisely)

Get the executive sponsor involved and ENGAGED – They can help explain the greater purpose and goal. You may consider “typical” Sprint 0 types of activities. (Pete note – I’ve seen this work really well, when guided properly)

Training Boot Camps might be of value – Consider both Retro & Future-spectives, etc., etc.,

No matter what else – DO include Collaborative Agile Team Chartering (this is a must!)

Chartering Model?

Integrate Purpose (Inspire)
Alignment (Collaborative)
Context (Dynamic)

Get people involved EARLY who can help guide those things – Produce Management, Sponsor, Facilitator, etc.,

Why?

This is where we let people know that this is worthy work, that this is something these people should invest their time and energy to act on this work. We can talk about

 

Purpose?

Product Vision (how will someone’s world change? What is the effect?)
Team Mission (what is the nature of the work that will need to be done to make that happen?)
Mission Tests (examine and TEST the mission – then write some tests that will help us measure and engage in the tasks at hand? Are we on track?

Alignment – This is how we commit to doing the work TOGETHER!

Simple Rules guide a system (pretty much all systems) and guide cohesion.
Core Team – why have people been engaged to be part of this team?
Working Agreement – stuff like, “What is DOD?” “What are our core hours?” “How many meetings will we have & how frequently?” – Stuff that actually guides the work.

Context – This is the piece that is usually most ignored.

How does this team fit with the needed work and how does this work with the team, the effort – and how does this work/team/effort fit into the broader system of systems

Go ahead and say Resource – really 

Committed Resources can be work space, tools, training, servers, etc., etc., Plan for that

LOOK FOR RISKS! (have the team help with this so they understand better what they may be facing. THIS IS A BIG DEAL.

The Charter - 

This is a living document, not a dust collector or door stop!

Help teams build the energy & momentum to help teams get thru the liftoff. It can be hard. Don’t make it any harder than necessary.

And we're over time!

Break now - then I present!

===

Right gave my presentation - handed out a LOT of chocolate bars. Had a bit of fun. Now up in the room changing shirts (it is WARM down there today!) and having a cool drink. I'll be back shortly!

Oh, Look for a live blog review of my presentation (which was recorded and will be played back later today!)

===
 

Right - I'm at a testing conference, so I did some testing for work between my session and lunch - and NOW I'm geting ready for the afternoon where Huib Schoots and Alex Schladebeck are getting ready for their keynote. However, Michael Sutton is up to something and this should be fun.

So ... Once upon a time... there was a lovely princess and an ugly ogre... Yeah. This is on telling a story.  

One upon a time, when Huib was a school boy, he had a hard time sitting still. He got put behind a pinboard so he would not distract the other students. He went into programming and… got trapped in tules.

Their goal for today is to focus on telling a good story – well.

Clips are being played –

I have a dream – Stay hungry and stay foolish – Vulnerability is not weakness – Yes we can

Right, so the point is, these people were telling stories in a compelling way. If you come back from holiday or vacation with a bunch of pictures, how do you describe them? In a story or in facts.

1 jeep 1 driver;
3 zebras, 1 jeep

Telling compelling stories does not come easily – it takes practice. Lots of practice. But – we musdt make it compelling. How?

Freytag’s Pyramid -
Expositon (background)
Rising Action (conflict)
Climax (high point)
Falling action (results)
Denoument (wrap up of the story)

And they play an ad from the Superbowl, with the puppy & the horse from Budweiser – the “Best Buds” tagline series.

By sharing stories with others, we understand each other better and we feel like we are part of a group, a clan. Don’t tell numbers, tell stories.

The stories we tell as a group, as a culture, helps us remember and make us come together, e.g., the Unicorn with ATD! 

If you put a series of specific bits, without context, purpose or motive, people will tend to make their OWN stories based on their own … thing. People will fill in the gaps of a story or bits of facts and build stories out of them. That is part of how telling partial facts, disjointed, in a compelling way can draw people to the conclusion you want them to reach without actually saying, precisely, what they want people to take away.

Conflict is crucial to storytelling – the hero/villain thing is based on this. It also tend to have the impact of changing who is the hero, based on the perspective the context or condition in the story.

The nature of stories can, and will, change people’s brain chemistry – so “sad stories” can be used to evoke the emotions of people to donate to charity or go to war.

So, what about testing?

A story is a tale about the status of your product.
 

A story is how you tested it.

If out test reports are charts of number, a couple of things can happen. They can give all the information in a simple manner. However!  Remember the bit about how people will build a storu to fit what they have and fill in the gaps?

Yeah. That .

Numbers are important - Stories are more important.

So, getting into the question of WHY? This is a crucial point. When looking at projects, ask “Why?” first – long before “How?” is considered.

How?

Demo & sprint reviews;
 

Personnas;
Risks;
Bugs & Familiar problems;
Tests/charters;
Consulting;

All of these impact on stories and shape the story of the project. Checklists can help – Stories fill in the blanks.

Software & software development is not about computers. It IS about things that benefit humans – PEOPLE!

So Huib & Alex are having people tell stories – 1 about “What are you passionate about?” and 2 – what was the dumbest thing they’ve ever done in a project. Point made.

Alex relates the story of her violin. How her dad would play recordings and have her “draw what she heard.” She told the story about how she learned about it. How the music given her by her dad was the greatest gift he could give her. Playing music can, and will help express the world. (Pete Comment – Oh yeah, should have brought my small instruments – instant session!)

Mind maps sent to people do not communicate well. They CAN be used to drive a conversation, and a story.

==

OK - Minor delay. I have 1 more interview session to do. Until THAT happens, I'll be liveblogging a thing on... Releasing without the numbers, by... me.

Came in late - I'm wrapping up a summary on various policies like lock down, no high priority bugs, etc., and some examples - healthcare.gov, Rhode Island benefit system, Australian Census, etc.,

So, if these disaster projects had solid metrics showing that the software was ready,  how could they go wrong? What was the real issue? What do the "hard facts" tell us about the software. I suspect that it DOES tell us about the state of software development management.

Facts are awesome because they are facts. Except... wait

Emotions have a much stronger impact in making decisions than outside data points. What are we really deciding on? How do we avoid having P-0 or P-1 bugs? We make them P-2! Or - we just don't write them up!  

In most Agile shops, there are some level of communication, some regular meetings, touch points. Yeah, the problem is Standups can get really long - But, can we have an impromptu meeting? Can we pull together the people involved from each group, and talk with them? How is your part of the project going? What are you running into?

The challenge is that it is possible, if not common, that management and individual work teams have different perspectives on the same body of work. Get the people together who are working on this - and have them talk. "How do you feel about the state of the project/release."

And I describe the study from the Journal Science - Durably Reducing Transphobia: A Field Experiment on Door-to-Door Canvassing." - Link Here

And I cite Lord Kelvin - and... I get pulled out for another interview. I get done with that and needed to check in with work. 

Right now, I'm in the Open Session room - loads of fun, more people than I expected.  Two sessions going at a time - cool! Here's Janet Gregory's tweet on one of the sessions.

Open Sessions are time boxed, self-selected discussion on topics the participants suggest in the room.

Up next is a short break followed by the closing keynote of the day - followed by testing games, a nice cabaret and a bit more fun.

Right then - Closing keynote of the day from Keith Klain (@KeithKlain) on Lessons Learned in Selling Software Testing. Large organizations have heavily outsourced an commoditized. 

Warns against false experts - quotes Kahneman - the question of people being considered experts because they said they were experts.   Wonders about the presence, or lack there of, on skepticism.
 
If you get up on stage and speak, you should be open to a greater amount of scrutiny.


States that when he left Barclays, a job he loved... involved self-questioning - "I don't know what the @#$%&! I'm doing"

Suggests people get out of their bubble and do a challenge of their own beliefs.

Keep your objectives in mind.

Testing is an information based science. We should test to learn something. And questions the intent to "automate everything." Organizations spend a lot of money on stuff and get no real value out of it - not even the simple stuff.

Cites the "Leprechauns in Software Engineering."

We have to fight against people selling crap all the time.Some 50% of enterprises use some form of a Testing Center of Excellence. Except they've spent so much money on the TCOE they don't want to walk away from that.

Smarty Pants syndrome - when criticized, recede into a third culture where they ... "tiger cub?"

Criticizes passive aggressive word correction - like "suggesting" a gentle change or correction when trying to be "nice." 

Compares the Hilary Step on Mt Everest with a career in testing. (Some 40 feet of sheer ice face to make the final summit of Everest.)

Looking for information about your business? Look at the company's publicly filed papers for public or privately traded companies. Listen to the quarterly stock performance calls. 

Critical bug test - what was the last critical bug you found and what would have been the impact to the business if it had gotten out.

Testing is a service, not a servant. (Pete's note - I am not certain he and I have the same definition of those words.)

Quote Feynman - We are never right, we can only be sure we are wrong.

The reason why it's so hard, is because it is so hard.

and into Q&A - 

With THAT! We have the Sponsor Speed Round, the Sponsor Reception and a Beer Testing! and Agile Games!

SPONSORS

THANK YOU FOR MAKING THIS EVENT POSSIBLE!!!!!!

Devoteam

D&H 

Easit 

here

jamo Solutions

iSQI

SeQis 

OTTO

Novatec

TestObject

SEASIDEV

Kreuzwerker

Thanks to all of you for sharing information about your company!

And now - the Reception!
 







 

Live! From Agile Testing Days 2016! Day 1

Tuesday, December 6 dawned cold. No, really cold. I'm from Michigan, this was cold. Snowing and still bright. Good thing I'm inside.

The morning started with a lean coffee session hosted by Lisa Crispin and Janet Gregory. There was a good turnout and really happy exchange of information.

The official opening of the conference - alas, without the regular host Jose Diaz, who is home sick. Filling in for him was Mike Sutton (@mhsutton) - really nice and out-going guy. Smart and crazy friendly. In the middle of the opening came... the Super Agile Person! and a small cast of characters portraying and playing out A Christmas Carol, as applied to software testing and Agile methodologies.

This set up the opening keynote of the conference, by Abby Fichtner, on twitter she's @HackerHhick, presenting "on what's possible." She begins by talking about how she got into software - after her dad bought an Atari (hey, 1980's!) and the two of them began writing code together.

She walks though her undergrad work and talks about how she got into computers and ... hacking. She also talked about the challenge associated with words. Like, how "hack" originally meant, an innovative workaound of a physical object - like - model trains. Except this was in the 1950s and the model trains in question were being done by engineering students at MIT trying to figure out how do drive specific reactions through electronic controls - an early form of programming.

She moves on to "haters gonna hate" - talking about how people with interesting, innovative ideas often get derided for moving forward with things that make no sense to anyone and look like toys. Like, telephones... airplanes... a small gadget called, an "ipod" or something like Amazon Web Services.

All of those things were derided (some very recently) as of no value and the person pushing them had gone round the bend a bit. And the detractors were proven fabulously wrong.

And she moves to an interesting idea that "Evolution is the ultimate hacker." It is less about engineering and more about making things work - that serve a purpose and will survive. For example, if an animal needs to be flexible, and fast, to not get eaten, they either all get eaten OR they develop the abilities and physical traits needed to survive - flexible wrists, wings, etc.,

She moves to human invention - how a long time is taken to get the ground work in place so that INNOVATION can ACTUALLY happen. We tend to see "innovation" as a magical moment and we don't see, partly because it is missed by most people, the painful work to make it possible to see the possibilities and maximize the potential. For example, driverless cars - the whole robot car thing. First one was made in 1925. Yeah. It has taken a while to get to where we are today.

Creativity & serendipity have a relationship. According to Abby, a variety of studies have shown that when comparing children's learning abilities and creative abilities to "innovate" - those with neat, organize thought processes, those often reward at school for being "good students" are often those who do not do the "innovative work" needed - that is often the result of people who have more chaotic thought patterns.

Many times, they are the people who overcome huge obstacles and creat a new world for the rest of us.

You gain strength courage and confidence from exery experience you have faced
 - Eleanor Roosevelt

Art is what we are doing when we make our best work.
- Seth Godin

When we reach out with courage, and do something in spite of fear, we make amazing things happen (she is going really fast - it is nearly impossible for me to keep up - sign of a really well-laden presentation in my mind.)

By creating art (or anything) that is something that defines us as being different and unique - not being part of the faceless masses who blend in and live lives of conformity.

It is by reaching out and creating and daring that make magic happen (she was a year or two behind me at Hogwarts. Different house though.)

And she brings back reference to her blog Hackerchick blog (- Pete note - Yeah. It's good. Read it You don't need to agree, just read it and think.)

Important note - Success may come from creativity. Be careful that the same success does not limit your creativity! This is a common problem. Keep challenging your own views and your own self.

OK - great quote during the Q&A - If something scares me, there is magic on the other side. (She's not a Hufflepuff.)

BREAK TIME!

SO, I stepped away for a couple of interviewing sessions and missed the first round of track talks. However! I'm back in time to hear a new speaker, Carin Eaton (@Caz_Eaton) from Cape Town South Africa.

This is an interesting idea - she's taking the "tell a story about your testing" to a literal example - Her slide deck consists of artwork that strongly resembles illustrations from a children's book. And she has a small booklet and is reading a story - the story of how her company has migrated from a Waterfall model to a more Agile approach.

She's describing the "relationship" between her company and Waterfall as a friendship by default, even though the relationship was less than totally beneficial. The problem was that sometimes Waterfall hurt people's feelings and they did not do their best work. Then, they met a new person, Agile.

They found that they could be friends with Agile, and Agile could be quite nice. As more people through the company met Agile, they found that many things they had been looking for became suddenly, easier. The people began to speak out and ask questions they had not before.

The hard part was that sometimes, people were a little afraid of change. Some people found that getting to know their new friend was a more work than they wanted to do - or were willing to do. They set up a small group to lead the effort. Then, they found that "doing all the things" led to a turmoil - stirring all the pots and not serving any food. (great analogy for many groups in an agile transformation!)

Instead of working in isolation (a common approach) they reached out to share ideas and pair/team on the effort. One issue they realized was that they had not had shared understanding of what the intent was, even though they "knew" what was supposed to happen. They had fallen into a common trap in Agile Transformation - they were trying to change how the organization functioned, by doing things the way the organization had... always functioned.

By reaching out to people in the organization, by sending surveys and questionnaires, and making them as personal as possible. The result was people responding in greater numbers than others had previously.

By reaching out, it helped people see that the task group needed people to be involved for the benefit of the comapny. By doing small things, with small amounts of input, they were able to help people overcome their fear of what might happen if things didn't work. Result(s) seemed to be mixed, except people began to act more openly.

By getting leadership to openly support the effort - beyond simple lip service - but getting into the effort and showing personal interest helped overcome certain levels of fear. By opening up processes, and in some instances installing tighter expectations, e.g., requireing a "show me" that an effort was ready to be tested beyond those who were working in the immediate task - a demo!

A "reverse demo" was also introduced - where testers walked developers through scenarios that needed to be exercised. The result was a closer pairing in work where testers and developers interacted instead of acting as if a wall was between them.

Training was important - not just in techniques or practices but also in other areas. Most important was people being engaged in the training - Not just the lecture type, but also the hands-on exercises. Most adults learn better by actually doing the work - drawing on the challenges to learn instead of being told what they would learn.

AND NOW - Carin is citing Matt Heusser's workshop from Agile Testing Days 2014 on Lean Testing as providing ideas and insights to use and try. She is also listing other ideas and exercises they make use of that they picked up from their experience at this conference in 2014.

OK - she's begining her wrap up - Question Everything. Participate not spectate. Lookf for the "big picture." Remember that the key is to do things that make sense. Not every approach will work for every problem or situation. Some techniques work really well in some situations, some do not. Look to see what is working, don't think that because you start with an approach you are committed to that approach only. If it is not working - Change it.

OH! Really nice touch. Last slide she has a picture of her team - the ones who were leading the efforts she was describing in the talk. Oh. And she had pictures of squirrels all the way though. Yeah, so squirrels.

-- Lunch Time --

Right lovely lunch conversation with a whole pile of people - too many to name - and I'm going to be late to Vasco Duarte (he's @duarto_vasco on twitter) if I don't scurry...

Vasco is talking on NoEstimates and software testing. He asserts that Estimates are more dangerous than Unicorns. I think the Agile Unicorn gor up and left in a huff. I am not sure he understood what was meant (Unicorns can be very sensitive)

The concern is that Estimates can be very limiting, constrictive guesses. And companies bet huge amounts of money on them. And people don't really see the problem except that so many times they are wrong. And the blame gets laid on the ... well, never mind.

And so we have estimation meetings and estimation meetings for the estimation meetings and the es... yeah. You get it.

Some Ideas (Principles)

1 - If you do not trust your process, don't try and improve it - dump it and clean up the mess.
... wait - what? No such thing as unicorns? (Pete comment - Dude, have you ever seen an angry unicorn? It isn't pretty)
Products get released because we need to make money or serve customers or both. Sad fact is, most estimates don't help with telling you much useful information in support of that purpose.

2 - Shorten the feedback cycle.
He assers that ,...
Cost (Duration) = Essential Complication * Accidental Complication
Ummm, consider - a 2-point story when the project is a big ball of mud is different than a 2-point story after you've been working on the software for some time. One will be much closer to reality, based on experience, the other is a random guess - and still both are measured for the same "weight" in duration - so they are "the same".
Do we spend time estimating how long it will be before we can work on a task before we actually get to that? Ummm - Look at the number of items with story points on items in the backlog. OK, so how long have they been there? Ummmm - yeah.
(Pete note - Yeah, dude, I know. this is the 2nd opportunity to make a Trump joke. Yeah, I get it.)

Now citing studies by Capers Jones & Scott Ambler as authorities on software failure rates.
(Pete - comment withheld so I don't get kicked out of the conference and the country.)

sigh

OK - back on track - there is a lot being said and I am missing much of it...

Speaker suggests "Testing for Value..." look for the value of the project.

Focus on what can be done in a block of time for specific reasons/goals. Idea to implementation & deliverability can be made shorter. Short & to the point.

Instead of testing for functionality, try testing for what people will benefit from the effort. Can the software be used beneficially now? How about when the next feature is finished? What about the feature after that? Stop trying to deliver more features and focus on the value.

---

When ypu can't do that, when you can't determine the value, then look at features.

Estimation is waste. Reduce the impact it has on your business.
Measure progress only with software that is running, has been validated (by some measure) and is being used.

Setting targets outside the normal performance of the organization is dangerous and corrupting.

--

System where you work has predictable outcomes. Learn what they are.

OK - Extra point - Projectsd are not the right way to deal with software. (Yeah, there's a #NoProjects thing)

BREAK TIME

With the Keynote finished, I have more "not in a session" responsibilities, so I'm going to miss the next block - BUT - I'll be back as soon as I can with Lightning Talks!

TTFN -

Other responsibilities are now completed and I'm set up in the room for Lightning Talks. Chris George (tweets at @chrisg0911) from Cambridge Consultants in England, is sitting next to me. Bright guy. Really smart guy and a good tester. I met Chris at my first Agile Testing Days. He impressed me then and he still does.

Sitting in front of me is Janet Gregory - YEAH! THAT JANET GREGORY! ( @janetgregoryca  'nuff siad)

And the talks are starting!

First up is Gil Zilberfeld (tweets at @gil_zilberfeld) talking about how so often the easy stuff is really the complex stuff. His examples are things like... Waterfall - easy to explain, really hard to do well. Then Scrum - easy to explain - really, REALLY hard to do.

Next up is Mark Winteringham (tweets at @2bittester ) on ATDD Paradox. OK - talking about acceptance tests and how they can do good stuff and avoid... sucking. You can't really automate some things with the most common tools. The challenge is to identify the tasks that need a little (or a lot) extra scruitiny. These tend to fall under one of the levels of complexity described by Jerry Weinberg ( @JerryWeinberg) in his An Introduction to Systems Thinking. The more complex systems require a different level of thinking.

And Lalitkumar Bhamare ( @Lalitbhamare) - Thinking about Session Based Programming. We know about Session Based Testing - Can we do something similar with Session Based Programming? Yeah, Programming... If we can do time boxed, focus work in testing, can there be value in doing the same in Programming. Sessions can be limited or keyed on specific ideas. Some can be considered similar to the constraints in testing - we need to look at the similarities before we dismiss. (He has a really good point. Many of the tasks do bear similarities worth considering.)

Next Up! Alex Schartz)  (@alexschwartzbln) ! "Forget the Red Shirts, here come the Tribbles." (I sense trouble ahead...) Why do we treat service people as throw aways? Why not treat the SERVERS as throw-aways ... the red shirts from Star Trek, (original series) OK, so those are the red shirts, how about the Tribbles?

Tribbles were nice cute, little beasties. They had a nice "trilling" sound that, strangely calmed the crew (human) of the Enterprise. Except... the things reproduced (Pete note - at rates that leave rabbits in awe.) Flexibility is strong, can we do something with lower cost that will make life better - and remember Servers are disposable?

Next up! Melissa Pontes ( Tweets at @melissabpontes) from Brazil! (One of our fellow Software Testing World Cup Judges!) She is talking about her experience working with training blind & visually impaired persons for testing. (With a video) Point of the video is that people with limited physical abilities are challenged to participate fully with society - particularly those who are blind or visually impaired. The challenge is often with US - to help them become more than what most of society expects. People who are smart, intelligent, good thinkers with capable minds should not be off-set by external limitations imposed by others - typically people who are themselves blind to their own imperfections and shortcomings.

With THAT! We are getting ready for the closing keynote of the day from Michael Wansley (The Wanz - @teewanz). After THAT there will be other activities for the evening, including the Winter themed party, dinner and the presenting of the prizes for the Software Testing World Cup for 2016 and the Most Influential Agile Testing Person award.

Until then - BREAK TIME!

And Michael Wansley (tweets at @teewanz)  launches his keynote with a riff from Thrift Shop... and the line "this is fucking awesome." Yeah - THAT Micheal Wansley ... and he's also a software testers.

So, he's talking on "From Waterfall to Agile, The Advantage is Clear." He talks about his work at MS, working on XP (gold) and talks through the stuff he worked on in that. First major point - Software is supposed to be so good, the people using it are not aware it is there... In HIS world there is one other major point - "Testers are the gatekeepers of quality."

Why? (GASP!) The simple fact is, in his world, the stuff he worked on and is still working on, needs to be so stable that people don't need to be aware of how the software works. It needs to be bullet proof - as clean as possible with an experience so simple that it is intuitive.

That was the system he grew up in. Test plan, test cases, software... test and kicking the software back until it is as perfect as possible. The challenges are that working in isolation is a challenge. (ahem)

After talking about his music and touring and sold-out shows. He finds himself back in software testing at Tableau Software. There, he's working in an agile environment in a massively expandable environment.

Ad-hoc work is encouraged - TO A PURPOSE - You exercise against pretty much the world. People have already exercised "the functions" and then his group finds itself dealing with pretty much everything else. Because, the challenge is, building environments that emulate customer environments.

They have moved to quarterly releases - massive large releases. And they then support loads of versions because releases are supported for a fairly long time, until they roll off. Not everyone finds the same things, but yeah...

Agile testing is looking for all the problems all at the  same time, Learning, discovering, exercising (paraphrasing - cuz, he's talking faster than I can type & no slides for me to cheat off from!)

Awesome analogy - Software testers are the rear right wheel (except in the UK & a few other countries). Why? You can't see it in the mirror, it does not steer the car, it just lets the car get down the road.

Simple, eh?

The flip side - be smart enough to know that other people are probably smarter than you. Recognize it. Learn. Intelligent is good. Smartest - that can change. Don't hang your hat on that.

"We are the power in the Powerpoint presentation." Yeah - he said that. "We find the things the customer should never, ever see." He said that too.

So, the great challenge is to test a piece of software that has already been tested. We are looking for software items that customers can find that, somehow, we're expected to find something that people might encounter. Edge cases are what they deal with and find. the stuff where "no one would ever do that." Yeah - that stuff.

Testers can search through the software and find the weird uses there may be.

BING!

Documentation is not for you - it is for the person that FOLLOWS you. Deal with it - and document it as well.

** OK - I lost a lot of the keynote as I had to help test a piece of software for work. Yeah, Testing while in a testing conference!

Stuff happening tonight - there may be updates!

Cheers - TTFN

Right - Prizes were announced for the Software Testing World Cup. It was a really, really tight contest. There were seven very good teams to critique.

And, here are the results -

Best Branding / consistency of message - Team Bug Terriers, Russia
Best Bug Award - QB Lab Technomaniacs - South Africa
Best Team Spirit - One Day Testers - Brazil
Holy Cow Who'd Look for THAT Bug - RT Pest Control - United States

3rd Place - Quest Aoteara - New Zealand
2nd Place - Team Mentor Graphics - Israel
1st Place - Pan Galactic Gargle Blasters - Netherlands

Live! From Agile Testing Days 2016 - STWC - Day 0

December 5, 2016 dawned cold, a little foggy after very heavy fog day night before, and with a beautiful hoarfrost coating the trees. I had a very long travel day yesterday which resulted in me showing up nearly 2 hours late to the conference center and hotel, and quite tired. The result was I unpacked, took a shower, dropped off the materials I was asked to bring for the conference, had a glass of beer and went to bed... and overslept. BUT! I was down by shortly after 9:00 and had a nice breakfast with George Dinwiddie, with a lovely conversation related to some blogging that will happen on Tuesday.

After enough coffee to revive a corpse, I scurried over to where the Software Testing World Cup 2016 Finals was to take place this afternoon. I met with a load of people and interviewed some of the teams, judges and other participants for a video that is being prepared for this year's test contest. At lunch, I checked in with the conference organizers - and was given a present as a thank you! A pair of Vic Firth drumsticks with my name and the name of my blog on them! AWESOME! Thanks so much!
.
In the afternoon, the Testing World Cup launched into full blown progress, testing a beta version of a product currently in production in Germany. It looked to be an awesome app (frankly, I wonder when a version with similar functionality will be available in the US.) We checked in with each team a couple of times during the contest, chatted briefly on video and observed their approach to testing a piece of software none of them had seen before.

I also took a bunch of pictures and tweeted a lot! Here.

During all of this, my "partner in crime" was Claudia Badell (tweets at @claubs_uy). I met her at Agile Testing Days in 2014. The several hours we worked together convinced me she is a really solid tester, a very good thinker and a remarkably thoughtful and kind person.

After the end of the contest, we did some wrap-up interviews and conversations.We also grabbed a beverage (or two) chatted and relaxed. On leaving the contest room I ran into many more people - speakers getting ready to head out to the Speaker's Dinner. After handshakes & huhgs all around, I went up to my room to freshen up a bit, relax o moment, check email (work and personal.)

I then headed downstairs to grab a bite of supper, pick up the blog post I was too busy to work on beyond 2 sentences today, grab a quick beer and... head off to review test reports from today's testing contest.

Yeah. There were loads of other things happening. I'll get to them later. Now, I have papers to read and review.

===

Bug reports have been read and critiqued. Testing  reports have been read an critiqued. This was a challenging task, but, we have a winner in a very, very close contest.

More tomorrow.

It's late.  Good night!