Implementation/Acceptance Testing / 1 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability.
Published byModified over 4 years ago
Presentation on theme: "Implementation/Acceptance Testing / 1 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability."— Presentation transcript:
Implementation/Acceptance Testing / 1 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability 3. Data currency 4. Data consistency 5. Data flexibility 6. Data efficiency
Implementation/Acceptance Testing / 2 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 3 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 4 Implementation and Acceptance Testing 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..
Implementation/Acceptance Testing / 5 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 6 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 7 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 8 Implementation and Acceptance Testing Other considerations: Concurrency control Access controls Recovery systems Database privacy
Implementation/Acceptance Testing / 9 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 10 Implementation and Acceptance Testing Maintenance : data entry Forms navigation Valid data entries Valid / correct calculations Tools - probably searching and sorting
Implementation/Acceptance Testing / 11 Implementation and Acceptance Testing 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’.
Implementation/Acceptance Testing / 12 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 13 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 14 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 15 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 16 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 17 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 18 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 19 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 20 Implementation and Acceptance Testing 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 ?
Implementation/Acceptance Testing / 21 Implementation and Acceptance Testing 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
Implementation/Acceptance Testing / 22 Implementation and Acceptance Testing 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 / 23 Implementation and Acceptance Testing