136 Chapter 6
n Software development
Short-Term Analysis. In this case, the Short-Term Analysis function may be more difficult to implement, so you might want to tackle this sooner in order to get it working. You will
probably want to complete Data Entry before Data Analysis although in theory they could be swapped in any approach as you will want to have ‘read in’ some data to work
with before you can implement and test the Data Analysis and its sub-functions. In practice you should mix and match the approach to the development you are undertaking. It may
be appropriate, for example, to code some components from the bottom-up to test out a difficult algorithm or routine and then tackle the remainder of the system top-down
to provide the user with a tangible view of the system overall. Once again, whatever you decide to do, you should be able to justify this to your supervisor and examiners, and you
may have to include some discussion on your chosen approach in your final report.
•
6.12 Verification, validation and testing
6.12.1 Introduction
There are three ways that you can deal with errors in your program:
1. Prevent or avoid introducing them in the first place. You achieve this through
practice and experience, and following a development process such as those out- lined earlier.
2. You can detect and remove the errors. You should hope to do this as early as possible
as the longer errors remain in your code the greater the impact they will have and the greater effort will be required to remove them later when the code has grown even
more. Verification, validation and testing VVT are concerned with this issue.
3. You can tolerate them. There may be a certain level of quality that your client, user,
supervisor and examiner are willing to accept or tolerate. You will know from your dealings with them what is acceptable and what is not. If a high level of quality is
required it may be better to reduce the scope of your system in order to minimise the number of errors within it. However, if your user is demanding a high level of
functionality, they may be willing to compromise a little on quality to get what they want. It is probably better to have an 80 functional system working 100 correctly
than a 100 functional system working 80 correctly – the former appearing much more professional and robust. In addition, in the former case, the remaining 20 of
functionality you have left out could always be identified as further work in your report and the 20 of problems in the latter case may take a long time to sort out
if the code is badly written. Discuss these alternatives with your supervisor and client so that an appropriate balance can be reached.
Of these three options, this section is concerned primarily with VVT.
6.12.2 Verification
Verification is the process of checking that we are performing our development correctly.
In other words, are we sticking to our project plan and are we performing the stages of the development process properly? For example, looking at the conventional waterfall model,
verification involves checking that we are performing each of the stages correctly – by
6.12 Verification, validation and testing 137
looking at what we know before a stage commences and whether when we have completed that stage that stage produces the things we would expect to the right level of
quality. For example, after putting together our program’s specification we would expect our design stage to produce an appropriate set of design documents based on this specifi-
cation. Boehm 1979 summarizes verification as:
Are we building the product right? You can use meetings with your supervisor to verify your development. For example,
you may identify the completion of each stage in your development process as a mile- stone and use this as a verification point with your supervisor.
6.12.3 Validation
While verification checks that you are developing your system correctly, validation is checking to see if that system is really what the clientuser needs at all. Referring back to
Figure 6.2, you will remember that a user’s problem is not stationary and will evolve over time as you undertake the project. Validation is concerned with re-visiting the require-
ments with your user at regular intervals and checking that you are still developing what your user needs. Certainly if the user was naïve or had limited understanding of the
problem, validation becomes vitally important to ensure that you eventually deliver a system to them that solves their problem. In a similar definition as before, Boehm ibid.
neatly summarizes validation as:
Are we building the right product? Validation will also include a deeper evaluation of your system when it is finally com-
pleted. For example, you should, if possible, evaluate your system against other similar systems – how is yours better, worse, different? How does it compare with commercial
software systems, freeware and others? How will your system improve things for the clientuser – what impact do you see it having? Is your system developed from an existing
system? If so, what enhancements does it include and what benefit are these to the user? Does your system include any innovative aspects – new algorithms, coding techniques,
user interface designs – that can be applied in other areas?
These kinds of evaluation show that you are thinking much more deeply about your
project. They provide your project with academic content – a deeper insight into the project than the mere writing of a piece of code.
6.12.4 Testing
Testing refers to the testing of the program itself to see if it works or has any bugs or errors within it. You can test your program as you go along, testing individual compo-
nents before bringing these together into the whole system which must also be tested thoroughly. Testing can take place at a number of levels:
n
Unit testing – of individual modules. You may have to build some form of program
harness to test these sub-components.
138 Chapter 6
n Software development
n
Integration testing – of sub-systems and the system as it is drawn together. Do the
components of the system interact correctly?
n
System testing – this is the final testing of the complete system against the specification
and possibly the user manual.
n
Acceptance testing – by the userclient with or without you present. They will be inter-
ested in how the system operates in its live environment, with real data and performing in real time under normal working pressures.
n
Regression testing – involves testing the system after you have made significant
changes to ensure that new bugs, not present in previously working parts of the system, have not crept in as a consequence of the change. Regression testing is
particularly important when working on group projects where individual members of the team are developing different parts of the system. It is important to ensure
that, as components are integrated and members of the team work on different parts of the system perhaps not understanding how other programmers imple-
mented certain parts of the system, new errors are not introduced andor old bugs are not reintroduced.
You should test your code both statically and dynamically. Static testing does not involve running the program but inspecting the code either on screen or a printed
copy or the designs, specifications or other documentation for example, the user manual. This technique can be used to assess the content and level of comments in a
program, the scope and declaration of variables, the overall structure of the program, how the program matches the design and the layout of the code have you used tabs to
indent statements, line breaks to separate different sections of the program?.
Dynamic testing involves running the program in order to identify any errors. In large software developments, dynamic testing involves white-box and black-box testing.
White-box testing means you know how the code is programmed and structured so that you can test out potentially error-prone parts of the system. Black-box testing
means that you only know what the program is supposed to do, not how it is pro- grammed to do it. For your own program testing you will be undertaking white-box
testing as you know how the program is structured. However, you may wish to involve others in black-box testing of your software if you feel this is appropriate.
Some useful tips for dynamic testing are presented below.
n
Create appropriate test data sets. Try to create test data for your program that includes both extreme values and normal data. It may also be appropriate to gener-
ate test data that includes ‘bad’ data – i.e., data that the program would not normally be expected to handle for example, text data instead of numeric data. How does
your program cope with this? Does it need to deal with extremes or bad data, or can these anomalies be ignored is the user ever likely to enter something like this??
Your test data should include boundary values and equivalence partitioning can be used to minimise the size of test data sets. Boundary values are input values at the bound-
aries of what the system is expecting. For example, if the system is expecting an input between 1 and 10, the test data should include 0, 1, 10 and 11, as well as a number in
between 5, for example. Equivalence partitioning splits the test data into categories whatever might be appropriate that represent different aspects of the data. You then
need only test the program with one sample from each category rather than all the data.
