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.
===
No comments:
Post a Comment