This item is scheduled for review.   Received comments are at the end of this page.

Please send any comments you have on the example using the Feedback Form.

Example – Events Booking System

Maintainability Testing

Database Maintainability Testing is aimed to prove the flexibility, usability and suitability of any given database. A selection of test cases should be executed to prove the database is fit for purpose.

Such a form of testing is applicable for all database changes, including conversions and the introduction of new databases. It is expected that this form of testing would take place at the point of operations acceptance testing.

Coverage

Bearing in mind the old adage that an application is only as good as it’s contents, then any form of data testing is paramount and the database upon which an application runs needs to be proven at the outset.

Types of testing that should be considered:

·        Functional Testing over the maintenance of the database, basic add, edit and delete. Testing for duplicate records, ensuring the key in the file forces a Primary Key – is this automatically generated.

·        Boundary Testing of the field and field values including the formatting of fields and the selection available from predefined values.

·        Usability Testing over the use of the data, case sensitive fields, wildcards, recognition of comma’s etc. Purging of data no longer required and archiving of old data.

·        Security Testing where data is sensitive/restricted view.

Database Maintainability Testing – Example

With the introduction of a new Events Booking application it is imperative that the users are up and running on the system within three months. The application and business venture are new to the company so initially the primary use for the system will be to enter new events, maintaining a diary of events and a log of locations and attendees. 

Requirements and Scope

The following have been identified as requirements and are listed in order of priority:

1.      The system will ensure that there is no double booking of venues.

·        Identify the field(s) that would constitute a double booking:

E.g. Venue + Data = Double Booking.

·        Is there another level down from venue, i.e. rooms.

In such a case the venue could be double booked on a single date but the rooms would be the identifier for the double booking.

1.      One an event has been set up the automatically maintained diary will trigger invites.

·        Events may be provisionally booked, at what point do they become active/live/confirmed events for which reminders/invites should be triggered.

Confirmation flag to be set on each event. I.e. once booked organisers liable to pay the costs even if cancelled.

·        Once the invites have been triggered for an event a flag needs setting to mark an invitee as being invited

This should hold date at which invite was triggered.

1.      In addition to the trigger of invites cancellation letters will be sent out to all confirmed attendees.

·        At which point does an attendant become confirmed.

A flag should be set on the database to denote that a record is eligible for a cancellation letter and a further flag to flag where a letter has been sent.

Test Execution

Key points in ensuring a reliable and maintainable database are:

·        Ensure fields are configured in such a way as to ensure data is correct. E.g. mandatory fields, avoid free text fields. (Force date/time formats)

·        Where a field can be left blank it should be identified as a blank selection. In the case of dropdown boxes a selection of ‘All’ or ‘None’ to ensure that the field does not contain a blank attribute.

·        A hierarchy of drop down lists. One selection predetermines the available selections in the next drop down list.

·        Ensure duplicate records cannot be added, this will depend on which field is the Primary Key, to avoid duplicates.

Test Results

Results were recorded as follows by executing scripts based on the above requirements:

1.      Venues that were allocated to a confirmed event could not be booked out for other events, it was also confirmed that although an event may take place on one day only the venue may be booked out for a period of time either side of this date to ensure set up etc. The system would book out the venue for all specified dates and not just the event date. Only available dates/venues were selectable from the drop down lists.

2.      Letters file triggered, attendee records flagged as having a letter sent and status changed to awaiting reply.

3.      Where an event is cancelled the system will automatically send a letter to all active attendees informing then of the cancellation. Active attendees are any attendees who to date are not recorded as having declined attendance to the event in question.

Conclusion

Clean and reliable data allows the application using the database to perform to it’s full potential. It is imperative therefore that the issue of purging and data housekeeping are taken into consideration at the outset and included in the requirements.

BPM’s (Business Process Maps) are always a good clear way to define business processes and in doing so it is easy to see how the data will perform, e.g:

·        Data dependencies, once highlighted it is easy to plot the use of fields and ensure that where options/choices are to be made by the users these can be limited to the only ones currently relevant, dependant upon previously entered data

·        Static data and free text fields, will some values always be system driven, therefore a list can be defined for selection purposes.

·        Projections can also be easier made on the growth of the database and the point at which a record (in this case event) becomes no longer active. Once the event is no longer active archiving may be considered, after a period of time such data is likely to be able to be purged completely from the database. This will keep the database tidy and clean, ensuring that when searches are done they are run only on valid data and not over a database of irrelevant records.

·        The database architecture should be written to support the current working business logic, as such any new fields to be added to the database should have their impact carefully considered before their inclusion to ensure that any changes to the database have little or no impact on the current workings of the database.

·        Deletions should take into consideration the possibility of parent/child records. It should be decided up front if deletes can happen on any record regardless of parent/child relationships or if the deletion of a child will always prompt a message to the user stating that there are dependant child records which need deleting first.

Please send any comments you have on the example using the Feedback Form.