Introduction to Software Test – Functional Test

functional testing qa

Functional Testing

Once coding of software is ‘done’, a formal test is needed. The purpose is to evaluate the quality of the software, and indicate what needs to be ‘fixed’ in order to improve the quality. More specifically, that the software does ‘what it is supposed to do’. That it ‘functions correctly’. Not surprisingly, this is often called ‘Function Testing’.

In order to test that something does what it is supposed to do, it should be obvious that the testers need to know what that is. This is best accomplished by designing the testcases or at least the test plan from formal documentation which specifies what the software is supposed to do.

There are 2 main methodologies to choose from, exploratory or scripted. Exploratory testing is ‘pretending to be a customer’. This can be particularly good at finding problems a customer would find, including those problems which could never be found by following the product documentation. Scripted testing is translating the product specifications into test actions. This can be good at ensuring consistent coverage of the whole product. Perhaps the best choice would be a methodology which included elements of both of these.

Because the goal of this test is functional in nature, the testing will be done using ‘black box’ techniques. The people who design the test should NOT be familiar with how the product is coded, which indicates that having a developer (formally) Function test their own code is risky. Why? I’m not saying that developers cannot adequately Function test (some can, some can’t, some won’t). My reasoning, backed by experience, is that developers, assuming they are human, have ‘blind spots’. And if they coded around any blind spot, they may well also test to the blind spot. Or they are ‘so sure’ that the way they did something is ‘right’, that needed tests are not included.

So Functional test is best performed by a test specialist. If this is not practical, the testing should at least be done by a DIFFERENT developer than coded what is being tested.

If this is the last test to be performed, it must be done on the ‘real’ system(s). No simulators, emulators or other non-customer-like platforms. If there will be a later test which will be on the ‘real’ system(s), then this test can be done on a ‘virtual’ system if that is preferred.

As this is a ‘Functional’ test, the goal is to verify the functions. To do this, execute all functions with all inputs and sequences of inputs which are practical. It is wise to do ‘boundary validation’, where you use the smallest and largest values allowable, ‘error validation’ where you use 1 smaller than the smallest and 1 bigger than the biggest values allowed, as well as other invalid values. Boundary values which might need testing may also be within the valid range. For instance, if ‘sizes’ less than 64K uses one method to handle and 64K or bigger ‘sizes’ use another method, then testing 64K-1, 64K and 64K+1 is usually advisable.

Formal functional test should be done on code which is ‘complete’, although it can be done on parts of the product, or on the whole product, as appropriate.

As mentioned, you can do this testing by following a ‘script’ (an approved set of testcases with instructions and validation criteria) or by ‘exploring’ the product by following a ‘map’ of what the product is supposed to do. In this case, many of the validation criteria might be ‘what seems right’ to the tester based upon the specified behavior of the program. Even if the testing is controlled by the set of testcases, it is wise for the tester to try additional things suggested by a testcase and his experience. It would be most unfortunate to miss a significant bug just because it was ‘not covered’ by the test’s testcases.

Note that once software is done, it is often updated. The new version should be ‘regression tested’ to make sure no unintended changes were made. In order to generate this test, the testcases run initially should be used as a basis. If ‘exploratory testing’ was used, then the steps taken during the test should be recorded in detail to facilitate generation of the regression test (as well as ‘prove’ what was done during the test).

For simple programs run in the real environment, this testing may be enough to validate the product for release. For more complex products, an additional test which simulates a real customer environment and usage is needed.