Grand Pronouncements, Best Practices and the Certainty of Failure

Many times, those "in charge" will issue mandates or directives that seem perfectly reasonable given specific ideas, conditions and presumptions.  We've seen this loads of time on things related to software development and testing in particular.

We've seen this many, many times.

1 July, 1916.

British infantry launched a massive assault in France along the Somme River. It was a huge effort - days of artillery bombardment intended to destroy German trenches and defensive positions, as well as destroy the barbed wire obstacles in front of the German positions.

The best practices mandated by High Command included forming ranks after scrambling "over the top" of the trenches, then march across no-mans-land, overcome what would be left of the German defenses and capture the German positions, thus breaching the lines and opening a hole miles long though which reinforcements could pour, and send the Germans reeling backward in defeat. Troops in the first two waves were promised that field kitchens would follow behind them with a hot dinner, and supplies of ammunition and more field rations would follow.

Brilliant plan. Conformed to all the official Best Practices of the day. In a training setting, the planners would have gotten very high marks indeed.

One very minor issue was it was based completely on unrealistic presumptions.

It did not work. Thousands were killed on the first day. Entire battalions simply ceased to exist as viable combat units. Some, like the Newfoundland Regiment, were destroyed trying to get to their launch point.

With luck, the best practices and directives you are getting are not in the same scale of life and death.

Being Done

What I have seen time and again, are mandates for a variety of things:

• All sprints must be 2 weeks long;
• Each team's Definition of Done MUST have provisions that ALL stories have automated tests;
• Automated tests must be present and run successfully before a story can be considered "done;"
• There is a demand for "increased code coverage" in tests - which means automated tests;
• Any tests executed manually are to be automated;
• All tests are to be included in the CI environment and into the full regression suite;
• Any bugs in the software means the Story is not "Done;"
• Everyone on the team is to write production/user-facing code because we are embracing the idea of the "whole team is responsible for quality."

Let me say that again.

• All "user stories" must have tests associated with them before they can be considered "Done;"
• Manual tests don't count as tests unless they are "automated" by the end of the sprint;
• All automated tests must be included in the CI tests;
• All automated tests must be included in the Regression Suite;
• All automated tests must increase code coverage;
• No bugs are allowed;
• Sprints must be two-weeks;
• Everyone must write code that goes into production;
• No one {predominantly/exclusively} tests, because the "whole team" is responsible for quality.

It seems to me organizations with controls like these tend to have no real idea how software is actually made.

There is another possibility - the "leaders" know these will be generally ignored.

Unfortunately, when people's performance is measured against things like "automated tests for every story" and "increased code coverage in automated tests" people tend to react precisely as most people who have considered human behavior would expect - their behavior and work changes to reflect the letter of the rules whilst ignoring the intent.

What will happen?

Automated tests will be created to demonstrate the code "works" per the expectation. These will be absolutely minimalist in nature. They will be of the "Happy Path" nature that confirms the software "works."

Rarely will you find deep, well considered tests in these instances because they take too long to develop, exercise, test (as in see if they are worth further effort) and then implement.

With each sprint being two weeks, and a mandate that no bugs are allowed, the team will simply not look very hard FOR the bugs.

When these things come together, all the conditions will be met:

• All the tests will be automated;
• All the tests will be included in the CI environment;
• All the tests will be included in the (automated) Regression suite; 
• Code coverage will increase with each automated test (even if ever so slightly);
• Any bugs found will be fixed and no new ones will be discovered;
• Everything will be done within the 2 week sprint.

There is one other thing that is very likely once the product gets deployed to whatever the next level is, there will be any number of bugs found. If this is some other group in the organization, the product will be sent back to be corrected.

If this is to some other group, it is probable that group will howl about the product. They likely will hound your support people and hammer on them. Expect them (or more likely their manager/director/big-boss) to hammer on your boss.

But, the fact remains, all the conditions for "Done" were met.

And together, they ensured failure.

Why Don't Managers Understand What Good Testing Is?

Several years ago, I was sitting having a quiet drink waiting for a couple of friends to arrive when a fellow walked over and sat down. Did not ask if he could, just sat down. Rude bugger.

He was a senior boss type in his own organization. I was... not a boss type.

Still, he sits down and asks me a question. "I don't know how you deal with this. I would think you get this all the time. It seems like every few months I get called into  my manager's office to answer questions about why we do what we do and why we don't do what these "experts" say we should be doing. It can be everything from metrics that are supposed to show us where all the problems are or sometimes some best practice that someone is pushing or some tool or other for test management or some requirements tracking tool that lets you show what you're testing and how much testing you're doing and how good a job testing you're doing or something. I explain to him why that stuff isn't real and how those things don't actually work. He seems OK with it, then another couple months and I'm back having the same conversation with him. Don't you find that frustrating?"

My response was something really non-committal. Something like, "Yup, that can be really frustrating and a huge energy draw."

He felt better after venting or maybe getting some form of confirmation that it really IS frustrating and went away - he went to hang with other manager boss types.

Here's what was running through my mind as I finished my beer.

Maybe the reason why this keeps coming up is in what he said to me.

Your manager or manager's manager or someone up the food chain is looking for information. If they are not seeing anything they understand or can report to THEIR manager on, they'll look for what is commonly discussed among their peers or in article or books or webinars or conference presentations.

They are looking for information they can use that is presented in a way they and other managers can understand. Let's be realistic. They don't have time to filter through 18 pages of buzz words, technical jargon, mumbo-jumbo and falderal. They want a single page, bullet pointed list that summarizes all that rubbish. They would also probably like some graphic representation that presents information clearly - and accurately. They don't have time or patience to sift through a dozen footnotes explaining the graphic.

You may object strongly to some level of manager higher than you being sucked in by snake-oil salesmen or some other word for con-artists.

Still, if the con-artists and snake-oil salesmen are presenting them with a tool or a "solution" or a method that gives them something resembling what they want and need, that will seem like The Solution to them, no matter how wrong you think The Solution is.

Then again, maybe the solution people are looking for, the one that looks right, based on their understanding will work. Maybe, just maybe, people will land on something that sounds like what "experts" are talking about. There are looking at the results of "software testing tools" in their favorite search engine and wondering why their company is not using one or some of these tools.

Then they enter "best software testing tools" into the search engine and see MORE results. And these are for the BEST testing tools. Some are "Manual Testing Tools" some are "Automated Testing Tools" and when you read the ad copy on the webpage - they sound AWESOME.

Then they wonder why their company is not using one of these BEST tools.

They read articles online or in a magazine and they talk about "test everything" because if you don't then bugs might get through. And they read about how they can have software with ZERO BUGS. And then there are the articles about choosing the RIGHT things to test since there isn't really time to test everything. And then they get confused because given the stuff they read in their search results talk about testing faster and better with these tools - and deliver results that can be tracked.

So they think about how to track results and how to measure things like "improvement" and "quality" and to see if there is anyway to tell if anything is being done, let alone done right, and when changes are implemented, do they make any difference at all,

This leads to things like methodologies, processes, process models, and SCRUM an KANBAN and how "Agile" is better than other ways of working and how to be Agile and how to measure how Agile you are and how to show that being Agile is better and how to Scale Agile and Disciplined Agile... and... and...

Still, the bosses want to know why we (the resident "experts" in testing) don't do things like they read about or hear about in meetings or conferences or training sessions or podcasts. We can explain how those things are not really helpful and don't really work - and the software being made still sucks and if more large customers don't like the software and cancel and it is likely that someday we'll run out of new customers to use the software we make and if we can't keep more of our customers happy, and then we are all screwed completely.

Why don't managers understand what we are doing and what good testing is?

Why is it they keep coming back and asking fundamental questions about what we do, how to evaluate progress, how to look for improvement in quality, how to track customer satisfaction, how to know the software works the way the sales people say it works...

Why is that?

When managers, bosses, whatever, are looking for help to make things happen - make things better or find some sense of progress, how do we respond?

Do we scoff openly at them and say "that will never work?" Personally, I find it not wise to scoff openly at managers and directors and VPs of whatever, but your experience may be different than mine.

Maybe we say "This is not going to help because..." and explain why it won't do what they are hoping it will. Perhaps our more sophisticated thought leader types might patiently explain what a "good" thing is (metric or tracking tool or some other tool.)

Then maybe give some sage advice like "You need to decide what you want to learn from this and what you intend to do with what you learn."

They blink. Maybe they realize they have no idea what that means. Let's face it - an awful lot of people have no idea what that statement means.

So far, except for the scoffing part, there is not a lot to object to in my experience.

The problem, and the reason why the questions keep coming back, is we have not provided an example of a good alternative.

If our method of teaching managers about testing and test management extends only as far as what won't work and why things are a bad idea, then we have greater issues.

We have only done half of what we need to do.

If a tool will not do what is needed, is there an alternative? Maybe there will need to be more than one working in parallel.

If they are trying to discover something about quality of the software, do we suggest paths to discover what is needed? Do we offer to help them with this and work on finding the solution together?

In short, if all we do is tell them something won't work, we are not doing our job.

We have no grounds to complain if we have not worked hard to provide viable alternatives they can understand.

Maybe the great gulf and obstacle to understanding is more simply put.

People (like Managers, Developers, Product Owners, Business Analysts, Project Managers, Scrum Masters and Testers) have no shared concept of what testing itself is.

Can we blame them if they do not understand what Good Testing is?

Considering Conferences: A Reflection

The last week I have had a series of interesting thought/introspection sessions. The kind where I pour a decent measure of good whisky sit back and look out the window and think. It helps to have a nice garden to see when I look out the window - and since the house does not have a fireplace and it is too bloody cold out to have a fire in the garden, well, staring into the fire is out of the question right now.

The gist of my thoughts? Let's see.

After speaking at many conferences a year on for several years, on various topics, then filtering down to a few conferences each year, and now one or two conferences a year - I have observed things that make me wonder why I should keep going and speaking at conferences.

Don't get me wrong. I really enjoy the conversations and sharing ideas that happen. Most of these, for me, happen in the hallway or "after hours."

Perhaps it is just that I've grown cynical with regard to the desire of so many people to belong to the cool-kid-club.

What do I mean?

For example - Cool-Kid A and Cool-Kid B talk about an exercise or a book and how awesome it is. They write about it and talk about it. In a short time, loads of other people are jumping in - recommending the same book or exercise. IN a year or so - SCADS of people are talking about how awesome it is and how cool it is. A year later they are all onto something... else. Typically endorsed by the cool kids.

People stopped talking about what they KNOW - what they have experienced and can demonstrate and instead talk about ... whatever the cool kids are talking about. Presentations - even keynotes - get more hand-wavy and full of dancing unicorns (the kind that are on the screen and don't really have a bearing on what is happening with people in the room) and truisms get spouted and straw-men get setup and then slain and people applaud and talk about what a great presentation it was.

My question is - What was the presentation about and how will it impact your work when you get back to the office?

Is the information really new to the people who think it was awesome, or does it merely confirm their beliefs on a subject. Are they so shallow as to not be able to consider going to a presentation they disagree with? Are they afraid of learning something new or taking on material that might lead them to reconsider what it is they think or believe?

I feel the same way about the cool books or exercise - the cool kids advocate.

How has this changed what you do as a tester? NO - Don't give me more bullshit answers about how it changed how you think. LOADS of things can change how you think. Good whisky can change how you think!

How did THIS book or THIS exercise change how you do your daily job? Because frankly, I suspect much of it is little more than mental self-indulgence (I had another word but a proof reader said it might be too explicit for some folks...)

And don't even get me going on so many bullshit keynotes I have heard. The abstracts were... harbingers of hand-wavy crap. Somehow the reality of the presentation so many times has been... more hand-wavy than the abstract. I find it actually quite depressing.

Why?

When I read proposals for conference presentations, I see a series of similarities and "sameness" among them. There are the ones that regurgitate ideas from 20 years ago. There are the ones that claim a new take on a topic - and when I dive in I find them to be regurgitating ideas from 20 years ago.

I see the cookie-cutter, instant solution to all your problems so frequently, I swear (as in take an oath) when I review proposals for conferences, I will not go to any conference that has people presenting such shallow rubbish - ever.

What is one of my warning signs? If the speaker or potential speaker cannot carry on a conversation for 40 minutes ON THE TOPIC THEY ARE PRESENTING ON - do they have any experience in the area or are they babbling theory only? Do they have any real-world applications of what they are presenting? Or...

I'm not sure why this is. I am not sure why people latch onto certain ideas and never vary from them. I am not sure why hand-wavy bullshit is so appealing to people, except for one small thing - it takes no effort to think about because there is nothing there TO think about.

I expect keynote speakers to be exceptionally well versed in their subject. When talking with them, either in advance when preparing a program or over drinks at a conference, I expect them to be able to cite specific experiences - nothing that would violate an NDA, but something like...

There was this problem where... The possible solutions I saw and presented to try were... The team tried this approach... The results were... 

IF they worked - fantastic. What was it that made the solution work? Why did this work? If not - then why did it not work? Talking over drinks (or over the phone) I want to know if the person has "been there and done that" to steal an over-used phrase, or if they are telling a fairy tale/war-story.

When I try to coach new speakers - to help them find their voice - the ground they are going to stake out as their own, I try to help them find a message that is uniquely their own. I try and help steer them away from the ground so often trod on by others and show a little used path they can take.

I expect that speakers will give me something I had not thought of before, some insight I have not considered or some point of view I can make use of when I get back to the office.

Avoid the band-wagon cool-kid trends. Speak and write on what you know and are passionate about.

That might just convince me to read what you write and maybe even go to the conference where you are presenting the idea.

Until then, be well and be.

End to End Testing and Integration Testing Revisited

After a crazy busy "black Friday" at work,  I was hiding at the small local coffee shop enjoying a really good cup of coffee. It was really very good coffee. Very nice.

I was half way though my first cup (I limit myself to 2 at this shop) looking out the window, glad I was not part of the mob scene of young people debating going to the local bar, the fancy coffee shop or replenishing the supplies from the "party" store next door. (There were loads of parties Wednesday night and Friday in the area.)

A guy I sort of knew from the local test meet up pulled up a seat and began talking about how awesome things were at work. He was really really proud and needed to tell someone about it. Their End-to-End Test Automation had been up and running for 3 releases and it was AWESOME! They made some tweaks and it ran clean and fast and all you had to do was click "Start" and it ran.

OK - Sounds pretty cool so far.

It has 300 steps - well, closer to 400  but, you know... (More coffee for me, this might be a long conversation.) And the first few times it ran it found a bunch of bugs and they could get them all fixed and now it is running really really clean!

Wow - OK, that sounds line something. So I ask the next question that seemed logical to ask...

So, this has been running for 3 releases? You found a bunch of bugs in the test environment early on, right? (Yeah, we did - saved our butts.) Cool. That's good. So, how about bugs in the  production environment? Got any cropping up there?

Well, there are always bugs in production, right? Something always goes wrong and there really isn't anything we can do to prevent them in advance. You know how it is. There's one the keeps cropping up. Seems like this reappears every few weeks. We just fix the data and move on.

Hmmm. So, is there a way to recreate the scenarios in the test environment and see if you can head off these issues you had in production? Is there a way to maybe isolate why you  need to "fix" data every few weeks?

Well, it's really complicated. We don't control that part of the data. Another team does. They claim their stuff works fine and the problem is with our stuff, so it is our problem.

Ouch. That kind of sucks. (Thinking about breaking my rule and going for a third cup of this really good coffee.) Ummm, what about integration testing? Is that a thing for you? or, not really?

Well, all the teams are testing their stuff in the System Integration Test environment we have. But we never seem to find these kinds of bugs there.

Hmmm. Yeah. That can be frustrating (wishing I was drinking a nice red wine at this point.) What would it take for that to happen?

We can't do that. We're Agile. We don't do that kind of thing. But hey - I see my wife outside - Gotta go! Later - See ya next month maybe at the meeting!

I sigh. realize I'm half way through my third cup of coffee and I hear my friend the Unicorn start laughing. YEAH - the Unicorn! I had not seen him in MONTHS.

He wasn't there when you talked about "Pulp Fiction Integration Testing" was he. Too bad.

(I blogged about it a long time ago here.)

So the Unicorn and I chatted for a while.

The problem we both have with much of the "automated end-to-end testing" stuff is that thinking humans tend to stop thinking and allow things to run on auto-pilot. If everything is green at the end there are no problems and anything that comes up in production was something that could not have EVER been anticipated.

Except often times they CAN be anticipated. Running tests in an "environment" does not make them "integration" tests. It does not mean they are telling you anything of value.

I might suggest this idea - try getting other teams involved - Other people who deal with systems or applications that interact with yours. Try comparing notes. Try setting up scenarios emulating what actually happens when the software is released to the wild.

Can you evaluate the touch points? Can you monitor the database or the logs and see if there are any warning signs popping up? What happens if you keep those multiple scenarios running for an extended period of time? What happens when OTHER scenarios get introduced into the middle of this?

What happens when something "impossible to happen" is introduced? Because all those things that "no real user/customer/person" would do? Oh yeah. They'll do them They'll do stuff because it makes their life easier - or they think it will - until they do it and stuff hits the fan and goes EVERY where. Then their life will get very unhappy.

Then they'll look at you for why you screwed things up.

Then you'll need Mr Wolfe to help clean up the problem.

Better you see the problem in advance and cut down those calls to Mr Wolfe.

I finished my coffee. The Unicorn finished his and we wished each other a Happy Thanksgiving and went our separate ways.

The Brightest Software Witch of Her Age

Folks who know me know my geek-interests are broad and varied. That is part of why I was intrigued when I saw a conference track talk at Agile Testing Days with a tie in to Harry Potter. So I grabbed my Hogwarts alumni lapel pin and Gryffindor house tie and made a point of packing said items for the conference.

If you read the Harry Potter books or watch the movies, you may remember toward the end more folks than Professor McGonagall, Ron and Harry realize just how bright Hermione is. She is referred to, to her face, as "the brightest witch of your age." Hermione is smart, intelligent, wise beyond her years, resourceful, dedicated, passionate and absolutely focused.

She represents all that is best in the world of wizardry and witchcraft. (Remarkable in that she is Muggle-born - neither of her parents had magical abilities.) Indeed, she represents the very future of that same world.

Last week, I believe I met the future of software at Agile Testing Days.

I met three bright, intelligent women in Potsdam. Each have their own strengths and characteristics. Still, each demonstrates the traits that make Hermione, well, Hermione.

Let me introduce you to them -

First, the person mentioned above with the link to Harry - Marianne Duijst.

Marianne is one of the plethora of talented testers from the Netherlands I have met over the years at Agile Testing Days. Of these three, Marianne is the likely candidate for "muggle-born" in that she came to software through a round-about route. (Don't get me wrong, I have known many talented software people who are muggle-born.) She did MA level studies in English Language and Culture with an emphasis in modern literature and theatre.

Now, THAT is some tech-heavy academic credentials (says the guy with enough university level credits in music and history studies to have majored in either...) Really. She taught for a time, then moved into software - development then testing. She also does some stuff as a Scrum master and coach.

My conversations with her reveled an ability to connect ideas and thoughts in unusual ways. Not just odd, "oh, liberal arts major" ways - where she's more butterfly than focused professional. Not at all. These were of the nature where an old guy, reasonably well read, was gobsmacked by how she was making connections from hugely diverse literary forms and works, and drawing connections to working with software.

The session she gave was outstanding. I believe she will go very far in shaping the world around her and making it better for all.  Find Marianne's website here: http://marianneduijst.nl/   - she can be found on twitter here: https://twitter.com/@marianneduijst
**
Cassandra Leung I met online while doing a podcast. I was excited to meet her in person at the conference and found her to be as personable and intelligent as my first impressions of her made her out to be.

Cassandra is from Glasgow, Scotland, currently working in Germany. She moved into software testing after doing a bit of a stint as an IT recruiter. We had some fun and informative chats on twitter before the conference.

The conversations and discussions with Cassandra at Agile Testing Days were more of the same. Practical, applicable ideas in place of the hand-wavy crap so often encountered of the "well, it depends, doesn't it?" ilk.

One key point I observed, at the start of her talk, Cassandra said something to the effect that she was not "an expert" in test automation - then proceeded to explain ideas and concepts more clearly that many self-proclaimed experts I've heard. She carries herself with an air of confidence that is remarkable.

How remarkable? Cassandra made and placed piles of "tester bingo" game sheets - pages with the names and pictures of speakers and other conference attendees, to encourage people to meet and start conversations. How cool is that?

If I were to mention anything negative, she claims she does not like coffee. I'm a little baffled. I thought coffee fueled most test efforts.

Find Cassandra at her website - http://www.cassandrahl.com/ or on twitter at https://twitter.com/@Tweet_Cassandrahttps://twitter.com/@Tweet_Cassandra
**
I met Sabina Simons  the first time at a conference a few years ago. When I saw her at ATD, I had this strange sense of having met before, but could not place it. That turned out to be a minor detail.

Sabina impressed me with her solid, straight-on approach.Originally from Quebec, she lives in Kitchener, Ontario and works at D2L She has moved from Quality Analyst and tester, to development, to Test Strategist, and was recently promoted to Development Manager.

Our conversations about software, problems with software, problems with roles and, frankly, life, were full of profound consideration - something I often associate with people who have "looked into the abyss" and considered their own purpose steadily.

Her presentation was solid - here's what we did, these things worked and these were the mistakes and unexpected consequences we encountered,,, Here's how it was handled. As with other people who are leaders, she shouldered the burden of the errors to allow the team to move on to do better work.

I've met very few new managers/team-leads with an attitude like that. I was impressed.

I'm not even jealous that she did one of the last PSLs that Jerry Weinberg hosted. That many of her lessons contain "Weinberg-isms" is no surprise. What is notable is how she has taken them on - internalized them - and not simply spouting them unthinkingly as so many do.

Find Sabina on twitter here: https://twitter.com/@sabina_s_simons
***
These three women each embody different aspects of the strengths and capabilities of Hermione Granger.

When I first got into software, I had visions of changing the world. I suspect these three just might do it.

The brightest witch of her age, indeed.

Considering Agile Testing Days 2017

I'm sitting in my favorite rocker with my feet up, a glass of very drinkable red wine, the dog worn out on the floor by the footstool thinking about what a week last week was.

I was in Potsdam, Germany for the 9th Agile Testing Days. I have been there for six years. This is astounding to me. I have seen the conference grow and develop into something... amazing.

Unicorns are a big deal with this conference now. I was at the conference my first year when unicorns became a thing - and speakers went out of their way to add unicorn images to their slide decks. I was one of them. I THINK I had the only image of a dead unicorn at the conference that year... ok, yeah.

My first year - I was bowled over. I met so many amazing people I had followed on-line, on twitter, reading blog posts, reading their articles, sometimes their books. And you know what I found out? They liked having a good time and meeting people and talking with people and hanging out and liking the same things everyone else did. I spent an amazing evening sitting with Lisa Crispin, Janet Gregory,  their husbands, my wife and younger daughter at the Speaker's Dinner. and we talked about all sorts of astoundingly normal things.

But - these were the authors of Agile Testing! THE BOOK people turn to - and then there was Huib Schoots and loads of other people I stumbled into and met and got to know. And they were good people who worked hard and shared their ideas openly with people  they had just met. We compared notes and told stories that had lessons and -

Then there were the organizers - Jose Diaz - whose crew did a fantastic job of EVERYTHING. Jose demonstrated what a leader does - all the credit goes to the crew. Any problems were on him.

There were people willing to think and question and think on the responses and consider and talk about it over drinks long after the sessions had ended. And this continued unto the wee hours.

And you know what? This has not changed - it has grown. It has matured. This year, there were a bunch of people there I had no recollection of meeting before. There were people I know were there in the previous years, but I simply had not met. At the same time, there were people I had met and spent excellent time with in previous years - that I simply never saw this year.

Having said that - there were just under 700 people at the conference this year. That is an astounding number. I'm not sure how many countries they came from, but I know the speakers alone came from every inhabited continent in the world. Yeah, it has become a global thing.

The word used a lot last week was "community."

I know I am not the brightest star in the universe of software testers. I work hard to contribute however I can, and encourage people I meet who are clearly above average. I firmly believe they will achieve great things and do things in ways people like me never imagined possible.

Last week I felt extremely privileged to spend time in conversation with Masters and Colleagues and Rising Stars of this craft we call Software Testing. Among them - George Dinwiddie - Yeah - GEORGE FUCKING DINWIDDIE - Many excellent conversations, ideas from his presentation and thoughts on a huge range of ideas. Ray Arell - Holy CRAP! How can you not know that name - go look him up. He's awesome. Alex Schladebeck - if you have not followed her work, you really need to. She is astounding. (I'm running out of superlatives...)

My friends - I mean that deeply and surely - Chris George - he's a good man and a fantastic tester. Huib, whom I mentioned before. ANOTHER good man - he works hard, plays hard and gives excellent support and insights to people who take the time to listen and share ideas. He really is a good man, a good coach and advocate for people wishing to do good testing work. Perhaps this is why he won this year's Most Influential Agile Testing Professional Person (MIATPP) award.

Of course - Tony Bruce. I met Tony at a workshop quite a few years ago - I knew who he was before - but the meeting was exceptional. My first evening, while a "confusion" with my room was being sorted - Tony stuck his head out from the hotel pub and called me in for a beer. "Pete! Let me stand you a pint!" After a very long day of travel and frustration at the end, he reminded me why I like this conference so much - the people.

Not just the speakers and the sessions, though these tend to be excellent, but the people in attendance. The people are what makes this conference special to me.The individual events - that things that stand out to many people were listed in my daily "Live From..." postings, not just this year, but pretty much every year I've been there. Year after year it is the small things that I don't write on directly that leave the deepest impression.

The number of people I ran into from previous years hoping to have conversation with this year were many. Alas - many were brief in the hallway or between sessions. Some folks I had intended to seek out, and never saw them at all - a sign of the growth of the conference I think. Others, I had gotten messages about meeting them - looking them up - serendipity smacked me about the head more than once and these conversations happened - sometimes briefly and sometimes in depth.

Toyer Mamoojee was as awesome as I was told. Claudio Perrone gave an awesome keynote - and was as personable in the hall (literally) as he was on the stage. Cassandra Leung had a powerful story to tell, then a more powerful story over lunch. Angie Jones - I enjoyed dinner the last night with her and some others. Matt Heusser - colleague, collaborator on many projects, enjoyed our brief chats and of course, dinner Friday. Anastasia Chicu - a delightful, exuberant person with much to tell the world. Ash Coleman - my partner in crime last year making videos - how delightful to see her again when she had such a strong message to give. Deb Hartmann - whom I only brifely saw - in an open space my very fiest day - this woman sits down and I'm thinking "Is that her?" and it WAS! Bart Knaack - David Evans - Yeah DAVID EVANS - Good guys - had a lovely breakfast conversation with David. What a n excellent way to start a day at a conference.

I know I am missing people. I kept seeing Fanny Pittack across the room. Gitte Klitgaard - who always puts people at ease simply by being her. Guna Petrova - if I had her level of energy, look out world! Meike Mertsch - the hug giver, and also excellent sounding board for ideas.

Sabina Simons, from Ontario (originally Quebec) - brilliant thinker. Signs of growing into an excellent leader. Mike Sutton - Yeah - HIM - a good, trusty man. Of course, Marianne Duijst - another fantastic thinker and excellent idea person. Rodrigo Cursino, whom I only saw across the room. Susan Bligh - wonderful, delightful person. Trinidad Schmidle - very, very nice. Viktorija Manevska, who was at the same tale for the Speakers Dinner with me - where we met and continued to chat through out the conference.

The PILES of people I did not chat with or more than a few words - Selena Delesie, Samantha Laing, Karen Greaves - and the list goes on. So, yeah - the people make this conference what it is....

==

Last year, I was horrified to hear people I respected tell stories of abuse in the work place and conferences. That was my last night at ATD before heading home. I was filled with a mixture of revulsion and rage Eventually that led to this post in February, 2017 (after my daughter read the 1st draft and said "You're screaming. People won't listen to you scream." She must get her good sense from her mother... http://bit.ly/2l0WkAy

This year, I heard and was in moving conversations of where there was a single common thread - people in positions of power took advantage of that to get what they wanted and inflict harm on others - workplace, conferences, school, home. The correct word in each of these cases is "criminal activity." No, my screaming isn't ended - it is simply toned into a very hot fire.

I had conversations with people who made a point of always seeing a bright future, no matter what had happened before. I saw people open their wallet and look in, then pull all the bills/notes they had and put them in the collection box for #saveLinnea. (https://www.savinglinnea.com/)There's always more money - they print more every day. Giving something as common as money to help save someone as uncommon as she is, and her parents are, seems only right.


My take? Some people are right proper asshats. Other people are good, well intended folks who sometimes make mistakes. Yeah, there is a difference.
 
**

And the ideas. I heard people express concepts and ideas in ways I had not considered before. This helped me see a different line of thinking and a different way of carrying on the same information.

I saw people get up and give their first presentation at a conference (some solo, some 1st time EVER) and be absolutely terrified - and still get the message delivered despite shaking voice at times, and knees perhaps a bit more wobbly than they would like to admit. And they were fantastic.

I saw people get up and tell terribly personal stories about themselves and their hopes and dreams for the future.

The spirit of community, the courageous energy and giving hearts and the desire to improve, individually and each other are what set this event apart from other conferences I have attended.

This year's conference was astounding. I can hardly wait to see what next year's - the 10th ATD will look like.

With luck I will see you all there - and manage to make the time to have a conversation with every person.

Live from Potsdam, Day 4 - Agile Testing Days 2017

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

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

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

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

Photo by Sabina Simons, used with permission

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

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

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

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

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

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

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

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

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

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

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

Jose is giving tokens to each of the girls.

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

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

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

And a standing ovation.

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

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

**

**

In George Dinwiddie's talk on improving gherkin.

 

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

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

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

If you start out with THIS -

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

 

Helpful hint from Liz Keogh

Liz Keogh reacting to her "hint" being in the slide deck

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

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

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

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

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

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

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

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

Maaret Pyhajarvi is giving us Leaning with Osmosis.

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

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

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

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

And then there was this comment -"Women only write comments in code."

ummm - right,

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

Still, things changed...

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

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

But trying it at meetups and with random people helped.

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

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

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

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

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

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

YES!

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

Very, very good.

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

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

Big Takeaway from mob programming (and testing) from a former intern brought on full time after a short period of pairing and mobbing:

And a BOOK! Leanpub - check it out.

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

In the mean time, you might get a sense of it here:
https://twitter.com/PeteWalen/status/931541792692072449

**
The FINAL sketchnote page was brought up for auction after Janet's Keynote. All of these are magnificent tributes to the skill of the speakers and the craft the artist Stuart Young- find him on twitter @Stuartliveart. Bidding atarted at 100 Euros and went up, stalling around 250. Until Jose Diaz very gently said into his mic "1000 Euros" - pandemonium wasn't in it.

All in all some 2700 Euros (I saw some figures of 3000+, not sure which is accurate) was raised through Agile Testing Days for #SavingLinnea.

We broke up into groups, some heading home, some to dinner before heading out the next day. Conversation at dinner was long and excited (much to the surprise of other patrons in the restaraunt - maybe that is why they had us in a room by ourselves.

Yes, I AM smiling!

***

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

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