Project 2 Quarter 8 ATM SYSTEM

Combined, all of them emphasize a standard approach to testingwith the following steps: usability testing, unit testing, integration testing, function testing,system testing, acceptance

PROJECT ON ATM SYSTEM

Developed by

Name: Huỳnh Thủy Ngân

ATM SYSTEM

Name of the Coordinator : Phạm Tiến PhúcName of the Developer : Huỳnh Thủy NgânDate of Submission : 20th Jun 2012

CERTIFICATE

This is to certify that this report, titled ATM System, embodies the original work done

by Huỳnh Thủy Ngân in partial of their course requirement at NIIT

Coordinator: Phạm Tiến Phúc

We have benefited a lot from the feedback and suggestions given to us by Mr PhạmTiến Phúc and other faculty members, and the machine room coordinator

- Fund transfer within the same bank

On the basic of these features, prepare a white paper for testing the ATM system Thewhite paper should present the general requirements of an ATM system and discuss thefollowing points:

- Test environment that needs to be set up to test an ATM system

- Testing techniques that need to be adopted to test an ATM system

- Testing tools that need to be acquired to test an ATM system

- Risk involved in testing an ATM system

- Typical components of a test plan that need to be developed for an ATM system

- Test metrics that need to be gathered while testing an ATM system

One of the best ways to guarantee long term performance is through rigorous,standardized testing at both the component and system levels Testing systems checkwhether ATM equipment meets their design specifications, confirm that products fromdifferent manufacturers can work together, measure performance against trafficcontracts, and provide assurances that the underlying physical resources are operatingcorrectly

IDEAL TEST ENVIRONMENT FOR

Intel EtherPro 10/100 NIC

* Windows 2000 Advanced Server * Windows 2000 SP1 Server* SQL Server 2000 * SOAP Toolkit

End-user machines Various 700 MHZ

64 MB RAM, 10 GB HD

* Windows 2000 Professional

* Internet Explorer 5.0 or later/Netscape browsers

SYSTEM TEST ENVIRONMENT

Intel EtherPro 10/100 NIC

* Windows 2000 Advanced Server

256 MB of RAM, 70-GB HD

Intel EtherPro 10/100 NIC

* Windows 2000 Advanced Server

256 of MB RAM, 29-GB HD

Intel EtherPro 10/100 NIC

* Windows 2000 SP1 Server* SQL Server 2000 * SOAP Toolkit

Client application

server

256 MB of RAM, 19-GB HD

Intel EtherPro 10/100 NIC

* Windows 2000 Advanced Server

End-user machines Various 700 MHZ

64 MB RAM, 10 GB HD

* Windows 2000 Professional

* Internet Explorer 5.0 or later/Netscape browsers

INDIVIDUAL PROJECT SCHEDULE

S

No

1 Analyze the given case study to identify the requirements 2 Hrs

2 Research for relevant information

Prepare a rationale for recommendations made in the solution 2 Hrs

3 Prepare the white paper after appropriate study 2 Hrs

4 Prepare the white paper after appropriate study

Submit the white paper to the faculty

2 Hrs

5 Present the white paper in class

Answer viva-voice related to the white paper

2 Hrs

METHODOLOGY APPROACH PROCESS OVERVIEW

General Testing Guidelines

The steps in this testing plan are to ensure a smooth transition of code from a developmentenvironment to its production usage The general approach in most recommended testingplans have been considered Combined, all of them emphasize a standard approach to testingwith the following steps: usability testing, unit testing, integration testing, function testing,system testing, acceptance testing and regression testing

Testing starts with the developer and the customer verifying (usability testing) the interfaceearly in development The developer develops the code to support the requirements andexercises it (unit test) After this, the interfaces between modules is tested (integrationtesting), and then independent testing against requirements (functional) is conducted.Exercising all components in a production like environment (system testing) with final testing

by the customer (acceptance testing) completes most of the process This also takes intoconsideration the need to retest software in the event of ongoing fixes (regression testing)

Early Development of Test Cases

Test cases are developed early in the process To complement the Extreme Programmingparadigm, which is discussed below, use cases will be developed early in development.These describe the use of a system by an “actor” and form the basis for both design and testcases

Extreme Programming

The most common method of software development is the waterfall method, which specifies aphased approach to software development – including plan, design, code, test, and releasecycles If a project is canceled during coding or earlier, it’s probable that no working code wasdeveloped, and the entire project will yield no tangible results

METHODOLOGY APPROACH PROCESS OVERVIEW

XP processes also include pair-up design sessions and code sessions; this ensures all code that

is created is viewed by two people After the software is created, it may be re-factored, andthen tested on a single “continuous integration” machine After copying the code, developersrun a full suite of the “test first” unit tests If the code passes all tests, the developers cancheck in the code and the unit test XP unit tests and building are covered in more detail under

“unit tests”, below

Essentially, stories allow coders to begin development early, and an on-site customer ensuresthat the software that is created actually meets the customer’s need “Getting to the code”early transforms expenses into working software; because of the priorities, it’s possible for thecustomer to cancel the project at 25% of schedule and actually get working software thatfulfils the most important 25% of the business need

Extreme Programming also uses the concept of “Project Velocity” to measure the cost, time,and relative late/early-ness of the project

In addition to a project-level function point analysis, Smart Savings also asked it’s developers

to measure the effort involved in creating the software in Extreme Programming units (XPU)

By dividing the XPUs by the typical development speed (XPU’s developed per week onprevious projects) the team produced a man-month estimate for development of the ATMproject; this estimate, along with function points and risk-adjusted estimates, was used tocreate the $350,00 bid for the ATM Project (Note: The deviation from “book” XP ofworking for a fixed price was a concession to the customer made to win the contract Thecustomer insisted on this concession to minimize uncertainty.)

The XP method practiced by Smart Savings Co feeds directly into the testing phase of theproject Although “book” XP does not include a testing phase, this concept has not exactlybeen embraced by the business community As a result, Smart Savings Co typicallyincludes a testing phase in it’s software projects similar to the testing phase advocated byDonaldson/Siegel in their book Successful Software Development

METHODOLOGY APPROACH

DEFINITIONS

Common Terminology

Acceptance Testing Formalized testing by the customer to determine completion of the product

prior to delivery and payment of services.

Base Line The version of the source code currently in production This is sometimes

referred to as the “gold” copy of the software currently in production.

Black Box Testing Testing software for its basic functionality without specifically exercising

known pieces of code.

Defect An instance of where the software does not meet the requirement.

Function Testing Formalized testing of modules for their functionality based on the

requirements document.

Glass Box Testing

White Box Testing

Both terms are a form of testing where internal coding knowledge is used to determine testing.

System Testing Formalized testing where the system is exercised under conditions similar to a

regular production environment.

Integration Testing Testing modules together to ensure the interfaces are compatible and meet

requirements.

System Testing Formalized testing where the system is exercised under conditions similar to a

regular production environment.

Test Case A specific set of steps to be followed to exercise a specific aspect of software.

The steps include how to setup, how to provide the input and the expected output.

Unit Testing Testing performed on a specific module by the developer.

Use Case A story about the use of the system

RISK ANALYSIS

Mitigation:

Budget is reduced Description:

The budget could be reduced if other portions of development incur cost overruns.

Mitigation: There are two forms to address this as follows:

1 Review the prioritization of the system testing areas based on the analysis and adjust accordingly.

2 Review the situation with the customer and request additional funding.

3 The SMART SAVINGS Co absorbs the cost.

Time is reduced Description:

Available time for testing could be reduced if other portions of development run over estimates time.

3 The schedule committed to the customer allows additional “buffer” time for QA beyond that predicted by the function-point estimate.

4 The contract provides four factors that the customer can use to control the project: Time, Quality, Features, and Resources If the QA phase runs over the committed complete date, then, to some extent, it is the customers choice.

5 The On-Site customer will get daily feedback and have options to “steer” the project to meet the complete date Again, if the project is late, then, to some extent, it is by customer choice.

6 If needed, SMART SAVINGS Co can absorb the cost of QA over-runs.

Co fix the defects without reimbursement and, in fact, insist on a discount because the software is “late.”

Mitigation:

1 Testing group has one additional man-month of budget.

2 Beyond that month, SMART SAVINGS Co will absorb the cost

3 Testing Manager will use FogBuz, internet-enabled bug tracking software,

to evaluate state of software and request additional development resources

as needed.

4 Customer will state explicit acceptance test requirements up front so test manager can prioritize defects and ensure that customer-required needs are met.

5 QA Phase as predicted by previous experience and function point analysis

is shorter than the date presented to the customer; this adds a “buffer” zone.

Turnover causes the

1 Explicit Contract forces customer to pay a nearly-prohibitive hourly fee for changes made after the specification is complete This provides the budget for testing to continue after “old” budget is expended

2 XP Methodology makes re-interpretation of “stories” extremely rare.

3 XP Methodology allows additional stories, which add Extreme Programming Units and Function Points, which increases the cost Code shipped to

customer fails to meet

quality standards

Description:

Although the code is passed by developers, approved by the test manager, and approved by the customer, the tests are minimal and the software has serious defects The customer insists of free “fixes”, and SMART SAVINGS has to either fix them for free or a hefty discount, or risk loss of professional reputation.

Mitigation:

1 Development, Testing, and the customer each perform an independent audit to uncover defects: Unit tests, functional tests, system tests, and the acceptance test This provides a layer of safety: While some defects may get past one tester, this form of testing ensures three, four, or more people will test functionality.

2 The “test first” and use-case based testing performed during the development cycle is claimed by XP enthusiasts to eliminate the need for

a QA group While this may not be the case, having a QA group does in fact add a layer of redundancy or additional confidence.

3 Because the customer performs their own acceptance test, the software will not pass unless the customer is willing to either “skip” on the test or make a choice to “skimp” on quality Either way shows a lack of commitment to quality and desire to “get the product out the door.” Under these conditions, it would be very hard for the customer to argue that SMART SAVINGS needs to make uncompensated bug fixes: As

UNIT TEST/INTEGRATION TEST PLAN

Approach

SMART SAVINGS Company defines unit and Interface testing as part of the developmentcycle; these tasks will be performed before the “Code Complete” date and the responsibility forthese tests lie with the software developers Because this process is testing, it is described below

Unit Testing:

All developers at SMART SAVINGS Co sit through a 1-hour presentation on unit testingtechniques before commencing to code First, all developers will ensure that fully dressed usecases are created Although use cases are associated more often with the Unified ModelingLanguage and the Unified Process, they complement the concept of stories within XP The usecase establishes the first point of traceability for further testing (Larman, 2002)

Before Developers create a logical unit (or module) of code, they create code to execute and testthe unit/module/object This code creates the object, performs operations on the object, and thenchecks the state of the object to ensure that it’s correct; this is a part of the Xtreme Programmingmethodology practices at SMART SAVINGS Company For example, if the programmer werecreating an object that simulates a cashier’s drawer, the code might look something like this inC++:

instance These classes as a whole would compose a “unit.”

When this script is devised, the object hasn’t even been coded, and it will not compile Thisprovides an additional “sanity check” and forces coders to perform design before coding;otherwise, writing the script would be impossible

UNIT TEST/INTEGRATION TEST PLAN

In keeping with XP methodology, all test scripts must execute 100% pass before the code can bechecked in

Interface Testing:

After Unit Testing is complete, developers must consider every other class that their object could

“interface” with After writing up what the various interfaces are, the developer will meet withthe main coder on the other objects and the two write up a “use-case” scenarios for theinterfaces The developer will then code and test interface tests in the same style as unit testsabove

Setup and Configuration Requirements

In keeping with the XP concept of continuous integration, all development machines must have

MS Visual Source Safe (for Version Control) , MS Visual Basic, and the Net Framework andIntegrated Development Environment Continuous Integration testing is performed on a separate

“build” machine, as described by Xtreme Programming Installed Developers run the entire suite

of checked-in unit tests overnight In addition, the developers will need a machine to simulatethe mainframe from which transactions are downloaded and performed; the customer willprovide this machine

Defect Handling

In the event that a unit test fails overnight, the coder who wrote that section will examine thetest, re-factor the code if needed, check in his code and run a new test the next day The project