System Development Techniques Individual Assignment

System Development Techniques

Diploma in Information Technology

Lesson 16

Learning outcomes After studying this chapter and the recommended reading, you should be able to:

• Describe implementation activities • Describe various types of software tests (unit,

integration, usability, and performance and stress) • Explain how and why each software test is used

Implementation and deployment

Testing

• Testing activities – process of examining a component, subsystem, or system

to determine its operational characteristics and whether it contains any defects.

– developers must have well-defined specifications for both functional and non-functional requirements.

– test developers develop precise definitions of expected operational characteristics based on the requirements specifications. (e.g. use case descriptions, activity diagrams)

Testing

• Testing activities – The developers test software by designing and building the

software, exercising its function, and examining the results.

– If the results indicate a shortcoming or defect, then the project team cycles back through earlier implementation or deployment activities until the shortcoming is remedied or the defect is eliminated.

Test type

• Four type of testing for different phase. – During Implementation • Unit Testing • Integration Testing

– During Deployment • System testing • User acceptance testing (UAT)

Test type

• During Implementation – Unit Testing • Software components must perform to the defined

requirements and specifications when tested in isolation • for example, a component that incorrectly calculates

sales tax amounts in different locations is unacceptable.

Test type

• During Implementation – Integration testing • Software components that perform correctly in

isolation must also perform correctly when executed in combination with other components. • They must communicate correctly with other

components in the system. • For example a sales tax component that calculates

incorrectly when receiving money amounts in foreign currencies is unacceptable .

Test type

• During Deployment – System testing • A system or subsystem must meet both functional and

non-functional requirements. • For example an item lookup function in a Sales

subsystems retrieves data within 2 seconds when running in isolation, but requires 30 seconds when running within the complete system with a live database.

Test type

• During Deployment – User acceptance testing (UAT) • Software must not only operate correctly, but must also

satisfy the business need and meet all user “ease of use” and “completeness” requirements. • for example, a commission system that fails to handle

special promotions or a data-entry function with a poorly designed sequence of forms is unacceptable.

Test case

• A test case is a formal description: – A starting state or condition – One or more events to which the software must

respond – The expected response or ending state

Test data

• Test data – Represented by the starting and ending states and the

events. – For example,

• the starting state of a system may represent a particular set of data. – such as the existence of a particular customer and order for that

customer. • The event may be represented by a set of input data items.

– such as a customer account number and order number used to query order status.

• The expected response (ending) may be a described behavior. – such as the display of certain information, or a specific state of stored

data, such as a canceled order.

Unit Testing

• Unit testing – lowest level testing for a new software system. – In object-oriented development approaches, a unit can be

defined as • an individual method or • a class or • a small set of closely integrated classes such as a package.

– primary purpose is to test a small piece of the code in isolation to make sure that it functions correctly before it is integrated into a larger program.

– make sure that the unit is error-free before being integrated into the larger program.

Unit Testing

• Three primary characteristics of a unit test: – done in isolation. – test data and the test are done by the programmer who

wrote the code. – It is done quickly without a large requirement for other

resources.

Unit Testing

• Unit test of a component often depends on others unit. – either to receive a parameter or to output a result. – Example below:

• Blue is the unit to be tested • Green is the input or output units.

Unit Testing

• Unit test would need a driver and a stub to be written and used to test the unit.

• In this example, the stubs are overlapped to indicate that a single stub class could be used to receive all unit test results.

Unit Testing

• Programmers should use automated tools (e.g. JUnit) to write unit tests codes.

• Unit test data should include both good and bad test data. • Unit testing should enhance the programmer’s productivity,

not consume a lot of resources. • In an iterative development project where the philosophy is

that the system is developed organically, software methods or classes can be written, unit tested, and quickly integrated into the new system as it gradually “grows.”

Integration Testing

• Integration testing – to test the interfaces between these units and to

test the entire integrated piece of software. – evaluates the functional behavior of a group of

classes or components when they are combined together.

Integration Testing

• Two types of results that can be tested. – test the interface itself between the components.

• Interface incompatibility. – For example, one method passes a parameter of the wrong data type

to another method. • Parameter values

– A method is passed or returns a value that was unexpected, such as a negative number for a price.

• Unexpected state interactions – The states of two or more objects interact to cause complex failures,

Example bubble tea order object state is “collected” and is passed to on to a Place Order process.

– tested is the value of the expected result.

Integration Testing

• Integration testing activities – Building the component for integration test.

• Write driver and stub for integration testing. • Use automated tools

– Creating test data. • Integration test data is more complex and usually requires

coordination between programmers. • Responsibility for coordinating the creation, formatting, recording,

use, and updating of the test data must be assigned.

Integration Testing

• Integration testing activities – Conducting the integration test.

• Decisions must be made and assignments given about who will conduct the integration tests, how they are done, what resources are used, and how frequently they are executed.

– Evaluating the results. • Often this requires involvement by all the programmers.

– Logging test results. • An error log is usually kept at this point to ensure that errors are

tracked and corrected.

Integration Testing

• Integration testing activities – Correcting the code and retesting.

• Programmer makes the corrections, conducts any required unit tests, and submits the components back for integration testing.

• The person conducting the integration test usually attempts to identify and isolate the cause of the error as much as possible.

System testing

• System test – a comprehensive integration test of the behaviour of an

entire system or independent subsystem. – performed at the end of each iteration where software is

completed. – to verify the functional and non-functional requirements,

• Business functions • Response time • Stability • Resources usage • Throughput • Speed

System testing

• Type of System test – Build and smoke – Performance test (stress test)

• Response time • Throughput

System testing

• Build and smoke test – is a system test that is typically performed daily or

several times per week. – The system is completely compiled and linked

(built), and a list of tests is executed to see whether anything malfunctions in an obvious way (“smokes”).

System testing

• Build and smoke test – provide rapid feedback on significant integration problems. – Any problem that occurs during a build and smoke test

must result from software modified or added since the previous test.

– Daily testing ensures that errors are found quickly and that they can be easily tracked to their sources.

– Less-frequent testing provides rapidly diminishing benefits because more software has changed and errors are more difficult to track to their sources.

System testing

• A performance test, (stress test) – determines whether a system or subsystem can meet such

time-based performance criteria as response time or throughput.

– Response time requirements • specify desired or maximum allowable time limits for software

responses to queries and updates.

– Throughput requirements • specify the desired or minimum number of queries and

transactions that must be processed per minute or hour.

System testing

• Performance tests – are complex because they can involve • multiple programs, • subsystems, • computer systems, and • network infrastructure.

– require a large suite of test data to simulate system operation under normal or maximum load.

User Acceptance Testing (UAT)

• User acceptance test (UAT) – is comprehensive system testing to determine whether the

system fulfills user requirements and can support all business and user scenarios.

– normally the final stage in testing the system. – Although the primary focus is usually on the functional

requirements, the non- functional requirements are often also verified.

User Acceptance Testing (UAT)

• User acceptance test (UAT) – In some cases, UAT is a formal milestone, and requires

completion and sign-off by the client. – Details of acceptance tests may even be included in a

request for proposal (RFP) and procurement contract when a new system is built by or purchased from an external party.

– Payments to the developers are often tied to passing specific acceptance tests.

User Acceptance Testing (UAT)

• User acceptance test (UAT) – All too often, because the project is behind and the

delivery date is fast approaching, UAT is minimized or partially skipped.

– However, minimizing the UAT is always a mistake and a source of problems and disagreements.

– It is the UAT that verifies that the system is ready to be deployed.

– If the UAT is minimized or skipped, then it is almost a certainty that the deployed system will have major problems.

User Acceptance Testing (UAT)

• Planning the UAT – should be included in the total project plan,

• included in specific iterations or have its own iterations toward the end of the project.

– Detailed plans for the UAT itself need to be developed early.

– Waiting until late in the project to plan the UAT causes serious difficulties and delays.

– test functional and nonfunctional requirements. .

User Acceptance Testing (UAT)

• Planning the UAT – Test cases should be identified to test various business

events, including • external events (from the users), • temporal events (such as month-end and year-end processing and

reporting), and • state events (such as inventory order points triggered).

– The test plan include test cases to verify the fulfillment of the specification.

User Acceptance Testing (UAT)

• Planning the UAT – Use user stories and use cases descriptions as inputs to

develop UAT test cases. – Developing the details of what is to be included in the UAT

occurs throughout the project. – The UAT test plan begins early and continues throughout

the project. – As each requirement is specified, the following question

should be asked: “How can the UAT test that this specification is complete?”

User Acceptance Testing (UAT)

• Preparation and Pre-UAT Activities

Simple UAT test case list

User Acceptance Testing (UAT)

• Preparation and Pre-UAT Activities – UAT test data • Two primary types of test data:

– data entered by users and – internal data residing in the database.

• The test data entered by users can be – precisely defined and documented.

» verification of expected results is easier. – create ad hoc data based on the requirement to be tested

User Acceptance Testing (UAT)

• Management and Execution of the UAT – decide who will participate and who has responsibility for

the UAT. – Ideally system users have primary responsibility.

• take full responsibility for identifying test cases, • creating test data, and • carrying out the UAT.

– Unfortunately, in many organizations, the users either are not prepared, do not have enough expertise, or do not have time from their regular responsibilities to take over the testing completely.

– it is common that some project personnel are required to help plan, organize, and execute the tests on behalf of system users.

User Acceptance Testing (UAT) • Management and Execution of the UAT – both users and development personnel are part of the

team. – Specific tests need to be scheduled. – Test data needs to be ready and in place. – Specific users will have assignments to complete their

tasks. – At the conclusion of each test, the results must be verified.

If there are failures, the required fixes must be documented and tracked.

– The test case tracking list must be kept to track errors (if any)

User Acceptance Testing (UAT)

• Management and Execution of the UAT – Test case tracking list

Summary

• Four type of testing for different phase. – During Implementation • Unit Testing

– Software components must perform to the defined requirements and specifications when tested in isolation

• Integration Testing – Software components that perform correctly in isolation must

also perform correctly when executed in combination with other components.

Summary

• Four type of testing for different phase. – During Deployment • System testing

– A system or subsystem must meet both functional and non- functional requirements.

• User acceptance testing (UAT) – Software must not only operate correctly, but must also

satisfy the business need and meet all user “ease of use” and “completeness” requirements.

Read

Textbook:

• Satzinger, Robert & Stephen Chapter 14