StarEast - Update for Wed/Thursday

OK, so I didn't get the Wednesday post written on Wednesday. I forgot how the evenings get busy here, too.

So, here goes. I liked James Whittaker's opening keynote session on Wednesday. It was a different topic than in the brochure, but that's cool.

He made a very important point that our future will involve a lot more code than it does today - and it's going to control even more critical functions than today. Therefore, it needs to work right all the time. I thought the session had some major implications:

1) He's talking about defect-free computing (not just software, but hardware, data and everything else involved in getting correct results.). History has shown this has been an elusive, if not impossible, effort to achieve - largely due to the complexity of the code. Does that mean we should give up? By no means. But, zero defects requires some very rigorous methods and ways to build-in quality, not test it in, which was one of James' points.


2) He said testers need to be less like Lewis and Clark in terms of their test approach. OK, I buy that. Lewis and Clark were explorers. I take that to mean that exploratory testing has some limitations and we need a better way to test. It's interesting, though, that exploratory testing is a very popular test approach and has gained a notable following. Is this a blow to exploratory testing - or simply an admonition that other methods are needed? I think it's the latter, but I find the remark very, very, interesting.


3) James said that testers need more insight into the code. Black box testing is inherently inefficient because you do a lot of poking around. I agree. So, the question is how do we get the development tools to the point that they also contain great diagnostics?


4) Software should be so good that testing is no longer needed. I only wish. I doubt that will ever happen due to the human aspect of software development and usage. About 20 years ago, the folks at SEI didn't include testing in the CMM because they felt if you had a good enough process, the software should be defect-free (or close to it). That never happened and I doubt it will in the future, either. So if you are a tester I wouldn't worry about your job security, at least as a profession. By the way, 20 years ago, people were predicting that coders would not be writing code in the future. While a great deal of code is generated by tools such as Microsoft's Visual Studio, there is still a whole lot of manual coding going on!


I don't know if we'll see the digital future James portrayed in his talk, but I do agree more and more things will be software-driven and the criticality of the applications will also be higher. Think of the cars that will be driving themselves. Heck, there have been cases already where Volvos have quit at highway speeds due to software failures. Along with the cool technology comes problems that aren't so cool.


I liked his session a lot and hope it resonates as a call to testers and developers to take software quality to a higher level.


The second keynote address was by Elizabeth Hendrickson, who spoke about her experiences as a tester on an Extreme Programming team. It was a great talk as well and gave people a good perspective of what an agile tester's work day is like. She addressed issues like requirements in agile, which I thought was great.


Throughout the day, there were a wide variety of track sessions which were well attended. Not every session had a great speaker, but sometimes the content is great so you stay. Sometimes the session as a whole just doesn't do it for you, so you can move to another one.


I spoke at 3:00 on the topic "Testing Disasters and Turnarounds". Thanks to everyone one who attended. I have posted my updated slides here:

http://www.riceconsulting.com/public_pdf/testing-disasters-and-turnarounds-v2.pdf

The products and services expo was good - very well attended. However, it seems like the numbers of tool vendors was smaller this year.


To top the day off, there was a casino night with several really cool prizes, none of which I won.



Thursday



Bahrat Mediratta and Antoine Picard of Google gave an encore presentation of their keynote from StarWest called, Testing in the Toilets. It's a neat story about how a simple act of posting articles they write about testing in the one place everyone goes - the restroom. The results were interesting and it's a great story about how they changed the culture at Google in terms of test awareness.



I had a book signing and other duties today, so I only got to attend two track sessions. I thought the one by Gerard Meszaros (author of "X Unit Patterns) was very interesting on building record/playback automation into your applications. It's an interesting alternative to commercial tools and opens some doors on some creative test automation that solves many of the problems seen in traditional test automation.

Finally, I went to John Fodeh's keynote session, "Are We Ready to Ship?", which was a nice treatment of the topic of release metrics for software. I came away with a lot of good ideas.

So, that's it. I'm heading back home early in the morning, so this is my last StarEast post this trip. I felt it was a good conference. I got to see many good friends from all over the world and that always is a good thing!

StarEast 2008 - Tuesday Update

Hi from Orlando!

The weather is great and the StarEast software testing conference is going well.

So far, all I can speak to are my own sessions. However, tomorrow I'll be in other sessions and giving some reports to those not able to attend.

In my "Becoming an Influential Test Team Leader" tutorial, we had a great time. Our biggest problem was that during the experiences, we got rather loud. I thought we might get in trouble!

However, I also had people tell me they were not bored at all and totally engaged because of the experiences.

This tutorial is one of my favorite parts of Star for one simple reason. It's an opportunity to engage with test team leaders and managers who want to make a positive difference in their organizations. The great majority of the people that attend this tutorial are savvy people looking for solutions. I hope I am able to provide hope and few solution strategies.

One of the interesting things I've started doing lately is having people submit cards that contain something they have achieved recently. We recognize the person as the larger group and although it sounds a little cheezy, it's a warm experience. Unfortunately, we don't do enough of that kind of thing in the trenches back home, but I hope people carry this idea back with them.

Everyone needs recognition and it is one way to add value to your team. That's because a person that feels appreciated will rise to the occasion at other times as well.

Today I spoke on pairwise testing applied to use cases. I like combining techniques to get a synergistic effect, and this is one of those times when two great techniques make a third more powerful one. I have some new things I plan to add the next time I present this session.

I had a good group and it's always cool to explain this concept to people. I remember the first time I saw the value of pairwise. It's a cool thing. Not the only technique by any means, but a powerful one when used intelligently.

I proctor one of the ASTQB exams this afternoon, and that will be today's work.

I think the format of more tutorials, with many of them being half-day tutorials is great. It "feels" good. I think it opens up more options for people to learn in some in-depth ways.

It's also been great to catch up with good friends like Lloyd Roden and Julie Gardiner from Grove Consultants in the U.K. Friends like this make the conference circuit an enjoyable experience!

See you tomorrow!

Randy

Why Your SOA Effort May Fail

I'm getting ready for my StarEast trip, but want to mention an interesting article I read this week titled, "SOA failures traced to people, process issues" on Networkworld.com (http://www.networkworld.com/news/2008/043008-interop-soa.html).

The article quotes Anne Thomas Manes of the Burton Group in response to a question about what overriding message IT executives need to hear about Service-oriented Architecture (SOA).
"The problem's not technology, Howard said. People and processes are at the heart of what's wrong with SOA as it currently exists in enterprises."

I found it interesting that in an audience of around 300 people, only 6 indicated that their SOA efforts were proceeding well.

I can add my own observation that adds support to Manes' comments, that is, people in my course on testing SOA seem to be much more interested in the technology aspects than they do the people and process aspects. This has been bothering me for some time now.

I agree that the technology seems to be progressing more than the human aspects. For example, getting the business folks to work better with the technology people is a big challenge in some companies. In fact, I think this is the big challenge of getting people to adopt agile methods as well.

The acticle goes on to state, "IT departments implement a SOA program that may be technically proficient but doesn't meet the needs of business users, Chris Howard said, noting that Burton Group is researching SOA successes and failures through interviews with IT pros and business executives at dozens of clients. Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said."

Interesting stuff, and it lines up with what I see as well.

Take a read and see what you think.

On a different note, yesterday (May 3) was the 9th anniversary of the F5 tornado which ripped across Oklahoma. It was a record-setting event, with sustained winds of over 318 mph and 40 deaths. There were 675 reported injuries. The damage estimate was 1.2 billion dollars. The outbreak spawned 66 tornadoes. The main tornado passed about 1 mile south of our home and was the closest I've ever been to a tornado. It was an awesome display of the fury of a tornado.

So today when the sirens sounded at noon, as they always do here on Saturdays, it brought back the feelings of taking cover and praying. (By the way, I learned that prayers get real short when an F5 tornado is bearing down on you!) That was quite a day for sure. I still use this as an example in my talk, "The Risks of Risk-Based Testing" as the kind of risk that is so far outside of the bounds that you don't even know how to plan for it.

I'll be posting all this coming week from StarEast, so stay tuned for updates!