The morning started with a lean coffee session hosted by Lisa Crispin and Janet Gregory. There was a good turnout and really happy exchange of information.
The official opening of the conference - alas, without the regular host Jose Diaz, who is home sick. Filling in for him was Mike Sutton (@mhsutton) - really nice and out-going guy. Smart and crazy friendly. In the middle of the opening came... the Super Agile Person! and a small cast of characters portraying and playing out A Christmas Carol, as applied to software testing and Agile methodologies.
This set up the opening keynote of the conference, by Abby Fichtner, on twitter she's @HackerHhick, presenting "on what's possible." She begins by talking about how she got into software - after her dad bought an Atari (hey, 1980's!) and the two of them began writing code together.
She walks though her undergrad work and talks about how she got into computers and ... hacking. She also talked about the challenge associated with words. Like, how "hack" originally meant, an innovative workaound of a physical object - like - model trains. Except this was in the 1950s and the model trains in question were being done by engineering students at MIT trying to figure out how do drive specific reactions through electronic controls - an early form of programming.
She moves on to "haters gonna hate" - talking about how people with interesting, innovative ideas often get derided for moving forward with things that make no sense to anyone and look like toys. Like, telephones... airplanes... a small gadget called, an "ipod" or something like Amazon Web Services.
All of those things were derided (some very recently) as of no value and the person pushing them had gone round the bend a bit. And the detractors were proven fabulously wrong.
And she moves to an interesting idea that "Evolution is the ultimate hacker." It is less about engineering and more about making things work - that serve a purpose and will survive. For example, if an animal needs to be flexible, and fast, to not get eaten, they either all get eaten OR they develop the abilities and physical traits needed to survive - flexible wrists, wings, etc.,
She moves to human invention - how a long time is taken to get the ground work in place so that INNOVATION can ACTUALLY happen. We tend to see "innovation" as a magical moment and we don't see, partly because it is missed by most people, the painful work to make it possible to see the possibilities and maximize the potential. For example, driverless cars - the whole robot car thing. First one was made in 1925. Yeah. It has taken a while to get to where we are today.
Creativity & serendipity have a relationship. According to Abby, a variety of studies have shown that when comparing children's learning abilities and creative abilities to "innovate" - those with neat, organize thought processes, those often reward at school for being "good students" are often those who do not do the "innovative work" needed - that is often the result of people who have more chaotic thought patterns.
Many times, they are the people who overcome huge obstacles and creat a new world for the rest of us.
You gain strength courage and confidence from exery experience you have faced
- Eleanor Roosevelt
Art is what we are doing when we make our best work.
- Seth Godin
When we reach out with courage, and do something in spite of fear, we make amazing things happen (she is going really fast - it is nearly impossible for me to keep up - sign of a really well-laden presentation in my mind.)
By creating art (or anything) that is something that defines us as being different and unique - not being part of the faceless masses who blend in and live lives of conformity.
It is by reaching out and creating and daring that make magic happen (she was a year or two behind me at Hogwarts. Different house though.)
And she brings back reference to her blog Hackerchick blog (- Pete note - Yeah. It's good. Read it You don't need to agree, just read it and think.)
Important note - Success may come from creativity. Be careful that the same success does not limit your creativity! This is a common problem. Keep challenging your own views and your own self.
OK - great quote during the Q&A - If something scares me, there is magic on the other side. (She's not a Hufflepuff.)
BREAK TIME!
SO, I stepped away for a couple of interviewing sessions and missed the first round of track talks. However! I'm back in time to hear a new speaker, Carin Eaton (@Caz_Eaton) from Cape Town South Africa.
This is an interesting idea - she's taking the "tell a story about your testing" to a literal example - Her slide deck consists of artwork that strongly resembles illustrations from a children's book. And she has a small booklet and is reading a story - the story of how her company has migrated from a Waterfall model to a more Agile approach.
She's describing the "relationship" between her company and Waterfall as a friendship by default, even though the relationship was less than totally beneficial. The problem was that sometimes Waterfall hurt people's feelings and they did not do their best work. Then, they met a new person, Agile.
They found that they could be friends with Agile, and Agile could be quite nice. As more people through the company met Agile, they found that many things they had been looking for became suddenly, easier. The people began to speak out and ask questions they had not before.
The hard part was that sometimes, people were a little afraid of change. Some people found that getting to know their new friend was a more work than they wanted to do - or were willing to do. They set up a small group to lead the effort. Then, they found that "doing all the things" led to a turmoil - stirring all the pots and not serving any food. (great analogy for many groups in an agile transformation!)
Instead of working in isolation (a common approach) they reached out to share ideas and pair/team on the effort. One issue they realized was that they had not had shared understanding of what the intent was, even though they "knew" what was supposed to happen. They had fallen into a common trap in Agile Transformation - they were trying to change how the organization functioned, by doing things the way the organization had... always functioned.
By reaching out to people in the organization, by sending surveys and questionnaires, and making them as personal as possible. The result was people responding in greater numbers than others had previously.
By reaching out, it helped people see that the task group needed people to be involved for the benefit of the comapny. By doing small things, with small amounts of input, they were able to help people overcome their fear of what might happen if things didn't work. Result(s) seemed to be mixed, except people began to act more openly.
By getting leadership to openly support the effort - beyond simple lip service - but getting into the effort and showing personal interest helped overcome certain levels of fear. By opening up processes, and in some instances installing tighter expectations, e.g., requireing a "show me" that an effort was ready to be tested beyond those who were working in the immediate task - a demo!
A "reverse demo" was also introduced - where testers walked developers through scenarios that needed to be exercised. The result was a closer pairing in work where testers and developers interacted instead of acting as if a wall was between them.
Training was important - not just in techniques or practices but also in other areas. Most important was people being engaged in the training - Not just the lecture type, but also the hands-on exercises. Most adults learn better by actually doing the work - drawing on the challenges to learn instead of being told what they would learn.
AND NOW - Carin is citing Matt Heusser's workshop from Agile Testing Days 2014 on Lean Testing as providing ideas and insights to use and try. She is also listing other ideas and exercises they make use of that they picked up from their experience at this conference in 2014.
OK - she's begining her wrap up - Question Everything. Participate not spectate. Lookf for the "big picture." Remember that the key is to do things that make sense. Not every approach will work for every problem or situation. Some techniques work really well in some situations, some do not. Look to see what is working, don't think that because you start with an approach you are committed to that approach only. If it is not working - Change it.
OH! Really nice touch. Last slide she has a picture of her team - the ones who were leading the efforts she was describing in the talk. Oh. And she had pictures of squirrels all the way though. Yeah, so squirrels.
-- Lunch Time --
Right lovely lunch conversation with a whole pile of people - too many to name - and I'm going to be late to Vasco Duarte (he's @duarto_vasco on twitter) if I don't scurry...
Vasco is talking on NoEstimates and software testing. He asserts that Estimates are more dangerous than Unicorns. I think the Agile Unicorn gor up and left in a huff. I am not sure he understood what was meant (Unicorns can be very sensitive)
The concern is that Estimates can be very limiting, constrictive guesses. And companies bet huge amounts of money on them. And people don't really see the problem except that so many times they are wrong. And the blame gets laid on the ... well, never mind.
And so we have estimation meetings and estimation meetings for the estimation meetings and the es... yeah. You get it.
Some Ideas (Principles)
1 - If you do not trust your process, don't try and improve it - dump it and clean up the mess.
... wait - what? No such thing as unicorns? (Pete comment - Dude, have you ever seen an angry unicorn? It isn't pretty)
Products get released because we need to make money or serve customers or both. Sad fact is, most estimates don't help with telling you much useful information in support of that purpose.
2 - Shorten the feedback cycle.
He assers that ,...
Cost (Duration) = Essential Complication * Accidental Complication
Ummm, consider - a 2-point story when the project is a big ball of mud is different than a 2-point story after you've been working on the software for some time. One will be much closer to reality, based on experience, the other is a random guess - and still both are measured for the same "weight" in duration - so they are "the same".
Do we spend time estimating how long it will be before we can work on a task before we actually get to that? Ummm - Look at the number of items with story points on items in the backlog. OK, so how long have they been there? Ummmm - yeah.
(Pete note - Yeah, dude, I know. this is the 2nd opportunity to make a Trump joke. Yeah, I get it.)
Now citing studies by Capers Jones & Scott Ambler as authorities on software failure rates.
(Pete - comment withheld so I don't get kicked out of the conference and the country.)
sigh
OK - back on track - there is a lot being said and I am missing much of it...
Speaker suggests "Testing for Value..." look for the value of the project.
Focus on what can be done in a block of time for specific reasons/goals. Idea to implementation & deliverability can be made shorter. Short & to the point.
Instead of testing for functionality, try testing for what people will benefit from the effort. Can the software be used beneficially now? How about when the next feature is finished? What about the feature after that? Stop trying to deliver more features and focus on the value.
---
When ypu can't do that, when you can't determine the value, then look at features.
Estimation is waste. Reduce the impact it has on your business.
Measure progress only with software that is running, has been validated (by some measure) and is being used.
Setting targets outside the normal performance of the organization is dangerous and corrupting.
--
System where you work has predictable outcomes. Learn what they are.
OK - Extra point - Projectsd are not the right way to deal with software. (Yeah, there's a #NoProjects thing)
BREAK TIME
With the Keynote finished, I have more "not in a session" responsibilities, so I'm going to miss the next block - BUT - I'll be back as soon as I can with Lightning Talks!
TTFN -
Other responsibilities are now completed and I'm set up in the room for Lightning Talks. Chris George (tweets at @chrisg0911) from Cambridge Consultants in England, is sitting next to me. Bright guy. Really smart guy and a good tester. I met Chris at my first Agile Testing Days. He impressed me then and he still does.
Sitting in front of me is Janet Gregory - YEAH! THAT JANET GREGORY! ( @janetgregoryca 'nuff siad)
And the talks are starting!
First up is Gil Zilberfeld (tweets at @gil_zilberfeld) talking about how so often the easy stuff is really the complex stuff. His examples are things like... Waterfall - easy to explain, really hard to do well. Then Scrum - easy to explain - really, REALLY hard to do.
Next up is Mark Winteringham (tweets at @2bittester ) on ATDD Paradox. OK - talking about acceptance tests and how they can do good stuff and avoid... sucking. You can't really automate some things with the most common tools. The challenge is to identify the tasks that need a little (or a lot) extra scruitiny. These tend to fall under one of the levels of complexity described by Jerry Weinberg ( @JerryWeinberg) in his An Introduction to Systems Thinking. The more complex systems require a different level of thinking.
And Lalitkumar Bhamare ( @Lalitbhamare) - Thinking about Session Based Programming. We know about Session Based Testing - Can we do something similar with Session Based Programming? Yeah, Programming... If we can do time boxed, focus work in testing, can there be value in doing the same in Programming. Sessions can be limited or keyed on specific ideas. Some can be considered similar to the constraints in testing - we need to look at the similarities before we dismiss. (He has a really good point. Many of the tasks do bear similarities worth considering.)
Next Up! Alex Schartz) (@alexschwartzbln) ! "Forget the Red Shirts, here come the Tribbles." (I sense trouble ahead...) Why do we treat service people as throw aways? Why not treat the SERVERS as throw-aways ... the red shirts from Star Trek, (original series) OK, so those are the red shirts, how about the Tribbles?
Tribbles were nice cute, little beasties. They had a nice "trilling" sound that, strangely calmed the crew (human) of the Enterprise. Except... the things reproduced (Pete note - at rates that leave rabbits in awe.) Flexibility is strong, can we do something with lower cost that will make life better - and remember Servers are disposable?
Next up! Melissa Pontes ( Tweets at @melissabpontes) from Brazil! (One of our fellow Software Testing World Cup Judges!) She is talking about her experience working with training blind & visually impaired persons for testing. (With a video) Point of the video is that people with limited physical abilities are challenged to participate fully with society - particularly those who are blind or visually impaired. The challenge is often with US - to help them become more than what most of society expects. People who are smart, intelligent, good thinkers with capable minds should not be off-set by external limitations imposed by others - typically people who are themselves blind to their own imperfections and shortcomings.
With THAT! We are getting ready for the closing keynote of the day from Michael Wansley (The Wanz - @teewanz). After THAT there will be other activities for the evening, including the Winter themed party, dinner and the presenting of the prizes for the Software Testing World Cup for 2016 and the Most Influential Agile Testing Person award.
Until then - BREAK TIME!
And Michael Wansley (tweets at @teewanz) launches his keynote with a riff from Thrift Shop... and the line "this is fucking awesome." Yeah - THAT Micheal Wansley ... and he's also a software testers.
So, he's talking on "From Waterfall to Agile, The Advantage is Clear." He talks about his work at MS, working on XP (gold) and talks through the stuff he worked on in that. First major point - Software is supposed to be so good, the people using it are not aware it is there... In HIS world there is one other major point - "Testers are the gatekeepers of quality."
Why? (GASP!) The simple fact is, in his world, the stuff he worked on and is still working on, needs to be so stable that people don't need to be aware of how the software works. It needs to be bullet proof - as clean as possible with an experience so simple that it is intuitive.
That was the system he grew up in. Test plan, test cases, software... test and kicking the software back until it is as perfect as possible. The challenges are that working in isolation is a challenge. (ahem)
After talking about his music and touring and sold-out shows. He finds himself back in software testing at Tableau Software. There, he's working in an agile environment in a massively expandable environment.
Ad-hoc work is encouraged - TO A PURPOSE - You exercise against pretty much the world. People have already exercised "the functions" and then his group finds itself dealing with pretty much everything else. Because, the challenge is, building environments that emulate customer environments.
They have moved to quarterly releases - massive large releases. And they then support loads of versions because releases are supported for a fairly long time, until they roll off. Not everyone finds the same things, but yeah...
Agile testing is looking for all the problems all at the same time, Learning, discovering, exercising (paraphrasing - cuz, he's talking faster than I can type & no slides for me to cheat off from!)
Awesome analogy - Software testers are the rear right wheel (except in the UK & a few other countries). Why? You can't see it in the mirror, it does not steer the car, it just lets the car get down the road.
Simple, eh?
The flip side - be smart enough to know that other people are probably smarter than you. Recognize it. Learn. Intelligent is good. Smartest - that can change. Don't hang your hat on that.
"We are the power in the Powerpoint presentation." Yeah - he said that. "We find the things the customer should never, ever see." He said that too.
So, the great challenge is to test a piece of software that has already been tested. We are looking for software items that customers can find that, somehow, we're expected to find something that people might encounter. Edge cases are what they deal with and find. the stuff where "no one would ever do that." Yeah - that stuff.
Testers can search through the software and find the weird uses there may be.
BING!
Documentation is not for you - it is for the person that FOLLOWS you. Deal with it - and document it as well.
** OK - I lost a lot of the keynote as I had to help test a piece of software for work. Yeah, Testing while in a testing conference!
Stuff happening tonight - there may be updates!
Cheers - TTFN
Right - Prizes were announced for the Software Testing World Cup. It was a really, really tight contest. There were seven very good teams to critique.
And, here are the results -
Best Branding / consistency of message - Team Bug Terriers, Russia
Best Bug Award - QB Lab Technomaniacs - South Africa
Best Team Spirit - One Day Testers - Brazil
Holy Cow Who'd Look for THAT Bug - RT Pest Control - United States
3rd Place - Quest Aoteara - New Zealand
2nd Place - Team Mentor Graphics - Israel
1st Place - Pan Galactic Gargle Blasters - Netherlands
No comments:
Post a Comment