Thursday, October 27, 2011

STPCon Fall 2011 - Part II

Tuesday at STPCon in Dallas was an astounding day.  Matt Heusser and I were slated to present a session entitled "On Complete Testing" immediately following Rex Black's morning keynote address.  As I wanted to prepare the room for our presentation and make sure all our potential examples were queued up, I admit that I ducked out early. 

Our Tuesday morning session started with a simple question to the participants "When the boss comes in and says 'We need this completely tested?' or 'We need this to be bug free' what is really meant?"  at is complete testing?"  We got an answer we expected - "That we have complete coverage in our testing."  OK.  Coverage of what?  "Requirements." 

We began discussing that idea, which drew out things like validation metrics, boundaries and equivalences defined within the requirements, and what can be done about undocumented requirements, assumptions and presumptions, expectations that were not communicated, and other problems. 

We moved on state diagrams - mapping each potential state within the application and how that can be exercised.  I pulled out a way cool example of a system I had worked on a few years ago.  The basic functions worked really well.  However, by sheer accident a memory leak in the application was found.  At no I had tested a few years ago.  This was an error found simply by letting the application idle over the weekend.  This proved to be an example of a problem of strange problems that can occur outside of our control or way of expecting any issues.

We moved on to the idea of code coverage as a means toward complete coverage.  This lead us to the differences between statement coverage and branch coverage.  This was an interesting discussion on just what the differences could be and how we could potentially miss paths even if every branch is tested.  We may miss combinations of branches.  We agreed that the idea of "100 Percent" coverage of lines or branches still would not give us complete testing.

We did agree that none of these techniques would give us true complete testing in isolation.  If we made use of all of these techniques, we would have a greater likelihood of coming close to "complete" testing. 

We continued down through input combination coverage, the idea of of order and filtering of memory, state and interrupt problems.  All in all, we had a rolling discussion and the hour and 15 minutes flew past for both Matt and I. 

We had an absolute blast! 

(Note - everyone who was in the session, we promised to send a transcript of the discussion to all who requested it.  SO, those who dropped off their business cards or gave us their email address on the "signup list" - I'm still working on that and I'll get it out as quickly as I can.  OK?)

The session wrapped up.  We headed out and got a cool beverage, then had some really interesting hallway conversations, and headed to lunch. 

The afternoon found me in a series of chats and conversations with people and just loving every minute of it.  Around 3:30, I reached into my briefcase, pulled out and put on a tie I brought specifically for my upcoming presentation on test leadership. 

My afternoon presentation was on Test Leadership Lessons from Harry Potter.  Yes, I know, a geeky-nerdy topic, but that is kinda me.

I walked in, got a very nice introduction from Fiona Charles who introduced me as "a colleague and friend" - which left me gobsmacked (not a good thing to have happen just before speaking.)  Suffice to say that the idea of technical leadership and the example of Harry Potter as a reluctant leader, one who is not appointed and does not seek to be a leader, but finds himself in that role, has similarities in the ideas of Technical Leadership expressed so well by Gerald Weinberg.

It was a fun session for me, and it seemed to me that the participants also had fun.  I encouraged them to write - for themselves, in blogs, newsletters and, well, anywhere.  Learn and share what you learn.  Experiment and share your results.  Be bold and dare greatly - (kinda like what testers are expected to do when testing, right?)

The session wrapped up and we retired to the "Welcome Reception" on the conference center's patio.  This was a great evening with nice appetizers, great conversation, meeting people and generally having a great time.  I was even interviewed by Yvette Francino for Search Software Quality!  How Cool! 

My day wrapped up with a nice relaxing evening back with another crowd of testers sharing stories and having a good day.

I can not imagine a better way I could have celebrated my 50th birthday.

:-)

3 comments:

  1. ** Posted on behalf of Jim Hazen **

    Pete,
    Sounds like you're having fun. I would like to talk to you about the Coverage stuff you talked about. Seems that some people are getting back into the Statement & Branch coverage static/dynamic testing methods. Which is good.

    Just most testers either don't know about them or don't have the time/resources to do it. Maybe now with agile pushing TDD this is something else the developers (who should be doing it) and testers can work on together to get more stable code ready before full system level testing occurs.

    Again, have fun dude. Tell Matt & Yvette hello for me. I'm sure I'll see her at the next SQuAD meeting in Denver.

    Jim

    ReplyDelete