I live and work in Grand Rapids, Michigan. Grand Rapids, for those not familiar with the city, was the home of Gerald R Ford and his wife Betty - Yeah, the same Ford who was President of the United States. They renamed the airport for him - Gerald R Ford International Airport (yeah, the same one of Parkcalc fame).
My colleague Matt Heusser refers to Grand Rapids as the "silicon alley" of software testing.
There are some really outstanding boutique development organizations doing top-flite, world class work. The first one that pops to mind is Atomic Object. These guys rock.
There are also a whole crop of small start-ups in niche markets doing good work and making their world better.
Then there are the really small "shops" - the one and two person outfits doing work on their own or in conjunction with others, or with other development teams that need a little help. Then there is where they are doing stuff.
Those of us who have spent most of our working careers for companies, large or small, that had a central office where we worked - the sense of community, the water cooler, coffee station, cafeteria , break room, where ever, was part and parcel to what we did. We'd chat and chill and hang out and bounce ideas off each other. But when you don't have an office to go to - well, what do you do?
If you're in (or around) Grand Rapids, you can hang out at a coffee shop, or your home (house, apartment, whatever) OR - you can find a co-working community. A what? A Co- working location! A place to go, work, develop, think, drink coffee, bounce ideas off other folks, hang and learn.
Like, The Factory. These folks.
What is special about them? Well, they do stuff that seems pretty cool to me. Like, provide work spaces and meeting space and classes and training and coffee and an amazing space to hang out during the day or into the evening.
They are regular hosts of several meetups, including GRTesters - the meetup I'm involved with. Its pretty cool. If you need a place to meet, and they have space available - and you ask them nicely - things can generally be worked out - at least from my experience.
We've had folks join the discussion, presentation, whatever, simply because they were curious about what we were talking about. Well, and we had pizza and wings. That may have helped.
The thing is, most of the time people are pretty good about things like, learning and sharing ideas. Most of us like it when people express an interest in what we're interested in. I expect a fair number of people would be happy if we asked them about what they are interested in. Places like The Factory kind of make that easier.
Classes on iOS development, JAVA development, database design, general design - stuff that helps people learn and grow. People who want to be involved in something new to them is what helps to spread knowledge and ideas. It is how we invigorate and reinvigorate our practices and our selves.
This is what helps build community and communities of practice.
And this is what people at The Factory are good at encouraging.
I don't know if you have something like this where you are. If you do, that is great. Get to meet them. You never know who you might meet. They might be pretty good folks to meet. They might be folks who can help you learn and develop and grow.
They might be like the folks at The Factory.
Sunday, June 22, 2014
Wednesday, June 18, 2014
On Technical Leadership and Relationships, for Irina
At Nordic Testing Days, this past June, I presented a
session on Test Leadership. It was a
fairly light-hearted approach to a complex subject. Specifically, I was talking about what is
sometimes called “non-positional leadership” or, as I prefer to think of it,
“technical leadership,” a term I first encountered in Jerry Weinberg’s
“Becoming a Technical Leader.”
It was a good session, I thought. It was the last track slot of the conference,
just before the closing keynote. Because
it was the end of three days of fairly intense work, I agreed with the
conference organizers that a lighter approach might be in order. So, I revived and modified the “Test
Leadership Lessons from Harry Potter.”
It seemed a good idea – and passing out chocolates (mini candy bars to
be precise) seemed a fun thing to do while people were filtering in.
Somehow I managed to trim a 90 minute presentation into
around 35 minutes (well, I did go over – so around 37 minutes) and still had
time for questions – around 10 minutes or so.
One question was, I thought fantastic “How do you know if you are ready to be this kind of leader?”
That was an excellent question. (It also won the prize – they really do have
prizes at NTD – for “best question” of at least some session.) My answer was “Do you have people come up to
you and ask for your advice or suggestions on how to do something or how to
approach a problem?” She nodded, with an
expression on her face that said she was not quite clear where I was going with
my response. I continued, “If people are
coming to you for these things, congratulations! You are becoming a leader!”
What does that mean?
The idea of people coming to you for help is part and parcel
of what I see “leadership” to be. It is
not an appointed thing. It is not a mandated
thing. It is a mix of mentor, trusted adviser and supporter.
The hard part is
often letting people know help is available, without imposing the help. When people come to you, on their own, that
is recognition that you have developed some level of expertise on the topic at
hand and they need guidance.
People who aspire to be leaders might consider that maybe
becoming a leader is not really a viable goal in itself, at least through the
paths I espouse. Instead, the type of
leader I want to foster and encourage is the type who masters their craft. They are the type who studies diligently what
they are about and why they are doing it.
They will seek out experts and learn from them. In turn, they will often share what they have
learned with others.
A few days after returning home, I had an email from a
participant in the session. She wrote:
The main
question that popups is responsibility: does such kind of leader, who you were
talking about, have responsibilities?
On the one
hand, as long as he is a leader he affects other people, who's decisions may
depend on leader's actions or opinion. So as long as he has power to affect -
he should have responsibilities. You become responsible, forever, for what
you have tamed. (Antoine de
Saint-Exupéry )
On the
other hand - he doesn't want to be a leader, he is just doing what he like to
do. It's other people who put him on a leading position, so he shouldn't be
responsible for other people's decision to follow him. Work on yourself first, take
responsibility for your own progress. (I Ching)
So the
question is: if leader knows that he is a leader, should he evaluate his
actions and decisions according to how they might affect on people around him?
I promised that I would consider a response and would send
one as soon as I could.
This is my response.
As I read the email, it seems there are three distinct
points.
First, there is the question of “responsibility” in
general. Does it exist for someone not
in a traditional leadership/management role?
To me, being a team lead or having the word “Lead” in your
title is stepping into the realm of management.
I suspect this is because most organizations where I have worked, once
one became a “lead” of anything the next step on the career ladder was
“supervisor” or “manager,” more on that in a moment.
Then there is the statement of generally opposing views on
the existence of any such relationship.
First of these is the statement from de Saint-Exupéry (You know, the guy who wrote The Little Prince? Yeah, him... highlighted above) that states “You become
responsible, forever, for what you have tamed.” This is similar to the concept that if you
save someone’s life, you are responsible for that person’s life going forward.
The second
viewpoint is that presented in the I Ching (The Classic of Changes or
Book of Changes, often attributed to Fu Xi, a legendary ruler of China, but it
seems likely to be from much later, roughly 400-200 BCE. Either way, it is old
by any measure I know of.) The point
made there, also highlighted above, is that one should “Work on yourself
first, take responsibility for your own progress.”
The third
portion of the message is the crucial one, the “call of the question.”
Let us examine the question.
First, let
me be clear that this form of “leadership” is not the form that most people
look at as such. This is partly because
most people look at “leadership” as another term for “management.” This is not about managers or team leads or
senior people overseeing the development and work of more junior people.
Instead, this
is about learning what it is that we, as professional testers and students of
our craft, are about. Instead of leading
others by compulsion or any other external means, we share our journey of
learning with others and allow them to decide.
In truth, we
do not lead anyone. We enable them to
begin on their own journey of learning.
They may
follow the same path we do for a while, or not.
By sharing or offering to share our learning with others , encouraging
ourselves and others to share what has been learned thus far and what we want
to learn in the future, we are opening the door a little wider than it was open
when we arrived.
By helping
others see what is possible and encouraging them to discover their own passion,
we are leading them – in the sense of empowering them. When we listen to what others have done, and
learn from it to try ourselves, we are allowing them to lead us.
And there is
where it gets interesting.
By allowing
others to grow and explore their areas if interest, their chosen areas of
professional development, we are demonstrating leadership in its most
fundamental form: We encourage people
and give them the opportunity to grow, then get out of the way until we
are asked to assist or contribute.
In doing so, when they come asking questions
or looking for assistance, it is up to us to determine what form that
assistance takes. We can help walk them
through their problem. We can evaluate
their solution, as presented to us. We
can pair with them as they do their work.
We can make
them the gift of our time to help them become better at their chosen craft.
This does
not mean we do their work for them. Nor
does it mean we take responsibility for them not accomplishing their tasks in a
timely manner.
We can say “No.”
This also
does not prevent us from saying “No.”
That may be extended into “No, not right now; can we get together later
today?” Or, it may be “We have done
similar things several times; why don’t you try it on your own then, if I can,
I can review it with you?”
This is the
final point I want to make on the relationship between “technical leaders” and
those they are assisting: it must be a relationship that is mutually agreed to.
If would-be
leaders find themselves in a position where they are doing other people’s work
for them, they are not helping that other person. Such a relationship exists only when people
have the right to opt-out either temporarily or permanently. From what I have seen, the relationship must
benefit both parties to be successful.
The best way
I know of to solidify what has been learned is to try and teach or explain it
to someone else. While they are learning
a new concept, we, the people explaining the concept, are testing our own
understanding of it as we explain it.
The fundamental basis here is that our learning is solidified as we
teach others.
The answer.
In the end, I generally fall in with the concept of the I
Ching – we must teach ourselves first.
In doing so, we can open up our learning to others. As we grow, we can make this available so
others may grow. Whether they chose to
act is not up to us.
Having said that, I believe there is a bit of responsibility
to others once you step beyond the question of personal professional
development. I believe that we have a
responsibility to aid others we help, although not “forever” as Saint-Exupéry would have us do. Partly this is because we are freeing them,
not “taming” them. We help them discover
their own passion to grow and develop.
This is why
I take the time to formulate an answer to a question sent by email after a
conference.
Wednesday, June 11, 2014
From Tallinn!! Nordic Testing Days - Retrospective
I had the immense pleasure of participating in Nordic Testing Days in Tallinn, Estonia.
Estonia is a country of 1.3 Million people in Eastern Europe - way Eastern Europe. The neighbors to the East are Russia - North, beyond the Bay of Finland is... Finland. There are ferries that run between Tallinn, the capitol city of Estonia, and Helsinki, Finland. Its a cool city with loads of medieval buildings, castles/city walls and churches.
The city's "Old Town', the medieval heart of the city is a wandering maze of narrow, cobble stone streets. The town square boasts the oldest apothecary in the world - established in 1422 and continuing to operate today. Oh, they also have wifi - free wifi. Wifi EVERYwhere.
Tallinn is far enough North where for those of us from the US - it is pretty amazing. By 11:00 PM the first week of June, it is still light enough where it would be somewhere between dusk, the gloaming and full night fall. At 11:30 one evening, whilst sitting with colleagues at a patio bar in the conference center, we were amazed when we realized how late it was - and how none of us had any idea of the time. (Hint if you'd like to go next year, check out the curtains in your room. There is a second, heavier curtain that helps cut down at the light coming in the room, so you don't wake up at 3:30 AM - like WIDE awake - as I did a couple of mornings.)
General Conference Impressions
The conference is organized by volunteers - this is the third year - Yeah - 3 years and it is looking really, really good!
Matt Heusser and I agreed to host a Lean Coffee each morning. And, each morning Lean Coffee had a small but doughty group who met to discuss items on testing and software development in general.
Wednesday, 3 June, Matt and I also hosted the 1 day version of Lean Software Testing. Essentially, applying Lean concepts to testing. For us, this was an experiment as we were not entirely certain how a series of exercises that absolutely demanded full participation of everyone in the room would translate across cultures. In general - with a little effort - it translated pretty well. We found chocolate helped.
I live blogged my experience from the two conference days. (Day 1 is here. Day 2 is here.) I found the mix of speakers and format to be quite good. At one point, Huib Schoots tweeted that he was torn between which session to go to. As the conference went on, others had similar problems/ For me, this is a sign of a great selection of offerings at a conference.
The morning keynotes on Thursday and Friday I found interesting. There were several valuable ideas that are worth consideration - I blogged them at the time - and chimed in on Twitter a couple of times. Other participants had other takeaways.
I must say here, that I got an email from Matt Heusser asking if I'd be interested in presenting the discussion "On Complete Testing" which we have done together a couple of other times. This is a discussion around a simple question - "When the boss/customer/key stakeholder says 'this has to be completely tested,' what does that mean and how can we do it?" I said "Sure! I think that would be fun!" A week or two later I got an email from the organizers about "the keynote." What? Ummm - Matt? We gotta talk. As it was, we had a lot of fun, and based on the conversations, tweets and other folks blog posts, it looks like other people had fun to.
Bribing them with "chocolate imported from the US" and other items may have helped.
People
For me, the highlight of any conference is the people I get to interact with and learn from The many people I met or became reacquainted with over the time in Tallinn is astounding.
Let's see. Who stands out? Well, among the Organizers - who worked so incredibly hard -Grete Napits Helena Jeret-Mäe Raimond Sinivee Participants/speakers/delegates - Huib Shoots, Ruud Cox, Gitte Ottosen, Guna Petrova, Peter Varhol, Gerri Owens, Stephen Janaway, Bill Mathews, Dan Billing, Kristjan Karmo, Irina Ivanova, Rob Lambert, Aleksis Tulonen, Andrei Contan, Rikard Edgren, Martin Nilsson, Aapo Reitsak, Raji Bhamidipati ... the list goes on. If I stop and think about it - I know I can add more names to this group. Like the fellows I was chatting with on Thursday during the networking/entertainment evening. I know you told me your names, but SHEESH guys - bring cards next time to help job my memory!
People referred to with some frequency...In no particular order - Jerry Weinberg, Nicholas Taleb, Michael Bolton, W Edward Deming, Daniel Kahneman, Doug Hoffman. I know there were others, but these were the names that came up in the sessions I participated in.
Summary
I thought Nordic Testing Days was extremely informative. Unlike some conferences I've been to, there were no sessions where I wished I had made another choice and I did not get something worth considering. Importantly, there were no sessions where I simply wrote the presentation off and focused on email or something else.
Tallinn is a beautiful city. The people are wonderful - not in the annoyingly fake "How are you?" way - when what they mean is {Insert generic greeting here} but more in the "We have more than one way to communicate and make you feel welcomed in our wonderful city" way.
One word of caution - when walking in the Old Town, really pay attention to where you are going. The cobblestone walks and street are - cobblestone, meaning not smooth cement - they are not even and you can trip easily if not vigilant.
So, WHEN you go next year, keep an open mind, be ready for long nights with fantastic conversation and be ready to think and learn.
Estonia is a country of 1.3 Million people in Eastern Europe - way Eastern Europe. The neighbors to the East are Russia - North, beyond the Bay of Finland is... Finland. There are ferries that run between Tallinn, the capitol city of Estonia, and Helsinki, Finland. Its a cool city with loads of medieval buildings, castles/city walls and churches.
The city's "Old Town', the medieval heart of the city is a wandering maze of narrow, cobble stone streets. The town square boasts the oldest apothecary in the world - established in 1422 and continuing to operate today. Oh, they also have wifi - free wifi. Wifi EVERYwhere.
Tallinn is far enough North where for those of us from the US - it is pretty amazing. By 11:00 PM the first week of June, it is still light enough where it would be somewhere between dusk, the gloaming and full night fall. At 11:30 one evening, whilst sitting with colleagues at a patio bar in the conference center, we were amazed when we realized how late it was - and how none of us had any idea of the time. (Hint if you'd like to go next year, check out the curtains in your room. There is a second, heavier curtain that helps cut down at the light coming in the room, so you don't wake up at 3:30 AM - like WIDE awake - as I did a couple of mornings.)
General Conference Impressions
The conference is organized by volunteers - this is the third year - Yeah - 3 years and it is looking really, really good!
Matt Heusser and I agreed to host a Lean Coffee each morning. And, each morning Lean Coffee had a small but doughty group who met to discuss items on testing and software development in general.
Wednesday, 3 June, Matt and I also hosted the 1 day version of Lean Software Testing. Essentially, applying Lean concepts to testing. For us, this was an experiment as we were not entirely certain how a series of exercises that absolutely demanded full participation of everyone in the room would translate across cultures. In general - with a little effort - it translated pretty well. We found chocolate helped.
I live blogged my experience from the two conference days. (Day 1 is here. Day 2 is here.) I found the mix of speakers and format to be quite good. At one point, Huib Schoots tweeted that he was torn between which session to go to. As the conference went on, others had similar problems/ For me, this is a sign of a great selection of offerings at a conference.
The morning keynotes on Thursday and Friday I found interesting. There were several valuable ideas that are worth consideration - I blogged them at the time - and chimed in on Twitter a couple of times. Other participants had other takeaways.
I must say here, that I got an email from Matt Heusser asking if I'd be interested in presenting the discussion "On Complete Testing" which we have done together a couple of other times. This is a discussion around a simple question - "When the boss/customer/key stakeholder says 'this has to be completely tested,' what does that mean and how can we do it?" I said "Sure! I think that would be fun!" A week or two later I got an email from the organizers about "the keynote." What? Ummm - Matt? We gotta talk. As it was, we had a lot of fun, and based on the conversations, tweets and other folks blog posts, it looks like other people had fun to.
Bribing them with "chocolate imported from the US" and other items may have helped.
People
For me, the highlight of any conference is the people I get to interact with and learn from The many people I met or became reacquainted with over the time in Tallinn is astounding.
Let's see. Who stands out? Well, among the Organizers - who worked so incredibly hard -Grete Napits Helena Jeret-Mäe Raimond Sinivee Participants/speakers/delegates - Huib Shoots, Ruud Cox, Gitte Ottosen, Guna Petrova, Peter Varhol, Gerri Owens, Stephen Janaway, Bill Mathews, Dan Billing, Kristjan Karmo, Irina Ivanova, Rob Lambert, Aleksis Tulonen, Andrei Contan, Rikard Edgren, Martin Nilsson, Aapo Reitsak, Raji Bhamidipati ... the list goes on. If I stop and think about it - I know I can add more names to this group. Like the fellows I was chatting with on Thursday during the networking/entertainment evening. I know you told me your names, but SHEESH guys - bring cards next time to help job my memory!
People referred to with some frequency...In no particular order - Jerry Weinberg, Nicholas Taleb, Michael Bolton, W Edward Deming, Daniel Kahneman, Doug Hoffman. I know there were others, but these were the names that came up in the sessions I participated in.
Summary
I thought Nordic Testing Days was extremely informative. Unlike some conferences I've been to, there were no sessions where I wished I had made another choice and I did not get something worth considering. Importantly, there were no sessions where I simply wrote the presentation off and focused on email or something else.
Tallinn is a beautiful city. The people are wonderful - not in the annoyingly fake "How are you?" way - when what they mean is {Insert generic greeting here} but more in the "We have more than one way to communicate and make you feel welcomed in our wonderful city" way.
One word of caution - when walking in the Old Town, really pay attention to where you are going. The cobblestone walks and street are - cobblestone, meaning not smooth cement - they are not even and you can trip easily if not vigilant.
So, WHEN you go next year, keep an open mind, be ready for long nights with fantastic conversation and be ready to think and learn.
Friday, June 6, 2014
LIVE from Tallinn! Nordic Testing Days - Day 2!
Friday, June 6 - Day 2 at Nordic Testing Days.
SOMEone (ahem) overslept and came flying in to Lean Coffee to find Matt Heusser running it (Thanks, man!) with Rob Lambert & Raimond Sinivee and some 6 others participating. It was a fantastic conversation! And like every other Lean Coffee I've been to, the topics and conversation flowed too quickly to track what was happening.
And now I'm after a bit to eat and at least one more coffee - Will be back for the keynote - see you then!
===
First Keynote for the day - Arto Veldre is presenting on Software Errors as the Founding Pillar of Modern Society. The opening gambit is that there are myths that each of us fall into easily. Then slides under "what is Estonian" - mentions 99 stereotypes of Estonians. He observes that Estonia has one of the most connected society in Europe (yeah - that is true from what I have seen - even the forests in the parks and open space have wifi hotspots - no, I'm not making that up!)
So of all the cool technology things going on - are any of them impervious to problems? Are they safe from accident? (well, no, that is why we have jobs, right?) The harder question is are they impervious to intentional, not accidental, harm? How complex are the systems we have built?
Simply put (his words) "Are these computer systems ready for prime time?"
Can we really understand how systems work, let alone their safety from attack - if we don't understand the complexity of the technology under them. (He had a cool slide showing the landing computer from Apollo 11, along with a binder of source code printed on green-bar paper (flashback to my early career!)
We could understand the code (at one time) and now many systems have become more and more complex - Now - the fragility of systems increases with each additional layer of technology.
He makes an EXCELLENT point around security - "Information security is the only discipline that has laws before the textbooks are published." (Yeah - that is related to one of the items discussed in Lean Coffee!)
AND after another reference - he brings up self-fulfilling prophecies - and Nicholas Taleb's Black Swan - where we are blind to the situation if we base our understanding only on a limited set of input - for example - the turkey in the US. Everything looks like things are awesome and will continue to be awesome until Thanksgiving rolls around - then there is nothing to prepare/warm them.
And references the idea that maybe (maybe?) that the problem lies between the keyboard and the monitor. (Re: Weinberg's all software problems are people problems)
We are wired (biologically and socially) to expect certain things. These can fall into the realm of bias when we consider what it is that we are trying to understand - and things don't fit. We will see something that does not fit and we can either "turn away" or reject it as "not real." Sometimes it may NOT be real - sometimes it is. Sometimes we can see things and will say "that can not be it" and we'll translate it into something that fits our view.
He runs thru a series of high profile and less well known - the F22 & Chinook aircraft - both had significant software errors - Heartbleed - Apple XSS - etc.,
How did these happen? What caused them? More to the point what allowed them to get through and not be detected/found and removed?
Well, we're human.
Sometimes they may be accidents - then there is stuff that happens that we do not pay attention to, even though we are aware of them at some level.
Why does the Estonian ID card (and other country's for that matter) have a chip embedded in them? Why do certain "smart TV's" identify and record information about what you are watching - either through cable or broadcast or streamed via the internet? Do these systems serve a purpose? Are they really needed? (reference the NSA)
So, what happens with "big data"? Who oversees that? Who guards that and keeps it from improper use? Who tracks what and why? How do we know?
OK - he had a stack of slides and ideas - I caught a few of them and that was pretty much it...
===
Right, so grab another coffee and some fruit and off to a presentation by Raji Bhamadipati. She's hosting a workshop titled "Where Are the Notes From When You Testing This?"
So, the room is absolutely packed (says the guy who is happy he grabbed a spot near a power outlet) In the room are Bill Mathews, Rob Lambert, Matt Heusser and a stack of other folks.
And WE'RE OFF!
Some nice slides of people's notes - from Da Vinci's notes from the British Museum, to diaries of British soldiers from WWI, to images of people's notes from different purposes. The gist is, notes and note taking tend to serve as memory aides for the person taking the notes. The "If you are not taking notes you are not learning" is referenced, with the caveat that others may take notes differently.
How these are applied to testing gets pulled in - as in a bug is detected by a customer months after the project releases - How do you remember what you saw when testing? We might have the scripts, we might have bug reports or session reports or something. But notes do things that may jog our memory.
EXERCISE! We have post its - so start with notes! What do we use for note taking? LOADS of stuff - see?
Then there are other options... We have stuff to do - and now we get an exercise! (another?)
Try it: http://peppytester.workroomprds.com/ - then select Puzzle 11... and I'm going to try it!
so there's a bunch of us playing - and without hacking the code, we had a bit of fun. So - click the button on the left - that in turn changes the behavior of the button on the right. Now... prove it
And folks are walking thru what they did - and Dan Billings (yeah, the guy who talked on Security yesterday) decompiled the code. (snarl,,,) Fun.
--
Right - the point is, notes can help us remember and understand. Any form of note taking has its own perils.
What makes a good set of notes for testing?
Structure -
Title/charter/test case number -
Time stamp -
Configuration/set-up -
Scenarios -
Detail (just enough information) -
Bugs - what happened you did not expect? -
Conclusions/Observations.
If we can't identify what and how we are testing, does what we are doing really count as testing? Really?
Personal notes may require less formality than notes the boss may want to see. In any case, there need to be enough information for people (like, you) to understand the point of what you did, how, and what you noticed.
So, how do you know if you are taking good notes? Try opening them up and seeing what they tell you... say in like, 60 days.
--
Lunch Time! YUM!!!!!!!!!!!
--
OK, so I took much of the afternoon off, relaxed and prepped for my track talk. Sat with my lovely lady-wife, ran into her while she was heading down to lunch - then chatted with folks - it was really a nice hallway track session - relaxed and easy among presenters who were done and others who (like me) were getting ready to go.
We had some interesting views on the world and what fun was - and what to do.
So, in the end - I chilled - until 3:35 - Then I went in and did the talk on Stepping Up to Leadership: Test Leadership Lessons from Harry Potter.
So, things went on and I worked up a sweat and gave away the last of the candy we brought from the US - And generally had a good time. Changed my shirt and grabbed a beer (yeah, its Estonia - apparently others were jealous when I walked into the closing Keynote with a beer) and grabbed a seat where I could sit and write and ... keep the beer from getting tipped over. (Priorities)
In listening now to Iris Classon on The Undeniable Value in Curiosity, Collaboration and Contribution. She describes herself as "The world’s happiest .NET developer & Microsoft C# MVP! More energy than a 5 year old, talks more than your grandmother..."
So she's been banging on some of the same ideas I presented in my session -
Ask question, be curious, try stuff - The twitter feed on her talk (so far) consists of...
Right - so you get the idea. And - the thing gets cut short because of tech problems? I'm not sure.
Anyway - the questions were good - centered around curiosity and generally, they were interesting. I think Huib Schoots asked the best question "What is curiosity?"
Now then - The rest of the day is a blur...
It was a fantastic week - I'm exhausted.
===
SOMEone (ahem) overslept and came flying in to Lean Coffee to find Matt Heusser running it (Thanks, man!) with Rob Lambert & Raimond Sinivee and some 6 others participating. It was a fantastic conversation! And like every other Lean Coffee I've been to, the topics and conversation flowed too quickly to track what was happening.
And now I'm after a bit to eat and at least one more coffee - Will be back for the keynote - see you then!
===
First Keynote for the day - Arto Veldre is presenting on Software Errors as the Founding Pillar of Modern Society. The opening gambit is that there are myths that each of us fall into easily. Then slides under "what is Estonian" - mentions 99 stereotypes of Estonians. He observes that Estonia has one of the most connected society in Europe (yeah - that is true from what I have seen - even the forests in the parks and open space have wifi hotspots - no, I'm not making that up!)
So of all the cool technology things going on - are any of them impervious to problems? Are they safe from accident? (well, no, that is why we have jobs, right?) The harder question is are they impervious to intentional, not accidental, harm? How complex are the systems we have built?
Simply put (his words) "Are these computer systems ready for prime time?"
Can we really understand how systems work, let alone their safety from attack - if we don't understand the complexity of the technology under them. (He had a cool slide showing the landing computer from Apollo 11, along with a binder of source code printed on green-bar paper (flashback to my early career!)
We could understand the code (at one time) and now many systems have become more and more complex - Now - the fragility of systems increases with each additional layer of technology.
He makes an EXCELLENT point around security - "Information security is the only discipline that has laws before the textbooks are published." (Yeah - that is related to one of the items discussed in Lean Coffee!)
AND after another reference - he brings up self-fulfilling prophecies - and Nicholas Taleb's Black Swan - where we are blind to the situation if we base our understanding only on a limited set of input - for example - the turkey in the US. Everything looks like things are awesome and will continue to be awesome until Thanksgiving rolls around - then there is nothing to prepare/warm them.
And references the idea that maybe (maybe?) that the problem lies between the keyboard and the monitor. (Re: Weinberg's all software problems are people problems)
We are wired (biologically and socially) to expect certain things. These can fall into the realm of bias when we consider what it is that we are trying to understand - and things don't fit. We will see something that does not fit and we can either "turn away" or reject it as "not real." Sometimes it may NOT be real - sometimes it is. Sometimes we can see things and will say "that can not be it" and we'll translate it into something that fits our view.
He runs thru a series of high profile and less well known - the F22 & Chinook aircraft - both had significant software errors - Heartbleed - Apple XSS - etc.,
How did these happen? What caused them? More to the point what allowed them to get through and not be detected/found and removed?
Well, we're human.
Sometimes they may be accidents - then there is stuff that happens that we do not pay attention to, even though we are aware of them at some level.
Why does the Estonian ID card (and other country's for that matter) have a chip embedded in them? Why do certain "smart TV's" identify and record information about what you are watching - either through cable or broadcast or streamed via the internet? Do these systems serve a purpose? Are they really needed? (reference the NSA)
So, what happens with "big data"? Who oversees that? Who guards that and keeps it from improper use? Who tracks what and why? How do we know?
OK - he had a stack of slides and ideas - I caught a few of them and that was pretty much it...
===
Right, so grab another coffee and some fruit and off to a presentation by Raji Bhamadipati. She's hosting a workshop titled "Where Are the Notes From When You Testing This?"
So, the room is absolutely packed (says the guy who is happy he grabbed a spot near a power outlet) In the room are Bill Mathews, Rob Lambert, Matt Heusser and a stack of other folks.
And WE'RE OFF!
Some nice slides of people's notes - from Da Vinci's notes from the British Museum, to diaries of British soldiers from WWI, to images of people's notes from different purposes. The gist is, notes and note taking tend to serve as memory aides for the person taking the notes. The "If you are not taking notes you are not learning" is referenced, with the caveat that others may take notes differently.
How these are applied to testing gets pulled in - as in a bug is detected by a customer months after the project releases - How do you remember what you saw when testing? We might have the scripts, we might have bug reports or session reports or something. But notes do things that may jog our memory.
EXERCISE! We have post its - so start with notes! What do we use for note taking? LOADS of stuff - see?
Then there are other options... We have stuff to do - and now we get an exercise! (another?)
Try it: http://peppytester.workroomprds.com/ - then select Puzzle 11... and I'm going to try it!
so there's a bunch of us playing - and without hacking the code, we had a bit of fun. So - click the button on the left - that in turn changes the behavior of the button on the right. Now... prove it
And folks are walking thru what they did - and Dan Billings (yeah, the guy who talked on Security yesterday) decompiled the code. (snarl,,,) Fun.
--
Right - the point is, notes can help us remember and understand. Any form of note taking has its own perils.
What makes a good set of notes for testing?
Structure -
Title/charter/test case number -
Time stamp -
Configuration/set-up -
Scenarios -
Detail (just enough information) -
Bugs - what happened you did not expect? -
Conclusions/Observations.
If we can't identify what and how we are testing, does what we are doing really count as testing? Really?
Personal notes may require less formality than notes the boss may want to see. In any case, there need to be enough information for people (like, you) to understand the point of what you did, how, and what you noticed.
So, how do you know if you are taking good notes? Try opening them up and seeing what they tell you... say in like, 60 days.
--
Lunch Time! YUM!!!!!!!!!!!
--
OK, so I took much of the afternoon off, relaxed and prepped for my track talk. Sat with my lovely lady-wife, ran into her while she was heading down to lunch - then chatted with folks - it was really a nice hallway track session - relaxed and easy among presenters who were done and others who (like me) were getting ready to go.
We had some interesting views on the world and what fun was - and what to do.
So, in the end - I chilled - until 3:35 - Then I went in and did the talk on Stepping Up to Leadership: Test Leadership Lessons from Harry Potter.
So, things went on and I worked up a sweat and gave away the last of the candy we brought from the US - And generally had a good time. Changed my shirt and grabbed a beer (yeah, its Estonia - apparently others were jealous when I walked into the closing Keynote with a beer) and grabbed a seat where I could sit and write and ... keep the beer from getting tipped over. (Priorities)
In listening now to Iris Classon on The Undeniable Value in Curiosity, Collaboration and Contribution. She describes herself as "The world’s happiest .NET developer & Microsoft C# MVP! More energy than a 5 year old, talks more than your grandmother..."
So she's been banging on some of the same ideas I presented in my session -
Ask question, be curious, try stuff - The twitter feed on her talk (so far) consists of...
Right - so you get the idea. And - the thing gets cut short because of tech problems? I'm not sure.
Anyway - the questions were good - centered around curiosity and generally, they were interesting. I think Huib Schoots asked the best question "What is curiosity?"
Now then - The rest of the day is a blur...
It was a fantastic week - I'm exhausted.
===
Thursday, June 5, 2014
Live from Tallinn!! Nordic Testing Days - Day 1
Thursday, June 5 came earlier than expected. It is AMAZING how
bright the sun is at 04:00 - yeah - 4:00 AM! MAN! Good thing the
curtains were closed! Normally that is not too big of a deal
particularly as I'm an early riser. However, given the full day of
tutorial on Wednesday, then a lengthy, leisurely Estonian dinner,
followed by "a little more beer" at the conference center bar.
We are off and running!
Lean Coffee with a small but doughty gathering met to discuss items from Exploratory Regression testing, ideas from the Lean Software Testing tutorial Matt Heusser and I did yesterday.
The conference is organized by volunteers - this is the third year - Yeah - 3 years and it is looking really, really good!
And now, we are starting the fun of Keynotes!
The opening keynote is by Jevgeni Kabanov on Testing in the Automation Age.
And here we go!
Jevgeni is a doctor - like PhD - and is the founder of GeekOut! another conference in Estonia. He is also the Founder and CEO of ZeroTurnaround.
Now, for my American colleagues, Estonia is a country of about 1.3 Million people in Eastern Europe - like waaaaay Eastern Europe. The neighbors to the East are Russia - North, beyond the Bay of Finland is... Finland. There are ferries that run between Tallinn, the capitol city of Estonia, and Helsinki, Finland. Its a cool city with loads of medieval buildings, castles/city walls, churches and wifi - like wifi EVERYwhere.
And the Keynote begins -
ZeroTurnaround started with a single product - JRebel - which runs for Java, and provides continuous testing availability for Java developers. The point is to speed the process that developers go through to deply to testing and make life easier for everyone. Their estimation is that this product can save teams 1 month of effort a year, by making life easier.
They added LiveRebel a bit later. LiveRebel provides Release Management for Continuous Delivery. It allows for testing of releases and, if bad things happen, can rollback in the case of failure.
Then XRebel allows for interactive Java profiling/ This allows developers (and others) to see/understand what is happening behind the scenes.
And in the Cost of Quality slide (following the XRebel summary) - the image is an atomic explosion. Cool.
When things don't work, you risk losing trust of your customers. If your software fails, or generally does not deliver, then there are problems Like - people want their money back. Like people walk away. Like people walk away and don't come back and tell people your software... stinks.
To help them manage their quality, they automated testing. They support 77 environments, 1,428 test suites and some 219,912 test results. (OK. let's see where this goes...) They are running a "team" of 27 "machines" (servers?), 3,132 unique job configurations and runs 294 jobs/hour - which gives 8+K jobs a day and... yeah - you get the picture.
They are running
Jenkins, Chef, Vagrant on Amazon EC2. Oh, and a scripting language
called Groovy. The issue they have is that Amazon tends to get annoyed
with them if they don't give a "heads up" at least, or ask permission,
to use more than a few thousand servers at a time. Ummm - yeah - that
is sucking up a fair portion of Amazon's resource.
This gives them the ability to run significant numbers of "Acceptance tests" which they define as tests that fails before the release and succeeds/passes, after the release. They run these nightly .
Captain Obvious says "Everybody Tests:Test Everything."
(OK - that sets up some interesting point/counter-point for the closing keynote for the day "On Complete Testing" with Matt Heusser and... well, me.)
The thing is, per Jevgeni, for them - engineers spend 30 - 50% of their time writing tests. Since Functionality is seen as a liability, tests help to counter it. This is an important point. We can catch/trap items before they go live by running a massive array of test scenario combinations.
For them,
"Everybody Tests" includes developers, sysadmins, customers and product
managers. And he makes an awesome point on his "CEO Tests" - in that
people who don't use the software all the time (or at least regularly)
will sometimes find interesting and significant bugs by not following
the rules.
Now - "Test Everything" - this includes challenging specs, considering usability, releases (obvious, no?) and processes. Then there is something really interesting. That is "test the business model" - does this make sense for us to do? This is something that many organizations can learn something from!
One aspect to consider - testers to go undercover as customers, put in support requests instead of bugs - suddenly devs take it very seriously. (Me: a little sneaky, but I get the gist.)
Founders are often generalists - they are "equally bad at everything" - which is maybe more honest than the "equally good at everything" view that people often spout. The consideration is that people will get as far as they can without a specialist. By the time they realize they need one, they are probably a year or so behind the curve. That is, you often find yourself in trouble and realize you need someone who is an expert/specialist later than you should have brought them in.
Two reasons to hire QA guys: productivity and pro-activity. Testers who are trained as testers and have specialized in testing tend to look at things differently than those who are not trained as testers. (Me: less confirmation bias?)
The final point he makes is that the people around us are the type companies need. When they started out, he took the view of automation will take care of things - now he needs testing specialists.
DING! Time is up - and into question/answers -
Q/A - Interesting question - What is the ratio of the work your developers put in to writing test automation vs writing production code? The answer was that all developers do both. The breakdown is that roughly 30% to 50% of each developer's time/effort will be to write automation code - the balance is writing production code.
A: (OK, so I missed the question, but the answer was a really good point) - For us the QA guys are part of the team - they participate in the same standups, they work with the developers, they learn how the developers think and they look at things differently.
===
I'll be diving in to the Exploratory Testing Dojo being run by Huib Schoots. The bummer of this for me is that Dan Billing will be presenting on Security Testing at the same time. BUMMER! I wanted to hear that one as well. (Note - for me, that is the sign of a good conference program - where I find myself torn between which session I'm going to next.)
OH! I ran into Stephen Janaway - who is ALSO live blogging -
here: http://stephenjanaway.co.uk/stephenjanaway/testing-2/live-from-nordic-testing-days/
Right - so Huib has a MASSIVELY full room to learn about Exploratory Testing - in his ET Dojo. I mean like - he has a full room - all the seats taken and a bunch of folks in chairs lined against the back wall. He is using LeanKit as the tool - (available here: www.leankit.com ) and it is available at the appstore and google play.
AND - with a room full of people exercising apps via wireless - the connection slows waaaaaaaaaaaaay down. bummer. And Huib wants me to not say nasty things about him...
Right - Huib is making a crucial point - TAKE NOTES! LOTS OF NOTES!
If you can't track what you did, how will you remember when the boss asks you at the end of the day - or when you're getting coffee in the middle of the day - "What did you do?" You may be able to have a general idea, but specifics? Probably not.
ME: This is where most people fail with ET in my experience!!!! People don't take notes detailed enough to be able to recreate what they did - EXACTLY - they can do it generally, but to be able to describe WHAT THEY DID? Usually not. It comes off as wishy-washy, and not very understandable.
So, people have finished chatting with each other and comparing notes. Except that some folks have actually gotten new test ideas to work with. Cool.
Huib brings people back to discuss what they noted. They first observation is that the mobile version and desktop version have different capabilities. The mobile version seems more limited than the desktop version.
Second group talks about how they went deep into a couple of the ideas - except they have had limited exposure to other functions - like - none. Huib points out that the initial instructions were to "see how the app works and don't go too deep." If you are looking to see general functionality, a deep dive does not work.
(Heh - I think I found a bug in Blogger in that I now have two entries with the same title. )
===
Back from Lunch and getting ready for the presentation this afteroon - and sneaking in to Peter Varhol and Gerie Owen on Cognitive Bias. The thing is, they are dealing with how these biases are impacted by the system 1 and system 2 thinking - via Thinking Fast & Slow. And yeah, Matt & I mentioned this in our workshop yesterday. Cool.
Various versions of bias discussed, and the "count the passes" video with in-attentional blindness. The question of Seeing vs Observing are presented - along with one of my favorite tester quotes:
Yeah, Sherlock Holmes, the character by Sir Arther Conan Doyle. Good stuff.
Raising the question of mindset - an how we can limit ourselves without realizing it.
AND - Sneaking off to fellow live-blogger, Stephen Janway's session (as this is a double length session - sorry Peter and Gerie.)
===
Stephen jumps into his presentation, Testing Your Emotions. The irony of him (a Brit) and him, being a male, have stereotypes of being limited by themselves. Stephen explains that emotions are core human responses, the include behavior as well as physically. Emotions impact memory - between the fight/flight response. The impact of the memory will colour how we deal with issues, or events, people, etc.,
Emotions can push us one way or another - and can bring us to levels we may not expect.
Emotional responses are those kinds of things we have little effort in controlling, because, lets face it, we can't always anticipate how people will react to our emotional reaction. Its a challenge, right?
Umm - Surprise! Charles Darwin was one of the first to consider and study emotions in people - and animals. The thing is, we express emotion physically. in ways that are similar to animals. Scary, eh?
Mentions Plutchick and the Wheel of Emotion and Loehen's Cube of Emotions.
The interesting thing is the relationship between chemicals in the brain and how the the body reactions - that is, emotion!
Now then - what does this mean to us as testers - as PEOPLE! Well, how about, if we, as testers are having a negative reaction which leads to a negative emotion, are we not noting the emotions that potential customers or people using the software might have? This brings us to Bolton's "Is there a problem here?"
Related to that, is Jerry Weinberg's comments on feelings - that is emotions. (Pete Comment: is this not part of how people may be finding the core problems and recording them emotionally?)
Understanding emotions can help us understand how we act, how we "should" act and how we react to other people.
Right - we're into Questions now. I quite liked that presentation. Does that count as an emotional response?
===
OK - so I went back to my room and picked up what I would need for the final session of the day. I also got cleaned up a bit - the conference center is REALLY WARM. So, a quick wash-up and clean shirt seemed in order.
I'm standing in the hallway cleaning up the blog post and listening to Gitte Ottosen. I met Gitte at Agile Testing Days - she is extremely smart and has good ideas worthy of consideration. Listen to her when you can and read her work. You don't have to agree with her to learn something of value. She is really good.
And now - Show Time!
==
Right. So we made it through the presentation. We had a bit of an issue with the laptop we were using - for reasons I'm not certain of, we were told we could not use out laptops. So, we made do. As it was, we made it through it.
Gave away loads of chocolate bars... from the US. We also had an absolute ball.
After that - a bit of a reception, some entertainment and fantastic conversation. Now, it is nearly midnight here - and I'm tired. By the way - did I mention that it is still light out?
Right. Lean Coffee in the morning.
G'nite all!
 |
| Unicorn in Estonia! |
We are off and running!
Lean Coffee with a small but doughty gathering met to discuss items from Exploratory Regression testing, ideas from the Lean Software Testing tutorial Matt Heusser and I did yesterday.
The conference is organized by volunteers - this is the third year - Yeah - 3 years and it is looking really, really good!
And now, we are starting the fun of Keynotes!
The opening keynote is by Jevgeni Kabanov on Testing in the Automation Age.
And here we go!
Jevgeni is a doctor - like PhD - and is the founder of GeekOut! another conference in Estonia. He is also the Founder and CEO of ZeroTurnaround.
Now, for my American colleagues, Estonia is a country of about 1.3 Million people in Eastern Europe - like waaaaay Eastern Europe. The neighbors to the East are Russia - North, beyond the Bay of Finland is... Finland. There are ferries that run between Tallinn, the capitol city of Estonia, and Helsinki, Finland. Its a cool city with loads of medieval buildings, castles/city walls, churches and wifi - like wifi EVERYwhere.
And the Keynote begins -
ZeroTurnaround started with a single product - JRebel - which runs for Java, and provides continuous testing availability for Java developers. The point is to speed the process that developers go through to deply to testing and make life easier for everyone. Their estimation is that this product can save teams 1 month of effort a year, by making life easier.
They added LiveRebel a bit later. LiveRebel provides Release Management for Continuous Delivery. It allows for testing of releases and, if bad things happen, can rollback in the case of failure.
Then XRebel allows for interactive Java profiling/ This allows developers (and others) to see/understand what is happening behind the scenes.
And in the Cost of Quality slide (following the XRebel summary) - the image is an atomic explosion. Cool.
When things don't work, you risk losing trust of your customers. If your software fails, or generally does not deliver, then there are problems Like - people want their money back. Like people walk away. Like people walk away and don't come back and tell people your software... stinks.
To help them manage their quality, they automated testing. They support 77 environments, 1,428 test suites and some 219,912 test results. (OK. let's see where this goes...) They are running a "team" of 27 "machines" (servers?), 3,132 unique job configurations and runs 294 jobs/hour - which gives 8+K jobs a day and... yeah - you get the picture.
They are running
Jenkins, Chef, Vagrant on Amazon EC2. Oh, and a scripting language
called Groovy. The issue they have is that Amazon tends to get annoyed
with them if they don't give a "heads up" at least, or ask permission,
to use more than a few thousand servers at a time. Ummm - yeah - that
is sucking up a fair portion of Amazon's resource.This gives them the ability to run significant numbers of "Acceptance tests" which they define as tests that fails before the release and succeeds/passes, after the release. They run these nightly .
Captain Obvious says "Everybody Tests:Test Everything."
(OK - that sets up some interesting point/counter-point for the closing keynote for the day "On Complete Testing" with Matt Heusser and... well, me.)
The thing is, per Jevgeni, for them - engineers spend 30 - 50% of their time writing tests. Since Functionality is seen as a liability, tests help to counter it. This is an important point. We can catch/trap items before they go live by running a massive array of test scenario combinations.
For them,
"Everybody Tests" includes developers, sysadmins, customers and product
managers. And he makes an awesome point on his "CEO Tests" - in that
people who don't use the software all the time (or at least regularly)
will sometimes find interesting and significant bugs by not following
the rules.Now - "Test Everything" - this includes challenging specs, considering usability, releases (obvious, no?) and processes. Then there is something really interesting. That is "test the business model" - does this make sense for us to do? This is something that many organizations can learn something from!
One aspect to consider - testers to go undercover as customers, put in support requests instead of bugs - suddenly devs take it very seriously. (Me: a little sneaky, but I get the gist.)
Founders are often generalists - they are "equally bad at everything" - which is maybe more honest than the "equally good at everything" view that people often spout. The consideration is that people will get as far as they can without a specialist. By the time they realize they need one, they are probably a year or so behind the curve. That is, you often find yourself in trouble and realize you need someone who is an expert/specialist later than you should have brought them in.
Two reasons to hire QA guys: productivity and pro-activity. Testers who are trained as testers and have specialized in testing tend to look at things differently than those who are not trained as testers. (Me: less confirmation bias?)
The final point he makes is that the people around us are the type companies need. When they started out, he took the view of automation will take care of things - now he needs testing specialists.
DING! Time is up - and into question/answers -
Q/A - Interesting question - What is the ratio of the work your developers put in to writing test automation vs writing production code? The answer was that all developers do both. The breakdown is that roughly 30% to 50% of each developer's time/effort will be to write automation code - the balance is writing production code.
A: (OK, so I missed the question, but the answer was a really good point) - For us the QA guys are part of the team - they participate in the same standups, they work with the developers, they learn how the developers think and they look at things differently.
===
I'll be diving in to the Exploratory Testing Dojo being run by Huib Schoots. The bummer of this for me is that Dan Billing will be presenting on Security Testing at the same time. BUMMER! I wanted to hear that one as well. (Note - for me, that is the sign of a good conference program - where I find myself torn between which session I'm going to next.)
OH! I ran into Stephen Janaway - who is ALSO live blogging -
here: http://stephenjanaway.co.uk/stephenjanaway/testing-2/live-from-nordic-testing-days/
Right - so Huib has a MASSIVELY full room to learn about Exploratory Testing - in his ET Dojo. I mean like - he has a full room - all the seats taken and a bunch of folks in chairs lined against the back wall. He is using LeanKit as the tool - (available here: www.leankit.com ) and it is available at the appstore and google play.
AND - with a room full of people exercising apps via wireless - the connection slows waaaaaaaaaaaaay down. bummer. And Huib wants me to not say nasty things about him...
Right - Huib is making a crucial point - TAKE NOTES! LOTS OF NOTES!
If you can't track what you did, how will you remember when the boss asks you at the end of the day - or when you're getting coffee in the middle of the day - "What did you do?" You may be able to have a general idea, but specifics? Probably not.
ME: This is where most people fail with ET in my experience!!!! People don't take notes detailed enough to be able to recreate what they did - EXACTLY - they can do it generally, but to be able to describe WHAT THEY DID? Usually not. It comes off as wishy-washy, and not very understandable.
So, people have finished chatting with each other and comparing notes. Except that some folks have actually gotten new test ideas to work with. Cool.
Huib brings people back to discuss what they noted. They first observation is that the mobile version and desktop version have different capabilities. The mobile version seems more limited than the desktop version.
Second group talks about how they went deep into a couple of the ideas - except they have had limited exposure to other functions - like - none. Huib points out that the initial instructions were to "see how the app works and don't go too deep." If you are looking to see general functionality, a deep dive does not work.
(Heh - I think I found a bug in Blogger in that I now have two entries with the same title. )
===
Back from Lunch and getting ready for the presentation this afteroon - and sneaking in to Peter Varhol and Gerie Owen on Cognitive Bias. The thing is, they are dealing with how these biases are impacted by the system 1 and system 2 thinking - via Thinking Fast & Slow. And yeah, Matt & I mentioned this in our workshop yesterday. Cool.
Various versions of bias discussed, and the "count the passes" video with in-attentional blindness. The question of Seeing vs Observing are presented - along with one of my favorite tester quotes:
You see, but you do not observe. The distinction is obvious.
Yeah, Sherlock Holmes, the character by Sir Arther Conan Doyle. Good stuff.
Raising the question of mindset - an how we can limit ourselves without realizing it.
AND - Sneaking off to fellow live-blogger, Stephen Janway's session (as this is a double length session - sorry Peter and Gerie.)
===
Stephen jumps into his presentation, Testing Your Emotions. The irony of him (a Brit) and him, being a male, have stereotypes of being limited by themselves. Stephen explains that emotions are core human responses, the include behavior as well as physically. Emotions impact memory - between the fight/flight response. The impact of the memory will colour how we deal with issues, or events, people, etc.,
Emotions can push us one way or another - and can bring us to levels we may not expect.
Emotional responses are those kinds of things we have little effort in controlling, because, lets face it, we can't always anticipate how people will react to our emotional reaction. Its a challenge, right?
Umm - Surprise! Charles Darwin was one of the first to consider and study emotions in people - and animals. The thing is, we express emotion physically. in ways that are similar to animals. Scary, eh?
Mentions Plutchick and the Wheel of Emotion and Loehen's Cube of Emotions.
The interesting thing is the relationship between chemicals in the brain and how the the body reactions - that is, emotion!
 | |
| Michael Bolton Quote |
Related to that, is Jerry Weinberg's comments on feelings - that is emotions. (Pete Comment: is this not part of how people may be finding the core problems and recording them emotionally?)
 | |
| Jerry Weinberg Quote |
Understanding emotions can help us understand how we act, how we "should" act and how we react to other people.
Right - we're into Questions now. I quite liked that presentation. Does that count as an emotional response?
===
OK - so I went back to my room and picked up what I would need for the final session of the day. I also got cleaned up a bit - the conference center is REALLY WARM. So, a quick wash-up and clean shirt seemed in order.
I'm standing in the hallway cleaning up the blog post and listening to Gitte Ottosen. I met Gitte at Agile Testing Days - she is extremely smart and has good ideas worthy of consideration. Listen to her when you can and read her work. You don't have to agree with her to learn something of value. She is really good.
And now - Show Time!
==
Right. So we made it through the presentation. We had a bit of an issue with the laptop we were using - for reasons I'm not certain of, we were told we could not use out laptops. So, we made do. As it was, we made it through it.
Gave away loads of chocolate bars... from the US. We also had an absolute ball.
After that - a bit of a reception, some entertainment and fantastic conversation. Now, it is nearly midnight here - and I'm tired. By the way - did I mention that it is still light out?
Right. Lean Coffee in the morning.
G'nite all!
Monday, June 2, 2014
Tactics, Strategy and the Glorious First of June
I am writing this the evening of 1 June – The First of June –
On an aircraft flying over the Atlantic.
When you spend time reading and thinking and considering different
topics, you find them overlapping – sometimes in surprising ways.
The movie being played on the screens (ahem, really? One screen
for everyone to watch the same film?) is Mr Peabody and Sherman. So, we’re conflating history and science and
popular understanding. Whilst setting
aside the whole “George Washington cut down a cherry tree then said he could
not tell a lie and admitted it” thing – yet supported the Marie Antoinette
thing where she said “let them eat cake” – another myth, except it was to
degrade the person instead of showing them as an icon.
I find the same thing happens with people talking about Test Strategy. I find many times they refer to items which I consider Tactical, not Strategic. There is a significant difference. One describes the purpose of why you are doing something - One describes how you intend to do it. People tend to focus on the thing in front of them and not on the most important goal they have.
Simple, right?
Except things are never so simple, I find.
The Glorious First of June
In May, 1794, Europe was
in the throes of reacting to the French Revolution, the Revolutionary Wars and
the general mess that was consuming the continent. The British Admiral,
Lord (Richard) Howe, the 1st Earl Howe, was chasing the French Admiral Villaret-Joyeuse, across
the sea in an attempt to intercept the French, who were bringing supplies of
grain and other necessities to support the French military who desperately
needed the supplies.
On 1 June, 1794, some 400 miles off Ushant, Howe caught up with the French Republican fleet.
The British fleet of 25 ships of the line, engaged the French fleet of 26 ships of the line - the capitol ships, the battleships of the day - the pride of their navies. When the smoke cleared, quite literally, some 1,200 British seamen were dead - but some 4,000 French seamen were dead, 7 of the French ships were captured or destroyed, and thousands more were prisoners.
This was hailed as a triumph for Lord Howe - and it was. A major achievement. The fist, and largest, fleet action fought by the British and French navies during the Revolutionary and Napoleonic wars - a clear British victory.
One for the record books. The smaller British fleet engages and does serious damage to the larger French fleet. Except for one thing...
While the fleets were blasting each other with shot, shell snd grape, the transport ships with their critical cargo, were not taken - they delivered their supplies. Howe had inflicted tactical damage on the French - and failed in the strategic mission.
In our testing - how often do we do the same thing? We find loads of bugs - except we can't tell our stakeholders anything about the software that is of real value? Some people make a big deal about the number of bugs found and ignore the critical question of what are we after?
Is our bug-finding of tactical importance or strategic importance to the organization?
Is our bug-finding of tactical importance or strategic importance to the organization?
 | |||||||
| Lord Howe's Action, or, the Glorious First of June |
Subscribe to:
Posts (Atom)
