Four Steps for Better Software Development

Let's Talk About Test, Baby

800x300_Software Development

By putting a product out into the world, a few things are happening simultaneously. The industry is being affected by your product, customers are expecting your product to improve their quality of life, and your company is being represented by the quality of the good. Clearly, it needs to work, and to ensure that it does, it needs to go through a rigorous testing procedure.Like human beings, anything complex is built with many layers and each of those layers needs to be verified. This article will guide you through the different stages of software testing.

There are 4 separate test steps that need to be taken when designing new software and integrating it into a final product. Each step includes preparing a test plan, creating the test cases and finally executing the tests each time. By following this format, it will protect your customers and your brand.

Step 1: Unit Testing

The trick to getting software to do what it’s supposed to do is to start at each component. Software that is installed in a complete solution is comprised of many commands also known as components or units. This will be a smaller sequence that generally does one task (has only one output). Logically, the software doesn’t work if the unit doesn’t work. This can be compared to testing each cog before assembling a clock.

Unit testing is done using white-box testing. This examines the structure of the code itself versus the functionality of the application. It is named as such because it is a transparent process where you analyze everything happening on the inside. White-box testing can include path testing, decision coverage, data flow testing, control flow testing and more. More often than not it is the software developer performing these tests, as they have the big picture of the ultimate goal.

Step 2: Integration Testing

When it comes time to pull all the units together, testing needs to start over. Just because a cog is perfectly designed, that doesn’t guarantee it will work well with the other cogs. Each component needs to fit together the right way in order for the clock to run. The goal of integration testing is to find any flaw in the software being designed, once all units are combined.

Four methods are used in integration testing:

Big Bang Testing: Combine all the modules together and see if it works;
Bottom Up Testing: The lowest level units are tested first, and used to simplify testing of all the higher-level components until reaching the top;
Top Down Testing: You guessed it, it is the reverse of bottom up testing. Here, the behaviour of lower-level units will be simulated;
Sandwich or Hybrid Testing: A combination of bottom up & top down testing.

Depending on the code that is being written, one method will be preferable over another. For example, if it’s a smaller program, big bang may be the most efficient way to go, however a program can easily be made up of hundreds of units. If something is off, a lot of time can be wasted looking for the issue if they aren’t verified piece by piece. This is also why it is important that unit testing is complete before starting integration testing. If you encounter an error, it will be unclear if the problem is at the integration level or unit level and force you to start back at the beginning.

It is also strongly recommended to automate testing for medium to large projects. Should any approach other than big bang be used, regression testing will be key. Regression testing means re-performing tests once a change is implemented to double check that change didn’t break anything. To do this manually can be very time-consuming and tedious. Automation will speed things up and execute the tests flawlessly.

Step 3: System Testing

We are now at the point where the software is complete, has been tested and has been installed on the machine it is meant to work on. Our clock now has all the cogs lined up, along with all the wires, knobs and hands. The question is, is the clock ticking?

Generally, system testing is performed by someone outside of the original developer’s team, and they will run all the tests to ensure the system is doing everything it was designed to do as per the original requirements. It is safe to assume they will use the original documentation (including any revisions that may have followed) as a checklist to confirm the product complies with its intention.

Step 4: Acceptance Testing

Like the stages of grief, the final step any product needs to undergo is acceptance. We now know the clock is put together, but is everything working as a consumer would expect? Acceptance testing verifies that all the features a customer is paying for will be delivered. The structure of the source code becomes invisible at this point and the priority becomes ‘Is this completed device ready to ship?’. This is called black box testing because contrary to white-box testing, you can’t see the inner-workings of the system anymore.

To go back to the clock, acceptance testing will verify the time is passing as it should, but will also check that all the lights will turn off and on, the cuckoo bird comes out every hour on the hour, that it makes the annoying sound, and so on.

Once acceptance testing is complete, your perfect product with your perfect software is ready to go out into the world and represents the quality of your brand. If each software testing step is followed, the results will speak for themselves with happy customers, fewer recalls and a healthier bottom line.

For advice on any or all of the steps listed above, please contact one of Averna’s software development experts.