How To Effectively Manage Software Testing

Testing is one of the most crucial parts of software development, but it's often neglected because seeing if something works is less sexy than building it in the first place. Whether you're an amateur developer working on a mobile app or a corporate manager with a large-scale project in mind, remember these guidelines to ensure your testing process goes smoothly.

Picture by Ron Wurzer/Getty Images

1. Allocate time for testing

Testing isn't something you should leave until the last minute; assign time to it when you first begin planning a project. Even if you're building an open source project and expect contributions and improvements from others, you'll need to allow time to debate and integrate those changes. For public-facing projects such as web sites or web applications, testing is likely to take at least as much time as the original development process.

2. Set a time for release and stick to it

On many projects, having a fixed time of day when you roll out new changes and begin testing makes sense. This is essential if you have separate test and development teams, but even when you're the main developer, consciously dividing the process means you will focus on testing what you've done rather than arbitrarily switching back to "coding mode". This again is especially important with web sites, which often have incremental improvements added over time. Even when you're using a staged development server, locking down what can be changed and fixing a time when it happens will make planning easier than if you constantly make minor updates.

3. Test on as many devices as possible

Development for mobile devices is a rapidly growing market; a 2010 survey by IBM suggested that more than half of all developers expected to concentrate their efforts on developing for mobile platforms. When testing on mobile platforms, use actual devices whenever possible. Emulators are useful for prototyping and will give you access to models you might not see otherwise, but emulation is rarely perfect and the user experience will often be subtly different. That said, for many projects it makes more sense to develop a mobile-friendly web site or app rather than concentrating on specific devices, and such an approach makes the rapid emergence of new hardware less of an issue.

4. Make use of external resources

Cloud-based external testing services provide a useful way to see how your applications work, especially if you want to see how they perform at scale. IDC says that more than $10 billion a year is being spent on these services, and growth rates of 15.4% are expected through to 2015. Using external testing providers also highlights issues that may not be obvious in your own testing processes.

5. Document the testing process properly

Documentation is the bane of many a developer's life, but failing to adequately document as you work invariably creates headaches in the future. Documentation is vital, and the same applies in a testing environment. When problems emerge, document them with as much detail as possible. If your company has a specific system, use it. Even on a one-person project, a formal bug tracking and testing system makes sense, and again emphasises the importance of considering testing as part of the development process, not an afterthought.

What approaches do you use to ensure software testing works? We'd love to hear extra ideas in the comments.


Comments

    If you are serious, employ a professional software tester (disclaimer: I am one). Developers can never be testers for a product.

    Here is a simple example. Developers have built a piece of software according to a specification. They will then test it against that specification. Software testers will test not just the software, but the specification. Often what I see is a software product that meets the specification, but the specification itself doesn't meet the business need.

    BTW, if you are project managing a development project, and you haven't allocated at least 20%-30% of your total budget to testing, then you deserve to fail.

    Also as a fellow Software Tester, the major benefit you get is that we ensure the software meets the business needs.

    Functional Specs / Business Requirements are the main focus of Testing and more often then not most issues occur due to the actual spec.... proving confusion between the Business Analyst who wrote it and the Business people that he/she spoke to.

    Most projects fail these days due to poor specifications / requirement gathering AND poor testing. Which occurs more often then not due to Project Managers failing to allocate reasonable time / budget for Testing. More often then not it's an after-thought 'oh sh1t we need to Test this thing aswell, I think this amount of time will do as I only have this much left, now I can tick that little check box for testing".

    Just remember... every defect found in the testing phase is a LOT CHEAPER to fix before the defect is found when the software goes live.

    > 1. Allocate time for testing
    You couldn't be so spot on! This is probably the most typical mistake, at least in my organization. We run a lot of website stress testing using BlazeMeter.com (regarding your comment of 'Make use of external resources', this is not an in-house tool but it saves us loads of time running Jmeter cloud testing), but it seems that the developers are doing way too much testing than they should (developers need to develop!)

    Point 3 - test on as many devices as possible. Without crowd-sourced testing like BugFinders.com - it is really difficult to test on all the platforms as there are upwards of 150 :(.

      Rather than test on as many devices as possible, I suggest that you want to identify your target devices and stick to them. Trying to test on upwards of 150 devices (and if we are talking about mobile development, this is talking about Android) is never going to work. All you are testing is device compatibility, and not the actual software. Devices change too rapidly for this to be a sustainable methodology. I suspect this is why some development houses have dropped Android device development. Trying to take into account too many devices in a fractured environment.

    You are right in saying that, one of the better ways to approach testing, is not to take it as an activity which is done at the last moment. Coming from a development background, I moved into testing with the aim of resolving that issue (disclaimer: have recently joined Access Testing Pty Australia, and am working on automation, for a government contract). The above issues are plaguing the industry, where software is released without much thought to testing, or the time allocated for testing is shrunk to fit in the excess time taken by the Development Teams.

    Testers should be involved from the initial phase of requirement gathering, as they are the people who actually do the User tests. They have a better understanding of where the pain points are and what can be optimized in user experience (UX) or functionality. This is rarely done, and needs to be fixed. Involve the Test Team early and you reap many additional benefits. [e.g., a typical issue being with automating the testing of Flash sites, where the developer does not know that tools may not work with the native release build].

    That said, I do believe that the above points and comments provide a great beginning to where testing should be going. Also, to add, Test Automation should not be forgotten in the large picture of testing, as that saves time for regression runs and can save time and effort in figuring out if a new feature broke something elsewhere.

    Great to see so many testers reading lifehacker!
    What everyone os saying, (start testing early) is basically the v-model of testing, where you start planning for integration and testing at the project inspection point.

    All the points are valid, just happy that Lifehacker is actualy putting some time in talking about it.

    Before you test, make sure your using a code review tool to catch most of the mundane bugs before they get to us so we can spend our time testing for the more serious issues!

    Unlike Mary Mary Quite Contrary - bugs don't line up in pretty little rows to be found. That means testers need to think critically about the project. What is the purpose of the testing, what do the stakeholders want? Where are the risks, what assumptions have been made about the product? This is what makes a tester valuable in a team, regardless of early/late testing, document vs no document, broad scope vs narrow scope.
    Testers need to be the skeptics, the ones that point out the elephant in the room. If thats not the case, they're merely there to make feel people good about the product.

Join the discussion!