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.