Top Five Pain Points: Dealing With Time Constraints

Too much work, not enough time and experienced people to do it in. Heard that before? Been there, done that? Living it now?

One of the top five pain points our customers listed when getting started with Test Studio was the difficulty of dealing with time constraints—the challenges of adding new testing approaches to their project. In this post I’ll try to lay out a few approaches to addressing time constraints, but be clear with your expectations: entire books have been written on project time constraints, so I’m only hitting a few of the high points I’ve focused on in past efforts.

At then end of the day, everything about success rolls back to proper, clear, and realistic expectations communicated between the entire team. That starts off by figuring out the scope of what you’re going to automate.

Know Why You’re Testing

Before you even sit down to select a software testing automation tool (or as early in your project as possible), ensure you know why you’re doing your testing. I use “why” in the context of understanding the goals you’re looking to achieve with the system you’re working on. Ensure you’ve got a clear picture of the level of testing you’re expected to perform for your project, and how that testing ties back to your stakeholders’ needs.

I highly recommend reading through the Agile Samaurai’s discussion of an Agile Project’s Inception, and/or have a look at Gojko Adzic’s Impact Mapping. These two works have helped shape my already lean views on where and why to apply automated testing to a project. (If you haven’t already, you should read Tom and Mary Poppendeick’s Lean Software series of books!)

Only Automate High Value Tests

High value tests are those which center around business features your stakeholders feel are the most critical. This ties directly back to the why I mentioned earlier. I say this constantly in the various workshops, presentations, and classes I deliver: When working with UI test automation there are a lot of things you can automate. There are only a few things you should.

High-value tests check that your most critical business value functionality still works. Can your customers check out with their shopping cart? Is sensitive data’s access blocked to unauthorized users?

Low value tests are those which don’t line up with those ideas, or tests which are hard to implement and extremely brittle. Validating styles, images, and alignment are examples of these. Back in September of 2011 I wrote Not Every Test Should Be Automated with a few other concrete illustrations of this.

Don’t Build Tests Twice (or Three or Four Times)

Mike Holmes of Holmes on Holmes and Home Inspection nails it: “Do it right the first time.” If you don’t have time to create your tests correctly now, when will you have time to fix them? Before you begin to craft your tests, take a moment to think about proper test case design. Here are a few points to consider:

• Is there enough clarity in the requirement or user story to understand what you’re testing?
• Are you writing a high-value test, or is it one best left off your work list?
• Are there previously written components you can leverage to compose your test?
• Is the UI you’re testing written with testability in mind? (IDs on essential elements)
• If not, can you work with the developers to clean up the UI?
• Do you have the proper infrastructure in place for your tests?
• Do you have support APIs, or do you need to coordinate with developers for new ones?

As you work through these points, plan out how you can create the test so it’s clearly readable, maintainable, and accurate. In that order. You’ll note I put correctness of the test last. That’s because I’m a firm believer (via hard experience!) that it’s easier to fix a test (or software) that’s clearly written and well-designed. It’s a nightmare to try and decipher an accurate test that is 452 steps long with badly named steps and elements duplicated throughout it.

Continually Re-Assess Your Automation Suite’s Effectiveness

You need to build your tests correctly the first time, but you also need to factor in time for updating and refactoring your tests as your project continues. You’re going to learn more about your tests and your system as you work through the project. Gather feedback on the stability and maintainability of your tests, then push that back into your automation suite via constant refactoring.

Perhaps you’ve found your initial approach was very difficult to work with. Get time on the schedule to rework your suite so it’s easier to maintain, execute, and evolve.

At my last job I led a team that wrote roughly 15,000 functional tests scattered across 1,000 or so fixtures/classes. We started out using Selenium v1 and ended up with WebDriver. We did two or three major rearchitectings of the suite over the space of 14-18 months—and that was time well spent because the tests ran smoother and were easier to work with.

Deal With The Human Side of Things

I’ve saved the hardest thing for last. Nearly every major project that’s ever failed hasn’t failed because of the technology, it’s failed because of human factors. We humans still stink at clear communication even after millennia talking to each other. Personalities, politics, cultures, philosophies, all this gets in the way of things.

It’s easier said than done, but you absolutely have to work hard at ensuring your entire team is communicating as best as possible. Identify misconceptions as early as possible and deal with them. Sometimes you have to get well outside your comfort zone to work through extremely difficult interpersonal conflicts. If you don’t step up and try to resolve those, then how will anything improve? As my good friend Leon likes to say, “Sometimes you’ve just got to hug it out.”

Succeed By Ensuring Expectations are Clear

Dealing with time constraints isn’t easy. None of what I’ve said so far is any form of magic bullet.

It all traces back to ensuring you have clear expectations. Work hard at that and you’ll find yourself succeeding with handling your time constraints.

What approaches for dealing with time constraints have you found useful in your situations?

About the author

Jim Holmes

Jim Holmes has around 25 years IT experience. He is co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. He's a blogger and evangelist for Telerik’s Test Studio, an awesome set of tools to help teams deliver better software. Find him as @aJimHolmes on Twitter.