Implementation/Acceptance Testing / 1 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability.

Implementation/Acceptance Testing / 1

Implementation and Acceptance TestingImplementation and Acceptance Testing

Physical Implementation

Criteria:

1. Data availability

2. Data reliability

3. Data currency

4. Data consistency

5. Data flexibility

6. Data efficiency



1. Data availability : The required data and relationships are stored in the database

2. Data reliability : Data will not be lost nor corrupted

3. Data currency : The data value is the latest value of the data item



4. Data consistency : The same data values will be obtained for the same item in different

queries at the same time

5. Data flexibility : Extension can be made to meet new requirements without rebuilding the

database

6. Data efficiency : Storage and retrieval are at minimum cost



The major components of the implementation model are :

1. A data model structure

2. Data definition languages to define the data model structure

3. The data access commands. Access specifications are embedded in programs, views, reports

4. Physical structures - based on volumes, usage, frequency of use, response times required, number of concurrent users..



The Enterprise Model Data Model Structure

Programs and enquiries

Access Specifications to access the database

Logical data model structure

Database Specification Physical database structures

Quantitative data



4 fundamental capabilities of a DBMS

1. The DBMS must provide a natural interface of user data

2. The interface must be independent of any physical storage structures

3. Different users should be able to access the same database using different views of the database

4. Changes to the database to be made without affecting programs which make no use of the change



The Operational Environment

– Specialised use by one or a few people

– The database is an integral part of a business operation and must be accessible to a large number of users who may be spread over many locations, and work in different time zones



Other considerations:

Concurrency control

Access controls

Recovery systems

Database privacy



A suggested Test Specification outline

Test the functional areas:– Maintenance– Analysis– Tools– Exit Procedures

Overall operation - menu navigation, forms opening, forms closing, button operation.

Transition to a new or former state



Maintenance : data entry

Forms navigation

Valid data entries

Valid / correct calculations

Tools - probably searching and sorting



Test each attribute in forms, views, reports

Order of presentation / appearance of input attributes

Navigation around or through forms - Tab key, Enter key

Is the progression accurate ? - what you expected ?

- smooth ?

What is the ‘user’ reaction ? - the Quality Reviewer in your team is an excellent ‘user’.

Indicate ‘actions’, ‘Expected results’, Actual results or ‘OK’.



Test forwards and reverse cursor movements

What error messages occur ?

What triggers them ?

How are they cleared - not a full restart ?

Do you have ‘standard’ error messages or is there a clear indication of the cause and correction of the error ?

Are attributes type protected ? Size protected ?



Do you have data presentation rules ?

e.g. - the first character of a string in Capitals

- punctuation

- $ signs or identifiers on numeric values displayed

- decimal points included and positioned correctly

- dates in British form e.g. 12/09/2002 or 12-October-2002

How are empty attributes presented ? Blank, ??, ‘no value’ displayed ?



What is your policy on deletions ? Tag and retain, release, archive ?

Are there any warning messages ?

Is referential integrity affected ?

Are deletions logged or archived ?

Who can delete ?

Is there a choice to proceed to deletion or not ?



How do you intend to record – successful tests

– problems in tests

– the action taken and the result of a re-test

– who took part in the test• who prepared the data• who prepared the ‘control’ output• who ran the test• who investigated the fault, if any



What does the ‘user’ expect to see ?

Is the user impressed ?

Does the ‘user’ require changes (terms, progression, colours, positioning ..) (Quality reviewer + possibly the team coordinator) ?

When were the various tests performed ?

What was the equipment / software configuration ?

Is it compatible with the end-user’s equipment and operating system ?



What are the criteria for a– a successful test

– an unsuccessful test

Do you intend for a team walkthrough before a test is made or a revision test is made

Who certifies the test result

Who organises the test schedule - who monitors it ?



Do you intend to include a glossary of terms in your Acceptance Test Specification - which terms ?

Could these be superceded by a training session with the

user ?

What if the user leaves, gets another job, ……

What form of certification are you going to present to the end-user ?



What is the recommended method of recovery ?

Does it work ?

Is it automated or will the end user need to run through a series of keyboard operations

How ‘clear’ are the instructions - is it likely that the end user will overwrite critical data ?

Will you train the user as part of your delivery package ?



What are the security provisions ?

Who will administer them ?

How secure are they ?

What risk is there to the end user when the system fails ?

Is there any fall back position / procedure ?



Are you able, or do you intend that the end user will have access to ongoing support ?

How ?

What are your suggestions to the end user regarding– software upgrades (e.g. Windows2000 to WindowsXP)– hardware upgrades– on line connections to the system – on line customer/account tracking (e-commerce)– customer on line access– service and support



How do you intend to load the initial working data for

the client ?

Who supplies the effort and meets the cost ?

How many rows / records are involved ?

Is there going to be a delay time prior to the system being operable ?

How would this gap be controlled - e.g. transactions occurring but not able to update ?

Implementation/Acceptance Testing / 1 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability.

Documents

data availability

required data

data consistency

data currency

data flexibility

data reliability

data values

data item slide