31 Days of Testing - Day 3: More Collaboration, Not Less

Updated: Index to all posts in this series is here! Also fixed some formatting problems.

So many problems in our software industry have poor communication at their root. The technology’s not the hardest part of our job, it’s getting clarity of expectations, dealing with roadblocks around effective understanding, and all the other human factors.

This isn’t news. We’ve known this for years. With that in mind, why would anyone think less collaboration between testers and other members of the team could ever be a recipe for a successful project?

In an earlier post the awesome Lisa Crispin said in a comment “I’d go further and say, testing is part of development, not a separate thing.”

I agree. Completely.

I firmly believe that we deliver the best possible product when testing is an integral part of the process, not a separate team, or some black hole of activity that comes after everything else is done. We want to deliver great software, and we want to deliver it rapidly to our customers with as little wasted time during that process.

Separate development and testing teams mean a lot of wasted effort around handoffs, and a tremendous amount of friction around the mechanics of that handoff. The old school mindset of “Build it and pitch it over the wall to QA” has to be avoided at all costs. Can you deliver great software that way? Possibly, but it’s at the cost of huge amounts of wasted time creating ponderous specs detailing every testing action in minutia. It’s at the cost of unnecessary, repeated cycles building software that’s handed off to QA only to be kicked back because there were misunderstandings about what was to be built, or what was to be tested.

I’ve seen this waste personally in environments I used to work in. I see this waste when I talk with folks in the community who still work in or around such environments. I see this waste when I talk with customers during demos, site visits, and training.

You can NOT convince me you can do a better job delivering the best possible software as quickly as possible at the lowest cost possible if you’re working with separate testing and development teams. Go ahead and try. I’ll plug my ears and yell “LA LA LA LA LA I CAN’T HEAR YOU!”

Without exception, the smoothest, fastest, best releases I’ve seen have been where testing is an integral part of the development process. There are no separate QA and dev teams. It’s one team—or at least as close to one team as possible.

Goals of Collaboration

Why do we care about good collaboration on our teams? It’s not a specious question, honest! Ask what the goals of your collaboration are. It’s a good exercise.

Here are some of the things I’ve learned over a few years in the workforce.

Build better stuff!

I care about building great software. I care about helping others build great software. Great software helps our clients solve real world problems and in some cases even save lives! In my previous job at Telligent I was part of a team that built software used by aid agencies rolling in to Haiti and other natural disaster sites. Our platform was helping those agencies coordinate emergency aid to help folks wiped out by earthquakes, tsunamis, etc. Wow.

Other testers help teams deliver software running medical devices. I’m a diabetic and my life is in the hands several times a day of the folks who built and tested the equipment I use to test my blood sugar and dispense the insulin I need. If either of those are off then I can drop in to a diabetic coma and die.

On a less dramatic scale, software we build and test helps move millions of people around the world through travel systems. Software we build and test enables my son to play Angry Birds during really boring long car rides.

The chance of creating wonderful systems is dramatically improved if we can boost our collaboration and increase effective communication among our team members. That may sound like marketing hyperbole, but it’s not.

Waste, in the Lean sense, happens when we spend too much time repeating work because goals weren’t clear. More collaboration, especially early in the game, lets our teams have a better understanding of what it is we’re trying to build, and how the testers are going to bash it around.

Less waste is a Good Thing.

Reduce handoffs

Along the same line, more collaboration can reduce waste incurred during handoffs. Every handoff incurs some waste since there’s context switching and ramping up involved. There’s increase in miscommunication. Contrast that with effective flow of work items through your chain with good discussion at all points.

Handoffs equal waste and opportunities for miscommunication. Reduce those handoffs as much as possible.

Reduce stress

Great collaboration and communication reduce stress, pure and simple. Less miscommunication, greater clarity of purpose. Smooth running teams have less stress, and if that’s not a great goal then I don’t know what is.

Developers and testers learn more about their domains

Improving your teams’ skills ought to be one of your prime goals. More collaboration means your developers start to pick up on more on handling things testers will be bashing up. Your testers learn more about how the system’s actually working. All this knowledge transfer is a beautiful thing.

What to Collaborate On?

If you weren’t already a believer, hopefully I’m swaying you to my view that more collaboration is better. So now what do we start to collaborate on as we move to a more integrated team? This list could be really huge, but I’m focusing on two items.

Acceptance criteria!

Target number one: Get your PMs/stakeholders, developers, and testers sitting down at the same table (virtual or otherwise) and get them discussing what great acceptance criteria are for each work item. Do this as early in the cycle as possible. The acceptance criteria shouldn’t be a huge dramatic spec, but your team does need to figure out what works for them. I always try to keep to the metaphor of bullets on a 3”x5” card, regardless of whether we’re using TFS, Unfuddle, or some other system.

Testabilty

Target number two for close collaboration: Testability of the system. Lots of conversations can help ensure the UI is being appropriately built to help support automation through functional tests. Lots of element IDs at appropriate spots, less convoluted DOM structures, less “clever” but messy Javascript that can potentially cause problems.

Close collaboration at this area can also help with developers starting to build up supporting frameworks for automation – service layers to help do basic CRUD operations to help set up prerequisites for tests, for examples.

Evolve a process and environment that promotes collaboration

Work hard to get your team collaborating, and build an environment that empowers them to do so.

Get your team as close together as possible, physically in the same room as possible. Look to creative ways to bring virtual members as close together. (Lisa Crispin’s team has one remote worker. They use a rolling desk with a monitor, speakers, microphone, and webcam to get that worker involved in nearly every aspect of their team’s work.) If you aren’t already, get your team using daily standups to help boost communication between your entire team. Get retrospectives going so everyone can help tweak things to create a better process and environments.

By all means, get your developers and testers pairing on a regular basis. The pairing doesn’t need (necessarily) to be all day every day, but it needs to be frequent and regular. That’s where you’ll find the best gains in how your developers are looking at the system they’re building, and how your testers see the overall system.

At the end of the day, the best single action you can do to boost collaboration is to stop referring to testing as a separate action. You don’t have a development team and a testing team. You have one team  that’s building great software to help your customers do great things.

31 Days of Testing: Day 2: Setting Expectations

Updated: Index to all posts in this series is here!

Updated again: Fixed some really ugly formatting. Sorry, folks!

We folks in the software industry talk a lot about the importance around setting expectations as we move through a software project. Too often those expectations are only discussed in the context of the system we’re delivering; setting expectations in the context of testing that system too often gets left at the sidelines. (I’d make a vehement argument that you shouldn’t be separating those contexts, but then this post would take me a year to write. Go with me on this, ok?)

Projects with unclear expectations are at an extremely high risk of failure. Take the same care of setting expectations around your testing efforts as you do with expectations of the system itself. (Better yet, have those as one combined discussion—because that’s really how it should be!)

What’s the goal of testing?

No, this isn’t a silly question. Putting the question of “What’s our goal with testing?” out on the table really helps get the team, including management, gelled around who/why/how much.

Here are a few different goals I came up with. It’s not a comprehensive list, but it’s a conversation starter:

Heal customer relationships/Improve perception of company

It happens. Your team/organization/company has done a poor job and you’re now paying the price with irate customers, bad press, and dropping revenues. Yes, poor quality does pay off in the negative sense over time. Now you’ve got to pay the piper. If you’re at this spot it’s not necessarily a bad thing. Someone high up in your food chain has likely figured out the damage that’s been done and is giving some support for changing things. Look at it in a positive light, although you’ve certainly got lots of work ahead of you!

Cut cost of maintenance?

Bugs kill. They’re costly to fix after they escape into production. Preventing bugs from ever being written is the best option. Catching them early in your project is nearly as good, and loads better than fixing after you release.

Identify risk

Zero bugs is an admirable goal, but it’s simply not possible for many teams. (Yes, there’s a sad note of surrender there.) Perhaps your team’s goal of testing is to at least identify for your product owners/stakeholders the level of risk for the software’s current state. At the end of the day the business side of the house needs to be able to make a business decision of “Can we ship this product as is, or do we need more work?” Testing helps identify and clarify the risk.

Fakery: Appearance of quality

Ouch. Yes, this happens. I’ve been in these environments and have left them. Poor companies/organizations use their testing team as a scapegoat or pointless mascot for their awful environments and development practices. “Yep, we’re solid with quality! We’ve got two testers for our 30 developers, and we’re committed to quality!” There’s just no nice way of putting it. Sorry.

Building great software

The best goal is that organizations want testing as an integrated part of their development processes because they simply want to ship great software that works and helps customers solve their problems.

Do an inception deck so everyone’s clear on the goals!

The awesome book Agile Samurai has a tremendous section in it on creating an Inception Deck. I highly encourage you to buy a copy of the book and have a look through that section.

The Inception Deck is a byproduct of a one or two day long workshop where the team lays out clear goals for the project, among other things. You end up with a great concise set of slides which clearly state goals for your project.

These sorts of goals need to be up in your team’s work areas, because these can greatly help keep everyone reminded of where testing fits in the picture, and what the overall goals of the project are. That’s a great head nod to the level of commitment you’ll need for a successful integrated testing effort.

One of the best points in Agile Samurai: Post the deck on a wall in the team area so everyone can see it!

Once you’ve done that, make sure you, your team, and your stakeholders/customers are clear on the many things you’ll need for a successful project. This list is of course focused on the testing-related things!

You’ll need time

Yes, testing requires time. Surprise! You’ll need time for a great many things relating to testing. Time to learn new skills and get through proficiency to mastery. Time to fit your testing into your existing processes, or to create new processes. Time to evaluate and update those processes. Time to learn new tooling you may be making use of. (Yes, even Test Studio, which I’m immensely proud to be a part of, requires time to master.) Time to set up that tooling and infrastructure.

Most of all you’ll need time for doing the work! Testing does add up front time, be it some form of developer-level testing (unit, integration, etc.), or the tester’s final checks. More time up front, dramatically less time after you’ve released. Sometimes that is a tough sell to folks who are too focused on the immediate timeframe.

You’ll need money

You have to set expectations around the cost of testing. Yes, there’s a cost, and it’s not trivial if all you’re focused on is what you’re paying today instead of focusing on the overall cost of the project. You’ll have increased headcount as you hire on new testers to your team. You’ll have increased costs for more infrastructure—that overloaded build server isn’t the right place to be hosting those long-running, intensive integration and functional tests—and you’ll need additional systems for those new team members.

There are costs for new tools, too, either explicitly if you’re buying something like Test Studio, or implicitly if you’re using one of the many great open source tools. (By “implicit cost” I mean the cost of getting up to speed and mastery of those tools.) There’s also an additional cost in the sense of the time it takes you to get those tests built, running, and maintained over time.

You have to be open and frank about the monetary costs of testing. It’s absolutely worth it, but get everything out in the open at the start so folks aren’t surprised later on.

You’ll need long-term, honest commitment

Testing requires commitment by everyone on the team at all levels. Every role from PM through dev and tester through stakeholder has to accept the many things I’ve laid out above—and they’ve got to commit to supporting the team. There will be times when management pushes back on time and resource commitments around testing. You and your team have to figure out when to fight that and when to realize that business has its own set of needs and that middle ground is an acceptable place to be.

Just remember the most important goal: Building great software that helps your customers do great things.

Development is part of that goal. Testing is too!

31 Days of Testing: Day 1: The Kickoff

I’ve seen a number of blog series over the last year or so along the theme of “31 days of <xxx>” where <xxx> is the technology/framework/whatever of the day. I thought I’d pile on with my own series of “31 Days of Testing” because you may, by now, have an idea about how important I think testing is…
Over the next 31 days I’ll be hitting a broad range of topics. Many of the follow on posts will be general or high level, although I’ll be diving in to some more technical aspects when it comes time to cover things like mocking, data setup, etc. I’m kicking this off somewhat spur of the moment, so the flow of the overall series may be a little disconnected and clunky. Sue me.
Some of the broad themes I’ll be covering include

• Building a culture and team that cherishes testing
• Building testing skills and team collaboration
• Different kinds of automated and manual testing
• Avoiding brittle, unmaintainable tests
• Infrastructure for testing
• Keeping your tests running quickly
• Keeping your tests focused on value
• Deciding what to test and what to automate
• Why *DD isn’t about testing, it’s about development

I’ve had a couple pals offer to write articles for the series, so I’ll be cross-posting or linking to content elsewhere when those posts come up—I’m lucky to have a network of smart folks to leech off of!
I’ll keep updating this specific post with links to follow on articles as I post them.
Do feel free to add in suggestions for topics. I’ll refactor as I go based on customer (reader!) input.
I hope you enjoy the series. I’m looking forward to it!

 

UPDATED: Here’s the index of posts in the series!

1. Day 1: The Kickoff (like, this post)
2. Day 2: Setting Expectations
3. Day 3: More Collaboration, Not Less
4. Day 4: Sustainable Pace, Sensible Flow
5. Day 5: Choosing What To Test
6. Day 6: Types of Automated Testing
7. Day 7: Automated Test Basics
8. Day 8: Pay Attention to Your Tests’ Setup!
9. Day 9: Readable Tests
10. Day 10: Mocking Out Dependencies
11. Day 11: Maintainable Functional Automation
12. Day 12: Functional Test 101
13. Day 13: Functional Test 201 (Common Problems)
14. Day 14: Tests as Specifications
15. Day 15: Cucumber is Not A QA Tool
16. Day 16: Testing Web Services
17. Day 17: Rules for Effective Data-Driven Tests
18. Day 18: Baseline Datasets
19. Day 19: Refactoring a “Monster” Functional Test, Part 1
20. Day 20: Refactoring a “Monster” Functional Test, Part 2
21. Day 21: Data Driving Your Functional Tests
22. Day 22: Why Collaboration Matters (A Real World Example)
23. Day 23: Acceptance Tests & Criteria in the Real World
24. Day 24: Getting Serious About Performance
25. Day 25: Performance Testing, Part 2

Combinatorial / Pairwise Tools

I’ve recommended combinatorial or pairwise tools frequently in my Automation Isn’t Shiny Toys talk. I think it’s a great way to cut down large matrices of input data or configurations. These tools can save you incredible amounts of time – as James Bach mentions on his Allpairs blurb, you can potentially cut 10,000,000,000 test cases down to 177.

Them’s big apples, folks.

Here are a few of the resources I’ve mentioned in that segment of the talk:

• Pairwise.org. A great starting place to learn about combinatorial or pairwise testing.
• Allpairs. Nifty Perl script from James Bach.
• ACTS. Another nice tool from the National Institute of Standards and Technology. It’s freely available, but you have to ask.
• MbUnit. Lovely test framework for the .NET platform which has combinatorial features built in!

I encourage you to do a bit of reading on the subject and see if it might be helpful for you!

Update: I totally forgot to mention Hexawise, an interesting tool/service. I haven’t personally used it, but I’ve read up on it and follow founder Justin Hunter on Twitter. Interesting pricing model, too.

Umm, Why No, There Aren’t Any More CodeMash 2012 Tickets

If you blinked this morning then unfortunately you’re likely out of luck.

CodeMash 2012 sold through 1200 tickets in 20 minutes.

We on the CodeMash staff are stunned at the excitement and passion our attendees show. Thanks for helping us make this an awesome conference!

CodeMash 2012 Registration Opens Today!

What’s special about October 24th? One should look no further than http://www.InfoPlease.com/dayinhistory/October-24. There you’ll find that in 1901 Anna Edson Taylor was the first person to survive going over Niagara Falls in a barrel. Her Wikipedia page leaves out a little-known, but extraordinarily important fact: she went over the falls, driven mad by having to program in COBOL.

Please, PLEASE, do not let the same thing happen to you. Keep your skills sharp and on the cutting edge. Keep yourself aware of the important things happening in the IT industry, and keep yourself tied in with great networks where you can find wonderful opportunities to keep you engaged, empowered, and motivated – and out of a barrel going over Niagara Falls.

CodeMash 2012 registration opens today at 10:24.

Do NOT delay or fool around. A barrel and ignominy awaits those who miss out.

Know a Diabetic? Help Them (Us!) by Supporting the Artificial Pancreas Campaign

Type 1 diabetes sucks, plain and simple. I won’t bother you with more details than that. Just take my word for it, T1D sucks—and my situation is relatively stable and very controllable compared to many other diabetics I know. Plus, I got my T1 when I was well in to middle age rather than at a very young age. If you’re interested in learning more, then hit any one of the many solid websites on the topic.

What I will bother you with is a request that you help try to sway the Food and Drug Administration’s opinion on speeding up progress around development of an artificial pancreas. (The pancreas produces the body’s insulin – it’s the organ that goes haywire for us diabetics.)

The Low Glucose Suspend (LGS) insulin pump, a precursor to an artificial pancreas, is currently in use in over 40 countries, including Canada, England, France, and Germany. Unfortunately, the FDA blocks diabetics in the US from using the LGS.

The Juvenile Diabetes Research Foundation is sponsoring a petition to send to the FDA encouraging them to move forward with adopting recommendations from industry experts. Adopting these recommendations would result in the FDA approving clinical trials around this sort of device.

The FDA is set to issue its guidance on 1 December, so there’s not much time to sway their opinion. Please take a few minutes, think this over, perhaps do some research on your own, and then go sign the petition if you believe it’s worthwhile.

If the same device is approved in 40 other nations, why in the world shouldn’t diabetics and medical researchers  here in the US have access to it? (Please note that depending on what sources you read from, the FDA isn’t actively blocking use of these devices; it just appears they’re not moving forward with approval in a timely fashion.)

Video of my Selenium Talk from Rocky Mountain Ruby Posted

Back in late August/early September I spoke at the Rocky Mountain Ruby conference in Boulder, Colorado. My talk was about lessons learned dealing with large functional test suites over my career. For example, at a previous job I ran a team that got up to 9,000 Selenium tests scattered across roughly 850 test fixtures. I’ve had similar experiences working on other projects too.

The talk was videotaped and is now up on the Confreaks video hosting site: Surviving Growing from Zero to 15,000 Selenium Tests. Yes, the talk’s title is wrong. I goofed when submitting it.

The fundamentals I lay out in this talk span all test tools and frameworks, so it doesn’t matter if you're writing your tests in Selenium or Watir, or using QTP or Visual Studio. Early in your automation effort you’ve got to address basic problems such as long-running suites, brittle tests, and focusing on automating only the most valuable, critical aspects of your system.

(I like to think that Telerik’s Test Studio helps you navigate these issues a little more easily but 0) I’m biased and B) you absolutely still need to use your grey matter and think about this stuff as you’re doing it!)

This talk was the genesis for my “Automation Isn’t Shiny Toys” talk I’m giving a number of times over the next few months. I’ll be writing up a number of blog posts around this both here at FrazzledDad and at my Telerik blog.

I’d also recommend you watch the Testing Panel discussion from the same conference. I sat on that panel with three other really smart folks and there’s a lot of tremendously useful information on it.

Upcoming Speaking Engagements

Updated AGAIN: I’m also giving my Intro to Unit Testing talk at the Cincinnati Financial User Group on 10/12.

Updated: I had the wrong date for speaking at Dayton! I’m doing that talk on 10/26!

I’m on the road a fair amount over the next couple months talking about maintainable automation and how to keep your sanity while moving forward with it. Here’s where I’ll be at between now and Thanksgiving. I’d love to see you if you’re in the neighborhood!

Name	Date	Location
StarWEST	10/6/11	Anaheim, CA
Cincinnati Financial User Group	10/12/11	Cincinnati, OH
DFW QA Association	10/18/11	Dallas, TX
Dayton .NET Developers Group	10/26/11	Dayton, OH
DevConnections	2-4 Nov	Las Vegas, NV
Agile Testing Days	11/15/11	Berlin, Germany

Three Book Reviews

Updated: Fixed the title which referenced two books when I’m actually reviewing three. Would have caught that off by one error had I written a test first…

Three long-overdue book reviews!

Debug It!

Debug It!: Find, Repair, and Prevent Bugs in Your Code by Paul Butcher, published by Pragmatic Press. ISBN 193435628X. This, coupled with David Agans’ Debugging, is a must-have on a programmer’s bookshelf.

Code goes wrong, systems get tetchy, and you need a logical approach to dealing with problems. Butcher’s book lays out lots of great tips and practices for finding, fixing, and preventing bugs in your software. I love his emphasis on empirical, measured approaches to troubleshooting, and I also like that he draws a clear border between finding and fixing bugs. You really do need to step back and take a breath after you’ve found a pesky bug, because you’ll want a different approach for fixing it and preventing other similar bugs.

“Debug It!” puts a great emphasis on controlling the environment and isolating one thing at a time as you work through finding bugs. Butcher’s sections making nondeterministic bugs deterministic and his logical steps for approaching bugs are wonderful. I also LOVE that he emphasizes, strongly, that the debugger is a tool of last resort. An important tool, but one to use only after you’ve exhausted other avenues. (I’m a firm believer the debugger is a time sink. Manually stepping through code is a horrible use of your time.)

Butcher covers a great many topics from the team’s culture to methodologies. Along the way he offers insight on tracking your bugs, practical tooling advice around assertions, and finishes up with a great section on Anti-Patterns. Here you’ll find some great reading around culture (had to work with a Prima Donna, anyone?), methodologies, and team culture (Code Ownership, FTW!).

This really was a tremendous book, and I highly recommend it!

The Manga Guide to the Universe

The Manga Guide to the Universe by Kenji Ishikawa, et. al. Published by No Starch Press. ISBN 1593272677.

I’ve gotten several Manga Guide to… books and they’ve all been wonderful. The Universe guide is no exception! The book’s comic-style is entertaining, although I could do without the weird females-as-sex-objects undertone, and the authors have done a great job bringing some really arcane, difficult topics to an understandable level.

The book weaves its education of the reader around a central plot where three girls are trying to write and create a school play. Their attempts to flesh out their storyline bring them in to contact with a number of other characters, each giving different insights into astrophysics, astronomy, and the historical evolution of science and theory in these domains.

I greatly enjoyed the historical aspect of the book – learning how scientists like Kepler, Galileo, and Copernicus made their discoveries is really fascinating. The book’s main storyline is interspersed with a lot of great sidebars on these practical matters in both historical and current contexts. You’ll read about how ancients attempted to measure distances of solar bodies, what dark matter is, how the universe was formed, and what scientists are working on currently.

This is another great addition to the Manga series, and I’m very happy to have gotten it!

The Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson, Pragmatic Press. ISBN 1934356581.

I get many free books for review – this is one I paid for out of my own pocket and it was worth every penny. Clear, well-written, and extremely useful. This book stays very focused on what matters in building a successful agile practice without being preachy or vague.

Rasmusson doesn’t pull punches on silliness around “agile” being some silver bullet. He’s pragmatic and practical – and blunt when discussing schizophrenias like management by miracle (an unrealistic plan has a miracle event which results in working software. Yeah, that happens often!).

He’s also hard-nosed (in a gentle way) about the fundamental problem in any software project: poor communication. Consider this beauty from Chapter 3:

Q: What kills most projects?

A: The assumption of consensus where none exists.

Much of his book (well, so much of “agile,” really) is about ensuring clarity of communication.

Rasmusson walks you through a Project Inception workshop to “Get Everyone On the Bus” then moves on to the other standard agile topics. He does a wonderful job explaining user stories and estimation—one of the better jobs around points I’ve ever read—and he lays out a nice clear picture of why and how you should set up a visual workspace.

The book finishes up with a nicely done section on building the software. Rasmusson walks through the standard fare of test driven development, refactoring, technical debt, and continuous integration. If you’ve read much about agile you’ll likely not learn anything in this section, but its tone and content is every bit well done as the other sections.

I’ve read plenty of books on Agile. This one’s definitely in the top three.

Join NW Ohio .NET User Group for Their 10th Anniversary!

The great Northwest Ohio .NET User Group in Toledo is celebrating their 10th anniversary on Tuesday, 9/20. Richard Campbell will be presenting at their meeting, and rumor has it they’re having BBQ to top things off!

If you’re in the area I encourage you to head over and join them in celebrating their great milestone. Register at Eventbrite to help them keep an accurate headcount.

Maintainable Tests: Keeping Your Test Cases Focused

Maintainable and performant test suites are somewhat my addiction right now – simply because I’m finding more and more and more folks in every domain running in to the same sorts of problems: brittle, long-running test suites that end up sucking the life and morale out of teams.

Before you dive into a new project, or as you’re rethinking an approach to an existing one, take some time to consider what your test suite will evolve to look like. I’m not talking just unit tests, I’m talking your full stack of tests: unit, integration, functional, and perhaps even performance.

I’ve got a number of topics I’ll be writing on over a few posts, but this particular post centers on an easy win: keeping your test cases focused on what you really need to test. This means you need to cut out any unnecessary steps or UI goo that don’t pertain exactly to the functionality you’re testing.

In my Surviving Growing from Zero to 9,000 Selenium Tests talk at Rocky Mountain Ruby, I used an example of testing that User B can reply to a forum post from User A.

“As a user, I want to reply to another user’s forum post, so that I can create a conversation”

There are any number of things which don’t pertain to that test, including things like:

• Can User B log on to the system?
• Does User B’s name show up when she’s logged in?
• Can User B browse to User A’s forum post?
• Can User B properly format bold, italic, and hyperlink text in the reply?

Logging in to the system and browsing to User A’s original forum post might take you ten seconds, plus you need validation checks that User B actually did log on. If you have 800 test fixtures, and logging on and navigating to a point in your system takes 10 seconds for each test fixture, then you’re looking at 8,000 seconds just for that effort. 8,000 seconds / 60 seconds per minute gives 133-ish minutes.

That’s two hours of time spent just getting to the place where you need to actually do your test. Worse yet, if you have any problems with your logon or navigation functionality then you’re going to have false failures for those areas which masks potential failures in your post-a-reply functionality.

Look carefully at your system and see how you might be able to bypass those particular authentication and navigation issues. Maybe you can store a generated cookie for User B, enabling you to completely skip the logon process. Perhaps you can figure out how to navigate directly to User A’s forum post instead of using your system’s browse/search/whatever navigation.

Taking these steps can greatly reduce the brittle and slow nature of your tests.

Next let’s consider how you actually enter the text for that reply. Are you using a rich text or some other fancy editor? How does that editor render on your page? Is it locked in some iframe or other odd element that’s difficult to point your automation framework at?

Perhaps your system has an alternative editor that’s simpler to deal with.  If that’s the case, look to use that simpler editor instead–you’ll find your tests for interacting with content become much cleaner and easier to maintain.

I’ve talked with developers who’ve created completely different configurations for their automated testing runs where entire slices of functionality get cut out in order to simplify testing of other discrete, controlled areas.

These sorts of concepts—cutting out unnecessary steps and eliminating irrelevant functionality—pay off in spades as you continue evolving your test suites. Look very hard at each test case as you’re fleshing it out and ensure you’re not biting off automation of steps you don’t need to.

Please note I’m not telling you to skip testing your logon and browsing functionality. (Or whatever it is you decide to cut out.) You’ll definitely need to test those bits and pieces, but you can do them in isolation instead of throughout the rest of your test suite.

Keep your test suites running as smoothly as possible by staying focused on exactly what you’re trying to test. Figure out ways to cut out all the remaining cruft. You’ll be much happier.

Slides From Effective Distributed Teams Talk (Philly Day of Agile)

I’ve posted the slides from my Effective Distributed Teams talk at the Philadelphia Day of Agile up to SpeakerDeck.

Feedback on this session was extremely polarized. A few attendees felt I spent too much time covering forming the teams and what tools to look in to versus walking through specific problems around processes with distributed teams. That’s highly useful feedback and I’m considering how to possibly refactor part of the talk.

The other side of the feedback coin was extremely satisfying – there was a group of ten or so folks in the session who were highly interactive. I love these kinds of sessions where the audience dives in to the discussion with some questions and things they’ve been through. I got some wonderful input from a couple different attendees on how to get past cultural and language barriers, plus folks were great about sharing their own experiences with distributed teams.

I greatly enjoyed the chance to speak with the group, and I hope most folks got something out of it!

Rocky Mountain Ruby Conference Wrapup

Where to start? My great bosses at Telerik fully embrace some of my quirky ideas about diving in to different, new communities for us. As a result, I found myself right in the midst of a crowd of passionate Rubyists at the Rocky Mountain Ruby conference in Boulder, Colorado.

I was fortunate enough to get picked up for a session – I spoke in front of the crowd about my experiences being part of a team growing a Selenium test suite from zero to 9,000 tests. I also participated in a follow-on panel discussing testing as well as a panel discussing diversity in the software engineering industry.

I loved the format of the conference: a mix of Unconference, lightning talks, and sessions of either 20 or 30 minutes in duration. The overall conference is also single-track, so you’re able to avoid stressing about running around and deciding what sessions you’re going to miss.

My goal going to RMR was to chat up folks around long-running test suites and brittle tests. I had good fortune to get great discussions with folks I already knew and folks I’d just met. Here’s a surprise: long-running tests are an issue in the Ruby domain, too.  (Say it quietly, but they’re a problem in every domain…) I didn’t get any magic answers about solving the problem, but then I didn’t really expect to. What I did come away with were contacts to continue more detailed discussions later on.

The rest of the conference was also very rewarding. Every session I sat through was great, but there were several standouts for me.
•    Michael Feathers’ keynote. I’m sure he hears it all the time, but his Legacy Code book was extraordinarily influential for how I think about software. It was great to finally hear him speak.
•    Anthony Eden’s talk on building great APIs was tremendous. Work hard on making your APIs clear, concise, and simple. I’m hoping Anthony will submit this to CodeMash because it’s absolutely applicable to you regardless whether you’re writing Ruby, C#, Java, or Perl. Might not apply to assembly folks.
•    Jeff Casmir’s session on rescue projects hit home for a lot of reasons. The things he brought up rang very true with my own experiences, and I loved how he put out that there are many hidden costs for failed projects beyond just the financial bottom line. Rescuing a project is hard, hard work, but it can bring a set of tremendous personal rewards.
•    Justin Searls and Cory Flanigan’s talk on testing Javascript was really well presented. Paired presentations often fall flat. Justin and Cory had a unique, entertaining style that I enjoyed. (Because as a presenter myself I know how much work they put in to it.)
•    Avdi Grimm’s Exceptions talk re-re-reminded me that your team needs to sit down and hash out an exception handling strategy early on in your project. His talk was more on the mechanics of dealing with Exceptions and it was really need to see some intriguing ways you can deal with Exceptions in Ruby. I also had a great hallway chat with Avdi about development and testing in the embedded world. He corrected some of my misperceptions (based on previous work experience) about automated testing in the embedded world.
•    Mike Gerhard’s meditation talk/exercise was a wonderful way to start off the conference. He encouraged folks to do short meditations during the week and Tweet about them with the hashtag #devmed (which is developer meditation, not developer medication). I’ve used short meditation off and on to help me regain some balance during extremely stressful times in previous jobs. Mike’s session reminded me of other great benefits of meditation – you’ll be seeing #devmed Tweets from me starting next week.

The culture and atmosphere of the conference were extraordinary. I was really upset about being gimped up – I missed a lot of hiking and trail running – but I hope to be back next year and make up for that!

Thanks to the organizers for picking up my talk, and thanks to all with whom I had great discussions!

Maybe You’re Not Right and They’re Not Wrong

It may be that you’re a bit too caught up in yourself if the organization you’re trying to force change upon isn’t willing to adopt that change. If you see yourself as the one voice in the wilderness trying to move a group in a new direction, then maybe you need to look at whether or not the change you’re trying to effect is for the organization’s good, or your own sense of self-worth.

Maybe that group or organization has had some successes. Maybe they’re getting things done in a way that’s different from what you’re passionate about. Does it make them wrong? Wrong in your view, perhaps, but perhaps not wrong for that organization.

Maybe your passionate cries for change aren’t being taken as a positive thing. Maybe those cries are being heard in a completely different fashion than you intend, regardless of how many different approaches you try. Maybe instead of forming allies in your cause, you’re alienating those around you. Maybe instead of being seen as a motivating agent of change, you’re being seen as a distraction or worse a hindrance.

Maybe the organization’s also using you as a token: “Yep, at least we’ve got <him/her> around to keep us straight!” Those words are easy for people to say. Implementing the changes you’re passionate about aren’t quite so easy – but again, maybe the things you’re so passionate about aren’t a great fit for that organization.

If the organization’s not doing things that put people’s lives in jeopardy, or if they’re not behaving illegally or unethically, then perhaps you need to re-think why it’s so important for you to make them change. Maybe they really don’t need to change to be successful in their own view – and that’s completely acceptable.

Maybe in that context you’re not right and they’re not wrong.

Move on. It’s OK. Find a place where you’re not the sole voice in the wilderness. You’ll be happier, they’ll be happier.

CodeMash Call for Submissions Opening 15 September

The CodeMash call for submissions will open up on 15 September. The window will be very short this year. Make sure you don’t miss out: Get ready for the 15th!

Follow CodeMash on Twitter, monitor the CodeMash site and news feed, and keep up here for further details.

Speaking at the Philly Day of Agile

I’m going to be speaking at the Philly Day of Agile on 10 September. I’ll be giving my talk on making distributed teams work well. There’s also a lot of good content on making teams work well regardless of your location. I’m really excited because I’ve never been to Philly and I’m looking forward to meeting an entire new circle of folks from that community.

Phil’s herding the cats for this event and has a great summary of the lineup.

Please look me up if you’re attending! (Better yet, go register if you’re in that area and haven’t yet!)

IE 9 Security Settings on Server 2008

I do all my dev and testing work in a VM running Server 2008 R2. I inevitably run in to problems with the various default security settings for IE9 on this OS. In today’s incident, I was unable to get IE9 to properly render HTML 5 controls on KendoUI’s demo site. This is a problem since I’m working with Test Studio to record a few tests and it uses IE9 for recording.

Having a highly secured browser on your production boxes is a Good Thing; however, for your dev or testing systems it’s nothing but pain.

Two quick things you can do to ensure you’re able to be as friction-free as possible (well, aside from using a real browser like Firefox or Chrome, that is):

• Add the sites you’re working with to the Local Intranet or Trusted Sites zone. Tools | Internet Options | Security | Click “Trusted Sites” | Sites | Add. You can use wildcards to add entire domains.
• Turn off Enhanced Security Configuration. Start Server Manager, click the server, then Configure IE ESC (in the Security Information section). Turn ESC off for both Admin and regular users.

WARNING: You should spend a bit of time understanding what the impacts of this are for your dev/test environment, and you should never, ever do this sort of stuff on a production system.

A picture’s worth a thousand words, ergo:

UPDATED: Fixed busted picture URL. Whoopsies.

Two Important Blogposts for Functional Test Writers

Adam Goucher wrote two great posts that really lay out some critical, foundational things around functional testing, particularly with Selenium. Go read both if you do any sort of functional testing. (Or want to.)

Implicit Waits – understanding how and why Selenium handles waits is important. This post is particularly focused on Adam’s Py.Saunter project, but the crux of the matter is important regardless of whether you’re using Selenium, Watir, or Test Studio. (Shameless plug.) Awesome money quote:

“One of the key benefits of doing functional automation is you, the script creator, gain a greater understanding of the application being automated”

The Great Locator Debate – it’s crucial you define your locators in one and only one spot. Adam walks through pros and cons of defining those locators Globally or Locally in your Page Object class. Money quote:

“The coupling of the locators with the Page Objects should be a tight one and the desire to break that model should be a trigger that perhaps your object model is not as complete as you thought it was.”

Go read both posts.

(And subscribe to Adam’s blog while you’re there…)

Considering Attending STARWEST? We have Discount Codes!

Are you considering attending STARWEST, one of the premiere software testing conferences? My employer Telerik has a discount code that can help you save a good amount of money off your tickets!

If you're interested please contact me via e-mail at work and I'd be happy to pass the code on -- no strings attached, and no, I won't add you to some mailing list! My e-mail is Jim DOT Holmes AT Telerik DOT com.

Cross-Posting With my “Work” Blog

A significant part of my new job at Telerik’ involves writing a fair amount of content for my blog at Telerik, plus creating regular webcasts.

I don’t want to cross-post everything from that blog here, but I do think there are a number of things I’ll be writing about which have applicability to folks who read this blog.

Moving forward I’ll be trying a number of things including posting full articles both here and “there,” or just posting simple announcements here (“I posted something on <xxxxx> at Telerik. Go read it if you’re interested.”)

My goal is to avoid making this blog seem like a shill spot; however, I believe there’s some good value to the things I will be posting over there.

As always, I’m happy to hear feedback from my readers. Let me know in the comments, via e-mail (see contact link on the sidebar), or via Twitter.

Updated: Thanks to the comment from Jay, I’ve updated my work blog with an RSS feed. Sorry for the oversight!

Renaming a System Running SQL Server

I do all my dev and testing work in VMWare virtual machines which I clone off of a baseline image. I rename those new images based on their usage, and I constantly forget how to handle renaming the SQL Server instance.

Ergo, in order to make it easier for me to find the info next time I do it: here is the MSDN article showing how to do this.

Want to Improve/Change Your Career? Get Hooked up in the Community!

Are you hesitant about getting involved with professional communities in your area? Get over that hesitation and dive in. Or at least get your foot in the water.

Community involvement rewards me in many ways: I’m around smart people who love to share their knowledge, I find new ways to solve problems, I get energized by those same people, etc., etc. (I also get lots of great bacon at CodeMash.)

If that’s not enough for you, consider the simple fact of how involvement you’re your professional community can impact your career opportunities. All four of my last jobs have come directly because of my involvement with the Heartland community. Let me run those short stories by you so you can get a picture of just how my participation in the community helped.

I left the workforce in 2005 to be a stay at home dad. During this time I wanted to stay current with things in the .NET world and I got sick of driving to Columbus to their .NET group, so I started the Dayton .NET Developers Group. I worked with James Avery and kicked off the Dayton-Cincinnati Code Camp, one of the region’s first software conferences for any community. Because of this work (and my blogging and co-authoring Windows Developer Power Tools) I was awarded my MVP status from Microsoft. In the space of just a short year I’d grown a tremendous network of really smart folks who were passionate about the same things I was.

Community contact job 1: When it came time to re-enter the workforce in 2006 I spread the word I was looking for work via a blog post. Within two hours I had three contacts, one of which was my community pal Chris Woodruff who referred me in to NuSoft where I landed a position as a principal consultant.

Community contact job 2: When it became time to move on from NuSoft I reached out to my community pal Brian Prince who was running the Solutions Practice at Quick Solutions in Columbus. Brian had a great group of folks working from him who were all heavily involved in the Heartland’s developer community, and I knew it would be a wonderful opportunity. We met for lunch on Wednesday and on Friday I had a job offer in hand. Brian was the only person I reached out to for my search.

Community contact job 3: Life at Quick Solutions was terrific; however, it was a minimum of a three hour commute each day and that was just too much impact on my family life. I reached out to a couple community contacts, but my main lead was through two more Heartland community homies Dave Donaldson and Leon Gersing. They hooked me up with Telligent where I had a great run of various accomplishments. I can’t recall how many different people I spoke with about opportunities, but I am fairly sure it was no more than three or four. All were folks/companies I knew through my community network.

Community contact job 4: My new position at Telerik also came about through community contacts. I learned about the test tools division at Telerik by chatting with a few folks at a couple conferences, and I started looking in to the tools and frameworks. I reached out to one pal at Telerik and inquired about opportunities. One thing led to another and soon I was sleeping on the floor at Chicago’s O’Hare airport after having flown down to Austin for a face-to-face interview with the testing tools folks. (No, Telerik didn’t make me stay overnight in an airport; serious weather issues diverted me to an epic journey to get home in time for work the next day.)

---

There you go. My last four jobs, all through community contacts. Not once did I use Monster.com, Craigslist, or a recruiter.

Here are some specifics about why you as a job hunter should look to community contacts:

• Better chance of finding open opportunities. You’ll hear about neat opportunities before they’re posted on job boards, etc. Moreover, you may find companies willing to make openings for you if you’re a good fit for them.
• Better chance of getting past screens. Personal referrals count for a lot with companies, and your chances of getting past initial screens and actually landing an interview are much higher.
• Better chance of a good fit. Since you will know those community contacts, you’ll have a better understanding of the potential employer’s culture, mindset, and staff. That exposure over time is a much better picture than you can get during a short interview process.

Community involvement is a wonderful thing for oh so many reasons; however, if for no other reason, get involved so you have a better channel to protect and advance your career. The bright, passionate, engaged folks you really want to work around are all deep in to the community. Hook up with them. It will help you and your career.

Follow Up to Maintainable Automation

During my first-ever webinar with Telerik this week I spoke briefly about learning how to keep your tests maintainable. This is something near and dear to my heart – I’ve been on a number of projects where we’ve had to suffer through test suites which became ever more brittle as time went on.

Brittle tests break frequently due to unrelated changes in the system’s workflow, UI, or business rules. Of course, tests should fail when something directly relating to the test is broken—that’s why we have the tests!—but one change to a web page unrelated to the specific area you’re testing shouldn’t completely derail that test. Brittle tests duplicate workflows and UI locators across many tests, forcing you to change hundreds or even thousands of tests when one webpage changes its layout. Brittle tests are overly complicated and have too many complex setup steps.

Brittle tests are the testing world’s equivalent of technical debt, shortcuts taken during development which end up causing you grief further down the road. Eventually the project team ends up spending a large amount of time simply cleaning up broken tests—and getting less and less work done around delivering value to the team’s customers or stakeholders. This can even lead to the team abandoning test automation completely, or worse.

Roy Osherove opens up his tremendous book “The Art of Unit Testing” with a very frank discussion of a project of his which failed because the team’s tests turned into a convoluted mess. Note they didn’t just abandon testing, the entire project failed. The team was spending more time trying to fix broken tests then they were delivering value to the customer, and the project tanked because of it.

Avoid this sort of drama by starting out your testing work with maintainability in mind from the beginning. Keep in mind the three major causes of brittleness in larger test suites:

• Large suites taking too long to run
• Changes to common workflow (such as logons) breaking multiple tests
• Changes to UI elements breaking multiple tests

Tests Taking too Long to Run

UI-driven tests will always be orders of magnitude slower than unit tests. As you reach hundreds or thousands of UI tests you may find your tests taking many hours to complete. You’ll find yourself unable to have regular, frequent execution passes of your functional tests, instead relying on everything to get run once a week over the weekend. Long-running test suites can lead to a mindset of ignoring the tests because feedback doesn’t happen until days later.

Solve this with two different approaches. First, look to scale out your test infrastructure. Get your tests running in parallel on multiple systems using some form of test runner agent. Selenium, in both its v1 and v2 incarnations, supports this through Selenium Grid, or you can look to splitting up tests via your own customized test runner. If you’re using Telerik’s Test Studio you’ll benefit from our combination of Scheduling and Execution Servers to do this for you.

Secondly, look to split out your large suites and pull out a minimal set of Basic Validation Tests (BVTs) to check only the most important set of features. These BVTs should check only fundamental operations like:

• Does the home page load
• Can a user log on
• Can a user create/retrieve/update/delete content

Using BVTs lets your team quickly execute a safety net of functional tests before making major commits, and you can also have these BVTs running on a much more frequent basis if you’re using some form of automated build or continuous integration. (And you should be!)

Use both of these approaches together to help deal with your long-running test suites.

Workflow Changes Breaking Multiple Tests

Your tests should focus on one discrete piece of your system’s functionality, i.e. does entering an invalid customer number display an error? However, your test will likely need to take other actions as a prerequisite—logging on to the system and navigating to the customer record area, for example. These prerequisites are likely common across many of your tests, and this can make them a significant risk for increasing complexity and brittleness.

These sorts of common actions need to be pulled out in to separate areas of your test suite so they’re defined once and only once. That way if your logon workflow changes (say you’ve added an additional requirement to input a value from a keyfob) you only need to update the workflow in one spot.

If you’re using Telerik’s Test Studio you can make use of our test-as-step feature to separate these common pieces out in to modules. If you’re working in Selenium, Watir, or some other testing framework then you can separate this commonality in to separate helper methods.

The main point of this is exactly the same as the software engineering concept of the Don’t Repeat Yourself (DRY) principle: Define functionality in one spot and one spot only.

UI Changes Breaking Multiple Tests

Changing UI can also wreak havoc with your tests. Element locator values (element IDs, XPath, CSS locators, etc.) will likely change if the UI is reorganized – and all your tests depend on being able to find those elements based on those locators. If you have your locators scattered through hundreds or even thousands of tests then you’re in for a sad time updating them after the UX team moved a widget from the right side of the page to the footer.

Mitigate this problem with the same concept I wrote about for workflow: Keep critical information in one and only one location in your codebase.  Use the same DRY principle for your locators.

If you’re using Selenium, Watir, or some other coding-based framework, then spend some time getting familiar with the Page Objects pattern. This idea has you create a separate class for each page you’re interacting with in your system. The locators are defined in each class, and the rest of your tests refer to or consume those page object classes. If something changes on the UI, you simply go back and modify that single page object class and all your other tests remain unaffected.

Telerik’s Test Studio helps with this as well by using our element repository. Elements you interact with are stored in one spot within Studio’s infrastructure. If an element’s locator changes it’s a simple thing to update that element to the new value – and you do it in one place only.

Wrapping Up

Automated tests are wonderful and I’ve been pitching (and practicing!) what I preach for years. That said, you have to approach your automation efforts with an eye to maintaining your suite over time. A long-term automation strategy isn’t just about writing great tests that help you deliver awesome software, it’s also about keeping your sanity as your software and tests evolve.

My New Job at Telerik!

I'm tremendously excited to announce my new career change: as of today I'm Telerik's newest evangelist!

I'll be spreading the word about Telerik's great Test Studio set of tools and their backing framework. Even more importantly, I'll be spending a great amount of time interacting with testers and developers across a number of communities! I'm really looking forward to being able to spend time talking with testers who are doing both manual and automated testing, and figuring out where we can help.

This new position really ties in to a number of things I'm passionate about: testing (of course), getting out in communities, interacting with folks to find out what works and what doesn't in their environments, speaking, writing, the list goes on. Test Studio speaks very dearly to me, having been through the wringer with leading a team writing a large suite of Selenium tests. The toolset offers up some really wonderful approaches to helping teams work through web and WPF automated testing -- and there's a LOT more coming down the pipe!

I'm very, VERY excited to be on board with Telerik. I'd interviewed with them five or so years ago, but chose a different path at that time. Thankfully they were still interested in me after all these years! Telerik's well-known for their community involvement; something that drew me to them years ago -- they were also the first sponsor of the Dayton .NET Developers Group, thanks to an introduction from Joe Kunk.

There will be a lot of exciting things going on, including me getting to spend a significant amount of time back doing technical work instead of leading a team and herding cats outside of that. I was extraordinarily fortunate to run a tremendous team of seven folks in my previous position; it's going to be equally as wonderful focusing my energies on creating content, helping educate folks, and best of all, LEARNING for myself.

Telerik has a great group of people working for them, and I'm honored to be among them!

Goodbye Telligent

Today’s my last day at Telligent.

I’m moving on to a very exciting position that hits a lot of my core passions, but I’ll leave that for a separate post come Monday. (And it will, shockingly, be made from a Mac… )

Telligent’s been a great place to hang my hat for the last 2.5 years, and management there was tremendously supportive in giving me free rein to build a QA team from scratch and run that team as I saw fit. While there were a number of things I wasn’t able to accomplish during my tenure at Telligent, I take great pride in having worked with a great group of testers who really transformed how Telligent ships software. We, as a great team, built something wonderful from scratch and that’s a tremendous accomplishment!

I’m also glad I’ve been able to gain experience working for a product company. I’d had years of experience working for consulting and contracting companies, but the environment of a product company is completely different. My experience here did nothing but cement up my firm beliefs in Lean: you simply can’t afford to build things only a few customers will ever care about. The pain and politics around trying to remove features you’ve released to the public isn’t something folks outside the product world will ever understand. Dodge all that pain and politics in the first place – avoid complexity, avoid building things the vast majority of your users won’t use frequently.

Many thanks to the folks at Telligent who put up with my oddball views coupled with a loud, often curmudgeonly personality. Most importantly, a load of emphatic thanks to the seven folks, onshore and off, who were on my QA team – you folks are some of the best people I’ve ever worked with and we did amazing things together!

A Mentor’s Worth: Breaking Things Down

Good mentors are worth their weight in gold for oh so many reasons: their experience gives them views into problems you’d never considered, their technical skills or domain knowledge lets them identify things you’d missed, and their longer careers may give them some calm perspective you’re too fired up to miss. They’re also exceptional at helping you step back from problems you’re too deep in to.

As I wrote recently, I’ve picked up guitar playing again and am loving how it’s stretching my thinking and learning in so many ways. I’m also finding great parallels between my experience as a mentor and how my guitar instructor guides me.

For instance, a couple weeks ago I was having serious difficulty on a piece around fingerpicking. It’s basic stuff, but well, I’m a beginner. I’d hit a total mental block and wasn’t able to get past some of the initial pieces.

John, my instructor, took out his pencil and quietly made a few marks on the page. “Do just these combinations first, forget the melody. Just focus on the chords.”

Wow. Well, wow and “duh!”

Stepping back and focusing on small pieces of the trouble is such a crucial problem solving skill. The problem was I couldn’t get myself to step back. I needed a guide to pull me back and show me the way. Break it down, simplify it.

This is the same sort of thing I really enjoy working with my mentorees/subordinates on. Got a problem? Let’s chat it up and see what it looks like. Then let’s step back and break it down. Dealing with a complex test matrix? Maybe we can figure out some common points, or look to some combinatorial pairwise magic. Got an overly complex, muddled test case? Let’s step back and think about what we’re really trying to test, then go after that test case with a scalpel to pare away everything that’s not essential.

It’s what mentors are great at: helping you step back and break large problems into manageable pieces.

Updated:Fixed busted image link.

Get the Reps In

I’ve played the guitar for 37 years now; however, I took a 35 year break and just picked it back up two months ago. For years I’d been feeling an urge to get back in to music in some form, and the final kick in the pants was watching Carl Franklin, Chris Castle, and the Womack Family Band put on an awesome show at CodeMash 2011. Their love of music and the sheer joy they had playing together really inspired me to get off my assets and do something musical again. (I’d also played trumpet for some years when I was younger.)

Because I realized how total my suckage would be, I signed up for some lessons at the awesome Piano Preparatory School in Beavercreek where my kids have been taking piano lessons for years. John Trent, my instructor is an amazing classical guitarist and a great teacher as well.

This journey over the last couple months has been an awesome practical re-re-re-reminder of why it’s so important how you approach any learning situation. I’ve spent significant amounts of time over the last couple decades teaching in various forms; however, it’s been a long time since I’ve been the student. What an awesome change of pace!

Work has been in a bad spot over the last month as we move into the final phase of a huge release we’ve been building to for nine or ten months. Couple that with kids, pets, a large yard, and a spouse who would like to see me occasionally, and it’s meant little spare time. As a result, it’s been really hard for me to dedicate 30 minutes each day to sit down and do the practice I need to.

This last week it showed. I hadn’t gotten in anywhere near enough practice on my pieces in my workbook and I was badly stumbling through a couple parts that were really challenging. John calmly and simply said, “Get the reps in.”

Four words.

Four simple words tying directly back to all the things I’ve believed so fervently during my decades of instructing. Four simple words tying directly back to all the wonderful things in Chad Fowler’s tremendous The Passionate Programmer or Andy Hunt's Pragmatic Thinking and Learning.

I wasn’t doing what I’ve preached to students, subordinates, and mentorees for years: work hard at learning. If you care about something, if you’re serious about wanting to improve, you’ve got to work at deliberate practice. Mastering anything, be it guitar, running, or software development, means that you’ve got to dedicate yourself to carving out time each day to work on it.

Get the reps in.

Focus on the Why, not the How

I’ve been mulling this post over for a year or more now, perhaps as long as two. I’ve started a number of drafts and thrown them out, dissatisfied with what had ended up on the screen. I’m tired of struggling to get it perfect, so I’m just tossing it out now. I’m not completely satisfied with what I’ve gotten done in this version, but here it is.

The crux of the debate with myself is an internal railing against the dogma I see in development methodologies and selection of toolsets/platforms/whatever. Too often I see good friends and industry leaders getting angry, condescending, outright insulting, (or a combination of all three) based on their preferred approach to software development.

Yes, I know. You may find this a surprising event in our chosen work domain. The software industry has never had these arguments before. Mere contradiction perhaps, but please, bear with me.

I’m tired of all the hot air around how we build software because too many people have, in my mind’s eye, lost sight of the why. Why do we develop software? To solve problems for the people who are paying us. Most of the time they don’t care how we do it.

Take the platform people develop on. A number of folks on Twitter throw out lines like “Why do great developers settle for platforms which aren’t Ruby?” or “Why are they choosing a bad technology instead of <x>?”

Focusing on the tooling or platform is focusing on the how, not the why of  building software.

The winner of a challenge at the first CodeMash conference won by solving the problem using a table in Microsoft Word, much to the chagrin of the other contestants who wrote a lot of code.

Ruby, Erlang, Clojure, etc. are all technologies we use to build systems on. They have nothing to do with why we build those systems. The software for the space shuttle is written in HAL/S, not Ruby, not Clojure, not some other cool platform of the day. Is that an inferior technology? Likely. So what?

How about the iPhone or iPad? The few iOS developers I talk with scream about the friction and pain they suffer on a daily basis because of the lousy tooling and awful platform issues. But look at why they’re working on that platform. My buddy and ex-colleague Joe Morel works at a company that’s won awards for their Rock and Roll Hall of Fame app. My good friend, muse, and also ex-colleague Leon builds amazing stuff that helps people collaborate on the iPhone and iPad.

They’re focused on why they’re building software and aren’t wrapped up in the arguments of how.

A similar line is dogma around TDD/BDD/whatever test-first methodology is being talked about today – and here is where my post will likely be misunderstood, misread, or flat taken out of context.

TDD/BDD/100% coverage is a how, not a why.

Software testing, at the unit, integration, or functional area, is critically important aspect of development. Software testing is something I’ve been passionate about for years, and have talked emphatically about for years.  Test-first development helps us design good architecture.  It gives us surety around behavior. It is an incredibly important line in the sand against regressions. Test-first development helps us evolve our skills to use the right patterns in the right places, and the right amount of abstraction.

Test-first development teaches us how to think critically because we’re forced to make decisions at a very minute, granular scope while paying attention to the larger impacts of those decisions. We’re learning critical thought as we move along that journey.

Unfortunately, some people carry the dogma to extremes and forego critical thought. (“Extreme dogma” is rather redundant. Sue me.)

An example: A pal of mine got to pair up with a well-known expert. The expert writes books, does training, speaks at conferences, and is extraordinarily influential and impactful on a great many people in our world, me included, and rightfully so.

They spent five hours ripping apart one specific view class to be able to get more tests around it. All the behaviors dependent on the view were tested in other areas of the test suite, but the expert felt compelled to get this particular aspect of the codebase completely covered in unit tests. I don’t know all the gory details of the view, but if you’re focusing on finding reasons how they could have succeeded, you’re missing the question of why they should have done it in the first place.

Five hours to try and get one class 100% covered with tests. They didn’t finish. Zero value was delivered to the customer. As a matter of fact, it was an opportunity cost that ended up causing my pal to miss finishing up his feature because he had to roll back a number of significant changes that were left unfinished.

That pair got wrapped up in the how of building software and lost sight of the why: delivering working software to the customer.

Another example of why hits very close to home for me: my diabetic gear. I turned in to a type 1 diabetic two years ago. At some point soon I’ll be dependent on an insulin pump to help keep me alive. Right now I use a blood test meter six to ten times a day, and I adjust my insulin doses based on that meter’s readout. If there’s a glitch with the meter I can overdose on my insulin and go in to a coma. Or die.

Scott Hansleman has a great post on his blog about the insulin pump and glucose meter he uses. He says his phone crashed twice the day he was writing that post. His meter and pump haven’t crashed in ten years.

Having worked in the embedded computing industry for a few years, I doubt the firmware in that gear was developed with any form of test-first methodology. It certainly wasn’t developed in any cool platform you’ve heard buzz about these last two years (unless you’re in the embedded industry).

Go read Agile Testing and pay close attention to the intro chapter where one of the authors talks about walking in to an ICU room where a loved one is hooked up to life-saving gear – and the author realizes she tested that equipment.

You want to tell me the folks in that industry aren’t great developers because they’re not doing *DD or working on some platform you’re enamored with? Two words: Fuck. You. Those people write amazing software that saves people’s lives. How’s that for an impactful why?

Now here’s where I finally get to the point I’ve wanted to make earlier but felt it necessary to first walk you through some over-the-top examples to help make my case. At least I didn’t go all Goodwin’s Law on you. Or make any Mom jokes.

The point is this: testing is critical for oh so many reasons, but it’s like scaffolding around a building under construction.[1] Apprentices and journeymen stoneworkers need that scaffolding and rely on it as they’re learning their craft. A master craftsman knows when he can do something without first standing up a bunch of scaffolding – but he’s making that decision based on years of getting it wrong and learning when he can do it right without the scaffolding. Darwinism may come in to play, too, since he’s obviously lived to know when he needs that scaffolding.

Another example would be the writings of Hemingway or e.e. cummings. Hemingway did insane things with his dialog, and cummings just decided he could throw out punctuation, grammar, and structure whenever he wanted to make a point. Both of them were masters at their craft, and both knew when they could move past the scaffolding they’d grown up with. You as an individual try getting away with that in your lit or comp classes and your instructor will most likely laugh you out of the room.

Testing is that scaffolding. Testing drives you to learn great design. Testing drives you to cut complexity. Testing drives you to learn how to build great software. But what do you do once you’ve learned how to do all that? Are you unable to write appropriate abstractions without tests? Are you unable to create loosely coupled designs that are simple and readable? And above all, are you unable to write software that is correct without tests?

Maybe, just maybe, you have gotten to the point where your experience has driven you to form great habits. Maybe, just maybe you can use your brain and look at your experience and skills – but with an honest, harsh eye – and figure out if you’re ready to move on past that point.  Maybe you can focus on why you’re building software, not how.

Am I saying stop testing tomorrow?

HELL NO. And I’ll call you a liar to your face if you say I did.

What I’m saying is use your brain. Figure out what’s right. Maybe testing is still the answer for you. Maybe some testing is the right answer. If there’s any question or self-doubt at all, then by all means continue your journey with tests to guide you.[2]

Whatever you do, think about the why of what you’re doing more than the how.

 

[1] A pal and I arrived at the example of scaffolding instead of training wheels after a number of very tasty beers at Spinozas. Scaffolding works much better for me because it’s much less diminutive than training wheels.

[2] Public Service Announcement: I will not give up writing tests any time soon. I have no doubt where I am on my personal development journey, and I’m nowhere near close to the level of mastery where I’d even consider going with out training wheels, much less scaffolding. Remember that if you ever pair with me.

Building Great Teams

UPDATE: I totally forgot one critical part of what I spoke on being a team leader – thankfully Dave Fancher’s summary of KalX reminded me.

Saturday at the Kalamazoo X Conference I gave a talk on building great teams. I did it sans slides, but wanted to follow that up with a blog post covering the points I hit during the talk – so here it is!

The trophy in this picture sits on the top shelf of my closet. I have a look at it frequently as a reminder of what a group of regular folks can do when they put their minds to it.

The trophy is from the 1991 Elmendorf Air Force Base Intramural Volleyball championships. At the time I was the player/coach of the 962 AWACS’s volleyball team. Our team wasn’t filled with the greatest athletes, but we played out of our brains and knocked off other teams that were filled with tremendous individual athletes.

That is the peak of any team experience I’ve been a part of because it continues to remind me that regular folks can do amazing things if they work to a common goal.

To me, all great teams are founded on three pillars: Respect, Great Communication, Passion. No team will work to its potential (or beyond!) if any of those three pillars is weak.

Everyone on a team has to keep those in mind, both individual members and leaders alike.

You as a Member of a Great Team

As a team member it’s your job to figure out how to make your team, not yourself, shine. Fall back to the three pillars and think about how you’re dealing with them.

Respect: Everyone’s got opinions. You’ve likely got a passle and you should feel free to raise ideas and suggestions, particularly in areas which may impact the success of the team. That said, think about how you’re throwing your ideas out to the rest of the team. Just because someone’s baby is ugly doesn’t mean you need to phrase it quite that way. Change “Your code sucks” to something helpful and easier to swallow, like “I bet if we pair up we can figure out a way to cut this method’s cyclomatic complexity from 352 down to something a bit more manageable as well as make it a bit more readable and testable.”

You also need to be able and let go of your own ego, particularly around your own ideas and opinions. Somewhere I heard the phrase “strong opinions, weakly held.”  I’ve always kept that to heart, because it’s particularly apt in our industry. I have extremely strong opinions on how to build great software: frameworks I favor, tools I use, methods on how to actually create software. I have those strong opinions because experience has proven these particular things help deliver great value.

I hold those opinions weakly: show me a better way and I’ll change in a snap. At the end of the day I’m in favor of anything that lets me spend more time on the couch playing XBox with my son or riding bikes with my daughter.

Communication: What are the team’s goals? Having difficulties with someone on your team? Stuck on a task, but aren’t stepping up to ask for help? Those all fall under Great Communication. You’re a part of your team’s communications ecosystem. [1] You need to step up to the plate and ensure you’re doing your part to keep that ecosystem healthy. It’s rarely easy to try and work out interpersonal issues with someone on your team. On occasion it blows up. You know what? Just because it’s hard doesn’t let you off the hook. Work hard at Great Communication because its benefits tremendously outweigh the effort it takes.

Passion: Get fired up about what you do. Yes, sometimes you have to suck it up and get that lipstick on a pig; that’s just a fact of business life. Offset those dreary periods with excitement about other things. Throw a lunch and learn on something interesting. Reach out to pair with someone you haven’t before. Look to learn something new. Share that excitement with others on your team.

You as the Leader of a Great Team

Do everything I just wrote about, but turn it up to 11 – and start with the respectful attitude with which you treat your team.

As a leader you can’t have the same sense of humor you do with peers. You’ve got to be very, very careful of how far you go when cutting up with your subordinates. You can’t in any fashion afford to point edgy, biting humorous insults at your team. That kind of humor (which I actually enjoy with friends and peers) isn’t at all appropriate when directed at those reporting to you.

There’s a completely different context and undercurrent when a boss fires off Mom jokes or insults at their subordinates – and a leader should never, ever even playfully joke about firings, i.e. “Whoever wrote this code should be fired.” These sorts of jokes always cut subordinates more deeply than you realize, and cutting up about firing someone over bad code/design/architecture/tests will crush down your team without you ever having a clue about it.

I can’t emphasize this enough: take care with the humor you present to your team. Make humor a big part of who you are as a lead, but stay far, far away from anything which can have a negative connotation.

Above and beyond that, build a great team. You need to take care forming your team – or improving the team you’re given. As the leader it’s your job to line up the best possible members for your team or work hard to deal with the ones you’re given – and “deal with” may mean moving unproductive members off the team. Makeup of your team has to be something you are willing to go to the mattresses on. Fight to get only great members, fight to turn existing members great, fight to get rid of members who aren’t willing to come along for the ride.

Once you’ve gotten your team built, empower them to do great work. I’m a firm, vehement believer that nobody does well under micromanagement. Set broad goals for your team and individual members, give them some borders on how to get that work done, then step back and watch them do amazing things. You’ve set your team up with great folks, or the potential to be great. They don’t need you to guide them every step of the way.

Empowering your team doesn’t mean you ignore them and abdicate your role of leader: you do need to monitor progress, and in no way, shape, or form does this get you off the mentoring hook. Checking progress from time to time ensures your directions weren’t completely misconstrued or that things haven’t gone off the rails. Checking progress does not mean you’re expecting hourly updates on everything though.

Closely tied to empowering your team is your role as Remover of All Things Roadblocky. I am absolutely not the sharpest tool in the shed. I look to get those folks on my team. What I am great at is helping those folks by getting every friction point out of their way I possibly can. I fight for hardware and get creative about sharing it with others when I can’t get what we really need. I push through for process changes to get asinine hindrances removed. Rinse, repeat. That’s one of my personal favorite, most rewarding things to do as the boss: solve problems so folks can shine.

Don’t forget to recognize the progress your folks are making. Teams get bogged down in minutia, so it’s important to give regular shout outs when they’re deserved. The ever-important BVC is critical so the team sees progress over time: “God, we sucked this week, but look at how much value we delivered this month!” I also make use of Amazon.com gift cards and foodie packages from Zingerman’s when the entire team’s done something really cool – like hit major milestones.

Be Part of a Great Team

Building, running, and being part of great teams isn’t easy. It’s a lot of hard work and care and feeding of your people – and it’s worth every penny. I’ve been on dysfunctional teams, I’ve been on teams that were just OK, I’ve been part of amazing teams that continually astounded me. Amazing teams can happen.

Make one. Be part of one. It’s life changing.

 

 

[1] I just totally invented the phrase Communications Ecosystem. Feel free to use it. Or not.