Let me ask you if this sounds familiar. You deploy a feature or a site to your customer’s staging server and send them an email letting them know that they can begin testing. After a day they email back that “Everything looks great!” and you deploy the feature to production. A day after that, your inbox is flooded with frustrated emails from your client how “everything’s broken and nothing works.”

What happened? Didn’t the client just say everything was great?

Yes they did, but unknown to you, their idea of testing was vastly different than your idea of testing.

Here was your customer’s “test”: One person in the office opened up their browser, checked to see if the pages matched the comps from their graphic designer, maybe edited a few fields and clicked “save.” They did that once, and they didn’t check edge cases, different browsers, or go through all the features you discussed in the requirements document. Then they sent you an email, “everything looks great.”

Now they’re getting angry emails from their users about how it won’t let them save in IE 6, or Firefox, or how the print margin on the printer-friendly view are off, and they’re asking “didn’t you even test this stuff.”

See the problem? When you told them that there was a “testing” phase to the project they assumed that you did all the technical testing, all they had to do was do a final sign off that everything was in the right place and looked the way it should.

Testing is an overloaded term, what you consider testing (finding bugs, checking if features work the way they’re supposed to, checking different browsers or operating systems) is different than what your customers consider testing. Your version of testing is Functional, while their idea of testing is Verification. A customer considers testing the same way they see approving a print ad or a piece or a design. If what I see on the screen matches what I expect, then it works.

They have that expectation that because they assume it’s your job (the developer or implementer of the project) to do the functional testing while it’s their job to verify.

As with most things in freelancing, this can be solved by properly setting the expectations with the client in advance. You have to make it clear that the testing phase of the project includes functional testing by the client as well.

Test Plans are great for setting this expectation, you don’t have to make them overly detailed but include the following for each test.

• A number to identify the test in emails/bug reports
• Steps on how to perform the test
• Edge cases for each test (like trying to save blank forms)
• The expected result of each test

You can work with your client to define the tests, but remember you’ll have to lead the charge on this (after all, you’re the technical expert).

I like using Test Plans for large, complicated projects and big feature releases, especially with new clients. They may seem like a pain to set up at first but believe me, the hour it will take to create a test plan will save you and your client a lot of pain and suffering post-production.

PS – Oh be sure to factor creating the test plan and managing the testing phase in your quote. But you know that 😉

There’s a job posting for a developer that I recently ran across that gave me an idea for doing this blog post. I won’t directly link to it, to protect the poster, but I think it serves as a great example of warning signs you need to watch for when taking a project. Here’s how it begins:

I had previously used someone else to start the project 2 weeks ago and they just cancelled today for no reason at all and had given me nothing to work with.

Not a good start, I ask all my clients with existing websites if they’ve worked with another developer and if so, I’ll ask them why the relationship ended. A developer who drops off the planet with no warning tells me the working relationship between the client and the developer was not great. The client seemed to be blindsided by this, so proper communication while the project was in progress was not in place.

The 1st phase of the project was supposed to be completed by Feb. 4. If you can get the 1st phase done between Feb. 4 to Feb11, I will offer a bonus!! I assume work would need to be started this weekend.

Also a bad sign, the project (an ecommerce site) was expected to take a total of two weeks. This is a very tight timeline (this is likely why the developer quit, they realized they signed up for more than they could handle) even for an experienced team. Instead of returning to the customer to establish a more reasonable timeline, the poster is offering a bonus to the next poor soul! Well, at least they realize that because of the timeline and the urgency of the situation they will have to pay a premium . . .

We are a marketing company with many clients so please price out the quote accordingly as we need to mark it up a little. I’m looking for an affordable developer who I can send projects to on a regular basis. My total budget is approx. $3000 so please reply if you are serious about the timeline and budget.

. . . or not

3K for the whole project? Also check out the bait: “if you do a good job with us, we’ll send you more low paying high pressure projects.” Gee! Thanks! I think Paulo Elias said it best

There’s second phase at the end of the month (Feb 28th), which has a lot of additional requirements and features they want added. I won’t break them down further since at that point I really zoned out.

The thing is, this might be a good project, I’m sure this project is perfect for someone. But after doing this for three years, I’ve developed a kind of gut feeling for projects (or Spidey-sense) that tells me to stay far away

I’ve developed it because I’ve taken projects like this, because when I started I didn’t know any better and because I didn’t have any idea what my time was actually worth.

Your time is the most valuable thing you have, if you commit to a bad project on bad terms, then your time will be spent on a nowhere project when you could have used that time for something else. Remember when you’re meeting with a client for a project, you should be vetting them, watch for the warning signs and run like hell if your spider-sense is tingling!

This isn’t my first blog, in fact kids, your old Uncle Pat has been blogging since 2004.

I used to be a private pilot. I’ve always loved aviation and in my early twenties, broke as hell and with way too much time on my hands (graduated college, no girlfriend, very few friends to hang out with) in 2004 I decided to give flying a shot.

From 2004 – 2010 I flew fairly regularly, about once a month. It was a lot of fun, I enjoyed the challenge of getting new ratings, testing my skills, up in the air just me and the airplane. I started blogging not long after I got my private pilot’s license, simply because I felt a single line in a logbook didn’t do what I was experiencing justice.

It was a lot of fun, for a while. Over time though I noticed a pattern, in that, I rarely left the pattern (in aviation, the “pattern” is the space surrounding the airport, usually 1000 feet above the ground reserved for taking off & landing traffic).  I would go on short hops to nearby airports, do some basic landings & takeoffs, and return back to my homefield. Soon, I stopped even making those trips.

I think I “officially” quit flying when I started Anecka, three years ago. But my heart quit on flying months before; I could blame the rising cost of rent, gas, insurance (it’s shocking and sad how expensive flying has become), in reality, I think it came down to just not surrounding myself with a group of people my own age interested in flying.

I’m an introvert, which means, I get energized by ideas, not necessarily meeting new people. It’s something I’m actively working on, and I’ve made a lot of progress, however in my twenties interacting with strangers was a nerve-wracking experience for me. I also didn’t really get how important peers can be.

Keep in mind peers are different from friends (a peer can be a friend, but not all friends are peers). Peers are people you have a mutual respect for who share a common interest or passion. Peers can help kick you out of the rut, they can challenge you to fly outside of the pattern once in a while and tackle something new. The best peers will show you where your blind spots are, help you find things that you might have missed or force you to thinking about details you thought were unimportant.

On the flip side, if you surround yourself with people who don’t understand what you’re trying to do, or who find ways to belittle or marginalize your accomplishments, then it can have a devastating affect on your success. Those people are not your peers and you have to take care to minimize your exposure to them (this is especially hard if they are family or “friends”).

I’m very lucky to have learned this, I have a fantastic wife who understands the struggles of working for yourself, because she does the same thing (peer), and I’ve sought out other entrepreneurs in Columbus at events like Wakeup Startup, Startup Weekend, and VentureCafe.

Finally, I’ve learned to reach out more to strangers and make myself available. Social anxiety is a luxury that I can’t afford anymore. If you find yourself stuck in a rut (or in aviation speak “circling the pattern”) I encourage you to get out of the home office and start to find a solid peer group. Heck shoot me a message on Twitter, or comment on this post, I’d be happy to get to know you!

Clear skies

In part 1, I discussed a maxim in the Freelancer’s Manifesto #4, Freelancing is Deadly. Basically the gist is that if you trade hours for money, you’re going release your product later (or not at all) and never escape the vortex of working for an hourly rate. The author, Rob Whalling, even compares freelancing to working for fast food.

That said, for a micropreneur, dollars for hours is death. If you build a business where your earnings directly correlate to your hours worked then you aren’t a micropreneur. You’re working fast food.