Testing Ideas CAST 2013 pt 1

OK!  Here we go.  Saturday, this past weekend, was the "Test Retreat" organized by Matt Heusser (Excelon Development) and was a fantastic kickoff to the event that is CAST.  Michael Larsen wrote about it - look for his stuff  here:

http://www.mkltesthead.com/2013/08/live-from-madison-its-testretreat.html
http://www.mkltesthead.com/2013/08/cast-2013-day-1-live-and-loud.html
http://www.mkltesthead.com/2013/08/day-2-at-cast2013-live-and-dangerous.html

==

The next day was a meeting of the Board of Directors - a long affair that was challenging for the participants.  I was there as a member of the Board.

Monday was full day tutorials/workshops.  The evening featured Matt and I presenting our Tester Round Tables Exercise.  More on that in another blog post

Which brings me to This Morning -

0.  Lean Coffee - We started Monday and Tuesday with a Lean Coffee session at a local coffee shop.  We had 15 people on Monday and 10 people on Tuesday.  I presume it was the result of extremely late night as we started at 7:00 AM.  At breakfast, there were a fair number of very tired looking people who mumbled something about being too tired to make it to Lean Coffee.  That's fine.  We're going to launch a Lean Beer tonight.

If you're at CAST, look for tweets on that announcing when and where.


Jon Bach's keynote on Argument.

His take - in summary - reasonable people can disagree.  Some do it bluntly, some do not.  Citing Stuart Reid's keynote from 2010 at EuroStar.  Interesting thing about that presentation - Jon's fight went viral.  His brother James described it not as an argument or a debate but an ideological war. I think there's something to that.

One observation(really important) - One thing we testers should be good at is argument.  Every bug we file is an argument - or a possible argument.  We need to advocate why that bug is important.  If it gets dismissed we resist.  If we don't are we really good testers?  Or are we faking it?

Can we deal with problems or fight with people who don't like what we say?  Who knows? Can we debate within our community?  Can we go "looking for a fight"? Can we jump to conclusions?  What about jumping to conjectures?  Jon (I agree) suggests that conjecture is what we do all the time.

Dale Hample - Arguing: exchanging reasons face to face  -  Yeah - something to that quote.

In short, Jon is presenting an idea similar to Lee's "fighting without fighting."

Interesting consideration, "root cause" of bugs - Humanity.  We're people.  Testers, Developers, Designers are human - they are fallible.

All Desire Causes Suffering - not the "don't want anything" instead, consider what it is that you want, don't attach excessive importance to those wants.  That is what causes harm.  Know what your values are, then stick with that.

There are several very good points - most grabbed in twitter.  Fear and concern and problems and conflict and ... stuff are related.  I think there's much to that.  Then there is the "Test is Dead" thing from 2011.

Really?  Yeah - HUGE conflict.

Now, consider the craft of testing as an investigative process.  When the argument seems totally having jumped the shark - consider reframing the argument.  In that, we have a consideration: testing is related to journalism.

Why?  Testing is interrogation & investigation in pursuit of information to aid evaluation.  That is what journalists - when they are at their best - are doing.

And now - open season!

- interesting opening question - argument / discussion - can they be interchanged?  Sure.  There are ways to make a case for something where you are aggressive and confrontational.  Other times, a more nuanced approach is of value. 

- Sometimes argument is not bad - It can serve to educate others on your position.  You may not convince your opponent, but others observing may be enlightened in what you value. 

TRACK SESSION

What's Software Craftsmanship - with Jim Holmes and Matt Barcomb

Right - sitting in the first track session of the season.  Jim tweeted a pair of links last night - I intend to find them.  And here they are: 
Code: https://github.com/jimholmes/PresentationDemos/tree/master/CAST2013
Slides: https://speakerdeck.com/jimholmes/cast-2013-software-craftsmanship-for-testers

Opening argument is that "software craftsmanship" grew from reaction to a couple of things, including Agile Community - and the programming community.  They launch into a discussion on 'what is it?' as in how do the people in the room think about it.

A variety of views from "becoming the best you can" to passion for the work.  An idea is presented that there is a community around this.  There are some things that are common and some are a little more interesting.

What is Test Craft?  How does one grow "craftsmanship"?

Why do we care?

* Maintainability;
* Continued Delivery of Value to Stakeholders (not customers);
* Sanity of the team;

These apply to testing as well as the code. 

Who cares?
* Testers
* Codes
* Whole Team

Generalization - if one is looking at the "whole team" - really that means people have a clue what the other specials do.  So, yeah, testers, get an understanding of what some basic terms mean.  You don;t need to be able to write production code, but understand some of the fundamental concepts.  ADDITIONALLY - Coders should learn fundamentals of testing beyond what unit testing they do.

Learn the Meta knowledge associated with your specific trade within the craft (eg., testing within the world of software development)  The Heuristics that we can keep handy to infer the years of knowledge it takes to understand programming - just as they can learn core Heuristics in testing.

It is not just OK to be specialized.  It is fantastic - AND - that means you can then address the needs of people without your experience.  They should be willing to do the same thing to help you understand their craft.  THERE is where "the whole teams" kicks in.

Concerns - Don't confuse "gilding the lily" with being a craftsman.  Too much of any one good thing is ungood.  Beware of being drawn into the trap of "this isn't good enough."

How do we care?

* A tester who works alone but wants to improve;
* During code reviews;
* During tester-coder pairing;
   * Tester as Navigator;

Right - so much of this is related to the idea of sharing information.  Testers don't need to critique the code (oh, this thingamajob looks incorrect and potentially inefficient. if you tweak the do-higgy it would work much better.)  Instead, look for the broader themes

Pairing is hard work - as humans we don't do well sitting 2 and a half inches away from someone working while that person is looking over your shoulder ALL THE TIME.  You need to take the approach of "we're here to help each other and our end goal is to make good stuff."  Jim makes the observation that no pair starts out fantastic or even good.  You each must work to build trust in each other.

Matt made the point that a tester who has learned some solid coding heuristics can actually make the tester helpful to developers.  (Pete note: absolutely - been there done that)

Coding Smells &  Anthony Marcano's Testing Smells (via Rob Sab)

Think of smells as the "spidey sense" that you have - be aware!  Observe!

Jim's "smell priorities" - WRONG -

Preferred order of these things:
* Optimization / speed
* correctness
* readbility

In code - Readability TENDS to trump everything else.  Unless it doesn't - hence the idea the heuristics are useful and  might be wrong.  Sometimes things will trump readability - except sometimes readability will help those other things...

Jim is now citing ideas I learned (mumble mumble mumble) years ago.  (Pete - while learning BASIC, FORTRAN, PASCAL and COBOL.  Yeah, somethings are still true.  You young whippersnappers aren't the first ones to struggle with this.  Argue with me and I'll get out my cane and beat you if you stand still.)

For example - Don't repeat yourself - DRY - as a rule on designing code.  Simple wins.  Simple is great.  Unless there is not enough abstraction - you've simplified it so much, it is of little use.

Not Enough Abstraction - Abstration is a pretty common idea - take one thing away and deal with it somewhere else.  This can make things easier to understand.  Unless you take this to a bit of an extreme - Loads of helper methods, wrappers within ... yeah ... yeah you get the idea.  Pushing things off is helpful - unless it is introducing problems - eg., not clear what is going on.

Complexity - so... what is this to us?  Well - let's see - 45 IF statements nested 8 levels deep.  1 case in the middle doesn't work - Why not?  WHO KNOWS?  Split it apart.  Make sure that each "test" is stand alone - not a conglomeration of multiple tests.  Keep it clean.  Keep it clean by refactoring.

Refactoring - Make small changes to implementation - NOT THE BEHAVIOR.  Look at what is happening and clean it up a little at a time.

Testers can help Developers (Coders) by asking questions - often around the scenarios of the code.

Jim walks through an exercise that was just too fast to capture - Find it in the code link above.  Its fun.  In short. in @ 10 minutes people in the session gave 4 test ideas he had not encountered even though he used the same example for several years.

MAtt is wrapping up with a story around "It takes a village to make software" - by a story around a reconstructed "Peat Bog Village" he and his wife visited in Ireland.  Kinda cool story - the gist was that the two /specialists/ in the village - the smith and the thatcher - needed to contribute to the greater community in the mundane tasks as well as exercise their specialties in the context of what needs to be done based on the season.  Related to that, was if there is a cobbler in the next village (a shoemaker) the smith may need to spend some time working with that craftsman - they each learn something and each benefit from their mutual work.

Sharing ideas can and will benefit both (or all) participants.

Find Jim on Twitter at @ajimholmes and Matt at @mattbarcomb

LUNCH TIME!

Pretty good conference lunch - a little pasta a nice salad some chicken like stuff - there was also pizza and a nice caprese salad (you know, the slices of tomatoes with slices of mozzarella in between drizzled with olive oil...)

And now in Erik Davis' session on finding testers "in the rust belt." 

Erik works at a company outside of Cleveland, OH, which, as he observes, is not one of the "cool technology" centers of North America.  He observes that they have an extremely difficult time to identify people who want to do testing - and want to do testing - and have really solid experience.  AND since CS majors tend to NOT want to do testing as a gig, after all, they'd rather do development for games and make a pile of money... AND then there are problems with recent grads not really knowing how to test because most colleges and universities in that area don't do a good job.

SO, here we are - what to do - Erik's solution was to hire entry level people.  No, not some entry level - everyone is an entry level tester.  THEN they learn - they are trained and worked with and lean their product then they learn to act and THINK like a tester.

That is a really important point.  How many companies treat testers as if they were not issued a brain when they were born?  When they think of "testing" they mean "click these buttons and enter these values and you will get this for a response - if you don't let us know."  That's not testing - not even checking - its rubbish.

So, they don't get many CS majors - when they do the get these weird requests to join as a tester - but really want to be developers... well, that may be good or it may stink.  If they want to learn the product and learn the product set for a year or two - AWESOME - then they can- no worries.  If their mission/intent is to get into dev AS SOON AS THEY START - they don't do well.

Erik's take is that some people with certain degrees tend to demonstrate certain traits.  He warns folks that certain people may have different experience. 

Interesting observation - Music Majors, Instructors, Fine Arts People - prove interesting.  They look at things differently.  Very differently.  They come in without the huge bias problems that "technical trained" people do - they may have problems with picking up computerish stuff - BUT - when they dive in they find new ways to look at testing.

This leads to issues with training people who "are not comfortable" with computers.  The thing is, fairly few people really are.  They do things that can compensate them.

Consideration - If you train people when they come in to the company, in a way that will benefit the company (not ust test) then you are helping people AND the company.  Everyone benefits.

One drawback - if you are calling people in for an interview and the candidate applied for a different position - tell them when you call.  That way if they hate the idea of being a tester they have the chance to bail before and save everyone's time.

Don't try and screen resumes.  For testers, there are not really good filter points that work - really.  Blind screens on certification or C# or C++ is not a good idea.  Having HR screen the resumes might not work - it did not for him at all.  BUT - HR can screen for "people problems" - with a funny story about a guy who stabbed a Pringles can because he was mad - and stabbed the hand holding the can.  Ouch.

He found interns really helpful - both college/uni level and high school kids (like strong STEM students).  It gets them in, AND - they gain interest (maybe in testing)

Follow Erik on Twitter at @erikld

OPEN SEASON -

Interesting - questions on training and Per Scholas come up.  How do people interact - Communicating via Network is helpful - INCLUDING - who might know someone who could fit in.  This is true in and out of companies (that was my comment.)

===

OK - I hid for a while.  I admit it.  Actually, I went to my room and swapped contents of my bag, put on a fresh shirt, washed my face and got back in time for milk & cookies.  YEAH!  COOLNESS!

And now in Erik Bricarp's session on Making Learning My Top Priority.

Very good opening/introduction on his personal experience, limitations and the like.  Perspective matters in all things.  He's describing his journey in self-education and learning.  The principle is fairly straight forward - using ideas and discoveries (self) to motivate yourself and develop thinking and work up the courage to take the next step.  Really good stuff -

Practice, Socialize, Present, Gather Feedback, Reflect (on all above), Read (stuff) / Watch (videos, webinars), Take Courses, Share Ideas, Mentoring, Organize. The thing is , we do much of this every day with things.  The hard part, from my experience is to actually go public with these ideas.

These items/ideas can contribute - by driving thinking, using them as a heuristic for working on each task.  Having said that, if you consider how to keep going, how to continue learning (Pete: continuous learning is an indicator of a true master) you can internalize these ideas and make this a perpetual loop - Pete: rather like Wash/Rinse/Repeat.

The challenge is to keep moving forward - to keep using this concept as a brainstorming exercise.  This is crucial of self-identified skills/training list. Using these ideas, one can strive (struggle?) to improve.

In Erik's case, he expects much of himself.  His goal is to demand much of himself, not necessarily others.  His goal was. simply, to get better.  Part of this includes establishing and raising personal standards.  When one does that, there are risks - professional and personal.

When you stand up, raise yourself, your standards and expectations, you will make waves.  People may not like it very much.  There may be costs.  When you do this, however, you will feel better about yourself.  You will grow - which is uncomfortable.

What do you do then?  Do you need some form of a personal manifesto?  Some form of guideline for your professional work?  The temptation is to become so "motivated" that you can't refuse anything - references "Yes Man" with Jim Carrey.  (Learning to do so is good, learning to say no is also important.)

Doing things that are scary is... scary.  It is part of how we develop.  It is part of embracing the challenge of what we have set for ourselves.  In turn, great things can happen - like speaking at CAST.


Pete: Yeah.  This was a good session for me to sit in. Follow Erik on Twitter at @Brickuz.

Open Season!