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!

Agile & Testing & Meeting - Agile Testing Days 2016

This will be a short blog post - shorter than my usual posts anyway.

I'm excited about some things. First, work is great. They day job has the usual interesting challenges and problems that any day job has. The team I am working with though is great and works together very well. The most cool part with them is they are constantly looking to learn, try and apply new approaches. This makes dealing with challenges that appear much less painful and more rewarding that they might otherwise be.

Second, there is a conference coming up. I know, conferences are everywhere these days, right? This one is different. This one is focused on testing in an Agile environment. Logically enough, it is named Agile Testing Days. The 2016 edition is occurring in Potsdam, Germany THIS DECEMBER! Yeah - if you have never been to Germany just before Christmas, this is a bonus! Conference is astounding. The host city is astounding. Environment is astounding.

Best part of this conference though, when you strip away the "Ooooooh! Look! Fun activities and cool stuff!" and look at the core of the conference it self - Look at the people. There are some fantastic speakers - recognized experts who are talking about ideas and what they actually do and use in their day-jobs. There are practitioners talking about what has worked for them - and what has NOT worked for them. There are people who are attending the conference who are willing to discuss ideas and ask questions and grab a corner and debate an idea into the wee hours.

There are people from all over the world attending, participating and deeply engaged.

If you are reading this BEFORE 3 October, you can get the Early Bird discount. If you miss the window for the early bird, and you still want to go (and the conference is not over!) leave a comment and I'll see if I can still get you some level of discount.

I'm going to be there. I'm going to be speaking. I would not take the time away from my work - my day job - for a week and travel to Germany if I did not think I'd be learning something of value. I've been there several times and always come home with something I can use at work the first day back.

I bet you will too.

On Ego and False Dichotomy

I apparently have a memory that stretches back to the dark ages. Aside from my now-23 year old grandson asking me what King Arthur and I talked about when we had lunch (he was 5 or so at the time) a fair number of my younger colleagues firmly believe that my start working in software, on mainframes, with COBOL and RPG and JCL and other arcane (to them) things must mean I have been working with software shortly after code was written by hammering 1s and 0s into stone tablets with a hammer and chisel.

My response?  "Not quite, but close.Not as old as dirt, but I do remember when fire was a new-fangled idea."

Really. I've used that recently. This last week.

I wonder if anyone else remembers the "dark ages" where "programmers" talked with people outside of tech? You know, like, people who would actually USE the software being worked on? People who were currently using it and had an idea that might make it better? You know, an "enhancement"?

I wonder if anyone else remembers the "dark ages" where "programmers" talked with those same people and figured out things like "requirements" and "expectations" and when pieces might be available, if not the whole thing

I wonder if anyone else remembers the "dark ages" where "programmers" looked at application and system models and did the design work for how their changes, the ones they talked with non-tech people about, would fit into the whole scheme? Like, did the design and architecture work?

I wonder if anyone else remembers the "dark ages" where "programmers" looked at file systems and databases and came up with solutions that would work for their needs and not step on the toes of any other systems or the people who used them.

I wonder if anyone else remembers the "dark ages" where "programmers" figured out how to test the software they made? Figured out what the expected behavior was and how to handle situations that would, almost certainly arise when something went hay-wire or "pear-shaped." (Yeah, that is still kind of my favorite euphemism for SNAFU.) Or how about, worked hard to find faults in their presumptions?

I wonder if anyone else remembers the "dark ages" where "programmers" sat down with other programmers and worked with each other on their code? Where they went beyond "I'm stuck" and looked at "is this the best way?" Where they reviewed each others code to look for potential problems or inconsistencies - like weird variable handling or dangling If-Then constructs - or worse - random periods - dots - that might get missed?

I wonder if anyone else remembers the "dark ages" where "programmers" carefully worked out what data they needed to test with before running the first test? What conditions they needed to meet and what combinations they needed to cover - and how to cover them?

I wonder if anyone else remembers the "dark ages" where "programmers" had other "programmers" look over their shoulder as they were running tests to help them see if they missed anything?

I wonder if anyone else remembers the "dark ages" where "programmers" worked with other "programmers" before testing the work of those other "programmers"?

I don't remember when this all changed.

It was gradual. It seems like it was getting tweaked and nudged and "improved" for some time. Before long, there was "designers" and "architects" and "business analysts" and "developers" and "testers" and... yeah. Next thing I knew, people needed special treatment. They were "specialists" in something. It seems that some needed to feel "special" - more "special" than others that were not as cool as them.

People began not talking to each other so freely - or at least not as colleagues - equals. People who were "testers" seemed less at-ease to talk with "developers" as equals. Instead of working towards solutions together, they saw themselves as part of a hierarchy - a pecking-order.

There were extremely formalized models to developing software that were put in place - models to prevent people from working together (as far as I could see.) Some were focused on  "maximizing individual skills" and "reducing distractions," as far as I could see then, and still see, they were about asserting power and control.

People began to see their work as more valuable than the work other people did. They felt, possibly believed but I find most beliefs to be reassured/asserted feelings, they were better than those "others" and had greater skills than those "others" and so were worth more to the company than those "others" and so they deserved to be paid more than those "others."

This was also about the time I began noticing there were fewer women working in software shops than there used to be. I don't know if they left because they got tired of dealing with jerks or is they simply had found something better to do. I suspect one led to the other.

I began seeing more "frat-boy" behavior on teams I worked with. Behavior that would have gotten you fired a few years ago was now the norm. I did not stick at those shops very long. I apparently was not a "cultural fit." So I quit or was transferred to another team of "old people."

At the time, I was not sure what was going on. I did not like it very much. I spent my time honing skills I saw were missing in many of the "developers" I worked with. I became good at testing. I became a "tester."

A rebellion started.

People began looking for "rapid software development" and "light development methods" and ways to make software get written and developed faster, without the huge overhead imposed by the control and power folks.

I remember reading articles, then a book, on this new cool approach called "Extreme Programming."

Then I remember reading about this cool newness called "Agile." At the time, I shrugged. I still kind of shrug, frankly.

I'd seen too many "hot trends that would revolutionize software development" come and go.I did my job to the best of my ability and helped other people work better.

Then some folks got the idea that "Agile" might really be a thing. There were suddenly loads of books and papers on it. There were people talking about the "whole team" being responsible for "quality."

Whatever. For some of us, that had been the way we worked years before. Back in the "dark ages."

Now, don't get me wrong. Back in the "dark ages" there always were "programmers" who wrote code pretty well, but were better at designing solutions or figuring out file systems and structures or looking for ways to exercise the software.  Everybody was expected to do some pieces of all of this - and everybody was expected to contribute in ways that made sense.

Now, people have decided that "whole team" means "everyone must learn to code."

It took 30 years (or so... ahem) for things to come almost full circle.

I'm watching people freak out over changes where "everyone is a developer" and "developers" being made the same as... everyone else. People are freaking over that. Why?

I'm not sure. Maybe ego? Maybe there is a bit of resentment - everyone is suddenly "equal" - everyone is suddenly the same - no one is special anymore. Or worse, maybe they are not better than other people any more?

What I tend to see is this...

There are legions of people with a shallow understanding of what "whole team" means. There is a huge, potentially intentional, misunderstanding over what "whole team" means.

If everyone "learns to code" do you really expect people to be able to write production facing code in a matter of days or weeks or months? Do you really expect people to be able to develop meaningful test approaches to that code in a matter of days or weeks or months if they have never had to do so in the past?

Even in the "dark ages" there were people who were better at something than others. That is still true. Make use of those differences in skills, abilities and viewpoints.

Don't let your ego get in the way. Don't let manufactured differences and false dichotomies play on your ability to work together.

If you are not sure what I mean, consider the list of items at the beginning of this blog post.

In short:
Developers - put the ego in check and realize you can't do it all yourself;
Testers - look, you'll be treated like second-class citizens as long as you act like second-class citizens;
The rest of you - chill - do what you know how to do and help everyone else do their thing.

Act professionally. Perhaps more importantly, act as a mature adult.

Contribute to the team's success.

If your ego can't handle it, go tell your mummy I hurt your feelings.

On the Value of Software Testers

This was originally published under the title "Considering the Value of Software Testers" in Stickyminds, July, 2014. The original, unedited, version appears below. - Pete

I try hard to learn what other people think about testing and how to do it well.  If you are like me, you have as well.  In doing so, you’ve also heard a variety of answers from gurus, telling us what to focus on. If so, then I suspect you’ll find these ideas familiar:

• Software testers find bugs;
• Software testers verify conformance to requirements;







• Software testers validate functions.

There are different versions of these ideas; they may be expressed in different ways.  Some people focus exclusively on one item.  Some will look at two.  Sometimes these ideas are presented as the best way (or the “right way”) to deal with questions around testing. 

Some organizations embrace one or more of these ideas. They define and direct testing based on their understanding of what these ideas mean.  They insist that testing be done a specific way, mandating practices (or documents) under the belief that controlling practices will ensure maximum effectiveness and best possible results. Less training time and easier switching between projects are two common reasons to do this.

Frankly, even when they work, I find the results unsatisfying. For example, the result of “standardizing” often consists of detailed scripts.  These scripts direct people’s efforts, which often results in actively discouraging questions.  The reasons for detailed scripts are often wrapped around concepts that many in the organization have a very shallow understanding of, such as Six Sigma in software development and repeatability of effort.

In Six Sigma, variation is viewed as the cause of error. A shallow understanding of Six Sigma leads to the understanding that varying from assigned steps in a test document will result in “error” in testing, making variation in test runs a cause of deep concern.

If the “expected results” explicitly state one thing, those executing the tests will soon find themselves looking only that thing. As Matt Heusser has often said (and I’ve stolen the line time and again), “At the end of every expected result is another, undocumented statement that says ‘… and nothing else strange happened’.” 

The point is the obvious solution is to direct people to look at broader aspects than what is documented as “expected results.”   This sets up a conundrum around what is and is not part of what should be looked for.

Many of us would assert that the tester should, out of responsibility and professionalism, track down apparently anomalous behavior and investigate what is going on.  Consider the team reducing variation in a shallow way that has defined steps that take a known period of time to execute. Then add a little time pressure.  What do you think happens when they encounter something that does not fit but is not to be check for explicitly? 

The human mind ignores these types of errors, often the most important errors, or at the very least, a hint that might lead to the most important error.  If you doubt this, then here is an exercise for you: Go to gmail or google and look for the banner ads.  Your mind has been ignoring these for year.  Do you notice how large and prominent then are?  Funny how you don’t notice them unless you look!

Of course management can insist that testers be “professional” and investigate off-script issues, but when the testers follow that advice, they will exceed the allotted time for the “test case.” If part of their performance review and the resultant pay/bonus is tied to those measures, can we really expect them to branch out from the documented steps?

Teams that rely on “click and get reports” automated tools for functional or UI testing are set up for a similar problem. Without careful investigation of the results in both the too and application logs, the software will only report errors in the explicit results. That means the error has to be anticipated in advance in order for the automation code to look for it. 

A Different Way

I’ve explored the consequences of these ideas and have tried them myself in my early career in testing.  I don’t believe they work as broadly as many say they do.  Frankly, they fail my smell test. Can I suggest a fourth definition of testing, perhaps not academically through, but a working definition, based on the things I have seen that actually work?

Software Testing is a systematic evaluation of the behavior of a piece of software, based on some model.

Instead of looking for bugs, what happens if we look at the software’s behavior?  If we have a reasonable understanding of the intent of how the software is to be used, can we develop some models around that?  One way might be to consider possible logical flows people using the software may use to do what they need to do.  Noting what the software does, we can compare that behavior against the expectations of our customers. 

These observations can serve as starting points for conversations with the product owners on their needs.   The conversations can incorporate the documented requirements, of course, along with the product owners’ expectations and expertise.   This means the project team can choose the path they wish to examine next based on its significance and the likelihood of providing information the stakeholders are interesting in evaluating next.  

Instead of a rote checklist, testers working with product owners, development team and other stakeholders can compare their understanding of the software and ask the crucial question of “Will this software meet our needs?” 

Comparing system behavior with the documented requirements means that testers can help initiate and participate in discussions around both the accuracy of the requirements (do they match the expectations) and the way those requirements are communicated, thus helping reduce the chance of misunderstanding.  This helps the Business and Requirements Analysts do a better job writing requirements and position us for conversations around how to make requirements better. 

By changing what we are looking for, from specific items in a check list to looking at overall behavior with specific touch points, we change what we do and how we are considered - moving testing from an activity that has to happen to get the software out the door (a cost center to be minimized) to a value-add activity.  

And You 

If you serve in this industry for any length of time, you have probably felt offended if not insulted as a tester. Perhaps someone who had never done testing a day in their life defined a process for you and you did it while knowing that the work you were doing was low-value and would take too long. Perhaps worse might be to be given a detailed low-variation test plan, measured on time, and also told to investigate - a scenario where you can’t win for losing! 

If that is the case, it might be time to say something like this “Let’s talk about what I do as a tester.” I know, you may be scared, worried about your review. A few testers I know have been fired over this, but that is only a few.  Consider the alternative:  keeping a job you don’t really want to have. 

Sometimes, the way to be most effective at your job is to act as if you don’t care about keeping it.

Piper Kenneth McKay at Waterloo

On Community, Faith and Belonging

There have been several things happen lately that made me consider what it is to be part of a community, any community, and how people relate to you, and you to them, as a result.

Miriam Websters Dictionary defines Community thus:

• a group of people who live in the same area (such as a city, town, or neighborhood)
• a group of people who have the same interests, religion, race, etc.
• a group of nations

This is a fairly common definition.

The questions I have been mulling in my mind revolve around the second definition. People with the same interests, like testing. Or maybe the same religion, or lack there-of. Or something. I'm not sure.

Simple, Obvious Communities

These are the kind that once upon a time,  I would have shaken my head at the lofty idea that this was some form of community. For example, voluntary communities like people in schools. Any level of school works, but let's consider a college or university.

One community meets at 8:00 AM five days a week for calculus, or differential equations or... something. Maybe another community is in the intro-chemistry lecture. There is nothing stopping members of one "community" being in the other. I had the good sense not to push my luck and take courses like that at the same time. Way more work than I wanted to do - which made another form of community.

Then there are people who work for the same company. Mind you, the first company I worked for was fairly large for where I was living - some 2,000 people worked there, all told, in many buildings on their "campus."

This could be narrowed down to people who work in the same building. Or maybe, we could limit it to the same Division or Department or Team. These might be individual communities.

Not terribly long lived, but still a community of sorts. People change positions, job functions, departments or leave the company altogether. They are no longer part of one of those other communities, but they may be part of a new community.

There are other communities I might belong to - like musicians, classical music performers (at one time) or blues and jazz performers (another time) or traditional/folk performers (still another time) or pipe band music performers (still another.) Each of these forms a community based on what the members do. That I was in another community that overlapped all of them, percussion performance, is immaterial. At one time in my life I was in each of these - several at once to be precise.

Then there are other communities...

These are the ones people are born into. Like, Caucasian Males for me - Caucasian Females for my sisters. There is the family community we were born into. In this case, most of us don't have much say who are parents are. None of us have much control over what group we are born into. We may change that community to a point, but somethings we really can't change. We're stuck with them - and the associated communities that go with them.

There are also communities that might be chosen for us, like what religion we are raised in, if any. We might have parents who take the course of teaching us about many religions, then explaining why "we" (they) follow the religion we/they do and the church they go to. Some of us stay with that religion out of conviction and belief. Others may wander away and choose another faith. Still others may choose to abandon organized religion altogether.

Wow. That is a complex "community" configuration.

And still...

That is a pretty common model for communities built on faith or belief. You begin in one community, because that is what those around you do. Then you change yourself... or not. As children grow and learn, it is not uncommon for them to push back, question  and challenge the religious tradition they are raised in. How this period of growth is handled varies from group to group and faith to faith.

This is part of the process of determining what the person really believes, and where they fall in with religious life.

The problem there is, most religions and belief systems have core tenets of faith and expected behaviors. These boil down to, "These are the things we believe and how we act or behave; if you do not act this way and do not believe these things you are not in communion with us."

So, if the religion says "Don't eat meat" then if you eat meat are you really in that community of faith? How about "Do not drink alcohol or caffeinated beverages (e.g., coffee)" and you do anyway, are you really in that community of faith? If the religion calls for respect and protection of women and children, even at the cost of your own life, and you willfully inflict pain on them, are you really in that community of faith?

What if your faith calls for complete non-violence?

What if one of the Commandments your religion says came directly from God says "You shall not commit murder?"

Most religions and faith based communities have ways and means for members who have "fallen away" from the faith. Many leaders will see some variance as "youthful indiscretions" while others will see similar behavior as suitable for damnation. (For me, the latter category likely have never gone through the maturing process where their faith has been challenged. They have likely never experienced the pain of trying to understand why they believe certain things and not others.)

If a person who violates the teachings of their faith or religion on a regular basis does so in complete disregard to the orthodoxy, the leaders of that faith community, are they part of that community? If a person "cherry picks" items so they feel better about their own lives, do they really believe what the community believes or are they setting out to a different community?

What about people who insist they are right, they understand the "true meaning" of what is is to be of that faith, and they fly in the face of the leaders of that community? Are they part of that community or are they part of something else?

Do people who claim to be part of a religious or faith community, who take self-directed actions "in the name of" that community, really do so for the community? For the faith? Or maybe for something else? Are they "faithful warriors" or are they attention seekers who only feel value if they can latch onto something?

What about testing?

In testing, we see people get identified (usually by others) as part of one "school" or self-identify as part of one school. This generally means you agree with certain tenets and theories (a bit like a religion.) The "community" is based on people agreeing on those tenets.

If those tenets are pretty loose, and the first is that the tenets are decent ideas and may need to be applied differently depending on the situation you find yourself in, how do you identify as part of that group?

Are you drawn by the "names" in the school? The community?

What if you question the bold statements and assertions of those "names"? Do you still belong? What if you disagree with those statements? Are you part of the club of those who declare their view is what is real and correct? "No real tester would..."

What if you see people slapped down (metaphorically) on twitter or some other social medium by these "names"?

When questioning is not allowed, or only permitted if the question is phrased very precisely, how do you teach others the "rightness" of your position?

Are the people slapping others down acting for the community or for their own self-glory? Do they need the attention on them? Instead of the message they claim to be spreading?