Diary of a Soccer Coach: Week 4

You've been there before a well worn meeting room with your team gathered around a table going over a list of action items related to the project you've been working.   Sometimes they are new requirements, perhaps they are refinements of existing functionality, or tweaks of the deployment procedures taking into account lessons learned in that first deployment of the software.   The first practice after that first game,  is very much like this.   Often there isn't enough time to discuss defensive or offensive tactics with the players before the first game.

It is sometimes a matter of perspective, a coach after the first game of the season, or a manager or lead on a team reviewing the steps they took on that first ever critical deployment, the first game, the first actions of substance as far as the customer might see.  So in hindsight, that first practice, that first meeting, is often a discussion of the aftermath.  For our kindergartners, we discuss the issues I noticed during that first game.  There are almost always a few areas to correct, and they aren't always the same from Game 1 in one year versus any of the others.

Typically a reminder of the rules is necessary.  A reminder about which goal we are attacking, which one we defend, a reminder not to use hands except for the Throw-ins, and an encouragement to stop play when the whistle blows and quickly bring the ball to the referee when there is a stoppage of play for going out of bounds.  While errors can occur in any game, I try to point out the mistake, and correct the behavior without singling out any particular team member.  The point after all is not that someone erred, but that we play the game correctly to reduce stoppages of play.

With the instructional league sometimes this is difficult.  Some players have an over arching desire for the ball, and they may indulge this by diving at the ball.  This is a behavior we try to discourage.  For one thing, falling to the ground is as bad as waiting flat footed for the ball.  They aren't upright able to move with the ball, and if they are down where the ball is, there's a higher possibility of injury as other players go for the ball around them.   Sometimes they fall down, and stay on the ground, and again even if the ball isn't near them, this isn't behavior we want to encourage.  Sometimes its a sign that the kid is tired, but they rarely will get into shape if they sit down when they are supposed to be in the game, and the ball could come at any time too.

Ever been on a team where similar behavior happens?  Where they get tunnel vision, seeing only the one task before them at the expense of what is going on around them on the field?   How can we avoid this behavior?  What's worse is what if a team mate ends up blocked or stuck in some area and doesn't realize it?    As professionals we can try to encourage, give a second set of eyes to these issues, but in the end its really up to the individual to get themselves back on track.  We can encourage that team mate to come back on board, but honestly, if that person cannot take the initiative, there may be little we can do to really fix an issue that is internal to them.

Just like with my soccer players, I take them back to basics, breaking down the basics of the pass, of corner kicks and goal kicks, of throw-ins and kick-offs.  Only so much time can be spent on correcting the past, as new challenges and new games await.  So before the second game we spend a little time talking about defense.  Of reminding the kids that in our league, there are no goalies and therefor noone should go into the goal arc even to go after the ball, but more importantly we teach them what to do to protect their own goal.

First involves positioning, if a player is following an opponent bringing the ball up, we show them how they can move their feet with out crossing them, using the balls of their feet to have better response time in their jockeying back and forth.  We show them how to encourage the ball handler to dribble a particular direction, to funnel them away from a straight shot on goal, or to where we hope additional team mates can cut off their lane of advance.  We also try to show them that having everyone covering one person leaves open lanes of passing to the opposition, it leaves area of the field uncovered, and opens up easy attacks on their teams goal.

In software development, testers play a part of defense, not from bugs scoring on them, but from preventing threats to the value of the product.  If the goal as a team is to release a product with value that's usable by the client, then anything that allows the product to be misused, leaves features less than fully implemented, or just plain not covered is a threat that we as testers try to find.   The one difference here is that unlike in soccer where we can see the ball coming many times before it arrives near our zone of defense, in testing we don't have the ability to look at the software and say a bug is coming from here or there.  We have to instead visualize it with our mind.

How can we visualize where bugs might be?  One way is to be involved early in the process, be in with the conversations with the customer or client and helping to determine how the software may be used.  We also must consider the negative, the view of what invalid data, or improper operations might do to the software.  What if a file consumed is missing settings, does the software resort to a default and store that in the configuration for next time?   If you start typing before the software can fully load, will it cause an unexpected behavior?   We can brain storm a horde of test ideas to try to cover the entire areas of the application, but the reality is just like in soccer, we are just one tester, we can only cover so much ground in eight hours of work time.

What about opposition tendencies? It may be possible in soccer to see that certain players tend to favor an attack on goal from the right or left side.  Some players may prefer passing the ball forwards, or looping back rather than continuing forward at a bad angle.  As testers, we can evaluate the software for tendencies, are there certain areas that seem more bug prone, are there areas that are more critical, or more likely to be highly used and thus could cause more risk?  Is there a particular feature set which sets your software apart from another, then that is an area I'd be sure to test.

Then a foul may be called.  Maybe one player pushed or tripped another, maybe it was a hand ball.  Maybe there's an area of your software that is of particular risk to the customer.  They need that feature to work, quickly, to solve a time critical problem.  Whatever the case may be, we try as hard as we can to find every single bug there may be, but the reality is we can't cover the whole of a software that's anything but trivial.  The nature of software and the myriad of systems it may be installed upon create such a large volume of possibilities that we cannot test it all, so we use techniques to break the software down into areas that we can cover.  We find ways to distill problems to a range of possible outcomes, and we try to think of new ways to test old functionality, because you just never know when a new feature may impact an old one.

Diary of a Soccer Coach: Week 3 and First Game!

I'm a bit behind on blogging due to duties last week, but I'll catch up by throwing the third week of practice alongside the first game.   In our league the third week of practice heralds two things, first the last practice before our first game, and the arrival of our team rosters and uniforms.  On this particular day, the 'head coach' of the league, who has been helping out with our Kindergartners had to distribute the uniforms to all the different divisions.  This left me alone to do a lot of work with the kids on my own.

This worked out fine, and as I always try to keep the kids moving it worked out great.  The Third practice is where we honed in on basic shooting skills.  For most introductory soccer players, the more advanced steps are not always easy to pass on.  At this practice I focused in on keeping their eye on the ball and following through as they shot.   Also, as with most practices I got and kept them moving as much as possible.

I started by having them stand next to the ball and shoot it stationary.  After each player had tried this a few times, I had them try shooting the ball by first running up on the ball and then kicking it into the goal.  Afterwards, I made it more difficult by having the players dribble the ball and then kick it into the goal.

On many development projects I've seen a similar step by step building up to completion.  A feature might start out very simplistic, or it may seem that way so we start by taking our first shot at it, just as my players might in their third practice.   Sometimes we may not understand some of the nuance to a requirement.  It may appear simple, just like striking that ball, but there are intricacies and un revealed flavoring that needs added for the code to really pull off what is intended.  So as a team maybe you work up to these features, adding a little more speed, a bit more control, and higher accuracy in its calculations.

I've found similar patterns in testing.  The first time through, you may just be poking around in an exploration of the application under test.   You may not have a full grasp of the features, how to activate or use them,  or the intent, but you build a bit of confidence and then take another test run at the software.  Then you might discover that this type of software is documented to have a particular susceptibility to one kind of fault, and begin tailoring your exploratory testing to hit those weaknesses.


The first game of a soccer season is always exciting.  Its the first time the kids are in their new uniforms, and you just never know how much the kids have absorbed from the limited practices you've had thus far.  Each year is a little bit different. One year, one team may have a very good grasp of the game and create a lot of goals in that first game.  Others might find it difficult to juggle defending the approaching ball, redirecting it to the goal they are attacking, or they may even get a little winded as they aren't used to moving so much at one time.

The first year I coached, an older coach told me, "You'll see the most improvement between the Second and Third games." I wasn't so sure how to take that, but later I realized what he meant.  Suffice it to say, many kids may not listen early in the practice.  Until they see how they can apply it in a game situation, they just may not realize the advice you are giving them.  I've seen this happen on development teams too.  A tester might make a suggestion about how to improve a process or function within the application, and might be ignored, because its simply not their job, or because the developer is too much ' in the zone' to stop and see what is being said.  There might even be, as is common in our first game of soccer, a lot of stops and starts as you build to a sustainable pace for development.

Bottom line though, remember it's just the first game.  A lot can change over the course of time on a project.  Change is inevitable in many projects, and how we handle and respond to it sets a strong light on our teams and how we cope with that change.