Software Functional Testing

Software Functional Testing is usually the first type of formal tests carried out by a dedicated test team in software development. The purpose is to find discrepancies between how the software has been implemented, and the function specification. In some cases, much of the testing effort will be concentrated here, as it is quite often the area where most errors are found.

Functional testing actually starts long before the software is released from development. Test analysts usually start the process at the same time as developers, receiving the functional / system specification from the project management team. Both development and test teams must use the same specification, so that the tests can relate directly to the software being produced. The test analyst is required to determine not only how the final product must work, but also how it might fail.

Analysing a specification is not a trivial task, and is a skill often devalued within the software industry. As the purpose of functional testing is to not only prove that the correct input will result in the correct output (as defined by the spec), but also that incorrect inputs will be handled in an appropriate manner. This input can be via a user interface or by electronic means.

To help with the analysis, various methods have been devised, the most common of which is called boundary analysis. This technical can help to simplify even the most complex of systems. It relies on determining where a change in the flow of data in a system can occur. An example will demonstrate this. Suppose an exam marking system is being developed, part of which will be the entry of a result percentage mark, and the output a simple pass or fail based on a pass mark of 40%

The first tests would be on the input of the result mark. The value can only be between 0 and 100%. You cannot have a negative mark, or score more than 100%. The boundaries can be seen to be 0 and 100. So the tests for this will be: -

 As you can see, even with this one simple input field we need at least 4 tests. However, now consider the computation of a pass or fail. The boundary here is 40%, giving:-

This gives an additional 3 tests that must be carried out. So even in this simple application we have 7 separate tests. In real world applications this can run in the hundreds or even thousands of tests. This in itself requires careful management and documentation as several testers can be employed to actually carry out the tests. For this purpose test scripts are used to define each test and expected result. These scripts are latterly a step-by-step description of how to conduct an individual test, down to entering numbers in a particular field, and pressing particular buttons. The expected result for each step should also be clearly defined so as a pass or fail can be recorded. At no time should there be any discrepancy in the script, as that can lead to errors not being detected, or the inability to reproduce a failed test. The writing of the test script is usually more time consuming than the actual tests themselves.

Any errors found during functional testing should be communicated back to the developers in a clear manner. One of the most common issues developers find is that not enough information is included in a bug report for them to reproduce the bug themselves. This can lead to a time delay as the error report is sent back to QA for more information.

Functional testing can be a difficult phase of the development cycle – deadlines are tight, the customer and management may want to release the code, programming is complete, but QA are still finding problems. Management temptation is always there to cut back on testing, but this is the only time to find problems that will surface perhaps weeks or months after a release.