As the year wraps up, I'm spending a bit of time sipping coffee and looking back on the last year.
There have been some changes, sure - I actually took a full time position in July (for those who missed the subtle notice then) with Gordon Food Service in Grand Rapids, Michigan. Still, my role remains much the same - help them do better testing. In doing so, Ive been on a deep dive looking at how testing is done - now I need to figure out what the next steps need to be and work on making them happen.
Simple, eh?
Looking Back -
The local tester meetup is continuing to help me learn and share ideas locally. I am grateful to all the usual suspects who get me to think about things I often would not otherwise consider.
By sifting through my blog posts from the last year, I expect you'll get an idea of some of the things I've been thinking about or trying to work through in my head. It is probably easier, and shorter, to simply point you there.
So, I guess that brings me to Conferences. Most of them I captured in live blogging (or almost-live blogging) at the time. If you want to go back and read them, by all means, do.
Let's see - the first conference I participated in this past year was in June - Nordic Testing Days in Tallinn, Estonia. It is a very good conference in a very nice, historic city. Loads to see and do - the National Parliament building, museums and many fine shops, restaurants and the like.
The most important thing I remember from this, and other conferences, are the people. Folks like Huib Schoots, Dan Billings, Stephen Janaway, Peter Varhol, Gerie Owen, Gitte Ottosen, Rob Lambert, Raimond Sinivee, Raji Bhamadipati, Helena Jeret-Mae, Ruud Cox, Bill Mathews, Kristjan Karmo, Irina Ivanova, Rob Lambert, Aleksis
Tulonen, Andrei Contan, Rikard Edgren, Martin Nilsson... loads of people worth meeting, getting to know in person, renewing acquaintances with...
August had me participating in CAST. The 2014 edition of the Conference of the Association for Software Testing was in New York City, in August. This conference, for me anyway, was unlike most conferences I've been to or participated in. I spent three days at the Registration table, checking people in, answering questions, directing people to where they are trying to go - and running the odd errand for speakers. Really, it was a pile of work and great fun all around.
One thing that makes CAST interesting is that people attending like hanging with other participants - even when they don't know them (at least when they start chatting.) The Sunday night before the conference, there were 15 people from the conference hanging out talking, having pizza and other food, and having a laugh or three over beer, wine or ...whatever. The fun part was, none of that was planned.
This is topped only by the hallway meetings and conversations that can last 3 minutes or 3 hours. And CAST this year was no exception for me - Let's see- time with Fiona Charles, Erik Davis (and his crew from Hyland Software - these folks get it), Huib Schoots, James Bach, Griffon Jones, Matt Heusser, Karen Johnson, Michael Bolton, Selena Delesie, Michael Larsen, James Christie, Richard Bradshaw, Smita Mishra, John Stevenson, and ...
the list just goes on.
The simple thing is, solid ideas can be discussed and shared with colleagues, new and old, given half a chance.
In October, I was at StarWest, in Anaheim, California. Yeah - Disneyland. I had not been there before and was not quite sure what to expect.
Aside from the lovely weather and nice venue (the Disneyland Hotel - yeah, its nice) It was very nice seeing familiar faces - Michael Bolton, Rob Sabourin, James Christie, Jon Bach, Griffon Jones, Martin Nilsson, Ben Simo, Paul Holland. It was also good to meet some new folks, like Julie Gardner and Rob's lovely and charming wife Anna.
There were many people I had great conversations with like, well, there were the nice people I had a glass of wine with one night, and talked about recruiting and training and motivating people - I'd tell you their names except, well - OK folks - I don't remember all your names - BRING BUSINESS CARDS AND HELP ME REMEMBER!!!!!!! (ahem - sorry)
November (sheesh, sounding like quite the jet-setter!) found me in Potsdam, Germany for Agile Testing Days. This was an amazingly rewarding trip this year. it was unlike any I've been to before. I was crazy busy - like CRAZY busy. Some of it you can see from the blog posts from the conference. Some of it - well - to quote the great, inspirational tester Conan the Barbarian, "Time enough for sleep in the grave." Let me just say that 15 minute naps help a great deal.
People - Oh my, where to begin - The wonderful staff from the conference - Jose Diaz, Madeleine Greip, Uwe Gelfert, Maik Nogens - they were everywhere doing everything - and still made time for you to feel like the most important person at the conference.
I had conversations with loads of people - some planned, some unplanned. Chats, unplanned but not un-hoped for with Bob Marshall (@Flowchainsensei), Meike Mertsch, Jean Paul Varwick, Huib Schoots (AGAIN!), Darryn Downey and the crazy folks from Paddy Power, Dan Ashby, Emma Armstrong, Chris George and the folks from Redgate, Tony Bruce, Selena Delesie (and her wonderfully charming son!), Markus Gaertner, Andreas Grabner, Bill Matthews, Carl Schaulis, Lars Sjodahl, George Dinwiddie, Richard Bradshaw, Alan Richardson, and, and... and more. Loads of people (can ya tell?)
{Updated - More, like, Danny Dainton (how could I have forgotten him?) and Maria Kedemo... that will teach me to try and 'power through' when I am tired...}
Then there were the planned chats. I was asked to "interview" selected speakers and participants from the conference. What would you chat about with Janet Gregory, Lisa Crispin, Joe Justice
(from Scrum, Inc.), Matt Heusser, Maik Nogens, Jose Diaz,and the members of Cesar Brazil?
Who? Team Cesar Brazil! The winners of the Software Testing World Cup (STWC) championship! Smart, Bright, Intelligent people - and very, very nice - An excellent combination. The team consisted of Alessandra Cursino, Jose Carrera, Melissa Pontes and Rodrigo Cursino. A lovely conversation.
So, 15 to 20 minutes or so of chatting over three days was loads of fun. The interviews were recorded and I expect will be available shortly.
One other thing - I tried to have informal chats with ALL the competitors in the Finals of the STWC. The folks were friendly and smart - if they reflect the future of testing, I have hopes that future will be bright:
Army Ants from Romania, consisted of Ileana Brodeala, Lavinia Cazacu, Sanda Cristina Pop, Irina Savescu. OK, The name for the team was inspired by Big Bang Theory - very fun.
Teststar from China, consisted of Nicole Niu, Humphrey Chen, Eva Hao and Harris Wei. A very bright and talented group of testers.
Quadcore from Canada (Kitchener-Waterloo, ON) was made up of Shivani Handa, Shuman Ip, Persis Newton and Richard Bouffard.
The Annunciation from New Zealand consisted of Joshua Uriele, Joseph Walker, Henry Ashton-Martyn and Mark Tokumaru. Very out-going gents with good thinking skills and very friendly.
Open Box from South Africa was Andrew Thompson, Carin Eaton, Delicia Oliver and Ryan Hill. Right. These folks were outgoing, welcoming, ready to learn and have a great time.
To each of the people from the teams, particularly those of you I was able to have longer conversations with, remember that you have good skills and wonderful gifts. Share them. Write, speak, help others learn. I look forward to hearing great things about you all.
Looking Forward -
For me this coming year, I can safely say things will be a bit different. I am not looking forward to what is coming. I am planning on fewer conference this year - I am looking forward to some new adventures.
One of those adventures is chairing CAST - the Conference of the Association for Software Testing. The 2015 edition will be in Grand Rapids, Michigan, August 3-5. Look for more on that in this blog as we get closer.
There will be more articles coming, and more sharing by other methods.
It is the conversations and connections that mean so much to me, and help me learn more about testing every day. Thank you for sharing my journey so far. Won't you continue along with me in the future?
I look forward to the company -
P.S. The UNICORN! Dude - I'm so sorry - I don't know how I left you out. Yeah, I know, I know - I'll buy you lunch tomorrow? Thanks for everything - P.
Monday, December 29, 2014
Wednesday, December 24, 2014
On Symbols, Metaphors and Understanding
I had an interesting conversation today. We were talking about testing, a group of us at coffee this morning, talking about how to get messages over to people. How do you explain things that people are not understanding in a way they can "get" it.
We talked about how visual representations can help some folks and how some people need more, well, linear representations. I talked a bit on how I have used mind-maps in the past - to track requirements and look at impact and risk and, well, stuff.
Then we talked about how we can present ideas to other people and get some core ideas an questions around them can be explained, sometimes in other ways.
For example? Well, Christmas for example.
So, for a long, long time, Christmas has been celebrated in December. Now, the stories around the "Nativity Event" all point to Jesus, you know, the guy whose birth is commemorated by the celebration/Holiday of Christmas, was born in the Spring. Likely around April. How is this clear? Well, consider that in Judea in the 1st Century (BC/AD - whatever) shepherds did not watch their flocks at night in the dead of winter - they did that when they were sent to pasture - in the Spring - April likely.
Yet, somehow people got the idea of celebrating the birth of this fellow in December seemed a reasonable idea. Of course, that has naught to do with reality. So, because there were large celebrations and festivals in Rome in the 1st Century AD and well into the 2nd and 3rd - this time of year honoring Saturn - the Saturnalia. Now, Saturn was an interesting character in the world of Roman mythology.
He was a complex figure thanks to his multiple associations, history, and stuff. He was the first god of the Capitol, known since the most ancient times as Saturnius Mons, and was seen as a god of generation, dissolution, plenty, wealth, agriculture, periodic renewal and liberation. At some point, he also became a god of time (not a Time Lord, significant difference there.) The Temple of Saturn in the Forum (the "city center" of Rome) housed the state treasury. Cool, eh?
Well, the big celebration of Saturn was, as I mentioned, the Saturnalia. Good party, that, I expect (my grandson's questions to the contrary - I wasn't there to actually participate, mind.)
Included in the celebration, was gift giving. Sometimes they were quite extravagant - other times, simple and fun. And children got games and toys and fun stuff.
And somehow, the idea of visiting people and sharing meals and gifts seemed to fit.
And, according to a couple of versions of the story, followers of this, Jesus fellow, joined in - about the same time, in December, around the Solstice, they began sharing meals and gifts. Instead of honoring Saturn, they honored Jesus' birth.
Then there is the word Christmas, derived from "Christ's Mass" - the religious commemoration of the "Nativity Event." There we have it - a celebration commemorating a thing that happened no where near the actual date of the events commemorated, but was similar to other celebrations happening at a given time of year.
And you know what? I don't think it matters.
Much like how we explain things - like, how we get people to look at other symbols - this is a symbol that people use to teach loads of things. Like, peace and charity and love.
Look at the things used as symbols to teach these lessons. The hammer of Mithras (who was born about this time, according to 'myth', grew to adulthood quickly and died to save his people, his followers - to rise from the dead and lead them to victory) the sun of Saturn (who brought wealth, prosperity and health to the people) St Nicholas/Father Christmas/Santa Clause who brings gifts/rewards to the worthy. All are symbols associated with this time of year.
All taught lessons at different times to people, who passed them on and taught lessons to live by.
Explaining fundamental ideas to people is a challenge, particularly when those people are young children. Sometimes the ideas around testing are things that are hard to explain any other way without symbols and metaphors, particularly with those who have no real connection with good testing.
We use terms that encompass what we mean - but then we don't always know how they relate to other people or their experience. So we need to try and explain, somehow - and we find ourselves looking at the idea of bags full of gifts and magical mutant caribou.
These symbols are representations of aspects that are important (or were important in some respect at some time) to the holiday or festival being celebrated. We use symbols and representations for what we do as well - mind maps, requirements documents, test plans, design documents, process flow diagrams, state diagrams, transition diagrams, and (dare I say it?) bug reports. These are not the thing they are explanations and representations of the thing.
So, while I consider the testing equivalent of magic bags and reindeer, let me wish you the greetings of the season -
Io Saturnalia - Happy Solstice - Happy Hanakkuh - Happy Kwanzaa - Merry Christmas.
We talked about how visual representations can help some folks and how some people need more, well, linear representations. I talked a bit on how I have used mind-maps in the past - to track requirements and look at impact and risk and, well, stuff.
Then we talked about how we can present ideas to other people and get some core ideas an questions around them can be explained, sometimes in other ways.
For example? Well, Christmas for example.
So, for a long, long time, Christmas has been celebrated in December. Now, the stories around the "Nativity Event" all point to Jesus, you know, the guy whose birth is commemorated by the celebration/Holiday of Christmas, was born in the Spring. Likely around April. How is this clear? Well, consider that in Judea in the 1st Century (BC/AD - whatever) shepherds did not watch their flocks at night in the dead of winter - they did that when they were sent to pasture - in the Spring - April likely.
Yet, somehow people got the idea of celebrating the birth of this fellow in December seemed a reasonable idea. Of course, that has naught to do with reality. So, because there were large celebrations and festivals in Rome in the 1st Century AD and well into the 2nd and 3rd - this time of year honoring Saturn - the Saturnalia. Now, Saturn was an interesting character in the world of Roman mythology.
He was a complex figure thanks to his multiple associations, history, and stuff. He was the first god of the Capitol, known since the most ancient times as Saturnius Mons, and was seen as a god of generation, dissolution, plenty, wealth, agriculture, periodic renewal and liberation. At some point, he also became a god of time (not a Time Lord, significant difference there.) The Temple of Saturn in the Forum (the "city center" of Rome) housed the state treasury. Cool, eh?
Well, the big celebration of Saturn was, as I mentioned, the Saturnalia. Good party, that, I expect (my grandson's questions to the contrary - I wasn't there to actually participate, mind.)
Included in the celebration, was gift giving. Sometimes they were quite extravagant - other times, simple and fun. And children got games and toys and fun stuff.
And somehow, the idea of visiting people and sharing meals and gifts seemed to fit.
And, according to a couple of versions of the story, followers of this, Jesus fellow, joined in - about the same time, in December, around the Solstice, they began sharing meals and gifts. Instead of honoring Saturn, they honored Jesus' birth.
Then there is the word Christmas, derived from "Christ's Mass" - the religious commemoration of the "Nativity Event." There we have it - a celebration commemorating a thing that happened no where near the actual date of the events commemorated, but was similar to other celebrations happening at a given time of year.
And you know what? I don't think it matters.
Much like how we explain things - like, how we get people to look at other symbols - this is a symbol that people use to teach loads of things. Like, peace and charity and love.
Look at the things used as symbols to teach these lessons. The hammer of Mithras (who was born about this time, according to 'myth', grew to adulthood quickly and died to save his people, his followers - to rise from the dead and lead them to victory) the sun of Saturn (who brought wealth, prosperity and health to the people) St Nicholas/Father Christmas/Santa Clause who brings gifts/rewards to the worthy. All are symbols associated with this time of year.
All taught lessons at different times to people, who passed them on and taught lessons to live by.
Explaining fundamental ideas to people is a challenge, particularly when those people are young children. Sometimes the ideas around testing are things that are hard to explain any other way without symbols and metaphors, particularly with those who have no real connection with good testing.
We use terms that encompass what we mean - but then we don't always know how they relate to other people or their experience. So we need to try and explain, somehow - and we find ourselves looking at the idea of bags full of gifts and magical mutant caribou.
These symbols are representations of aspects that are important (or were important in some respect at some time) to the holiday or festival being celebrated. We use symbols and representations for what we do as well - mind maps, requirements documents, test plans, design documents, process flow diagrams, state diagrams, transition diagrams, and (dare I say it?) bug reports. These are not the thing they are explanations and representations of the thing.
So, while I consider the testing equivalent of magic bags and reindeer, let me wish you the greetings of the season -
Io Saturnalia - Happy Solstice - Happy Hanakkuh - Happy Kwanzaa - Merry Christmas.
Saturday, December 20, 2014
On Waiting and Testing
A couple of weeks ago I wrote a post about childhood views on the world and how we need to grow beyond those simple concepts we learned once upon a time, and develop an adult view of the world. This allows us to continue growing and learning.
It is only fair that as I write this, it is one week until Christmas Day - that much anticipated, looked for and hoped for day by people all around me. Children and adults alike look forward to the wonder of the season.
Yet it is in this season that so many people rush in soon and quickly. The anticipation of childhood, the waiting, the excitement, is part of what makes the "magic of Christmas" well, magic - and I think is missing for many people these days.
It is the sharing of this feeling that makes things so... wonderful for so many people. Still, it is the idealized memory of what Christmas "should" be that causes so many people so much stress. I suspect that at least part of this is related to the ever-earlier start of "Christmas Shopping Season" - This year it seemed to be mid-October and Christmas displays were up in shopping malls.
Except I am not writing about Christmas. I've been thinking about testing a lot lately.
If there is one thing I'd suggest to people when it comes to testing is, take a deep breath and wait a moment. Make a nice cup of tea. There are practical reasons for what so many non-tea drinkers look at as rituals around tea.
Things like heating fresh cool water, warming the tea pot with hot water, pouring out the hot water, adding the tea leaves to the pot (I prefer leaves in an infuser - some use tea bags, and that's OK, at the office I do the same thing.) Then pouring the not-quite-boiling water into the pot and ... tea.
But that takes waiting a moment. It takes knowing the right time to do the right thing. Not too soon and not too late.
The thing with testing I've seen lately - so many people want to charge in and test stuff. NOW! Just DIVE IN!
I might suggest making a tea... or a coffee if you prefer. I like a really good cup of coffee, too. I blogged about that once upon a time. I really like a good cup of coffee.
Ask some questions. I might start with asking something like "Why are we doing this? What do we hope to learn from testing this? If you are telling me how you want the software tested, will that 'how' answer the question 'why'?"
This might seem obvious to some people I often associate with. To others, I think they might not understand why.
Another set of questions might start with something like, "Is there something we should probably know about this that we have not considered?" Another way to ask that might be "Is there something acting against the system, or the data that is used by the system, that is important? Maybe that we have not asked about? Is there something that 'everybody knows' we have not thought about?"
If you are testing a system that you have been participating in developing, some of these questions may not be so important - if you have been in the discussions around how the software should work, and why. Of course, when it comes to that, it might be important to ask yourself if you have built up an immunity to such things. Your certainty and understanding might be of value. Then again, if you clear your head and have a tea, then what happens if you look again with fresh eyes?
When you are handed software and told to "just test it" then remember that sometimes waiting a bit allows you to discover something you had not considered. Asking questions of people might reveal something important to you.
Those questions might tell you something about the software. The problem I see time and again is that people want to try and force the issue. They, or their bosses or developers or managers or PMs or someone, want them to jump in too soon.
Take the time to see what things look like after a tea, or a coffee. You might learn something about the software. You might learn something about the attitude of people you work with toward testing.
You might also learn something about yourself.
It is only fair that as I write this, it is one week until Christmas Day - that much anticipated, looked for and hoped for day by people all around me. Children and adults alike look forward to the wonder of the season.
Yet it is in this season that so many people rush in soon and quickly. The anticipation of childhood, the waiting, the excitement, is part of what makes the "magic of Christmas" well, magic - and I think is missing for many people these days.
It is the sharing of this feeling that makes things so... wonderful for so many people. Still, it is the idealized memory of what Christmas "should" be that causes so many people so much stress. I suspect that at least part of this is related to the ever-earlier start of "Christmas Shopping Season" - This year it seemed to be mid-October and Christmas displays were up in shopping malls.
Except I am not writing about Christmas. I've been thinking about testing a lot lately.
If there is one thing I'd suggest to people when it comes to testing is, take a deep breath and wait a moment. Make a nice cup of tea. There are practical reasons for what so many non-tea drinkers look at as rituals around tea.
Things like heating fresh cool water, warming the tea pot with hot water, pouring out the hot water, adding the tea leaves to the pot (I prefer leaves in an infuser - some use tea bags, and that's OK, at the office I do the same thing.) Then pouring the not-quite-boiling water into the pot and ... tea.
But that takes waiting a moment. It takes knowing the right time to do the right thing. Not too soon and not too late.
The thing with testing I've seen lately - so many people want to charge in and test stuff. NOW! Just DIVE IN!
I might suggest making a tea... or a coffee if you prefer. I like a really good cup of coffee, too. I blogged about that once upon a time. I really like a good cup of coffee.
Ask some questions. I might start with asking something like "Why are we doing this? What do we hope to learn from testing this? If you are telling me how you want the software tested, will that 'how' answer the question 'why'?"
This might seem obvious to some people I often associate with. To others, I think they might not understand why.
Another set of questions might start with something like, "Is there something we should probably know about this that we have not considered?" Another way to ask that might be "Is there something acting against the system, or the data that is used by the system, that is important? Maybe that we have not asked about? Is there something that 'everybody knows' we have not thought about?"
If you are testing a system that you have been participating in developing, some of these questions may not be so important - if you have been in the discussions around how the software should work, and why. Of course, when it comes to that, it might be important to ask yourself if you have built up an immunity to such things. Your certainty and understanding might be of value. Then again, if you clear your head and have a tea, then what happens if you look again with fresh eyes?
When you are handed software and told to "just test it" then remember that sometimes waiting a bit allows you to discover something you had not considered. Asking questions of people might reveal something important to you.
Those questions might tell you something about the software. The problem I see time and again is that people want to try and force the issue. They, or their bosses or developers or managers or PMs or someone, want them to jump in too soon.
Take the time to see what things look like after a tea, or a coffee. You might learn something about the software. You might learn something about the attitude of people you work with toward testing.
You might also learn something about yourself.
Tuesday, December 9, 2014
On Learning, Growth and Leaving Childhood Behind
Of late, I've been thinking a great deal on how people learn - how they "stay current" in their profession, to resurrect a buzzword from longer ago than I wish to recall. That got me thinking.
What have people done to learn something recently?
Let me see if I can explain where part of this thought developed from.
In the "Liturgical Year" I am writing this in the Second Week of Advent - the time of religious and spiritual preparation for Christmas. The Sermon/Homily this last Sunday was one that featured a note of irony. The gist of it was that Advent, the season of preparation, is one of waiting. People get ready for something they know is coming, but are not sure when it will actually come. The priest's point was that in an era when Christmas music starts on the radio and in shopping malls a day or two after Hallowe'en, when society is rushing toward a fixed date, the Church is asking people to pause and consider what may be coming.
On top of this, a few years ago, before the previous pastor retired, he gave a sermon about this same time of year. He stood in the middle of the church, the main aisle, and pointed at the stained glass windows that ran the length of the church - both sides. They really are lovely to look at.
Anyway, the pastor made a comment that many people's idea around matters of faith are those of a small child - the same basic things one learns in school, maybe age 7 or 8. People like the idea of Christmas and the child in the manger and the shepherds and the lights and tinsel and what-not. But they don't like the "opposite bookend" as the pastor described it. They don't like the story of that same child beaten, flogged and executed in a manner that boggles the mind of most people in this day and age.
As he was talking about this - he pointed to two windows. One, on his right, depicted the Christmas story. The other, on his left, exactly opposite the first, depicted Good Friday - the death of the same baby. His statement was simple. We can't accept the simple, childhood story without looking at the hard truth that accompanies it.
As mature adults, we need to step beyond the things we "learned" early on - either as children in school or as fledgling software professionals.
When was the last time we challenged our own beliefs and presumptions? When was the last time we critically considered what we were about? Have we become complacent?
Are we still operating based on our childhood understandings? Are we still operating on things we learned years ago and have not thought about? Are we passing on this same "wisdom" to people without a deeper understanding?
Why?
Should we simply accept the pronouncements of people whose learning and understanding stopped when they were 7 or 8 years of age? What about "professionals" whose learning stopped 10 or 15 years ago? How about 25 years ago?
What have people done to learn something recently?
Let me see if I can explain where part of this thought developed from.
In the "Liturgical Year" I am writing this in the Second Week of Advent - the time of religious and spiritual preparation for Christmas. The Sermon/Homily this last Sunday was one that featured a note of irony. The gist of it was that Advent, the season of preparation, is one of waiting. People get ready for something they know is coming, but are not sure when it will actually come. The priest's point was that in an era when Christmas music starts on the radio and in shopping malls a day or two after Hallowe'en, when society is rushing toward a fixed date, the Church is asking people to pause and consider what may be coming.
On top of this, a few years ago, before the previous pastor retired, he gave a sermon about this same time of year. He stood in the middle of the church, the main aisle, and pointed at the stained glass windows that ran the length of the church - both sides. They really are lovely to look at.
Anyway, the pastor made a comment that many people's idea around matters of faith are those of a small child - the same basic things one learns in school, maybe age 7 or 8. People like the idea of Christmas and the child in the manger and the shepherds and the lights and tinsel and what-not. But they don't like the "opposite bookend" as the pastor described it. They don't like the story of that same child beaten, flogged and executed in a manner that boggles the mind of most people in this day and age.
As he was talking about this - he pointed to two windows. One, on his right, depicted the Christmas story. The other, on his left, exactly opposite the first, depicted Good Friday - the death of the same baby. His statement was simple. We can't accept the simple, childhood story without looking at the hard truth that accompanies it.
As mature adults, we need to step beyond the things we "learned" early on - either as children in school or as fledgling software professionals.
When was the last time we challenged our own beliefs and presumptions? When was the last time we critically considered what we were about? Have we become complacent?
Are we still operating based on our childhood understandings? Are we still operating on things we learned years ago and have not thought about? Are we passing on this same "wisdom" to people without a deeper understanding?
Why?
Should we simply accept the pronouncements of people whose learning and understanding stopped when they were 7 or 8 years of age? What about "professionals" whose learning stopped 10 or 15 years ago? How about 25 years ago?
Sunday, December 7, 2014
On Growth and Learning and the Wisdom of Unicorns
I got a phone call the other day from a development manager who was not sure how to deal with a couple of issues and wanted to bounce ideas off a neutral party. We met for a coffee and chatted for a bit and she got a very distinct look in her eye - one that meant she was at the place she needed to be in order to ask the questions she wanted to ask.
"Why don't people want to learn new ideas about making software?"
Oh my. I admit, that made me put down my coffee cup and ask what she meant.
"I don't really know,and that is frustrating me. Let me explain. We talked before about how people are 'motivated' and I get your point that external motivation does not really work, at least not for the long-term. I understand and see now how the 'threat-reward' model I've been told to use really doesn't do what we want it to do. It certainly did not work when I was a developer, why should it work on other developers?"
"OK, fair point," I said. She smiled.
"I guess my problem is I don't know how to encourage people to learn something new - how to try and look at their careers as being more than what their job is right now. I can offer classes and they aren't interested. I offer to set up lunch and learns and bring in whatever food they want and no one is interested. I send out notices of meetups they might be interested in and no one goes to them. I offer to bring in outside instructors to teach cool new techniques and no one wants to be bothered. 'It doesn't apply to what we are doing' is what they say. How do I overcome that?"
Ouch. Yeah, it reminds me of a shop where I worked where over half the folks writing production code wanted nothing at all to do with "new languages" or "new ways" of doing things. The new language in question was COBOL - yeah - that was the new language. Mind you, I was teaching myself VB and C at the time so I had no sympathy for people not wanting to learn new stuff.
There is an idea that I find troubling in the recurring theme of "you can't make me learn new stuff" - until the jobs using the "old stuff" all kind of went away. (I know there are still a bunch of people doing COBOL, but as a percentage of all software development? COBOL used to be THE language for people writing software for businesses - it's now a benchmark for how old you are in many shops.)
We talked on that a bit. We talked on the question of "how do I get people to go to GR Testers meetups" - the answer to that one is easy "Offer something they are interested in."
We talked a bit on the number of developers and testers at the company where she worked - and the percentage of those who expressed a desire to learn more things - at the entire company, not just on her team. There are some who are hungry for more knowledge, information and ideas. Then there are the majority of people who shrug and are not interested.
I warned her to be careful of rejecting the idea of learning new things because they "don't apply" right now. I have learned so many things that can be applied in multiple contexts that they are amazing to me when I look back at them. If I had rejected things because they "don't apply right now" what I really meant was "I don't see an immediate application for this nor do I see how it will help me in the short term."
That does not mean I will not seek out information or ideas I can apply or might be able to apply. If I have a choice of learning opportunities, one that has a direct application to where I am in my professional path and one that does not, at this time, have a direct application I can see, I tend to go to the first option - particularly if they are happening at the same time.
"But, Pete, you're an expert. What is there really for you to learn?"
Oh dear, First I'm not an expert. I am learning all the time. There is much more for me to learn. When there is nothing more for me to learn, then go ahead and say I'm an expert. Until then, I need to keep at it.
At that point, the Unicorn at the next table cleared its throat and harumphed in a significant way. I was a little surprised to see him, this was not the usual coffee shop where I'd run into him. I was a little taken aback. The nice person I was chatting with had eyes that looked to be bugging out.
"I can't believe it! When did a Unicorn sit down here?"
The Unicorn smiled and said "I was here when you sat down. You finally noticed I was here, that's all. Forgive me if it seems I was eavesdropping, but there is something maybe you could point out to your team."
At this point, I was not really certain what to expect the Unicorn to say.
"Remind them that all the people complaining about not being able to have a chance to apply for the new 'technology' jobs we keep hearing about in the news - the ones the 'tech companies' say need more visas to allow workers from other countries to come in and do - Many, not all, but many of those people had the opportunity to learn these new languages and techniques and chose not to. Now they want to be 'given a chance' and learn them, but I think for many it is too late."
I jumped in (a fairly brave thing to interrupt a Unicorn) with an observation. "I don't know if that is a fair summation of what is going on. There are many people who have been trying to learn these new things and find themselves pulled away for other responsibilities. Not everyone has the time or resources to learn and embrace these new technologies and techniques."
The Unicorn smiled and said "But the things this nice lady here has been describing seems to me to be presenting these opportunities at little or no cost to her staff, other than time, and they are rejecting the chances. In 5 or 10 years when there is some cool new technology the company wants to put in place, how likely is it that the people who were offered and rejected an early start will get to work on it? How likely is it that they will find themselves relegated to 'maintenance' for the old system while the new system is being developed?"
I sat back and realized I had seen that pattern many, many times in the last 30 years. Suddenly, I felt very sad.
The development manager seemed deep in thought. She asked the Unicorn what she could do that might help her team - warn them from this path.
He looked at her and smiled. "Lead by example. Take a course on something new. Go to some of the meetups when you can - let them know you are going and offer to make an outing of it. Offer to pick up dinner for anyone who joins you. I know you have kids and responsibilities. How many nights do you work late at the office? What if you were to bring papers home and work on them from home after the kids were in bed instead? What if once every two weeks, or maybe a month, you came home after a meetup and tucked them in?"
"You could explain to the kids that you had to go to school to keep learning new things, too - just like they did. And sometimes the school class was at night. The children may learn something about always learning. Maybe your staff might learn something as well."
As I drove back to my office that day, I thought about the Unicorn. He had said things I would not have dared say - and part of me wanted to reject as "UNFAIR!" Except I learned long ago that many things are unfair.
Baseball should allow 4 or 5 strikes before the batter is "out." (I had terrible hand-eye coordination as a kid - that seems perfectly reasonable to the 9 or 10 year old self.) In (American) football, there should be 5 "downs" to advance the ball 10 yards for a first down. These would make it "more fair" by some measures - and then unfair by others.
We may not be able to change the way the world is, but we can change how we respond to it and how we act to others who are also struggling to respond. We can lead. We can help others along the path, if they want help. We can continue learning.
If you are reading this, I hope you are one of the people having a problem trying to learn new things. There is a possibility, however, that you wish to only get trained in areas where you are comfortable. I hope that is not the case.
Learn and grow.
"Why don't people want to learn new ideas about making software?"
Oh my. I admit, that made me put down my coffee cup and ask what she meant.
"I don't really know,and that is frustrating me. Let me explain. We talked before about how people are 'motivated' and I get your point that external motivation does not really work, at least not for the long-term. I understand and see now how the 'threat-reward' model I've been told to use really doesn't do what we want it to do. It certainly did not work when I was a developer, why should it work on other developers?"
"OK, fair point," I said. She smiled.
"I guess my problem is I don't know how to encourage people to learn something new - how to try and look at their careers as being more than what their job is right now. I can offer classes and they aren't interested. I offer to set up lunch and learns and bring in whatever food they want and no one is interested. I send out notices of meetups they might be interested in and no one goes to them. I offer to bring in outside instructors to teach cool new techniques and no one wants to be bothered. 'It doesn't apply to what we are doing' is what they say. How do I overcome that?"
Ouch. Yeah, it reminds me of a shop where I worked where over half the folks writing production code wanted nothing at all to do with "new languages" or "new ways" of doing things. The new language in question was COBOL - yeah - that was the new language. Mind you, I was teaching myself VB and C at the time so I had no sympathy for people not wanting to learn new stuff.
There is an idea that I find troubling in the recurring theme of "you can't make me learn new stuff" - until the jobs using the "old stuff" all kind of went away. (I know there are still a bunch of people doing COBOL, but as a percentage of all software development? COBOL used to be THE language for people writing software for businesses - it's now a benchmark for how old you are in many shops.)
We talked on that a bit. We talked on the question of "how do I get people to go to GR Testers meetups" - the answer to that one is easy "Offer something they are interested in."
We talked a bit on the number of developers and testers at the company where she worked - and the percentage of those who expressed a desire to learn more things - at the entire company, not just on her team. There are some who are hungry for more knowledge, information and ideas. Then there are the majority of people who shrug and are not interested.
I warned her to be careful of rejecting the idea of learning new things because they "don't apply" right now. I have learned so many things that can be applied in multiple contexts that they are amazing to me when I look back at them. If I had rejected things because they "don't apply right now" what I really meant was "I don't see an immediate application for this nor do I see how it will help me in the short term."
That does not mean I will not seek out information or ideas I can apply or might be able to apply. If I have a choice of learning opportunities, one that has a direct application to where I am in my professional path and one that does not, at this time, have a direct application I can see, I tend to go to the first option - particularly if they are happening at the same time.
"But, Pete, you're an expert. What is there really for you to learn?"
Oh dear, First I'm not an expert. I am learning all the time. There is much more for me to learn. When there is nothing more for me to learn, then go ahead and say I'm an expert. Until then, I need to keep at it.
At that point, the Unicorn at the next table cleared its throat and harumphed in a significant way. I was a little surprised to see him, this was not the usual coffee shop where I'd run into him. I was a little taken aback. The nice person I was chatting with had eyes that looked to be bugging out.
"I can't believe it! When did a Unicorn sit down here?"
The Unicorn smiled and said "I was here when you sat down. You finally noticed I was here, that's all. Forgive me if it seems I was eavesdropping, but there is something maybe you could point out to your team."
At this point, I was not really certain what to expect the Unicorn to say.
"Remind them that all the people complaining about not being able to have a chance to apply for the new 'technology' jobs we keep hearing about in the news - the ones the 'tech companies' say need more visas to allow workers from other countries to come in and do - Many, not all, but many of those people had the opportunity to learn these new languages and techniques and chose not to. Now they want to be 'given a chance' and learn them, but I think for many it is too late."
I jumped in (a fairly brave thing to interrupt a Unicorn) with an observation. "I don't know if that is a fair summation of what is going on. There are many people who have been trying to learn these new things and find themselves pulled away for other responsibilities. Not everyone has the time or resources to learn and embrace these new technologies and techniques."
The Unicorn smiled and said "But the things this nice lady here has been describing seems to me to be presenting these opportunities at little or no cost to her staff, other than time, and they are rejecting the chances. In 5 or 10 years when there is some cool new technology the company wants to put in place, how likely is it that the people who were offered and rejected an early start will get to work on it? How likely is it that they will find themselves relegated to 'maintenance' for the old system while the new system is being developed?"
I sat back and realized I had seen that pattern many, many times in the last 30 years. Suddenly, I felt very sad.
The development manager seemed deep in thought. She asked the Unicorn what she could do that might help her team - warn them from this path.
He looked at her and smiled. "Lead by example. Take a course on something new. Go to some of the meetups when you can - let them know you are going and offer to make an outing of it. Offer to pick up dinner for anyone who joins you. I know you have kids and responsibilities. How many nights do you work late at the office? What if you were to bring papers home and work on them from home after the kids were in bed instead? What if once every two weeks, or maybe a month, you came home after a meetup and tucked them in?"
"You could explain to the kids that you had to go to school to keep learning new things, too - just like they did. And sometimes the school class was at night. The children may learn something about always learning. Maybe your staff might learn something as well."
As I drove back to my office that day, I thought about the Unicorn. He had said things I would not have dared say - and part of me wanted to reject as "UNFAIR!" Except I learned long ago that many things are unfair.
Baseball should allow 4 or 5 strikes before the batter is "out." (I had terrible hand-eye coordination as a kid - that seems perfectly reasonable to the 9 or 10 year old self.) In (American) football, there should be 5 "downs" to advance the ball 10 yards for a first down. These would make it "more fair" by some measures - and then unfair by others.
We may not be able to change the way the world is, but we can change how we respond to it and how we act to others who are also struggling to respond. We can lead. We can help others along the path, if they want help. We can continue learning.
If you are reading this, I hope you are one of the people having a problem trying to learn new things. There is a possibility, however, that you wish to only get trained in areas where you are comfortable. I hope that is not the case.
Learn and grow.
Saturday, December 6, 2014
Random Stuff from Agile Testing Days 2014
Agile Testing Days, in Potsdam, Germany, wrapped up a bit over a month ago. I collected a variety of images, pictures and other stuff. So, I'm going to try and post some of these here - in sequence - and tell a story differently than I normally do.
It was a pile of work, many very good sessions, excellent conversation, extremely good learning and intelligent, thinking people.
Monday - Workshop...
Tuesday - Keynotes
Costume Party - Tuesday Night...
Wednesday
 |
| Ummm, this was my session. People were still coming in, some are sitting in the aisle and off to the left of where I was standing. |
The Car
Thursdsay
It was a pile of work, many very good sessions, excellent conversation, extremely good learning and intelligent, thinking people.
Sunday, November 23, 2014
Agile Testing Days, Conversations and Considerations (pt 2)
Tuesday, that same person opened up all the channels and we ended up buried.
I digress.
Instead, I have been thinking about conversations around the office. One of them was "So, did you get to Lean Coffee? You always talk about how cool it is..." Well, I must admit I did not. Not once in Germany did I get into the official meeting place with a coffee and chat with people in typical "lean coffee" mode (time-box discussion around dot-voted topics put forward.)
And I missed every single one. Sheesh.
I did TRY! Three days I was up early, showered, shaved and dressed and down for breakfast. And three days something got in the way. Conversation.
One morning it was conversation with Matt Heusser and Meike Mertsch and ... OK, there was a rotating list of people in and out. I don't remember everyone who was there. Another time it was a veritable who's-who. Including Bob Marshall (@flowchainsensei).
My conversation with Bob that day was short. He headed out to Lean Coffee - other people allowed me to be dragged into more conversation.
The third day was amazing. I had several minutes with Bob - and no one around. (That actually is kind of a rare thing at a breakfast place in a nearly sold-out conference center.)
The conversation made me think of several things - and bits come back from time to time.
Simply put: Words have meaning.
Easy, right? Except, there is a problem with some people's approach. The question is, an you converse and share ideas in a way that allows your meaning to be clear with the other person, without causing offense.
OK, to be fair, that was not the conversation - that was one of the things I've been thinking about since. The way we frame ideas and thoughts and how we present them may make perfect sense to us, and leave others utterly clueless.
When people talk about "communication" much of the time they mean "how to say stuff." Except that is a "push" function - Communication is a "pull" function - what does the other person actually receive from what we are trying to deliver?
Can we deliver what people need, in a way they need it, in such a way that they can receive it? (OK, find Bob's stuff on going beyond the "Golden Rule." The thing where we don't treat others as we wish to be treated, but as they wish to be treated.)
Can we find a way to share information that will be received - including how we frame the information we present? Can we form the images in our mind in ways that do not form negative images? Can we build positive images to build on?
Can we do things without causing injury or harm? Even to ourselves? Can we build a positive communication style and model that can help make things better?
I'm still thinking on this.
Wednesday, November 19, 2014
Agile Testing Days, Conversations and Considerations (pt 1)
I returned from Potsdam, Germany roughly a week ago. I had the immense pleasure of participating in Agile Testing Days - speaking and interviewing speakers and participants - and on the Monday, "moderating" the finals of the Software Testing World Cup - an international testing contest.
Others have written about the testing contest in detail - I judged some continental contests and was present for the finals. The cool thing was that the conference hosts flew the winners of each of the continental qualifying contests to Germany for Agile Testing Days, put them up and gave them all conference passes. Pretty cool.
I found myself doing something resembling "play by play" at the testing contest - which proved more difficult than I expected! The challenge was describing something I could see but - even if you zoomed over with a camera - might not "see." I don't know if that makes sense - ah well. It was an excellent time.
The rest of the week, I kept running into various competitors. We talked about testing and life and communications and... well, there were a few other points.
As I was on my way out - at Tegel Airport checking in for my flight - there were some tester/competitors there also. We spoke of the conference and the experiences we had individually and together - and the takeaways we had.
Then there was the topic that is always near and dear to me "This was great. I learned so much and have loads of stuff to bring back. They (the company) will never pay for me to come back here next year."
So I said, "Well, there is a way - Speak." (Insert a chorus of "No! I can't! I'm terrible at speaking in front of people!"and other similar comments.)
Here's what I mean -
You just returned from a conference with loads of opportunity for learning and meeting people and hanging out and talking and... yeah. You get the idea.
You have loads of notes and ideas. The boss is probably going to want to know what you came back with and - really importantly - how can they be implemented at the company.
BING! (as in a bell going off...)
There is your entrance!
Take the information you brought back - make sure it is written down or recorded in some way to help you remember it.
Here's the hard part: Try the ideas.
Maybe not all at once - but maybe one at a time. Look at the ones likely to help your organization and try them. Not just once but try them several times. If they work the first time, you want to be sure that that was not a one-off. If they don't work the first time, was that because of the way you tried to implement them? Who knows! Look to see what happens.
Record what you tried to do. Record what you hoped would be the results. Record the results. Then, record your own reactions to what you learned from the trying of it.
Record what you learned - how did it impact what you do and how can it be of value to your company? Then, take these notes and ideas - write them out. Describe your journey.
Then share it.
Writing. Speaking. Having a coffee with people at the office. Having a beer with folks after work.
The more you do these things, the easier it becomes.
===
What triggered this was a conversation leaving Agile Testing Days. That is a really good conference. However, these ideas can be applied to any set of conference learnings or take-aways.
Try them. Be bold.
I have every confidence in you.
Others have written about the testing contest in detail - I judged some continental contests and was present for the finals. The cool thing was that the conference hosts flew the winners of each of the continental qualifying contests to Germany for Agile Testing Days, put them up and gave them all conference passes. Pretty cool.
I found myself doing something resembling "play by play" at the testing contest - which proved more difficult than I expected! The challenge was describing something I could see but - even if you zoomed over with a camera - might not "see." I don't know if that makes sense - ah well. It was an excellent time.
The rest of the week, I kept running into various competitors. We talked about testing and life and communications and... well, there were a few other points.
As I was on my way out - at Tegel Airport checking in for my flight - there were some tester/competitors there also. We spoke of the conference and the experiences we had individually and together - and the takeaways we had.
Then there was the topic that is always near and dear to me "This was great. I learned so much and have loads of stuff to bring back. They (the company) will never pay for me to come back here next year."
So I said, "Well, there is a way - Speak." (Insert a chorus of "No! I can't! I'm terrible at speaking in front of people!"and other similar comments.)
Here's what I mean -
You just returned from a conference with loads of opportunity for learning and meeting people and hanging out and talking and... yeah. You get the idea.
You have loads of notes and ideas. The boss is probably going to want to know what you came back with and - really importantly - how can they be implemented at the company.
BING! (as in a bell going off...)
There is your entrance!
Take the information you brought back - make sure it is written down or recorded in some way to help you remember it.
Here's the hard part: Try the ideas.
Maybe not all at once - but maybe one at a time. Look at the ones likely to help your organization and try them. Not just once but try them several times. If they work the first time, you want to be sure that that was not a one-off. If they don't work the first time, was that because of the way you tried to implement them? Who knows! Look to see what happens.
Record what you tried to do. Record what you hoped would be the results. Record the results. Then, record your own reactions to what you learned from the trying of it.
Record what you learned - how did it impact what you do and how can it be of value to your company? Then, take these notes and ideas - write them out. Describe your journey.
Then share it.
Writing. Speaking. Having a coffee with people at the office. Having a beer with folks after work.
The more you do these things, the easier it becomes.
===
What triggered this was a conversation leaving Agile Testing Days. That is a really good conference. However, these ideas can be applied to any set of conference learnings or take-aways.
Try them. Be bold.
I have every confidence in you.
Thursday, November 13, 2014
LIVE! From Potsdam! Agile Testing Days - Day 3!
Thursday, 13 November - I'm STILL at Agile Testing Days in Potsdam, Germany. I stayed up a bit too late last night doing things like hanging with folks and talking and playing games - then finishing blog posts from Day 0. (ahem)
I was intending to make it to Lean Coffee this morning, particularly as I had not been there at ALL this week. As it was, whilst having a nice chat with people over breakfast I lost complete track of time. Oops. I did stick my head in and see how things were going though. It looked like a good group of folks divided up into 3 tables/discussions.
===
Sitting now waiting for the morning's keynote with Antony Marano talking on "Don't put me in a box."
If Antony, or someone else, walks up and says "Hello, what do you do?" Most people will describe something critical about themselves - this may be something related to their job or not. In most of them, it is putting us in a category - a box.
Job titles tend to show how important people are - either in their companies or by some other model.
Comparatively, in the 1960's "Dads" and "Moms/Mums" had extremely narrowly defined roles around the house and raising children. The difference is that today these roles have shifted. There may be some variation, but the general gist is toward more balanced work sharing.
Companies are like this as well. In the 1960's there were very specific roles and responsibilities and things were pretty straight forward. Today things are straight forward in a totally different way. Usually. Some companies are still acting as if they are in the 1960's. Too bad.
The point is - work is changing - How we do things is changing. Tony describes his first experience in "pair programming" - with his Dad on a Commodore 64 (I remember those!) He wrote a simple program to do some estimates so his Dad did not need to spend hours and hours doing calculations by hand - and they could spend more time together.
Except, when he went to work - he was told, in essence, "Ummm, sorry, we don't do it that way."
Point of the story - Don't do stuff the way someone tells you to do it simply because of the job title you have. Look for ways to do it efficiently and effectively.
Moved on to another (familiar) story - working on a team "in IT" where half the people on the company say "Oh! You're in IT? I'm having this problem with my email/printer/something lame." Except in this company, you had to get from one group of the company to the other, you had to walk around the atrium - there was a "rule" that one could not simply walk across the atrium ("You'd ruin the view the lawyers had... or something") an you HAD to walk around. Except that doing that the people tended to spend loads of time walking around instead of doing stuff.
And then one day he got forgotten when the team he was working with (well, doing stuff with) that sat on the other side of the atrium went to the pub and forgot about him. Bummer. Yeah, that is kind of no fun. No harm was meant - they simply grabbed the folks that were around them and went.
So, there was an empty desk near them, and he packed up his stuff and moved to that desk. When asked why, it was so he could work better with them. Actually, it was to make sure he would not get forgotten when going to the pub - well - maybe it was to really work better with them. Asking questions and getting better understanding - and soon, the devs are all working with him to make sure their stuff is right and they being referring to him as their "go-to guy."
"I don't think it gets the best out of people to call them a 'resource' because it gives the message that they can be thrown away."
And he's citing "Tayloristic mindset" of management! ROCK ON!
We should not manage "Quality" by managing a process (YEAH!) instead we should manage quality by empirical evidence. What data points do we have to measure what we are doing? Can we have some real measures that make sense?
"I think quality comes from people, not process."
And he's telling a story about testing games. In this case, the computerized version of the tactical response training - the thing used to train police & soldiers on "live scenario" training - where targets pop up and you shoot - or don't.
The first time they tested that, they were given specific tasks - then repeat precisely each time. Same people in the same role. Except the thing was, that is slower than other methods.
To increase flow, the "entry team" for room clearing - the two guys who actually entered a room after the door had been forced and the "distraction device" was deployed & went off, the rest of the team could move to the next room without waiting for the two folks in the room to get out and take up their original positions. THis allows fast movement, better flow and (frankly) acknowledges that there is a chance - a good chance - that one of those guys that went into the room may not come out. Its a sad fact that this must be build into training.
It may not be exactly agile, it is lean - eliminating waste and increasing flow to support customers. We can do that whether the "customers" are hostages to be released or application products to be released.
---
As always this week, loads of stuff was presented and I simply could not keep up. I hope someone else catches stuff I missed... (oh, twittersphere?)
--
Brialliant Question! "Should testers need to learn to code?" FANTASTIC ANSWER! "I dislike the work 'should' because it means 'I know better than you do what you are doing and how.' In reality, people need to be concerned about being put into limiting boxes, e.g., specific job titles... Instead look into other areas, broaden your horizons and look to how many things can be applied in different ways in different situations." (Pete note: He's describing my definition of "context.")
==
Right - I'll be interviewing the winners of the Software Testing World Cup for 2014 - Cesar Brazil! So as cool as that is, I won't be in a track talk for the first track session - We'll see what happens and what shape I will be in for the second track block. See you all in a while - Cheers -
==
Had a lovely visit with Cesar Brazil and then a nice hallway chat with Christina Ohanian (shetweeted a picture of her sketch notes from my talk yesterday. Pretty cool.
AND NOW! in Dan Ashby's session on Lateral and Critical Thinking Skills for Testers.
He launches by having a volunteer say the colors on the screen - except the words were colors - so, like, "YELLOW" was in Green text, "RED" was in Blue text, and so on.
Western logical thinking is based on the work of the "Greek Gang of Three" - Socrates, Plato & Aristotle. The thing is, most "logic" is based on argument. The OTHER thing is, Plato had this habit of gathering information & putting into buckets - categories. This became the root for describing "critical thinking."
For example - how do you get from where you live to where you want to go for supper? There are any number of possibilities. Walking? Taxi? Traffic patterns? Lights? Then again, the whole world tends to look at things... differently.
Loads of examples - cool stuff - TOO BLOODY FAST (which is one of my heuristics for a good
conference session.)
Loads of good conversation& exchanges (another of my heuristics for a good conference session.)
Citing Ed de Bono - "You cannot dig a hole in a different place by digging the same hole deeper." Cool guy - he coined the term "Lateral Thinking."
What kind of scenarios work for the supposition? What things won't work? (Pete note: How can people keep learning when they are not sure what they are about?)
OK - More de Bono - "Lateral thinking is for changing concepts and perceptions."
Cool pic - "What do you see? How many items can you see in the pic - simple, eh?
Then he does a cool "connect the dots" exercise. It's pretty good and I won't take pics of that. It is good though. Have a chat with Dan if you want to see the examples.
Lateral Thinking skills help us get to the ability to test the software (or requirements) or... see Alan Page's comment - "Good test ideas lead to good test design."
And another good example - wine glass stuff... As a bar tender I want to be able to pour wine from a bottle into a wine glass. There are a couple of questions around the "acceptance criteria" - like "what is it made of? does it hold wine? and so forth. Good stuff -
He then lists a group of books - de Bono's again - Thinking Fast and Slow - 6 Thinking Hats... all good resources to help people improve their testing.
Right - that wrapped up way too fast. Sometimes 40 minutes is not nearly enough time.
==
Lunch and a bit of a rest to let things assimilate. Then afternoon activities.
===
Right - had a lovely conversation with loads of people - recharged the engines and talked with Jose Diaz - the conference ... master? I don't know - smart man, good man (sadly a rare combinations sometimes) and generally an all around Spanish Gentleman, in the classic sense.
I'm back in the plenary session room to catch some concession talks. I like the idea of them - short, concise talks on a topic the speaker is passionate about.
First Concession talk I make it into is Test First Code Later by Christina Ohanian. She's based in London, remarkably bright (see the comment I made about about the chat I had with her. Christina is making a bang at the start - "Great! Another Bug! Log it! That makes 50 bugs - we must be doing something right!"
NO WE'RE NOT. We're doing it wrong. If we have this number of bugs we're dfinding in testing something is serious wrong. Why do we spend so much time chasing bugs and not keeping them out in the first place - Why do we have so many problems?
Heh - Maybe because we fail at conversations. Conversations Matter.
Can testers really get involved in the discussions before code gets written? Yeah, that's right - they're there to ask questions.. .blah blah blah - ARE TESTERS ASKING THE RIGHT QUESTIONS?
Simply put, they can't ask any questions if they are not in the conversation in the first place (OK - see my note on Dan Ashby's talk - she is cruising along - pounding out points - hard to keep up. Luvin it!)
Scenarios, sketches, condition lists, prototypes are all part of her description of "testing first." She is cautious about prototypes - because too often they become the final product - and are poorly built because it was "just a prototype." Ick.
What can be done though?
Well, Let's start with "Inspect and Adapt" - her note is "Use the Force, not a silver bullet..."
Next on her list is "Team Commitment" - Short lived success without that commitment.
Third - "Continuous Team Collaboration" - Two heads are better than one - as long as they actually work together and not independently.
Fourth - "A Culture Shift" - The light saber at the end of the tunnel.
(Matt Heusser is missed during that talk)
Instead of asking "Have we build the right thing?" - ask "Are we building the right thing?"
Technology changes every day - Nothing matters if toy don't know what you're building -(pete note: or on what platform it is needed.)
Tools won't save you (Pete Note: AMEN! AMEN!)
Yeah - well done - very nicely presented!
---
Next up, Helmut Pichler is presenting (Fr)agile Quality.
Helmut is from Vienna, Austria and is a tester with ANECON Software. The company offers assistance and support services in the area of "implementation strategies." He is ISQI Cat certified, ISTQB certified - and - I missed the third item on the slide (sorry.)
Citing Standish Report on Chaos. The 2012 Standish Chaos Report shows nice pie charts on failed projects between waterfall and agile projects - the percentages are different than the percentages cited y Joe Justice. (Pete note: Interesting.)
Loads of examples of "failed projects" - mostly clippings from German language papers.
OK - there are some interesting numbers being said - and some bar graphs going up on the screen. Alas, my German is not good enough to follow the slides along. Not all are in German, but a fair number of them are.
Pete Note: Not a bad summary of the pros/cons and other ideas around Agile implementation. It seems a bit pedestrian, but it could be me having a hard time isolating his points.
---
Coming Up! The FINAL keynote of Agile Testing Days 2014!
Helping Testers Add Value to Agile Projects with Alan Richardson (@eviltester) - Yeah - I'm looking forward to this one.
We're set and ready to go - Jose Diaz is at the front of the room making some announcements- including that there is more happening after Alan's talk.
He starts with the observation that there are trends in the keynotes this year. And that is a trend in message. I think to BREAK that trend he starts with the philosopher Warren Zevon and his master work "It ain't all that pretty."
How? By working on the reality that is in place - regardless of what people want to see - things get in the way of that.
Which brings us The Dread Pirate Roberts - Quoted by S Morgenstern - abridged by WIlliam Goldman to text and screen...
Westley makes himself useful, he does stuff that adds value - and eventually Westley learns that the Dread Pirate Roberts is not the DPR - he's a fellow who learned the trade - and became the DPR when the previous DPR retired... and Westley becomes the DPR.
Fine.
Except testers look at things from a different angle - They disabuse people of the notuon that they are something they are not.
Testers mantra should be "I'm not here to make you look good." I'm here to help you see what is and do it better,
We survive by learning to adapt to the system OF development. (Pete - so Warren Zevon, Pricness Bride and now slides with images from Transformers (the comic books).)
In 1901 there was a news story about Annie Edson Taylor - the first woman to gove over Niagara Falls in a barrel - And the story that she would rather be shot from a cannon than go over a waterfall again.
Alan's comment - "I survived the waterfall, and won't do it again."
And now - William Blake is cited -
Except - the first time Alan was on an "Agile" project, he's asked to write a test strategy. Gah.
He was stuck on - Writing a test strategy - Poor stories and acceptance criteria - etc.ad nauseum...
And NOW we get Pink & the Brain! "Tomorrow, we take over the world!"
Except his normal behaviors from the past - where he can assert himself and take things on - excet it becomes very hard. So he ned to expand his reality.
He needs to learn Java - the Perl - AND then he needed to learn & improve his TDD skills.
He did not know the technology so he had to learn it - he needed to also expand his skills and embrace the ideas in new ways. He got to "what is "done"? What can be done to advance what testing was in Agile.
THEN - the next task was "get to done" with no stories that fixed the stuff that was done... wrong.
NO-ONE ELSE knew what testing was supposed to look like - so he made it up.
Scary - BUT! Life is good.
And Alan then reverted to form - He did what he always did -
Mat the "ptest process" and adance the goals.
When you look at AGILE in isolation - life kind of sucks (Pete: that's my paraphrase cuz Alan is FLYING past points - HOLY COW!!!!!!)
Instead - looking at Agile as a SYSTEM leads to broader understanding - this allowd us to look at things differently each and every time because we are on projects that are not like the last 5 or 6. We are wortking withy people who may not have worked with us before. THESE are the things that REALLY contribute to to moving things forward.
And he's citing Sun Tzu's Art of War as a referene - YES -
Loot, Pillage, Raid and Steal from other disciplines - by "borrowing it - we need to give it back. So WE TAKE IT - that makes it ours. (I think Alan has Viking blood in him...)
And here comes "Green Eggs and Ham" reference - but it is "Do not call me QA" (I got a pic of the
QA is not Testing - call it QA - he calls it Tester. Ask for a "QA Team Report" and there will be silence. (Pete note: AMEN!)
People new to Agile need help - let the experienced ones help the novices - but let people try things themselves! If you impose YOUR model of "Agile" on a group - YOU HAVE FAILED! You are no longer Agile - You are going to a dark evil place (well, Pete is paraphrasing cuz he's going right bloody fast.)
Foster of attitude - of helping testers; and of ownership - and of How to surviveloads of stuff. Its all good.
"Only variety can absorb variety." Stafford Beer restating - (Pete note: bugger - missed that original source - sorry.)
Teams absorb behavior & respond...
Testers need to help foster tester's survival.
--
Pete Note - ALAN! I need some slides I could not get good pics of - unless u don't want them in the blog...
===
And NOW - Janet & Lisa are giving a retrospective?
I think?
A skit - brandy & cigars? Maybe a Boston Legal meme? so maybe its Scotch?
And Super Agile Person makes a return - and Jose is the barman - with a nice apron - and a ... mustache?
So they are going over the conference - with a C/W song in the background? if I knew country better I could tell you - but I don't. Oh well.
Mobile testing - vendor demos - hallway conversations - and some unexpected things - like non-violent communication, non-judgemental observations (Bob Marshall's stuff) - and - improving relationships - and - failing fast, but does that really mean "learning fast"? hmmmmmmmm - then the Open Space stuff gets mentioned - loads of fun stuff apparently - including the Lego workshop...
Then there was ... one of the challenge on their wall (in their workshop) - how do we get "skilled testers" - And now there is a room sharing their experiences - I'm not able to keep up - sorry -
==
And Jose is wrapping things up - bringing out Uwe and Madeleine - and recogizing Alex - who reviews the proposals - and WOW! I got a thank you gift for the live blogging, etc - that I am to bring home to my lady-wife, Connie. Thanks! I am honored -
Loads of people make an event like this happen.
And he is now thanking Matt Heusser and Maik Nogens for their work on Software Testing World Cup. That was a bunch of work - and loads of effort
Next Year - Nov 9-12 - 2015 - In Potsdam!
And on Tutorial Day - a kid's track - something appropriate for children that works in line with the theme of Agile & testing - Way cool idea.
Coming UP!
Agile Testing Day - Netherlands - March 19 - 2015!
===
This ends the day 3 Live blog - thanks for playing along -
Finished with engines.
I was intending to make it to Lean Coffee this morning, particularly as I had not been there at ALL this week. As it was, whilst having a nice chat with people over breakfast I lost complete track of time. Oops. I did stick my head in and see how things were going though. It looked like a good group of folks divided up into 3 tables/discussions.===
Sitting now waiting for the morning's keynote with Antony Marano talking on "Don't put me in a box."
If Antony, or someone else, walks up and says "Hello, what do you do?" Most people will describe something critical about themselves - this may be something related to their job or not. In most of them, it is putting us in a category - a box.
Job titles tend to show how important people are - either in their companies or by some other model.
Comparatively, in the 1960's "Dads" and "Moms/Mums" had extremely narrowly defined roles around the house and raising children. The difference is that today these roles have shifted. There may be some variation, but the general gist is toward more balanced work sharing.
Companies are like this as well. In the 1960's there were very specific roles and responsibilities and things were pretty straight forward. Today things are straight forward in a totally different way. Usually. Some companies are still acting as if they are in the 1960's. Too bad.
The point is - work is changing - How we do things is changing. Tony describes his first experience in "pair programming" - with his Dad on a Commodore 64 (I remember those!) He wrote a simple program to do some estimates so his Dad did not need to spend hours and hours doing calculations by hand - and they could spend more time together.
Except, when he went to work - he was told, in essence, "Ummm, sorry, we don't do it that way."
Point of the story - Don't do stuff the way someone tells you to do it simply because of the job title you have. Look for ways to do it efficiently and effectively.
Moved on to another (familiar) story - working on a team "in IT" where half the people on the company say "Oh! You're in IT? I'm having this problem with my email/printer/something lame." Except in this company, you had to get from one group of the company to the other, you had to walk around the atrium - there was a "rule" that one could not simply walk across the atrium ("You'd ruin the view the lawyers had... or something") an you HAD to walk around. Except that doing that the people tended to spend loads of time walking around instead of doing stuff.
And then one day he got forgotten when the team he was working with (well, doing stuff with) that sat on the other side of the atrium went to the pub and forgot about him. Bummer. Yeah, that is kind of no fun. No harm was meant - they simply grabbed the folks that were around them and went.
So, there was an empty desk near them, and he packed up his stuff and moved to that desk. When asked why, it was so he could work better with them. Actually, it was to make sure he would not get forgotten when going to the pub - well - maybe it was to really work better with them. Asking questions and getting better understanding - and soon, the devs are all working with him to make sure their stuff is right and they being referring to him as their "go-to guy."
"I don't think it gets the best out of people to call them a 'resource' because it gives the message that they can be thrown away."
And he's citing "Tayloristic mindset" of management! ROCK ON!
We should not manage "Quality" by managing a process (YEAH!) instead we should manage quality by empirical evidence. What data points do we have to measure what we are doing? Can we have some real measures that make sense?
"I think quality comes from people, not process."
And he's telling a story about testing games. In this case, the computerized version of the tactical response training - the thing used to train police & soldiers on "live scenario" training - where targets pop up and you shoot - or don't.
The first time they tested that, they were given specific tasks - then repeat precisely each time. Same people in the same role. Except the thing was, that is slower than other methods.
To increase flow, the "entry team" for room clearing - the two guys who actually entered a room after the door had been forced and the "distraction device" was deployed & went off, the rest of the team could move to the next room without waiting for the two folks in the room to get out and take up their original positions. THis allows fast movement, better flow and (frankly) acknowledges that there is a chance - a good chance - that one of those guys that went into the room may not come out. Its a sad fact that this must be build into training.
It may not be exactly agile, it is lean - eliminating waste and increasing flow to support customers. We can do that whether the "customers" are hostages to be released or application products to be released.
---
As always this week, loads of stuff was presented and I simply could not keep up. I hope someone else catches stuff I missed... (oh, twittersphere?)
--
Brialliant Question! "Should testers need to learn to code?" FANTASTIC ANSWER! "I dislike the work 'should' because it means 'I know better than you do what you are doing and how.' In reality, people need to be concerned about being put into limiting boxes, e.g., specific job titles... Instead look into other areas, broaden your horizons and look to how many things can be applied in different ways in different situations." (Pete note: He's describing my definition of "context.")
==
Right - I'll be interviewing the winners of the Software Testing World Cup for 2014 - Cesar Brazil! So as cool as that is, I won't be in a track talk for the first track session - We'll see what happens and what shape I will be in for the second track block. See you all in a while - Cheers -
==
 |
| Christina Ohanian |
AND NOW! in Dan Ashby's session on Lateral and Critical Thinking Skills for Testers.
 |
| Dan Ashby |
Western logical thinking is based on the work of the "Greek Gang of Three" - Socrates, Plato & Aristotle. The thing is, most "logic" is based on argument. The OTHER thing is, Plato had this habit of gathering information & putting into buckets - categories. This became the root for describing "critical thinking."
For example - how do you get from where you live to where you want to go for supper? There are any number of possibilities. Walking? Taxi? Traffic patterns? Lights? Then again, the whole world tends to look at things... differently.
Loads of examples - cool stuff - TOO BLOODY FAST (which is one of my heuristics for a good
conference session.)
Loads of good conversation& exchanges (another of my heuristics for a good conference session.)
Citing Ed de Bono - "You cannot dig a hole in a different place by digging the same hole deeper." Cool guy - he coined the term "Lateral Thinking."
What kind of scenarios work for the supposition? What things won't work? (Pete note: How can people keep learning when they are not sure what they are about?)
OK - More de Bono - "Lateral thinking is for changing concepts and perceptions."
Cool pic - "What do you see? How many items can you see in the pic - simple, eh?
Then he does a cool "connect the dots" exercise. It's pretty good and I won't take pics of that. It is good though. Have a chat with Dan if you want to see the examples.
Lateral Thinking skills help us get to the ability to test the software (or requirements) or... see Alan Page's comment - "Good test ideas lead to good test design."
And another good example - wine glass stuff... As a bar tender I want to be able to pour wine from a bottle into a wine glass. There are a couple of questions around the "acceptance criteria" - like "what is it made of? does it hold wine? and so forth. Good stuff -
He then lists a group of books - de Bono's again - Thinking Fast and Slow - 6 Thinking Hats... all good resources to help people improve their testing.
Right - that wrapped up way too fast. Sometimes 40 minutes is not nearly enough time.
==
Lunch and a bit of a rest to let things assimilate. Then afternoon activities.
===
Right - had a lovely conversation with loads of people - recharged the engines and talked with Jose Diaz - the conference ... master? I don't know - smart man, good man (sadly a rare combinations sometimes) and generally an all around Spanish Gentleman, in the classic sense.
I'm back in the plenary session room to catch some concession talks. I like the idea of them - short, concise talks on a topic the speaker is passionate about.
First Concession talk I make it into is Test First Code Later by Christina Ohanian. She's based in London, remarkably bright (see the comment I made about about the chat I had with her. Christina is making a bang at the start - "Great! Another Bug! Log it! That makes 50 bugs - we must be doing something right!"
NO WE'RE NOT. We're doing it wrong. If we have this number of bugs we're dfinding in testing something is serious wrong. Why do we spend so much time chasing bugs and not keeping them out in the first place - Why do we have so many problems?
Heh - Maybe because we fail at conversations. Conversations Matter.
Can testers really get involved in the discussions before code gets written? Yeah, that's right - they're there to ask questions.. .blah blah blah - ARE TESTERS ASKING THE RIGHT QUESTIONS?
Simply put, they can't ask any questions if they are not in the conversation in the first place (OK - see my note on Dan Ashby's talk - she is cruising along - pounding out points - hard to keep up. Luvin it!)
Scenarios, sketches, condition lists, prototypes are all part of her description of "testing first." She is cautious about prototypes - because too often they become the final product - and are poorly built because it was "just a prototype." Ick.
What can be done though?
Well, Let's start with "Inspect and Adapt" - her note is "Use the Force, not a silver bullet..."
Next on her list is "Team Commitment" - Short lived success without that commitment.
Third - "Continuous Team Collaboration" - Two heads are better than one - as long as they actually work together and not independently.
Fourth - "A Culture Shift" - The light saber at the end of the tunnel.
(Matt Heusser is missed during that talk)
Instead of asking "Have we build the right thing?" - ask "Are we building the right thing?"
Technology changes every day - Nothing matters if toy don't know what you're building -(pete note: or on what platform it is needed.)
Tools won't save you (Pete Note: AMEN! AMEN!)
Yeah - well done - very nicely presented!
---
Next up, Helmut Pichler is presenting (Fr)agile Quality.
Helmut is from Vienna, Austria and is a tester with ANECON Software. The company offers assistance and support services in the area of "implementation strategies." He is ISQI Cat certified, ISTQB certified - and - I missed the third item on the slide (sorry.)
Citing Standish Report on Chaos. The 2012 Standish Chaos Report shows nice pie charts on failed projects between waterfall and agile projects - the percentages are different than the percentages cited y Joe Justice. (Pete note: Interesting.)
Loads of examples of "failed projects" - mostly clippings from German language papers.
OK - there are some interesting numbers being said - and some bar graphs going up on the screen. Alas, my German is not good enough to follow the slides along. Not all are in German, but a fair number of them are.
Pete Note: Not a bad summary of the pros/cons and other ideas around Agile implementation. It seems a bit pedestrian, but it could be me having a hard time isolating his points.
---
Coming Up! The FINAL keynote of Agile Testing Days 2014!
Helping Testers Add Value to Agile Projects with Alan Richardson (@eviltester) - Yeah - I'm looking forward to this one.
We're set and ready to go - Jose Diaz is at the front of the room making some announcements- including that there is more happening after Alan's talk.
He starts with the observation that there are trends in the keynotes this year. And that is a trend in message. I think to BREAK that trend he starts with the philosopher Warren Zevon and his master work "It ain't all that pretty."
How? By working on the reality that is in place - regardless of what people want to see - things get in the way of that.
Which brings us The Dread Pirate Roberts - Quoted by S Morgenstern - abridged by WIlliam Goldman to text and screen...
"Thank you for everything, Westley, good night now, I'll probably kill you in the morning."
Westley makes himself useful, he does stuff that adds value - and eventually Westley learns that the Dread Pirate Roberts is not the DPR - he's a fellow who learned the trade - and became the DPR when the previous DPR retired... and Westley becomes the DPR.
Fine.
Except testers look at things from a different angle - They disabuse people of the notuon that they are something they are not.
Testers mantra should be "I'm not here to make you look good." I'm here to help you see what is and do it better,
We survive by learning to adapt to the system OF development. (Pete - so Warren Zevon, Pricness Bride and now slides with images from Transformers (the comic books).)
In 1901 there was a news story about Annie Edson Taylor - the first woman to gove over Niagara Falls in a barrel - And the story that she would rather be shot from a cannon than go over a waterfall again.
Alan's comment - "I survived the waterfall, and won't do it again."
And now - William Blake is cited -
"I must create a system. Or be enslav'd by another Mans; I will not reason & compare: my business to create"
William Blake, Jerusalem
He was stuck on - Writing a test strategy - Poor stories and acceptance criteria - etc.ad nauseum...
And NOW we get Pink & the Brain! "Tomorrow, we take over the world!"
Except his normal behaviors from the past - where he can assert himself and take things on - excet it becomes very hard. So he ned to expand his reality.
He needs to learn Java - the Perl - AND then he needed to learn & improve his TDD skills.
He did not know the technology so he had to learn it - he needed to also expand his skills and embrace the ideas in new ways. He got to "what is "done"? What can be done to advance what testing was in Agile.
THEN - the next task was "get to done" with no stories that fixed the stuff that was done... wrong.
NO-ONE ELSE knew what testing was supposed to look like - so he made it up.
Scary - BUT! Life is good.
And Alan then reverted to form - He did what he always did -
Mat the "ptest process" and adance the goals.
When you look at AGILE in isolation - life kind of sucks (Pete: that's my paraphrase cuz Alan is FLYING past points - HOLY COW!!!!!!)
Instead - looking at Agile as a SYSTEM leads to broader understanding - this allowd us to look at things differently each and every time because we are on projects that are not like the last 5 or 6. We are wortking withy people who may not have worked with us before. THESE are the things that REALLY contribute to to moving things forward.
And he's citing Sun Tzu's Art of War as a referene - YES -
Loot, Pillage, Raid and Steal from other disciplines - by "borrowing it - we need to give it back. So WE TAKE IT - that makes it ours. (I think Alan has Viking blood in him...)
And here comes "Green Eggs and Ham" reference - but it is "Do not call me QA" (I got a pic of the
QA is not Testing - call it QA - he calls it Tester. Ask for a "QA Team Report" and there will be silence. (Pete note: AMEN!)
People new to Agile need help - let the experienced ones help the novices - but let people try things themselves! If you impose YOUR model of "Agile" on a group - YOU HAVE FAILED! You are no longer Agile - You are going to a dark evil place (well, Pete is paraphrasing cuz he's going right bloody fast.)
Foster of attitude - of helping testers; and of ownership - and of How to surviveloads of stuff. Its all good.
"Only variety can absorb variety." Stafford Beer restating - (Pete note: bugger - missed that original source - sorry.)
Teams absorb behavior & respond...
Testers need to help foster tester's survival.
--
Pete Note - ALAN! I need some slides I could not get good pics of - unless u don't want them in the blog...
===
And NOW - Janet & Lisa are giving a retrospective?
I think?
A skit - brandy & cigars? Maybe a Boston Legal meme? so maybe its Scotch?
And Super Agile Person makes a return - and Jose is the barman - with a nice apron - and a ... mustache?
So they are going over the conference - with a C/W song in the background? if I knew country better I could tell you - but I don't. Oh well.
Mobile testing - vendor demos - hallway conversations - and some unexpected things - like non-violent communication, non-judgemental observations (Bob Marshall's stuff) - and - improving relationships - and - failing fast, but does that really mean "learning fast"? hmmmmmmmm - then the Open Space stuff gets mentioned - loads of fun stuff apparently - including the Lego workshop...
Then there was ... one of the challenge on their wall (in their workshop) - how do we get "skilled testers" - And now there is a room sharing their experiences - I'm not able to keep up - sorry -
==
And Jose is wrapping things up - bringing out Uwe and Madeleine - and recogizing Alex - who reviews the proposals - and WOW! I got a thank you gift for the live blogging, etc - that I am to bring home to my lady-wife, Connie. Thanks! I am honored -
Loads of people make an event like this happen.
And he is now thanking Matt Heusser and Maik Nogens for their work on Software Testing World Cup. That was a bunch of work - and loads of effort
Next Year - Nov 9-12 - 2015 - In Potsdam!
And on Tutorial Day - a kid's track - something appropriate for children that works in line with the theme of Agile & testing - Way cool idea.
Coming UP!
Agile Testing Day - Netherlands - March 19 - 2015!
===
This ends the day 3 Live blog - thanks for playing along -
Finished with engines.
Wednesday, November 12, 2014
Almost LIVE! From Potsdam - Agile Testing Days 2014 Day 0
Monday, 10 November in Potsdam Germany saw a day of tutorials and the first ever Software Testing World Cup Finals!
Matt Heusser asked me to assist him with his Lean Software Testing tutorial - which he was offering as a 1/2 day format for the first time (drinking from a fire hose ain't in it.) So, we had a small group - which probably made it possible to get through the material we had lined up - more than a handful an it would have been impossible.
So, we ran a series of exercises and retrospectives. We threw people in with little guidance - and they came away impressing me - I suspect Matt was equally impressed (you'd need to ask him!) After 3 1/2 extremely intense hours, lunch break came.
I ended up grabbing an ironing board, ironing ALL my shirts, slacks, etc, (as I could not on Sunday, the day I arrived) then got downstairs to "moderate" the Software Testing World Cup (STWC) finals contest by the designated 2:00 PM time. The contest started later than that, but an hour of prep, level checks and the like made it go very, very quickly.
I had the chance, with my "broadcasting partner" Kira, to meet all the teams and chat with them briefly. My intention was to wish them luck and generally be supportive - and give us an idea of the make up of the teams before we began the contest.
In short, we did a live stream of the contest with Kira and I doing commentary. (One friend said it was a bit like listening to someone calling a football match with no actual football being played on the screen!) It was a lot of work - and a lot of fun. We had an excellent time.
Frankly, Kira asked some really good questions - they were pretty basic and showed she was not in software at all - but it gave me the chance to talk about what we could see the testers actually doing in the room - Mind maps, collaboration plans, time blocking - pretty basic stuff for testers used to Session Based Test Management (SBTM) or Exploratory Testing in general. But, it gave me the chance to talk to some common misconceptions about software and testing.
I'm not quite sure how to sum up the afternoon and evening. When the dust settled - I tried to talk with each team for a few minutes - with the cameras off. They all did extremely well in a fairly stressful situation and showed they were capable of far more than the 3 hours allotted for testing the software under test and reporting the results of those tests.
I was impressed by the teams' behavior - and extremely impressed by how the teams all mingled after the contest ended. Loads of talking and laughing and having a drink together - Friendly competition at its best.
The winners of the African contest, OpenBox from South Africa, brought around bracelets for each of their competitors - one for each team member. Others shared props and toys and all shared a laugh.
I've been told the livestream was recorded, I really hope it was. I've gotten several tweets to the effect of "That was a brilliant answer!" Except I have no idea what most of the questions were and not certain what I said - for the most part.
So, we ran a series of exercises and retrospectives. We threw people in with little guidance - and they came away impressing me - I suspect Matt was equally impressed (you'd need to ask him!) After 3 1/2 extremely intense hours, lunch break came.I ended up grabbing an ironing board, ironing ALL my shirts, slacks, etc, (as I could not on Sunday, the day I arrived) then got downstairs to "moderate" the Software Testing World Cup (STWC) finals contest by the designated 2:00 PM time. The contest started later than that, but an hour of prep, level checks and the like made it go very, very quickly.
I had the chance, with my "broadcasting partner" Kira, to meet all the teams and chat with them briefly. My intention was to wish them luck and generally be supportive - and give us an idea of the make up of the teams before we began the contest.
In short, we did a live stream of the contest with Kira and I doing commentary. (One friend said it was a bit like listening to someone calling a football match with no actual football being played on the screen!) It was a lot of work - and a lot of fun. We had an excellent time.
Frankly, Kira asked some really good questions - they were pretty basic and showed she was not in software at all - but it gave me the chance to talk about what we could see the testers actually doing in the room - Mind maps, collaboration plans, time blocking - pretty basic stuff for testers used to Session Based Test Management (SBTM) or Exploratory Testing in general. But, it gave me the chance to talk to some common misconceptions about software and testing.
I'm not quite sure how to sum up the afternoon and evening. When the dust settled - I tried to talk with each team for a few minutes - with the cameras off. They all did extremely well in a fairly stressful situation and showed they were capable of far more than the 3 hours allotted for testing the software under test and reporting the results of those tests.
I was impressed by the teams' behavior - and extremely impressed by how the teams all mingled after the contest ended. Loads of talking and laughing and having a drink together - Friendly competition at its best.
The winners of the African contest, OpenBox from South Africa, brought around bracelets for each of their competitors - one for each team member. Others shared props and toys and all shared a laugh.
I've been told the livestream was recorded, I really hope it was. I've gotten several tweets to the effect of "That was a brilliant answer!" Except I have no idea what most of the questions were and not certain what I said - for the most part.
LIVE! from Potsdam! Agile Testing Days - Day 2!
Wednesday, November 12 dawned very nicely in Potsdam. A soft, gentle morning. Not too cool, very gentle weather. Not that many participants were up and going at the same time I was - it was an excellent reception last night and may people continued the festivities into the wee hours.
The theme of the party was "Carnival" recognizing the German Carnival celebrations that start regionally in early November. Costumes and dancing - to tie in with Carnival in Brazil, there were Brazilian dancers, drummers entertaining the group - the party grew louder with the announcement of the winners of the Software Testing World Cup finals contest (held Monday evening.)
The third place winners were the team from Romania - the Army Ants, European winners. The second place team was The Annunciation from New Zeeland, the Oceana winners. The winning, first place team was Cesar Brazil, from Brazil - the South American winners.
I spent time yesterday afternoon talking with Lisa Crispin, Janet Gregory and (ahem) Joe Justice - from Scrum Inc (yeah, Jeff Sutherland's company)
===
Joe Justice is presenting his keynote on How Test First Saved the World. He works fro Scrum Inc.,and runs his own 501-C-3 - WikiSpeed. Wikispeed is a cool company focused on making ultra-high efficiency, ultra-low emission, road legal, practical purposes.
Joe put together an entry for the X-Car prize - and the results were astounding. They landed at the Detroit Auto Show, and then were contacted by other manufacturers. They are now capable of producing cars - and have 1 in Germany (arrived last night) to be assembled at the conference.
This started by Joe setting up some stories - targets such as "build a car that is low emissions", "build a car that is ultra-efficient" and "build a car that is road legal." He modeled components, such as the body designed in foam, then built the car that went on display at the Detroit Auto Show - and a fan saw the picture - mocked up some variations - and THAT is what is now available.
Wikispeed calls these techniques "XM" - Extreme Manufacturing. They employ the core principles of Extreme Programming - Joe was a Java developer and Scrum coach before he turned into a car designer.
Using these techniques, SAAB is building combat aircraft at a fraction of the cost of the comparable combat aircraft in the US - the F35. Which, by the way, still is not in production because of "software errors."
These techniques are now in use at Lockheed Martin to fix the problems with the F35, and also at Boeing - and now at John Deere.
Tomes Law: Team Velocity+Portfolio Velocity = Transition Velocity - named for an embedded Scrum coach with John Deere.
What has been found in these organizations is that teams of 4-5 people make highly efficient teams. Other companies, such as Raytheon and Tom Tom (the GPS folks) have applied these techniques and significantly reduced their backlog.
Joe was brought in to advise Unesco on stabilizing EU troubled economies. Explaining how Scrum worked, short iterations, short delivery and quick review - and now are looking at the way to revamp their company recovery plan - which used to require a 5 year plan with penalties for deviation from the plan - to an iterative approach for recovery. Except now this needs to be tested.
The testers need to be able to support people by asking the right questions at the right time.
That is what we are supposed to do anyway, right?
Now - There are companies and organizations and countries that are working poorly that can work better. Using Agile techniques in general and Scrum in particular can help people do better work and get those companies, organizations and countries out of trouble.
(Umm - Joe is going really fast - I hope that the someone else is catching stuff I'm missing)
Using Test First techniques wikispeed began building their cars using these approaches. By using these techniques they can speed cycles and determine results of efforts faster.
Agile/Scrum - Reduces the cost to make change
Lean - Use less stuff
TDD - Build just enough stuff to save the world
---
That was the end of the keynote - perhaps a pretty good evaluation came from Huib Schoots - "That was an awesome keynote."
===
And in the Q/A session - Joe mentions how Beer helps testing - Yeah - Kind of what I said Monday at the STWC finals, and in Estonia. Because - BEER HELPS TESTING.
===
Now for track talks...
--
I'm sitting in Richard Bradshaw's session entitled Developers Testing? Yes, and Enjoying It!
I have known Richard cyberly for some time and engaged in some wonderful conversations, virtually and in person, the last several years. I have never seen him present (that I can recall) and am looking forward to this. He's in the "Test Strategies and Exploratory Testing" track today, so I suspet that is a clue to his general message.
And here we go...
Richard (NOT JOE!!!!!!!!) is giving some information on actual events, an experience report if you will - of what he did at a client shop. Often times companies view testers as the guy on the other side of the wall "firing bugs" (reporting bugs) to developers. This is, sadly, not uncommon. THis was even a "cool" company all into Kanban, Pairing, TDD, DevOps, 2x weekly releases, on and on and on...
Interviews consist of "Right, here's a room with a computer and some software - test it, we'll be back in an hour." You go home, then if they like the results of your work, they call you in for the discussion part. The do something similar with developers - tossing them in and pairing with a dev for an hour or so, working on code.
So - What were they looking for? The title was "Test Evangelist - a Test Specialist." They were looking for someone who ould talk about testing and work on stuff and help people do better work.
Of course, a big part of that was to get developers to do testing. So, Richard sat down and was asking questions like "so, how did you test this? how did you structure your tests?" The answer consisted of "Well, we tried it a bit, poked around a bit - and seemed fine. So, we shipped it."
Except, there was loads of testing going on - the people doing the testing simply did not have the vocabulary to explain what they did. For example, they did loads of stuff - much in automated work in Selenium - and Richard came in and looked at the automation - and refactored it (as he was comfortable with webdriver.)
Except that soon, all the testing was being dropped on Richard - who really could not do all the testing. There was simply too much. On top of that, this wasn't really what he was supposed to be doing. So, going to the boss, he asked and the response was interesting. "Yeah, I kind of expected that to happen. I would be surprised if you could get them doing all the testing. This is part of getting them to test."
Richard introduced the idea of Session Mased Testing - Session Based Test management (SBTM) developed by James Bach, et al. Focused, time box test events to exercise pieces of the functionality.
The key to making this work is cutting down the charters to small pieces - and then cutting down the stories to much smaller pieces. This allows you to work in specific bits - and test specific bits. Recording and capturing information is important - Richard's client used JIRA. There are some handy add-ons that can help with that.
The realization that these things can directly impact the "quality" of the product - that they can do things that make quality better - both testing and non-testing activity - makes the idea of QA = Testing a different discussion - one that Richard (Pete Note: and I) are much more willing to have.
Internal Talking Opportunities - Informal chats at the office - "Beer and Cheese Nights" Kind of like wine and cheese - except that no one there really liked wine.
And after posting a bit on TDD, there was a rush of discussion. So, he put a copy of "Explore It!" out in the company kitchen - sometimes open to specific pages - and the developers actually read it! A book on Testing!
Then there was "Lessons Learned in Software Testing" - a 'fairly old' book (Richard's comment) but with loads of good information - stuff that is really valuable.
The then put out James Bach and Michael Bolton's Checking vs Testing - where checking began to morph into "change detection" - something happened and maybe it was something they did not expect. With the "C vs T" thing - the developers found they were really, really good at automating the "checking" - because they had TDD, they had loads of examples to choose from for the Selenium script.
The result was that the devs became very very good at spotting differences and identifying their own software problems.
So, the shift began in the "Pre-Planning Meetings" - half day things talking about what was going on. Except while people looked at the needs, the looked at the complexity - and sometimes code they'd need to work with or On. And Richard began asking things like "What is this? How are we going to test it?"
Questions can be asked and answered - and sometimes the answer is that things need to be worked on a bit more - sometimes it is that things are pretty straight forward. As the time to do something goes up, possibly a simple tool (helper) can be of value. In one case, the weird problem to exercise the function needed a log reviewed. Manually reviewing logs takes a lot of time. So, the devs wrote a quick tool to review the logs - voila! Loads of time saved.
Then - this lead to development of code reviews and tests around them - including people developing tests because they saw there wasn't one created for the specific function.
So, the result was that bugs were dealt with quickly - and the dev pairs were self-motivated to find bugs and improve eah other's work.
Consideration of the need for testers on a team -
Alan Page's Generalist Specialist - "Jack of all trades, master of none"
If all the dev's are testing, who is developing? (and the other way around."
In the end - people were diving in and doing good testing work The issues found were pretty central and the teams embraced the approaches Richard introduced.
---
Right - Nice summary and set up for my session!
==
whew - Here's my room 5 minutes before I started... SHEESH!
By the time I actually got going, there were no empty chairs and the aisle was full of people sitting and the space to my left at the front of the room (out of the frame) had 8 or 10 people sitting on the floor. Wow! What a response!
I am absolutely humbled by the turnout.
So, apparently I struck a chord with people based on the twitter stream. I always find it interesting what people latch onto and grab as a takeaway. Thanks to everyone who came - I admit I was a little taken aback by the response. I am honored by your kind reception.
--
Lunch time (when I got over to the food) had an absolutely brilliant conversation with three very bright testers all from Redgate. Chris George (@chrisg0911), Emma Armstrong (@EmmaATester) and Gareth Bragg (@GBCamb) were all deep in a lovely conversation on testing and motivation and honest collaboration and... the topics were wide ranging. We were so deep into it that we missed the first 10 minutes of the keynote - and then decided to keep going.
Sorry - I don't have notes from the presentation by Alexander Schwartz and Fanny Pittack on Insights from Happy Change Agents. I was kind of looking forward to this as I had met Fanny at last year's Agile Testing Days - very bright tester as I recall. I hope someone has notes I can check out please?
--
In the meantime, I check on the interview with Matt Heusser and Maik Nogens on the Software Testing World Cup contest, and a couple of questions around Matt winning the MIATPP award. In the process of THAT - I stopped to check out the car being built in sprints, in the lobby of the hotel.
Check it out...
And with the interview over, and a quick change of clothes (it is really warm in here - putting on something a bit lighter) I'm catching up the live blog and heading back to where the action is!
See you in a few minutes!
---
And the car is starting to look like a car!
And David Evans is now up for the "Pillars of Testing." Looking good!
He starts with some really bad puns around Columns, Pillars, Greek Capitals and Roman Capitals. (Pictures to follow when I get caught up...)
The issue is, how do we get to greater confidence? What are the dependencies? How do we make things work?
Confidence is supported by Safety and courage - which are in turn supported by Stronger Evidence, Better Design, Greater Coverage and Faster Feedback - THESE ARE THE PILLARS! (Well, actually they are columns, but you get the idea. Right?)
THOSE in turn are supported by Collaboration and Communication, Test Techniques, Effective Automation, Business Engagement and - stuff that went to fast for me to get... GAH!
Last year's keynote stated "The Product of Testing is Confidence." In that, Confidence depends on the bits mentioned above.
These are the Pillars - Each pillar represents a measurable, valuable quality of Testing. Each quality exists to some extent but can always be improved. Aim to understand and improve each and balance it with others.
The Pillars/Columns rest on fancy terms of architecture that I did not get. But, the intent is that they serve as the team foundations.
Among these are the Collaboration & communication - which rests on Business Engagement and Team Structures? How easy is it to get information for the REAL experts - the people who know the system intimately. These things are what the "Stronger Evidence" pillar/column rests on
Then we get the Test Techniques - which rests on Skills and Experience. These two things are that which Better Design and Greater Coverage rest on.
Which brings us to "Effective Automation" - which relies on Application Testability and Configuration Management. These support "Faster Feedback."
These ALL rest on Management and Leadership as well as Engineering Discipline. The taller the pillar/column, the greater the need for a stronger base.How can we really build things higher without laying a solid foundation?
Many companies try to do just that. A strong foundation is crucial. The foundation needed is solid Organizational Culture and Values.
How can we use this? Well, how about a Discovery Model? We can look for things we simply don't know.
Another is as an Assessment Tool. Self Assessment is critical to growth and understanding - it is hard work and calls for a willingness for deep self-awareness. "We might be bad at this, but is it important?"
Then the third option is Challenge tool. Rejecting something out of hand is not the point. The real point is to get you to think about what is indeed needed.
David's New book is out though - and I DOWNLOADED A COPY!!!!!! WHOO HOO! Thanks man!
===
Official activities are done - but there are things going on. The car build is still in progress, there is a reception this evening followed by games and the like.
Should be a good evening.
More later. Maybe.
===
Its later - like - WAAYYYyy later.
Car Delivery status: Done.
===
The theme of the party was "Carnival" recognizing the German Carnival celebrations that start regionally in early November. Costumes and dancing - to tie in with Carnival in Brazil, there were Brazilian dancers, drummers entertaining the group - the party grew louder with the announcement of the winners of the Software Testing World Cup finals contest (held Monday evening.)
The third place winners were the team from Romania - the Army Ants, European winners. The second place team was The Annunciation from New Zeeland, the Oceana winners. The winning, first place team was Cesar Brazil, from Brazil - the South American winners.
I spent time yesterday afternoon talking with Lisa Crispin, Janet Gregory and (ahem) Joe Justice - from Scrum Inc (yeah, Jeff Sutherland's company)
===
Joe Justice is presenting his keynote on How Test First Saved the World. He works fro Scrum Inc.,and runs his own 501-C-3 - WikiSpeed. Wikispeed is a cool company focused on making ultra-high efficiency, ultra-low emission, road legal, practical purposes.
Joe put together an entry for the X-Car prize - and the results were astounding. They landed at the Detroit Auto Show, and then were contacted by other manufacturers. They are now capable of producing cars - and have 1 in Germany (arrived last night) to be assembled at the conference.
This started by Joe setting up some stories - targets such as "build a car that is low emissions", "build a car that is ultra-efficient" and "build a car that is road legal." He modeled components, such as the body designed in foam, then built the car that went on display at the Detroit Auto Show - and a fan saw the picture - mocked up some variations - and THAT is what is now available.
Wikispeed calls these techniques "XM" - Extreme Manufacturing. They employ the core principles of Extreme Programming - Joe was a Java developer and Scrum coach before he turned into a car designer.
Using these techniques, SAAB is building combat aircraft at a fraction of the cost of the comparable combat aircraft in the US - the F35. Which, by the way, still is not in production because of "software errors."
These techniques are now in use at Lockheed Martin to fix the problems with the F35, and also at Boeing - and now at John Deere.
Tomes Law: Team Velocity+Portfolio Velocity = Transition Velocity - named for an embedded Scrum coach with John Deere.
What has been found in these organizations is that teams of 4-5 people make highly efficient teams. Other companies, such as Raytheon and Tom Tom (the GPS folks) have applied these techniques and significantly reduced their backlog.
Joe was brought in to advise Unesco on stabilizing EU troubled economies. Explaining how Scrum worked, short iterations, short delivery and quick review - and now are looking at the way to revamp their company recovery plan - which used to require a 5 year plan with penalties for deviation from the plan - to an iterative approach for recovery. Except now this needs to be tested.
The testers need to be able to support people by asking the right questions at the right time.
That is what we are supposed to do anyway, right?
Now - There are companies and organizations and countries that are working poorly that can work better. Using Agile techniques in general and Scrum in particular can help people do better work and get those companies, organizations and countries out of trouble.
(Umm - Joe is going really fast - I hope that the someone else is catching stuff I'm missing)
Using Test First techniques wikispeed began building their cars using these approaches. By using these techniques they can speed cycles and determine results of efforts faster.
Agile/Scrum - Reduces the cost to make change
Lean - Use less stuff
TDD - Build just enough stuff to save the world
---
That was the end of the keynote - perhaps a pretty good evaluation came from Huib Schoots - "That was an awesome keynote."
===
And in the Q/A session - Joe mentions how Beer helps testing - Yeah - Kind of what I said Monday at the STWC finals, and in Estonia. Because - BEER HELPS TESTING.
===
Now for track talks...
--
I'm sitting in Richard Bradshaw's session entitled Developers Testing? Yes, and Enjoying It!
I have known Richard cyberly for some time and engaged in some wonderful conversations, virtually and in person, the last several years. I have never seen him present (that I can recall) and am looking forward to this. He's in the "Test Strategies and Exploratory Testing" track today, so I suspet that is a clue to his general message.
And here we go...
Richard (NOT JOE!!!!!!!!) is giving some information on actual events, an experience report if you will - of what he did at a client shop. Often times companies view testers as the guy on the other side of the wall "firing bugs" (reporting bugs) to developers. This is, sadly, not uncommon. THis was even a "cool" company all into Kanban, Pairing, TDD, DevOps, 2x weekly releases, on and on and on...
Interviews consist of "Right, here's a room with a computer and some software - test it, we'll be back in an hour." You go home, then if they like the results of your work, they call you in for the discussion part. The do something similar with developers - tossing them in and pairing with a dev for an hour or so, working on code.
So - What were they looking for? The title was "Test Evangelist - a Test Specialist." They were looking for someone who ould talk about testing and work on stuff and help people do better work.
Of course, a big part of that was to get developers to do testing. So, Richard sat down and was asking questions like "so, how did you test this? how did you structure your tests?" The answer consisted of "Well, we tried it a bit, poked around a bit - and seemed fine. So, we shipped it."
Except, there was loads of testing going on - the people doing the testing simply did not have the vocabulary to explain what they did. For example, they did loads of stuff - much in automated work in Selenium - and Richard came in and looked at the automation - and refactored it (as he was comfortable with webdriver.)
Except that soon, all the testing was being dropped on Richard - who really could not do all the testing. There was simply too much. On top of that, this wasn't really what he was supposed to be doing. So, going to the boss, he asked and the response was interesting. "Yeah, I kind of expected that to happen. I would be surprised if you could get them doing all the testing. This is part of getting them to test."
Richard introduced the idea of Session Mased Testing - Session Based Test management (SBTM) developed by James Bach, et al. Focused, time box test events to exercise pieces of the functionality.
The key to making this work is cutting down the charters to small pieces - and then cutting down the stories to much smaller pieces. This allows you to work in specific bits - and test specific bits. Recording and capturing information is important - Richard's client used JIRA. There are some handy add-ons that can help with that.
The realization that these things can directly impact the "quality" of the product - that they can do things that make quality better - both testing and non-testing activity - makes the idea of QA = Testing a different discussion - one that Richard (Pete Note: and I) are much more willing to have.
Internal Talking Opportunities - Informal chats at the office - "Beer and Cheese Nights" Kind of like wine and cheese - except that no one there really liked wine.
And after posting a bit on TDD, there was a rush of discussion. So, he put a copy of "Explore It!" out in the company kitchen - sometimes open to specific pages - and the developers actually read it! A book on Testing!
Then there was "Lessons Learned in Software Testing" - a 'fairly old' book (Richard's comment) but with loads of good information - stuff that is really valuable.
The then put out James Bach and Michael Bolton's Checking vs Testing - where checking began to morph into "change detection" - something happened and maybe it was something they did not expect. With the "C vs T" thing - the developers found they were really, really good at automating the "checking" - because they had TDD, they had loads of examples to choose from for the Selenium script.
The result was that the devs became very very good at spotting differences and identifying their own software problems.
So, the shift began in the "Pre-Planning Meetings" - half day things talking about what was going on. Except while people looked at the needs, the looked at the complexity - and sometimes code they'd need to work with or On. And Richard began asking things like "What is this? How are we going to test it?"Questions can be asked and answered - and sometimes the answer is that things need to be worked on a bit more - sometimes it is that things are pretty straight forward. As the time to do something goes up, possibly a simple tool (helper) can be of value. In one case, the weird problem to exercise the function needed a log reviewed. Manually reviewing logs takes a lot of time. So, the devs wrote a quick tool to review the logs - voila! Loads of time saved.
Then - this lead to development of code reviews and tests around them - including people developing tests because they saw there wasn't one created for the specific function.So, the result was that bugs were dealt with quickly - and the dev pairs were self-motivated to find bugs and improve eah other's work.
Consideration of the need for testers on a team -
Alan Page's Generalist Specialist - "Jack of all trades, master of none"
If all the dev's are testing, who is developing? (and the other way around."
In the end - people were diving in and doing good testing work The issues found were pretty central and the teams embraced the approaches Richard introduced.
---
Right - Nice summary and set up for my session!
==
whew - Here's my room 5 minutes before I started... SHEESH!
I am absolutely humbled by the turnout.
So, apparently I struck a chord with people based on the twitter stream. I always find it interesting what people latch onto and grab as a takeaway. Thanks to everyone who came - I admit I was a little taken aback by the response. I am honored by your kind reception.
--
Lunch time (when I got over to the food) had an absolutely brilliant conversation with three very bright testers all from Redgate. Chris George (@chrisg0911), Emma Armstrong (@EmmaATester) and Gareth Bragg (@GBCamb) were all deep in a lovely conversation on testing and motivation and honest collaboration and... the topics were wide ranging. We were so deep into it that we missed the first 10 minutes of the keynote - and then decided to keep going.
Sorry - I don't have notes from the presentation by Alexander Schwartz and Fanny Pittack on Insights from Happy Change Agents. I was kind of looking forward to this as I had met Fanny at last year's Agile Testing Days - very bright tester as I recall. I hope someone has notes I can check out please?
--
In the meantime, I check on the interview with Matt Heusser and Maik Nogens on the Software Testing World Cup contest, and a couple of questions around Matt winning the MIATPP award. In the process of THAT - I stopped to check out the car being built in sprints, in the lobby of the hotel.
Check it out...
 |
| Assorted bits & pieces... |
 |
| Planning Board/Scrum Team List |
 | |
| Uwe rushing to deal with a "situation" |
 | |
| Chassis, wheels and more stuff |
And with the interview over, and a quick change of clothes (it is really warm in here - putting on something a bit lighter) I'm catching up the live blog and heading back to where the action is!
See you in a few minutes!
---
And the car is starting to look like a car!
And David Evans is now up for the "Pillars of Testing." Looking good!
He starts with some really bad puns around Columns, Pillars, Greek Capitals and Roman Capitals. (Pictures to follow when I get caught up...)
The issue is, how do we get to greater confidence? What are the dependencies? How do we make things work?
Confidence is supported by Safety and courage - which are in turn supported by Stronger Evidence, Better Design, Greater Coverage and Faster Feedback - THESE ARE THE PILLARS! (Well, actually they are columns, but you get the idea. Right?)
THOSE in turn are supported by Collaboration and Communication, Test Techniques, Effective Automation, Business Engagement and - stuff that went to fast for me to get... GAH!
Last year's keynote stated "The Product of Testing is Confidence." In that, Confidence depends on the bits mentioned above.
These are the Pillars - Each pillar represents a measurable, valuable quality of Testing. Each quality exists to some extent but can always be improved. Aim to understand and improve each and balance it with others.
The Pillars/Columns rest on fancy terms of architecture that I did not get. But, the intent is that they serve as the team foundations.
Among these are the Collaboration & communication - which rests on Business Engagement and Team Structures? How easy is it to get information for the REAL experts - the people who know the system intimately. These things are what the "Stronger Evidence" pillar/column rests on
Then we get the Test Techniques - which rests on Skills and Experience. These two things are that which Better Design and Greater Coverage rest on.
Which brings us to "Effective Automation" - which relies on Application Testability and Configuration Management. These support "Faster Feedback."
These ALL rest on Management and Leadership as well as Engineering Discipline. The taller the pillar/column, the greater the need for a stronger base.How can we really build things higher without laying a solid foundation?
Many companies try to do just that. A strong foundation is crucial. The foundation needed is solid Organizational Culture and Values.
How can we use this? Well, how about a Discovery Model? We can look for things we simply don't know.
Another is as an Assessment Tool. Self Assessment is critical to growth and understanding - it is hard work and calls for a willingness for deep self-awareness. "We might be bad at this, but is it important?"
Then the third option is Challenge tool. Rejecting something out of hand is not the point. The real point is to get you to think about what is indeed needed.
David's New book is out though - and I DOWNLOADED A COPY!!!!!! WHOO HOO! Thanks man!
===
Official activities are done - but there are things going on. The car build is still in progress, there is a reception this evening followed by games and the like.
Should be a good evening.
More later. Maybe.
===
Its later - like - WAAYYYyy later.
Car Delivery status: Done.
===
Subscribe to:
Posts (Atom)
