Skip to main content

Kick-starting a development project with a solid testing approach - a 5 step process to ensure quality

Ask a developer about their feelings about testing and you can elicit a huge spectrum of opinions:
  • "It's someone else's responsibility"
  • "Unit testing is the way forward"
  • "Manual testing gets the best results"
  • "You can't make the software better through testing!"
Above are all things I've heard people say when talking about testing. However it is such a broad subject and we tend to focus on a very specific aspect of it (e.g. unit tests or manual tests) and we can sometimes miss the big picture. When kick-starting a new product or project, it's vital that you think about various aspects of testing up front - here's my 5 step approach to ensure you have quality software right from the beginning:
solid testing approach
  1. Test input early in software lifecycle. You need to think about testing as early in the project as you can. When looking at designs, for example, you should think about negative tests and edge cases to help guide your design decision process. If you have testers within your team then this is great and you should get them involved in the design; if you don't have test resource the developers need to take on this mantle (they should also do this if there are testers involved in the project). Testing then happens as the software is developed with close interactions between the testers and developers and quick feedback loops. This is a very agile approach which works really well. Leaving testing until the last minute just doesn't work. Getting them involved early also allows them to start writing test scripts which is important for step 3.
  2. Automated test environment setups. A huge mistake people can make is leaving the test team to spend hours setting up test environments for every set of tests they do. This is such a waste - for every 1 hour spent testing you can easily burn 7 hours doing server and data setup. Investment in automated deployments for test purposes early on is a time well spent. There are also some really good by-products of emphasising this at the start of a project; you start to think about how the software would be deployed, how it would be upgraded potentially, how you load data into the system and also helps you consider your installation times. You will want it to be as efficient and quick as possible so any benefits your test team gain from this, your customers will gain when your product goes out the door.
  3. Manual test scripts. In modern software development people sometimes baulk at the idea of not just manual tests, but writing test scripts for this. However, there is no substitute for getting a real person do testing. They find things a system can't, they can pick up usability issues etc. By writing test scripts at the design stage, the test team can test the design or mock ups without any software needing to be developed. Things that are missed in the design can be picked up at this stage. The test scripts should be well structured and repeatable as the manual test scripts can then be used as a basis for automation test scripts. A huge by-product of well written test scripts is you can then scale up your test team when you need to (e.g. before release) with new people who are unfamiliar with the product as the tests should be detailed enough for them to step through. You can scale up using test resource from other teams in your organization, from outsourcing potentially, or even by getting your development team to run through the tests.
  4. A path to automation. If done correctly, the manual test scripts will provide you a set of repeatable steps that are always tested with every release of the software. The automated test environment setups give you a one click ability to setup the system on which to run this test. If you automate this manual test and marry it up to run on the automated deployment, then you have a quick and easy path to having good automation coverage. You don't need to automate everything - in fact I'd just automate the core 20-50% of your product. The time saved here in the long term will be enormous. Every time a developer commits, you can spin up a new test environment and then run your automated tests; if the tests fails the test team do not even need to do anything with this build and hence do not waste any time. Efficiency starts to go through the roof.
  5. Regular bug purges. A bad habit to fall into is to leave bugs for later, as you are adding a great new feature. This ends up with a big backlog of bugs and a lot of technical debt. If this is a long term project - avoid this at all costs. There are various approaches to keeping your bug count low; rotate a developer onto purely bug fixing every iteration, assign 20% of your iteration capacity just to bugs, make every 3rd or 4th iteration purely a bug fixing iteration. Do whatever of these suits but make sure you do it. With a good continuous integration system and automated deploys and tests, the chances of bad code and major defects creeping in decreases which should help to keep this figure low.
Of course there are various other things that need done when thinking about testing a product and it will vary depending on project size, team sizes and skillsets. However, following the five steps above as part of your development process will ensure you have a quality driven approach to your product.
How do you approach testing? Are there any other things that should be done in the initial stages of product development which are big wins? If so please leave a comment below.

Related Posts


Popular posts from this blog

Managing programmers and the programming mother******* mentality

I came across the following great site on Stumbleupon today - - and as a developer had a great laugh before realising that in my day job I'm really the guy the site is having a swipe at!

The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:

Whilst the site may be a bit tongue in cheek (obviously taking inspiration from Pulp Fiction), a huge challenge of managing developers can be the fact they can see you as a roadblock in the way of them producing code. Ultimately you are responsible for the success or failure of a project and as a result you have probably applied a process to the team to help you ensure your team are progressing in the correct direction. So how, as a manager, can you break down this perception from members of your team who have this mentality?

Before I start, I'll confess when I started my first programming job I agree 100% with the se…

Integrating Google Analytics into existing Android app

Analytics are key to measuring the success of your project or application and are a great way of identifying your users trends and demographics. Have you released an app and wondered who your users actually are? Well with analytics you could find out where your users are situated, what ages they are etc. The leader in this field is Google Analytics - this can be embedded into your mobile application, website and even your blog.

After a few frustrating attempts at integrating Google Analytics into an existing app I thought I should post a guide on how to do this.

1. Download the Google play services library and add it to your project.

You can do this by right clicking on the project you want to add analytics to in eclipse, choosing properties and then the Android tab. In the Library section, select Add and choose google-play-services_lib and select Apply.

2. Add the required permissions to AndroidManifest.xml.


Android - Could not find HelloWorld.apk! - fix

So my first experience of Android development left me frustrated after getting an error trying to launch the  simple Hello World example!

Simple fix - basically when I set up eclipse I forgot to set the JAVA_HOME path variable.

The symptoms are this in the console:
[2011-12-12 22:37:05 - RoryHelloWorld] Android Launch! [2011-12-12 22:37:05 - RoryHelloWorld] adb is running normally. [2011-12-12 22:37:05 - RoryHelloWorld] Could not find RoryHelloWorld.apk!
The fix is simple. Open up your machines environment variables (in Vista it's Control Panel -> System -> Advanced System Settings -> Environment Variables).

In System Variables add a new variable JAVA_HOME set to where your JDK is installed, e.g.

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12\
Then add JAVA_HOME to your Path variable. I added:

%JAVA_HOME%\bin;%PATH%; to the end of mine
Restart eclipse for the changes to take effect, then the next time you run your app it should work!